Home/Toolchest

Windows firewall rule audit

A read-only Windows Firewall audit that records enabled allow rules, ports, profiles, and address scopes.

Good For

  • exposure review
  • server hardening
  • migration prep
  • incident scoping
  • policy drift detection

How to Use It

  1. Collect enabled inbound allow rules from the target host or server group.
  2. Join rule evidence with port and address filter details so broad local ports and remote-any scopes are visible.
  3. Compare active allow rules against the application owner, baseline policy, and known management ports.
  4. Flag rules with Any profile, Any remote address, broad port ranges, unknown owners, or stale application names.
  5. Separate discovery from remediation so production dependencies are understood before rule changes.
  6. Export the evidence for security and application owner review.

Execution Modes

  • local
  • remote-single-host
  • remote-host-list

Inputs and Outputs

Inputs

  • computer name
  • CSV or TXT server list
  • approved management port list
  • application owner mapping

Outputs

  • verbose-console
  • csv
  • future-html-report

Command Starter

Safe to run: read-only

Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow | Select-Object DisplayName, Profile, Enabled, Direction, Action
Get-NetFirewallPortFilter | Select-Object InstanceID, Protocol, LocalPort, RemotePort
Get-NetFirewallAddressFilter | Select-Object InstanceID, LocalAddress, RemoteAddress

Validation

  • Every scoped host has enabled inbound allow rule evidence or an access/error note.
  • Broad or ownerless rules are classified as approved, exception, unknown, or cleanup candidate.
  • Any later firewall change is validated by rerunning the same audit and testing the application path.

Reporting

  • export enabled allow rules with port and address filters to CSV
  • group broad exposure findings by host, profile, port, and owner
  • promote repeated use into a firewall policy drift report

Safety Notes

  • This audit is read-only and should not create, disable, or remove firewall rules.
  • Do not tighten firewall scopes until application dependencies, break-glass access, and rollback are documented.