Sécurité DNS · 3 min read · Oct 27, 2025
Vulnérabilité BIND 9 et Solution - Patch BIND Pour Éviter le Poisonnement de Cache (Fedora/CentOS)
Vulnérabilité BIND 9 et Solution - Patch BIND Pour Éviter le Poisonnement de Cache (Fedora/CentOS)
Je suis assez sûr que la plupart d’entre vous ont entendu parler de la vulnérabilité dans BIND. Dan Kaminsky a annoncé plus tôt ce mois-ci un problème massif, multi-vendeurs avec DNS qui pourrait permettre aux attaquants de compromettre n’importe quel serveur de noms - clients inclus.
Je pensais partager avec vous tous l’une des solutions les plus rapides que les administrateurs système utilisant BIND 9 peuvent utiliser pour aider à résoudre cette vulnérabilité au cas où leurs systèmes seraient vulnérables.
Après 3 jours de tests et d’expérimentations avec mes serveurs DNS, j’ai découvert quelque chose qui semblait résoudre mon problème, d’où ma décision de partager cela avec vous tous.
Je ne suis pas sûr que cela ait vraiment résolu le problème, bien que cela ait fonctionné pour moi car les résultats des tests sont excellents. Mais vos suggestions et commentaires sont les bienvenus.
Ma découverte, aussi simple soit-elle, ne s’applique qu’à ceux qui exécutent BIND 9 sur Centos 4 ou 5 et les systèmes Fedora core et supérieurs… J’ai testé sur toutes ces machines dans mon bureau.
Commençons… n’est-ce pas ?
Prérequis et Hypothèses
- Votre pare-feu (iptables NAT/PAT ou PIX) doit avoir le port 53 ouvert de manière à permettre la sélection de ports aléatoires.
- Vous devez exécuter BIND 9 sur Centos 4 ou 5 ou tout système Fedora core.
- BIND doit fonctionner en mode chrooté, bien que ce ne soit pas un prérequis mais une bonne pratique.
- Dans vos fichiers /etc/named/named.conf OU /etc/named.conf…. Il faut désactiver les requêtes récursives et également ajouter un acl pour ne permettre qu’à leurs réseaux de faire des requêtes récursives. Avec cela, l’administrateur système aura réduit les chances de poisonnement de cache à leurs propres réseaux connus.
acl "mynetworks" {
127/8; 172.16.0.0/12; 10.0.0.0/8; 192.168.0.0/16view "internal" {
match-clients { mynetwork; };
allow-query { mynetwork; };
allow-recursion { mynetwork; };
match-recursive-only yes;view "external" {
match-clients { any; };
allow-query { any; };
allow-recursion { none; };
match-recursive-only no;Et Maintenant Pour Corriger La Vulnérabilité BIND
La première étape consiste à vérifier si votre système est vulnérable… en exécutant les commandes ci-dessous en remplaçant ns1.youdomain.co.tz par le TLD ou ccTLD de votre organisation.
dig +short @ns1.youdomain.co.tz 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.
“192.168.1.3 est MAUVAIS : 26 requêtes en 20.0 secondes depuis 1 ports avec écart type 0.00”
MAUVAIS —–> indique définitivement que le serveur de noms ou le système en question est vulnérable et bien sûr le logiciel BIND en cours d’exécution est également ancien et doit être PATCHÉ …
Solution
Pour ceux qui exécutent des systèmes CentOS OU Fedora….. yum peut être utilisé pour patcher les systèmes. Les développeurs de CentOS 5 ont déjà publié un patch pour le logiciel BIND et le patch actuel est : bind-9.3.4-6.0.2.P1.el5_2. P1 indique que le paquet est un paquet patché.
Sur mes systèmes après le patchage, j’ai obtenu ce résultat..
rpm -q bindbind-9.3.4-6.0.2.P1.el5_2 —-> si votre version de bind n’est pas patchée.. alors patchez-la.
Il faut faire cela pour obtenir le dernier logiciel et le patch.
yum update bind bind-chroot -yIl faut éditer leur fichier named.conf et ajouter ce qui suit. Enregistrez et rechargez BIND.
vi /etc/named.conf options {
directory "/var/named";
allow-transfer {192.168.1.4 ;};
query-source address * port 53; ##COMMENTER ou RETIRER CETTE LIGNE.Cela permettra la sélection de ports aléatoires. Ne faites cela que si ce paramètre est activé sous options dans votre fichier named.conf.
dnssec-enable yes; ## AJOUTEZ CETTE OPTION POUR ACTIVER DNS-SEC.La ligne ci-dessus, lorsqu’elle est ajoutée à votre fichier named.conf, activera DNS-SEC. Allez-y et configurez DNS-SEC mais rappelez-vous que DNS-SEC n’est pas une solution ultime à cette vulnérabilité. **
Rechargez ou redémarrez BIND.
/etc/init.d/named reload
Puis testez à nouveau pour voir si vous obtenez un meilleur résultat.
dig +short @ns1.youdomain.co.tz porttest.dns-oarc.net TXT
Juste pour confirmer… :-)
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.
“192.168.1.3 est BON : 26 requêtes en 19.6 secondes depuis 26 ports avec écart type 16515.27”
BON indique que le serveur de noms en question à 192.168.1.3 semble être sûr, mais il faut s’assurer que les ports listés ne suivent pas un modèle évident. c’est-à-dire les ports avec écart type.. 16515.27… Mais si votre test affiche ( 10000.00 écart type) alors votre serveur DNS est plus sûr et vos clients ou utilisateurs ne devraient pas s’inquiéter.
La même procédure doit être effectuée sur tous les serveurs DNS de votre organisation.
Recevez de nouveaux articles dans votre boîte de réception.
Aucun spam. Désabonnez-vous à tout moment.