Services DNS : les conseils d'architecture de l'ANSSI

Cloisonner des fonctions DNS avec des conteneurs ? C'est non pour l'ANSSI : en l'état, on les déploiera sur des VM ou des serveurs physiques distincts.

Cette recommandation en accompagne une trentaine d'autres, consignées dans un guide relatif aux architectures des services DNS.
L'agence en distingue trois types :

• Résolution des noms de domaine internes
• Résolution des noms de domaine Internet
• Hébergement des noms de domaine Internet

Pour ce qui est du cloisonnement des fonctions, il est acceptable de mutualiser le cache et le serveur récursif sur une même instance, nous explique-t-on.

TSIG, voire TLS pour les transferts vers les zones secondaires

Au niveau des services, on assurera :

• Une isolation physique des infras entre DNS internes (exposés sur le SI) et externes (connectés à Internet)
  Ces derniers devront, comme tout service exposé à Internet, être placés dans une passerelle d'interconnexion sécurisée avec des ressources dédiées (serveurs, pare-feu, commutateurs).
• Une interdiction des flux entre services DNS internes et externes
  Dans le contexte des services externes, les services d'hébergement et de résolution ont des niveaux d'exposition différents. On les placera donc dans deux zones de sécurité distinctes, avec éventuellement un cloisonnement physique.

En complément au filtrage des flux réseau, on déploiera un serveur primaire caché (qui n'apparaît pas dans les enregistrements de la zone DNS). On utilisera le protocole TSIG (signature de transaction), voire XoT (XFR-over-TLS) pour protéger les transferts de zone vers les serveurs secondaires.

De l'analyse de risque à la supervision, un protocole spécifique pour DNSSEC

Le durcissement des composants des services DNS et l'activation du pare-feu local des serveurs s'assortiront d'une diversification des logiciels assurant une même fonction. Il en va d'une logique de résilience.

Plusieurs des recommandations de l'ANSSI portent sur le protocole DNSSEC. Dans les grandes lignes, vu sa complexité et les risques que cela suppose, il devra faire l'objet d'une analyse de risque, d'un processus de gestion et d'une supervision spécifiques.

En matière de supervision, on appliquera un processus de MCS (maintien en condition de sécurité) tout en centralisant la journalisation. On se référera, en parallèle, à un autre guide ANSSI : celui sur les bonnes pratiques d'administration sécurisée des SI.

Services DNS internes : pointer les clients vers le serveur de cache

Sur les services DNS à usage interne, on interdira, d'une part, la résolution de noms de domaine Internet. De l'autre, les accès audit service depuis Internet. On limitera aussi l'accès des clients au seul serveur cache.

Le cloisonnement des fonctions DNS sera fera tant au niveau système (machine physique ou virtuelle, donc) qu'au niveau réseau (commutateur physique ou VLAN dédié). Il conviendra d'isoler physiquement les serveurs faisant autorité vis-à-vis de ceux portant des fonctions différentes. Un équipement de type pare-feu filtrera, en complément, les flux et échanges internes.

Des serveurs relais pour les services de résolution externe

L'interdiction des accès depuis Internet vaut aussi, de manière générale, pour les services de résolution des noms de domaine Internet. Au niveau des requêtes internes, on bloquera par défaut celles des équipements terminaux, pour lesquels on mettra en place des serveurs relais, cloisonnés et filtrés.

Un cloisonnement - physique - s'appliquera également aux serveurs de cache. Ils seront, dans l'idéal, positionnés entre deux pare-feu, filtrant respectivement les connexions avec Internet et le SI interne ou les autres équipements de la DMZ.

L'ANSSI ne s'oppose pas à la mutualisation des pare-feu en coupure avec Internet pour protéger plusieurs services du SI. Elle rappelle toutefois que l'exposition de services sur Internet implique un plus grand risque de compromission de la fonction de filtrage des flux entrants par rapport à la fonction de filtrage des flux sortants.

Avant de mettre en place des listes d'autorisation, on pourra commencer par des listes d'interdiction, plus simples à mettre en place et à gérer. On n'oubliera pas de limiter aussi le nombre de requêtes par client (journalisation au-delà d'un premier seuil, rejet des requêtes au-delà d'un deuxième).

Concernant les services d'hébergement DNS, au-delà des mesures de protection anti-DDoS, on cloisonnera physiquement les serveurs accueillant tout service d'hébergement de noms de domaine Internet. S'il existe des serveurs secondaires externes pour des raisons de disponibilité, on utilisera un serveur tampon. Celui-ci assurera les transferts de zone depuis les serveurs primaires internes. Il fera aussi office de serveur secondaire vis-à-vis du serveur primaire caché.

Illustration