Comme recommandé dans la note Faille DNS : Le grand "buzz" de ces derniers jours la mise à jour des serveurs DNS de type "resolver/cache" est une action devant etre menée à bien si pas déjà effectuée depuis.
Votre serveur DNS est donc protégé, tout retourne à la normale..... Sauf que NON.... Celui-ci est toujours marqué comme étant vulnérable via un outil comme "DNS Checker" proposé sur le site http://www.doxpara.com : Les ports sources sont toujours aussi statiques qu'avant....
D'où vient le problème ? Une erreur lors du déploiement du correctif ? Un problème de configuration de la nouvelle version du DNS ? Des yeux embrumés ? Une erreur de l'outil DNS Checker ?
Non, c'est tout simplement que votre serveur DNS est derrière un equipement qui fait de la translation d'adresse (NAT), comme par exemple un équilibreur de charge, un firewall, un routeur, etc... Comment aborder le sujet ? Quels principes adopter ? .....
Un équipement effectuant de la NAT (Network Address Translation) effectue deux principaux changements sur tous les paquets sortants : Il change (ou translate) l'adresse IP source des paquets d'une adresse IP privée (typiquement en RFC1918) vers une adresse IP publique et change aussi les numéros des ports source.
Ces modifications sont nécessaires pour que l'équipement puisse retransmettre les réponses après coup au bon serveur lorsque celles-ci arriveront.
Le problème c'est qu'une très grande majorité des équipements effectuant de la NAT ne conservent pas le coté "aléatoire" des numéros de port sources des paquets [1] et [2] : Votre nouveau serveur DNS qui générait désormais des requêtes sortantes avec des ports sources aléatoires se retrouve affublé de ports alloués de façon séquentielle.... Donc tout le travail de mise à jour que vous avez pu effectuer n'a servi à rien.... Votre serveur DNS peut être "poisoned"
Quelles options sont envisageables ?
- La plus radicale c'est de ne plus faire de NAT : Cela impliquant un changement d'architecture... solution parfois complexe, coûteuse en temps et en effort, ... et pas toujours faisable selon le contexte.
- Re-configurez l'équipement qui fait la NAT (votre firewall, load-balancer, ...) de sorte qu'il alloue des numéros de port aléatoire et non plus séquentiels.
- Changer votre Firewall/équipement de NAT pour un système qui alloue des numéros de port sources aléatoires. Comme par exemple PF d'OpenBSD [3] ou encore IPTables de Linux [4].
Et les bonnes nouvelles dans tout ça ?
Il y en a une : Avec un système de NAT qui alloue des numéros de port sources aléatoires vous protégez un serveur DNS vulnérable... Plus besoin de patcher votre vieux système pour lequel vous n'avez pas payé la maintenance depuis des années et qui est un emblème vivant du proverbe bien connu "If its works, don't fix it".
Je continuerai à développer le sujet "DNS poisoning" dans une autre note.
Pour les lecteurs intéressés, quels liens :
[1] ISS, Frequency X Blog, (UPDATED) DNS Cache Poisoning and Network Address Translation, July 10, 2008
http://blogs.iss.net/archive/dnsnat.html
[2] ISS, Frequency X Blog, More on DNS Cache Poisoning and Network Address Translation, July 14, 2008
http://blogs.iss.net/archive/morednsnat.html
[3] Jon Hart's Blog, Mitigating DNS cache poisoning with PF, July 14, 2008
http://blog.spoofed.org/2008/07/mitigating-dns-cache-poisoning-with-pf.html
[4] Cipherdyne, Mitigating DNS Cache Poisoning Attacks with iptables, July 14, 2008
http://cipherdyne.org/blog/2008/07/mitigating-dns-cache-poisoning-attacks-with-iptables.html
Au sein de la direction sécurité du Groupe Orange, je suis en charge de la veille sécurité et de la sensibilisation à la sécurité. Franchise, optimisme et bonne-humeur sont mes moteurs quotidiens