Sécurité des systèmes informatiques/Sécurité informatique/Signature et messagerie

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 codice_1. Un autre serveur DNS privé (IP 10.59.1.3) est associé à la gestion d'un domaine fictif privé (invisible depuis Internet) nommé codice_2. 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 (codice_1) et pour son domaine privé local (codice_2). Plusieurs serveurs DNS (deux au moins) devant être disponibles depuis Internet pour gérer le domaine public codice_1 (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 :
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 :
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 codice_1 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 codice_1 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 :
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 (codice_1), 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.

Sécurité des systèmes informatiques/Sécurité informatique/PKI