Firewall Rule Review Checklist

Before you start

• Take the configuration from a backup or an export, not from a live session, and record the date and the firmware version.
• Collect the rule hit counters, ideally covering at least 90 days, and the change records for the same period.
• List the zones and what each is meant to hold: internet, DMZ, internal, management, partner links, cloud connections.
• Identify an owner for every rule. A rule nobody owns is already a finding.

Rules that allow too much

These are the findings that matter most, because each one is a path an attacker can use today.

• Any rule with source, destination and service all set to “any”. This is the single most common serious finding.
• Any rule with “any” in the source or the service where a specific host, subnet or port would do.
• Rules that let the internet reach internal subnets directly instead of a DMZ or a reverse proxy.
• Wide ranges such as /8 or /16 where a host or a /24 would do.
• Administrative and data services reachable from untrusted networks: SSH (22), Telnet (23), RDP (3389), SMB (445), WinRM (5985/5986), and databases and caches such as SQL Server (1433), MySQL (3306), PostgreSQL (5432), Oracle (1521), MongoDB (27017), Redis (6379) and Elasticsearch (9200).
• Cleartext protocols permitted where an encrypted one exists: Telnet, FTP, plain HTTP for administration, SNMP v1 and v2c.
• Rules with no comment, no owner or no business reason that anyone can state.

Rules that do nothing

Dead rules do not open a hole, but they hide the live ones and make every later review slower.

• Shadowed rules: an earlier rule already matches everything a later rule would, so the later rule can never be hit.
• Disabled rules left in place, and duplicate rules.
• Rules that reference objects, groups or addresses that no longer exist.
• Temporary rules whose expiry has passed. Look for “temp”, “test”, a ticket number or a date in the name.
• Rules with a zero hit count over the whole period. Confirm with the owner before removing: disaster-recovery paths and month-end or year-end jobs can look unused for months.

The device itself

A perfect rule base on a firewall with an exposed management interface is not secure.

• The administrative interface is reachable only from a dedicated management network, never from the internet.
• Administration uses HTTPS and SSH only. Telnet and plain HTTP are disabled.
• Administrators sign in through central authentication with multi-factor authentication. Default and shared accounts are removed.
• SNMP uses version 3. Community strings are not “public” or “private”.
• The running firmware is checked against the vendor's security advisories, and the result is recorded.
• Configuration backups are encrypted and access to them is restricted. A firewall configuration contains topology, object names and sometimes secrets.
• Time is synchronised to a reliable source so that logs from different devices line up.

Logging and monitoring

• The final deny rule logs. Without it you cannot see what is being blocked.
• Allow rules into sensitive zones log as well.
• Logs go to a central collector, not only to the device, which can be wiped by whoever compromises it.
• Retention matches the longest requirement that applies to you. In India, the CERT-In directions of 28 April 2022 require logs of ICT systems to be kept for a rolling 180 days within Indian jurisdiction.
• Configuration changes raise an alert that someone reads.

Change control

• Every rule traces to an approved change ticket.
• Every rule has an owner and, where it is temporary, an expiry date.
• Changes are approved by someone other than the requester.
• Emergency changes are reconciled against tickets afterwards, not forgotten.

What to keep as evidence

An auditor does not ask whether you reviewed the firewall. They ask to see the review.

• The dated configuration export you reviewed.
• The review sheet, with a decision for each flagged rule: keep, modify or remove.
• The approver's name and the date they signed it off.
• The ticket numbers for every resulting change.
• A re-run of the review after the changes, showing the findings closed.

Where this maps

References

• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
• PCI DSS v4.0, PCI Security Standards Council
• CIS Benchmarks
• CERT-In, directions under section 70B(6) of the IT Act, 28 April 2022