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).