Comment corriger BIND9 contre l'empoisonnement du cache DNS sur Debian Etch

Comment corriger BIND9 contre l’empoisonnement du cache DNS sur Debian Etch

Version 1.0
Auteur : Falko Timme

Cet article explique comment vous pouvez corriger un serveur de noms BIND9 sur un système Debian Etch afin qu’il ne soit plus vulnérable à l’empoisonnement du cache DNS.

Ce document est fourni sans garantie d’aucune sorte ! Je ne donne aucune garantie que cela fonctionnera pour vous !

1 Vérification si BIND est vulnérable

Exécutez la commande suivante contre votre serveur de noms pour savoir s’il est vulnérable (remplacez ns1.example.com par votre propre adresse de serveur de noms) :

dig +short @ns1.example.com porttest.dns-oarc.net TXT 

mh1:~# dig +short @ns1.example.com porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“1.2.3.4 est MAUVAIS : 26 requêtes en 4.4 secondes depuis 1 ports avec un écart type de 0.00”
mh1:~#

MAUVAIS indique que BIND est vulnérable. Dans ce cas, vous devez corriger BIND.

Si vous ne recevez aucune réponse, cela signifie que votre serveur DNS n’est pas un résolveur récursif, ce qui signifie qu’il ne répond pas aux requêtes pour des domaines pour lesquels il n’est pas autoritaire. Dans ce cas, vous n’êtes pas vulnérable à l’empoisonnement du cache, mais je vous conseille fortement de mettre à jour BIND !

2 Correction de BIND

Ce n’est pas tant un correctif, mais une mise à jour. Il suffit d’exécuter

apt-get install bind9 bind9-host

Cela installera les paquets BIND mis à jour à partir des dépôts Debian.

Ensuite, ouvrez /etc/bind/named.conf et modifiez la section des options. Si vous n’avez pas besoin d’un résolveur récursif (c’est-à-dire, si votre serveur de noms doit répondre uniquement aux requêtes pour les domaines dont il est responsable), ajoutez allow-recursion { none; };. De cette façon, vous désactivez la mise en cache pour d’autres domaines. La deuxième ligne que vous devriez ajouter est dnssec-enable yes; - cela fait que BIND répond aux requêtes sur des ports aléatoires qui sont plus difficiles à deviner pour les hackers (rappelez-vous la réponse à notre commande dig au chapitre 1 : […]26 requêtes en 4.4 secondes depuis 1 ports[…] - BIND répondait sur un seul port…).

Correction : Je viens de recevoir le courriel suivant d’Alan Clegg :

Bonjour ! Je viens de lire votre article sur : https://www.howtoforge.com/how-to-patch-bind-to-avoid-cache-poisoning-debian-etch et j’ai quelques commentaires. Tout d’abord, merci d’avoir écrit cela. Nous avons besoin que le plus de personnes possible corrigent ce problème. Deuxièmement, il y a une petite erreur qui devrait être corrigée. Vous déclarez : “La deuxième ligne que vous devriez ajouter est dnssec-enable yes; - cela fait que BIND répond aux requêtes sur des ports aléatoires qui sont plus difficiles à deviner pour les hackers” En réalité, cette ligne permet au serveur de répondre avec des enregistrements DNSSEC lorsque le bit “DO” (DNSSEC OK) est défini dans la question posée. Ce que vous voulez que les gens recherchent est une déclaration comme : query-source […] port XX; où le XX est un numéro de port fixe sur lequel les requêtes de ce système doivent être envoyées. Cela annule tout ce que les nouvelles versions de BIND font pour randomiser le port source UDP. Si vous avez des questions, n’hésitez pas à envoyer un e-mail. Alan Clegg
Internet Systems Consortium (ISC)
Formation et Support

vi /etc/bind/named.conf

| [...] options { pid-file "/var/run/bind/run/named.pid"; directory "/etc/bind"; auth-nxdomain no; allow-recursion { none; }; dnssec-enable yes; /* * S'il y a un pare-feu entre vous et les serveurs de noms avec lesquels vous voulez * communiquer, vous devrez peut-être décommenter la directive query-source * ci-dessous. Les versions précédentes de BIND posaient toujours * des questions en utilisant le port 53, mais BIND 8.1 utilise un port non privilégié * par défaut. */ // query-source address * port 53; }; [...] |

Redémarrez BIND ensuite :

/etc/init.d/bind9 restart

(Si vous utilisez ISPConfig, vos modifications seront écrasées par ISPConfig. Pour éviter cela, nous prenons le fichier modèle named.conf /root/ispconfig/isp/conf/named.conf.master, le modifions comme indiqué ci-dessus, et enregistrons le modèle modifié dans le répertoire /root/ispconfig/isp/conf/customized_templates => /root/ispconfig/isp/conf/customized_templates/named.conf.master. Veuillez également modifier /etc/bind/named.conf comme indiqué ci-dessus en plus de cela.)

3 Vérification de BIND à nouveau

Maintenant, nous exécutons la requête du chapitre 1 à nouveau :

dig +short @ns1.example.com porttest.dns-oarc.net TXT

Si tout s’est bien passé, cela devrait maintenant afficher BON au lieu de MAUVAIS, et cela devrait utiliser plus qu’un seul port :

mh1:~# dig +short @ns1.example.com porttest.dns-oarc.net TXT
z.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
“1.2.3.4 est BON : 26 requêtes en 4.4 secondes depuis 26 ports avec un écart type de 20195.32”
mh1:~#

Félicitations, vous venez de corriger BIND !

Vous pouvez également exécuter la commande dig contre les serveurs de noms de votre FAI pour savoir si leurs serveurs de noms sont toujours vulnérables. S’ils le sont, vous devriez inciter votre FAI à mettre à jour leurs serveurs de noms !