Pare-feu des DC : ports, flux sortants, accès admin

Un contrôleur de domaine doit être joignable par chaque membre du domaine. On en déduit souvent qu'il est impossible de le protéger par un pare-feu. C'est faux. Les clients ont besoin d'un ensemble connu de ports d'authentification et d'annuaire, mais pas de RDP, de WinRM ni de la gestion de services à distance. Le DC lui-même n'a presque jamais besoin d'initier une connexion vers un poste de travail ou vers Internet. Maîtrisez ces trois points et vous supprimez d'un coup le mouvement latéral vers les DC, les chemins de relais par coercition et les flux sortants de commande et contrôle.

La base DC énonce le principe du contrôle des flux sortants. Ce guide le transforme en une politique déployable. Il couvre la matrice des ports, la mesure du trafic réel avant tout blocage, les règles hôte et réseau, l'accès d'administration réservé au Tier 0, et la vérification que rien n'a été cassé.

La matrice des ports

Répartissez le trafic des DC en trois flux. Chaque flux a ses propres sources et ses propres règles.

Clients et serveurs membres vers les DC (entrant) :

De DC à DC (réplication, dans les deux sens) : tout ce qui précède, plus les ports RPC utilisés par DRSUAPI et DFSR. Autorisez l'intégralité du trafic entre les sous-réseaux de DC. Diagnostiquer une panne de réplication causée par une ACL trop astucieuse n'en vaut pas la peine.

Administration (Tier 0 uniquement) : 3389 (RDP), 5985/5986 (WinRM), 9389 (AD Web Services, utilisé par le module PowerShell ActiveDirectory et ADAC), plus le RPC pour les composants logiciels enfichables MMC. Ces flux ne proviennent que des PAW ou des hôtes de rebond Tier 0.

Le NetBIOS historique (UDP 137/138, TCP 139) n'est nécessaire que si vous avez encore des clients qui en dépendent. Retirez-le dans le cadre du travail sur LLMNR et NBT-NS décrit dans désactiver LLMNR, NetBIOS et WPAD.

Ce que l'on oublie

• ICMP. Le traitement de la stratégie de groupe et certaines vérifications du localisateur de DC utilisent l'écho ICMP pour détecter les liaisons lentes. Autorisez les requêtes/réponses d'écho ICMP des sous-réseaux clients vers les DC plutôt que de les bloquer et de diagnostiquer plus tard des comportements GPO étranges.
• IPv6. Windows privilégie IPv6 lorsqu'il est disponible. Si vos règles réseau ne couvrent qu'IPv4, un DC doté d'une adresse lien-local ou SLAAC peut être joignable par des chemins que votre politique n'a jamais envisagés. Écrivez des règles pour les deux, ou contrôlez délibérément IPv6 sur les sous-réseaux de DC.
• Les DC en lecture seule dans les sites distants ou en périphérie. Un RODC a besoin des ports de réplication vers un DC accessible en écriture, mais dans un seul sens pour la réplication entrante. Traitez le sous-réseau du RODC comme moins fiable que celui des DC centraux, et ne le laissez pas atteindre les ports d'administration des DC accessibles en écriture.
• Les autres forêts. Les approbations nécessitent Kerberos, LDAP, DNS, SMB et RPC entre les DC des deux forêts. Limitez ces règles aux adresses des DC du partenaire, pas à tout son réseau.

Facultatif : fixer les services RPC sur des ports statiques

Si votre équipe réseau exige des règles étroites, vous pouvez fixer les services RPC les plus sollicités sur des ports statiques. Microsoft prend en charge ces paramètres ; ils nécessitent un redémarrage du service concerné (en pratique, un redémarrage du DC) :

$ntds     = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters'
$netlogon = 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters'
Set-ItemProperty $ntds     -Name 'TCP/IP Port' -Value 50100 -Type DWord   # Réplication AD / DRSUAPI
Set-ItemProperty $netlogon -Name 'DCTcpipPort' -Value 50101 -Type DWord   # Netlogon
dfsrdiag StaticRPC /port:50102 /Member:DC01.corp.example.com               # DFSR (SYSVOL)

Cela resserre le trafic de réplication, mais ne supprime pas le besoin de la plage dynamique, car d'autres interfaces RPC l'utilisent toujours. Considérez-le comme facultatif.

Mesurer : ce qui communique réellement avec vos DC

N'écrivez pas un jeu de règles à partir d'un seul tableau de ports. Avant de bloquer quoi que ce soit, activez la journalisation du pare-feu pour les connexions autorisées et rejetées sur chaque DC. Cela doit être un paramètre de GPO sous Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security > Windows Defender Firewall Properties > Domain Profile > Logging. L'équivalent PowerShell, utile pour un DC pilote :

Set-NetFirewallProfile -Profile Domain,Private,Public `
    -LogAllowed True -LogBlocked True -LogMaxSizeKilobytes 32767 `
    -LogFileName '%systemroot%\system32\LogFiles\Firewall\pfirewall.log'

Collectez deux à quatre semaines de journaux, en incluant une fin de mois et un cycle de correctifs. Synthétisez ensuite par port de destination, sous-réseau source et sens. Une façon rapide de voir les sessions sortantes actives initiées par un DC :

Get-NetTCPConnection -State Established |
    Where-Object { $_.RemoteAddress -notmatch '^(127\.|::1)' -and $_.LocalPort -gt 1023 } |
    Group-Object RemoteAddress, RemotePort | Sort-Object Count -Descending |
    Select-Object Count, Name -First 40

Attendez-vous à des flux sortants vers les autres DC, les redirecteurs DNS, votre serveur WSUS ou de correctifs, les sources de temps, le SIEM ou le collecteur de journaux, les serveurs de sauvegarde et les emplacements CRL/AIA de la PKI. Tout le reste doit avoir un propriétaire. Les agents de supervision et les outils de sauvegarde qui « appellent la maison » vers un cloud éditeur sont les surprises habituelles.

Appliquer sur le réseau

Implémentez la politique principale sur le pare-feu réseau ou la plateforme de segmentation placée devant le sous-réseau des DC, afin que les administrateurs locaux du DC ne puissent pas l'annuler :

# Inbound to DC subnet
ALLOW  client/server subnets -> DCs   53,88,123,135,389,445,464,636,3268,3269,49152-65535
ALLOW  DC subnets            -> DCs   any
ALLOW  Tier 0 PAW subnet     -> DCs   3389,5985,5986,9389 (+ above)
DENY   any                   -> DCs   3389,5985,5986,9389
DENY   any                   -> DCs   any   (log)

# Outbound from DC subnet
ALLOW  DCs -> DC subnets, DNS forwarders, WSUS, NTP, SIEM, backup, CRL/AIA
DENY   DCs -> workstation and user-server subnets  445, 80, 443   (log)
DENY   DCs -> internet                            any            (log)

C'est le refus sortant vers les sous-réseaux de postes de travail sur 445 et 80/443 qui retire l'essentiel de son intérêt à la coercition d'authentification. Un DC qui ne peut pas ouvrir de session SMB ou HTTP vers l'hôte de l'attaquant ne peut pas être relayé depuis celui-ci. Si un proxy est nécessaire pour les mises à jour, n'y publiez que les points de terminaison de mise à jour Microsoft, jamais la navigation générale.

Appliquer sur l'hôte

Le pare-feu de l'hôte est votre deuxième couche, et la seule pour le trafic au sein d'un même sous-réseau. Configurez-le dans une GPO liée uniquement à l'UO Domain Controllers, sous Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security :

• Firewall state: On pour tous les profils. Inbound connections: Block (default). Outbound connections: Allow (default) tant que vous n'avez pas suffisamment cartographié les flux sortants pour basculer.
• Sous Customize pour chaque profil : Apply local firewall rules: No et Apply local connection security rules: No, afin que les modifications locales et les programmes d'installation ne puissent pas ajouter d'exceptions.
• Comme les règles locales ne sont plus fusionnées, les règles activées localement par le rôle AD DS ne comptent plus. Ajoutez les groupes de règles prédéfinis dans la GPO elle-même (New Inbound Rule > Predefined) : Active Directory Domain Services (qui inclut aussi la règle NTP de W32Time), DNS Service, DFS Replication, Kerberos Key Distribution Center, Netlogon Service et Core Networking. Pilotez cela d'abord sur un seul DC.
• N'ajoutez pas les groupes prédéfinis Remote Desktop ou Windows Remote Management, qui autorisent n'importe quelle adresse distante. Créez plutôt des règles restreintes.

# Règles d'administration restreintes écrites directement dans la GPO de pare-feu des DC
$gpo = 'corp.example.com\DC - Firewall'
New-NetFirewallRule -PolicyStore $gpo -DisplayName 'T0 - RDP from PAW' -Direction Inbound `
    -Protocol TCP -LocalPort 3389 -RemoteAddress 10.10.50.0/24 -Action Allow -Profile Domain
New-NetFirewallRule -PolicyStore $gpo -DisplayName 'T0 - WinRM from PAW' -Direction Inbound `
    -Protocol TCP -LocalPort 5985,5986 -RemoteAddress 10.10.50.0/24 -Action Allow -Profile Domain
New-NetFirewallRule -PolicyStore $gpo -DisplayName 'T0 - ADWS from PAW' -Direction Inbound `
    -Protocol TCP -LocalPort 9389 -RemoteAddress 10.10.50.0/24 -Action Allow -Profile Domain

Rappelez-vous que le Pare-feu Windows traite les règles de blocage avant les règles d'autorisation. Si vous voulez « refuser le RDP depuis partout sauf le sous-réseau des PAW », restreignez la règle d'autorisation et supprimez les autorisations larges. N'ajoutez pas de blocage large, car il l'emporterait aussi sur votre autorisation restreinte. Associez les règles réseau aux restrictions d'attribution des droits utilisateur de la base et au modèle des postes d'administration sécurisés, afin que le sous-réseau des PAW ne contienne réellement que des PAW.

Vérifier

Testez depuis trois emplacements : un poste de travail standard, un PAW et un autre DC.

# Depuis un poste standard : True attendu sur les ports d'authentification, False sur les ports d'administration
'DC01' | ForEach-Object {
    foreach ($p in 53,88,389,445,636,3268,3389,5985,9389) {
        [PSCustomObject]@{ Port = $p; Open = (Test-NetConnection $_ -Port $p -WarningAction SilentlyContinue).TcpTestSucceeded }
    }
}

# Depuis un DC : confirmer l'absence de flux sortant vers Internet
Test-NetConnection www.example.org -Port 443

# État de la réplication et du localisateur après toute modification
repadmin /replsummary
dcdiag /test:replications /test:netlogons /test:advertising /e /q
nltest /dsgetdc:corp.example.com

Sur chaque DC, confirmez la stratégie effective avec Get-NetFirewallProfile -PolicyStore ActiveStore et vérifiez qu'aucune règle locale n'est fusionnée. Examinez chaque semaine, pendant le premier mois, pfirewall.log et les journaux de refus du pare-feu réseau. Chaque flux légitime refusé est soit une règle oubliée, soit un agent qui ne devrait pas communiquer avec un DC.

Ce que cela casse

• Les outils d'administration à distance sur les postes ordinaires. Les consoles RSAT, le module PowerShell ActiveDirectory (ADWS sur 9389), Enter-PSSession et le RDP depuis les postes du support cessent de fonctionner vers les DC. C'est l'objectif. Déplacez ce travail sur des PAW, ou déléguez-le à des outils qui n'ont pas besoin d'un accès de niveau DC.
• Les agents qui appellent la maison. Les agents de supervision, d'EDR et de sauvegarde qui joignent directement un cloud éditeur depuis le DC échouent une fois l'accès Internet sortant fermé. Faites-les passer par un proxy approuvé ou un relais situé dans la zone d'administration Tier 0.
• Les connexions initiées par le DC vers les membres. Un gpupdate /force distant lancé depuis un DC, les scripts qui poussent des fichiers d'un DC vers des serveurs et certains modèles historiques de distribution logicielle cessent de fonctionner. Rien de tout cela ne devrait s'exécuter depuis un DC.
• La réplication, si vous resserrez trop. Fixer les ports RPC puis oublier un DC ou un nouveau lien de sites est la panne auto-infligée classique. Laissez le trafic entre DC entièrement ouvert entre les sous-réseaux de DC.
• Les clients NetBIOS historiques qui dépendaient des ports 137-139 perdent la navigation réseau et la résolution de noms.

Pour aller plus loin : la base DC, définir le Tier 0 pour décider quels hôtes d'administration ont leur place dans le sous-réseau des PAW, et imposer la signature SMB pour le trafic que vous autorisez encore.