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.
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.
