FIABILISATION ET SECURISATION DU DNS

Transcription

1 FIABILISATION ET SECURISATION DU DNS Best Practice Document Document rédigé par le groupe de travail «DNS» animé par le GIP RENATER (CBP R6.1) Auteurs: Jean Benoit (Université de Strasbourg/GIP RENATER) Olivier Prins (CNRS/GIP RENATER) V1 03/12/13

2 GIP RENATER 2013 TERENA All rights reserved. Document No: GN3plus-NA3-T2-R6.1 Version / date: V1 03/12/13 Original language : French Original title: «FIABILISATION ET SECURISATION DU DNS» Original version / date: V1 03/12/13 Contact: RENATER bears responsibility for the content of this document. The work has been carried out by a RENATER led working group on DNS as part of a joint-venture project within the HE sector in France. Parts of the report may be freely copied, unaltered, provided that the original source is acknowledged and copyright preserved. The research leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/ ) under grant agreement n , relating to the project 'Multi-Gigabit European Research and Education Network and Associated Services (GN3plus)'. 2

3 Table of Contents 1 Executive Summary 5 2 Contexte 6 3 Préconisations générales Sensibilité du service par rapport aux dépendances hiérarchiques Isolement des rôles de résolution récursive et de serveur faisant autorité Isolement des zones publiques et des zones privées Plusieurs NS esclaves Hébergement des NS sur des réseaux distincts Hébergement des NS sur des sites géographique distincts Choisir une valeur adaptée pour le TTL Synchroniser les zones privées sur les résolveurs internes Panacher les systèmes d exploitation et les types de serveurs pour augmenter la résilience Virtualisation Séparer l adresse IP du service et l adresse IP de gestion Politique de sécurité et de filtrage des serveurs Chroot et limitation de privilèges Politique de nommage 9 4 Gestion des zones Enregistrement et gestion administrative des zones Choix du TLD Choix du bureau d'enregistrement (registrar) Whois: informations diffusées par les TLDs Création et suivi du domaine Transfert administratif de domaine Architecture des serveurs d autorité Serveur maître furtif ou caché Restriction des transferts de zones par IP et/ou signature TSIG et des mises à jour dynamiques Vues et split-dns Management/Supervision Gestion manuelle des zones Approche dite «industrielle» Ventilation des fichiers de configuration Ventilation des logs Suivi des délégations de zones 16 5 Service de résolution de requêtes DNS : résolveur Rappels sur la résolution récursive et le serveur cache 17 3

4 5.2 Résolveur et esclave non-officiel (stealth) pour les zones locales Fiabilisation du service de résolution DNS Reconfiguration des clients DNS ANYCAST Protocole de redondance (VRRP, Heart-beat,...) Problématique des résolveurs ouverts Résolveur et zones privées Activation de la validation DNSSEC sur le résolveur 22 6 DNSSEC Risques Risques d expiration Risque de compromission des clefs Risque d inaccessibilité de la zone Mise en oeuvre de DNSSEC Rotation des clefs 24 7 Messagerie : dépendance au DNS Eviter le «phishing» Publier les serveurs SMTP ayant autorité Signer un domaine de messagerie Utiliser des résolveurs locaux sur les serveurs SMTP 25 8 Synthèse des recommandations 26 9 Annexes Description des différents TTLs Le TTL par défaut de la zone Les TTL de l enregistrement SOA Réinitialisation du serial number par "overflow" (RFC1982) Contrôler la compatibilité EDNS du résolveur (RFC2671) Délais de timeout lors de la résolution par Bind Références Erreur! Signet non défini. 11 Glossaire Erreur! Signet non défini. 4

5 1 Executive Summary Le service DNS (pour Domain Name System) est un composant primordial d une architecture informatique. Lors des échanges inter-machines, la quasi-totalité des processus font en effet référence non pas directement à des adresses IP mais à des noms. Si la traduction des noms en adresses IP faite par le DNS venait à ne plus être assurée, tous ces services deviendraient inopérants. Il en est de même pour les autres informations que diffuse le DNS, notamment la résolution inverse, les relais des zones de messagerie ainsi qu un nombre croissant d autres informations fonctionnelles (via les champs de type TXT ou SRV). De plus, le DNS est appelé à devenir un référentiel d autorité incontournable grâce au déploiement de DNSSEC qui assure l intégrité de la source. Par exemple, la diffusion de certificats HTTPS via DANE (enregistrement TLSA) de manière autonome, contrairement aux certificats X509 qui nécessitent l intervention de tiers comme les autorités de certification. Sa criticité et son extension à de nouvelles fonctions sensibles font du DNS une cible de choix pour les attaques. Sa fiabilisation et sa sécurisation doivent être assurées rigoureusement. Ce document se veut un guide de bonnes pratiques afin d augmenter la résilience de votre service DNS. 5

6 2 Contexte La première section de ce document reviendra sur les notions de base du DNS qu il est nécessaire de maîtriser. Nous utiliserons les termes suivants : «NS» (Name Server) pour serveur DNS. «NS maître» pour serveur de nom primaire. «NS esclave» pour serveur de nom secondaire. 6

7 3 Préconisations générales 3.1 Sensibilité du service par rapport aux dépendances hiérarchiques Il faut garder à l esprit que l architecture DNS repose sur une arborescence hiérarchique stricte. Toute défaillance d un nœud père remet en cause la résolution d une zone fille. Dans le cas de zone de 1 er niveau ce n est pas problématique car les serveurs de nom pour la racine et pour les Top Level Domains (com, net, org, fr) s appuient sur des architectures fortement redondantes à l échelon international et sont en général très fiables. Pour les niveaux sous-jacents, il faudra s assurer que la zone parente à laquelle on se rattache propose un niveau de résilience élevé. 3.2 Isolement des rôles de résolution récursive et de serveur faisant autorité Il est fortement conseillé de compartimenter sur des plateformes matérielles distinctes les rôles de serveur faisant autorité et de serveur de résolution récursive. 3.3 Isolement des zones publiques et des zones privées De la même manière, il faut compartimenter les serveurs faisant autorité pour les zones publiques et les serveurs faisant autorité pour les zones privées. En effet, ces périmètres ont des finalités bien distinctes et des besoins de sécurité opposés : les zones publiques sont destinées à être visibles sur tout l Internet pour que les services qui en dépendent (serveur web, messagerie etc.) soient accessibles ; les zones privées contiennent des adresses internes qui intéressent uniquement les clients internes. Faire une séparation entre les données des zones publiques et celle des zones privées, et isoler au niveau réseau l accès à ces zones privées garantit la non-divulgation d informations vers l extérieur : architecture du réseau interne, plans d adressage, noms des serveurs, etc. Bien évidemment, la sécurité par l obscurité qui en découle ne constitue pas une mesure suffisante pour protéger le réseau interne. Cependant, en complément de la mesure principale qu est le filtrage à la périphérie du réseau par un pare-feu, elle contribue superficiellement à la protection du réseau interne. 3.4 Plusieurs NS esclaves Afin d assurer la continuité de service en cas de défaillance du NS maître il est indispensable de prévoir des NS esclaves afin de répartir le service sur plusieurs NS. La bonne pratique recommande d avoir au moins 3 NS (un maître et deux esclaves). Il est recommandé de mettre en place des serveurs secondaires, à la fois sur des réseaux IP distincts et sur des sites distincts, pour augmenter la résilience. Il est d usage de demander l hébergement d un serveur esclave à un partenaire, en proposant, en échange de bons procédés, d héberger le serveur esclave du partenaire. Des communautés peuvent formaliser un agrément d hébergement de serveurs esclaves. Il est très important de prévoir des canaux de communications entre les gestionnaires du serveur maître et ceux du serveur esclave. Il faut être très attentif aux risques que présentent des serveurs esclaves qui ne font plus autorité. Il peut arriver que le gestionnaire du serveur maître supprime l esclave dans sa liste des esclaves à notifier en cas de modification ou dans la liste des serveurs autorisés à transférer les zones. Dans ce cas, le serveur esclave risque de continuer à servir pendant quelque temps des données périmées. Les gestionnaires du serveur maître doivent absolument avertir de tout changement. 7

8 3.5 Hébergement des NS sur des réseaux distincts Afin d améliorer la résilience en cas de défaillance d un des NS ou d une attaque de type DOS par exemple, il est indispensable d héberger les NS sur des réseaux distincts. Cela permet d améliorer les capacités d interconnexion (attaque DOS) et d apporter une redondance en cas de défaillance d un de ces réseaux. 3.6 Hébergement des NS sur des sites géographique distincts. La répartition sur des réseaux distincts si elle est importante n est pas un élément suffisant, il convient également que les NS soient dispersés sur des infrastructures physiques et des sites géographiques distincts. 3.7 Choisir une valeur adaptée pour le TTL La durée de validité (Time To Live ou TTL) des enregistrements de la zone est fixée en fonction des paramètres suivants : le niveau de redondance de l architecture DNS : le TTL doit être supérieur à la durée estimée d une interruption du service DNS ; la charge : plus le TTL est faible, plus le DNS sera interrogé fréquemment (ce problème se pose surtout pour des services très visités) ; la réactivité lors d une modification de la zone : le TTL doit être inférieur à la durée souhaitée d expiration des enregistrements dans les caches des résolveurs. Exemple : le serveur web change d adresse IP ; si le TTL est à 24h, l ancienne adresse IP doit continuer à fonctionner pendant une journée avant qu on puisse la supprimer ; les risques d empoisonnement de cache : plus le TTL est élevé, plus les risques d empoisonnement du cache sont faibles. Les valeurs les plus communes du TTL sont entre 3600 et secondes. Il faut être vigilant aux effets du cache négatif lié au TTL. En effet, les résolveurs gardent en cache nonseulement les enregistrements trouvés, mais également les réponses indiquant qu'un enregistrement n existe pas, et cela pour une durée de plusieurs minutes à plusieurs heures. Par exemple, si lors de la modification d'un enregistrement, il y a un intervalle de temps pendant lequel l'enregistrement n'existe pas (entre le moment de la suppression et le moment de la recréation) le risque existe qu'un résolveur mette en cache la réponse négative. 3.8 Synchroniser les zones privées sur les résolveurs internes Afin d éviter les latences de mise à jour des zones liées au TTL, il est conseillé de déclarer ses zones en esclaves sur les résolveurs internes. Ces zones esclaves ne seront pas publiées publiquement. Elles ne servent que de cache bénéficiant d une notification active de la part du NS maître (clause «notify-also» sous Bind). Ce point est détaillé dans le paragraphe Panacher les systèmes d exploitation et les types de serveurs pour augmenter la résilience Utiliser différents systèmes d exploitation ou distribution (Debian Linux, RedHat Linux, OpenBSD ou FreeBSD par exemple) et différents serveurs DNS (ISC Bind ou NSD par exemple) permet de limiter les risques d attaques en s appuyant sur des ressources hétérogènes qui n ont pas des faiblesses exploitables simultanément. 8

9 3.10 Virtualisation L hébergement des NS sur une infrastructure virtualisée ne présente pas de contre-indications. Pour éviter le risque de dépendance circulaire, il faut néanmoins s assurer que la plateforme de virtualisation (l hôte) ne s appuie pas sur des ressources DNS publiées par la machine virtuelle (pour des réseaux privés notamment). Il est conseillé de préserver au moins un NS physique, qu il soit maître ou esclave Séparer l adresse IP du service et l adresse IP de gestion Le NS doit disposer d une adresse IP dédiée pour la gestion (accès SSH, supervision, contrôle à distance du serveur de nom etc.) et d une autre adresse IP consacrée au service DNS, sur une autre interface physique ou virtuelle (éventuellement sur une interface loopback). Cela permet de séparer l administration du serveur et l accès au service, et elle autorise différentes technique de redondance (VRRP, Anycast etc.) Politique de sécurité et de filtrage des serveurs Seul le port 53 en TCP et en UDP doit être accessible de l Internet pour un serveur public. Aucun autre service ne devrait tourner sur les serveurs en dehors du DNS. Il faut maintenir à jour le logiciel de serveur de nom, appliquer les correctifs de sécurité et limiter l'accès à ce serveur Chroot et limitation de privilèges Il est recommandé de chrooter le service DNS dans une arborescence dédiée afin de limiter la portée d une exploitation de faille de sécurité. De plus, le serveur ne doit pas tourner sous un utilisateur ayant les droits d administration ( root ou Administrateur ). Pour limiter ses privilèges, il faut le faire tourner sous l identité d un utilisateur avec un minimum de privilèges créés spécifiquement pour cela ( named par exemple). Exemple pour bind ; démarrage du processus sous l utilisateur named dans le répertoire chroot /var/named : /usr/sbin/named -u named -t /var/named Pour plus d information, consulter le chapitre 7 (Bind Security consideration) du [Bind Operation Guide] Politique de nommage Les données servies par les DNS sont publiques par nature. Il faut veiller à ne pas y mettre des données sensibles ou qui pourraient faciliter des attaques. De plus, il est recommandé de définir et d'appliquer une politique de nommage. 9

10 4 Gestion des zones 4.1 Enregistrement et gestion administrative des zones Choix du TLD Du fait du fonctionnement hiérarchique du DNS, le choix de l'extension d'un domaine n'est pas neutre. En effet le niveau de fiabilité des TLDs n'est pas homogène. Mieux vaut éviter les extensions "exotiques" Choix du bureau d'enregistrement (registrar) La qualité de service des différents bureaux d'enregistrement est très hétérogène. Il faut veiller à la qualité, à la souplesse et à la réactivité des procédures de mise à jour (l'idéal étant une interface de management en ligne avec une API). En effet, pour une zone de premier niveau, toute mise à jour de NS nécessitera une demande auprès du bureau d'enregistrement afin qu'il modifie la délégation de zone auprès du TLD Whois: informations diffusées par les TLDs Les TLDs diffusent via le service Whois des informations administratives et techniques sur les zones DNS, notamment le propriétaire et les contacts techniques ainsi que la liste des NS. Ces informations sont purement indicatives. Les NS indiqués peuvent ne pas correspondre aux NS ayant effectivement délégation. Cela n a pas d'incidence pratique. Néanmoins il est souhaitable que les données Whois soient maintenues à jour via le bureau d enregistrement Création et suivi du domaine Pour limiter les risques de cybersquating, il est conseillé d enregistrer des déclinaisons du nom (exemple : mondomaine.fr, mon-domaine.fr, etc.) et sous différents TLDs (exemple : mondomaine.fr, mondomaine.net, mondomaine.org etc.) Lors de la création, il faut vérifier que les enregistrements de la zone sont corrects avec un outil comme ZoneCheck. Il faut consulter régulièrement les informations concernant le domaine grâce à Whois, et veiller à renouveler le contrat pour éviter l'expiration du domaine. Autant que possible, il est recommandé d automatiser la surveillance et/ou le renouvellement. 10

11 4.1.5 Transfert administratif de domaine Lors de l'enregistrement d'un domaine, il faut bien s'assurer d'être bien déclaré comme propriétaire administratif du domaine, notamment lorsque l'on passe par un prestataire de service. Car le cas échéant, seul le propriétaire pourra initier la session ou la migration du domaine. Il faut également prendre soin de définir une personne morale comme propriétaire et non une personne physique qui risque de partir vers de nouveaux horizons. 4.2 Architecture des serveurs d autorité Le serveur maître est particulièrement sensible. S il est compromis et si les zones sur lesquelles il fait autorité sont modifiées, au bout d un certain temps, tous les serveurs esclaves et les serveurs cache finiront par récupérer les informations modifiées. De même, tous les clients qui font une résolution auront les informations modifiées. Ces informations modifiées le resteront jusqu à la correction de la zone et après expiration du TTL associé. Il faut sécuriser le serveur tel que décrit dans le paragraphe Serveur maître furtif ou caché Il est possible d isoler le serveur maître dans une architecture dite stealth master DNS ou hidden master DNS : le serveur maître sur lequel les zones sont modifiées n est jamais accessible ni visible de l extérieur. Le serveur maître officiel, dont le nom est mentionné dans le SOA, est en réalité un serveur esclave qui synchronise ses zones sur le serveur maître caché. Chaque fois qu une zone est modifiée sur le maître caché, les esclaves sont notifiés. 11

12 De plus, il est préconisé de mettre en place plusieurs serveurs esclaves. Comme indiqué plus haut, deux serveurs esclaves représentent le minimum recommandé. Il est tout à fait possible de mettre en place trois serveurs esclaves ou plus, de préférence sur des sites et des réseaux distincts, afin de distribuer la charge. Ainsi, en cas de dysfonctionnements réseau ou serveur, accidentels ou liés à une attaque, les autres serveurs esclaves sont toujours disponibles pour répondre aux requêtes extérieures. Il faut veiller à ne pas mettre trop de serveurs car la réponse à la requête DNS concernant les serveurs de nom doit idéalement rester en dessous des 512 octets en UDP (certaines implémentations de firewall filtrant les extensions DNS EDNS0) [RFC1035, & RFC2671] Restriction des transferts de zones par IP et/ou signature TSIG et des mises à jour dynamiques Pour que les mises à jour de zones soient le plus rapide possible entre le maître et les esclaves, il est recommandé d'activer la notification. Exemple pour Bind : notify yes; Le comportement par défaut de Bind est de notifier tous les serveurs indiqués sous les enregistrements de type NS dans le fichier de zone. Un NS maître ne doit autoriser les transferts de zones (AXFR ou IXFR) qu'à ses seuls NS esclaves (directive "allow-transfer sous Bind). Il est important de restreindre les transferts de zone sur tous les serveurs, aussi bien les serveurs maîtres que les serveurs esclaves. Exemple (bind) : options { allow-transfer { } } Afin de contrôler l'identité des NS lors des transferts de zones, il est conseillé de mettre en place une signature symétrique TSIG (Transaction SIGnature) [RFC2845]. Cela nécessite de mettre en place une clef sur le serveur maître et sur les serveurs esclaves et de configurer les serveurs pour signer les transferts de zone avec cette clef. Attention: il est impératif de synchroniser les horloges systèmes de tous les serveurs de noms, par exemple avec le protocole NTP. De plus, il faut interdire les mises à jour dynamiques. Normalement, elles sont interdites par défaut dans Bind. Il faut veiller à ne pas avoir de directives qui les autorisent dans la configuration. Autoriser une adresse IP à faire des mises à jour dynamiques est extrêmement dangereux. Si cette fonctionnalité est vraiment nécessaire, il faut utiliser TSIG pour authentifier les mises à jour dynamiques. Example de configuration TSIG dans le fichier named.conf de Bind : key "tsig_001." { algorithm "hmac-md5"; secret "IaPUtN3x+xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx...xxxxxS4g=="; }; server { keys { tsig_001.; }; }; server 2001:DB8::ABCD:ABCD:1 { keys { tsig_001.; }; }; 12

13 4.2.3 Vues et split-dns La mise en place du principe de séparation des zones publiques et privée se fait soit en utilisant les vues, soit via une architecture scindée en deux dite Split DNS Il est possible de créer plusieurs vues à destination des clients différents. En fonction de son adresse IP, chaque client verra d autres enregistrements. Par exemple, pour la zone example.com, les clients internes verront l ensemble des postes, des imprimantes et des serveurs internes déclarés dans la vue interne, et les clients externes ne verront que le serveur web et le relais de messagerie publics. Exemple dans Bind : view internal { match-clients { /24; }; # uniquement les adresses internes zone example.com { type master; file internal/example.com ; # contient l ensemble des enregistrements } } view external { match-clients { any; }; zone example.com { type master; file external/example.com ; # ne contient que www et mail } } L'utilisation des vues présente des risques opérationnels. Dans la mesure où, en fonction de son adresse IP source, on ne reçoit pas la même réponse, cela peut introduire des problèmes qui n'existent pas dans le fonctionnement normal du DNS et peut compliquer le débogage. Il est recommandé de bien mettre en perspective le risque et le gain de sécurité avant de choisir d'implémenter les vues DNS. 4.3 Management/Supervision Il existe deux approches pour gérer le contenu des zones Gestion manuelle des zones La gestion manuelle des fichiers de configuration est conseillée pour les zones ayant peu d entrées et/ou peu de mise à jour. C est également envisageable pour les zones plus complexes si l on adopte une grande rigueur dans le formatage des fichiers, en l occurrence: Mise à jour systématique du cartouche ; Classement par ordre alphabétique stricte : Dans le cas d entrées multi-niveaux classer sur le niveau parent ; Contrôle syntaxique via un outillage (sous Bind le rechargement d un fichier erroné ne génère pas d erreur) => voir script d exemple en annexe : named-checkconf pour les fichiers de configuration ; named-checkzone pour les fichiers de zones ; Vérifier que la valeur du champ Serial est bien incrémentée (ou incrémenter la valeur par programme) Exemple sous Bind : 13

14 ; DEBUT DE FICHIER ; Zone example.fr ; ; pdupond : update "web" from to ; pdupond : create zone ; ; TTL par defaut $TTL 3600 ; RACINE $ORIGIN example.com. ; Serveur maitre Mail contact technique ; IN SOA ns1.example.com. dnsmaster.example.com. ( ; Version ; Refresh (6h) 3600 ; Retry (1h) ; Expire (1000h) 3600 ; Negative caching TTL (1h) ) ; Serveurs maitre et esclave(s) IN NS ns1.example.com. IN NS ns2.example.com. IN NS ns3.example.com. ; Messagerie IN MX 0 smtp1.example.com. IN MX 0 smtp2.example.com. IN TXT "v=spf1 mx mx:smtprelay.example.com ~all" ; Microsoft Office 365 IN TXT "MS=ms " ; COLLE ; Les adresses des NS sous example.com ; ns1 IN A IN AAAA 2001:DB8:1234:1234:1234:1 ns2 IN A IN AAAA 2001:DB8:ABCD:ABCD:ABCD:1 ns3 IN A IN AAAA 2001:DB8:CDEF:CDEF:CDEF:1 ns1.succursale IN A ns2.succursale IN A ns3.succursale IN A ; ; DECLARATION DES ENTREES ; ; Ordre alphabetique sur le 1er niveau (ex: xxx.yyy est trie sur yyy). ; Les zones deleguees sont mixees avec les non deleguees. ; On ne tient pas compte de l'eventuel " ; Separateur: tabulation (sauf entre MX et son poids: utiliser un espace). ; abc IN CNAME web ; <pierre.dupond@succursale.example.com> succursale IN NS ns1.succursale IN NS ns2.succursale IN NS ns3.succursale test IN CNAME web IN CNAME web list.test IN CNAME web IN CNAME web intranet.test IN CNAME web IN CNAME web web IN A ; FIN DE FICHIER

15 4.3.2 Approche dite «industrielle» À l inverse, il est possible de gérer l ensemble des informations du DNS dans une base externe au serveur de nom. Il existe des outils libres ou commerciaux, les IPAM (IP Address Management), permettant de maintenir un référentiel des données du DNS : noms de domaines, noms des machines, sous-réseaux, adresses IP etc. Ces outils offrent plusieurs avantages : cohérence des données. Par exemple, les enregistrements de type A, associant une adresse à un nom auront toujours un enregistrement inverse, de type PTR correspondant ; gestion intégrée d autres services d infrastructure : DHCP, routage de messagerie etc ; possibilité de déléguer l administration : il est possible de donner des droits fins à d autres administrateurs via une interface web ; découplage des données et du serveur de nom : il est possible de changer la façon de stocker les enregistrements sans dépendre du format des fichiers de zone d ISC BIND. Aussi, la migration vers un autre serveur de nom dépend simplement de la modification du processus de génération des zones à partir de la base de données ; automatisation de certaines tâches. Par exemple, l import et l export dans d autres formats, la déclaration ou le renommage en masse ; application systématique de politiques. Par exemple, il est possible de vérifier à la saisie si les noms entrés se conforment à un schéma de nommage défini (pour les postes de travail, pour les interfaces de routeurs etc.) Ces outils présentent également un certain nombre de risques : une plus grand complexité, et donc des difficultés de débogage, en raison des dépendances entre les différents éléments : outils de génération, interface web, authentification des utilisateurs, base de données etc ; s il existe une faille de sécurité dans l outil, que ce soit dans l interface web, l authentification, la génération, il est possible de modifier les zones. Il est recommandé de sécuriser l outil de gestion des zones avec des mesures telles que le filtrage au niveau réseau du serveur et du contrôle d accès Ventilation des fichiers de configuration Lorsqu un grand nombre de zones sont hébergés, il est conseillé d éclater la configuration dans différents fichiers qui seront incorporés par des «include» dans le fichier principal (named.conf sous Bind). Cela offre une meilleure visibilité et facilite la maintenance. Exemple pour Bind sous /var/named/chroot/etc : named.conf options.conf controls.conf logging.conf masters.conf masters_reverse.conf slaves.conf slaves_reverse.conf forwards.conf 15

16 4.3.4 Ventilation des logs Par défaut l ensemble des logs sont stockés dans un fichier unique. Il est conseillé de les ventiler par type via la section «logging» sous Bind par exemple. Exemple pour Bind : /var/log/queries/queries.log Requêtes clientes /var/log/lamers.log Erreurs serveurs DNS distants /var/log/xfer-out.log Transferts de zones sortant /var/log/xfer-in.log Transferts de zones entrant /var/log/client.log Erreurs lors émission réponse /var/log/default.log Autres messages Il peut être judicieux d exploiter ces logs pour réaliser des statistiques afin de détecter d éventuelles dérives. Par exemple la commande suivante fournit le palmarès des IP des 10 plus gros requêteurs : cat /var/named/chroot/var/log/queries/queries.log* cut -d" " -f6 cut -d"#" -f1 sort uniq -c sort -nr head -10 Des utilitaires tiers comme dnstop ou dnsperf offrent des tableaux de bord complets. Il est recommandé de centraliser les logs sur un serveur de log dédié. [ajouter configuration syslog bind en exemple] Suivi des délégations de zones La délégation de zone est à réaliser avec prudence car une fois un sous-domaine délégué celui-ci échappe totalement au domaine père. Il est ainsi fréquent qu un sous-domaine soit abandonné sans que l administrateur du domaine père en soit averti. Pour garder un œil sur les zones déléguées, il est intéressant de mettre en place un outillage qui réalisera périodiquement un ensemble de contrôle : connectivité DNS aux NS, transfert de zone si l on est esclave, etc => voir exemple de script en annexe. 16

17 5 Service de résolution de requêtes DNS : résolveur 5.1 Rappels sur la résolution récursive et le serveur cache Un serveur DNS assurant la fonction de résolution DNS pour des clients est parfois abusivement appelé serveur récursif. Cela tient au fait que ce serveur va effectuer toutes les requêtes nécessaires pour obtenir la réponse et ceci de manière récursive avant de renvoyer l'information au demandeur. Par opposition, on parlera de serveur itératif lorsqu'un serveur de noms qui ne possède pas l'information n'effectue pas de recherche mais renvoie comme réponse que l'information est détenue par un autre serveur. Le choix de ces modes de configuration a de fortes implications. De manière générale, les serveurs DNS faisant autorité sur une zone doivent être configurés en mode itératif et les serveurs DNS assurant un service de résolution de requêtes DNS doivent être configurés en mode récursif. De même un résolveur est également parfois appelé abusivement serveur cache. Cela tient au fait que le serveur de noms va également avoir une fonctionnalité appelée cache qui va stocker les informations qu il a recueillies tant que celles-ci ne sont pas périmées. Ceci est fait pour améliorer le temps de réponse aux requêtes mais également pour éviter de surcharger les serveurs de noms de requêtes identiques. 17

18 5.2 Résolveur et esclave non-officiel (stealth) pour les zones locales Pour un résolveur, la fonction de cache peut entraîner une certaine latence dans les mises à jour des données, ce qui pose des problèmes pour les zones locales. En effet, il se peut que peu de temps après une requête DNS, l enregistrement DNS qui a été sollicité soit modifié. Or cet enregistrement restera stocké dans le cache tant que sa durée de validité ne sera pas atteinte (TTL). Pour pallier ce problème, il est parfois utile de déclarer le résolveur comme esclave des zones sans pour autant que le résolveur soit un esclave officiel et visible dans le SOA de la zone. On parle alors de serveur caché qui va être notifié par les serveurs faisant autorités lors d une modification sur la zone DNS concernée. La configuration de cette notification se fait via l option alsonotify sous ISC BIND. 5.3 Fiabilisation du service de résolution DNS Historiquement, la fiabilisation de cette fonction est assurée par le fait d'avoir plusieurs serveurs DNS qui puissent être interrogés par le client. Pour les systèmes unix, la liste des serveurs DNS interrogeables est spécifiée dans le fichier /etc/resolv.conf dont voici un exemple : search example.com nameserver nameserver nameserver De cette façon, si le premier serveur DNS a une défaillance, le client interroge le serveur DNS suivant et ainsi de suite. Toutefois, cette solution n est pas forcément la plus efficace : elle est dépendante de l'algorithme utilisé par le système d exploitation. Ce qui est généralement constaté sur les systèmes unix (linux, freebsd,...), c est que par défaut toute requête va d'abord interroger le premier serveur DNS et si ce dernier ne répond pas ce n'est qu'au bout que de 5 secondes que le client va interroger le serveur DNS suivant et ainsi de suite. Il est toutefois possible de modifier ce délai via l option timeout. Ce principe qui a l intérêt d être simple et généralement disponible sur tous les systèmes n est cependant pas satisfaisant car il entraîne des latences perceptibles par l'utilisateur dès que le premier serveur DNS est défaillant. Nous allons donc aborder, sans être exhaustif, 3 méthodes pour limiter voire rendre invisible l impact de la défaillance d un serveur DNS : 1. Reconfiguration de la liste des serveurs DNS 2. DNS ANYCAST 3. Redondance du service de résolution de nom DNS par un protocole de redondance spécifique (VRRP, Heartbeat etc.) 18

19 5.3.1 Reconfiguration des clients Une solution simple serait de supprimer le résolveur défaillant de la liste des serveurs DNS que doit interroger le client. Concrètement, sur un système unix, il s agit de supprimer l entrée associée au serveur DNS défaillant dans le fichier /etc/resolv.conf. Toutefois, si cette solution simple peut être envisageable pour un poste client, elle est difficilement applicable pour un parc comportant plusieurs centaines voire milliers de machines. Un moyen d automatiser la diffusion de cette reconfiguration de la liste des résolveurs est d utiliser un service DHCP (et notamment l option domain-name-servers pour la déclaration des serveurs DNS) pour la configuration IP des machines. Le principe serait alors de mettre à jour la liste des serveurs DNS interrogeables dès qu'un résolveur serait détecté comme défaillant. Ceci suppose toutefois de disposer d'un bail DHCP court pour que cette reconfiguration soit effectuée le plus rapidement possible sur les postes. Exemple de configuration de l option domain-name-servers sous ISC DHCP : option domain-name-servers , , ; DNS ANYCAST L architecture DNS anycast est intéressante dans le cas où l infrastructure est répartie sur plusieurs sites, de préférence éloignés l un de l autre. Les serveurs DNS devront être routés sur des routeurs différents. L architecture anycast apporte une redondance du service et une répartition de la charge ; elle permet de résister aux attaques de déni de service. L anycast assure une répartition des requêtes sur plusieurs serveurs DNS en agissant au niveau de la couche réseau. Son fonctionnement s appuie sur les principes suivants : une même adresse ip (l adresse du service dns) est configurée sur plusieurs serveurs DNS différents (sur une interface loopback) localisés chacun sur un site distinct. un démon de routage (QUAGGA, BIRD etc.) implémentant un protocole de routage (OSPF, BGP etc.) tourne sur le serveur DNS en plus du serveur de nom, une annonce de l adresse du service DNS est envoyée au routeur par le démon de routage le routeur apprend l adresse IP du serveur. La décision de routage garantit que les paquets à destination du DNS sont transmis au serveur le plus proche. Le mécanisme de redondance est simple : si le DNS ou le réseau ne fonctionne plus, l annonce de l adresse IP n est plus envoyée au routeur. Pour que cela fonctionne, il est impératif de coupler l état de fonctionnement du serveur DNS et l annonce de la route au routeur. Cela est souvent réalisé avec un simple script : le script tourne sur le serveur DNS il effectue régulièrement une requête locale auprès du service DNS si le service DNS ne fonctionne plus (si le process Bind ne tourne plus par exemple), le script stoppe le démon de routage pour cesser d annoncer l adresse. à l inverse quand le DNS fonctionne à nouveau, le script peut relancer le démon de routage. Il faut noter que le temps de convergence est souvent de plusieurs secondes, car l ajout et la suppression de la route doit se diffuser entre les routeurs. Il existe un grand choix de démons de routage à déployer sur le serveur DNS : Quagga, Bird, openbgpd, openospfd etc. Le protocole de routage est également un choix ouvert en fonction des possibilités des routeurs : BGP nécessite un peu plus de configuration notamment la mise en place de peering, mais il permet de fonctionner au-delà des frontières d un domaine de routage (AS) OSPF est légèrement plus simple à configurer mais est limité au domaine de routage 19

20 L anycast fonctionne bien car le protocole DNS est sans état : en UDP, une requête donne lieu à une réponse. Dans certains cas, le DNS utilise TCP. L anycast fonctionne également en TCP à condition que la route ne change pas durant la connexion TCP. Il est possible d avoir plusieurs serveurs qui s annoncent sur le même serveur mais cette architecture n est pas recommandée. S il existe plusieurs routes de poids équivalent vers différents serveurs DNS, la répartition de charge effectuée par le routeur doit toujours envoyer les paquets de la même connexion TCP vers le même serveur. Ceci est souvent le cas si le routeur route par flux ou si l algorithme de répartition de charge s appuie sur une fonction de hachage prenant l adresse IP source et/ou les ports source et destination Protocole de redondance (VRRP, Heart-beat,...) Il existe une autre approche en matière d architecture redondante. Sans s appuyer sur des protocoles de routage, il est possible d utiliser un mécanisme de redondance directement sur le serveur, comme VRRP ou heart-beat : soit entre des serveurs de noms redondants, soit entre des load-balancers frontaux redondants. Grace à VRRP, un serveur principal est élu et tous les autres serveurs sont en backup. Le mécanisme d élection est basé sur des annonces régulières effectuées par le serveur principal, doté d une priorité plus grande que les serveurs de backup. Il existe plusieurs implémentations pour les unix libres : CARP, ucarp, VRRPd, heartbeat, corosync etc. Comme pour l anycast où redondance est liée à des protocoles de routage, il faut coupler le mécanisme de redondance et l état du service Problématique des résolveurs ouverts Un résolveur ouvert à tout l Internet présente des risques importants: d empoisonnement du cache, d être victime d une attaque de déni de service (DOS) ciblée sur le résolveur (impactant l ensemble des utilisateurs internes), de servir de vecteur indirect dans une attaque de déni de service distribuée (DDOS) : attaque DNS par amplification en usurpant l adresse IP source. 20