Product SiteDocumentation Site

5.7. Sécurisation de BIND

Il y a différents problèmes qui peuvent être traités pour sécuriser le démon de serveur de domaine; problèmes similaires à ceux étudiés quand on sécurise n'importe quel service donné :

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[47]
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
Voilà ! Maintenant named ne s'exécute plus en tant que superutilisateur. Si vous voulez lire plus d'informations sur pourquoi BIND ne fonctionne pas en tant qu'utilisateur non superutilisateur sur les systèmes Debian, veuillez vérifier le système de suivi des bogues concernant BIND, en particulier les bogues http://bugs.debian.org/50013, http://bugs.debian.org/132582, http://bugs.debian.org/53550, http://bugs.debian.org/52745 et http://bugs.debian.org/128129. Vous pouvez contribuer à ces rapports de bogue si vous le désirez si vous pensez pouvoir ajouter des informations utiles.

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).
De plus, vous pouvez trouver plus d'informations concernant le chrootage de BIND dans le http://www.linuxdoc.org/HOWTO/Chroot-BIND-HOWTO.html (au sujet de BIND 9) et http://www.linuxdoc.org/HOWTO/Chroot-BIND8-HOWTO.html (au sujet de BIND 8). Ces mêmes documents devraient être disponibles par l'installation de doc-linux-text (version texte) ou doc-linux-html (version HTML). Un autre document utile est http://web.archive.org/web/20011024064030/http://www.psionic.com/papers/dns/dns-linux.
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[48] :
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[49] 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).
Pour plus d'informations sur la mise en place de chroots, consultez Section 5.10, « Paranoïa généralisée du suid et du chroot ».


[47] Notez que selon la version de BIND, l'option -g risque de ne pas être disponible, en particulier si vous utilisez bind9 avec Sarge (version 9.2.4).
[48] Cette configuration n'a pas encore été essayée pour les nouvelles versions de BIND.
[49] Sauf si vous utilisez l'option instdir lors de l'appel à dpkg mais alors la prison chroot peut être un petit peu plus complexe.