5.7.1. Configuration de BIND pour éviter de mauvaises utilisations
				Vous devriez restreindre certains renseignements donnés par le serveur DNS aux clients extérieurs pour l'empêcher d'être utilisé pour obtenir des informations de valeur sur votre organisation que vous ne voudriez pas divulguer. Cela inclut l'ajout des options suivantes : allow-transfer, allow-query, allow-recursive et version. Vous pouvez soit limiter cela dans la section globale (pour que cela s'applique à toutes les zones servies) ou individuellement par zone. Cette information est documentée dans le paquet bind-doc, consultez /usr/share/doc/bind/html/index.html en plus à ce sujet une fois que le paquet est installé.
			
				Imaginez que votre serveur (un serveur avec plusieurs adresses de base) est connecté à Internet et à votre réseau interne (votre adresse IP interne est 192.168.1.2), vous ne voulez fournir aucun service à Internet et vous voulez juste autoriser les consultations DNS à partir de vos hôtes internes. Vous pourriez le restreindre en incluant dans 
/etc/bind/named.conf:
options {
            allow-query { 192.168.1/24; } ;
            allow-transfer { none; } ; 
            allow-recursion { 192.168.1/24; } ;
            listen-on { 192.168.1.2; } ;
            forward { only; } ;
            forwarders { A.B.C.D; } ;
};
			
				L'option listen-on lie uniquement le DNS à l'interface ayant une adresse interne, mais, même si cette interface est la même que l'interface qui permet la connexion à Internet (par l'utilisation de NAT, par exemple), les requêtes ne seront acceptées que si celles-ci proviennent d'hôtes internes. Si le système est constitué de plusieurs interfaces et que le listen-on n'est pas présent, seuls les utilisateurs internes pourront émettre des requêtes, mais, puisque le port restera accessible à des attaquants externes, ils pourront essayer de faire tomber (ou exploiter une attaque de débordement de tampon sur) le serveur DNS. Vous pouvez même le mettre uniquement en écoute sur l'adresse 127.0.0.1 si vous ne désirez offrir le service à personne d'autre que vous même.
			
				L'enregistrement version.bind dans la classe chaos contient la version du processus bind actuellement en cours d'exécution. Cette information est souvent utilisée par des scanners automatisés et des individus malveillants qui souhaitent déterminer si un 
bind est vulnérable à une attaque spécifique. En fournissant des informations fausses ou pas d'informations du tout, on limite la probabilité qu'un serveur soit attaqué sur la base de la version qu'il publie. Pour fournir votre propre version, utilisez la directive 
version de la manière suivante :
options {
        ... diverses options ici ...
        version "Not available.";
 };
			
				Changer l'enregistrement version.bind ne fournit pas actuellement de protection contre les attaques, mais cela devrait être considéré comme une protection utile.
			
				Un fichier de configuration 
named.conf d'exemple pourrait être me suivant :
acl internal {
        127.0.0.1/32;           // localhost
        10.0.0.0/8;             // interne
        aa.bb.cc.dd;            // IP eth0
};
acl friendly {
        ee.ff.gg.hh;            // DNS escalve
        aa.bb.cc.dd;            // IP eth0
        127.0.0.1/32;           // localhost
        10.0.0.0/8;             // interne
};
options {
        directory "/var/cache/bind";
        allow-query { internal; };
        allow-recursion { internal; };
        allow-transfer { none; };
};
// À partir d'ici jusqu'à la zone mysite.bogus
// est dans l'ensemble non modifié des valeurs par défaut Debian
logging {
        category lame-servers { null; };
        category cname { null; };   
};
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";
};
// Zones ajoutées moi-même
zone "mysite.bogus" {
        type master;
        file "/etc/bind/named.mysite";
        allow-query { any; };
        allow-transfer { friendly; };
};
			
				Veuillez vérifier (de nouveau) le système de suivi des bogues (BTS) à propos de BIND, en particulier le 
http://bugs.debian.org/94760. Vous pouvez contribuer si vous le désirez au rapport de bogue si vous pensez pouvoir ajouter des informations utiles.
			
5.7.2. Changer l'utilisateur de BIND
				Concernant la limitation des privilèges de BIND vous devez être conscient que si un utilisateur différent du superutilisateur exécute BIND, alors BIND ne peut pas détecter de nouvelles interfaces automatiquement, par exemple, quand vous insérez une carte PCMCIA dans un portable. Consultez le fichier 
README.Debian du répertoire de documentation de named (
/usr/share/doc/bind/README.Debian) pour plus d'informations sur ce problème. De nombreux problèmes de sécurité concernant BIND ont été récemment découverts, donc le changement d'utilisateur est utile si possible, cependant si vous désirez le faire de façon automatique, vous pouvez essayer le script fourni dans 
Section B.5, « Exemple de script pour changer l'installation par défaut de BIND ».
			
				Remarquez, de toute façon, que cela ne concerne que la version 8 de BIND. Dans les paquets Debian de la version 9 (depuis la version 9.2.1-5, disponible avec Sarge), l'utilisateur bind est créé et utilisé en configurant la variable OPTIONS de /etc/default/bind9. Si vous utilisez BIND version 9 et que le démon de serveur de noms ne fonctionne pas avec l'utilisateur bind, vérifiez les configurations de ce fichier.
			
				Pour démarrer BIND sous un autre utilisateur, tout d'abord créez un utilisateur et un groupe séparé (ce n'est 
pas une bonne idée d'utiliser nobody ou nogroup pour chaque service ne devant pas tourner en tant que superutilisateur). Dans cet exemple, l'utilisateur et le groupe 
named seront utilisés. Vous pouvez faire cela en tapant :
addgroup named
adduser --system --home /home/named --no-create-home --ingroup named \
      --disabled-password --disabled-login named
			
				Notez que l'utilisateur 
named sera très restreint. Si vous désirez, pout toute raison, avoir une configuration moins restrictive, utilisez :
adduser --system --ingroup named named
			
				Maintenant vous pouvez soit éditer, à l'aide de votre éditeur favori, 
/etc/init.d/bind et modifiez les lignes commençant par
start-stop-daemon --start
				en
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named
			
				soit modifier (créez-le s'il n'existe pas) le fichier de configuration par défaut (
/etc/default/bind pour BIND en version 8) et introduisez ceci :
OPTIONS="-u named -g named"
				Modifiez les permissions des fichiers utilisés par BIND, y compris 
/etc/bind/rndc.key :
-rw-r-----    1 root     named          77 Jan  4 01:02 rndc.key
				et l'endroit où BIND crée son fichier pid en utilisant, par exemple 
/var/run/named au lieu de 
/var/run :
$ mkdir /var/run/named
$ chown named.named /var/run/named
$ vi /etc/named.conf
[ ... mettez le fichier de configuration à jour en utilisant ce nouvel
emplacement ...]
options { ...
        pid-file "/var/run/named/named.pid";
};
[ ... ]
			
				Pour éviter également d'exécuter quoi que ce soit en tant que superutilisateur, modifiez la ligne 
reload du script init.d en substituant :
reload)
       /usr/sbin/ndc reload
			
				par :
reload)
        $0 stop
        sleep 1
        $0 start
			
				Remarque : selon la version de Debian, vous pouvez devoir changer la ligne restart également. Cela a été corrigé dans la version 1:8.3.1-2 de BIND pour Debian.
			
				Il ne reste plus qu'à redémarrer BIND à l'aide de /etc/init.d/bind restart, puis rechercher dans le journal système les deux entrées suivantes :
			
				
Sep  4 15:11:08 nexus named[13439]: group = named
Sep  4 15:11:08 nexus named[13439]: user = named
			 5.7.3. Chrooter le serveur de domaine
				Pour atteindre une sécurité de BIND maximale, construisez maintenant une prison chroot (consultez 
Section 5.10, « Paranoïa généralisée du suid et du chroot ») autour du démon. Il y a un moyen facile de faire cela : l'option 
-t (consultez la page de manuel 
named(8) ou la page 100 de la 
http://www.nominum.com/content/documents/bind9arm.pdf). Cela fera que BIND se chrootera lui-même dans le répertoire donné sans que vous ayez besoin de configurer une prison chroot et de vous inquiéter au sujet des bibliothèques dynamiques. Les seuls fichiers qui doivent être dans cette prison chroot :
dev/null
etc/bind/       - doit contenir named.conf et toutes les zones du serveur
sbin/named-xfer - si vous faites du transfert de nom
var/run/named/  - devrait contenir le PID et le cache du serveur de nom
                  (s'il existe), ce répertoire doit être accessible en
                  écriture à l'utilisateur named
var/log/named   - si vous configurez le journal vers un fichier, doit
                  être accessible en écriture à l'utilisateur named
dev/log         - syslogd devrait écouter ici si named est configuré
                  pour journaliser en l'utilisant
			
				Pour que le démon BIND fonctionne correctement il a besoin de permissions dans les fichiers named. C'est une tâche facile car les fichiers de configuration sont toujours dans /etc/named. Prenez en compte qu'il n'a besoin que d'un accès en lecture seule aux fichiers de zone, sauf s'il s'agit un serveur de nom secondaire ou serveur cache. Si c'est le cas vous devrez permettre la lecture et l'écriture aux zones nécessaires (pour que les transferts de zone à partir du serveur primaire fonctionnent).
			
				Si vous configurez une véritable prison chroot (c'est-à-dire pas seulement l'option 
-t) pour BIND dans Debian, assurez-vous qu'elle contient les fichiers suivants
 :
dev/log - syslogd devrait écouter ici
dev/null
etc/bind/named.conf 
etc/localtime
etc/group - avec une seule ligne: "named:x:GID:"
etc/ld.so.cache - généré avec ldconfig
lib/ld-2.3.6.so
lib/libc-2.3.6.so
lib/ld-linux.so.2 - lié symboliquement à ld-2.3.6.so  
lib/libc.so.6 - lié symboliquement à libc-2.3.6.so
sbin/ldconfig - pourra être effacé après la configuration du chroot
sbin/named-xfer - si vous faites des transferts de nom
var/run/
			
				Modifiez aussi l'écoute de syslogd sur $CHROOT/dev/log pour que le serveur de nom puisse écrire des entrées de journalisation système dans le journal du système local.
			
				Pour éviter des problèmes avec les bibliothèques dynamiques, vous pouvez compiler BIND statiquement. Vous pouvez utiliser 
apt-get pour cela avec l'option 
source. Il peut même récupérer les paquets dont vous avez besoin pour le compiler correctement. Il vous faudrait faire quelque chose comme :
$ apt-get source bind
# apt-get build-dep bind
$ cd bind-8.2.5-2
  (modifier src/port/linux/Makefile pour que CFLAGS contienne
   l'option « -static »)
$ dpkg-buildpackage -rfakeroot -uc -us
$ cd ..
# dpkg -i bind-8.2.5-2*deb
			
				Après l'installation, vous devrez déplacer des fichiers dans la prison chroot
 vous pouvez conserver les scripts 
init.d dans 
/etc/init.d pour que le système lance automatiquement le serveur de domaine, mais éditez les pour ajouter 
--chroot /location_of_chroot dans les appels à 
start-stop-daemon dans ces scripts ou utilisez l'option 
-t de BIND en la configurant dans l'argument OPTIONS du fichier de configuration 
/etc/default/bind (pour la version 8) ou 
/etc/default/bind9 (pour la version 9).