## page was renamed from sécuriser Bind
== Comment protéger bind9 sous Debian ==

Depuis [[Debian]] "Sarge", bind9 est automatiquement lancée sous l'utilisateur `bind` par défaut, mais toujours pas en `chroot`, ce qui serait pourtant une bonne idée du point de vue sécurité.

{{{
# stopper l'exécution de bind pendant son emprisonnement
/etc/init.d/bind9 stop

# créer la prison pour bind
mkdir -p /var/chroot/bind
cd /var/chroot/bind
mkdir -p dev etc var/cache var/run
cp -a /dev/log /dev/null /dev/random dev/
cp -p /etc/localtime etc/

# la configuration
mv /etc/bind etc/
chown -R root:bind etc/bind
chmod -R u=rwX,g=rX,o= etc/bind
ln -s /var/chroot/bind/etc/bind /etc/

# le cache
mv /var/cache/bind var/cache/
chown -R bind:bind var/cache/bind
chmod -R u=rwX,g=rX,o= var/cache/bind
ln -s /var/chroot/bind/var/cache/bind /var/cache/

# le pid
mv /var/run/bind var/run/
chown -R bind:bind var/run/bind/run
chmod -R u=rwX,g=rX,o= var/run/bind/run
ln -s /var/chroot/bind/var/run/bind /var/run/

# changer le répertoire personnel de bind vers sa future prison
usermod -d /var/chroot/bind bind

# modifier les options de demarrage de bind
sed -i '/^OPTIONS=/c OPTIONS="-u bind -t /var/chroot/bind"' /etc/default/bind9

# configurer sysklogd pour accepter les messages de logs depuis le bind emprisoné
[ -r /etc/init.d/sysklogd ] && sed -i '/^SYSLOGD=/s#"\(.*\)"#"\1 -a /var/chroot/bind/dev/log"#' /etc/default/sysklogd && /etc/init.d/sysklogd restart

# configurer syslog-ng pour accepter les messages de logs depuis le bind emprisoné
[ -r /etc/syslog-ng/syslog-ng.conf ] && sed -i '/unix-stream("\/dev\/log");/a\\t# bind9 chroot\n\tunix-stream("/var/chroot/bind/dev/log");' /etc/syslog-ng/syslog-ng.conf && /etc/init.d/syslog-ng restart

# configurer pour RSYSLOG pour accepter les messages de logs depuis le bind emprisonné
[ -r /etc/rsyslog.conf ] && echo "\$AddUnixListenSocket /var/chroot/bind/dev/log" > /etc/rsyslog.d/chroot-bind.conf

# enfin, redemarrer bind dans sa prison !
/etc/init.d/bind9 start
}}}

=== Vérifier que tout va bien ===

En surveillant le contenu du fichier '''/var/log/daemon.log''' qui ne doit pas contenir d'erreur ou de warning suite aux redemarrage des deux services.

En faisant un '''ps ax | grep named''', le résultat doit ressembler à cela :

{{{
# ps ax | grep named
17938 ?        Ss     0:00 /usr/sbin/named -u bind -t /var/chroot/bind
17939 ?        S      0:00 /usr/sbin/named -u bind -t /var/chroot/bind
17941 ?        S      0:00 /usr/sbin/named -u bind -t /var/chroot/bind
17942 ?        S      0:00 /usr/sbin/named -u bind -t /var/chroot/bind
17943 ?        S      0:00 /usr/sbin/named -u bind -t /var/chroot/bind
}}}

Et on peut aussi vérifier que le repertoire racine du processus '''named''' est bien devenu '''/var/chroot/bind''' :

{{{
# ls -l /proc/17938/root
lrwxrwxrwx    1 root     root            0 Jul 13 14:05 /proc/17938/root -> /var/chroot/bind
}}}

== Lien ==

Une bonne doc sur les autres aspects largement aussi importants (allow-transfer, allow-query) : [[http://www.security-labs.org/full-page.php3?page=411|Sécuriser un serveur de nom]] (a copier-coller et adapter ici si besoin).
----
CatégorieSécurité
CatégorieManuel
CatégorieDNS
CatégorieLogiciel