GESTION DU RENOUVELLEMENT DES CLEFS POUR DNSSEC

Transcription

1 Ecole Nationale Supérieure des Télécommnunications de Bretagne RAPPORT DU STAGE DE FIN D ETUDE GESTION DU RENOUVELLEMENT DES CLEFS POUR DNSSEC Mai Septembre 2003 Réalisé par : LEI Zhi Yu Encadrants : Olivier COURTAY Bernard COUSIN Correspondant école : Francis DUPONT

2 Remerciements Remerciements à tous mes encadrants : Olivier Courtay, Bernard Cousin et Francis Dupont, pour leur accueil chaleureux et leur conseils. Merci au M. Sylvain Gombault et Gille Guette pour leus conseils. Adresses LEI Zhi Yu ENST Bretagne Option RSIFI 2, rue de la Châtaigneraie Cesson Sévigné Cedex Tel : Zhiyu.lei@enst-bretagne.fr Olivier COURTAY Equipe Armor IRISA / INRIA Rennes Campus Universitaire de Beaulieu Avenue du Général Leclerc RENNES Cedex France Tel : Olivier.Courtay@irisa.fr Bernard COUSIN Equipe Armor IRISA/INRIA Campus Universitaire de Beaulieu RENNES Cedex Tel : Fax : Bernard.Cousin@irisa.fr Francis DUPONT ENST Bretagne Département RSM 2, rue de la Châtaigneraie Cesson Sévigné Cedex Tel : Francis.Dupont@enst-bretagne.fr - 2 -

3 Résumé Le DNS (Domaine Name System), est une partie indispensable de l Internet d aujourd hui, mais le système DNS original ne propose aucune protection contre des attaques variées, sa sécurisation est-elle devenu une nécessité. Depuis 1999, une extension sécurisée du DNS, DNSSEC, a été exploitée. DNSSEC garantit l intégrité des requêtes et des données et l authentification de la source en utilisant une système de cryptographie à clef publique et de signature numérique. De nouveaux enregistrements (RR KEY, SIG, NXT et DS) sont introduits au service DNS. Des enregistrements d'une zone DNS sécurisée sont signés, par des clefs privées associée à la zone. La durée de validité d'une clef est limitée et les clefs doivent être renouvelées périodiquement, mais ce genre de gestion s'avère coûteuse en temps pour le personnel d'administration. Ce stage est proposé par l IRISA (Institut de Recherche en Informatique et Système Aléatoire), comme une partie du projet IDsA (Infrastructure DNS Sécurisé et Applications). Le but de ce stage est de développer les outils nécessaires à une gestion automatisée de ces clefs de DNSSEC, afin d améliorer l efficacité du traitement des zones et des clefs changées, et de faciliter le travail de maintenance. La durée de stage est du 22 mai au 30 septembre. Ce stage se déroule au site rennais de l IRISA et de l ENST Bretagne. Une solution pour l automatisation de renouvellement des clefs dans DNSSEC est proposée au cour de ce stage, après avoir etudié le mécanisme courant du renouvellement des clefs. Cette solution consiste en un modèle conceptuel décrivant un algorithme nommé KRO, qui efficacement gère le processus de Key Rollover, et un logiciel, implémenté en langage C sous FreeBSD, correspondant au modèle KRO. Mots Clefs : DNSSEC, Key Rollover, Gestion automatisée, KRO - 3 -

4 Abstract Nowadays, the DNS (Domain Name System) is an essential part of the Internet, but originally DNS system did not propose any protection against various attacks and threats, its security had become a necessity. Since 1999, the security extension of the DNS, DNSSEC, was exploited. DNSSEC guarantees the data integrity in DNS messages (requests or response) and the authentication for the source of a message by using a system combined public key infrastructure with digital signatures. New resource records (RR KEY, SIG, NXT and DS) are introduced to service DNS. The resource records of a secured DNS zone are signed by private parts of key-pairs associated with that zone. But the period of validity of a key is limited and the keys must be renewed periodically (Rollover), this kind of management proved to be time-consuming for the personnel of administration. This intern project is proposed by IRISA (Institut de Recherche en Informatique et Système Aléatoire), as a part of IDsA project (Infrastructure DNS Sécurisé et Applications). The goal of this intern is to develop a tool needed for an automated management of these DNSSEC keys so as to improve the performance in processing the changed zones and keys, and to make the work of maintenance easier. The duration of the intern is from May 22 to September 30. This intern proceeded at Rennes, in the location of IRISA and ENST Bretagne. After having studied current mechanism of the keys rollover, a solution is proposed at during this intern, for an automated rollover of the keys in DNSSEC. This solution consists a conceptual model named KRO, which describes an algorithm handles the process of Key Rollover effectively, and a software corresponding to the process of rollover described by the model KRO, implemented in language C under FreeBSD. Keywords: DNSSEC, Key Rollover, Automated Management, KRO - 4 -

5 Sommaire Acronyme...6 I. Introduction...7 II. Contexte Le DNS Historique Architecture du système DNS Contenu d une zone Processus de résolution DNSSEC Extension sécurisée Clef et signature Chaîne de confiance (Chain of Trust)...20 III. DNSSEC Key Rollover Problématique KRO Un algorithme de Key Rollover Justification des choix Avantages et inconvénients Implémentation Découpage fonctionnel Flux d exécution Bibliothèques utilisées Interface utilisateur Résultat...36 IV. Déroulement du projet...40 V. Conclusion et perspectives...41 Index des matériels graphiques...42 Index des extraits du fichier...42 Références...43 Annexe A : Informations sur KEY, SIG et DS...44 Annexe B : Extraits des fichiers de configuration...46 Annexe C : Extraits du code source

6 Acronyme BIND Berkeley Internet Name Domain. Un des programmes DNS sous UNIX et Windows. RFC Request For Comments. DNS Domain Name System, système de noms de domaine DNSSEC DNS security extension PKI Public Key Infrastructure DoS Denial of Service TTL Time To Live. Durée de vie, la durée de validité des données. RR Resource Record. Enregistrement de données figurant pour un nom de domaine dans un serveur de noms. Les enregistrements de données sont de plusieurs types, voici la liste (non-exhaustive) des types d'enregistrements. A Enregistrement adresse AAAA Enregistrement adresse IPv6 CNAME Enregistrement alias NS Enregistrement serveur de noms SOA Enregistrement Start Of Authority TXT Enregistrement texte HINFO Enregistrement d information sur le serveur MX Enregistrement pour l échange du mail Des enregistrements spécifiés par DNSSEC, l extension sécurisé du DNS NXT Enregistrement Next, utilisé pour vérifier la non-existance d une ressource dans une zone KEY Enregistrement clef, la partie publique d une paire de clefs PKI SIG Enregistrement signature, contenant la signature numérique des enregistrements DS Enregistrement du type Delegation Signer RRset Un ensemble de RRs avec même nom, classe et type, par exemple : tous les adresses de en IPv

7 I. Introduction Le DNS (Domaine Name System), qui permet à une machine de communiquer sans connaître au préalable l adresse IP de ses correspondants, est une partie indispensable de l Internet d aujourd hui. Ce service est chargé, entre autres, de la conversion entre un nom de machine et son adresse IP et inversement, mais le système DNS original ne propose aucune protection contre des attaques variées, ni de moyen d authentification ou de contrôle l intégrité des informations obtenues. Une extension récente du DNS, DNSSEC (depuis mai 1999, RFC2535), vient d'être proposée afin d assurer l'authentification et l'intégrité des requêtes et des données DNS. Cette extension utilise une système de cryptographie à clef publique et introduit de nouveaux enregistrements (RR KEY, SIG, NXT et DS) au service DNS. Les enregistrements d'une zone DNS sécurisée sont signés par des clefs privées associée à la zone, afin de réaliser la sécurisation des données, qui est l'objectif principal de DNSSEC. Ainsi, des proposition sont données sur la sécurisation de transaction DNS. La gestion des clefs de zone s'appuie sur la structure hiérarchique des zones du DNS. Pour assurer un certain niveau de sécurité, la durée de validité d'une clef est limitée. Face à tous ces besoins, les clefs doivent donc être renouvelées périodiquement, mais ce genre de gestion peut s'avérer coûteuse en temps pour le personnel d'administration. Le but de ce stage est de développer les outils nécessaires à une gestion automatisée de ces clefs de DNSSEC, afin d améliorer l efficacité du traitement des zones et des clefs qui sont changées, et de faciliter le travail de maintenance du personnel d'administration à la fois. Ce stage est proposé par l IRISA (Institut de Recherche en Informatique et Système Aléatoire), comme une partie du projet IDsA (Infrastructure DNS Sécurisé et Applications). Dans les chapitres suivants, nous expliquerons brièvement d abord, l origine et fonctionnement du système de noms de domaine, DNS, la problématique qui provoque la création de l extension sécurisé de DNS, le DNSSEC, et les comportements principaux de ce dernier. Ensuite nous allons présentons notre solution pour le renouvellement des clefs dans DNSSEC, après avoir expliqué le mécanisme courant du renouvellement. Notre solution consiste d abord en un modèle conceptuel décrivant le processus de Key Rollover (renouvellement des clefs), nommé KRO, et des codes implémentés correspondant à notre modèle, que nous détaillerons. Nous presentons des résultats que nous avons obtenus d après notre solution, ainsi qu une conclusion et des perspectives future

8 II. Contexte L'accès aux services sur Internet se repose sur l'utilisation massive de l'infrastructure DNS. Aujourd'hui, son utilisation est tellement naturelle qu'elle est devenu inévitable. Aussi, sa sécurisation est-elle devenu une nécessité, vu des nombreuses attaques sur des sites célèbres commerciaux ou même des sites gouvernementaux. Donc, depuis des années récentes, une telle infrastructure sécurisée, DNSSEC, a été exploitée pour la sécurisation du service DNS. Dans la partie suivante, nous allons parcourir le principe du service DNS et son extension sécurisé, DNSSEC. 1. Le DNS 1.1 Historique Au début, l'internet (ou anciennement ARPAnet) était formé simplement de quelques machines. Elles avaient chacune une adresse que l'on retenait facilement vu leur faible nombre. Un fichier hosts.txt comprenait les noms des différentes machines avec leur(s) adresse(s). Les manipulations sur ce fichier sont peu à peu devenues trop lourdes avec l augmentation du nombre de machines connectée au réseau, car l'administrateur désirant nommer une machine devaient envoyer un courrier électronique au responsable de la maintenance du fichier, ce dernier effectuait la mise à jour, et publiait une nouvelle version du fichier. Il n'était pas souvent à jour, et les modifications étaient longues à se propager. Un nouveau système a donc été créé, puis mis en place pour remplacer l'ancien. Paul Mockapetris a conçu et spécifié le DOMAIN NAME SYSTEM, ou DNS, en éditant les RFC882 et RFC883, plus tard mises à jour par RFC1034 et RFC1035 [RFC03]. Ce sont les spécifications officielles du système DNS et ce système permet de gérer des milliers de machines, ayant des noms descriptifs. La base de données du DNS est mise à jour de façon distribuée, et qui permet à certaines machines de contrôler certains segments de la base de données, tandis que toute la base de données est accessible par des clients par un mécanisme client-serveur. Un système de réplication assure une fiabilité raisonnable, tandis que des caches augmentent la performance du système. D'autres protocoles existent pour associer des informations à des noms de machines, par exemple NIS ou yellow pages, un système développé par SUN, qui peut être configuré de manière à utiliser aussi le DNS pour la recherche de noms de machines. De même, certains clients peuvent utiliser plusieurs systèmes de recherche, la configuration est spécifique au système. Mais notre considération est plutôt concentrée sur le DNS

9 1.2 Architecture du système DNS ENST Bretagne Campus Rennes L architecture de la base de données DNS est un arbre inversé. La racine se trouve au sommet, et porte le nom vide mais s écrit. (ou racine). Chaque nœud de l'arbre porte une étiquette qui l'identifie par rapport à son parent. L'utilisation de majuscules ou de minuscules est indifférente dans l'écriture des noms d étiquettes. Seuls les lettres, les chiffres, et le symbole "-" sont autorisés. Le terme "nom de domaine" ici représente donc indifféremment les nœuds de l'arbre (domaines, sous-domaines) ou les feuilles (terminales). com edu fr cn irisa enst-bretagne Zone fr Zone enst-bretagne.fr Domaine fr titan rsm A xx.xx AAAA 2001:... [Fig.1 Arbre des zones] Dans l exemples ci-dessus, nous avons un domaine fr, que l'on peut aussi écrire fr. pour bien montrer qu'il est en haut de l'arbre. Ce nœud de l'arbre à un certain nombre de fils, comme irisa.fr ou enst-bretagne.fr dans la figure et bien sûr d autres fils comme tf1.fr ou sncf.fr. Un domaine est la partie de l'arbre présente sous un nom donné. Par exemple, le domaine fr contient le nœud fr ainsi que tous les nœuds dont le nom de domaine se termine par fr, c'est à dire tous des nœuds sous le nœud fr. Chaque nœud peut aussi contenir un certain nombre d'informations, comme une adresse IP, un type de machine, le nom de la machine en charge du courrier pour ce domaine, etc., c est sont des enregistrements des données DNS. Ces informations sont représentées par un ensemble d'enregistrements associés au nœud de l'arbre (A, HINFO, MX, etc.). Les programmes utilisant le DNS peuvent obtenir les enregistrements d'un certain type pour un nom de domaine donné. Dans l illustration au dessus, des enregistrements des données apparaissent dans le cadre sous le label du nœud rsm, entre autres il y a une adresse IP en IPv4 et aussi une autre en IPv6. Nous allons voir - 9 -

10 dans la partie suivante pour les détails des enregistrements. ENST Bretagne Campus Rennes En utilisant la structure d'arbre, il est possible de définir des domaines de responsabilité dans le nommage. Chaque fléche reliant un nœud à un nœud inférieur peut convoyer une information précisant qui est responsable du niveau inférieur. En des termes plus informatique, le domaine à l'origine de la fléche, le père, contient des informations précisant quels sont les serveurs possédant des informations sur les fils. Délégation est la notion utilisée à cet effet dans le système DNS. À chaque niveau cela peut se répéter, d'ou la création d'une répartition des responsabilités de nommage et de fonctionnement mais elle peut également indiquer qu'il n'y a pas de délégation de responsabilité. Une zone est la partie d'un domaine parcourue sans franchir de fléche, délégant la responsabilité. Ou autrement dit, une zone est la partie de l'arbre gérée par le même serveur (mais le même serveur peut gérer plusieurs zones). Dans le schéma, nous pouvons voir la zone fr et la zone enst-bretagne.fr, ainsi que la délégation entre ces deux zones, qui signifie que la zone enst-bretagne.fr est la zone fille de la zone fr. Le nœud rsm est le fils du nœud enst-bretagne.fr, donc le nom complet du nœud rsm, qui est en fait l un des serveurs de notre école, est rsm.enst-bretage.fr, ou rsm.enst-bretagne.fr. avec le point terminal. Les données de chaque zone sont dupliquées sur plusieurs serveurs. Cette duplication permet d'améliorer la fiabilité du service et de répartir la charge entre les différents serveurs. Aussi, chaque enregistrement contient une durée de validité des informations. Une fois qu'une machine cliente a obtenu une information, l'enregistrement est valide pour le temps donné (TTL). Après cette durée, il faut à nouveau demander cette information. Pendant cette durée, l'information peut être stockée dans un cache. La présence de ce mécanisme de cache dans tous les serveurs de noms ainsi que dans un certain nombre de clients (résolveur) permet de limiter le nombre de requêtes faites, au prix d'une certaine latence dans la mise à jour d'informations quand un changement est effectué. 1.3 Contenu d une zone Nous avons vu que chaque nœud peut aussi contenir un certain nombre d'informations, comme une adresse IP, un type de machine, le nom de la machine en charge du courrier pour ce domaine, etc., c est sont des enregistrements. Ces informations sont représentées par un ensemble d'enregistrements décrits dans des fichiers de configuration de la zone correspondante. Dans ce rapport, des exemples sont tous faites sous FreeBSD 4.8 release en utilisant BIND (version 9.3 Snapshot). Après avoir vu la configuration d une zone, dans des serveurs de nom, c est le fichier named.conf qui contient la configuration du serveur et en particulier la liste des zones sur lesquelles le serveur

11 est autoritaire (primaire ou secondaire). La syntaxe complète de ce fichier dépend de la version de BIND. La documentation et les dernières informations de la version actuelle sont disponibles sur l Internet et il est aussi possible de l obtenir par la commande man named.conf. Toutes les zones sont énumérées dans le fichier de configuration du serveur de noms en précisant si la zone est primaire, secondaire, ou cache. La syntaxe générale est la suivante : <type de la zone><nom de la zone>[source]<fichier> Par exemple : zone "lei.enst.idsa.prd.fr" { type master; file "master/lei.enst.idsa.prd.fr.signed"; ; zone "names.lei.enst.idsa.prd.fr" { type slave; masters { ;; file "slave/names.lei.enst.idsa.prd.fr"; ; [Extrait du fichier /etc/namedb/named.conf, section des zones] Outre la liste des zones, le fichier named.conf contient aussi des options de configuration du serveur, par exemple, les noms de fichiers peuvent être absolus (commençant par un /), ou relatifs, l option directory peut être utilisée pour changer le répertoire courant du programme. Par exemple : options { directory "/etc/namedb"; listen-on-v6 { any; ;... ; [Extrait du fichier /etc/namedb/named.conf, section des options] Les champs sont séparés par des espaces, les tabulations sont plus ou moins bien acceptées suivant les versions. Les lignes vides sont acceptées, des commentaires peuvent figurer par ligne entière commençant par un point-virgule ;. Nous avons vu que dans named.conf, pour chaque zone gérée par ce serveur, un fichier de configuration est spécifié, dans l extrait précédant, la ligne file "master/lei.enst.idsa.prd.fr.signed"; et file "slave/names.lei.enst.idsa.prd.fr"; sont des noms de fichier correspondent à la zone

12 "lei.enst.idsa.prd.fr" et "names.lei.enst.idsa.prd.fr". ENST Bretagne Campus Rennes Chaque fichier de configuration de la zone contient une liste de differents enregistrements liées à la zone, ce sont des Resource Records(RR). Dans le système DNS original, des RR de type adresse IPv4(A), adresse IPv6 (AAAA), alias (CNAME), serveur de noms (NS) et start of authority (SOA) sont définis entre autres. Géneralement un RR a une représentation corresponde à le modèle suivant : Name TTL Class Type Rdata Par exemple: names.lei.enst.idsa.prd.fr 600 IN A xxx.xxx Pour le RR SOA, le format est plus compliqué comme le modèle extrait ci-essous : names.lei.enst.idsa.prd.fr. 60 IN SOA ps2.ipv6.rennes.enst-bretagne.fr.enst.idsa.prd.fr. zhiyu\.lei.enst-bretagne.fr.enst.idsa.prd.fr. ( ; serial 60 ; refresh (60 seconds) 3600 ; retry (1 hour) ; expire (1 week) ; minimum (1 day) ) [Extrait du fichier de zone, section RR SOA] Dans l extrait on peut voir un numéro de série et les périodes de différentes opérations de la zone. Mais ici nous ne spécifions pas plus de détails de la configuration d un fichier de zone, pour des enseignements détaillés et complets, nous vous conseillons de voir [AL01] et [OK02]. Il faut noter que sur la réalisation du DNSSEC (nous allons voir en détails dans la partie II.2 du rapport), dans la version 9.2 ou plus anciennes du BIND, la méthode proposé par RFC2535[R2535] est utilisée donc des RR du type KEY, SIG NXT sont implémentés et dépuis BIND 9.3(snapshot) l approche DS est adoptée

13 1.4 Processus de résolution ENST Bretagne Campus Rennes Le DNS est utilisé par la plupart des services liés à l'internet. Chaque fois que l'un de ces services fait référence à une machine par son nom, la base de données est interrogée (si l'enregistrement recherché n'est pas dans le cache du client). Sur des système UNIX, l'interrogation de la base de données est généralement faite par la librairie C dans la routine gethostbyname(). La librairie en question s'appelle libresolv.a et ses routines sont documentées dans le man resolver(3). Cette routine est utilisée par: Telnet (connexion à d'autres machines) FTP (transfert de fichiers) sendmail (MTA) Browsers WWW (Mozilla, NetScape...) etc... Le but de la librairie est de mettre en forme la requête cliente, de l'envoyer à un (ou plusieurs) serveur(s), et de collecter la réponse. Les clients peuvent être des programmes utilisant le service de noms dans la liste précédente ou d autres outils comme nslookup et dig. Chaque serveur possède une partie de la base de données du DNS, en général une ou plusieurs zones. Si c'est un serveur qui a la version officielle des donnés de la zone et les autres serveurs s'adressent à celui-ci pour les obtenir, on dit alors que ce serveur est autoritaire sur cette zone. Les serveur gardent aussi pendant une certaine période des informations venant d'autre zones en mémoire. C'est la fonction cache. Cela permet de limiter le trafic et de diminuer les temps de réponse en n'ayant pas systématiquement besoin de s'adresser à une des serveurs officiel d'un segment de la base pour obtenir les donnés après les avoir obtenues une première fois. Néanmoins les clients interrogent en général toujours le même serveur, souvent une machine "de service" ayant pour vocation de "faire tourner un DNS". Bien sûr cette machine ne connaît pas toutes les réponses (base de données répartie) et il y a d'autres machines plus appropriées pour répondre à certaines question sur un domaine. Une fois une requête reçue pour un domaine dont le serveur n'est pas autoritaire, deux cas sont possibles: Mode itératif 1 : rsm.enst-bretagne.fr? 2 : fr->ns2 Serveur du nom 1 resolveur 3 : rsm.enst-bretagne.fr? 4 : enst-bretagne.fr->ns3 Serveur du nom 2 fr 5 : rsm.enst-bretagne.fr? Serveur du nom 3 6 : rsm.enst-bretagne.fr IN A [Fig.2 Résolution en mode itératif] enst-bretagne.fr

14 Le serveur renvoie une réponse au client en indiquant qu'il ne connaît pas la réponse, mais qu'il suppose que tel serveur est plus renseigné que lui. Le client va envoyer la requête à un premier serveur puis à un second, peut être à un troisième, etc. Mode récursif 1 :rsm.enst-bretagne.fr? Serveur du nom 1 6: rsm.enst-bretagne.fr IN A resolveur Serveur du nom 2 fr 4 3 Serveur du nom 3 enst-bretagne.fr [Fig.3 Résolution en mode récursif] Le serveur envoie la question à un serveur supposé plus renseigné que lui, attend la réponse et la fait suivre au client. Le client envoie la requête à un serveur, celui-ci la fait suivre à un second serveur, ce dernier l'envoie peut-être à un troisième serveur, etc. Par défaut, un resolveur envoie des requêtes en mode récursif aux serveurs de noms, et des serveurs font des requêtes nécessaires en mode itératif pour y répondre, sauf dans les cas ou l option forwarder est configurée dans named.conf du serveur. [AL01] Dans des resolveurs, c est aussi possible et nécessaire de traiter le cas où des noms sont simples qui ne contiennent pas de points en leur ajoutant un nom de domaine (souvent du réseau local). En effet les autres serveurs DNS ne savent traiter que des requêtes pour des noms complets à partir de la racine. Donc généralement une librairie est créée, elle utilise un fichier de configuration précisant la liste des serveurs à contacter, et le nom de domaine par défaut. Sous UNIX, le fichier /etc/resolv.conf qui contient des informations utiles à résoudre ce problème. domain ipv6.rennes.enst-bretagne.fr nameserver xxx.xx [Extrait du fichier /etc/resolv.conf] Dans tous les cas précédents, nous avons parlé de moyens de trouver l'adresse d'une machine à partir de son nom, en revanche, nous avons aussi le pourvoir de faire l'inverse, c'est à dire ayant une adresse de trouver les noms qui correspondent. Mais dans ce papier nous ne détaillons pas ce processus là

15 2. DNSSEC 2.1 Extension sécurisée Puisque le DNS est la base de ce stage, nous avons fait beaucoup d efforts en expliquant la fonctionnement du DNS dans la partie précédante. Maintenant nous avançons à son extension sécurisée, DNSSEC. Comme décrit précédement, le DNS permet des machines de communiquer au travers de l Internet sans connaître leurs adresses IP respectives, mais la conception originelle de ce service n inclut aucun service sécurisé ayant pour but de protéger les transactions et les données échangées. Et par conséquent, le service DNS demeure très vulnérable aux attaques telles que la création ou modification des messages, la pollution de cache, l usurpation d identité, etc. [GC03, AA03] Dans la figure suivante, les endroits où des attaques sont possibles sont marqués par un point d interrogation. Nous pouvons voir qu il y a des faiblesses situées dans des échanges de message DNS, et aussi des intrusions potentielles dans le fichier de zone ou le cache.?? Serveur DNS 1 Cache? Fichier de zone? Resolveur? Cache Serveur DNS 2 Fichier de zone Cache? [Fig.4 Points faibles du DNS] Par exemple, il est possible d intercepter un message DNS et de le modifier. En effet, il n est pas difficile d analyser le trafic sur le réseau à l écoute d une requête DNS (ce qui est particulièrement aisé sur les réseaux locaux où un support commun est partagé par plusieurs stations). Lorsqu une requête DNS passe, l attaquant la duplique, l analyse et envoie une réponse erronée à cette requête avant que le serveur de noms n ait eu le temps de répondre [GC03]. Ou, on peut fabriquer des réponses erronées directement, si l on a deviné le ID (et autre informations) de la requête suivante

16 successivement. [AA03] ENST Bretagne Campus Rennes De plus, le fonctionnement du cache, qui a pour but d améliorer les performances du DNS, c est-à-dire diminuer les temps de réponse lors d une résolution de noms, se fait une cible particulièrement intéressante pour les attaques appelé pollution de cache (ou cache poisoning), qui sont réalisés par une séries d interceptions et manipulations de message DNS. Ainsi, il est possible d utiliser un serveur DNS corrompu pour faciliter le processus d intrusion dans d autres systèmes, en modifiant le fichier de zone. En brèf, le système DNS est très vulnérable aux attaques, les problèmes de sécurité du DNS portent sur : - la sécurité des transaction de message DNS - la sécurité des données, l intégrité et l authentification - le déni de services Pour combler ce manque de sécurité, le protocole DNSSEC est proposé. DNSSEC apporte deux services de sécurité essentiels au DNS : DNSSEC garantit l intégrité des données et l authentification de la source des données. Afin de les mettre en œuvre efficacement, DNSSEC utilise une cryptographie à clef publique et des signatures numériques. Cette extension utilise de nouveaux enregistrements (RR KEY, SIG, NXT et DS) en supplément au service DNS original pour gérer des clefs et signatures nécessaire à l utilisation d une système de cryptographie à clef publique. Dans DNSSEC, chaque enregistrement est désormais signé (sauf les glues), et cette signature est stockées dans un enregistrement de type SIG spécifique [R2535]. Veuillez bien noter que la sécurisation ici est toujours au sens de la garantit de l intégrité des données et l authentification de la source des données. Ou autrement dit, le service DNSSEC est un service sécurisé et non-confidenciel, des données DNS sont toujours accessibles au public. L utilisation de SIG(0) et TSIG dans DNSSEC sont proposées par d autres chercheurs[r2845, R2931] afin de sécuriser des transaction entre serveurs DNS, mais la défense contre le déni de services n'est pas dans le domaine couvert par DNSsec. DNSSEC permet la sécurisation du DNS en se basant sur deux points : - La sécurisation d une zone - La confiance d une zone à une autre : Chaîne de confiance (Chain of Trust);

17 2.2 Clef et signature DNSSEC utilise une cryptographie à clef publique et des signatures numériques pour garantir l intégrité et l authentification dans le service DNS. Au lieu d expliquer en détails la fonctionnalité de PKI et de signature numérique, nous vous présentons le schéma de signature de vérification utilisé par DNSSEC : Signature : Message Message signé Hache Fonction de hachage Chiffrement avec clef privée Signature Envoi de message Vérification : avec clef publique Hache Dechiffrement avec clef publique Signature Message signé Message Les deux hachages sont-ils identiques? Hache [Fig.5 PKI et signature dans DNSSEC]

18 L idéé principale de cryptographie à clef publique est l utilisation asymétrique de clef publique et clef privée, et en revanche la signature numérique est une fonction de hachage. Le système PKI et signature numérique sont des méthodes matures et efficaces, leur emploiment dans DNSSEC est réalisé par la définition et l utilisation des nouveaux enregistrement : RR KEY et SIG. Dans chaque fichier de zone, nous allons trouver, entres autres, des enregistrements de type KEY pour stocker la partie publique des clefs capables d être utilisé à signer d autres enregistrements, ainsi que des enregistrements SIG contenant la signature de l enregistrement auquel ils font référence, et bien sûr la clef utilisée à la création de ce signature. TTL Type Drapeau Protocole Algorithme Clef publique ID de clef 60 KEY (AQPY2k4P2w/fFq/mARgANC8ypQAYEkgxWhSafulQ6rX tz33kk4vojlgcea7yehsp0k0jc5mxwy/fc8ohcug+q0//) ; key id = SIG KEY ( lei.enst.idsa.prd.fr. Y/0nwlvo77IuGBG62S27vqiatzSoehM3WbCqKFzmp5VV DJQ4epQwMTKdkLOI0pWE3ZgMtWKGb9ySvE/2icXsvg == ) NXT chambre.lei.enst.idsa.prd.fr. NS SOA SIG KEY NXT Data fin de valadité Data début de valadité Algorithme Nom de signataire 60 SIG NXT ( lei.enst.idsa.prd.fr. QjBIFk+yJ9rjoBc+cc81oz/EZ6A8Dig+Ii7V8C5+497r5b2 +RwON/1eIwZyHnPtEQO3uNIYKJ5ORh5zZpS0FjQ== )... Label Field [Fig.6 Extrait du fichier de zone, section clefs et signature] En effet, des enregistrements KEY et SIG font partie de la réponse DNS, à condition que le client qui envoie le requête demande l information DNSSEC en supplémentaire et le serveur a implémenté DNSSEC. De cette manière là, le client qui veut vérifier des données dans la réponse DNS qu il a obtenue d un serveur DNSSEC, il lui faut prendre la partie de signature chiffrée (dans enregistrement SIG), et re-établir la signature originale grâce à la partie publique de la clef qui est aussi inclue dans la réponse, et aussi prendre la partie de données et y faire la fonction de hachage pour créer la signature à nouveau. En comparant la signature original dechiffré de la réponse et la signature

19 qu il construite, il connaîtra l intégrité de l information obtenu. ENST Bretagne Campus Rennes Pour plus d information sur la création des clefs et des signatures, vous trouverez des instructions détaillées dans [OK02], ou des aides fourni dans BIND pour la commande dnssec-keygen et dnssec-signzone. D autre part, il existe un type de RR KEY spécial qui sert à signaler des serveur DNSSEC que cette zone n est pas sécurisé, il s agit une de type NULL. Pour plus d information veuilliez voir l annexe A du rapport. Dans l extrait du fichier précedante, nous avons aussi vu l autre type d enregistrement, NXT. En fait des enregistrement d une zone signée sont triées en ordre alphabétique quand on signe une zone par la commande dnssec-signzone, des RR NXT sont ajoutés automatiquement par BIND afin de répondre à la non-existence d un nom d une manière sûre

20 2.3 Chaîne de confiance (Chain of Trust) ENST Bretagne Campus Rennes Nous avons vu qu au sein d un fichier de zone ou d une réponse DNS, il y a des enregistrements sécurisés via des signatures numériques signé par des clefs privées de la zone. Le point critique devient donc de vérifier que la clef utilisée pour créer ces signatures correspondantes est légale. Pourtant, il existe deux types de clefs : les Key Signing Key (KSK) et les Zone Signing Key (ZSK). Les ZSK sont les clefs qui signent tous les enregistrements de la zone et les KSKs sont les clefs qui signent uniquement le KEY RRset. Mais ici c est le KSK qui fait partie de l architecture hiérarchique de l arbre DNS. Afin de valider une clef KSK, Delegation Signer[OG03] spécifient qu un enregistrement DS valide pour la clef de la zone fille doit être conservé dans la zone parente, et DNSSEC l a implémenté depuis BIND 9.3 Snapshot. Cela implique que quand une zone fille veut changer de KSK, elle doit contacter sa zone parente et lui envoyer son KEY RRset pour la prévenir des changements effectués. La zone parente peut alors créer le DS correspondant ou détruire un DS devenu obsolète. Grâce au DS dans la zone parente, on peut authentifier le KEY RRset du KSK correspondant du côté de la zone fille, et une fois la KSK était vérifié, les vérifications des ZSK et d autres enregistrements vont se faire successivement. 60 DS ( AB45E BFD538C8F656A2C61 349B ) 60 KEY ( AQPtej06bDqsYnS97ez4suIS2xqphkUePL7N nieq0+2kc4yzc3qbshee/dwsajtaiv9vnc/j zffsx0yc8kw6dsx2pqbtax/mgdsjj/puy2ct 79Znos+K7f+AI2LmoTUnyRtGsrKI7bToQDfK V9b3MGvP71B8XoeQ2Rk7s9W2PU89qw== ) ; key id = [Extrait du fichier de zone fille, section DS, et section KSK correspondante] En effef, le RR DS comporte un haché d une clef KSK de sa zone fille, sa création est automatisé dans la processus de la commande dnssec-signzone du côté de serveur de la zone parente, si le Keyset de zone fille est déjà donné. D après [OG03], le haché est calculé par : Hache = hash (FQDN du RR KEY Rdata RR KEY) où Rdata RR KEY = Drapeaux Protocole Algorithme Clef Publique et FQDN = Nom ou alias de la zone déléguée Comme dit toujours, DNSSEC utilise le modèle arborescent du DNS, donc pour valider une clef il