Firewall rule review: a checklist for quiet risks.

A firewall starts life with a tidy rule set. A year or two later it has dozens of exceptions added for a vendor, a project, a temporary test or “just for now”. Each one is a small gap, and together they are how many breaches begin. A regular rule review is cheap and effective.

Before you start

• Export and save the current configuration.
• Get the network diagram and a list of servers, sites and services.
• Gather the change history, if you have one.
• Agree who can approve the removal of a rule, and a way to restore it quickly.

The review

1. Rules that are too broad

• Any source to any destination on any port.
• Whole subnets allowed where one host would do.
• Wide port ranges when one port is needed.
• Rules that allow management ports (remote desktop, SSH, web admin) from the internet.

2. Rules nobody uses

Most firewalls show a hit count. A rule with no hits for six months is a candidate for removal. Disable first, wait, then delete.

3. Rules nobody owns

Every rule should have a name, a reason, an owner and an end date if it is temporary. If nobody can say why a rule exists, treat it as a risk.

4. Shadowed and duplicate rules

A rule placed below a broader rule never fires. Duplicates add confusion. Clean up the order so that specific rules come before general ones and the last rule denies everything.

5. Logging

Check that rules which matter are logged, and that logs are stored off the device and kept long enough to investigate an incident. Log volume that is too large to read is a sign that the rules need attention.

6. Access to the firewall itself

• Limit the admin interface to a management network or VPN.
• Remove default and shared accounts, use named accounts and multi-factor authentication.
• Remove staff and vendor accounts that are no longer needed.
• Check that the admin password was changed from the default.

7. VPN and remote access

Review who has VPN access, whether former staff and vendors still do, and whether multi-factor authentication is on. Remove inactive accounts.

8. Firmware and subscriptions

Is the firmware current? Do the intrusion prevention and web filtering subscriptions still run? Has the model reached end of life? See renewal and end-of-life planning.

9. Segmentation

Do guest, staff, server and camera networks match your design? Look for rules that quietly connect them. Our note on network segmentation shows what good looks like.

After the review

1. Write down what changed and why.
2. Fix the highest risks first, the open management ports and the any-any rules.
3. Put a date in the calendar for the next review, ideally every six months, and after any big change in the business.
4. Introduce a simple change process so new rules are named, justified and given an end date.

A review does not need special tools to start, only a clear head and the willingness to delete things. If your team does not have the time, a managed review under an agreement is a sensible use of an engineer’s day. The checklist also helps when you choose a firewall project scope.