Firewall für Domänencontroller: Ports, Egress, Admin-Zugriff

Ein Domänencontroller muss für jedes Domänenmitglied erreichbar sein. Deshalb wird oft angenommen, er lasse sich nicht per Firewall absichern. Das stimmt nicht. Clients brauchen eine bekannte Menge an Authentifizierungs- und Verzeichnisports, aber weder RDP noch WinRM noch Remote-Dienstverwaltung. Der DC selbst muss so gut wie nie eine Verbindung zu einer Arbeitsstation oder ins Internet aufbauen. Wer diese drei Punkte richtig umsetzt, beseitigt in einem Zug Lateral Movement auf DCs, Relay-Pfade für Coercion und Command-and-Control-Egress.

Die DC-Baseline formuliert das Egress-Prinzip. Dieser Leitfaden macht daraus eine Richtlinie, die Sie ausrollen können. Er behandelt die Portmatrix, das Messen des tatsächlichen Verkehrs vor dem Blockieren, Host- und Netzwerkregeln, Verwaltungszugriff ausschließlich aus Tier 0 und die Prüfung, dass nichts kaputtgegangen ist.

Die Portmatrix

Teilen Sie den DC-Verkehr in drei Flüsse auf. Jeder Fluss hat andere Quellen und andere Regeln.

Clients und Mitgliedsserver zu DCs (eingehend):

DC zu DC (Replikation, in beide Richtungen): alles oben Genannte plus die von DRSUAPI und DFSR genutzten RPC-Ports. Lassen Sie den gesamten DC-zu-DC-Verkehr zwischen DC-Subnetzen zu. Die Fehlersuche bei einem Replikationsausfall wegen einer allzu cleveren ACL lohnt sich nicht.

Verwaltung (nur Tier 0): 3389 (RDP), 5985/5986 (WinRM), 9389 (AD Web Services, genutzt vom PowerShell-Modul ActiveDirectory und von ADAC) sowie RPC für MMC-Snap-Ins. Diese Zugriffe kommen ausschließlich von PAWs oder Tier-0-Jump-Hosts.

Legacy-NetBIOS (UDP 137/138, TCP 139) wird nur benötigt, wenn Sie noch NetBIOS-abhängige Clients haben. Schalten Sie es zusammen mit LLMNR und NBT-NS ab, wie in LLMNR, NetBIOS und WPAD deaktivieren beschrieben.

Was gern vergessen wird

• ICMP. Die Gruppenrichtlinienverarbeitung und einige DC-Locator-Prüfungen verwenden ICMP-Echo, um langsame Verbindungen zu erkennen. Lassen Sie ICMP Echo Request/Reply von Client-Subnetzen zu den DCs zu, statt es zu blockieren und später seltsames GPO-Verhalten zu untersuchen.
• IPv6. Windows bevorzugt IPv6, wenn es verfügbar ist. Decken Ihre Netzwerkregeln nur IPv4 ab, kann ein DC mit Link-Local- oder SLAAC-Adresse auf Wegen erreichbar sein, die Ihre Richtlinie nie berücksichtigt hat. Schreiben Sie Regeln für beide Protokolle oder steuern Sie IPv6 in DC-Subnetzen bewusst.
• Schreibgeschützte DCs in Filial- oder Perimeterstandorten. Ein RODC braucht die Replikationsports zu einem beschreibbaren DC, für eingehende Replikation aber nur in eine Richtung. Behandeln Sie das RODC-Subnetz als weniger vertrauenswürdig als das Kern-DC-Subnetz und lassen Sie es keine Verwaltungsports auf beschreibbaren DCs erreichen.
• Andere Gesamtstrukturen. Vertrauensstellungen benötigen Kerberos, LDAP, DNS, SMB und RPC zwischen den DCs beider Gesamtstrukturen. Beschränken Sie diese Regeln auf die DC-Adressen des Partners, nicht auf dessen gesamtes Netz.

Optional: RPC-Dienste an feste Ports binden

Besteht Ihr Netzwerkteam auf engen Regeln, können Sie die meistgenutzten RPC-Dienste an statische Ports binden. Microsoft unterstützt diese Einstellungen; sie erfordern einen Neustart des betroffenen Dienstes (in der Praxis einen Neustart des 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   # AD-Replikation / DRSUAPI
Set-ItemProperty $netlogon -Name 'DCTcpipPort' -Value 50101 -Type DWord   # Netlogon
dfsrdiag StaticRPC /port:50102 /Member:DC01.corp.example.com               # DFSR (SYSVOL)

Das engt den Replikationsverkehr ein, macht den dynamischen Bereich aber nicht überflüssig, weil andere RPC-Schnittstellen ihn weiterhin nutzen. Betrachten Sie es als optional.

Messen: Was kommuniziert tatsächlich mit Ihren DCs?

Schreiben Sie ein Regelwerk nicht allein anhand einer Porttabelle. Bevor Sie etwas blockieren, aktivieren Sie auf jedem DC die Firewall-Protokollierung für zugelassene und verworfene Verbindungen. Das sollte eine GPO-Einstellung unter Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security > Windows Defender Firewall Properties > Domain Profile > Logging sein. Das PowerShell-Äquivalent, nützlich für einen Pilot-DC:

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

Sammeln Sie zwei bis vier Wochen Protokolle, einschließlich eines Monatsabschlusses und eines Patch-Zyklus. Fassen Sie sie dann nach Zielport, Quellsubnetz und Richtung zusammen. Ein schneller Weg, die ausgehenden Sitzungen zu sehen, die ein DC gerade aufbaut:

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

Erwarten Sie ausgehende Flüsse zu anderen DCs, DNS-Weiterleitungen, Ihrem WSUS- oder Patch-Server, Zeitquellen, dem SIEM oder Log-Collector, Backup-Servern sowie PKI-Speicherorten für CRL/AIA. Alles andere braucht einen Verantwortlichen. Monitoring-Agenten und Backup-Tools, die „nach Hause telefonieren“ – in die Cloud des Herstellers –, sind die üblichen Überraschungen.

Im Netzwerk durchsetzen

Setzen Sie die Kernrichtlinie auf der Netzwerk-Firewall oder der Segmentierungsplattform vor dem DC-Subnetz um, damit die lokalen Administratoren des DC sie nicht rückgängig machen können:

# 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)

Die ausgehende Sperre zu Arbeitsstations-Subnetzen auf 445 und 80/443 nimmt Authentication Coercion den größten Teil ihres Werts. Ein DC, der keine SMB- oder HTTP-Verbindung zum Host des Angreifers öffnen kann, lässt sich von dort nicht relayen. Wird für Updates ein Proxy benötigt, veröffentlichen Sie darüber nur die Microsoft-Update-Endpunkte, niemals allgemeines Surfen.

Auf dem Host durchsetzen

Die Host-Firewall ist Ihre zweite Schicht – und die einzige für Verkehr innerhalb desselben Subnetzes. Konfigurieren Sie sie in einer GPO, die nur mit der OU Domain Controllers verknüpft ist, unter Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security:

• Firewall state: On für alle Profile. Inbound connections: Block (default). Outbound connections: Allow (default), bis Sie den ausgehenden Verkehr gut genug kennen, um umzustellen.
• Unter Customize für jedes Profil: Apply local firewall rules: No und Apply local connection security rules: No, damit lokale Änderungen und Installationsprogramme keine Ausnahmen hinzufügen können.
• Da lokale Regeln nicht mehr zusammengeführt werden, zählen die von der AD-DS-Rolle lokal aktivierten Regeln nicht mehr. Fügen Sie die vordefinierten Regelgruppen in die GPO selbst ein (New Inbound Rule > Predefined): Active Directory Domain Services (enthält auch die NTP-Regel für W32Time), DNS Service, DFS Replication, Kerberos Key Distribution Center, Netlogon Service und Core Networking. Testen Sie das zuerst auf einem einzelnen DC.
• Fügen Sie die vordefinierten Gruppen Remote Desktop oder Windows Remote Management nicht hinzu – sie erlauben jede Remote-Adresse. Legen Sie stattdessen eingeschränkte Regeln an.

# Eingeschränkte Verwaltungsregeln direkt in die DC-Firewall-GPO schreiben
$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

Denken Sie daran, dass die Windows-Firewall Sperrregeln vor Zulassungsregeln verarbeitet. Wenn Sie „RDP von überall außer dem PAW-Subnetz verweigern“ wollen, schränken Sie die Zulassungsregel ein und entfernen Sie die breiten Zulassungen. Fügen Sie keine breite Sperrregel hinzu, denn sie überstimmt auch Ihre eingeschränkte Zulassung. Kombinieren Sie Netzwerkregeln mit den Einschränkungen beim Zuweisen von Benutzerrechten aus der Baseline und mit dem Modell der Privileged Access Workstations, damit das PAW-Subnetz wirklich nur PAWs enthält.

Überprüfen

Testen Sie von drei Stellen aus: von einer Standard-Arbeitsstation, einer PAW und einem anderen DC.

# Von einer Standard-Arbeitsstation: True bei Authentifizierungsports, False bei Verwaltungsports erwartet
'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 }
    }
}

# Von einem DC: bestätigen, dass kein Internet-Egress möglich ist
Test-NetConnection www.example.org -Port 443

# Zustand von Replikation und Locator nach jeder Änderung
repadmin /replsummary
dcdiag /test:replications /test:netlogons /test:advertising /e /q
nltest /dsgetdc:corp.example.com

Bestätigen Sie auf jedem DC die wirksame Richtlinie mit Get-NetFirewallProfile -PolicyStore ActiveStore und prüfen Sie, dass keine lokalen Regeln zusammengeführt werden. Werten Sie im ersten Monat wöchentlich pfirewall.log und die Sperrprotokolle der Netzwerk-Firewall aus. Jeder legitime, verworfene Fluss ist entweder eine vergessene Regel oder ein Agent, der nicht mit einem DC sprechen sollte.

Was dabei kaputtgeht

• Remote-Admin-Tools auf gewöhnlichen Arbeitsstationen. RSAT-Konsolen, das PowerShell-Modul ActiveDirectory (ADWS auf 9389), Enter-PSSession und RDP von Helpdesk-Desktops funktionieren gegen DCs nicht mehr. Genau das ist das Ziel. Verlagern Sie diese Arbeit auf PAWs oder delegieren Sie sie an Werkzeuge, die keinen Zugriff auf DC-Ebene benötigen.
• Agenten, die nach Hause telefonieren. Monitoring-, EDR- und Backup-Agenten, die direkt vom DC aus Hersteller-Clouds erreichen, schlagen fehl, sobald der Internet-Egress geschlossen ist. Leiten Sie sie über einen genehmigten Proxy oder ein Relay in der Tier-0-Verwaltungszone.
• Vom DC initiierte Verbindungen zu Mitgliedern. Remote-gpupdate /force von einem DC, Skripte, die Dateien von einem DC auf Server verteilen, und einige ältere Softwareverteilungsmodelle funktionieren nicht mehr. Nichts davon sollte von einem DC aus laufen.
• Replikation, wenn Sie zu eng filtern. RPC-Ports festzulegen und dann einen DC oder eine neue Standortverknüpfung zu vergessen, ist der klassische selbstverschuldete Ausfall. Halten Sie den DC-zu-DC-Verkehr zwischen DC-Subnetzen vollständig offen.
• Legacy-NetBIOS-Clients, die auf 137–139 angewiesen waren, verlieren Suchdienst und Namensauflösung.

Weiterführende Lektüre: die DC-Baseline, Tier 0 definieren, um zu entscheiden, welche Verwaltungshosts ins PAW-Subnetz gehören, und SMB-Signierung erzwingen für den Verkehr, den Sie weiterhin zulassen.