Isolation réseau des contrôleurs de domaine : pas d'Internet, des flux maîtrisés et un pare-feu actif
Les contrôleurs de domaine doivent être joignables par tout le parc pour l'authentification, ce qui pousse souvent à les laisser grands ouverts. Pourtant, entre « accessible pour les services d'annuaire » et « accessible pour tout », il y a une marge considérable. L'isolation réseau réduit à la fois la surface d'attaque et les possibilités d'exfiltration.
Pas de navigation Internet depuis un DC
Un contrôleur de domaine n'a aucune raison de consulter des sites web, de lire des courriels ou de télécharger des outils. Chaque session de navigation ouverte depuis un DC expose un compte de niveau 0 à du contenu non maîtrisé. La règle doit être technique et non seulement organisationnelle : le proxy refuse les requêtes émises par les contrôleurs de domaine, sauf vers une liste restreinte de destinations nécessaires, et aucun navigateur n'est utilisé sur ces serveurs.
Les exceptions légitimes existent mais se comptent sur les doigts d'une main : service de mise à jour (idéalement un serveur WSUS interne ou une solution de gestion des correctifs), service cloud de Defender for Identity ou de Defender for Endpoint, source de temps externe pour l'émulateur PDC. Chacune doit être documentée et limitée à ses points de terminaison.
Restreindre les flux sortants
On pense spontanément aux flux entrants, mais les flux sortants d'un DC sont tout aussi importants. Un contrôleur de domaine qui peut ouvrir une connexion SMB ou HTTP vers n'importe quelle machine peut être contraint de s'y authentifier, ce qui alimente les attaques par relais NTLM. Il peut aussi servir de point de départ pour exfiltrer des données. En pratique, un DC a besoin de joindre les autres DC (réplication, DNS), ses sources de temps, ses serveurs de mise à jour, de supervision et de sauvegarde, et quelques services cloud identifiés. Le reste peut être refusé.
L'administration uniquement depuis des postes dédiés
Les protocoles d'administration (RDP, WinRM et PowerShell à distance, consoles MMC via RPC) ne doivent être acceptés que depuis des postes de travail d'administration privilégiés (PAW) ou un réseau d'administration de niveau 0. Un administrateur qui ouvre une session RDP sur un DC depuis son poste bureautique expose ses identifiants à tout ce qui s'exécute sur ce poste. Le filtrage se fait à deux niveaux : sur le réseau (listes d'accès, segmentation) et sur le DC lui-même, via le pare-feu Windows.
Le pare-feu Windows sur les contrôleurs de domaine
Désactiver le pare-feu Windows sur les DC « pour éviter les problèmes » reste courant. C'est une erreur : il doit être actif sur tous les profils, configuré par GPO et non localement, avec la journalisation des paquets refusés activée. Les règles entrantes des services d'annuaire restent ouvertes à tout le parc, tandis que les règles d'administration sont limitées aux plages d'adresses des PAW. Désactivez la fusion des règles locales pour qu'un administrateur ne puisse pas ajouter discrètement une exception.
Les principaux ports à connaître sont les suivants :
| Service | Port(s) | Portée recommandée |
|---|---|---|
| DNS | TCP/UDP 53 | tout le parc |
| Kerberos et changement de mot de passe | TCP/UDP 88, TCP/UDP 464 | tout le parc |
| LDAP, LDAPS | TCP/UDP 389, TCP 636 | tout le parc |
| Catalogue global | TCP 3268, TCP 3269 | tout le parc |
| SMB (SYSVOL, NETLOGON) | TCP 445 | tout le parc |
| Mappeur de points de terminaison RPC et ports dynamiques | TCP 135, TCP 49152-65535 | tout le parc (réplication, services) |
| Heure (NTP) | UDP 123 | tout le parc |
| Services web Active Directory | TCP 9389 | postes d'administration |
| RDP, WinRM | TCP 3389, TCP 5985/5986 | PAW uniquement |
Cette liste couvre les besoins courants ; certains rôles (DHCP, réplication de fichiers, services tiers installés sur les DC) en ajoutent. Consultez la documentation Microsoft sur les ports utilisés par Active Directory et validez chaque règle en recette.
Moins de rôles, moins de ports. Chaque rôle supplémentaire installé sur un DC (serveur d'impression, serveur de fichiers, agent applicatif) ouvre des flux et élargit la surface d'attaque. Un contrôleur de domaine doit rester un contrôleur de domaine.
Ce qu'un audit vérifie
- l'état du pare-feu Windows sur chaque DC, l'origine GPO des règles et la journalisation ;
- la possibilité de naviguer sur Internet ou de joindre des destinations arbitraires depuis un DC ;
- les adresses sources autorisées pour RDP, WinRM et les consoles d'administration ;
- les rôles et logiciels non nécessaires installés sur les contrôleurs de domaine.