Auditing Windows Firewall Rules: Dangerous Ports, Shadowed Rules, and Silent Exposure

“Is your firewall on?” is the wrong question. On nearly every Windows machine, the answer is yes — and it means almost nothing. Windows Firewall ships with hundreds of inbound rules, and the ones that matter are the individual allow rules quietly punched through it by installers, dev tools, and your own past experiments. A firewall that is enabled but riddled with over-broad allow rules is a firewall in name only.

The rule is the attack surface, not the toggle

Each inbound allow rule answers three questions: which port, from which addresses, and for which program. Tighten all three and a rule is a scalpel. Leave any of them set to Any and it starts to widen. Leave all three open and the rule accepts anything from anyone — the firewall equivalent of propping the door open and taping over the lock.

These rules accumulate silently. A database you installed once, a game launcher, a “just make it work” rule you added during a hackathon three years ago — they persist long after the reason for them is gone. Nobody audits them because the top-level firewall status still cheerfully reports On.

What actually goes wrong

• Dangerous ports exposed to the world. An inbound allow on 3389 (RDP), 445 (SMB), 5985/5986 (WinRM), 1433 (SQL Server), 6379 (Redis), or 27017 (MongoDB) from Any remote address is a standing invitation. Many of these services are unauthenticated by default; the firewall rule is the only thing between them and the internet.
• Overly-permissive scope. A rule that allows any protocol, any port, any address, and any program isn’t a rule — it’s a hole. It effectively disables the firewall for whatever it covers.
• Public-profile exposure. A rule scoped to the Public profile applies on untrusted networks — the coffee-shop Wi-Fi, the conference hotspot. Services you’d never expose at home ride along.
• Duplicate rules. Same direction, action, protocol, port, and program, listed twice. Harmless to traffic, but they bloat the rule set and hide the rules that matter.
• Shadowed rules. A carefully-scoped narrow rule is meaningless if a broader rule above it already allows everything the narrow one does. You think you restricted something; the broad rule quietly overrides your intent.

Auditing rules by hand

You can dump every inbound rule with built-in tooling:

netsh advfirewall firewall show rule name=all dir=in verbose

The problem is volume. A typical machine has 300+ rules, and the risky ones don’t announce themselves — you have to cross-reference each rule’s port against a list of dangerous services, check whether the remote address is scoped, notice which rules shadow which, and total it all up. Doing that by eye, across every machine, every month, is not a plan.

How WinSentinel does it

WinSentinel’s firewall rule analysis reads your live inbound rules and scores each one, no manual cross-referencing required. It flags rules exposing dangerous ports (RDP, SMB, WinRM, SQL, Redis, MongoDB and more), overly-permissive wide-open rules, Public-profile exposure, duplicates, and shadowed rules — then rolls them into a single firewall risk score so you can tell at a glance whether your rule set is a scalpel or a screen door.

winsentinel --audit

Every finding comes with the specific rule name and a remediation: which port to restrict, which address to scope, which duplicate to delete. This runs entirely on your machine — no data leaves the box — and it’s part of the free, single-machine tool. Install it from NuGet:

dotnet tool install --global WinSentinel.Cli

Managing this across a fleet — pushing a “no inbound RDP from Any” policy to every machine and getting alerted when a node drifts — is what WinSentinel Pro adds on top. But the per-machine audit that finds the exposure in the first place is free, and it’s the right place to start. Turn the firewall on, then go read what it’s actually allowing.