« Sécurité des systèmes informatiques/Sécurité informatique/DNS avec BIND 9 » : différence entre les versions
Contenu supprimé Contenu ajouté
Aucun résumé des modifications |
Aucun résumé des modifications |
||
Ligne 1 :
{{Sécurité informatique}}
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 <tt>test.fr</tt>. Un autre serveur DNS privé (IP 10.59.1.3) est associé à la gestion d'un domaine fictif privé (invisible depuis Internet) nommé <tt>here.local</tt>. 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 (<tt>test.fr</tt>) et pour son domaine privé local (<tt>here.local</tt>). Plusieurs serveurs DNS (deux au moins) devant être disponibles depuis Internet pour gérer le domaine public <tt>test.fr</tt> (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.
[[Image:dns_general.png|frame|center|Schéma général des échanges DNS]]
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é (<tt>test.fr</tt> dans 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 <tt>test.fr</tt> 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;
Ligne 28 :
};
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
zone "test.fr" {
type slave;
Ligne 40 :
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
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 :
Ligne 51 :
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 (<tt>test.fr</tt>), 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 {
| |||