How do you review firewall rules, and which ones should go?

The short answer: you go through every rule in the order the firewall evaluates them and ask each one the same questions. Does traffic still use it? Is it wider than the job needs? Does a rule above it mean it never matches? Has its end date passed? Does anyone own it? The rules that should be changed or removed fall into six groups: shadowed, redundant, any-any, unused, expired temporary rules, and rules with no owner or reason.

NIST SP 800-41 Rev. 1, NIST's firewall guideline (September 2009), notes that firewall rulesets can become increasingly complicated with age: a ruleset that starts with a handful of entries will likely contain far more by the end of its first year in production, and a review can uncover rules that are no longer needed. What follows is a checklist you can work through.

RULEBASE (top-down, first match)        REVIEW                  
  # name     src  dst      service      finding / action        
────────────────────────────────────────────────────────────────
▶ 1 web-in   any  dmz-web  tcp/443                              
                                                                
  2 lan-out  lan  any      any                                  
                                                                
  3 lan-dns  lan  dns-srv  udp/53                               
                                                                
  4 old-ftp  lan  ftp-01   tcp/21                               
                                                                
  5 vendor   ext  db-01    tcp/1433                             
                                                                
  6 mon-snmp mgmt any      udp/161                              
                                                                
  7 deny-all any  any      any                                  
                                                                
checking                                                        

What do you need before you start?

Three things: the ruleset exported in its real order, usage data for every rule, and the change history since the last review.

• The ruleset, in order. Many firewalls check traffic against rules in a sequential manner until a match is found, so order matters as much as content. On FortiGate, use the By Sequence view, which displays policies in the order that they are checked for matching traffic without any grouping.
• Usage data. PAN-OS shows Hit Count, Last Hit, First Hit, Modified and Created for each rule. FortiGate stores seven numbers for the last seven days and an active counter for the current day, and the CLI shows first and last hit times.
• Change history. NIST says each review should include a detailed examination of all changes since the last regular review, particularly who made the changes and under what circumstances.

For an HA pair, collect from both firewalls. On PAN-OS, rule hit counts are not synchronized across firewalls in a high availability (HA) deployment. If you only read today's active unit, a rule that was busy while the other unit was active looks unused.

Which rules should be removed or changed?

Work from the top down and run each rule through the six checks below.

1. Shadowed rules

A shadowed rule is one that traffic never reaches, because a broader rule above it already matches everything it would match. Palo Alto Networks' knowledge base says the shadow warning generally indicates a more broad rule matching the criteria is configured above a more specific rule. PAN-OS prints it at commit time:

Rule 'rule1' shadows 'rule2'
Configuration committed successfully

The commit still succeeds, which is why the warning is easy to miss. The same article notes that unresolved FQDNs can also trigger it, so check FQDN objects before concluding a rule is really shadowed.

Action: if the shadowed rule's action is the one you want, move it above the broader rule. If not, delete it; it has never had any effect.

2. Redundant rules

A redundant rule is one you can delete without changing the outcome for any traffic, because another rule with the same action covers it. Unlike a shadowed rule, a redundant rule can still show hits, since traffic reaches it first; without it, that traffic would match another rule with the same result. NIST notes that some firewalls have tools that review policies automatically, looking for such things as redundant rules, and that such tools should be used periodically, probably as part of the regular policy review.

Action: merge the two, or remove the narrower one, then check that the remaining rule's hit count rises as expected.

3. Any-any rules

A rule with any as its source, destination or service goes against two NIST principles: rulesets should be as specific as possible with regards to the network traffic they control, and firewalls should block all inbound and outbound traffic that has not been expressly permitted by the firewall policy, known as deny by default. An any service permits everything nobody thought to forbid, which is the opposite.

Action: use the rule's traffic logs to see what actually passes, write a new rule for just that, and place it above the old one. When the old rule stops getting hits, disable it. The PAN-OS docs describe the same method for moving from port-based to app-based rules: add the new rule above, then use hit counts to determine whether it is safe to remove the port-based rule.

4. Rules with no hits

A rule that has matched nothing over a long enough period is a candidate to disable. The PAN-OS docs give the reason: to prevent attackers from exploiting over-provisioned access, such as when a server is decommissioned or when you no longer need temporary access to a service, use the policy rule hit count data to identify and remove unused rules. Policy Optimizer can filter, for example, for Unused rules within the last 30 days.

Action: disable first; don't delete yet. The next section explains why.

5. Expired temporary rules

Rules opened for a vendor visit or a test are rarely closed by anyone. If your firewall can expire a rule, set the date when you create it. FortiOS 7.4 has Policy expiration, a date on which the policy is disabled. The default state is Disable (the policy does not expire); Default expires it after 30 days, a value you can set between 0 and 365:

config firewall policy
    edit 25
        set policy-expiry enable
        set policy-expiry-date "2025-10-31 18:00:00"
    next
end

Action: search for rules whose name or comment says they are temporary. Past the agreed date, disable them. If one is still needed, ask for a new end date and a reason.

6. Rules with no owner or reason

A rule with no comment, no ticket number and no known requester is a rule nobody can say is still needed. NIST: a rule comment is important for others to determine why a rule was made and is quite useful to people auditing rulesets, and a log should be kept of all policy decisions and ruleset changes. FortiOS 7.4 can enforce this with Policy change summary, which enforces an audit trail for changes to firewall policies.

Action: find the owner from the change log or from the traffic the rule carries, and add a comment. If you can't find one, treat it as an unused rule and put it through disable-before-delete.

Why shouldn't you delete a rule with zero hits right away?

Because a zero does not always mean nobody uses it. There are at least four ways the number misleads:

• The window is too short. A quarterly or yearly job won't show up in 30 days, and FortiGate's policy list shows only the past seven-day hit count.
• The counter was reset. On PAN-OS the hit count persists through reboot, dataplane restarts, and upgrades unless you manually reset or rename the rule, and reset data is no longer available. On FortiGate, Clear Counters deletes the traffic statistics for the policy.
• Only one HA unit was checked, as above.
• It is a standby rule, for example one that only matters after a failover to a recovery site.

Check the Created and Modified dates too: a rule added yesterday also has zero hits. PAN-OS Policy Optimizer can exclude rules reset during the last number of days you choose.

How do you remove a rule without breaking something?

In three moves: test, disable, then delete.

1. Test before you change. Use a policy match tool to ask the firewall which rule a given flow would hit. On PAN-OS it is under Device > Troubleshooting, where you enter zones, source, destination, port and protocol. On FortiGate it is Policy Lookup, which highlights the matching policy in the list. This tells you where traffic will land once a rule is moved or disabled.
2. Disable first, and tag it with the date. PAN-OS lets you disable and tag rules directly from the policy optimizer. A disabled rule can be turned back on in one step if someone calls to say something stopped working.
3. Delete after a waiting period. Once a full cycle has passed that covers monthly or quarterly jobs, with no complaints, delete the rule and record it in the change log.

Every step should go through change management. NIST says ruleset changes should be managed by a formal change management control process because of their potential to impact security and business operations, and that firewall policies and rulesets should be backed up regularly. Take the backup before you start.

How often should you review firewall rules?

NIST does not give a number. It says it is best to review the firewall policy at regular intervals so that such reviews do not only happen during policy or security audits (or, worse, only during emergencies), and suggests occasionally having people outside the normal review team audit the whole ruleset, to see how well the policy matches the organisation's goals. It also suggests penetration testing to confirm the ruleset behaves as intended, in addition to, rather than instead of, a conventional audit program.

My view: the right interval is one the team will actually keep every time. If rules change often, a shorter cycle means less to look at each round. If a standard or regulation you follow sets an interval, treat that as the minimum.

Sources

• NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy (September 2009)
• Palo Alto Networks PAN-OS 11.1: View Policy Rule Usage
• Palo Alto Networks PAN-OS 11.1: Test Policy Rules
• Palo Alto Networks Knowledge Base: What is a Shadow Rule?
• Fortinet FortiOS 7.4.0: Firewall policy
• Fortinet FortiOS 7.4.2: Seven-day rolling counter for policy hit counters