Windows-Firewall gegen Lateral Movement härten

Jeder unterstützte Windows-Rechner bringt eine leistungsfähige, zustandsbehaftete Host-Firewall mit. In vielen Umgebungen ist sie entweder abgeschaltet („das erledigt die Netzwerk-Firewall“) oder im Auslieferungszustand belassen, in dem Installationsprogramme und lokale Admins nach Belieben eingehende Regeln anlegen. Richtig eingesetzt ist sie eine der günstigsten und wirksamsten Maßnahmen gegen Lateral Movement: die Technik, die aus einem kompromittierten Laptop ein kompromittiertes Netzwerk macht.

Dieser Leitfaden baut eine Richtlinie für Arbeitsplätze und Server per Gruppenrichtlinie auf (dieselben Einstellungen gibt es in Intune unter Endpoint security > Firewall).

Grundsätze

1. Alle drei Profile aktiv (Domäne, Privat, Öffentlich), per Richtlinie erzwungen.
2. Eingehend standardmäßig: blockieren. Nur explizit zugelassener Verkehr kommt herein.
3. Nur zentrale Regeln zählen. Das Zusammenführen lokaler Regeln ist deaktiviert.
4. Admin-Protokolle nur aus Admin-Netzen. RDP, WinRM, SMB, RPC und WMI sind von Jump-Hosts und PAWs erreichbar, nicht von jedem anderen Client.
5. Verworfene Pakete protokollieren, das Log ausreichend dimensionieren und einsammeln.

Schritt 1: Profileinstellungen

GPO-Pfad: Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security. Öffnen Sie die Eigenschaften und setzen Sie für jedes der Profile Domäne, Privat und Öffentlich:

Das PowerShell-Äquivalent, nützlich zum Testen auf einem einzelnen Rechner:

Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True `
  -DefaultInboundAction Block -DefaultOutboundAction Allow `
  -NotifyOnListen False -AllowLocalFirewallRules False `
  -LogBlocked True -LogMaxSizeKilobytes 16384 `
  -LogFileName "%SystemRoot%\System32\LogFiles\Firewall\pfirewall.log"

Den effektiven Zustand prüfen (das zusammengeführte Ergebnis aus lokalen und Gruppenrichtlinien-Einstellungen):

Get-NetFirewallProfile -PolicyStore ActiveStore |
  Select-Object Name, Enabled, DefaultInboundAction, AllowLocalFirewallRules, LogBlocked

Mit AllowLocalFirewallRules auf False werden Regeln ignoriert, die Installationsprogramme lokal angelegt haben. Das ist beabsichtigt und der Grund, vor dem Rollout zu inventarisieren, welche eingehenden Regeln Ihre Anwendungen wirklich brauchen (Schritt 3).

Schritt 2: Regeln für Arbeitsplätze

Arbeitsplätze brauchen sehr wenig eingehenden Verkehr. Eine realistische Zulassungsliste:

Alles andere, insbesondere SMB, RPC und WinRM von anderen Arbeitsplätzen, bleibt blockiert. Diese eine Entscheidung stoppt den Großteil des „Springens von Laptop zu Laptop“, das Ransomware-Affiliates nutzen.

Begrenzte Regeln sehen so aus (GPO-Regeln sind identisch, über die Registerkarte Scope):

New-NetFirewallRule -DisplayName "RDP from Tier2 admin subnet" -Direction Inbound `
  -Protocol TCP -LocalPort 3389 -RemoteAddress 10.20.50.0/24 -Action Allow -Profile Domain

New-NetFirewallRule -DisplayName "SMB from management servers" -Direction Inbound `
  -Protocol TCP -LocalPort 445 -RemoteAddress 10.20.10.11,10.20.10.12 -Action Allow -Profile Domain

Vorsicht bei vordefinierten Regelgruppen wie Remote Desktop, File and Printer Sharing oder Windows Remote Management: Wer die Gruppe aktiviert, aktiviert Regeln mit dem Remotebereich Any. Passen Sie entweder deren Bereich in der GPO an oder legen Sie stattdessen eigene, begrenzte Regeln an.

Schritt 3: Regeln für Server

Server brauchen eingehende Regeln für den bereitgestellten Dienst sowie begrenzten Managementzugriff:

• Anwendungsports (HTTPS 443 auf einem Webserver, 1433 auf SQL Server), begrenzt auf die Clients oder Load Balancer, die sie nutzen, und nicht „Any“, wenn es sich vermeiden lässt.
• Management-Ports, begrenzt auf Tier-1-Jump-Hosts oder PAWs.
• Auf Domänencontrollern muss der vollständige Satz an AD-Ports (Kerberos 88, LDAP 389/636, GC 3268/3269, DNS 53, SMB 445, RPC 135 und der dynamische Bereich) für alle Domänenmitglieder erreichbar bleiben; beschränken Sie die Management-Protokolle (RDP, WinRM) auf Tier-0-Admin-Hosts.

Inventarisieren Sie vor der Erzwingung, was tatsächlich lauscht und wer sich verbindet:

Get-NetTCPConnection -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess,
    @{n='Process';e={(Get-Process -Id $_.OwningProcess).ProcessName}} |
  Sort-Object LocalPort -Unique

Kombinieren Sie das mit einigen Tagen pfirewall.log bei aktivierter Protokollierung erfolgreicher Verbindungen, damit die Regeln der Realität entsprechen und nicht der Dokumentation.

Ausgehend auf Servern. Die meisten Server müssen nur mit einer bekannten Menge an Zielen sprechen: DNS, Domänencontroller, Updateserver, ihre Datenbank. Ausgehend standardmäßig verweigern, insbesondere auf Tier-0-Servern, erschwert Command-and-Control und Datenexfiltration erheblich. Beginnen Sie mit log successful connections, um die Liste aufzubauen, und stellen Sie dann die ausgehende Standardaktion mit Zulassungsregeln auf Block um.

Schritt 4: den üblichen Missbrauch blockieren

Einige zusätzliche Regeln, die sich lohnen:

• Eingehenden Verkehr im Public-Profil auf Laptops vollständig blockieren (das Standard-Block erledigt das, wenn Sie keine Public-Zulassungsregeln hinzufügen).
• Ausgehendes SMB (TCP 445) ins Internet auf Host-Ebene blockieren; dafür gibt es keinen legitimen Grund, und es verhindert Credential-Leaks durch erzwungene Authentifizierung gegenüber externen Hosts.
• mshta.exe, wscript.exe, cscript.exe und ähnliche Skript-Hosts an ausgehenden Verbindungen hindern, wo sie nicht genutzt werden. Anwendungssteuerung ist die stärkere Lösung, aber das hier ist billig.

New-NetFirewallRule -DisplayName "Block outbound SMB to Internet" -Direction Outbound `
  -Protocol TCP -RemotePort 445 -RemoteAddress Internet -Action Block

Internet ist ein integriertes Schlüsselwort, das das lokale Subnetz und die als Intranet definierten privaten Bereiche ausschließt; prüfen Sie, ob das zu Ihrer Adressierung passt, oder führen Sie Ihre internen Bereiche explizit in einer Zulassungsregel auf.

Schritt 5: Protokollierung und Überwachung

pfirewall.log ist ein reines Textlog auf jedem Host. Es ist bei Untersuchungen nützlich, wird aber selten eingesammelt. Optionen:

• Mit Ihrem Log-Agent einsammeln.
• Oder die Überwachung der Windows Filtering Platform aktivieren (Advanced Audit Policy > Object Access > Filtering Platform Connection, nur Fehler), die Sicherheitsereignisse 5157 für blockierte Verbindungen erzeugt. Mit Erfolgsüberwachung ist das sehr laut, also mit Fehlern beginnen und am Collector filtern.
• Änderungen an der Firewall-Konfiguration immer überwachen: Sicherheitsereignisse 4946-4948 (Regel hinzugefügt, geändert, gelöscht) und 4950 (Einstellung geändert) aus Audit MPSSVC Rule-Level Policy Change.

Ein Angreifer, der die Firewall abschaltet oder eine Zulassungsregel für sein Werkzeug hinzufügt, hinterlässt genau diese Ereignisse.

Checkliste

• Firewall in allen Profilen aktiv, per GPO oder Intune erzwungen
• Eingehend standardmäßig blockiert; Zusammenführen lokaler Regeln deaktiviert
• Arbeitsplätze nehmen RDP/WinRM/SMB/RPC nur von Admin- und Managementhosts an
• Vordefinierte Regelgruppen ersetzt oder neu begrenzt
• Serverregeln aus lauschenden Ports und beobachteten Verbindungen abgeleitet
• Tier-0-Server ausgehend standardmäßig verweigert
• Verworfene Pakete protokolliert; Alarme auf Regeländerungsereignisse 4946-4950

Host-Firewalls ergänzen das Admin-Tiering: Tiering verhindert, dass privilegierte Anmeldedaten auf Arbeitsplätze gelangen, und die Firewall verhindert, dass Arbeitsplätze als Sprungbrett taugen, selbst wenn doch einmal Anmeldedaten abfließen.