Le protocole DNS assure la correspondance entre le nom d'une machine et son adresse IP. Un serveur DNS est en écoute par défaut sur le UDP port 53. Les attaques décrites ici concernent les faiblesses du protocole DNS.
C'est la première attaque que nous allons décrire. Elle aboutit à un détournement de flux entre deux machines à l'avantage du pirate.
Imaginons qu'un client A veuille établir une connexion avec une machine B. La machine A connaît le nom de la machine B mais pas son adresse IP, ce qui lui empêche pouvoir communiquer avec. La machine A va donc envoyer une requête au serveur DNS du réseau de B pour connaître l'adresse IP de B, cette requête sera identifiée par un numero d' identification (ID). Le serveur répond à cette requête en fournissant l'adresse IP de B et en utilisant le même numéro d'ID.
Ce numéro a une valeur comprise entre 0 et 65535.
Le DNS ID spoofing a pour but de d'envoyer une fausse réponse à une requête DNS avant le serveur DNS. De cette façon, le pirate peut rediriger vers lui le trafic à destination d'une machine qu'il l'intéresse.
Dans notre exemple, un pirate C doit répondre à A avant le serveur DNS (D) du réseau de B. Ainsi, il envoie à A son adresse IP associée au nom de la machine B. A communiquera alors avec le pirate C au lieu de la machine B.
Illustration :
Néanmoins, pour implémenter cette attaque, le pirate doit connaître l' ID de requête DNS. Pour cela, il peut utiliser un sniffer s'il est sur le même réseau, soit prédire les numeros d'ID par l'envoi de plusieurs requêtes et l'analyse des réponses.
Le principe de cette attaque est très similaire à celui de l'ARP-Poisoining. Pour gagner du temps dans la gestion des requêtes, le serveur DNS possède un cache temporaire contenant les correspondances adresses IP - noms de machine. En effet, un serveur DNS n'a que la table de correspondance des machines du réseau sur lequel il a autorité. Pour des machines distantes, il doit interroger d'autres serveurs DNS. Pour éviter de les interroger à chaque requête, il garde en mémoire (dans un cache), le résultat des précédentes requêtes.
L'objectif du pirate est d'empoisonner ce cache avec de fausses informations. Pour cela, il doit avoir un nom de domaine sous contrôle et son serveur DNS.
Imaginons qu'un pirate (A) possède le nom de domaine
attaquant.com, et son serveur DNS (C)
et qu'il veuille empoisonner le cache du serveur DNS (B) du réseau
cible.net.
Le pirate envoie une requête au serveur DNS (B) du réseau
cible.net demandant la résolution du
nom de domaine attaquant.com.
Le serveur DNS (B) de cible.net va
donc envoyer une requête sur le serveur DNS (C) de l'attaquant
(c'est lui qui a autorité sur le domaine attaquant.com). Celui-ci répondra et joindra des
informations additionnelles falsifiées par le pirate (un nom de
machine (D) associé à l'adresse IP (A) du pirate). Ces informations
seront mises en cache sur le serveur DNS (B) de cible.net. Si un client quelconque (E) demande
l'adresse IP pour le nom de la machine (D), il recevra l'adresse du
pirate (A) en retour.
Illustration :
Configurez votre serveur DNS pour qu'il ne résolve directement que les noms de machine du réseau sur lequel il a autorité.
Autorisez seulement des machines internes à demander la résolution de noms de domaines distants.
Mettez à jour ou changez les logiciels assurant le service DNS pour qu'ils vous protègent des attaques décrites précédemment.
Il existe de nombreux documents décrivant la configuration du service DNS. Dans le monde GNU/Linux, la référence de base est le DNS HOWTO. On peut aussi citer DNS et sécurité.
En ce qui concerne le volet sécurité, deux références sortent du lot :
-
Le guide publié par le CERT : Securing an Internet Name Server est une excellente référence sur la syntaxe des fichiers de déclaration de zones.
-
La page Web Secure BIND Template est dédiée à la publication de patrons de fichiers de configuration. Elle est très régulièrement mise à jour depuis plusieurs années.