Windows-Firewall im großen Maßstab mit GPO und Intune

Die Windows-Firewall auf einem Rechner zu konfigurieren ist einfach. Tausende Rechner auf einer einheitlichen, beabsichtigten Richtlinie zu halten ist der Punkt, an dem die meisten Programme ins Stocken geraten: Regeln stapeln sich in vielen GPOs, Installationsprogramme legen lokale Regeln an, Intune und Gruppenrichtlinie greifen auf dieselben Geräte zu, und niemand kann sagen, welche Regel einen bestimmten Port eigentlich zulässt.

Der Leitfaden zur Härtung der Windows-Firewall definiert, was die Richtlinie sein soll. Dieser Leitfaden behandelt, wie man sie im großen Maßstab betreibt: wie sich Richtlinienquellen kombinieren, wie Regeln ausgewertet werden, wie man GPOs und Intune-Profile strukturiert und wie man nachweist, was ein Gerät tatsächlich erzwingt. Die vollständige Reihe finden Sie im Thema Windows-Firewall.

Wie Richtlinienspeicher kombiniert werden

Die Windows-Firewall hält Regeln in mehreren Speichern und führt sie zu einem aktiven Speicher zusammen, den die Engine erzwingt:

Es gelten zwei unterschiedliche Zusammenführungsverhalten:

• Regeln sind additiv. Jede Regel aus jeder GPO im Geltungsbereich landet im aktiven Speicher. Für Regeln gibt es kein „der Letzte gewinnt“.
• Profileinstellungen folgen der Rangfolge. Firewallstatus, ein- und ausgehende Standardaktion, Benachrichtigungen, Protokollierung und die Schalter für das lokale Zusammenführen sind Einzelwerte; bei der Gruppenrichtlinie gilt die normale LSDOU-Reihenfolge, und je Einstellung gewinnt die GPO mit dem höchsten Vorrang.

Die Folge: Eine Zulassungsregel für TCP 3389 von Any in einer vergessenen Alt-GPO, die am Domänenstamm verknüpft ist, wird auf jedem Rechner erzwungen, ganz gleich, wie sorgfältig Ihre neuen Rollen-GPOs RDP begrenzen.

Wie Regeln ausgewertet werden

Trifft ein Paket ein, wendet die Engine die Regeln in dieser Reihenfolge an:

1. Einschränkungen der Windows-Diensthärtung (integriert, nicht überschreibbar).
2. Verbindungssicherheitsregeln (IPsec), die Verkehr authentifizieren oder schützen.
3. Regeln für die authentifizierte Umgehung (Zulassungsregeln mit Override block rules, nur mit IPsec nutzbar).
4. Block-Regeln.
5. Allow-Regeln.
6. Die Standardaktion des Profils.

Block schlägt immer Allow. Ein häufiger Fehler ist eine weit gefasste Regel „SMB eingehend blockieren“, gefolgt von einer Regel „SMB von Managementservern zulassen“: Die Blockregel gewinnt, und das Management bricht. Mit einer eingehenden Standardaktion Block brauchen Sie explizite eingehende Blockregeln kaum je; drücken Sie die Absicht mit begrenzten Zulassungsregeln aus und behalten Sie explizite Blockregeln für Dinge, die nie passieren dürfen (zum Beispiel ausgehendes SMB ins Internet).

Schritt 1: lokales Zusammenführen überall deaktivieren

Klicken Sie in den Eigenschaften der Firewall-GPO für jedes Profil unter Settings auf Customize und setzen Sie Apply local firewall rules auf No sowie Apply local connection security rules auf No. In Intune heißen die entsprechenden Einstellungen im Firewallprofil Allow Local Policy Merge und Allow Local Ipsec Policy Merge, beide pro Profil auf False (Firewall-CSP MdmStore/<Profile>/AllowLocalPolicyMerge und AllowLocalIpsecPolicyMerge).

Lokale Regeln werden nicht gelöscht; sie bleiben im PersistentStore und werden einfach ignoriert. Das macht das Zurückrollen leicht, bedeutet aber auch, dass Sie wissen müssen, welche dieser lokalen Regeln tatsächlich wichtig waren. Exportieren Sie vor dem Umschalten in einer Pilotgruppe, was Installationsprogramme angelegt haben:

Get-NetFirewallRule -PolicyStore PersistentStore -Direction Inbound -Enabled True -Action Allow |
  ForEach-Object {
    $port = $_ | Get-NetFirewallPortFilter
    $app  = $_ | Get-NetFirewallApplicationFilter
    [pscustomobject]@{ Name=$_.DisplayName; Profile=$_.Profile; Protocol=$port.Protocol
                       LocalPort=$port.LocalPort; Program=$app.Program }
  } | Export-Csv "$env:TEMP\local-inbound-rules.csv" -NoTypeInformation

Sammeln Sie diese CSV aus einer repräsentativen Stichprobe ein, entfernen Sie, was niemand braucht, und machen Sie aus dem Rest zentrale Regeln.

Schritt 2: die GPOs strukturieren

Eine Aufteilung, die auch nach Jahren lesbar bleibt:

Richtlinien, die Wildwuchs verhindern:

• Ein Verantwortlicher pro GPO, im GPO-Kommentar benannt.
• Regelnamen enthalten Ticket oder Zweck (SQL-1433-from-AppTier-CHG1234), und die Regeleigenschaft Group ist gesetzt, damit Regeln als Satz gefiltert und ausgewertet werden können.
• Vordefinierte Regelgruppen nie aktivieren (Remote Desktop, File and Printer Sharing), ohne ihren Remotebereich anzupassen; standardmäßig steht er auf Any.
• Alt-GPOs auf Firewallregeln prüfen. Wer alle GPOs mit Get-GPOReport -All -ReportType Xml exportiert und die Ausgabe nach Firewallregel-Elementen durchsucht, findet vergessene Richtlinien schnell.

GPO-Firewallregeln lassen sich über eine GPO-Sitzung direkt per Skript in eine Richtlinie schreiben, was das Bearbeiten Hunderter Regeln von Hand erspart:

$gpo = Open-NetGPO -PolicyStore 'corp.example.com\FW-Role-SQL'
New-NetFirewallRule -GPOSession $gpo -DisplayName 'SQL-1433-from-AppTier' `
  -Group 'Role-SQL' -Direction Inbound -Protocol TCP -LocalPort 1433 `
  -RemoteAddress 10.30.20.0/24 -Profile Domain -Action Allow
Save-NetGPO -GPOSession $gpo

Legen Sie die Skripte in die Versionsverwaltung. Sie werden zu Ihrer Dokumentation und Ihrem Rollback.

Schritt 3: das Intune-Äquivalent

Im Intune Admin Center bietet Endpoint security > Firewall zwei Profiltypen für Windows:

• Windows Firewall (Profileinstellungen): Status, Standardaktionen, lokales Zusammenführen, Protokollierung, pro Profil.
• Windows Firewall Rules: einzelne Regeln. Ein Profil fasst eine begrenzte Anzahl an Regeln (zum Zeitpunkt des Schreibens 150), teilen Sie also wie bei GPOs nach Rollen auf.

Weisen Sie Regelprofile Gerätegruppen zu, die Ihre GPO-Rollen widerspiegeln, und nutzen Sie Zuweisungsfilter für Ausnahmen, statt Profile zu klonen. Intune unterstützt außerdem wiederverwendbare Einstellungsgruppen für Remote-IP-Bereiche: Das „Tier-2-Admin-Subnetz“ wird einmal definiert und von jeder Regel referenziert, die es braucht; ändern Sie den Bereich an einer Stelle, folgen alle Regeln.

Bei hybrid eingebundenen Geräten, die sowohl GPO- als auch Intune-Firewallrichtlinien erhalten, landen beide Regelsätze im aktiven Speicher. Vermeiden Sie überlappende Profileinstellungen: Wählen Sie eine Autorität pro Population und verschieben Sie Geräte explizit zwischen ihnen. Die Richtlinie MDMWinsOverGP gilt nur für Einstellungen im Policy CSP, nicht für den Firewall-CSP, und löst Überlappungen daher nicht auf. Der Firewall-CSP dokumentiert stattdessen eine eigene Zusammenführungsregel: Für Profileinstellungen wie Firewallstatus, eingehende Standardaktion und Protokollierungseinstellungen gewinnt ein per Gruppenrichtlinie konfigurierter Wert gegen den MDM-Wert. Auf hybriden Geräten überschreibt eine übrig gebliebene Firewall-GPO also stillschweigend Ihr Intune-Profil.

Schritt 4: Änderungsmanagement

Firewalländerungen legen die Produktion schneller lahm als die meisten Richtlinienänderungen. Ein praktikabler Prozess:

1. Anfrage mit Nachweis: welcher Prozess, Port, welche Richtung und Quelle, idealerweise belegt durch pfirewall.log oder 5157-Ereignisse aus der Firewallprotokollierung.
2. Pilot: zuerst mit einer Pilot-OU oder -Gruppe verknüpfen bzw. ihr zuweisen. Intune-Ringe oder GPO-Sicherheitsfilterung funktionieren beide.
3. Vorherigen Zustand festhalten: netsh advfirewall export auf einem Referenzhost und Backup-GPO für die Richtlinie.
4. Nach der Pilotphase auf den breiten Geltungsbereich ausweiten.
5. Vierteljährlich überprüfen: Regeln, die seit Monaten keinen Verkehr mehr getroffen haben, sind Kandidaten zum Entfernen. Wer auf einer Stichprobe vorübergehend die Erfolgsprotokollierung aktiviert, macht das messbar.

Was kaputtgeht

• Anwendungen, die bei der Installation eigene Regeln anlegen (Kollaborationsclients, Peer-to-Peer-Updatekomponenten, Entwicklerwerkzeuge, Virtualisierungs- und Containerplattformen), erhalten keinen eingehenden Verkehr mehr, sobald das lokale Zusammenführen aus ist. Die meisten modernen Clients arbeiten rein ausgehend; der Rest braucht eine zentrale Regel.
• Benutzerspezifische Programmpfade unter %LocalAppData% lassen sich zentral schwer abbilden. Verwenden Sie für solche Anwendungen besser port- und protokollbasierte Regeln, die auf die richtigen Remoteadressen begrenzt sind.
• Explizite Blockregeln, die als „alles blockieren außer“ gedacht waren, überschreiben stillschweigend später hinzugefügte Zulassungsregeln.
• Gemischte GPO- und Intune-Richtlinien lassen Regeln auftauchen, die keines der beiden Teams kennt.
• Übermittlungsoptimierung (Delivery Optimization) mit Peer-Caching (TCP 7680) und ähnliche Funktionen funktionieren zwischen Clients nicht mehr, wenn Sie sie nicht zulassen; entscheiden Sie das bewusst.

Überprüfen

Der aktive Speicher ist die Wahrheit. Fragen Sie ihn, woher jede Regel stammt:

Get-NetFirewallRule -PolicyStore ActiveStore |
  Group-Object PolicyStoreSourceType | Select-Object Name, Count

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound -Action Allow -Enabled True |
  Select-Object DisplayName, PolicyStoreSource, Profile |
  Sort-Object PolicyStoreSource

PolicyStoreSource nennt für jede Regel die GPO oder den Speicher, sodass Sie eine Zulassungsregel aus einer unerwarteten GPO sofort erkennen. Prüfen Sie die Profileinstellungen auf dieselbe Weise:

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

AllowLocalFirewallRules sollte in jedem Profil False sein. Ergänzen Sie das mit gpresult /h für die GPO-Seite und dem Richtlinienstatus pro Gerät in Intune für MDM, und verfolgen Sie das Sicherheitsereignis 4954 (Firewalleinstellungen der Gruppenrichtlinie angewendet) über Ihre Ereignisweiterleitung.

Checkliste

• Zusammenführen lokaler Regeln und Verbindungssicherheitsregeln in jedem Profil deaktiviert
• Lokale Regeln von Installationsprogrammen exportiert, geprüft und bei Bedarf durch zentrale Regeln ersetzt
• Profileinstellungen in einer Baseline-GPO oder einem Intune-Profil; Regeln nach Rollen aufgeteilt
• Keine expliziten eingehenden Blockregeln als „alles blockieren außer“ im Einsatz
• Vordefinierte Regelgruppen neu begrenzt; Alt-GPOs auf Regeln geprüft
• Eine Richtlinienautorität (GPO oder Intune) pro Gerätepopulation
• Aktiver Speicher nach PolicyStoreSource überprüft; Änderungen pilotiert und gesichert

Eine einheitliche, zentral verantwortete Richtlinie ist auch die Grundlage für identitätsbasierte Regeln mit IPsec-Domänen- und Serverisolation und für das gestufte Zugriffsmodell im Admin-Tiering.