26/11/2024

DNS et chroot : la solution de confinement

I. Présentation

Afin d’aller plus loin en termes de sécurisation d’une architecture de résolution de noms DNS, on peut également confiner le ou les serveurs maitres et esclaves au sein d’une architecture dite chrootée. Cela revient à déporter l’arborescence par défaut dans une sous-arborescence en restreignant les accès. Cela permet de réduire le risque d’utilisation détournée d’une faille de sécurité par un tiers malintentionné.

ATTENTION : afin de mettre en œuvre ce cantonnement et ce déport, il est conseillé d’utiliser alors un compte distinct du compte root afin d’empêcher la capacité d’un pirate à disposer des droits d’administration illimités depuis le compte du super-utilisateur.

II. Chrooter le service named

On va alors créer une sous-arborescence dans /var/named, en reproduisant celle du système global : /etc, /dev, /var dans laquelle on pourra confiner le service named.

Cela permettra alors de positionner des droits limités, avec un compte différent de root et de chrooter la nouvelle sous-arborescence :

# mkdir –p /var/named/chroot/named
# cd /var/named/chroot/named
# mkdir –p dev etc/namedb/slave var/run

On peut alors déplacer les fichiers de zones et de configuration standard, dans l’environnement de confinement restreint, de sorte que BIND puisse y accéder. EN toute logique, le fichier named.conf sera déplacé dans /var/named/chroot/named/etc et les fichiers de zones seront placés dans /var/named/chroot/named/etc/namedb :

 # cp –p /etc/namezd.conf /var/named/chroot/etc/
 # cp –a /var/named/* /var/named/chroot/named/etc/namedb/

REMARQUE : le service BIND a besoin d’écrire directement dans le répertoire namedb. Toutefois, pour renforcer la sécurité, on peut l’interdire. Mais, si le serveur en question est un esclave du serveur maître, afin de mettre à jour une zone, il lui faudra enregistrer ses fichiers dans un répertoire séparé et auquel il aura accès. On autorise donc le compte named à accéder au répertoire /var/named/chroot/named/etc/namedb/slave :

# chown –R named:named /var/named/chroot/named/etc/namedb/slave

Il faut déplacer toutes les zones esclaves dans ce sous-répertoire et on doit également mettre à jour le fichier de configuration named.conf en conséquence. De plus, le service de résolution devra également pouvoir écrire dans le répertoire /var/named/chroot/named/var/run pour y placer ses fichiers contenant les numéros de processus et de statistiques :

# chown named:named /var/named/chroot/named/var/run

Etant donné qu’en environnement confine restreint BIND ne peut plus accéder aux fichiers hors de ce périmètre, il lui faut malgré tout accéder aux fichiers /dev/null, /dev/random et /dev/zero. Il faut donc les recréer dans le sous-répertoire /var/named/chroot/named/dev :

# mknod /var/named/chroot/named/dev/null c 1 3
# mknod /var/named/chroot/named/dev/random c 1 8
# mknod /var/named/chroot/named/dev/zero c 1 5
# chmod 666 /var/named/chroot/named/dev/{null,zero,random}

Il faut encore copier le fichier /etc/localtime dans le sous-répertoire /var/named/chroot/named/etc afin que BIND puisse enregistrer les évènements en disposant d’un horodatage cohérent:

# cp /etc/localtime /var/named/chroot/named/etc/

Il reste alors deux points à traiter pour prendre en compte le confinement restreint du service named:

  • La gestion de la journalisation via syslogd
  • La gestion du script d’initialisation du service
  • La gestion du cache

III. Gestion de la journalisation syslogd

Normalement, le daemon syslogd possède une option –a (introduit par OpenBSD), permettant d’écouter le trafic depuis un socket. On va donc ajouter ce paramètre à la ligne de commande, utilisée pour initialiser le daemon syslogd, au sein du script /etc/rc.d/init.d/syslog :

daemon syslogd –m 0 –a /var/named/chroot/named/dev/log

REMARQUE : la plupart du temps, les options du daemon syslogd (cela fonctionne aussi avec le daemon rsyslogd), sont paramétrables depuis le fichier /etc/sysconfig/syslogd où l’on peut préciser alors:

OPTIONS_SYSLOGD="-m 0 –a /var/named/chroot/named/dev/log"

Une fois cela fait on peut alors arrêter et redémarrer le service syslogd :

# /etc/init.d/syslogd stop
# /etc/init.d/syslogd start

Lorsque le service a redémarré, on devrait voir apparaître un socket dans le répertoire /var/named/chroot/named/dev :

srw-rw-rw-   1 root     root            0 May 13 10:28 log

IV. Gestion du script d’initialisation

On doit alors modifier trois paramètres au sein du script de lancement du service de résolution de noms :

  • -u named: pour forcer l’utilisation du service avec le compte named (et plus root).
  • -t /var/named/chroot/named: pour que BIND s’exécute dans le bon environnement.
  • -c /etc/named.conf: pour que le service retrouve sa configuration dans le périmètre chroot.

En fait, le premier paramètre n’est plus utile car c’est systématiquement named qui est utilisé.

A l’identique de la gestion des journaux de logs avec syslogd (ou rsyslogd), il suffit simplement d’éditer le fichier /etc/sysconfig/named pour lui préciser la variable ROOTDIR qui convient pour envoyer l’exécution de BIND vers le confinement souhaité:

ROOTDIR="/var/named/chroot"

V. Gestion du cache

Dans le cas où l’on n’utilise pas le cache intégré à BIND, il ne faut surtout pas oublier de rapatrier également le contenu du répertoire de cache /var/cache/bind dans l’espace de confinement :

# cp /var/cache/bind/* /var/named/chroot/named/cache/

A ce stade, il est alors possible de redémarrer le service named en exécutant le script se trouvant dans le répertoire /etc/init.d :

# /etc/init.d/named start

On peut également restreindre l’accès de root sur le répertoire de confinement ainsi que celui du compte named :

# chown root /var/named/chroot
# chmod 700 /var/named/chroot
# chown named:named /var/named/chroot/named
# chmod 700 /var/named/chroot/named

Ainsi, n’importe quel utilisateur ne peut plus accéder à l’arborescence /var/named/chroot et seul le compte named peut se déplacer dans /var/named/chroot/named.

IMPORTANT : sur des systèmes d’exploitation tels que Microsoft Windows, le vidage du cache s’effectue en ligne de commande au travers d’une fenêtre DOS/CMD :

$ ipconfig /flushdns

Les informations concernant le cache DNS peuvent être consultées directement en exécutant la commande ci-dessous :

# ipconfig /displaydns
author avatar
Philippe PIERRE
A exercé de nombreuses années en tant qu'administrateur de base de données et comme administrateur Système Unix/Linux. Il a enseigné les réseaux au CNAM (Paris). Aujourd'hui, employé en tant qu'ingénieur infrastructure, au sein d'un laboratoire pharmaceutique et administrant un cluster de calculs HPC, il connaît parfaitement les environnements GNU/Linux dans le cadre d'une entreprise et des systèmes de haute disponibilité. Il aime partager son expérience.
Partagez cet article Partager sur Twitter Partager sur Facebook Partager sur Linkedin Envoyer par mail