Info16.fr

#Gnu/Linux

Sécuriser un DNS BIND avec les views

27 juillet 2011 Rédigé par bartounet

Ce billet explique comment éviter que votre serveur DNS serve de relay DNS.

En général la manière classique d'éviter que votre dns réponde au demande autre que celle relative à votre domaine est d'implementer la commande allow-recusion en la limitant sur une ACL

     acl lan {      localhost;      192.168.0.0/16;     }; options {     allow-transfer { none; };     allow-query { lan;};     allow-recursion { lan;}; }; Mais si vous faites des tests  plus avancés, vous vous rendez vite compte que votre DNS répond à des requetes extérieures mais pour résoudre des noms qui n'appartiennent pas à votre domaine. En entreprise ce n'est pas acceptable. En fait votre DNS ne résoud pas tous les noms mais seulement qui sont déjà dans son cache local.... La commande vu plus haut n'empêche pas l'accès au cache du serveur DNS. Si l'attaquant réussit à peupler ce cache (par exemple en envoyant un courrier à une machine utilisant légitimement ce serveur récursif), il pourra quand même mener son attaque. BIND 9.4 (pas encore publié à ce jour) aura une nouvelle option allow-query-cache qui résoudra ce problème. Avec cette option, une configuration raisonnable sera : allow-recursion {mynetworks;}; allow-query-cache {mynetworks;}; // Surtout ne pas oublier celui-ci. Mais en attendant cette nouvelle version on ne peut pas se permettre de laisser notre cache DNS ouvert à tout le monde... Pour résoudre ce probleme on va creer des views. La commande view dansbind permet de determiner qui aura le droit de visu sur les différentes zone de notre DNS. Le but sera donc de creer une ACL qui comprendra tous les hotes de notre réseau local ( par exemple LAN) et une autre view pour tous les autres, qui n'auront accès qu'a la zone qui gere votre nom de domaine... Votre DNS ne répondra qu'au requetes qui concerne votre nom de domaine et aucune autre. pour cela je vous montre mon fichier de conf vi /etc/bind/named.conf

 acl lan {       localhost;       192.168.0.0/16;      };   //  logic to all top level domains, and to the root domain.  An exception list   //  should be specified, including "MUSEUM" and "DE", and any other top level   //  domains from whom undelegated responses are expected and trusted.   // root-delegation-only exclude { "DE"; "MUSEUM"; };   #include "/etc/bind/named.conf.local";   view interne {           match-clients {                   lan;                   };           recursion yes;   zone "." {           type hint;           file "/etc/bind/db.root";   };   zone "localhost" {           type master;           file "/etc/bind/db.local";   };   zone "127.in-addr.arpa" {           type master;           file "/etc/bind/db.127";   };   zone "0.in-addr.arpa" {           type master;           file "/etc/bind/db.0";   };   zone "255.in-addr.arpa" {           type master;           file "/etc/bind/db.255";   };   zone "info16.fr" {           type master;           file "/etc/bind/db.mondomaine.fr";   };   zone "22.151.91.in-addr.arpa" {           type master;           file "/etc/bind/db.mondomaine.fr.inv";   };           };   view externe {           match-clients {                   any;                   };           recursion no;   zone "mondomaine.fr" {           type master;           file "/etc/bind/db.mondomaine.fr";   };   zone "31.121.91.in-addr.arpa" {           type master;           file "/etc/bind/db.mondomaine.fr.inv";   };           };

Les étapes importantes, # Creer une acl       acl lan {        localhost;        192.168.0.0/16;       }; # creer les views en définissant, qui a droit d'utiliser la view et quelle zone sont visible dans cette view.   view interne {            match-clients {                    lan;                    };            recursion yes;    zone "." {            type hint;            file "/etc/bind/db.root";    };    zone "localhost" {            type master;            file "/etc/bind/db.local";    };    zone "127.in-addr.arpa" {            type master;            file "/etc/bind/db.127";    };    zone "0.in-addr.arpa" {            type master;            file "/etc/bind/db.0";    };    zone "255.in-addr.arpa" {            type master;            file "/etc/bind/db.255";    };    zone "info16.fr" {            type master;            file "/etc/bind/db.mondomaine.fr";    };    zone "22.151.91.in-addr.arpa" {            type master;            file "/etc/bind/db.mondomaine.fr.inv";    };            };    view externe {            match-clients {                    any;                    };            recursion no;    zone "mondomaine.fr" {            type master;            file "/etc/bind/db.mondomaine.fr";    };    zone "31.121.91.in-addr.arpa" {            type master;            file "/etc/bind/db.mondomaine.fr.inv";    };            };

Testons la différence entre notre DNS sécurisé et un DNS mal configuré inet:/var/log # nslookup > server cxd15.com Default server: cxd15.com Address: 200.200.134.52#53 > www.free.fr Server:         cxd15.com Address:        200.200.134.52#53 Non-authoritative answer: Name:   www.free.fr Address: 212.27.48.10

Dans cet exemple on voit bien que la dns de la société (fictive) cxd15, donne l'ip correspondant à www.free.fr

Maintenant en utilisant notre serveur a partir de l'exterieur.

@@

inetgw:~ # nslookup > server ns.info.fr Default server: ns.info.fr Address: 91.100.30.206#53 > www.free.fr Server:         ns.info16.fr Address:        91.100.30.206#53 Non-authoritative answer: *** Can't find www.free.fr: No answer@@

Mais bien sur si on fait la meme requete sur notre serveur, mais à partir de notre réseau local.

@@

root@serveur:~# nslookup > www.free.fr Server:         127.0.0.1 Address:        127.0.0.1#53 Non-authoritative answer: Name:   www.free.fr Address: 212.27.48.10

@@

On voit bien que notre DNS est sécurisé et ne répond aux requetes récursives que lorsque c'est son propre réseau local (défini dans l'ACL lan) qui l'interroge.

PS: Les ip que j'ai utilisée sont fictives ainsi que leur nom de domaines associés.

Les commentaires sont fermés.