Firewall Rule Audit Checklist: 15 Checks to Run Every Quarter

Most firewall rule sets don't fail all at once. They rot quietly: a temporary exception from a project that shipped two years ago, an any-any rule added at 2 a.m. during an incident, an address group still pointing at a subnet that was re-IP'd last spring. None of these will page you at night. Together, they widen the opening an attacker needs.

A quarterly audit is the cheapest way to keep that drift in check. Ninety focused minutes four times a year beats a week of emergency clean-up after a penetration test goes badly. What follows is a checklist you can run as-is, adapt to your platform, and hand to whoever owns the firewall next quarter.

Before You Start: Get a Baseline You Can Compare

Audit first, change second. Reviewing and editing at the same time makes it impossible to tell whether a rule was always odd or whether you just broke it.

Export the full configuration in text form and store it with a timestamp. Capture rule hit counters before resetting anything, note the firmware version, and record which zones or interfaces are in scope. If your platform supports configuration diffing, run a diff against the last approved export. That diff, not your memory, is the starting point.

The 15 Checks

Rule hygiene

1. Any-any rules. Find every rule with "any" as source, destination, or service. Each one needs a written business reason and an expiry date, or it needs to go.
2. Port and protocol scope. Look for rules permitting full port ranges (1–65535) or "any" service. Watch for management protocols like RDP, SSH, or SMB crossing into user or guest segments where they have no reason to be.
3. Shadowed and redundant rules. A rule that can never match because an earlier rule already covers the same traffic is pure confusion. Reorder or delete it.
4. Disabled rules. Anything named "temp", "test", or "old" that has been disabled for months is clutter. Delete it, or give it a ticket and a date.

Exposure and reachability

1. Internet-facing inbound rules. For each one, confirm the destination host still exists, still runs that service, and is still supposed to be public. Decommissioned servers keep their NAT entries far too long.
2. Management access. Verify that administration interfaces are reachable only from dedicated management networks, not from user VLANs, wireless, or the internet.
3. Egress rules. Broad outbound permissions let a compromised host call home. Check which internal systems can reach the internet directly and whether that matches expectations.
4. VPNs and tunnels. Review peer addresses, allowed subnets, and key or certificate validity. Retire tunnels whose remote site closed, and check that unused tunnels are actually down.

Objects and ownership

1. Address objects and groups. Hunt for stale IPs, duplicate objects with different names, and groups with a single member. A group whose contents nobody recognises is a hidden gap.
2. Named owners. Every rule should carry a ticket number, an owner, and a creation date in its description or comment field. No owner means no defender when someone asks whether it is safe to remove.
3. Expiry dates. Confirm that temporary rules have genuinely expired, and that scheduled rules fire when you expect. Re-test the ones you keep.

Logging, review, and change control

1. Logging coverage. Deny rules should be logged. Confirm your collector is receiving events and isn't drowning in noise, then skim the denies for traffic you cannot explain.
2. Hit counters. Sort rules by hit count and reset the counters. A rule with zero hits for 90 days deserves a question. Some rules only fire seasonally, such as payroll or year-end backup traffic, so treat counters as a prompt, not proof.
3. Change history. Compare the current configuration to the last approved one. Every difference should map to a change ticket. Unexplained differences are the ones that matter.
4. Backup and rollback. Confirm the configuration is backed up off the device, that someone has actually restored one in a test, and that you know how long a rollback takes.

Turning Findings Into Changes Without an Outage

Sort findings into three buckets: immediate fixes for genuine exposure, scheduled changes for cleanup, and documented exceptions for rules that must stay broad.

The safe removal sequence is disable, wait, then delete. Disabling keeps the rule visible if traffic breaks, which makes diagnosis a one-minute job instead of an hour. Let a disabled rule sit for a full business cycle before deleting it, and longer for anything tied to quarterly or annual processes. Before you disable, check the logs to see what actually matched it in the last 30 days.

Do removals in a change window with a rollback plan, and test the affected service before and after. If a vendor or partner insists a rule must stay, ask them to confirm the source and destination ranges in writing. Vague answers usually mean the rule is a workaround, not a requirement.

Documenting the Audit

The audit is only useful if next quarter's reviewer can pick it up cold. Record the date, the configuration version or hash, who performed the review, and the findings with severity and decision for each one.

• Rules removed, disabled, or modified, with ticket references
• Exceptions granted, with the owner and review date
• Items deferred, with a reason and a target quarter
• Open questions for application or network owners

Keep this register next to the configuration itself, not in someone's mailbox. If your team changes, the document is the handover.

Make the Next Quarter Easier

Most of the pain in a firewall audit comes from missing context, not from the rules themselves. Add the owner, ticket, and expiry date when a rule is created and you eliminate half of next quarter's detective work. Configure exports and diffs to run automatically. Ask your monitoring platform to report zero-hit rules on a schedule. Book the audit slot in the calendar now, so it doesn't become a project you start six months late.

Four short reviews a year keep the rule set close to what your network actually does. That is a far better place to be than explaining to an auditor, or an attacker, why the door you thought was locked has been propped open since 2022.

Photo: Grove Brands / Pexels