Client-Firewalls als AD-Grenze: laterale Wege zwischen Endpunkten schließen

Ausgangslage: Domänenmitgliedschaft braucht keine freie Client-Erreichbarkeit

Viele Active-Directory-Umgebungen behandeln das interne Client-Netz weiterhin als eine gemeinsame Vertrauenszone. Die Windows Defender Firewall ist zwar häufig eingeschaltet, breite vordefinierte Regelgruppen, lokal angelegte Ausnahmen oder alte Gruppenrichtlinien machen Arbeitsstationen jedoch aus großen Adressbereichen erreichbar. In anderen Umgebungen wurde die Firewall vor Jahren zur Fehlerbehebung deaktiviert und nie wieder in einen verwalteten Zustand überführt.

Diese Erreichbarkeit schafft unnötige Wege zwischen gleichartigen Endpunkten. Ein normaler Büro-Client benötigt ausgehend DNS, Domänendienste, Updates, Webzugriffe und Geschäftsanwendungen. Unaufgeforderte eingehende Verbindungen für SMB, RDP, RPC, WMI oder WinRM von jeder anderen Arbeitsstation sind dagegen selten erforderlich. Bleiben solche Pfade offen, stellt ein betroffener Client dieselben Verwaltungs- und Dateidienste auf vielen Nachbarsystemen unmittelbar in Reichweite.

Netzwerksegmentierung bleibt wichtig, ist aber nicht immer fein genug. Mehrere Abteilungen teilen sich häufig ein VLAN, WLAN-Clients wechseln Standorte und zentrale Firewalls unterscheiden eher zwischen Benutzer- und Servernetzen als zwischen einzelnen Benutzerendpunkten. Die Host-Firewall setzt die Grenze direkt am Zielsystem durch. Sie wirkt deshalb auch dann, wenn zwei Clients im selben Subnetz kommunizieren und keine geroutete Firewall den Verkehr sieht.

Die Maßnahme ist mehr als „Firewall einschalten“. Ein Default-Block ohne notwendige Verwaltungswege kann Support, Softwareverteilung oder Monitoring unterbrechen. Eine pauschale Freigabe für das gesamte Domänennetz erhält dagegen fast die ursprüngliche Angriffsfläche. Widersprüchliche GPO-, MDM- und lokale Einstellungen können zudem auf nominell identischen Geräten unterschiedliche wirksame Regeln erzeugen. Eine belastbare Baseline braucht deshalb ein Verkehrs- und Applikationsinventar, eng begrenzte Regeln, eine führende Verwaltungsquelle, Telemetrie und einen getesteten Rückfallweg.

Auch die Schutzgrenze muss klar bleiben: Client-Firewalls reduzieren unaufgeforderte Netzwerkzugriffe und erschweren laterale Bewegungen. Sie entfernen keine kompromittierten Zugangsdaten, härten keinen erlaubten Dienst und ersetzen weder EDR, Patchmanagement, Admin-Tiering noch Netzwerksegmentierung. Beim üblichen ausgehenden Default-Allow sind sie außerdem keine allgemeine Egress-Kontrolle.

Zielbild: Clients akzeptieren nur begründete eingehende Verbindungen

Ein verteidigbarer Zielzustand besitzt konkrete Eigenschaften:

1. Die Firewall ist in allen Profilen aktiv. Domain, Private und Public sind ausdrücklich konfiguriert; ein Profilwechsel hebt die Kontrolle nicht auf.
2. Eingehende Verbindungen werden standardmäßig blockiert. Ausnahmen gelten nur für dokumentierte Dienste, Geräteklassen und Quellsysteme.
3. Ausgehende Verbindungen bleiben auf normalen Clients standardmäßig erlaubt. Ein ausgehender Default-Deny ist ein separates Hochsicherheitsprojekt mit vollständigem Applikations- und Zielinventar.
4. Client-zu-Client-Administration ist nicht allgemein zulässig. RDP, SMB, WinRM, WMI und vergleichbare Pfade beginnen nur auf freigegebenen Verwaltungssystemen.
5. Regeln sind enger als eine Portnummer. Programm oder Dienst, Protokoll, lokaler Port, Quelladresse, Profil und bei Bedarf Schnittstellentyp werden begrenzt.
6. Geräteklassen erhalten getrennte Policies. Büro-Clients, PAWs, Entwicklergeräte, Kiosks und Spezialarbeitsplätze teilen nicht blind dieselben Ausnahmen.
7. Pro Gerätepopulation ist eine Verwaltungsquelle führend. GPO- und MDM-Verantwortung sind dokumentiert; unerwünschte lokale Regelzusammenführung ist abgeschaltet.
8. Ausnahmen haben Owner und Prüftermin. Zweck, Quelle, Zielgruppe, Verantwortlicher und Ablauf- oder Review-Datum sind nachvollziehbar.
9. Blockierungen und Policy-Drift werden zentral sichtbar. Logging und Auditierung sind dimensioniert, ohne unbegrenzt hochvolumige Rohdaten zu sammeln.
10. Rollout und Rollback sind praktisch getestet. Pilotgeräte, mobile Nutzung, VPN und Wiederherstellungswege werden vor breiter Durchsetzung geprüft.

Das Ziel ist keine möglichst lange Regelliste. Die von einem Client angebotene Netzwerkfläche soll klein, erklärbar und passend zu seiner tatsächlichen Rolle sein.

Umsetzung: aus beobachteten Abhängigkeiten eine Policy bauen

1) Wirksamen Zustand und Listener inventarisieren

Beginne mit repräsentativen Systemen jeder Geräteklasse. Erfasse aktive Profile, Default-Aktionen, Regelquellen, lokale Ausnahmen, Listener und bestehende Verwaltungsabhängigkeiten. Die Ansicht in der GPMC reicht nicht: mehrere GPOs, MDM, lokale Regeln und Sicherheitsprodukte können das tatsächliche Ergebnis verändern.

Die folgenden Abfragen verändern keinen Zustand und liefern einen belastbaren lokalen Ausgangspunkt:

Get-NetFirewallProfile -PolicyStore ActiveStore |
  Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction,
    AllowInboundRules, AllowLocalFirewallRules, AllowLocalIPsecRules,
    LogBlocked, LogAllowed, LogFileName, LogMaxSizeKilobytes

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

Port- und Adressfilter müssen separat betrachtet werden; der Anzeigename einer Regel beweist ihren Scope nicht:

Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True -Direction Inbound |
  Get-NetFirewallPortFilter |
  Select-Object InstanceID, Protocol, LocalPort, RemotePort

Get-NetFirewallRule -PolicyStore ActiveStore -Enabled True -Direction Inbound |
  Get-NetFirewallAddressFilter |
  Select-Object InstanceID, LocalAddress, RemoteAddress

Get-NetTCPConnection -State Listen |
  Sort-Object LocalPort |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-NetUDPEndpoint |
  Sort-Object LocalPort |
  Select-Object LocalAddress, LocalPort, OwningProcess

Ein Listener ist noch kein geschäftlicher Bedarf, und eine Momentaufnahme übersieht kurzlebige Prozesse. Ergänze die Daten um EDR- und Flow-Telemetrie, Softwareverteilung, Monitoring, Helpdesk-Abläufe und Applikations-Owner. Für jeden benötigten eingehenden Flow sollten Ziel-Geräteklasse, Programm oder Dienst, Protokoll und Port, erlaubte Quellen, Profile, Zweck und Ausfallwirkung dokumentiert sein. Unbekannter Verkehr gehört in die Analyse, nicht in eine pauschale Übergangsfreigabe.

2) Baseline und Rollenausnahmen trennen

Lege eine dedizierte Computer-GPO für die gemeinsame Client-Firewall-Baseline an. Zusätzliche, eng gefilterte GPOs enthalten nur die Ausnahmen einzelner Rollen. So wird eine Entwickler- oder Supportregel nicht automatisch Teil jedes Arbeitsplatzes.

Die Einstellungen liegen unter:

Computerkonfiguration
  Richtlinien
    Windows-Einstellungen
      Sicherheitseinstellungen
        Windows Defender Firewall mit erweiterter Sicherheit

Konfiguriere Domain, Private und Public ausdrücklich:

• Firewallstatus: Ein,
• eingehende Verbindungen: Blockieren (Standard),
• ausgehende Verbindungen: Zulassen (Standard),
• Benachrichtigungen über eingehende Ausnahmen: deaktiviert,
• Logging: aktiviert und passend zur Sammlung dimensioniert,
• lokale Regelzusammenführung: nach erfolgreichem Pilot kontrolliert deaktiviert.

„Alle eingehenden Verbindungen blockieren“ ist nicht dasselbe wie der normale Default-Block. Dieser abgeschirmte Zustand ignoriert auch definierte Allow-Regeln und eignet sich eher für eine temporäre Isolation als für den Regelbetrieb mit verwalteten Ausnahmen. Konfiguriere außerdem nicht nur das Domain-Profil. Kann ein Gerät vorübergehend keinen Domain Controller erkennen oder befindet es sich außerhalb des Firmennetzes, wird ein anderes Profil aktiv. Private und Public dürfen dann keine breitere Eingangsfläche erhalten.

Verknüpfe die GPO zunächst nur mit einer Pilot-OU oder einer eng kontrollierten Sicherheitsfilterung. Komplexe WMI-Filter für eine Kernkontrolle sind zu vermeiden, solange stabile OUs oder Gruppen den Scope abbilden können.

3) GPO, MDM und lokale Regeln eindeutig zuordnen

Hybrid verwaltete Clients erhalten Firewall-Einstellungen häufig aus mehreren Quellen: klassischer Gruppenrichtlinie, Firewall-CSP, Intune Endpoint Security, Security Baselines und lokaler Administration. Zwei Konsolen mit Status „erfolgreich“ beweisen nicht, dass der gewünschte Gesamtzustand am Client wirksam ist.

Bestimme für jede Gerätepopulation eine führende Quelle und setze überlappende Einstellungen in der anderen Quelle auf Not configured oder schließe die betreffenden Gerätegruppen aus. Prüfe Priorität und Regel-Stores auf einem tatsächlich hybrid verwalteten Piloten. Verlasse dich nicht pauschal auf „MDM gewinnt“; die Zusammenführung hängt von Einstellung und Policy-Store ab. Maßgeblich ist der ActiveStore am Zielgerät.

Ist GPO die führende Quelle, setze Lokale Firewallregeln anwenden für die relevanten Profile auf Nein, sobald alle benötigten zentralen Ausnahmen bereitstehen. Regeln eines Installers oder lokalen Administrators erweitern dann nicht mehr unbemerkt die geprüfte Eingangsfläche. Verbindungssicherheitsregeln und IPsec-Regelzusammenführung werden getrennt bewertet.

Diese Verschärfung hat eine klare Betriebsfolge: Anwendungen, die beim Setup selbst eine lokale Inbound-Regel erzeugen, sind erst nach einer zentralen Freigabe erreichbar. Das ist ein Packaging- und Ownership-Thema, kein Grund, die lokale Regelzusammenführung für alle Geräte wieder zu öffnen. Lokale Gruppenrichtlinien und lokale Administratorrechte bleiben dennoch eigene Vertrauensanker und müssen separat kontrolliert werden.

4) Ausnahmen an Dienst und vertrauenswürdige Quelle binden

Eine eingehende Allow-Regel sollte mindestens folgende Dimensionen prüfen:

• Programm oder Windows-Dienst: Bindung an den vorgesehenen Prozess statt an jedes Programm, das denselben Port verwenden kann.
• Protokoll und lokaler Port: nur der tatsächliche Listener; weite Bereiche nur bei dokumentierter technischer Notwendigkeit.
• RemoteAddress: konkrete Managementserver, Jump Hosts, PAWs, Monitoring- oder Verteilungssysteme statt Any oder des gesamten internen Netzes.
• Profil: nur die Netzprofile, in denen der Dienst erreichbar sein muss.
• Schnittstellentyp: WLAN oder Remote Access ausschließen, wenn der Prozess nur im verwalteten LAN vorgesehen ist.
• IPv4 und IPv6: beide Protokollfamilien testen und begrenzen.
• Owner und Zweck: stabiler Bezeichner, Änderungsreferenz und Review-Termin in Beschreibung und Regelregister.

LocalSubnet ist für Remote-Administration meist zu breit: Es umfasst häufig gerade die benachbarten Arbeitsstationen, gegen die die neue Grenze wirken soll. Ebenso sind die IPv4-/IPv6-Filter einer WinRM-Richtlinie nicht automatisch eine Allowlist aufrufender Hosts; der Caller-Scope muss zusätzlich in der Firewallregel über die RemoteAddress eingeschränkt werden.

Aktiviere nicht blind eine komplette vordefinierte Regelgruppe. „Datei- und Druckerfreigabe“, „Remote Service Management“ oder „Netzwerkerkennung“ können mehrere Protokolle, Programme und Profile enthalten. Prüfe die einzelnen Regeln und übernimm nur den benötigten Teil. Eingehendes SMB sollte auf Standard-Clients ohne freigegebene Sharing-Rolle nicht offen sein. RDP, WinRM, WMI, Remote Event Log und Softwareverteilung werden auf die tatsächlichen Verwaltungsquellen begrenzt. Ein großer dynamischer RPC-Portbereich für das gesamte Client-Netz ist keine akzeptable Abkürzung.

IP-Adressen reduzieren die Fläche, sind aber keine starke Geräteidentität. DHCP, VPN, NAT, Adresswiederverwendung und ein kompromittierter Managementserver bleiben relevant. Wenn ein Managementpfad eine authentifizierte Computer- oder Benutzeridentität benötigt, können IPsec-Verbindungssicherheitsregeln ergänzen. Das ist ein eigenes Pilotprojekt: zuerst Verbindungen anfordern und messen, dann erst verlangen. Bootstrap-Verkehr, nicht domänengebundene Systeme und Recovery-Pfade brauchen geplante Ausnahmen.

5) Durchsetzung in Ringen statt mit einer Scheinauditierung

Windows Defender Firewall besitzt keinen AppLocker-ähnlichen Audit-Modus, der zuverlässig jede Verbindung meldet, die eine zukünftige Policy blockieren würde. Ein risikoarmer Rollout stützt sich deshalb auf Inventar, Labortests und kleine Durchsetzungsringe.

Eine praktikable Reihenfolge ist:

1. Wirksame Regeln, Listener und benötigte eingehende Flows dokumentieren.
2. Logging und zentrale Sammlung vor der Verschärfung aktivieren.
3. Baseline und Ausnahme-GPOs erstellen, sichern und zunächst ohne breiten Link testen.
4. Vollständige Profilwerte und notwendige Ausnahmen gemeinsam auf Referenzsysteme ausrollen.
5. Zugriffe von erlaubten Managementsystemen und von normalen Peer-Clients positiv und negativ testen.
6. Pilot auf IT/Security, reale Fachbereiche, Standorte, WLAN, VPN und mobile Geräte erweitern.
7. Erst danach breite Altregeln entfernen und lokale Regelzusammenführung deaktivieren.
8. Spezialgeräte und PAWs als getrennte Policy-Entscheidungen behandeln.

Jeder Ring sollte mindestens einen Patch-, Applikationsupdate-, Monitoring- und Remote-Support-Zyklus abdecken. Ein frisch installierter Büro-Laptop im LAN reicht nicht als Test. Rollout und Ausnahmen müssen in derselben kontrollierten Änderung wirksam werden; eine zwischenzeitliche Default-Block-Policy ohne Managementregeln kann Geräte unnötig isolieren.

6) Logging nutzbar machen und Volumen begrenzen

Konfiguriere das Firewall-Logging je Profil zentral. Getrennte Dateien wie pfirewall_Domain.log, pfirewall_Private.log und pfirewall_Public.log vereinfachen die Zuordnung; die Standardablage liegt unter %SystemRoot%\System32\LogFiles\Firewall\. Der Default von wenigen Megabyte rotiert in aktiven Umgebungen schnell, daher braucht die Größe eine bewusste Festlegung. Dropped Packets sollten im Pilot und im Betrieb protokolliert werden. Successful Connections sind für eine zeitlich begrenzte Baseline nützlich, erzeugen aber deutlich mehr Daten.

Lokale Textlogs sind Troubleshooting-Nachweise, kein zentrales Monitoring. Relevante Signale gehören über EDR, WEF/WEC oder die vorhandene SIEM-Pipeline in einen auswertbaren Kontext. Windows Filtering Platform liefert unter anderem 5152 für verworfene Pakete, 5157 für blockierte und 5156 für zugelassene Verbindungen. Regeländerungen erscheinen beispielsweise in 4946 bis 4948, Profilwechsel in 4956. Paket- und Success-Auditing kann sehr hohes Volumen erzeugen und wird deshalb zuerst auf Piloten dimensioniert.

Die Auswertung muss konkrete Fragen beantworten: Welcher benötigte Dienst wird auf welcher Geräteklasse und in welchem Profil blockiert? Kam die Verbindung von einem freigegebenen Managementsystem oder einem Peer-Client? Werden temporäre Ausnahmen noch genutzt? Melden Systeme ein deaktiviertes Profil, lokale Regelzusammenführung oder unerwartete Quellen?

Ein Drop ist nicht automatisch ein Freigabegrund. Discovery-Verkehr, Hintergrundrauschen, alte Managementjobs und unerlaubte Werkzeuge sollen an dieser Grenze scheitern. Erst ein belegter Bedarf mit Owner rechtfertigt eine Policy-Änderung.

7) Ausgehendes Default-Allow bewusst beibehalten

Für die normale Client-Flotte ist ausgehendes Default-Allow eine bewusste Scope-Entscheidung. Betriebssystem- und Applikationsupdates, Zertifikatsprüfungen, Browser, Collaboration, Cloud-Dienste und Geschäftsanwendungen bleiben funktionsfähig, während unnötige eingehende Erreichbarkeit reduziert wird. Gezielte Outbound-Blockregeln können verbotene Protokolle oder Anwendungen ergänzen, ergeben aber noch keine vollständige Egress-Kontrolle.

Ein ausgehender Default-Deny ist möglich, aber ein separates Hochsicherheitsprojekt. Es benötigt ein belastbares Applikationsinventar, Dienst- und Cloudziele, Proxy- und Updatearchitektur, DNS- und PKI-Abhängigkeiten, Exception-Owner und permanente Regressionstests. Eine Regel „TCP 443 zu Any“ begrenzt Anwendungen kaum; starre Adresslisten für dynamische Cloud-Dienste werden schnell fragil.

Nutze Default-Deny deshalb nur für Geräteklassen mit stabilem Workload und passendem Betriebsmodell, etwa bestimmte PAWs, Kiosks oder eng definierte VDI-Pools. Sie erhalten eigene GPO, Pilot, Rollback und Supportverfahren. Zwei unterschiedliche Projekte in einem Rollout erschweren Diagnose und Wiederherstellung unnötig.

8) Rollback und dauerhaften Regelbetrieb testen

Sichere die relevanten GPOs und exportiere den wirksamen Zustand vor einer Produktivänderung. Halte eine bekannte, funktionierende Baseline bereit, die über eine höher priorisierte Recovery-GPO oder kontrollierte Link-Änderung wiederhergestellt werden kann. Recovery bedeutet normalerweise, die zuletzt freigegebenen Profilwerte und Regeln zurückzurollen, nicht den Firewall-Dienst MpsSvc abzuschalten.

Teste den Rückfall sowohl im LAN als auch mit einem entfernten Piloten. Ein Gerät ohne DC-Verbindung erhält eine Notfall-GPO nicht sofort. Der für die Wiederherstellung vorgesehene MDM-, VPN- oder Out-of-Band-Pfad muss durch die Policy erlaubt und praktisch erprobt sein.

Nach jedem Policy Refresh werden ActiveStore, Profile, Regelquellen und Funktionstests mit der Freigabe verglichen. Ausnahmen brauchen wiederkehrende Reviews. Regeln aus beendeten Projekten werden entfernt, temporäre Adressbereiche verkleinert und abweichende Geräte untersucht. Neue Software muss im Intake beantworten, ob eingehende Erreichbarkeit nötig ist, von welcher Quelle, in welchem Profil und für welche Dauer. „Der Hersteller verlangt eine deaktivierte Firewall“ ist keine technische Regelspezifikation.

Vorteile

• Reduziert die Client-Angriffsfläche: Nicht benötigte Listener bleiben aus dem Netz unerreichbar, auch wenn Dienst oder Anwendung installiert sind.
• Begrenzt Peer-to-Peer-Wege: Eine Benutzerarbeitsstation ist keine allgemein vertrauenswürdige Quelle für die Administration einer anderen.
• Wirkt innerhalb eines Subnetzes: Das Zielsystem setzt die Grenze durch, selbst wenn keine zentrale Firewall den Verkehr sieht.
• Bleibt bei mobilen Clients aktiv: Private und Public Profile schützen auch außerhalb des Firmennetzes.
• Erhält kontrollierte Administration: Freigegebene Managementsysteme erreichen den benötigten Dienst über eng definierte Regeln.
• Macht Ausnahmen prüfbar: Programm, Dienst, Quelle und Profil erzeugen eine belastbarere Entscheidung als eine flache interne Freigabe.
• Ergänzt Netzwerksegmentierung: Host- und Netzwerkkontrolle überlappen, sodass eine breite Route nicht automatisch jeden Client-Dienst freigibt.

Nachteile und Grenzen

• Abhängigkeitsanalyse kostet Aufwand: Legacy-Management, dynamisches RPC und schlecht dokumentierte Anwendungen können bei der Umstellung ausfallen.
• Remote-Support wird anspruchsvoller: Unvollständige Regeln oder ein fehlender Recovery-Pfad können die Wiederherstellung entfernter Geräte verzögern.
• IP-Adressen sind keine Identitäten: Quell-Scope reduziert die Fläche, authentifiziert den Aufrufer aber nicht allein.
• Erlaubte Dienste bleiben angreifbar: Die Firewall behebt keine schwache Autorisierung, ungepatchte Software oder überhöhte Rechte hinter einer Allow-Regel.
• Managementsysteme werden besonders kritisch: Ein kompromittierter Jump Host oder Deployment-Server kann seinen gesamten freigegebenen Scope erreichen.
• Ausgehendes Default-Allow begrenzt keine allgemeine Egress-Kommunikation: Dafür bleiben Proxy-, EDR- und Netzwerkkontrollen erforderlich.
• Hybrid-Policies erhöhen die Komplexität: GPO, MDM, lokale Regeln und Security-Produkte können je Gerätepopulation unterschiedlich interagieren.
• Telemetrie verursacht Kapazitätskosten: Detaillierte WFP- und Success-Events überlasten ohne Tuning lokale und zentrale Sammlung.
• Die Maßnahme ersetzt keine Segmentierung: VLANs, Zugriffskontrollen und administrative Tiers bleiben eigenständige Grenzen.

Typische Stolperfallen

• Das Domain-Profil als vertrauenswürdiges Netz behandeln: RemoteAddress = Any öffnet die Client-Fläche erneut.
• LocalSubnet für Administration verwenden: Gerade benachbarte Peer-Clients werden dadurch zu erlaubten Quellen.
• Nur Portregeln erstellen: Programm-, Dienst-, Quell- und Profilbezug fehlen trotz technischer Möglichkeit.
• Nur das Domain-Profil konfigurieren: Mobile oder falsch kategorisierte Geräte fallen auf eine schwächere Policy zurück.
• Ganze vordefinierte Gruppen aktivieren: Enthaltene Regeln öffnen mehr Programme, Protokolle oder Profile als benötigt.
• Lokale Regelzusammenführung zu früh deaktivieren: Noch nicht zentral abgebildete Anwendungen verlieren ihre Erreichbarkeit.
• GPO und MDM gleichzeitig führen lassen: Erfolgreiche Zuweisungen können dennoch einen unerwarteten ActiveStore erzeugen.
• IPv6 nicht testen: Eine nur für IPv4 gedachte Grenze bleibt unvollständig oder verursacht unklare Fehler.
• Breite Blockregeln mit spezifischen Allows reparieren wollen: Explizite Blockregeln haben Vorrang und können erlaubten Verkehr weiter verhindern.
• Nur positive Tests durchführen: Funktionierende Administration beweist nicht, dass derselbe Zugriff von Peer-Clients scheitert.
• Firewall oder MpsSvc zur Fehlersuche abschalten: Damit verschwindet die gesamte Grenze statt nur der fehlerhaften Regel.
• Outbound Default-Deny in den ersten Rollout mischen: Fehlerursachen und Recovery werden unnötig schwer unterscheidbar.

Projekt-Checkliste

• [ ] Standard-Clients, PAWs, Entwicklergeräte, Kiosks und Spezialgruppen getrennt definieren.
• [ ] Policy-Owner, Service-Owner und Freigabeprozess für Ausnahmen benennen.
• [ ] Aktive Profile, Default-Aktionen, Regelquellen und Merge-Einstellungen inventarisieren.
• [ ] TCP- und UDP-Listener auf repräsentativen Systemen erfassen.
• [ ] Benötigte eingehende Flows mit Programm, Dienst, Port, Quelle, Profil und Zweck dokumentieren.
• [ ] Remote-Support, Monitoring, Softwareverteilung, Schwachstellenscans und EDR-Abhängigkeiten aufnehmen.
• [ ] Pro GPO- oder MDM-Gerätepopulation eine führende Verwaltungsquelle festlegen.
• [ ] Wirksame Priorität auf hybrid verwalteten Pilotgeräten prüfen.
• [ ] Dedizierte Client-Firewall-Baseline-GPO erstellen und sichern.
• [ ] Firewall für Domain, Private und Public ausdrücklich aktivieren.
• [ ] Eingehend Block, ausgehend Allow als normale Client-Baseline setzen.
• [ ] Gemeinsame Baseline von rollenspezifischen Ausnahme-GPOs trennen.
• [ ] Inbound-Regeln auf Programm oder Dienst, Protokoll, Port und erlaubte Quellen begrenzen.
• [ ] Breite Client-zu-Client-Freigaben für RDP, SMB, WinRM, WMI und RPC entfernen.
• [ ] Vordefinierte Regelgruppen einzeln prüfen statt komplett aktivieren.
• [ ] Lokale Firewallregel-Zusammenführung nach vollständiger zentraler Abbildung deaktivieren.
• [ ] IPsec-Regelzusammenführung separat bewerten, falls Verbindungssicherheit eingesetzt wird.
• [ ] Drop-Logging, Dateigröße, Aufbewahrung und zentrale Sammlung konfigurieren.
• [ ] WFP-Auditierung zunächst auf Datenvolumen und Nutzen pilotieren.
• [ ] Erlaubte Verwaltung aus freigegebenen Quellzonen positiv testen.
• [ ] Gleichartige Zugriffe aus normalen Client-Netzen als Negativtest ausführen.
• [ ] LAN, WLAN, VPN, Remote- und neu provisionierte Geräte in den Pilot aufnehmen.
• [ ] Mindestens einen Patch-, Applikationsupdate- und Support-Zyklus beobachten.
• [ ] Letzte funktionierende GPO und Rollback ohne Abschalten des Firewall-Dienstes testen.
• [ ] Recovery-Pfad für Geräte ohne unmittelbare DC-Verbindung praktisch prüfen.
• [ ] ActiveStore nach Policy Refresh mit der Freigabe vergleichen und Drift untersuchen.
• [ ] Jede Ausnahme mit Begründung, Owner und Review- oder Ablaufdatum versehen.
• [ ] Ausgehendes Default-Deny als getrenntes Hochsicherheitsprojekt planen.
• [ ] Client-Firewalls regelmäßig zusammen mit Segmentierung, EDR, Patching und Admin-Tiering prüfen.