Utiliser TSIG dans BIND

mieux en charge
DNSSEC, on peut utiliser TSIG pour
authentifier les transactions DNS entre
deux hôtes.

Dans TSIG, deux hôtes (c’est-à dire,
deux serveurs DNS ou un serveur
DNS et un client DNS) partagent une
clé secrète et utilisent un algorithme
MD pour authentifier une transaction
de message DNS. Contrairement à 
DNSSEC, TSIG n’utilise pas de fichiers de zone présignés. Quand un hôte validé
TSIG envoie un paquet de messages,
il lui associe une signature, laquelle
ne vaut que pour cette
transaction. La technologie de clé secrète
partagée de TSIG permet à  de
multiples hôtes de partager la même
clé secrète. Ce type de clé est plus vulnérable
que les clés publique et privée
que DNSSEC utilise, et donc TSIG n’est
pas aussi sûr que DNSSEC.

On peut utiliser TSIG pour authentifier
des transactions de messages
DNS comme des requêtes et réponses,
des mises à  jour dynamiques, et des
transferts de zones. On peut, par
exemple, utiliser TSIG entre les serveurs
DNS et les serveurs DNS des ISP
ou des partenaires pour sécuriser ces
communications. Si votre serveur
BIND utilise une zone DDNS (Dynamic
DNS), vous pouvez utiliser TSIG pour
authentifier les mises à  jour dynamiques
provenant des clients, des serveurs
DHCP, et des autres serveurs
supportant TSIG. Ce type d’authentification
des mises à  jour dynamiques est
plus sûr que l’authentification par
adresse IP. On peut également utiliser
TSIG pour authentifier les transferts de
zones du serveur DNS primaire vers les
serveurs DNS secondaires. BIND 8.2.4
et 9.1.3 supportent essentiellement
TSIG pour la communication de serveur
à  serveur. L’outil de mise à  jour dynamique
de ces versions BIND,
Nsupdate, supporte également TSIG à 
l’aide d’une option de clé secrète.
Supposons que l’on veuille utiliser
TSIG entre deux hôtes, host1 et host2.
Il faut commencer par générer une clé
secrète pour les hôtes. Pour cela, on
dispose de la commande dnssec-keygen

dnssec-keygen a HMACMD5

b 128 n HOST

host1-host2.

Comme je l'ai expliqué précédemment,
l'option -a de cette commande
définit l'algorithme de signature numérique
que la clé générée utilisera. RFC
2845 spécifie HMAC-MD5 comme l'algorithme obligatoire pour l'interopérabilité
TSIG, et BIND n'accepte
que HMAC-MD5 pour TSIG. La longueur
de clé maximale pour HMACMD5
est de 512 bits. (L'exemple utilise
une longueur de clé de 128 bits.) Le
nom de clé dans cet exemple est host1-
host2. (le point final fait partie du
nom). Le fichier de clés privées de sortie
contient la clé secrète générée.
Ainsi, la commande exemple crée le fichier
de clés privées Khost1-
host2.+157+59290 .private. La ligne
Key : dans ce fichier contient la clé secrète.
Il faut fournir en toute sécurité
cette clé aux deux hôtes.

Si host1 et host2 sont tous deux
des serveurs BIND, il faut ajouter l'instruction
key du listing 2 aux fichiers
named.conf des deux serveurs. Pour
protéger l'instruction key, il faut restreindre
l'accès en lecture à 
named.conf afin que seul le compte racine
puisse lire le fichier.

Il est préférable de maintenir un fichier
séparé ne contenant que les instructions
key, de protéger ce fichier,
puis d'inclure son nom dans
named.conf. En procédant de la sorte,
il n'est pas nécessaire de restreindre
named.conf.

Pour permettre à  host1 (adresse IP
192.168.1.10) d'utiliser la clé et TSIG
quand il envoie un message à  host2
(adresse IP 192.168.2.10), ajoutez l'instruction
server que présente le listing
3, au fichier named.conf de host1.
Ajoutez l'instruction server du listing 4
au fichier named.conf d'host2.

Si host2 met à  jour dynamiquement
une zone dynamique sur host1,
on peut utiliser la clé TSIG pour authentifier
host2 et sa requête. Pour
cela, on utilise une instruction allowupdate,
comme dans le listing 5, dans
le fichier named-conf d'host1.