Sécurité des systèmes informatiques/Sécurité informatique/DNS avec BIND 9
La figure ci-dessous présente le fonctionnement général des requêtes DNS dans une architecture comportant plusieurs serveurs DNS. Certains de ces serveurs (IP 192.168.69.1, 192.168.66.1 et 194.54.3.68) sont associés à la gestion des noms d'un domaine fictif test.fr. Un autre serveur DNS privé (IP 10.59.1.3) est associé à la gestion d'un domaine fictif privé (invisible depuis Internet) nommé here.local. On a également représenté deux serveurs DNS externes quelconques situés sur Internet.
Cette architecture correspond à une situation où les serveurs DNS internes de l'entreprise sont installés dans la zone protégée du réseau, à la fois pour le domaine visible depuis Internet (test.fr) et pour son domaine privé local (here.local). Plusieurs serveurs DNS (deux au moins) devant être disponibles depuis Internet pour gérer le domaine public test.fr (c'est une obligation pour se voir attribuer un nom de domaine), un deuxième serveur est positionné dans une DMZ (192.168.66.1), et un troisième (194.54.3.68) est certainement situé chez un prestataire extérieur offrant un service de secours réellement redondant.
Dans ce schéma, on distingue les différents types de requêtes DNS pouvant transiter sur le réseau :
- Les requêtes récursives correspondent aux demandes normalement effectuées par les clients à leur serveur DNS habituel, lequel prend alors en charge la totalité du protocole de résolution des noms. Il consulte son cache et contacte si besoin plusieurs autres serveurs DNS pour obtenir une réponse ou une erreur.
- Les requêtes itératives correspondent aux demandes de résolution effectuées généralement entre les serveurs DNS eux-mêmes. Les réponses aux requêtes itératives peuvent consister à rediriger le demandeur vers un autre serveur, charge au demandeur de poursuivre lui-même la résolution.
- Les requêtes de transferts de zones sont effectuées entre un serveur secondaire et le serveur primaire pour un même domaine pour permettre au serveur secondaire de posséder une copie à jour de la zone DNS qu'il gère.
On distingue également le double rôle que jouent généralement les serveurs DNS du point de vue des flux d'information traversant l'architecture. En effet, ils sont à la fois :
- des serveurs au sens propre du terme qui répondent aux demandes entrantes de clients externes (d'autres serveurs DNS) concernant le domaine géré (
test.frdans notre exemple) ; - et des relais qui exécutent pour le compte de clients internes des demandes sortantes de résolution DNS et maintiennent aussi un cache pour les accélérer.
Une première approche de la sécurité des serveurs DNS consiste à clarifier l'architecture et bien paramétrer les serveurs de manière à ce qu'il répondent à ces différentes demandes correctement en fonction de l'origine du client.
Ainsi, il importe d'abord de limiter correctement les transferts de zones, qui diffusent la totalité des informations concernant test.fr en une seule fois. Cette limitation doit être faite sur le serveur primaire (IP 192.168.69.1) en y identifiant les serveurs secondaires autorisés à recevoir une copie de la zone :
zone "test.fr" {
type master;
file "/etc/bind/db.test.fr";
allow-transfer {
192.168.66.1;
// or 194.56.3.68; (see below)
};
};
Mais cette limitation peut également être effectuée sur le serveur secondaire (IP 192.168.66.1) en lui indiquant précisément le serveur primaire à utiliser pour la zone test.fr dont il est secondaire :
zone "test.fr" {
type slave;
masters { 192.168.69.1; };
file "/etc/bind/bak.db.test.fr";
allow-transfer {
194.56.3.68; // or "none"
};
};
Ensuite, sur le serveur primaire comme sur le serveur secondaire, il est possible de contrôler les accès effectués aux zones gérées :
- les requêtes itératives proviennent d'autres serveurs (c'est à dire d'Internet) ;
- les requêtes récursives proviennent seulement des clients internes, c'est à dire des utilisateurs finaux (ou de leur mandataire).
En effet, dans l'exemple que nous suivons le serveur DNS interne public à l'adresse IP 192.168.69.1 reçoit en fait les requêtes des utilisateurs via le serveur DNS interne privé à l'adresse 10.59.1.3. Ce dernier est en fait normalement son seul client, à part pour quelques exceptions (autres serveurs, dépannages éventuels, etc.). Ce sont ces règles que nous appliquons ici :
// We allow only recursive queries from the internal nameserver, the 2nd, and self
acl "ns_rzo" { 192.168.66.1; 10.59.1.3; 127.0.0.1; };
// We also allow some admin. station to do queries here directly in case of problem
acl "admin" { 192.168.65.1; };
…
allow-query { any; }; // or "slaves_ns"
allow-recursion { "ns_rzo"; "admin"; };
Nous avons donc ici le cas d'un serveur DNS (IP 192.168.69.1) qui contient la référence du domaine public d'une entreprise (test.fr), qui gère pour le compte de tous les postes de travail la résolution des requêtes DNS sur Internet mais dont la configuration ne permet quasiment qu'un seul client. C'est en fait parfaitement conforme au cheminement souhaité des flux réseau dans l'architecture.
Par ailleurs, le serveur DNS interne privé (IP 10.59.1.3) étant très proche du serveur DNS accédant à Internet, il n'est pas nécessaire d'utiliser ses fonctions de cache qui sont redondantes avec celles mises en œuvre au niveau suivant. Il est alors utile de faire fonctionner ce dernier serveur en mode relais pur :
options {
…
// Allowed forwarders (only the DMZ nameservers)
forwarders {
192.168.69.1; 192.168.66.1;
};
// We *always* forward
forward only;
…
};
L'intérêt de ce type d'architecture est de permettre une protection maximale du serveur DNS interne privé de l'entreprise qui n'accède absolument pas à Internet directement mais qui est cependant en mesure d'assurer l'ensemble des services DNS nécessaires aux postes de travail du réseau local, y compris la résolution de noms externes à l'entreprise. Ce serveur est aussi en mesure de résoudre les noms internes à l'entreprise (dans le domaine here.local) qu'il gère directement. Les postes de travail accèdent donc de manière transparente à tous les différents domaines.