Windows Firewall logging and monitoring that works

A host firewall that blocks traffic but tells nobody is only half a control. The drops it records show scanning, lateral movement attempts and misconfigured applications. Its configuration-change events show an attacker opening a port for their tooling or switching the firewall off. Most environments collect neither.

The Windows Firewall hardening pillar sets the policy: all profiles on, inbound default block, admin protocols scoped to management hosts. This guide builds the monitoring on top of it. There are three sources, and each has a different purpose:

The broader area overview lives on the Windows Firewall topic page.

Step 1: configure pfirewall.log per profile

GPO path: Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security. Open the properties, and on each of the Domain Profile, Private Profile and Public Profile tabs, click Customize under Logging:

When the file reaches its size limit, Windows renames it to pfirewall.log.old and starts a new one, overwriting the previous .old. On a noisy server that can mean only a few hours of history, so either collect the file or rely on the events in Step 2.

You can use a separate file per profile (domainfw.log, publicfw.log) to see at a glance which profile a laptop was in when something was dropped. If you move the log anywhere other than the default folder, the firewall service must be able to write there:

$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, the equivalent profile settings are in the settings catalog under the Firewall category, per profile: Log File Path, Log Max File Size, Enable Log Dropped Packets and Enable Log Success Connections (Firewall CSP MdmStore/DomainProfile/LogFilePath, LogMaxFileSize, EnableLogDroppedPackets, EnableLogSuccessConnections, and the same under PrivateProfile and PublicProfile). On a device that also receives Group Policy, a GPO value for the log path and size wins over the MDM value.

Reading the file

The file is space-delimited with a #Fields: header line. Parse it from the header rather than assuming a fixed column order, because newer Windows builds have added fields:

$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

A single source hitting many ports, or many internal sources hitting TCP 445 or 5985 on workstations, is exactly the pattern the pillar's rules are designed to stop.

Step 2: enable Windows Filtering Platform auditing

WFP is the engine underneath the firewall. Its audit events are more useful than the text log for central monitoring because they include the application path and the direction and go through the normal event pipeline.

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

Remember that Advanced Audit Policy only applies if Audit: Force audit policy subcategory settings to override audit policy category settings is enabled under Security Options, which any modern baseline already does.

On a single machine for testing:

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

Event 5157 reads "The Windows Filtering Platform has blocked a connection" and contains the process (as a device path such as \device\harddiskvolume3\windows\system32\svchost.exe), direction, source and destination address and port, protocol and a Filter Run-Time ID. To find which filter or rule produced a block, dump the WFP state and search for that ID:

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

Note that 5157 also fires for packets dropped by the default block action, not only for explicit block rules, so a stream of 5157 events is normal. What matters is who is being blocked and from where.

Step 3: always audit firewall configuration changes

Configuration changes are rare, cheap to collect and high-value. Enable Audit MPSSVC Rule-Level Policy Change for Success and Failure under Advanced Audit Policy Configuration > Audit Policies > Policy Change. The key events in the Security log:

Group Policy refresh produces 4954 and, on some builds, bursts of 4946/4948 as policy rules are re-applied. Build your detection around changes that do not coincide with a policy refresh, or that come from a process other than the ones your management stack uses.

The Applications and Services Logs > Microsoft > Windows > Windows Firewall With Advanced Security > Firewall log records the same changes with rule details and the modifying application. Its event IDs differ between Windows releases (older builds used 2004, 2005 and 2006 for added, modified and deleted rules), so check the IDs on your current Windows 11 24H2/25H2 and Server 2025 images before writing rules against it.

Also watch the service itself. An attacker who stops MpsSvc or changes its start type leaves Service Control Manager events 7036 and 7040 in the System log.

Step 4: forward what matters

For the WFP and policy-change events, Windows Event Forwarding (see the WEF glossary entry) or your SIEM agent is the transport. Keep the subscription tight so 5157 does not drown the collector:

<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 is the inbound direction value. Blocked inbound connections on workstations are the interesting ones for lateral movement; blocked outbound is noisier and mostly useful on servers with default-deny outbound. If volume is still too high, collect 5157 only from servers and a sample of workstations, and rely on EDR network telemetry for the rest.

For pfirewall.log, point your log agent at the file (and the .old file) and parse it with the header fields shown above.

Detection ideas

• Firewall turned off or default inbound set to Allow: 4950 for any profile, outside a change window. Alert immediately.
• New inbound allow rule created locally: 4946 on a device where local rule merge is disabled is often an attacker or installer that will have no effect, but it still signals intent.
• Internal scanning: one source address producing 5157 events against many destination hosts or ports within minutes.
• Workstation-to-workstation management traffic: 5157 inbound on TCP 445, 135, 3389 or 5985 from non-admin subnets.
• Blocked outbound SMB to the internet: an attempted forced authentication or data exfiltration.

The security event ID reference puts these alongside the logon and process events you will correlate them with.

What breaks

• Security log churn: enabling Filtering Platform Connection success auditing fleet-wide can rotate the Security log in minutes and hide logon events. Increase the Security log size (at least 1 GB on servers) and stick to failures on clients.
• Collector load: an unfiltered 5157 subscription is often the single largest event source in a WEF deployment. Filter at the source with XPath.
• Custom log paths without NT SERVICE\mpssvc write access silently produce no file.
• Profile mismatch: logging configured only in the Domain profile gives nothing when a laptop is on the Public profile at home.

Verify it

Check the effective logging configuration, which reflects GPO and MDM rather than local settings:

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"

Then test end to end: from a non-admin workstation, run Test-NetConnection <target> -Port 445 against another workstation. On the target you should see a DROP TCP line in pfirewall.log and a 5157 event; on the collector, the 5157 should arrive within your forwarding interval. Finally, add and delete a harmless test rule and confirm 4946 and 4948 reach the SIEM.

Checklist

• Dropped-packet logging on in all three profiles, file size at least 16 MB
• Custom log paths writable by NT SERVICE\mpssvc
• Filtering Platform Connection audited for failure; success only on selected servers
• MPSSVC Rule-Level Policy Change audited for success and failure
• Events 4946-4950, 4954 and 5157 (filtered) forwarded to the SIEM
• Alerts on firewall disabled, local allow rules and internal scanning patterns
• End-to-end test performed: blocked connection and rule change visible centrally

Logging is only useful if the policy behind it is consistent across the fleet; the next step is managing firewall policy at scale.