<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
<!ENTITY howto "http://www.traduc.org/docs/howto/lecture/">
<!ENTITY traduc "http://www.traduc.org">
]>
<article lang="fr">
<articleinfo>
<title>
Guide pratique d'utilisation de BIND en environnement restreint
</title>
<subtitle>
Adaptation française du guide pratique <foreignphrase>Chroot-BIND
HOWTO</foreignphrase>
</subtitle>
<author>
<firstname>Scott</firstname>
<surname>Wunsch</surname>
<email>scott CHEZ wunsch POINT org</email>
</author>
<othercredit role="traduction" class="translator">
<firstname>Vincent</firstname>
<surname>Loupien</surname>
<contrib>Adaptation française</contrib>
<email>vincent POINT loupien CHEZ neuf POINT fr</email>
</othercredit>
<othercredit role="relecture" class="translator">
<firstname>Benoît</firstname>
<surname>Rouits</surname>
<contrib>Relecture de la version française</contrib>
<email>brouits CHEZ free POINT fr</email>
</othercredit>
<othercredit role="relecture" class="translator">
<firstname>Jean-Philippe</firstname>
<surname>Guérard</surname>
<contrib>Relecture de la version française</contrib>
<email>fevrier CHEZ tigreraye POINT org</email>
</othercredit>
<othercredit role="publication" class="copyeditor">
<firstname>Jean-Philippe</firstname>
<surname>Guérard</surname>
<contrib>Préparation de la publication de la v.f.</contrib>
<email>fevrier CHEZ tigreraye POINT org</email>
</othercredit>
<releaseinfo>Version : 1.5.fr.1.0</releaseinfo>
<pubdate>20 juillet 2005</pubdate>
<revhistory>
<revision>
<revnumber>1.5.fr.1.0</revnumber>
<date>2005-07-30</date>
<authorinitials>VL, BR, JPG</authorinitials>
<revremark>
Version française relue par Benoît Rouits.
</revremark>
</revision>
<revision>
<revnumber>1.5.fr.0.9</revnumber>
<date>2004-06-28</date>
<authorinitials>VL, JPG</authorinitials>
<revremark>
Première version française (non relue).
</revremark>
</revision>
<revision>
<revnumber>1.5</revnumber>
<date>2001-12-01</date>
<authorinitials>SW</authorinitials>
</revision>
</revhistory>
<abstract>
<para>
Ce document décrit l'installation du serveur de noms BIND 9 dans un
environnement d'exécution restreint en tant qu'utilisateur non root.
Cette configuration offre une meilleure sécurité et permet de limiter
les effets potentiels d'une compromission. Ce document a été mis à jour
pour la version 9 de BIND ; si vous utilisez toujours la
version 8 de BIND, référez-vous plutôt au <quote>Guide pratique
d'utilisation de BIND 8 en environnement restreint</quote>.
</para>
</abstract>
</articleinfo>
<section>
<title>Introduction</title>
<para>
Ce document est le guide pratique de BIND en environnement
restreint ; reportez-vous à la <xref linkend="Ou"/> pour trouver la
version la plus récente de ce document. Nous supposerons que vous savez
déjà configurer et utiliser BIND (le serveur de Noms de Domaines
Internet de Berkeley). Si ce n'est pas le cas, je vous recommande de
commencer par lire le guide pratique du DNS (DNS HOWTO). Nous
supposerons également que vous avez une connaissance suffisante de la
compilation et de l'installation d'un logiciel sur un système de type
Unix.
</para>
<section>
<title>Objet de ce document</title>
<para>
Ce document présente quelques précautions de sécurité supplémentaires
applicables lors de l'installation de BIND. Il explique comment
configurer BIND de sorte qu'il réside dans un environnement restreint,
ce qui signifie qu'il ne peut voir ou accéder aux fichiers à l'extérieur
de sa propre arborescence. Nous le configurerons également pour
s'exécuter en tant qu'utilisateur non root.
</para>
<para>
Le principe d'un environnement restreint est assez simple. Lorsque vous
exécutez BIND (ou tout autre processus) dans un environnement restreint
(c'est-à-dire en utilisant pour le système de fichier une racine
différente — d'où le nom de la commande utilisée
<quote><foreignphrase>chroot</foreignphrase></quote>, c'est-à-dire, en
anglais, <quote>changer la racine</quote>), le processus ne peut tout
simplement pas voir les autres parties du système de fichiers (situées
hors de son environnement). Vous avez probablement déjà rencontré un
environnement restreint auparavant, si vous avez déjà utilisé un client
<command>ftp</command> pour vous connecter à un serveur de fichier
public.
</para>
<para>
Étant donné que le processus d'exécution en environnement restreint est
beaucoup plus simple avec BIND 9, j'ai commencé à développer
légèrement ce document, pour y inclure des astuces plus générales sur la
manière de sécuriser une installation BIND. Néanmoins, ce document n'est
pas (et ne souhaite pas devenir) une référence complète pour la
sécurisation de BIND. Faire uniquement ce qui est décrit dans ce
document ne suffit pas à sécuriser un serveur de nom !
</para>
</section>
<section>
<title>Pourquoi ?</title>
<para>
Le principe de l'exécution de BIND en environnement restreint est de
limiter le degré d'accès dont pourrait bénéficier un individu
malveillant en exploitant une des vulnérabilités de BIND. C'est pour la
même raison que nous exécutons BIND en tant qu'utilisateur non root.
</para>
<para>
Ceci devrait être considéré comme un supplément aux précautions normales
de sécurité (exécution de la dernière version, utilisation des listes de
contrôle d'accès, et cætera), et non comme une solution de remplacement
à ces dernières.
</para>
<para>
Si la sécurité du DNS vous intéresse, quelques autres produits
pourraient également vous intéresser. Compiler BIND avec <ulink
url="http://www.immunix.org/stackguard.html">StackGuard</ulink> peut
être une bonne idée pour assurer une plus grande protection. Son
utilisation est simple ; elle équivaut à utiliser un gcc standard.
Il existe aussi une alternative sécurisée à BIND, <ulink
url="http://cr.yp.to/dnscache.html">DNScache</ulink>, écrit par Dan
Bernstein. Dan est l'auteur de qmail et DNScache semble en suivre la même
philosophie.
</para>
</section>
<section id="Ou">
<title>Où ?</title>
<para>
La dernière version française de ce document est toujours disponible sur
le site du projet <ulink url="&traduc;">Traduc.org</ulink> :
<ulink url="&howto;Chroot-BIND8-HOWTO.html"/>.
</para>
<para>
La dernière version originale de ce document est toujours disponible à
partir du site Web des Utilisateurs de Linux et de logiciels libres de
Regina, Sask. : <ulink
url="http://www.losurs.org/docs/howto/Chroot-BIND.html"/>.
</para>
<para>
Il existe maintenant une traduction japonaise de ce document, maintenue
par
<email>nakano CHEZ apm POINT seikei POINT ac POINT jp</email>.
Elle est disponible à l'adresse <ulink
url="http://www.linux.or.jp/JF/JFdocs/Chroot-BIND-HOWTO.html"/>. BIND
est disponible à l'adresse de l'<ulink
url="http://www.isc.org/">Internet Software Consortium</ulink> à
l'adresse <ulink url="http://www.isc.org/bind.html"/>. Au moment de la
publication de ce document, la version courante de BIND 9 est la
version 9.2.0. La version 9 de BIND est sortie depuis
longtemps et est déjà largement employée en production. Néanmoins,
nombre de traditionalistes préfèrent encore utiliser BIND 8. Si
c'est votre cas, reportez-vous à mon <quote>Guide pratique de
l'utilisation de BIND 8 en environnement restreint</quote>
(disponible au même endroit) qui vous expliquera comment l'exécuter en
environnement restreint. Cependant, soyez conscient que BIND 8 est
plus difficilement exécutable en environnement restreint. Gardez à
l'esprit qu'il existe des trous de sécurité <emphasis>connus</emphasis>
sur toutes les versions de BIND. Assurez-vous que vous exécutez bien la
dernière version !
</para>
</section>
<section>
<title>Comment ?</title>
<para>
J'ai écrit ce document en me basant sur mon expérience du paramétrage de
BIND dans un environnement restreint. Dans mon cas, j'avais déjà un BIND
en exploitation sous la forme d'un paquet fourni par de ma distribution
Linux. Je suppose que beaucoup d'entre-vous êtes dans la même situation,
que vous allez juste récupérer et modifier les fichiers de configuration
provenant de votre installation actuelle de BIND, puis désinstaller
l'ancien paquet avant d'installer le nouveau. Ne désinstallez pas le
paquet tout de suite ; nous pourrions avoir besoin d'y récupérer
quelques fichiers.
</para>
<para>
Si vous n'êtes pas dans ce cas, vous devriez néanmoins être capable de
comprendre ce document. La seule différence est que, lorsque je parle de
copier un fichier existant, vous devrez d'abord le créer vous-même. Le
guide pratique du DNS pourra vous être utile pour cela.
</para>
</section>
<section>
<title>Mise en garde</title>
<para>
Cette procédure a fonctionné pour moi, sur mon système. Vous pourriez
avoir à la modifier. Ce n'est qu'une façon d'aborder la
question ; il y a d'autres moyens d'arriver à la même solution
(cependant l'approche restera la même). Il s'est juste trouvé que ma
première tentative a fonctionné, et j'ai donc tout noté.
</para>
<para>
À ce jour, mon expérience de BIND se limite à l'installation sur des
serveurs Linux. Cependant, la plupart des instructions de ce document
devraient être facilement applicables à d'autres saveurs d'UNIX et
j'essaierai d'indiquer les éventuelles différences dont j'aurais
connaissance. J'ai également reçu des suggestions de personnes utilisant
d'autres distributions et d'autres plates-formes, et j'ai essayé
d'incorporer leurs commentaires lorsque cela était possible.
</para>
<para>
Si vous utilisez Linux, vous devez être sûr d'utiliser un noyau 2.4
avant d'essayer ceci. Le paramètre <literal>-u</literal> (exécution par
un utilisateur non root) requiert cette version du noyau.
</para>
</section>
</section>
<section>
<title>Préparation de l'environnement restreint</title>
<section>
<title>Création d'un utilisateur</title>
<para>
Comme cela est mentionné dans l'introduction, il n'est pas conseillé de
faire fonctionner BIND sous le compte root. Ainsi, avant de commencer,
créons un utilisateur spécifique pour BIND. Notez que vous ne devez
jamais employer un utilisateur générique comme <literal>nobody</literal>
pour cela. Ainsi, quelques distributions, comme SuSE et Mandrake Linux
ont commencé à fournir un utilisateur spécifique (généralement appelé
<literal>named</literal>) ; si vous le souhaitez, vous pouvez
tout simplement adapter cet utilisateur à nos desseins. Ceci exige
l'ajout d'une ligne comme celle qui suit dans
<filename>/etc/passwd</filename> :
</para>
<screen>
named:x:200:200:Serveur de noms:/chroot/named:/bin/false
</screen>
<para>
Et d'une ligne de ce type dans <filename>/etc/group</filename> :
</para>
<screen>
named:x:200:
</screen>
<para>
Ceci crée pour BIND un utilisateur et un groupe appelés
<literal>named</literal>. Assurez-vous que l'UID et le GID (tous deux
valant 200 dans cet exemple) sont uniques sur votre système.
L'interpréteur de commande est mis à <literal>/bin/false</literal> car
cet utilisateur n'aura jamais besoin de se connecter.
</para>
</section>
<section>
<title>Arborescence de répertoires</title>
<para>
Nous devons maintenant mettre en place l'arborescence de répertoires que
nous allons utiliser pour l'environnement restreint d'exécution de BIND.
Elle peut se situer n'importe où dans votre système de fichiers ;
si vous êtes vraiment paranoïaque, vous pourrez même la placer dans un
volume séparé. Je supposerai que vous allez employer <filename
class="directory">/chroot/named</filename>. Commençons en créant
l'arborescence de répertoires suivante :
</para>
<screen>
/chroot
+-- named
+-- dev
+-- etc
| +-- namedb
| +-- slave
+-- var
+-- run
</screen>
<para>
Si vous utilisez la commande GNU <command>mkdir</command> (tel que
présente sur les systèmes Linux), vous pourrez créer l'arborescence de
répertoires ainsi :
</para>
<screen>
# mkdir -p /chroot/named
# cd /chroot/named
# mkdir -p dev etc/namedb/slave var/run
</screen>
</section>
<section>
<title>Mise en place des données de BIND</title>
<para>
Si vous avez déjà fait une installation conventionnelle de BIND et si
vous l'utilisez, votre fichier <filename>named.conf</filename> et vos
fichiers de zones existent déjà. Ces fichiers doivent être déplacés (ou
copiés pour plus de sûreté) dans l'environnement restreint, de sorte que
BIND puisse les atteindre. <filename>named.conf</filename> ira dans
<filename>/chroot/named/etc</filename>, et les fichiers de zone pourront
aller dans <filename>/chroot/named/etc/namedb</filename>. Par
exemple :
</para>
<screen>
# cp -p /etc/named.conf /chroot/named/etc/
# cp -a /var/named/* /chroot/named/etc/namedb/
</screen>
<para>
BIND a normalement besoin d'écrire dans le répertoire
<filename>namedb</filename>, mais pour renforcer la sécurité, nous ne
l'autoriserons pas à le faire. Si votre serveur de nom est esclave pour
une zone quelconque, il aura besoin de mettre à jour ces fichiers de
zones, ce qui veut dire nous devrons les enregistrer dans un répertoire
séparé, auquel BIND aura accès.
</para>
<screen>
# chown -R named:named /chroot/named/etc/namedb/slave
</screen>
<para>
Gardez à l'esprit que vous devrez déplacer toutes vos zones esclaves
dans ce répertoire et que vous devez mettre à jour votre
<filename>named.conf</filename> en conséquence.
</para>
<para>
BIND aura aussi besoin d'écrire dans le répertoire
<filename>/var/run</filename>, pour y mettre ses fichiers pid et ses
fichiers de statistiques, donc permettons-lui de le faire :
</para>
<screen>
# chown named:named /chroot/named/var/run
</screen>
</section>
<section>
<title>Fichiers de support système</title>
<para>
Lorsque BIND s'exécute dans l'environnement restreint, il ne peut plus
<emphasis>du tout</emphasis> accéder aux fichiers situés hors de
celui-ci. Cependant, il a besoin d'accéder à quelques fichiers clefs,
bien que leur nombre soit bien moindre que ce dont BIND 8 avait
besoin.
</para>
<para>
Un fichier dont BIND aura besoin à l'intérieur de sa prison est le bon
vieux <filename class="devicefile">/dev/null</filename>. Notez que la
commande exacte nécessaire pour créer ce fichier spécial peut varier de
système à système ; vérifiez le script
<filename>/dev/MAKEDEV</filename> pour vous en assurer. Quelques
systèmes peuvent également exiger <filename>/dev/zero</filename>, que
nous pourrons créer de la même façon. Il a été mentionné que les version
préliminaires de BIND 9.2.0 ont maintenant également besoin de
<filename>/dev/random</filename>. Pour la plupart des systèmes Linux,
nous pourrons employer les commandes suivantes :
</para>
<screen>
# mknod /chroot/named/dev/null c 1 3
# mknod /chroot/named/dev/random c 1 8
# chmod 666 /chroot/named/dev/{null,random}
</screen>
<para>
Pour FreeBSD 4.3, ce sera :
</para>
<screen>
# mknod /chroot/named/dev/null c 2 2
# mknod /chroot/named/dev/random c 2 3
# chmod 666 /chroot/named/dev/{null,random}
</screen>
<para>
Vous aurez besoin de disposer d'un autre fichier dans le répertoire
<filename>/etc</filename> de l'environnement restreint. Vous devrez
copier <filename>/etc/localtime</filename> (nommé
<filename>/usr/lib/zoneinfo/localtime</filename> sur certains systèmes),
afin que BIND puisse enregistrer les évènements avec un horodatage
correct. La commande suivante s'en chargera :
</para>
<screen>
# cp /etc/localtime /chroot/named/etc/
</screen>
</section>
<section id="logging">
<title>Journalisation des évènements</title>
<para>
BIND a beau être prisonnier de son environnement restreint,
contrairement à un prisonnier ordinaire, il ne peut écrire son journal
sur les murs de sa cellule <literal>:-)</literal> Normalement, BIND
enregistre un journal des évènements grâce à
<application>syslogd</application>, le démon de journalisation système.
Cependant, ce type de journalisation est effectué en envoyant les
enregistrements d'évènements vers le connecteur (<foreignphrase
lang="en">socket</foreignphrase>) spécial
<filename>/dev/log</filename>. Puisqu'elle se trouve désormais à
l'extérieur de l'environnement restreint, BIND ne peut plus l'employer.
Heureusement, il existe quelques solutions pour contourner le problème.
</para>
<section>
<title>La solution idéale</title>
<para>
La solution idéale de ce dilemme exige une version raisonnablement
récente de <application>syslogd</application> qui prenne en charge le
paramètre <option>-a</option> introduit par OpenBSD. Reportez-vous à la
page de manuel de votre
<citerefentry>
<refentrytitle>syslogd</refentrytitle>
<manvolnum>8</manvolnum>
</citerefentry>
pour vérifier si elle offre cette option. Si c'est la cas, la seule
chose que vous ayez à faire est d'ajouter le paramètre
<quote><literal>-a /chroot/named/dev/log</literal></quote> à la ligne de
commande utilisée pour lancer <application>syslogd</application>. Sur
les systèmes qui utilisent un init SysV complet (ce qui inclut la
plupart des distributions Linux), vous pouvez faire cela en modifiant le
fichier <filename>/etc/rc.d/init.d/syslog</filename>. Par exemple, sur
mon système Linux Red Hat, j'ai changé la ligne
</para>
<screen>
daemon syslogd -m 0
</screen>
<para>
en
</para>
<screen>
daemon syslogd -m 0 -a /chroot/named/dev/log
</screen>
<para>
Il est intéressant de noter qu'à partir de la Red Hat 7.2, Red Hat a
apparemment rendu ce processus plus facile. Il y a maintenant un fichier
appelé <filename>/etc/sysconfig/syslog</filename> dans lequel on peut
définit des paramètres supplémentaires pour syslogd. Les systèmes
OpenLinux de Caldera utilisent un démon de lancement appelé
<application>ssd</application>, qui lit la configuration depuis
<filename>/etc/sysconfig/daemons/syslog</filename>. Il vous suffit de
modifier la ligne d'options pour qu'elle ressemble à ceci :
</para>
<screen>
OPTIONS_SYSLOGD="-m 0 -a /chroot/named/dev/log"
</screen>
<para>
De la même façon sur les systèmes SuSE, il m'a été indiqué que le
meilleur endroit pour ajouter ce paramètre est le fichier
<filename>/etc/rc.config</filename>. Changez la ligne
</para>
<screen>
SYSLOGD_paraMS=""
</screen>
<para>
en
</para>
<screen>
SYSLOGD_paraMS="-a /chroot/named/dev/log"
</screen>
<para>
devrait faire l'affaire. Enfin, le dernier mais non le moindre,
pour FreeBSD 4.3, il suffit apparemment de modifier le fichier
<filename>rc.conf</filename> et d'y ajouter :
</para>
<screen>
syslogd_flags="-s -l /chroot/named/dev/log"
</screen>
<para>
Le <option>-s</option> est là pour des raisons de sécurité, et fait
partie des paramètres par défaut. Le <option>-l</option> doit être suivi
d'un chemin local, dans lequel on souhaite placer une autre interface de
journalisation. Une fois que vous avez compris comment faire cette
modification sur votre système, il vous suffira de redémarrer
<application>syslogd</application>, que cela soit en le tuant (avec un
<command>kill</command>) et en le relançant (avec les paramètres
supplémentaires) ou en employant le script d'init SysV qui le fera pour
vous :
</para>
<screen>
# /etc/rc.d/init.d/syslog stop
# /etc/rc.d/init.d/syslog start
</screen>
<para>
Une fois redémarré, vous devriez voir dans
<filename>/chroot/named/dev</filename> une entrée appelée
<filename>log</filename> qui ressemble à ceci :
</para>
<screen>
srw-rw-rw- 1 root root 0 Mar 13 20:58 log
</screen>
</section>
<section>
<title>L'autre solution</title>
<para>
Si vous avez un ancien <application>syslogd</application>, vous devrez
trouver une autre façon d'écrire dans le journal des évènements. Il
existe quelques programmes pour cela, comme
<application>holelogd</application>, qui est conçu pour agir comme un
serveur mandataire en acceptant les entrées d'évènements du BIND en
environnement restreint pour les passer au véritable connecteur
<filename>/dev/log</filename>. Vous pouvez aussi tout simplement
configurer BIND pour journaliser les évènements dans un fichier au lieu
de les passer à syslog. Reportez-vous à la documentation de BIND pour
plus d'informations si vous choisissez d'utiliser cette méthode.
</para>
</section>
</section>
<section id="perm">
<title>Resserrer les permissions</title>
<para>
Tout d'abord, n'hésitez à restreindre à l'utilisateur
<literal>root</literal> l'accès à la totalité du répertoire
<filename>/chroot</filename>. Bien sur, tout le monde ne voudra pas
faire cela, particulièrement si cela indisposait d'autres logiciels
installés dans la même arborescence.
</para>
<screen>
# chown root /chroot
# chmod 700 /chroot
</screen>
<para>
Vous pouvez aussi sans danger restreindre l'accès de
<filename>/chroot/named</filename> à l'utilisateur
<literal>named</literal>.
</para>
<screen>
# chown named:named /chroot/named
# chmod 700 /chroot/named
</screen>
<para>
Pour renforcer un peu plus la sécurité, sur les systèmes Linux utilisant
le système de fichier ext2, nous pouvons rendre certains fichiers et
répertoires immuables, en utilisant l'utilitaire
<literal>chattr</literal>.
</para>
<screen>
# cd /chroot/named
# chattr +i etc etc/localtime var
</screen>
<para>
De même, sur FreeBSD 4.3, <command>chflags</command> est l'outil à
examiner pour rendre certains fichiers immuables. À titre d'exemple, ce
qui suit devrait rendre immuable le contenu du répertoire
<filename>/chroot/named/etc</filename> :
</para>
<screen>
# chflags schg /chroot/named/etc/*(*).
</screen>
<para>
Il serait pratique de pouvoir faire la même chose sur le répertoire
<filename>dev</filename>, mais malheureusement cela empêcherait
<application>syslogd</application> de créer son connecteur
<filename>dev/log</filename>. Vous pourrez aussi choisir de positionner
le bit immuable sur d'autres fichiers de votre prison, comme par exemple
vos fichiers de zone primaire, à condition qu'ils ne soient pas supposés
changer.
</para>
</section>
</section>
<section id="compiling">
<title>Compiler et installer votre beau BIND tout neuf</title>
<section>
<title>Compiler</title>
<para>
Compiler BIND 9 pour l'utiliser dans un environnement restreint est
une expérience plus plaisante que cela ne l'était avec BIND 8. En
fait, vous n'avez rien de spécial à faire ; le classique
<userinput>./configure && make</userinput> suffira.
Gardez à l'esprit que, sur des systèmes Linux, si vous voulez activer la
compatibilité IPv6 de BIND (<option>--enable-ipv6</option>), vous devrez
disposer de versions correspondantes du noyau et de la bibliothèque
glibc. Si vous avez un noyau 2.2, vous aurez besoin de la
glibc 2.1. Si vous avez un noyau 2.4, vous avez besoin de la
glibc 2.2. BIND est plutôt pointilleux à ce propos.
</para>
</section>
</section>
<section id="installing">
<title>Installer votre beau BIND tout neuf</title>
<para>
Vous devez aussi savoir que, si vous avez déjà installé BIND, par
exemple en utilisant un paquet RPM, vous devrez probablement le
désinstaller avant d'installer votre nouvelle version. Sur un système
Red Hat, cela implique probablement de désinstaller les paquets
<literal>bind</literal> et <literal>bind-utils</literal>, et peut-être
aussi <literal>bind-devel</literal> et
<literal>caching-nameserver</literal>, si vous les avez.
</para>
<para>
Vous devriez sauvegarder une copie du script d'init (en général
<literal>/etc/rc.d/init.d/named</literal>), s'il y a en un, avant la
désinstallation ; ce sera utile plus tard.
</para>
<para>
Si vous réalisez une mise à jour depuis une ancienne version de BIND,
tel que BIND 8, vous devriez lire le document de migration contenu
dans le fichier <filename>doc/misc/migration</filename> du paquet source
de BIND. Ce document ne traite pas du tout de la migration ; il
part simplement de l'hypothèse que vous remplacez une installation
existante et fonctionnelle de BIND 9.
</para>
<section>
<title>Installer les binaires</title>
<para>
C'est la partie facile :-) Lancez juste <userinput>make
install</userinput> et laissez-le tout faire pour vous. Et voilà, c'est
aussi simple que cela.
</para>
</section>
<section>
<title>Mise en place du script d'init</title>
<para>
Si vous avez un script d'init provenant de votre distribution, le mieux
serait probablement de simplement le modifier pour exécuter le nouveau
binaire, avec les paramètres appropriés. Les paramètres sont…
<emphasis>(roulement de tambour s'il vous plaît…)</emphasis>
</para>
<itemizedlist>
<listitem><para>
<option>-u named</option>, pour exécuter BIND avec l'utilisateur
<literal>named</literal> , plutôt que <literal>root</literal>.
</para></listitem>
<listitem><para>
<option>-t /chroot/named</option>, pour que BIND s'exécute dans
l'environnement restreint que nous avons mis en place.
</para></listitem>
<listitem><para>
<option>-c /etc/named.conf</option>, pour que BIND trouve
sa configuration à l'intérieur de la prison.
</para></listitem>
</itemizedlist>
<para>
Ce qui suit est le script d'init que j'utilise avec mon système Red Hat
6.0. Comme vous pouvez voir, il est presque identique à celui livré par
Red Hat. Je n'ai pas encore essayé la commande <command>rndc</command>,
mais je ne vois pas pour quelle raison elle ne fonctionnerait pas.
</para>
<programlisting>
#!/bin/sh
#
# named Le rôle de ce script est de démarrer et d'arrêter
# named (serveur DNS BIND).
#
# chkconfig: 345 55 45
# description: named (BIND) est le serveur de nom (DNS) \
# utilisé pour résoudre les noms de domaines en adresses IP.
# probe: true
# Lecture de la bibliothèque de fonctions.
. /etc/rc.d/init.d/functions
# Lecture des paramètres réseau.
. /etc/sysconfig/network
# Vérifie que le réseau fonctionne.
[ ${NETWORKING} = "no" ] && exit 0
[ -f /usr/local/sbin/named ] || exit 0
[ -f /chroot/named/etc/named.conf ] || exit 0
# En fonction de ce qui est appelé.
case "$1" in
start)
# Démarrer le démon.
echo -n "Démarrage de named : "
daemon /usr/local/sbin/named -u named -t /chroot/named \
-c /etc/named.conf
echo
touch /var/lock/subsys/named
;;
stop)
# Arrêter le démon.
echo -n "Arrêt de named : "
killproc named
rm -f /var/lock/subsys/named
echo
;;
status)
status named
exit $?
;;
restart)
$0 stop
$0 start
exit $?
;;
reload)
/usr/local/sbin/rndc reload
exit $?
;;
probe)
# named sait comment redémarrer intelligemment ;
# nous ne voulons pas que linuxconf nous propose
# de le redémarrer à chaque fois
/usr/local/sbin/rndc reload >/dev/null 2>&1 || echo start
exit 0
;;
*)
echo "Utilisation: named {start|stop|status|restart|reload}"
exit 1
esac
exit 0
</programlisting>
<para>
Comme pour syslogd, à partir de la version 7.2 de Red Hat, ce processus
est devenu encore plus simple. Il existe maintenant un fichier nommé
<filename>/etc/sysconfig/named</filename> dans lequel il est possible
d'ajouter des paramètres pour syslogd. Cependant, dans la distribution
Red Hat 7.2, la version par défaut de
<filename>/etc/rc.d/init.d/named</filename>, vérifie l'existence de
<filename>/etc/named.conf</filename> avant de lancer BIND. Vous devrez
corriger ce chemin.
</para>
<para>
Sur les systèmes OpenLinux de Caldera, vous avez juste besoin de
modifier les variables définies au début et le script s'occupera
apparemment du reste pour vous :
</para>
<screen>
NAME=named
DAEMON=/chroot/named/bin/$NAME
OPTIONS="-t /chroot/named -u named -g named"
</screen>
<para>
Et sous FreeBSD 4.3, vous pouvez éditer le fichier
<filename>rc.conf</filename> et y ajouter les lignes suivantes :
</para>
<screen>
named_enable="YES"
named_program="chroot/named/bin/named"
named_flags="-u named -t /chroot/named -c /etc/namedb/named.conf"
</screen>
</section>
<section>
<title>Changement de configuration</title>
<para>
Vous devrez aussi ajouter ou modifier quelques options dans votre
<filename>named.conf</filename> pour que vos divers répertoires soient
correctement définis. En particulier, vous devrez ajouter (ou changer,
si vous les avez déjà) les directives suivantes dans la section
<literal>options</literal> :
</para>
<screen>
directory "/etc/namedb";
pid-file "/var/run/named.pid";
statistics-file "/var/run/named.stats";
</screen>
<para>
Ce fichier étant lu par le démon <application>named</application>, tous
les chemins sont relatifs à l'environnement restreint. Au jour de la
rédaction de ce document, BIND 9 ne permettait pas d'utiliser
nombre des fichiers de statistiques et de vidage qu'il était possible
d'utiliser avec la version précédente. Présumons que les prochaines le
pourront ; si vous exécutez de telles configurations, vous devrez
ajouter des entrées additionnelles pour forcer BIND à également écrire
ces fichiers dans le répertoire <filename
class="directory">/var/run</filename>.
</para>
</section>
</section>
<section>
<title>Fin</title>
<section>
<title>Lancement de BIND</title>
<para>
Tout devrait être configuré et vous devriez être prêt à lancer BIND,
dans cette nouvelle version plus sûre. Si vous utilisez un script d'init
de type Système V, vous pourrez le lancer tout simplement en
utilisant la commande :
</para>
<screen>
# /etc/rc.d/init.d/named start
</screen>
<para>
Avant de faire cela, assurez-vous d'avoir arrêté toutes les anciennes
versions de BIND qui pourraient encore fonctionner.
</para>
</section>
<section>
<title>Voilà !</title>
<para>
Vous pouvez aller faire un petit somme maintenant ;-)
</para>
</section>
</section>
<appendix>
<title>
Annexes
</title>
<section id="upgrading">
<title>Mises à jour ultérieures de BIND</title>
<para>
Vous avez maintenant un BIND 9.1.2 tout joliment casé dans son
environnement restreint et assez peaufiné à votre goût… et vous
entendez parler de cette désagréable rumeur disant que BIND 9.1.3 est
finalement sorti. Vous vous sentez donc obligé de l'essayer sans
attendre. Devrez-vous repasser entièrement par ce long processus pour
installer cette nouvelle version ?
</para>
<para>
Pas du tout. En fait, vous aurez juste besoin de compiler le nouveau
BIND et l'installer par dessus l'ancien. N'oubliez pas d'arrêter
l'ancienne version et de redémarrer BIND, ou c'est l'ancienne version
qui continuera à tourner !
</para>
</section>
<section id="thanks">
<title>Remerciements</title>
<para>
Je voudrais remercier les personnes suivantes pour leur aide dans la
création de ce guide pratique :
</para>
<itemizedlist>
<listitem><para>
Lonny Selinger
<email>lonny CHEZ abyss POINT za POINT org</email>
pour l'évaluation» de la première version de ce guide pratique et pour
s'être assuré que je n'avais rien oublié.
</para></listitem>
<listitem><para>
Chirik
<email>chirik CHEZ CastleFur POINT COM</email>,
Dwayne Litzenberger
<email>dlitz CHEZ dlitz POINT net</email>,
Phil Bambridge
<email>phil.b CHEZ cableinet POINT co POINT uk</email>,
Robert Cole
<email>rcole CHEZ metrum TIRET datatape POINT com</email>,
Colin MacDonald
<email>colinm CHEZ telus POINT net</email>,
et tous ceux qui ont mis le doigt sur des erreurs, des omissions et
prodigué d'autres conseils utiles pour rendre encore meilleur ce guide
pratique.
</para></listitem>
<listitem><para>
Erik Wallin
<email>erikw CHEZ sec POINT se</email>
et Brian Cervenka
<email>brian CHEZ zerobelow POINT org</email>
pour avoir fourni de bonnes suggestions pour rendre encore plus sûr
l'environnement restreint.
</para></listitem>
<listitem><para>
Robert Dalton
<email>support CHEZ accesswest POINT com</email>
pour avoir suggéré une paire d'exemples supplémentaires et m'avoir
indiqué que les BIND 9.2.0 avaient besoin de
<filename>/dev/random</filename>.
</para></listitem>
<listitem><para>
Eric McCormick
<email>hostmaster CHEZ cybertime POINT net</email>
pour les informations sur FreeBSD 4.3.
</para></listitem>
<listitem><para>
Tan Zheng Da
<email>tzd CHEZ pobox POINT com</email>
pour les informations sur les changements survenus dans la version 7.2
de la distribution Red Hat, qui ont rendu le processus un peu plus
facile.
</para></listitem>
</itemizedlist>
<para>
Et le dernier mais certainement pas le moindre, je voudrais remercier
Nakano Takeo
<email>nakano CHEZ apm POINT seikei POINT ac POINT jp</email>
pour avoir traduit en japonais ce guide pratique de BIND en
environnement restreint. Vous pouvez trouver sa traduction à l'adresse
<ulink url="http://www.linux.or.jp/JF/JFdocs/Chroot-BIND-HOWTO.html"/>.
</para>
</section>
<section id="legal">
<title>Politique de distribution de ce document</title>
<para>
Copyright © Scott Wunsch, 2000-2001 pour la version originale.
</para>
<para>
Copyright © 2004-2005 Vincent Loupien, Benoît Rouits et
Jean-Philippe Guérard pour la version française.
</para>
<para>
Ce document peut être distribué selon les termes de la licence LDP tels
que définis à l'adresse <ulink
url="http://metalab.unc.edu/LDP/COPYRIGHT.html"/>.
</para>
<para>
Ce guide pratique est une documentation libre ; vous pouvez le
redistribuer ou le modifier conformément à la licence de LDP. Il est
distribué dans l'espoir qu'il sera utile, mais <emphasis>sans aucune
garantie</emphasis> ; sans même les garanties de
commercialisation ou d'adaptation dans un but spécifique. Voir la
licence de LDP pour plus de détails.
</para>
</section>
</appendix>
</article>
