FIABILISATION ET SECURISATION DU DNS - Best Practice Document
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
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 ‐ jean@unistra.fr (Université de Strasbourg/GIP RENATER)
Olivier Prins ‐ olivier.prins@dsi.cnrs.fr (CNRS/GIP RENATER)
V1 – 03/12/13
© GIP RENATER 2013 © TERENA 2010. 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: cbp @listes.renater.fr 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/2007-2013) under grant agreement n° 605243, relating to the project 'Multi-Gigabit European Research and Education Network and Associated Services (GN3plus)'. 2
Table of Contents
1 Executive Summary 5
2 Contexte 6
3 Préconisations générales 7
3.1 Sensibilité du service par rapport aux dépendances hiérarchiques 7
3.2 Isolement des rôles de résolution récursive et de serveur faisant autorité 7
3.3 Isolement des zones publiques et des zones privées 7
3.4 Plusieurs NS esclaves 7
3.5 Hébergement des NS sur des réseaux distincts 8
3.6 Hébergement des NS sur des sites géographique distincts. 8
3.7 Choisir une valeur adaptée pour le TTL 8
3.8 Synchroniser les zones privées sur les résolveurs internes 8
3.9 Panacher les systèmes d’exploitation et les types de serveurs pour augmenter la
résilience 8
3.10 Virtualisation 9
3.11 Séparer l’adresse IP du service et l’adresse IP de gestion 9
3.12 Politique de sécurité et de filtrage des serveurs 9
3.13 Chroot et limitation de privilèges 9
3.14 Politique de nommage 9
4 Gestion des zones 10
4.1 Enregistrement et gestion administrative des zones 10
4.1.1 Choix du TLD 10
4.1.2 Choix du bureau d'enregistrement (registrar) 10
4.1.3 Whois: informations diffusées par les TLDs 10
4.1.4 Création et suivi du domaine 10
4.1.5 Transfert administratif de domaine 11
4.2 Architecture des serveurs d’autorité 11
4.2.1 Serveur maître “furtif” ou “caché” 11
4.2.2 Restriction des transferts de zones par IP et/ou signature TSIG et des
mises à jour dynamiques 12
4.2.3 Vues et split-DNS 13
4.3 Management/Supervision 13
4.3.1 Gestion manuelle des zones 13
4.3.2 Approche dite «industrielle» 15
4.3.3 Ventilation des fichiers de configuration 15
4.3.4 Ventilation des logs 16
4.3.5 Suivi des délégations de zones 16
5 Service de résolution de requêtes DNS : résolveur 17
5.1 Rappels sur la résolution récursive et le serveur cache 17
35.2 Résolveur et esclave non-officiel (stealth) pour les zones locales 18
5.3 Fiabilisation du service de résolution DNS 18
5.3.1 Reconfiguration des clients 19
5.3.2 DNS ANYCAST 19
5.3.3 Protocole de redondance (VRRP, Heart-beat, ....) 20
5.3.4 Problématique des résolveurs ouverts 20
5.4 Résolveur et zones privées 22
5.5 Activation de la validation DNSSEC sur le résolveur 22
6 DNSSEC 23
6.1 Risques 23
6.1.1 Risques d’expiration 23
6.1.2 Risque de compromission des clefs 23
6.1.3 Risque d’inaccessibilité de la zone 23
6.2 Mise en oeuvre de DNSSEC 23
6.3 Rotation des clefs 24
7 Messagerie : dépendance au DNS 25
7.1 Eviter le « phishing » 25
7.2 Publier les serveurs SMTP ayant autorité 25
7.3 Signer un domaine de messagerie 25
7.4 Utiliser des résolveurs locaux sur les serveurs SMTP 25
8 Synthèse des recommandations 26
9 Annexes 27
9.1 Description des différents TTLs 27
9.1.1 Le TTL par défaut de la zone 27
9.1.2 Les TTL de l’enregistrement SOA 27
9.2 Réinitialisation du serial number par "overflow" (RFC1982) 28
9.3 Contrôler la compatibilité EDNS du résolveur (RFC2671) 29
9.4 Délais de timeout lors de la résolution par Bind 29
10 Références Erreur ! Signet non défini.
11 Glossaire Erreur ! Signet non défini.
41 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.
52 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.
63 Préconisations générales
3.1Sensibilité 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 1er 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.
73.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 86400 secondes.
Il faut être vigilant aux effets du cache négatif lié au TTL. En effet, les résolveurs gardent en cache non-
seulement 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 5.2
3.9 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.
83.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.
3.11 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.).
3.12 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.
3.13 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].
3.14 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.
94 Gestion des zones 4.1 Enregistrement et gestion administrative des zones 4.1.1 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". 4.1.2 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. 4.1.3 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. 4.1.4 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
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 3.13
4.2.1 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.
11De 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, § 2.3.4 & RFC2671].
4.2.2 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 { 192.0.2.1 }
}
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 198.51.100.1 {
keys { tsig_001.; };
};
server 2001:DB8::ABCD:ABCD:1 {
keys { tsig_001.; };
};
124.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 { 192.0.2.0/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.
4.3.1 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;------------------------------ DEBUT DE FICHIER -------------------------------
; Zone example.fr
;-------------------------------------------------------------------------------
; 20130701 pdupond : update "web" from 203.0.113.1 to 203.0.113.2
; 20130627 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. (
2013070101 ; Version
21600 ; Refresh (6h)
3600 ; Retry (1h)
3600000 ; 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=ms12345678"
;----------------------------------- COLLE ------------------------------------
; Les adresses des NS sous example.com
;------------------------------------------------------------------------------
ns1 IN A 192.0.2.1
IN AAAA 2001:DB8:1234:1234:1234:1
ns2 IN A 198.51.100.1
IN AAAA 2001:DB8:ABCD:ABCD:ABCD:1
ns3 IN A 203.0.113.1
IN AAAA 2001:DB8:CDEF:CDEF:CDEF:1
ns1.succursale IN A 192.0.2.200
ns2.succursale IN A 198.51.100.200
ns3.succursale IN A 203.0.113.200
;------------------------------------------------------------------------------
; 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 "www."
; Separateur: tabulation (sauf entre MX et son poids: utiliser un espace).
;------------------------------------------------------------------------------
abc IN CNAME web
;
succursale IN NS ns1.succursale
IN NS ns2.succursale
IN NS ns3.succursale
test IN CNAME web
www.test IN CNAME web
list.test IN CNAME web
www.list.test IN CNAME web
intranet.test IN CNAME web
www.intranet.test IN CNAME web
web IN A 203.0.113.2
;------------------------------ FIN DE FICHIER --------------------------------
144.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.
4.3.3 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
154.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]
4.3.5 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.
165 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.
175.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 also-
notify 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 192.0.2.1
nameserver 198.51.100.1
nameserver 203.0.113.1
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.)
185.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 192.0.2.1, 198.51.100.1, 203.0.113.1;
5.3.2 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
19L’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.
5.3.3 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.
5.3.4 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.
20Pour ces raisons, il est impératif de limiter l’accès au service de résolution récursive uniquement à ses propres
clients.
Exemple de configuration pour bind :
options {
allow-recursion {
192.0.2.0/24;
2001:db8:cafe::/48;
...
};
...
};
Exemple de configuration pour Unbound :
server:
access-control: 192.0.2.0/24 allow
access-control: 2001:db8:cafe::/48 allow
Par ailleurs, les possibilités d’empoisonnement de cache ont été limitées dans la plupart des résolveurs depuis
quelques années grâce à la randomisation du port source dans les requêtes. Il est donc recommandé
d’installer la version la plus récente possible du résolveur. De plus, DNSSEC, par la signature des
enregistrements, constitue une bonne solution à ce problème.
Par ailleurs, pour éviter que son réseau puisse contribuer à une attaque de déni de service distribuée, il est
recommandé de suivre les bonnes pratiques en terme de configuration réseau et notamment la BCP 38 pour
empêcher toute usurpation d’adresse IP depuis son réseau.
215.4 Résolveur et zones privées
En ce qui concerne les zones privées, soit dans des vues internes, soit sur des serveurs spécifiques dans une
architecture “Split-DNS”, celles-ci ne sont pas accessibles par un résolveur faisant uniquement des résolutions
récursives. En effet, comme le résolveur n’a pas connaissance de ces zones, une résolution à partir de la
racine se soldera par un échec. Il est recommandé :
de faire de la redirection spécifiquement pour ces zones,
de faire du résolveur un DNS esclave si c’est possible.
La première solution qui consiste à rediriger les requêtes vers le DNS faisant autorité pour ces zones privées
est relativement simple. Cependant, les informations mises en cache pour ces zones sont soumises à
l’expiration du TTL.
Exemple dans unbound :
local-zone: "internal.example.com." nodefault
forward-zone:
name: "internal.example.com."
forward-addr: 192.0.2.1
Dans la deuxième solution, le résolveur est aussi DNS esclave, il n’y a pas de problème de mise à jour des
informations : le serveur DNS maître notifie les esclaves en cas de modification. Par contre, le DNS devient un
serveur hybride, à la fois résolveur et esclave, engendrant plus de complexité de gestion.
5.5 Activation de la validation DNSSEC sur le résolveur
La résolution des requêtes de type DNSSEC peut être autorisée dans la configuration des résolveurs, elle est
même souvent implicite sur les résolveurs récents. Néanmoins il est nécessaire de déclarer au moins une
“ancre” dans la configuration du résolveur.
Dans ce cas le contrôle de validité de la chaîne de certification est effectué.
Exemples
Sous Bind (activé par défaut à partir de le version 9.5) :
options {
…
dnssec-enable yes;
dnssec-validation yes;
};
Déclaration de l’ancre via les clauses trusted-keys ou managed-keys dans named.conf
Exemple de résolution DNSsec de l’ensemble de la chaîne de certification:
dig +topdown +sigchase +multiline -ta www.isc.org
226 DNSSEC
DNSSEC garantit l’intégrité des informations servies par le DNS. Chaque enregistrement est augmenté d’une
signature cryptographique. Au moment de la résolution, la signature est validée. Comme le DNS est
hiérarchique, il est nécessaire d’établir une chaîne de confiance de la racine jusqu’à la zone feuille. La zone
parente doit être signée et une délégation vers la zone fille doit exister (enregistrement de type DS, Delegation
Signer).
6.1 Risques
La mise en œuvre de DNSSEC présente des risques opérationnels nouveaux.
6.1.1 Risques d’expiration
Les clefs ont une durée de vie limitée, et il est recommandé de les changer régulièrement. Les signatures
quant à elles ont une date d'expiration. . Si cette date est dépassée, les enregistrements servis par le DNS
seront invalides pour les résolveurs qui les vérifient, même si l’infrastructure DNS fonctionne parfaitement. De
plus, il est recommandé de synchroniser le serveur DNS avec NTP.
6.1.2 Risque de compromission des clefs
De plus, il faut sécuriser les clefs privées servant à signer les clefs ou les zones. C’est une problématique
classique de gestion des clefs.
6.1.3 Risque d’inaccessibilité de la zone
Il existe diverses raisons pour lesquelles la résolution risque de ne plus fonctionner sur une zone sécurisée par
DNSSEC : filtrage de paquets DNS particuliers (EDNS0, certains types d’enregistrements), filtrage des
fragments IP ou des messages ICMP etc. Il s’agit souvent de firewalls, de relais applicatifs ou de box mal
configurés. Un pourcentage relativement faible d’utilisateurs sur Internet risque de ne pas pouvoir résoudre
des enregistrements DNS à cause de DNSSEC.
[https://www.usenix.org/conference/usenixsecurity13/measuring-practical-impact-dnssec-deployment].
6.2 Mise en œuvre de DNSSEC
Il faut générer deux types de clef :
● la KSK (Key Signing Key) qui servira à signer les clefs
● la ZSK (Zone Signing Key) qui servira à signer la zone
Il faut ensuite ajouter les clefs à la zone. Puis il faut signer la zone et la redéployer.
Il est fortement recommandé d’automatiser la gestion des clefs et des signatures en s’appuyant sur des
fonctions intégrées à Bind ou sur OpenDNSSEC.
236.3 Rotation des clefs
Les signatures ayant une date d’expiration il convient d’anticiper celle-ci en publiant deux clefs à un instant
donné :
● une clef A active, qui expire à un instant T,
● une clef B inactive, qui expire à un instant T+3 mois par exemple
La transition de la clef A vers la clef B doit se faire avant l’expiration de la clef A. La clef B est créée par
anticipation pour qu’elle soit présente dans les caches des résolveurs au moment où on effectue la transition.
La rotation des clefs doit être automatisée. À partir de la version 9.8, Bind intègre un certain nombre de
fonctions d’automatisation. Il existe également des outils comme OpenDNSSEC. Des explications plus
détaillées sont fournies dans la documentation de Bind et d’OpenDNSSEC.
247 Messagerie : dépendance au DNS
Les serveurs SMTP d’une zone sont publiés au travers des enregistrements de type « MX ». On y associe un
indice de priorité permettant une répartition de charge de type round robin. Lorsqu’un serveur est déclaré avec
un « poids » faible il est prioritaire. Mais attention, même dans ce cas certaines requêtes seront affectées au
serveur(s) non prioritaire(s).
7.1 Eviter le « phishing »
Le DNS propose des solutions afin de limiter le risque de « phishing » ou « hameçonnage ».
7.2 Publier les serveurs SMTP ayant autorité
Une zone DNS peut publier les serveurs SMTP ayant autorité pour l’envoi de mails avec ce domaine en clause
« FROM ». Cela se fait au travers d’un enregistrement de type « Sender Policy Framework » (RFC4408). Il
s’agit d’une entrée de type « TXT » ou « SPF » déclarant les serveurs SMTP valides.
Exemple de syntaxe : @ IN TXT “v=spf1 mx mx:smtprelay.cnrs.fr a:sgaia1.dsi.cnrs.fr ~all"
7.3 Signer un domaine de messagerie
Le « DomainKeys Identified Mail » (RFC4871) ajoute une signature dans l’entête du message qui authentifie le
domaine expéditeur.
Exemple de syntaxe dans le fichier de zone :
dkim._domainkey.secours IN TXT "v=DKIM1;
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDI8W7ZkozIjg1R9kavGJjPeief5Tdf++wIA4mVbOGAn3xsh8WPH
oL2OGqEl7xKZcfCyBFhlI3bkb31hsWv7SDyoVP4IBO/K7hYufrzLt3zIWmijAWerEhgPx91u3cxHN3KRxT4e30DE4gV
qjZQom4xKUaMtULO5pDh13xxTwgn3wIDAQAB"
7.4 Utiliser des résolveurs locaux sur les serveurs SMTP
Les serveurs de messagerie sont très consommateurs de requêtes DNS. Il peut être intéressant d’installer
localement sur ces machines un résolveur DNS qui permettra de profiter de son cache et déchargera le
résolveur mutualisé.
258 Synthèse des recommandations
Sécurité
Continuité et intégrité du service Confort
des infos
Critique Important Conseillé
Renouvellement de la délégation X
Au moins un NS esclave X
Restreindre la résolution récursive X
Isolement Résolveur/Autorité X
Isolement zones privées/publiques X
Isolement NS management/publics X
Plusieurs NS esclaves X
NS sur réseaux distincts X
Panachage OS & serveur DNS X
Interface d’administration * X
Virtualisation * X
DNSsec ** X
Messagerie : DKIM et SPF X
Chrootage du service X
Ventilation des fichiers de config X
Ventilation des logs X
* : peut potentiellement engendrer une faiblesse de sécurité
** : peut potentiellement bloquer la résolution si mal géré
26Vous pouvez aussi lire
