Firewall Rule Cleanup: Finding and Auditing Unused Policies

A firewall policy audit is the process of proving, with evidence, that every rule in the firewall still has a business justification, actually matches traffic and is not shadowed by another rule. Rule cleanup is the output of that audit: unused, redundant and overly permissive policies are narrowed or removed in a controlled way. The result is a smaller attack surface, a readable rule base and an evidence file you can hand to an auditor.

What Is Firewall Rule Cleanup and Why Does It Become Unavoidable?

Firewall rule cleanup is the work of inventorying firewall policies, identifying those that see no traffic, sit inside the scope of another rule or have lost their justification, and then removing or narrowing them. A rule base is a living document; because nobody dares to delete, it only grows, and as it grows both risk and operating cost rise.

Rule bases grow not because of poor administration but because of how business works. A new application goes live, a server moves, a vendor is given two weeks of access, a "temporary" permit is written during troubleshooting. The project ends, the server is decommissioned, the vendor leaves; the rule stays. When an old appliance is replaced, rules are usually carried over one to one because nobody knows which ones are still needed. A few years later the administrator faces a policy list several hundred lines long, and even the most experienced engineer cannot answer "what breaks if I delete this?" with confidence.

This accumulation has three costs. The first is security: overly broad and forgotten permit rules are lateral-movement paths for an attacker who has gained a foothold. The second is operations: every change requires reading hundreds of rules, troubleshooting takes longer, and a new rule appended at the bottom is increasingly likely to be shadowed by a broad rule above. The third is compliance: when an auditor asks "why does this rule exist?" and there is no answer, a finding is written regardless of how current the firmware is.

This article does not repeat the fundamentals of policy management; for rule syntax, object handling and security profiles see our FortiGate firewall policy management guide. The focus here is auditing an existing rule base and shrinking it safely. The most efficient moment for a cleanup is a hardware replacement: as described in our migration plan from a legacy firewall to FortiGate, auditing rules before carrying them over starts the new appliance clean on day one.

Where Does the Audit Start? Rule Inventory and Business Justification

A firewall audit begins with a complete rule inventory: policies are exported for every appliance and virtual domain (VDOM), and each rule is mapped to an owner, a purpose and a change record. A rule whose justification cannot be found is flagged as suspect even if it works technically, and it enters a recertification process.

The inventory starts with a configuration backup. The dated backup taken at the start of the audit is both the rollback point and the first document in the evidence file. The policy list is then exported to a table with at least the following fields per row: policy ID and name, source and destination interfaces, source and destination address objects, services, action, schedule, NAT state, assigned security profiles, logging setting, comment field, hit count and last-used time. This table is the working surface of the audit; findings, decisions and dates are recorded in the same place.

Harder than the technical fields is the business context. Three questions are asked of every rule: Who requested it? Which business process needs it? When will it become unnecessary? The answers are sought in the comment field, in change records or in the ticketing system. On a FortiGate the policy name and comment fields are sufficient to carry a ticket number and owning department; after the audit, a naming standard that makes these fields mandatory should be adopted. NIST's SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy, recommends a deny-by-default rule base in which each rule is written as narrowly as possible and documented; the inventory table is the organization's internal counterpart to that documentation.

For rules with a known owner, a recertification round is opened: the rule list is sent to the business unit with a deadline to answer "still required" or "can be removed". Rules with no response automatically become candidates for disabling. This step prevents the technical team from making removal decisions alone and moves responsibility to where it belongs, the business owner. In our field experience this is the longest step of a first audit; in later cycles it shortens markedly because the inventory is kept current.

How Do You Find Unused Policies? Hit Count and Last-Used Data

An unused firewall policy is a rule that has matched no traffic during a defined observation window. On a FortiGate, the hit count and last-used columns of the policy table, and in the CLI the output of diagnose firewall iprope show 100004 <policy-id>, provide first and last hit times; FortiAnalyzer logs confirm the data along a time axis.

Hit count is the most powerful tool in the audit, but it is easy to misread. Depending on version and configuration, counters may restart after a reboot, a rule edit or a manual clear (diagnose firewall iprope clear 100004), and the seven-day rolling policy counter described in the FortiOS 7.2 documentation also changes the period the on-screen value covers. A value of zero therefore does not by itself mean "never used". Note when the counters started counting before you begin, and confirm counter behavior for your firmware in the Fortinet documentation. The observation window follows the rhythm of the business: ninety days is a reasonable minimum for routine office traffic, while rules serving infrequent processes such as year-end closing, periodic audits or disaster-recovery drills need a window of six to twelve months.

The second source of evidence is the logs. On FortiAnalyzer, traffic logs can be grouped by policy ID to produce a policy usage report per period; this report is independent of device counters and shows history even if a counter was reset. Our article on FortiGate logging, monitoring and FortiAnalyzer integration covers the log infrastructure and report design. Where FortiAnalyzer already handles central logging, the same platform becomes the source of audit evidence.

When an unused rule is found, the path has four steps. First, classification: permit rules and explicit deny rules are assessed separately; an explicit deny that receives no hits is often a deliberate policy statement and may be kept. Second, disabling: the rule is not deleted, its status is set to disabled and the date and audit reference are written into the comment field. Third, quarantine: if no business disruption is reported within a period such as thirty days, the rule is ready for deletion. Fourth, recording: the full definition of the deleted rule is added to the evidence file. Throughout, logging of violation traffic on the implicit deny policy should be enabled; it makes any real traffic blocked by a removed rule visible immediately and simplifies the rollback decision.

How Do You Detect Shadowed, Redundant and Conflicting Rules?

A shadowed rule never executes because a broader rule above it captures all of its traffic; a redundant rule repeats the same action for the same traffic; a conflicting rule applies a different action to partially overlapping traffic. All three show zero or low hit counts, but the root cause is an ordering error, and the fix is reorganizing rather than deleting.

Firewall policies are evaluated top to bottom and the first match wins. This simple rule produces surprises in long lists. Example: if rule twelve permits all services from the LAN to an application server in the DMZ, the "HTTPS only" rule at position twenty-five never runs; the administrator believes a narrow policy is in place, the device enforces the broad one. The more dangerous scenario is a deny rule that blocks file sharing from the guest network to a server but never takes effect because of a broad permit rule above it. In that case the security control written in the policy document does not exist in practice.

There are three ways to detect these anomalies. Organizations running FortiManager can use its Policy Consistency Check, which runs against a policy package and reports duplicate, shadowed, overlapping and unused (orphan) objects; confirm the scope of this feature in the documentation for your version. Independent rule analysis platforms inspect appliances from multiple vendors in one console and assign a risk score per rule. For small rule bases, sorting the inventory table by source and destination address overlap lets an experienced eye catch shadowed rules manually. The table below summarizes the anomaly types encountered in an audit and the correct action for each.

When a shadowed rule is found, the first question should be "which one is right?" rather than "should I delete it?". More often than not the narrow rule sitting in the shadow expresses the real intent, and the one to remove is the broad rule above it. That is why shadow analysis is carried out together with the any-any narrowing work in the next section.

Any-Any and Overly Broad Rules: Narrowing the Riskiest Policies

An any-any rule is a policy that uses "all" in at least two of the source, destination and service fields, and it effectively cancels network segmentation. The safe way to remove it is not to delete it outright but to enable logging first, measure real traffic, write narrow rules above it that cover that traffic, and disable the broad rule in stages.

Any-any rules usually come from three sources: broad permits opened at initial setup with a "make it work first" mindset, rules written during troubleshooting and forgotten, and historical policies migrated from a previous appliance. What they have in common is a high hit count; this is why they never appear in unused-rule analysis and require a separate effort. A high hit count does not prove a rule is necessary, only that a great deal of traffic passes through it.

The narrowing exercise runs in six steps. First, enable logging of all sessions on the broad rule and accumulate data across the observation window. Second, extract from the logs which source, destination and service triples are actually in use. Third, write those flows as narrow rules above the broad one, using address groups and service groups. Fourth, assign IPS, antivirus, web filtering and application control profiles to internet-bound rules; these profiles are frequently missing on the broad rule. Fifth, watch the broad rule's hit count fall toward zero; if it does not, a flow has been missed. Sixth, once the hit count reaches zero, disable the broad rule, wait through the quarantine period and delete it.

The same approach applies to management access: administrative access from the WAN interface is closed, and management is permitted only from trusted source addresses and, where possible, from a dedicated management network. These steps are independent of hardware; every model in the FortiGate family shares the same policy logic and the same counters, so the audit discipline established on a small branch appliance transfers unchanged to the head-office device.

Change Management and Audit Evidence: How Does Cleanup Stay Clean?

Cleanup stays permanent only when every new rule is created with an approved request, an owner, a purpose and an expiry date. Change management requires before-and-after configuration backups, an approval record and a rollback plan; audit evidence consists of the dated inventory, the hit-count report, the list of removed rules and the recertification correspondence.

It is common for a cleaned rule base to revert to its old state within six months, and the cause is the absence of a change process. The minimum process is this: the request enters the ticketing system with a written business justification; the technical team checks that the new rule does not shadow or duplicate existing rules; approval is obtained; the change is applied in a maintenance window; before-and-after configuration backups are retained; the result is verified and the ticket is closed. For temporary access, FortiGate schedule objects are used; an end-dated schedule lets a vendor rule expire on its own and dries up the "forgotten temporary rule" class at its source. Organizations running FortiManager can use configuration revision history to see who changed what and when, and to compare differences between revisions.

The audit evidence file answers the auditor's or customer's question "do you review your rule base?" with documents. It contains: audit start and end dates, dated configuration backups, the rule inventory table, the hit-count and policy usage report, the anomaly list with the decision taken for each, full definitions of removed and narrowed rules, business owners' recertification responses and the change tickets. The same file is the starting point of the next audit.

Compliance frameworks make this cycle mandatory. PCI DSS v4.0 requirement 1.2.7 calls for network security control configurations to be reviewed at least once every six months. In Turkey, the Personal Data Protection Authority's Personal Data Security Guide (Technical and Administrative Measures) lists firewalls and the management of access rights among technical measures; we cover the firewall side of those measures in our KVKK technical measures checklist. For retention obligations on traffic and event logs see our article on Law No. 5651 and central log management; in both areas we recommend verifying the current legislation and official guidance. Where the in-house team cannot dedicate time to this cycle, periodic policy audits are part of the standard scope of a managed firewall service.

Firewall Policy Audit Checklist

The firewall policy audit checklist is used to run an audit end to end and document its result with evidence. Each row answers a single question with yes or no and names the evidence that goes into the file; the list is repeated at least every six months, or quarterly in environments with frequent change.

Rather than turning the list into a score, we recommend converting every "no" into an action item. Many "no" answers in a first audit are normal; the aim is for the count to fall in the second cycle and for the audit to become routine maintenance by the third. In our projects the fastest gains come from a comment-field standard and end-dated schedules: these two habits markedly slow the rate at which a rule base gets dirty again.

Frequently Asked Questions

How often should firewall rule cleanup be performed?

PCI DSS v4.0 requirement 1.2.7 calls for network security control configurations to be reviewed at least once every six months. Environments with frequent changes benefit from a quarterly cycle, and any major migration or network redesign should trigger an unscheduled audit.

Is it safe to delete a rule with a hit count of zero right away?

No. Counters may have been reset by a reboot or a rule edit, and annual processes may fall outside your observation window. Confirm when the counters started, disable the rule instead of deleting it, wait through a quarantine period, then delete it and record the change.

What is the difference between a shadowed rule and a redundant rule?

A shadowed rule never matches because a broader rule above it captures all of its traffic, so the intended policy is silently not enforced. A redundant rule repeats the same action for the same traffic; it does no functional harm but bloats the rule base and complicates maintenance.

How do I see unused policies on a FortiGate?

Enable the hit count and last-used columns in the policy table and filter for zero or stale values. In the CLI, diagnose firewall iprope show 100004 returns first and last hit times per policy, and a FortiAnalyzer policy usage report confirms the finding from the log side.

Will business applications break if we remove the any-any rule?

Not if the order is right. Enable full session logging on the broad rule, measure real traffic over the observation window, write specific rules above it that cover that traffic, and wait until the broad rule's hit count drops to zero. Only then disable it.

Does a firewall policy audit count as evidence for PCI DSS or data-protection compliance?

The evidence is the output, not the activity: a dated rule inventory, hit-count report, list of removed and narrowed rules, owner recertification responses and change tickets. That file demonstrates the periodic review PCI DSS requires and the documented access control that data-protection guidance expects.

Does it make sense to outsource rule cleanup?

It does when the in-house team is consumed by daily operations; periodic policy audits are part of most managed firewall services. The key is that removal decisions are made together with business owners and every step is recorded: the external team analyzes and implements, the organization approves.

Conclusion

Firewall rule cleanup does not make the appliance more powerful; it makes the appliance enforce the policy you actually wrote. An audit cycle that starts with inventory and business justification, weeds out unused rules with hit counts and logs, reorganizes shadowed and any-any rules, and documents every step with evidence both shrinks the attack surface and produces a defensible file for PCI DSS and data-protection reviews. The secret to permanence is procedural, not technical: no rule is opened without an approved request, an owner, a purpose and an end date.

To plan a first audit of your rule base, review your current FortiGate configuration or bring periodic audits into a managed service scope, you can schedule a free discovery call with Sora Yazılım; we will define the right scope together and prepare a proposal.