Windows-Firewall: Protokollierung und Überwachung

Eine Host-Firewall, die Verkehr blockiert, aber niemandem davon erzählt, ist nur eine halbe Maßnahme. Die protokollierten Verwerfungen zeigen Scans, Lateral-Movement-Versuche und falsch konfigurierte Anwendungen. Ihre Konfigurationsänderungsereignisse zeigen einen Angreifer, der einen Port für sein Werkzeug öffnet oder die Firewall abschaltet. Die meisten Umgebungen sammeln weder das eine noch das andere.

Der Leitfaden zur Härtung der Windows-Firewall legt die Richtlinie fest: alle Profile aktiv, eingehend standardmäßig blockiert, Admin-Protokolle auf Managementhosts begrenzt. Dieser Leitfaden setzt die Überwachung darauf auf. Es gibt drei Quellen mit jeweils eigenem Zweck:

Die Übersicht über den gesamten Bereich finden Sie auf der Themenseite Windows-Firewall.

Schritt 1: pfirewall.log pro Profil konfigurieren

GPO-Pfad: Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security. Öffnen Sie die Eigenschaften und klicken Sie auf den Registerkarten Domain Profile, Private Profile und Public Profile jeweils unter Logging auf Customize:

Erreicht die Datei ihre Größengrenze, benennt Windows sie in pfirewall.log.old um und beginnt eine neue, wobei die vorherige .old überschrieben wird. Auf einem lauten Server bedeutet das womöglich nur wenige Stunden Historie. Sammeln Sie die Datei also ein oder verlassen Sie sich auf die Ereignisse aus Schritt 2.

Sie können pro Profil eine eigene Datei verwenden (domainfw.log, publicfw.log), um auf einen Blick zu sehen, in welchem Profil ein Laptop war, als etwas verworfen wurde. Wenn Sie das Log außerhalb des Standardordners ablegen, muss der Firewalldienst dort schreiben können:

$path = 'D:\Logs\Firewall'
New-Item -ItemType Directory -Path $path -Force | Out-Null
$acl = Get-Acl $path
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
  'NT SERVICE\mpssvc','Modify','ContainerInherit,ObjectInherit','None','Allow')
$acl.AddAccessRule($rule); Set-Acl -Path $path -AclObject $acl

In Intune finden Sie die entsprechenden Profileinstellungen im Einstellungskatalog unter der Kategorie Firewall, pro Profil: Log File Path, Log Max File Size, Enable Log Dropped Packets und Enable Log Success Connections (Firewall-CSP MdmStore/DomainProfile/LogFilePath, LogMaxFileSize, EnableLogDroppedPackets, EnableLogSuccessConnections und dasselbe unter PrivateProfile und PublicProfile). Auf einem Gerät, das zusätzlich Gruppenrichtlinien erhält, hat ein GPO-Wert für Logpfad und -größe Vorrang vor dem MDM-Wert.

Die Datei lesen

Die Datei ist durch Leerzeichen getrennt und hat eine Kopfzeile #Fields:. Parsen Sie sie anhand dieser Kopfzeile, statt eine feste Spaltenreihenfolge anzunehmen, denn neuere Windows-Builds haben Felder ergänzt:

$log = "$env:SystemRoot\System32\LogFiles\Firewall\pfirewall.log"
$fields = (Get-Content $log -TotalCount 10 | Where-Object { $_ -like '#Fields:*' }) -replace '^#Fields:\s*' -split ' '
Get-Content $log | Where-Object { $_ -and $_ -notlike '#*' } |
  ConvertFrom-Csv -Delimiter ' ' -Header $fields |
  Where-Object action -eq 'DROP' |
  Group-Object 'src-ip','dst-port' | Sort-Object Count -Descending | Select-Object -First 20 Count, Name

Eine einzelne Quelle, die viele Ports anspricht, oder viele interne Quellen, die auf Arbeitsplätzen TCP 445 oder 5985 ansprechen, ist genau das Muster, das die Regeln aus dem Härtungsleitfaden unterbinden sollen.

Schritt 2: Überwachung der Windows Filtering Platform aktivieren

WFP ist die Engine unter der Firewall. Ihre Überwachungsereignisse sind für die zentrale Überwachung nützlicher als das Textlog, weil sie den Anwendungspfad und die Richtung enthalten und über die normale Ereignis-Pipeline laufen.

GPO-Pfad: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Object Access:

Denken Sie daran, dass die erweiterte Überwachungsrichtlinie nur greift, wenn Audit: Force audit policy subcategory settings to override audit policy category settings unter Security Options aktiviert ist, was jede moderne Baseline bereits tut.

Auf einem einzelnen Rechner zum Testen:

auditpol /set /subcategory:"Filtering Platform Connection" /failure:enable
auditpol /get /subcategory:"Filtering Platform Connection","MPSSVC Rule-Level Policy Change"

Ereignis 5157 lautet „The Windows Filtering Platform has blocked a connection“ und enthält den Prozess (als Gerätepfad wie \device\harddiskvolume3\windows\system32\svchost.exe), Richtung, Quell- und Zieladresse und -port, Protokoll sowie eine Filter Run-Time ID. Um herauszufinden, welcher Filter oder welche Regel eine Blockierung verursacht hat, exportieren Sie den WFP-Zustand und suchen nach dieser ID:

netsh wfp show filters file="$env:TEMP\filters.xml"
Select-String -Path "$env:TEMP\filters.xml" -Pattern '<filterId>123456</filterId>' -Context 0,20

Beachten Sie, dass 5157 auch bei Paketen ausgelöst wird, die durch die Standard-Blockaktion verworfen werden, nicht nur bei expliziten Blockregeln. Ein stetiger Strom von 5157-Ereignissen ist also normal. Entscheidend ist, wer blockiert wird und von wo.

Schritt 3: Änderungen an der Firewallkonfiguration immer überwachen

Konfigurationsänderungen sind selten, günstig zu erfassen und sehr wertvoll. Aktivieren Sie Audit MPSSVC Rule-Level Policy Change für Success und Failure unter Advanced Audit Policy Configuration > Audit Policies > Policy Change. Die wichtigsten Ereignisse im Sicherheitsprotokoll:

Die Aktualisierung der Gruppenrichtlinie erzeugt 4954 und auf manchen Builds Serien von 4946/4948, weil Richtlinienregeln neu angewendet werden. Bauen Sie Ihre Erkennung um Änderungen herum, die nicht mit einer Richtlinienaktualisierung zusammenfallen oder von einem anderen Prozess stammen als denen Ihres Management-Stacks.

Das Protokoll Applications and Services Logs > Microsoft > Windows > Windows Firewall With Advanced Security > Firewall zeichnet dieselben Änderungen mit Regeldetails und der ändernden Anwendung auf. Seine Ereignis-IDs unterscheiden sich zwischen Windows-Versionen (ältere Builds verwendeten 2004, 2005 und 2006 für hinzugefügte, geänderte und gelöschte Regeln). Prüfen Sie die IDs daher auf Ihren aktuellen Images von Windows 11 24H2/25H2 und Server 2025, bevor Sie Regeln dagegen schreiben.

Beobachten Sie auch den Dienst selbst. Ein Angreifer, der MpsSvc stoppt oder dessen Starttyp ändert, hinterlässt die Dienststeuerungs-Manager-Ereignisse 7036 und 7040 im Systemprotokoll.

Schritt 4: das Wichtige weiterleiten

Für die WFP- und Richtlinienänderungsereignisse ist Windows Event Forwarding (siehe den Glossareintrag zu WEF) oder Ihr SIEM-Agent das Transportmittel. Halten Sie das Abonnement eng, damit 5157 den Collector nicht überflutet:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID&gt;=4946 and EventID&lt;=4950) or EventID=4954 or EventID=4956]]</Select>
    <Select Path="Security">*[System[EventID=5157]] and *[EventData[Data[@Name='Direction']='%%14592']]</Select>
  </Query>
</QueryList>

%%14592 ist der Wert für die eingehende Richtung. Blockierte eingehende Verbindungen auf Arbeitsplätzen sind die interessanten für Lateral Movement; blockierter ausgehender Verkehr ist lauter und vor allem auf Servern mit ausgehend standardmäßig verweigert nützlich. Ist das Volumen immer noch zu hoch, sammeln Sie 5157 nur von Servern und einer Stichprobe von Arbeitsplätzen und verlassen Sie sich für den Rest auf die Netzwerktelemetrie Ihres EDR.

Für pfirewall.log richten Sie Ihren Log-Agent auf die Datei (und die .old-Datei) aus und parsen sie mit den oben gezeigten Kopfzeilenfeldern.

Erkennungsideen

• Firewall ausgeschaltet oder eingehende Standardaktion auf Allow gesetzt: 4950 für ein beliebiges Profil außerhalb eines Änderungsfensters. Sofort alarmieren.
• Neue eingehende Zulassungsregel lokal angelegt: 4946 auf einem Gerät mit deaktiviertem Zusammenführen lokaler Regeln stammt oft von einem Angreifer oder Installationsprogramm und bleibt wirkungslos, signalisiert aber trotzdem eine Absicht.
• Interne Scans: eine Quelladresse, die innerhalb von Minuten 5157-Ereignisse gegen viele Zielhosts oder Ports erzeugt.
• Managementverkehr zwischen Arbeitsplätzen: 5157 eingehend auf TCP 445, 135, 3389 oder 5985 aus Nicht-Admin-Subnetzen.
• Blockiertes ausgehendes SMB ins Internet: ein Versuch erzwungener Authentifizierung oder Datenexfiltration.

Die Referenz der Sicherheitsereignis-IDs stellt diese Ereignisse neben die Anmelde- und Prozessereignisse, mit denen Sie sie korrelieren.

Was kaputtgeht

• Umwälzung des Sicherheitsprotokolls: Die flächendeckende Erfolgsüberwachung von Filtering Platform Connection kann das Sicherheitsprotokoll in Minuten rotieren lassen und Anmeldeereignisse verdrängen. Vergrößern Sie das Sicherheitsprotokoll (mindestens 1 GB auf Servern) und bleiben Sie auf Clients bei Fehlern.
• Last auf dem Collector: Ein ungefiltertes 5157-Abonnement ist in einer WEF-Bereitstellung oft die größte einzelne Ereignisquelle. Filtern Sie an der Quelle per XPath.
• Benutzerdefinierte Logpfade ohne Schreibzugriff für NT SERVICE\mpssvc erzeugen stillschweigend keine Datei.
• Profilkonflikt: Eine nur im Domänenprofil konfigurierte Protokollierung liefert nichts, wenn ein Laptop zu Hause im Profil Öffentlich ist.

Überprüfen

Prüfen Sie die effektive Protokollierungskonfiguration, die GPO und MDM widerspiegelt statt lokaler Einstellungen:

Get-NetFirewallProfile -PolicyStore ActiveStore |
  Select-Object Name, LogFileName, LogMaxSizeKilobytes, LogBlocked, LogAllowed
Get-NetConnectionProfile | Select-Object InterfaceAlias, NetworkCategory
auditpol /get /subcategory:"Filtering Platform Connection","MPSSVC Rule-Level Policy Change"

Testen Sie dann durchgängig: Führen Sie von einem Nicht-Admin-Arbeitsplatz Test-NetConnection <target> -Port 445 gegen einen anderen Arbeitsplatz aus. Auf dem Ziel sollten Sie eine Zeile DROP TCP in pfirewall.log und ein 5157-Ereignis sehen; auf dem Collector sollte das 5157 innerhalb Ihres Weiterleitungsintervalls eintreffen. Legen Sie abschließend eine harmlose Testregel an, löschen Sie sie wieder und bestätigen Sie, dass 4946 und 4948 das SIEM erreichen.

Checkliste

• Protokollierung verworfener Pakete in allen drei Profilen aktiv, Dateigröße mindestens 16 MB
• Benutzerdefinierte Logpfade für NT SERVICE\mpssvc beschreibbar
• Filtering Platform Connection auf Fehler überwacht; Erfolg nur auf ausgewählten Servern
• MPSSVC Rule-Level Policy Change auf Erfolg und Fehler überwacht
• Ereignisse 4946-4950, 4954 und 5157 (gefiltert) an das SIEM weitergeleitet
• Alarme bei ausgeschalteter Firewall, lokalen Zulassungsregeln und internen Scanmustern
• Durchgängiger Test durchgeführt: blockierte Verbindung und Regeländerung zentral sichtbar

Protokollierung ist nur nützlich, wenn die zugrunde liegende Richtlinie in der gesamten Flotte einheitlich ist; der nächste Schritt ist die Verwaltung der Firewallrichtlinie im großen Maßstab.