DNS : les protections simples

I. Présentation

On l’a vu précédemment, le service BIND prend en charge les transferts de zone incrémentaux (aussi appelés Incremental Zone Transfers et abrégés en IXFR), dans lesquels le serveur de noms esclave ne télécharge depuis le serveur maître, que les portions d’informations mises à jour, d’une zone modifiée.

Toutefois, le processus de transfert standard nécessite que la zone entière soit transférée vers chaque serveur DNS esclave, même pour des modifications légères. Aussi, pour des domaines importants, avec des fichiers de zones très longs avec de nombreux serveurs DNS esclaves, le protocole IXFR rend la notification et les processus de mise à jour bien moins exigeants en ressources. Lorsqu’on édite manuellement les fichiers de zones pour effectuer les modifications, c’est la méthode de transfert AXFR (Automatic Zone Transfer) qui prévaut.

Durant cette phase de transfert, si l’on ne souhaite pas voir afficher la version du protocole BIND lors de l’interrogation d’un serveur DNS (qu’il s’agisse d’un serveur maître ou d’un esclave), il suffit d’ajouter les lignes suivantes dans le fichier de configuration named.conf :

options {
     directory "/var/named/var/cache/bind";
     version "SECRET";
}

Ainsi, lorsque l’on interroge le serveur de noms, à l’aide d’un client tel que nslookup, on ne devrait récupérer aucun adresse ni aucune version pouvant renseigner un éventuel tiers malveillant :

# nslookup -q=txt -class=CHAOS version.bind. 0
Server:         0
Address:        0.0.0.0#53
version.bind    text = "SECRET"

REMARQUE : cela n’empêche absolument pas l’utilisateur de connaître sa version locale du service en interrogeant le daemon named de la façon suivante (en local sur le serveur) :

# named –v
BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6

II. Les ACLs avec Bind

On peut s’intéresser à l’application de restrictions, au niveau des requêtes des clients, puisque par défaut, n’importe lequel des clients, de n’importe quel réseau, peut à sa guise, interroger le serveur DNS. On peut donc filtrer ce mécanisme et appliquer des règles d’accès (Access Control List ou ACL).

REMARQUE : il est toutefois plus judicieux d’autoriser uniquement les clients du réseau LAN, à interroger le serveur DNS, en autorisant uniquement le bin réseau souhaité. Par exemple, 192.168.1.0/24 si tel est votre réseau local. On peut aussi indiquer plusieurs adresses réseau, dans le cas où l’on dispose de plusieurs sous-réseaux. Enfin, le cas le plus extrême, on peut aussi indiquer une adresse IP unique, en dehors des sous-réseaux précédemment autorisés.

Afin d’appliquer de telles règles, il existe alors deux stratégies :

• Appliquer sur la totalité des requêtes reçues, au niveau du serveur DNS.
• Appliquer différentes restrictions selon les zones considérées.

ASTUCE : il est même possible de coupler les deux techniques, en indiquant une restriction globale et une restriction particulière, selon certaines zones. Lorsqu’une zone n’a aucune indication spécifique, alors la restriction globale doit s’appliquer. Par contre, dans le cas où les deux catégories de règles sont définies, c’est la règle précisant une restriction spécifique de zone qui est préemptive.

Afin d’avoir une administration plus fine et plus flexible de ces règles, il semble préférable de configurer chaque zone, même si le processus est plus long à mettre en place. Depuis la version du serveur BINDv9, il est possible de mettre en place des ACL. Cela permet de définir alors plusieurs ACL et de les attribuer sur différentes zones. Ainsi, lorsqu’on souhaite effectuer une modification de restriction, il n’y a qu’à modifier l’ACL correspondante, et non les zones une à une.

Comment appliquer une restriction au niveau de l’ensemble des requêtes : c’est-à-dire sur toutes les zones ? Il faut pour cela, modifier le fichier named.conf (ou named.conf.options sur Debian), dans la section options, en précisant les adresse autorisées dans le champ "allow-query" .

Exemple : pour autoriser les clients du réseau 192.168.1.0/24 et la machine 192.168.2.254 :

…
allow-query {192.168.1.0/24 ; 192.168.2.254;};

Ensuite, après avoir configuré le serveur DNS avec des restrictions globales, on peut ajouter des ACL de restrictions, zone par zone. Il faut donc modifier le ou les fichiers contenant la description de vos zones. Par défaut, celles-ci se trouvent dans /etc/named.rfc1912.zones ou (sur une distribution Debian, dans le fichier named.conf.local).

Note : la gestion d’ACL n’est pas une obligation, mais cela simplifie grandement l’administration du système, notamment, concernant l’aspect du temps passé dessus.

Les ACL que l’on ajoute doivent être positionnées en début de fichier, puisqu’on les appelle dans la déclaration des zones, et doivent donc être définies avant, sinon BINDv9 ne pourra pas les trouver. Une règle de contrôle d’accès se définit ainsi :

acl "nom-acl" {Paramètres} ;

Le nom de l’ACL doit être significatif et doit permettre de s’y retrouver lorsque l’on aura à retoucher à la configuration ultérieurement. Il faut bien imaginer avoir des dizaines de zones à gérer avec autant (sinon, plus), de règles ACL associées. Les paramètres, quant à eux doivent être précisés dans la partie entre accolades "{ };". IL s’agit alors des adresses réseau et hôtes que l’on souhaite autoriser à manipuler les requêtes de résolution de noms.

Ainsi, pour créer une ACL autorisant les deux sous-réseaux 192.168.1.0/24 et 192.168.2.0/24 à effectuer des requêtes, il faudra ajouter la règle suivante :

acl "acl-lan" { 192.168.1.0/24;192.168.2.0/24; };

L’application d’une règle acl prédéfinie sur une zone s’effectue en indiquant le paramètre "allow-query" (comme précédemment), mais on référencera alors le nom de la règle souhaitée, en lieu et place des adresses listées auparavant :

allow-query { "acl-lan"; };

IMPORTANT : lorsqu’on dispose d’un seul et unique serveur DNS au sein de l’architecture, il est essentiel de ne pas autoriser le transfert de zone, afin qu’aucun autre serveur (surtout ceux dont on ignore l’existence), puisse venir lire les fichiers de zones. Il faut alors modifier le fichier de configuration pour positionner le paramètre allow-transfer à la valeur ‘none’ :

allow-transfer { none; };

Le cas des serveurs redondés est un peu plus complexe et sera vu ultérieurement dans ce module.