Auditing the Windows Firewall: The Host-Based Control Everyone Misconfigures

The Windows Defender Firewall is the most underrated control on the platform. It ships enabled, it blocks unsolicited inbound traffic by default, and most administrators promptly stop thinking about it. That neglect is the problem. The firewall is not a set-and-forget box — it is a stateful rule engine with three independent profiles, and over the life of a machine it accumulates exceptions the way a junk drawer accumulates cables. By the time an attacker is probing the host, the firewall has usually been quietly turned into Swiss cheese by software installers, "temporary" troubleshooting rules, and a domain GPO nobody has re-read since deployment.

Host-based firewalling matters precisely because the network perimeter cannot save you. Once an attacker has a foothold on one machine — phishing, a compromised VPN account, a contractor's laptop — every other endpoint is on the same flat L2 segment as far as the perimeter is concerned. The host firewall is the control that decides whether your file server answers an SMB probe from a random workstation, or whether a developer box accepts an inbound RDP session from the accounting subnet. Lateral movement lives and dies on these rules.

The Three Profiles Are Where It Goes Wrong

Windows applies one of three profiles per network connection: Domain, Private, and Public. Each has its own enabled state, default inbound/outbound actions, and rule set. The single most common finding in the field is a profile that has been switched off entirely — often the Public profile, disabled during a coffee-shop troubleshooting session and never re-enabled. A laptop with the Public firewall off is fully exposed the moment it joins an untrusted network. Audit all three explicitly:

# Per-profile state — never trust "the firewall is on" as a single fact
Get-NetFirewallProfile |
  Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction, LogAllowed, LogBlocked

# A healthy baseline looks like:
#   Name    Enabled  DefaultInboundAction
#   Domain  True     Block
#   Private True     Block
#   Public  True     Block

DefaultInboundAction should be Block on every profile. If it reads Allow or NotConfigured (which falls back to allow on older builds), the firewall is inspecting nothing on the inbound path — rules become opt-out instead of opt-in, which is backwards.

The Rules Nobody Remembers Adding

The rule list is where real attack surface hides. Every installer that wants inbound connectivity drops a rule; so does every admin who hit a "this app is blocked" prompt and clicked Allow. Months later you have inbound exceptions for tools that were uninstalled, all-port rules scoped to Any remote address, and rules that quietly re-open the very protocols you hardened elsewhere. Hunt for the dangerous shape — inbound, allow, broad scope:

# Enabled inbound ALLOW rules open to any remote address
Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow |
  Where-Object { ($_ | Get-NetFirewallAddressFilter).RemoteAddress -eq 'Any' } |
  Select-Object DisplayName, Profile

# The usual suspects you do NOT want world-reachable:
#   File and Printer Sharing (SMB-In)      -> TCP 445 from Any
#   Remote Desktop (TCP-In)                -> TCP 3389 from Any
#   Windows Remote Management (HTTP-In)    -> TCP 5985 from Any

An inbound allow rule for RDP or SMB scoped to Any is functionally an open port to the entire subnet. The fix is rarely "delete the rule" — these services may be needed — it is to scope the rule to the specific management subnet or jump host that should reach them. A firewall rule with a tight RemoteAddress is the difference between RDP-for-IT and RDP-for-the-attacker.

Logging: The Forensic Trail You Forgot to Turn On

By default the firewall log is disabled and capped at 4 MB. After an incident, "did this host accept a connection from the beachhead machine?" is a question you answer from pfirewall.log — if you enabled it beforehand. Turn on dropped-packet logging at minimum and raise the size cap so it does not roll over in an hour:

Set-NetFirewallProfile -All -LogBlocked True -LogMaxSizeKilobytes 16384 `
  -LogFileName '%SystemRoot%\System32\LogFiles\Firewall\pfirewall.log'

How WinSentinel Audits This

Doing the above by hand on one box takes ten minutes; doing it correctly and repeatedly is exactly what an agent is for. WinSentinel's firewall posture audit checks all three profiles' enabled state and default actions, flags inbound allow rules with overly broad remote scopes, verifies that high-risk services (SMB, RDP, WinRM) are not world-reachable, and confirms logging is enabled with a usable size. Every finding comes with the specific remediation, not a generic "review your firewall" nag.

# Single machine — free, every module, no limits:
winsentinel --audit --modules firewall

[CRITICAL] Public profile firewall is DISABLED
[CRITICAL] Inbound ALLOW rule "Remote Desktop (TCP-In)" scoped to Any remote address
[WARNING]  DefaultInboundAction is NotConfigured on Private profile
[WARNING]  Dropped-packet logging is OFF — no firewall forensic trail
[INFO]     27 enabled inbound allow rules (8 reference uninstalled software)

On a single machine that is the whole story: run it, read the criticals, fix them, re-run to confirm the score moved. The entire firewall module — like all 33 modules — is free and unmetered on one host. There is no "pro firewall check"; the audit depth is identical everywhere.

What changes at organizational scale is orchestration, not capability. The thing that bites a fleet is drift: a baseline you hardened in January, slowly chewed apart machine-by-machine as users click Allow and installers add rules. WinSentinel Pro puts an agent on every endpoint reporting firewall posture into a central node, so you see fleet-wide rollups, get a drift alert the moment a machine's Public profile flips off or a wide-open RDP rule appears, and can prove the baseline held for a CIS or SOC 2 audit across the whole estate. Same audit, many machines, managed centrally — that is the only line between Free and Pro.

The Bottom Line

The Windows Firewall is a genuinely strong control that almost everyone runs in a quietly degraded state. Treat it as a posture surface, not a checkbox: verify every profile is enabled and defaulting to block, scope your inbound rules to the hosts that actually need them, and turn the log on before you need it. Then let an agent watch it, because the firewall you hardened today is not the firewall you will have in three months unless something is checking.

winsentinel --audit --modules firewall
# Close the rules you forgot you opened.