Domain Name System - Le protocole
DNS est l'un des premiers protocoles à avoir vu le jour. Il a été défini et implémenté dans les années 80,
c'est une brique fondamentale dans l'internet d'aujourd'hui.
On peut le comparer à une base de donnée distribuée sur des milllions de machines. Il permet de faire la relation entre le nom d'une machine et son adresse IP.
Il est composé de 13 serveurs racines répartis dans le monde, qui constituent le point d'entrée dans le schéma arborescant (hiérarchique) ci-dessous. Ensuite viennent les « Top-Level Domains » ou domaines de premier niveau (.fr, .com, etc..) puis les noms de domaine classiques comme « fnac.fr ». DNS repose sur un système de communication entre ces différentes strates pour pouvoir identifier la machine étant capable de donner la réponse a la requête d'un internaute.
Par défaut DNS utilise UDP et ne chiffre pas ses paquets. Dans la capture suivante nous pouvons voir tous les champs qui composent un paquet.
Nous noterons que certains sont plus sensibles que d'autres :
-
Identification : Un identifiant de 16 bits généré aléatoirement. Cet identifiant est copié dans la réponse correspondante à la requête initiale. Il est nécessaire qu'un nouveau nombre aléatoire, de 16 bits, soit généré pour chaque demande.
-
Total Additional Resource Records : Permet de rajouter des enregistrement supplémantaires dans la réponse à une requête.
Les messages des requêtes et des réponses DNS utilisent un format uniforme. Ces messages peuvent être transportés dans des datagrammes UDP par le port 53 ou des datagrammes TCP par le port 53. Les datagrammes UDP ont une taille fixe de 512 octets et doivent être tronqués si le message est plus long.
Ceci est identifié par le flag DNS TC.
Sécurité : les vulnérabilités
Le protocole DNS n’est pas très sur, les principaux problèmes connus sont (RFC 3833):
-
Le Cache Poisonning
-
Les attaques de type Denial of Service
-
Le Name Chaining
-
L'interception de paquets
-
Le brute force du champ Identification
La RFC 3833 décrit plutôt bien ces problèmes, nous nous intéresserons surtout à l'un d'eux qui est à l'origine de plusieurs attaques, le Cache Poisonning :
On peut citer l'attaque de Bradesco au travers du FAI Brésilien NET Virtua que l'on soupçonne d'avoir été empoisonné. La faille Kaminsky révélée à la Black Hat 2008 dénonce se problème et démontre comment empoisonner un serveur de noms pour qu'il réponde de fausses informations.
Explication :
Dans le cas d'un serveur A, envoyant une requête vers un serveur B. L'objectif du "Pirate" est de faire passer l'une de ses propres réponses pour une réponse du serveur B, et ainsi empoisoner le cache du serveur A. Dans ce cas le serveur A, répondra la fausse information transmise par le pirate lorsqu'on lui posera la bonne question.
Dans un premier temps, le pirate déclanche la résolution d'une adresse par le serveur A en lui envoyant des requêtes. Ensuite, sachant que le serveur A va envoyer des requêtes et attendre des résponses, le pirate va pouvoir forger des réponses erronées et les envoyer au serveur A.
Cette attaque est possible principalement du au fait qu'il n'y ai pas d'authentification. La seule authentification se base sur le fait que la réponse doit avoir la même valeur que la requête dans le champ Identification du paquet DNS et que le port soit le bon.
Problématique et enjeux
Tout cela fait émerger la problématique suivante :
Comment assurer l’intégrité des données et authentifier les résolveurs / serveurs faisant autorité tout en conservant la rétrocompatibilité avec DNS ?
Les principaux enjeux sont sont de pouvoir :
-
Assurer la sécurité d’accès à la ressource demandée aux 3 milliards d’utilisateurs
-
Trouver une solution assez légère pour ne pas surcharger les serveurs de noms