Suite a la decouverte ces derniers temps, de nombreuses erreurs d'implementation dans BIND. On optera pour version 8.2.3 minimum. De plus la version 9 de Bind implemente DNSSEC pour les zones signees et TSIG pour signer les requetes DNS, ce qui devrait resoudre a terme les differents problemes lies au DNS spoofing. Donc nous decidons d installer la version 9.2.1. Nous savons que BIND est capable de supporter de lourdes charges, le serveur F.root-servers.net utilisant bind 8.2.3 repond a plus de 272 millions de requetes DNS par jour.
Le numero de version s'obtient facilement :
Une possibilite est de definir le texte a renvoyer. Dans la rubrique options, il nous suffit de specifier
Mais cela a l'inconvenient de le masquer pour tout le monde. On peut ruser un peu plus en redefinissant la zone "chaos" :
Cette zone recouvre un ensemble d'information sur le serveur comme sa version VERSION.BIND ou ses auteurs authors.bind. Dans le fichier bind, on definit la classe chaos.
Ainsi lorsqu'un potentiel pirate cherche a obtenir la version de bind, sa tentative sera enregistree :
Et on pourra continuer a recuperer le numero de version en local.
Prenons le parti d'etre paranoiaque, interdisons tout par defaut.
"also-notify" doit contenir les DNS secondaires non officiels, cela permet de les prevenir immediatement si une mise a jour d'une zone est effectuee.
"allow-query" indique qui peut interroger le serveur pour une zone donnee.
Pour obtenir la liste des DNS primaires, il suffit d'executer la commande
Ils resolvent les adresses ip/noms pour lesquels le serveur DNS n'est ni primaire, ni secondaire.
La zone pour les requetes par defaut est la zone "." definie ci-dessous :
Dans certains cas d'architecture reseau ou pour des raisons de securite, on peut vouloir forcer un DNS interne a utiliser un serveur DNS bien specifique pour repondre aux requetes DNS. Dans ce cas-la, on impose cette contrainte dans les options :
Une zone de resolution inverse, adresse IP vers nom de machine, pour l'adresse de loopback se definit ainsi
Le serveur primaire doit etre interroger par tous mais n'autoriser que les dns secondaires a effectuer des transferts de zone.
Les ports inferieurs a 1024 sont des ports privilegies, c'est-a-dire que seuls les programmes
fonctionnant en tant que root peuvent les utiliser. Le port dedie aux serveurs DNS est le port
TCP/UDP 53 (domains).
Un mecanisme de securite est incorpore dans les versions modernes de bind qui lui permet,
une fois qu'il s'est attribue le port domains (53), de prendre l'identite d'un utilisateur
sans pouvoir, named generalement. Ainsi, en cas de faille de securite, le pirate prend
l'identite named et non root.
Cependant, le pirate possede desormais un acces a la machine, ou il est en mesure d'exploiter
des failles locales. L'idee est de le confiner dans une partie de l'arborescence, par exemple,
le repertoire /var/chroot-named ou se trouvent egalement les fichiers necessaires a bind.
Pour creer la prison, il faut commencer par etre root.
Syslogd supporte l'option "-a", donc il faut qu'il soit demarrer avec dans
/etc/rc.d/init.d/syslog :
Dans named.conf :
Les fichiers de log appartiennent a root.
Recuperation de la configuration
N'oublions pas que bind doit pouvoir ecrire dans les repertoires correspondant aux zones esclaves. Il faut donc les creer et les attribuer a l'utilisateur named, sans quoi il ne pourra pas recuperer les zones dont il est secondaire.
Soit on compile named et named-xfer en statique, soit on utilise les binaires existants et on copie les librairies dynamiques necessaires :
Cette derniere commande montre toutes les librairies dont bind a besoin pour fonctionner : chacune d'elle doit egalement etre presente dans la prison.
Dans /etc/rc.d/init.d/named, on signale que le demon tourne dans une prison :
L'option "-u" designe l'utilisateur sous lequel fonctionnera bind et l'option "-t" le repertoire dans lequel il s'execute, sa prison.
La securite TSIG permet de reduire les consequences de l'IP spoofing entre les DNS primaires et secondaires. Ils partagent une cle secrete dont le nom meme est secret, grenier-supersecret dans l'exemple. La cle est encodee en base 64 head -c 16 /dev/urandom | uuencode -m - et se definit ainsi dans les fichiers de configuration des serveurs concernes :
Dans la configuration du DNS maitre, on ajoute :
et pour les DNS secondaires, on met la meme chose mais avec l'adresse IP du serveur DNS
primaire.
Pour fonctionner, les horloges systemes des deux serveurs doivent etre synchronisees. Au besoin,
on peut les synchroniser par ntp. La confidentialite des cles est liee a la securite du serveur
le plus vulnerable.