Introduction a DNSSEC
Domain Name System
Léger rappel
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 sur le web 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.
Arborescance hiérarchique DNS
Lorsqu'un utilisateur souhaite accéder à un site web, il utilise généralement un nom. Ce nom est très pratique car il est beaucoup plus simple à retenir qu'une adresse IP mais il nécessite d'être résolu. Et pour ce faire, DNS utilise un processus particulier. Avant tout l'utilisateur va faire suivre sa requête de résolution à un résolveur distant, qui est souvent par défaut le résolveur du FAI concerné. Par exemple pour www.wikipedia.fr, le résolveur va alors entamer la procédure suivante :
- Demande l'adresse du TLD « .fr » à l'un des serveurs racine
- Demande l'adresse du serveur « wikipedia.fr » au serveur .fr
- Demande l'enregistrement « www » au serveur wikipedia.fr
- Le résolveur envoie finalement la réponse à l'utilisateur qui peut désormais interroger son serveur web
La résolution DNS (www.afnic.fr)
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.
Vulnérabilités
DNS n’est pas sur (RFC 3833), les principaux problèmes connus sont :
- 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 se 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 ceci 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