> Tech > Optimiser la sécurité de Bind DNS

Optimiser la sécurité de Bind DNS

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Tao Zhou - Mis en ligne le 11/06/2002
Aucune société ne peut se permettre d'ignorer la sécurité de son service DNS, important outil qui assure la résolution des noms d'hôtes et des adresses IP sur Internet. Bien que Windows 2000 offre un service DNS intégré, BIND est le logiciel DNS le plus largement utilisé sur Internet et bon nombre d'administrateurs Win2K s'en servent pour maintenir leurs serveurs DNS Internet.

« Sécurisez votre service BIND DNS » de février 2002, j'explique les vulnérabilités des anciennes versions BIND et comment utiliser les nouveaux paramètres de contrôle d'accès BIND 8 (c'est-à -dire, BIND 8.2.3 et ultérieurs) et BIND 9 (c'est-à -dire BIND 9.1.0 et ultérieurs) pour instaurer une couche de protection de base. Mais ces paramètres ne concernent pas deux critères de sécurité importants : l'authentification et l'intégrité des données. Pour être vraiment sécurisé, un client ou serveur DNS ne doit communiquer qu'avec un serveur DNS trusted et il doit authentifier les données reçues : confirmer que personne n'a intercepté la réponse à  une requête et n'a modifié son contenu pendant sa transmission sur Internet.

C'est pour garantir l'authentification et l'intégrité des données que l'IETF (Internet Engineering Task Force) a lancé le développement du standard DNSSEC (DNS Security) Internet, qui utilise la clé publique et la signature numérique que les développeurs peuvent intégrer dans leurs logiciels DNS. L'IETF a également mis au point le protocole d'authentification de transactions DNS TSIG (Transaction Signature), qui utilise la clé secrète partagée pour contribuer à  la sécurité des transactions DNS. (IETF Request form Comments - RFC - 2535 et RFC 3008 expliquent DNSSEC ; RFC 2845 explique TSIG. Pour plus d'informations sur DNSSEC, on peut également visiter le site Web des ressources DNSSEC du Lab NLnet à  http://www.nlnetlabs.nl/ dnssec.).

L'ICS (Internet Software Consortium), qui développe et maintient les codes source BIND, a intégré DNSSEC et TSIG dans BIND 8.2.3 et ultérieure et dans BIND 9.1.0 et ultérieure. Les nouvelles versions de BIND 9 prennent mieux en charge DNSSEC et TSIG que les versions BIND 8. Les deux générations peuvent engendrer des clés publiques et privées, mais BIND 9.1.0 a des possibilités de signature de zone étendues. C'est pourquoi cet article se concentre sur la mise en oeuvre de DNSSEC et TSIG dans BIND 9.1.3. (L'ISC n'a pas encore importé BIND 9.1.3 dans Win2K ou Windows NT, mais on peut utiliser BIND 9.1.0 sur la plupart des plates-formes UNIX et Linux. De plus, BIND Release Candidate - RC - 9.2.0 supporte Win2K et NT.) Cet article supporte que vous connaissez les principes de base de BIND, de la signature numérique, et de la clé secrète partagée.

Optimiser la sécurité de Bind DNS

La mise en oeuvre de DNSSEC sur votre
serveur BIND DNS implique la signature
du fichier de zone de domaine
DNS du serveur. (J’explique ce processus
plus loin.) DNSSEC applique ensuite
la signature numérique à  chaque
enregistrement dans la zone. Quand
un client DNS demande un enregistrement
DNS spécifique, le serveur DNS
répond avec la version signée de l’enregistrement demandé. Le client
DNS utilise alors la signature numérique
pour confirmer l’intégrité des
données de l’enregistrement reçu et
pour authentifier le serveur DNS. A
l’appui de la signature numérique,
DNSSEC présente deux nouveaux RR
(resource records) DNS : SIG et KEY.
Le protocole de sécurité introduit
également le RR NXT pour faciliter
l’authentification des enregistrements
DNS non existants.

Le RR SIG. Un RR SIG contient la
signature numérique de chaque RR
original (Start of Authority – SOA –
NS, A, PTR, MX, CNAME, par
exemple). Dans une zone signée,
DNSSEC associe chaque RR original à 
un RR SIG pour former un ensemble
d’enregistrements. Le listing 1 présente
le fichier de zone pour une
zone non signée et non sécurisée,
us.example.com. La figure 1 montre
le fichier de zone pour la zone sécurisée
et signée correspondante.
Comme on le voit figure 1, un RR SIG
suit chaque RR original dans la zone
signée. La syntaxe d’un RR SIG est la
suivante :

corresponding_RR_type
signing_algorithm
number_of_owner_labels
original_TTL
signature_expiration
signature_inception key_tag
signer signature

Par exemple, le renvoi D en figure
1 montre le RR SIG pour l'enregistrement
A de www.us.example.com.
Cette sortie montre que le RR SIG correspond
à  un RR A et que DNSSEC a
utilisé DSA (Digital Signature
Algorithm) pour signer le RR original.
(RFC 2535 explique les algorithmes de
signature possibles: 1 pour
RSA/Message Digest 5 - MD5, 2 pour
Diffie-Hellman et 3 pour DSA. Le propriétaire
du RR A (c'est-à -dire
www.us.example.com) a quatre labels
(c'est-à -dire www, us, example et com).
La valeur TTL (Time to Live) originale
du RR A est de 86.400 secondes (c'està -
dire 1 jour), la signature expire à 
6:10:13 GMT (Greenwich Mean Time), le 3 avril 2001 (c'est-à -dire
20010403061013), et la signature est
devenue valide à  6:10:13 GMT, le 4
mars 2001 (c'est-à -dire 200103040
61013). Le key tag (c'est-à -dire, un
nombre qui identifie la paire de clés
publique et privée de la zone) est
51297. Le signataire est us.example.
com et l'étrange chaîne finale est la signature.

Le RR KEY. On utilise la clé privée
d'une zone (tirée de sa paire de clés
publique et privée) pour signer la zone
pendant l'implémentation de DNSSEC.
On tient la clé privée secrète et le RR
KEY stocke la clé publique, qu'un
client DNS utilise pour vérifier les signatures
des enregistrements DNS reçus.
DNSSEC fournit un RR SIG correspondant
pour chaque RR KEY, mais la
zone parent signe le RR KEY. Ainsi, la
zone parent example.com signerait un
RR KEY dans la zone signée
us.example.com. La syntaxe d'un RR
KEY est la suivante :

flags protocol algorithm
public_key

Des flags indiquent le type de la clé
incluse et comment l'utiliser. Ainsi, le
renvoi A de la figure 1 montre le RR
KEY de us.example.com. Cette sortie
montre que la clé est une clé de zone ne servant qu'à  l'authentification. Le
protocole est DNSSEC (représenté par
le chiffre 3), l'algorithme de signature
est DSA (représenté par le chiffre 3) et
la chaîne finale est la clé publique de la
zone. (RFC 2535 explique la signification
des options du RR KEY.) Le RR SIG
correspondant de RR KEY, représenté
par le renvoi B en figure 1, définit le signataire
du RR KEY (c'est-à -dire la zone
parent de us.example.com, example.
com).

Le RR NXT. Les RR SIG et KEY sont
suffisamment puissants pour authentifier
des enregistrements DNS existants,
mais DNSSEC ne serait pas vraiment
sûr sans un mécanisme d'authentification d'enregistrements
non existants. Prenons par exemple le
fichier de zone www.us.example.com
non sécurisée du listing 1. Si un client
demande un enregistrement non existant,
product.us.example.com, le serveur
DNS utilisant la zone non sécurisée
renverra le RR SOA et une erreur
NXDOMAIN, qui indique que l'enregistrement
demandé n'existe pas.

Si DNSSEC utilisait la même méthode
pour répondre à  une telle requête
- même si DNSSEC fournissait
un RR SIG correspondant pour le RR
SOA signé - un intrus pourrait facilement
semer le chaos. L'intrus pourrait
interroger la zone ou écouter sur la ligne pour déterminer le SOA de
us.example.com et les RR SIG correspondants.
Ensuite, quand un client demanderait
au serveur DNS l'enregistrement
existant www.us.example.com,
l'intrus pourrait envoyer à  ce client les
RR SOA et SIG et l'erreur NXDOMAIN
avant que le serveur DNS ne puisse répondre.
Le client vérifierait la signature
du RR SOA et déterminerait que
www.us.example.com n'existait pas.

Pour prévenir de tels problèmes,
DNSSEC a introduit le RR NXT, qui indique
les noms des propriétaires d'enregistrements
qui n'existent pas dans
un certain intervalle de noms. (Par
exemple, si un client sait que dans l'intervalle
de noms de 1 à  4, l'enregistrement
courant est 1 et l'enregistrement
suivant est 4, le client peut en déduire
que les enregistrements 2 et 3 n'existent
pas.)

DNSSEC dispose les ensembles
d'enregistrements d'une zone signée
en ordre canonique (c'est-à -dire, nom
de zone, wildcard - * - enregistrement
- éventuel, puis les autres enregistrements
en ordre alphabétique) et insère
un RR NXT pour chaque enregistrement.
La syntaxe d'un RR NXT est la
suivante :

next_record_owner record_types_
in_current_set

Ainsi, le RR NXT de ns1.us.example.
com, correspond au renvoi C de la
figure 1, indique que le nom du propriétaire
de l'enregistrement suivant
est www.us.example.com et que l'enregistrement
courant (c'est-à -dire
ns1.us.example.com) contient les
types de RR A, SIG et NXT. A partir de
ce RR NXT, le client peut déterminer
qu'aucun autre enregistrement
n'existe entre ns1.us.example.com et
www.us.example.com. Le RR NXT final
d'une zone pointe toujours en retour
sur le premier enregistrement de la
zone (c'est-à -dire le nom de la zone).
DNSSEC signe chaque RR NXT avec un
RR SIG associé, et la syntaxe de l'enregistrement
NXT empêche les intrus d'utiliser le RR NXT pour faire croire à 
un client qu'un enregistrement existant
n'existe pas.

Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par iTPro.fr - Publié le 24 juin 2010