DNS intégré à Active Directory : sécuriser les zones, les mises à jour et le groupe DnsAdmins
Le DNS est le service dont tout dépend dans un domaine Active Directory, et pourtant c'est l'un des moins examinés. Hébergé sur les contrôleurs de domaine et stocké dans l'annuaire, il hérite des forces d'AD mais aussi de permissions par défaut que peu d'équipes connaissent. Voici ce que nous vérifions systématiquement.
Un service stocké dans l'annuaire
Dans une zone intégrée à Active Directory, chaque nom est un objet dnsNode stocké dans une partition d'application (DomainDnsZones ou ForestDnsZones) et répliqué avec le reste de l'annuaire. Cela apporte la réplication multi-maître et la possibilité de contrôler finement qui peut créer ou modifier un enregistrement. Mais cela signifie aussi que la sécurité du DNS se joue dans les listes de contrôle d'accès de l'annuaire, et pas seulement dans la console DNS.
Mises à jour dynamiques : « sécurisées uniquement »
Une zone peut accepter les mises à jour dynamiques de trois façons : aucune, non sécurisées et sécurisées, ou sécurisées uniquement. Une zone qui accepte les mises à jour non sécurisées permet à n'importe quel équipement du réseau, même non authentifié, d'enregistrer ou d'écraser un nom. C'est une porte ouverte à la redirection de trafic. Toute zone intégrée à AD devrait être configurée en sécurisées uniquement.
Avec les mises à jour sécurisées, le compte qui crée un enregistrement en devient propriétaire, et lui seul peut ensuite le modifier. Une exception à connaître : le groupe DnsUpdateProxy. Les enregistrements créés par ses membres, souvent les serveurs DHCP, n'ont pas de propriétaire protégé et peuvent être repris par n'importe qui. Il est préférable de configurer le service DHCP avec un compte dédié pour les mises à jour plutôt que de l'ajouter à ce groupe.
Tout utilisateur authentifié peut créer des enregistrements
Par défaut, les utilisateurs authentifiés disposent du droit de créer des objets enfants dans une zone intégrée à AD. C'est ce qui permet à un poste de s'enregistrer lui-même. Conséquence moins connue : n'importe quel compte du domaine peut créer un nom qui n'existe pas encore, en passant directement par LDAP plutôt que par le protocole DNS. Cette technique est souvent désignée sous le nom d'abus ADIDNS.
Un attaquant disposant d'un simple compte utilisateur peut ainsi créer un nom recherché par les postes mais absent de la zone, et faire pointer ce nom vers une machine qu'il contrôle, afin d'intercepter des authentifications. Deux cas sont particulièrement sensibles :
- WPAD : le nom utilisé par la découverte automatique de proxy. Le serveur DNS Windows le bloque par défaut grâce à sa liste globale de blocage des requêtes, qui contient aussi
isatap. Vérifiez qu'elle est toujours active et n'a pas été vidée pour « régler un problème » ; - l'enregistrement générique (
*) : s'il est créé, il répond à toute requête pour un nom inexistant dans la zone, ce qui détourne potentiellement une grande quantité de trafic.
Les mesures possibles : restreindre le droit de création d'objets enfants sur les zones aux comptes qui en ont réellement besoin (en testant l'impact sur l'enregistrement des postes), créer vous-même les noms sensibles pour qu'ils ne puissent pas être pris, et surveiller la création d'objets dnsNode par des comptes utilisateurs.
Indicateur simple. Un enregistrement dont le propriétaire est un compte utilisateur et non un compte ordinateur, un serveur DHCP ou un administrateur mérite toujours une explication. Nous en trouvons régulièrement, rarement justifiés.
DnsAdmins : un groupe de niveau 0 qui s'ignore
Le groupe DnsAdmins permet d'administrer le service DNS. Or ce service tourne sur les contrôleurs de domaine avec les privilèges système, et sa configuration permet notamment de charger une bibliothèque de greffon au démarrage. Un membre de DnsAdmins peut donc, en pratique, faire exécuter du code sur un contrôleur de domaine. Microsoft considère ce comportement comme conforme à la conception : c'est à vous de traiter ce groupe comme privilégié.
Nous recommandons de laisser DnsAdmins vide ou limité à des comptes d'administration de niveau 0, de surveiller toute modification de son appartenance, et de vérifier les droits sur l'objet MicrosoftDNS et les zones, qui permettent un contrôle équivalent.
Nettoyage et hygiène des zones
Le nettoyage (scavenging) supprime les enregistrements dynamiques qui n'ont pas été rafraîchis depuis une durée donnée. Sans lui, les zones accumulent des noms de machines disparues, ce qui fausse les inventaires et peut créer des confusions de résolution. Il doit être activé à la fois sur les zones et sur au moins un serveur, avec des intervalles cohérents avec la durée des baux DHCP. Les enregistrements statiques ne sont pas concernés. Profitez-en pour vérifier que les transferts de zone sont désactivés ou limités à des serveurs explicitement désignés.
Ce qu'un audit vérifie
- Le mode de mise à jour dynamique de chaque zone, et l'absence de zones acceptant les mises à jour non sécurisées.
- Les permissions de création d'objets enfants sur les zones intégrées à AD.
- La présence d'enregistrements génériques ou WPAD et l'état de la liste globale de blocage.
- Les enregistrements dont le propriétaire est un compte utilisateur.
- L'appartenance aux groupes DnsAdmins et DnsUpdateProxy.
- La configuration du nettoyage et des transferts de zone.