 |
|||||||||||||||||||||||
|
[Sécuriser l'exécution de BIND] Ce document présente quelques éléments essentiels permettant d'exécuter BIND dans un environnement sécurisé.
[I.1. Version de BIND] BIND, au même titre que Sendmail, est un programme complexe qui a laissé apparaître, au cours des nombreuses années de son utilisation, beaucoup de failles de sécurité (liées également à DNS). Il est donc essentiel de toujours utiliser des versions récentes et/ou des patchs à jour afin d'éliminer le risque de compromission par l'exploitation d'une faille ancienne. Les dernières versions de BIND sont disponibles directement sur le Web : A ce jour, il convient d'utiliser la version 9.1 de BIND. [I.2. Installation de BIND] Pour
installer BIND, se référer au guide d'installation.
[II. Sécuriser l'exécution de BIND] [II.1. Exécution de BIND sans droit root] BIND
est parfois (dans les versions moins récentes) exécuté avec des droits
root, afin d'utiliser le port privilégié 53 (TCP, UDP), inférieur à
1024. [Pourquoi exécuter BIND sous une identité différente de root ?] De
par sa complexité, BIND est vulnérable à un certain nombre de failles
de sécurité exploitables par des pirates. Il est donc essentiel de
protéger le système hébergeant le service de résolution de noms de
toute attaque potentielle. [Comment configurer BIND pour s'exécuter sans droit root ?] 2 étapes sont nécessaires à l'exécution de BIND sous une identité distincte de root. 1. Création du compte d'exécution et mise en place des permissions Il convient de créer en
premier lieu le compte de service utilisé par BIND pour s'exécuter, et
de fixer les droits adéquats sur les fichiers et répertoires utilisés
par BIND :
Et dans le fichier /etc/group :
Remarque : pour les utilisateurs de système Linux, les commandes useradd et groupadd permettent de créer respectivement l'utilisateur dns et le groupe dns. Voici un exemple dans lequel UID et GID sont fixés à 53 :
Si les mots de passe sont sécurisés avec shadow, ajouter * dans le champs password de /etc/shadow (le champs password de /etc/passwd présente un "x"). - Créer et disposer des droits restreints sur le répertoire de base de l'utilisateur dns :
2. Lancer BIND sans l'identité root Le service named doit être lancé avec l'utilisateur dns créé précédemment. Pour celà, modifier le fichier de configuration du démon named (ex. sous Linux /etc/rc.d/init.d/named) en remplaçant la ligne :
Par
Puis relancer le démon :
3. Alternative : lancer BIND depuis Inetd Une
alternative intéressante, bien que non conseillée ;-), consiste à lancer BIND non pas en tant que
démon, mais au travers du super-démon Inetd. Pour lancer le service named non plus comme démon, mais via inetd (le super-démon), il convient d'effectuer les étapes suivantes (exemple donné pour Linux). a) Ajouter les lignes suivantes dans le fichier /etc/inetd.conf :
b) Arrêter le démon named :
Veiller à ne plus permettre à named de démarrer en tant que démon, par exemple (sous Linux) :
c) Relancer le super-démon inetd :
[II.2. Exécuter BIND dans un environnement confiné] Exécuter BIND dans un environnement confiné consiste à utiliser chroot pour définir un espace d'exécution isolé dédié à named. Pour obtenir un niveau de sécurité et d'efficacité optimum, toujours accompagné l'exécution de BIND dans un environnement confiné (chroot) par un changement d'identité. En effet, l'utilisateur root est capable de sortir de la prison imposée par chroot, ce qui en réduit considérablement l'intérêt d'un point de vue sécurité. Remarque : de manière générale, lorsqu'une application est emprisonnée par chroot, ne jamais l'exécuter sous root ! Les étapes décrites ci-après pour "chroot-er" BIND dans un environnement Linux sont extraites du document "Securing and optimizing Redhat Linux 1.3" de Gerhard Mourani et du document "Chroot-BIND-HOWTO". 1. Librairies partagées de named Il est nécessaire de connaître les librairies utilisées par le démon named :
2. Construction de l'environnement chroot Une
partition spécifique, /chroot, est normalement attribuée pour
recevoir les environnements restreints, en dehors des partitions
utilisées par le système. Les répertoires suivants doivent être créés :
Si un démon named est lancé, il convient de l'arrêter :
3. Copie des fichiers dans l'environnement chroot Dans un premier temps, les fichiers de configuration doivent être copiés :
Attention : le propriétaire du répertoire /chroot/named/var/named (et tous les fichiers dans ce répertoire) doit être l'utilisateur choisi pour exécuter named. Dans notre cas, nous allons reprendre l'utilisateur choisi précédemment : dns.
Remarque : l'utilisateur dns devra avoir pour répertoire de base /chroot/named (cf. étape 4 pour la création de l'utilisateur dns). Il est ensuite nécessaire de copier les librairies partagées identifiées à l'étape 1 :
Puis copier les fichiers nécessaires à l'horodatage correct des messages de log :
Certains fichiers critiques ne doivent pas pouvoir être modifiés, renommés ou effacés de manière inopportune :
4. Création du compte de service utilisé pour l'exécution de named Comme nous l'avons vu précédemment, il convient de créer le compte et le groupe utilisé par named pour s'exécuter. Pour cela, nous allons procéder de la même manière que dans la partie II.1. de ce document. Nous
avons ici choisi d'utiliser un utilisateur nommé dns et un group dns. Il
convient de sélectionner un UID et un GID non déjà utilisés, par
exemple 53 :-) La création de l'utilisateur et du groupe doit ensuite être effectuée : useradd -c "DNS
User" -u 53 -g 53 -s /bin/false -r -d /chroot/named dns Comme précédemment, l'utilisateur dns ne doit pas pouvoir ouvrir de session sur le serveur et donc ne pas disposer de mot de passe (remplacement du caractère !! par * dans le champ password du fichier /etc/shadow). 5. Re-direction des messages de logs Il
est nécessaire de préciser au démon syslog d'écouter les logs produits
par named dans son nouvel environnement.
Par la ligne :
Relancer ensuite le démon syslog :
6. Configuration du démon named Il est nécessaire de modifier le script de lancement du démon named afin de prendre en compte le nouvel environnement. Dans le fichier /etc/rc.d/init.d/named, modifier les lignes suivantes :
Les options -u et -g
précisent à BIND respectivement l'utilisateur et le groupe qu'il doit
utiliser pour s'exécuter. 7. Modification du ndc A partir de la version BIND 8.2, ndc (name daemon control) n'est plus un script mais un programme. Il convient de le recompiler afin de prendre en compte les modifications opérées. Il faut alors effectuer les opérations suivantes (ex. donné pour un système Linux) :
Éditer le fichier Makefile.set et modifier les variables suivantes en précisant l'environnement chrooté :
Recompiler alors le programme ndc :
8. Un peu de nettoyage Effacer les fichiers et répertoires inutiles :
9. Lancement de named Il est maintenant possible de lancer named dans son environnement restreint :
Priez... Puis vérifier alors que named est démarré et fonctionne correctement et qu'il s'exécute sous l'identité choisie (i.e. : dns) :
[Références] - "Securing
and optimizing Redhat Linux 1.3" - Gerhard Mourani.
|
securIT@free.fr -
Plein accès
