Domänen- und Serverisolation mit IPsec

Firewallregeln auf Basis von IP-Adressen beantworten die Frage „Woher kommt dieses Paket?“. Angreifer sind gut darin, vom richtigen Ort zu kommen: von einem kompromittierten Arbeitsplatz im richtigen Subnetz oder einem Laptop, der in einem Besprechungsraum eingesteckt wurde. IPsec-Verbindungssicherheitsregeln stellen eine stärkere Frage: „Welcher authentifizierte Computer oder Benutzer ist am anderen Ende?“

Mit Domänenisolation nehmen Domänenmitglieder eingehenden Verkehr nur von anderen authentifizierten Domänenmitgliedern an. Mit Serverisolation nimmt ein sensibler Server Verkehr nur von bestimmten, per Kerberos identifizierten Computern oder Benutzern an, unabhängig von der IP-Adresse. Beides wird aus denselben Komponenten der Windows-Firewall gebaut, die Sie bereits per Gruppenrichtlinie im großen Maßstab verwalten, und baut auf den Begrenzungsprinzipien aus dem Leitfaden zur Härtung der Windows-Firewall auf.

Dies ist eine fortgeschrittene Maßnahme. Sie ändert, wie jede Verbindung aufgebaut wird, daher ist der Rollout ebenso wichtig wie die Konfiguration.

Die Bausteine

Verbindungssicherheitsregeln lassen für sich genommen keinen Verkehr zu. Sie sorgen dafür, dass Verkehr authentifiziert ist; die Firewallregeln entscheiden dann, ob authentifizierter Verkehr von diesem Partner zugelassen wird.

Schritt 1: IPsec-Standardwerte festlegen

GPO-Pfad: Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security, Eigenschaften, Registerkarte IPsec Settings, Customize:

In PowerShell sind Kryptosätze eigene Objekte, auf die Regeln verweisen:

$mm = New-NetIPsecMainModeCryptoProposal -Encryption AES256 -Hash SHA256 -KeyExchange DH19
New-NetIPsecMainModeCryptoSet -Name 'MM-Strong' -DisplayName 'MM-Strong' -Proposal $mm -PolicyStore 'corp.example.com\FW-IPsec'

$qm = New-NetIPsecQuickModeCryptoProposal -Encapsulation ESP -ESPHash SHA256
New-NetIPsecQuickModeCryptoSet -Name 'QM-Integrity' -DisplayName 'QM-Integrity' -Proposal $qm -PolicyStore 'corp.example.com\FW-IPsec'

$auth = New-NetIPsecAuthProposal -Machine -Kerberos
New-NetIPsecPhase1AuthSet -Name 'P1-ComputerKerberos' -DisplayName 'P1-ComputerKerberos' -Proposal $auth -PolicyStore 'corp.example.com\FW-IPsec'

Regeln verweisen auf diese Sätze über ihren Name, nicht über den Anzeigenamen. Deshalb erhält jeder Satz ein explizites -Name; ohne diesen Parameter erzeugt Windows eine GUID, und die folgende Regel findet den Satz nicht.

Schritt 2: Domänenisolation im Anforderungsmodus

Legen Sie in einer neuen, mit einer Pilot-OU verknüpften GPO eine Verbindungssicherheitsregel vom Typ Isolation an:

• Requirements: Request authentication for inbound and outbound connections.
• Authentication method: Computer (Kerberos V5).
• Profile: Domain.

New-NetIPsecRule -DisplayName 'Domain isolation' -InboundSecurity Request -OutboundSecurity Request `
  -Phase1AuthSet 'P1-ComputerKerberos' -Profile Domain -PolicyStore 'corp.example.com\FW-IPsec'

Der Anforderungsmodus blockiert nie etwas. Domänenmitglieder, die beide die Regel haben, handeln Sicherheitszuordnungen aus; alles andere fällt auf Klartextverkehr zurück. Diese Phase zeigt Ihnen ohne Ausfall, welche Partner sich authentifizieren können und welche nicht.

Fügen Sie Authentifizierungsausnahmen für Infrastruktur hinzu, die IPsec nicht aushandeln kann oder soll:

• Domänencontroller, damit Clients die Kerberos-Tickets erhalten, die IPsec selbst benötigt. Belassen Sie DCs im Anforderungsmodus statt im Erzwingungsmodus.
• DHCP- und DNS-Server, sofern sie keine DCs sind.
• Netzwerkgeräte, Drucker, IoT und Nicht-Windows-Systeme, die mit Domänenmitgliedern sprechen.

Halten Sie die Ausnahmeliste klein, dokumentiert und auf Adressen beschränkt, die Sie kontrollieren; jede Ausnahme ist ein Loch im Modell.

Schritt 3: eingehende Authentifizierung erzwingen

Sobald die Überwachung zeigt, dass nahezu der gesamte Domänenverkehr geschützt ist (siehe den Überwachungsabschnitt unten), stellen Sie zuerst Server, dann Arbeitsplätze auf Require inbound and request outbound um. Geräte ohne Domänenidentität können dann keine Verbindungen mehr zu ihnen aufbauen. Ausgehend bleibt es bei request, damit Domänenmitglieder weiterhin ausgenommene und Nicht-Windows-Systeme erreichen.

Vermeiden Sie Require inbound and outbound außer für streng kontrollierte Servergruppen: Es bricht jede ausgehende Verbindung zu einem Partner, der IPsec nicht aushandeln kann.

Schritt 4: Serverisolation für sensible Systeme

Legen Sie für einen sensiblen Server, etwa eine Finanzdatenbank oder einen Tier-0-Managementserver, eingehende Firewallregeln an, die nur authentifizierten Verkehr von autorisierten Computern annehmen:

1. Legen Sie eine Computersicherheitsgruppe an, zum Beispiel IPsec-FinanceDB-Clients, mit den Anwendungsservern, die sich verbinden dürfen.
2. Legen Sie auf dem Server eine eingehende Zulassungsregel für den Dienstport mit Allow the connection if it is secure an und autorisieren Sie auf der Registerkarte Remote Computers nur diese Gruppe. Optional fügen Sie Remote Users für eine Autorisierung auf Benutzerebene hinzu (dafür ist eine zweite Authentifizierung mit Benutzer-Kerberos nötig).
3. Entfernen Sie jede andere Zulassungsregel für diesen Port.

$sid = (Get-ADGroup 'IPsec-FinanceDB-Clients').SID.Value
New-NetFirewallRule -DisplayName 'SQL 1433 - authorised computers only' -Direction Inbound `
  -Protocol TCP -LocalPort 1433 -Action Allow -Authentication Required `
  -RemoteMachine "D:(A;;CC;;;$sid)" -Profile Domain -PolicyStore 'corp.example.com\FW-FinanceDB'

Ergänzen Sie -Encryption Required, wo das Protokoll nicht bereits verschlüsselt. Die Mitgliedschaft in Computergruppen wird im Kerberos-Ticket transportiert. Das Hinzufügen eines Computers zur Gruppe wird daher erst wirksam, wenn das Ticket dieses Computers erneuert wird (Neustart oder klist purge -li 0x3e7).

Dasselbe Muster liefert Ihnen identitätsbasierten Managementzugriff: RDP und WinRM auf Tier-0-Servern werden nur von Computern in einer Gruppe Tier0-PAW angenommen, was zum Admin-Tiering und zum Tier-Modell passt.

Was IPsec verhindert und was nicht

IPsec-Isolation macht ein nicht verwaltetes Gerät im Netzwerk für den Zugriff auf Domänenmitglieder weitgehend nutzlos und macht IP-Spoofing und einfache Netzwerk-Relays gegen isolierte Server wirkungslos. Sie ergänzt die Protokollhärtung wie SMB-Signierung und NTLM-Einschränkungen aus dem Leitfaden zu Legacy-Protokollen, ersetzt sie aber nicht: Ein Angreifer, der einen domänengebundenen Computer kontrolliert, authentifiziert sich als dieser Computer. Serverisolation begrenzt, welche Domänencomputer in Frage kommen; Schutzmaßnahmen gegen NTLM relay bleiben wichtig.

Was kaputtgeht

• Load Balancer und NAT zwischen Clients und Servern: Der IPsec-Transportmodus wird Ende-zu-Ende ausgehandelt, ein Load Balancer, der Verbindungen terminiert oder umschreibt, bricht also die Authentifizierung. Nehmen Sie die VIP aus oder schützen Sie den Verkehr nur hinter dem Load Balancer.
• Netzwerküberwachung und IDS verlieren die Sicht auf die Nutzdaten, wenn Sie Verschlüsselung erzwingen. ESP nur mit Integrität lässt Pakete lesbar.
• Systeme außerhalb der Domäne und aus anderen Gesamtstrukturen brauchen Zertifikate oder Ausnahmen.
• Kerberos-Probleme werden zu Verbindungsproblemen: Zeitabweichungen, defekte SPNs oder unerreichbare DCs zeigen sich jetzt als fehlgeschlagene Verbindungen.
• Leistung: Der CPU-Overhead ist auf moderner Hardware mit NIC-Offload gering, testen Sie aber Server mit hohem Durchsatz.
• Fehlersuche ist für Teams ohne IPsec-Erfahrung schwieriger. Schulen Sie Netzwerk- und Serverteams vor der Erzwingung.

Sicherheitszuordnungen überwachen

Aktivieren Sie die IPsec-Überwachung unter Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff: Audit IPsec Main Mode und Audit IPsec Quick Mode (mindestens Fehler), dazu System > Audit IPsec Driver. Nützliche Ereignisse im Sicherheitsprotokoll:

Ein Anstieg von 4653 nach dem Wechsel in den Erzwingungsmodus deutet auf Partner ohne gültige Identität hin: genau die Geräte, die Sie ausnehmen oder reparieren müssen. Erfolgsereignisse sind sehr zahlreich; sammeln Sie Fehler zentral und Erfolge stichprobenartig.

Überprüfen

Auf einem Server im Geltungsbereich:

Get-NetIPsecRule -PolicyStore ActiveStore | Select-Object DisplayName, InboundSecurity, OutboundSecurity, Enabled
Get-NetIPsecMainModeSA | Select-Object RemoteEndpoint, LocalFirstId, RemoteFirstId
Get-NetIPsecQuickModeSA | Select-Object RemoteEndpoint, RemotePort, LocalPort

RemoteFirstId zeigt die authentifizierte Computeridentität jedes Partners. Unter wf.msc > Monitoring > Security Associations sehen Sie dieselben Daten grafisch. Testen Sie dann negativ: Von einem nicht domänengebundenen Laptop im selben Subnetz sollte Test-NetConnection <server> -Port 445 fehlschlagen, sobald der Server eingehende Authentifizierung erzwingt, während ein Domänenmitglied in der autorisierten Gruppe sich weiterhin verbindet.

Checkliste

• IPsec-Standardwerte gesetzt: kein SHA-1 oder DH-Gruppe 2, ICMP ausgenommen
• Domänenisolationsregel im Anforderungsmodus zuerst in einem Pilot, dann breit ausgerollt
• DCs, DHCP, DNS und Nicht-Windows-Infrastruktur ausgenommen und dokumentiert
• Server nach Messung der SA-Abdeckung auf „eingehend erzwingen, ausgehend anfordern“ umgestellt
• Sensible Server per „allow if secure“ auf autorisierte Computergruppen beschränkt
• Verschlüsselung nur erzwungen, wo das Protokoll sich nicht selbst schützt
• Fehler in IPsec Main Mode und Quick Mode überwacht und weitergeleitet

Die vollständige Reihe, einschließlich Protokollierung und Richtlinienverwaltung, finden Sie im Thema Windows-Firewall.