Sécurité DNS

Risques et contre mesures

DNS Cache Poisoning and Spoofing

• La finalité de l’empoisonnement DNS est d’acheminer les utilisateurs vers un site Web frauduleux. Par exemple, un utilisateur tape « gmail.com » dans un navigateur Web avec pour objectif d’aller consulter sa boîte email. Le DNS ayant été empoisonné, ce n’est pas la page gmail.com qui s’affiche mais une page frauduleuse choisie par l’attaquant, dans le but par exemple de récupérer les accès aux boîtes emails. Les utilisateurs saisissant le nom de domaine correct, ils ne se rendent pas compte que le site Web qu’ils visitent est un faux, une escroquerie.
  Cela crée une opportunité parfaite pour les attaquants d’utiliser des techniques de phishing pour soutirer de l’information, qu’il s’agisse des informations d’identification ou des informations de carte de crédit, auprès de victimes peu méfiantes. L’attaque peut être dévastatrice, en fonction de plusieurs facteurs, selon l’intention de l’attaquant et la portée de l’empoisonnement DNS.

• Solution: Le Cache Poisoning and Spoofing est très difficile à détecter. Il peut durer jusqu’à ce que le TTL expire sur les données en cache ou qu’un administrateur le réalise et résolve le problème. En fonction de la durée du TTL, les serveurs peuvent prendre des jours pour résoudre le problème de leur propre chef.
  Les meilleures méthodes pour empêcher une attaque par empoisonnement du cache DNS incluent la mise à jour régulière du programme, la réduction des temps TTL et la suppression régulière des caches DNS des machines locales et des systèmes réseau.
  Pour les registres qui le permettent la mise en place de DNSSEC est la meilleure réponse afin de signer les zones des noms de domaine sur l’ensemble de la chaine et rendre impossible une attaque par empoisonnement du cache.

Attaque DDoS et par amplification

• Les attaques DDoS se produisent généralement à l’aide d’un botnet. L’attaquant utilise un réseau d’ordinateurs infectés par des logiciels malveillants pour envoyer de grandes quantités de trafic vers une cible, comme un serveur. Le but est de surcharger la cible et de ralentir ou de l’écraser.
  Les attaques par amplification ajoutent plus de puissance. Plutôt que d’envoyer le trafic directement d’un botnet à une victime, le botnet envoie des demandes à d’autres systèmes. Ces systèmes répondent en envoyant des volumes de trafic encore plus importants à la victime.
  Les attaques par amplification DNS en sont un exemple parfait. Les attaquants utilisent un botnet pour envoyer des milliers de demandes de recherche pour ouvrir des serveurs DNS. Les demandes ont une adresse source falsifiée et sont configurées pour maximiser la quantité de données renvoyées par chaque serveur DNS.

• Solution: Certains pare-feu peuvent être configurés pour reconnaître et arrêter les attaques DDoS au fur et à mesure qu’elles se produisent en supprimant des paquets artificiels essayant d’inonder les systèmes sur le réseau.
  Une autre façon de lutter contre les attaques DDoS consiste à héberger notre architecture sur plusieurs serveurs. De cette façon, si un serveur devient surchargé, un autre serveur sera toujours disponible. Si l’attaque est faible, les adresses IP d’envoi du trafic peuvent être bloquées. En outre, une augmentation de la bande passante du serveur peut lui permettre d’absorber une attaque.

Les sécurités mises en place et configuration

Dans le but de se protéger de plusieurs problèmes de sécurité liés au protocole DNS, nous avons mis en place DNSsec ainsi que la désactivation du transfert de zone.

1. Pour empêcher le transfert de zone avec bind, nous avons ajouté la commande suivante dans le fichier named.conf.options

allow-transfer { none; };

2. Dans ce même fichier nous allons ajouter ces trois lignes afin d'activer DNSsec.

dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

3. A présent nous allons devoir générer une paire de clé privé/public "Key Signing Key" et une nouvelle paire privé/public "Zone Signing Key". Pour cela il suffit de taper les commandes suivantes directement dans le container /etc/bind/.

dnssec-keygen -a RSASHA256 -b 2048 -f KSK l1-5.ephec-ti.be dnssec-keygen -a RSASHA256 -b 1024 l1-1.ephec-ti.be

4. Maintenant les deux paires privé/public créés, nous allons copier le nom des deux .key et les insérer comme ci-dessous dans le bas de notre fichier de zone (pour nous db.l1-5.ephec-ti.be)

$INCLUDE Kl1-5.ephec-ti.be.+007+00810.key $INCLUDE Kl1-5.ephec-ti.be.+007+58100.key

5. Tout est en place, nous pouvons donc créer la copie signée de notre fichier de zone pour ensuite aller la déclarer à la place de l'ancienne dans notre zone.

• Exécuter la commande suivante en remplaçant ce qu'il faut pour générer la copie signée:
  

dnssec-signzone -t -g -A -3 $(head -c 1000 /dev/urandom | sha1sum | cut -b 1-16) -N INCREMENT -k KSK -o "nom de domaine" -t "nom du fichier de zone" "ZSK.key"

• Dans le named.conf.local, ajouté signed à la suite de votre fichier de zone pour que cela corresponde au nom du fichier signé.
  

zone "l1-1.ephec-ti.be" IN { type master; //file "l1-1.ephec-ti.be"; file "l1-1.ephec-ti.be.signed"; }

6. Tout devrait être opérationnel. Faite un restart de votre bind ou de votre container puis tester avec la commande dig ou un mxtool. Voici deux exemples.