Why a firewall policy always degrades
No rule base stays clean. Every rule was added for a good reason, by someone with a problem to solve that day. What almost never happens is removal: the project ends, the server is decommissioned, the contractor leaves, and the rule stays. After a few years the policy describes the history of the organisation rather than its current needs.
Here are the defects found in nearly every audit, and how to detect them without reading thousands of lines by hand.
Six recurring defects
1. Shadowed rules
A rule higher in the list intercepts all the traffic a lower rule was meant to handle. The second one will never apply. This is the most deceptive defect: the rule exists, it is documented, it is reassuring, and it is dead. Finding shadowed rules requires analysing order and object overlap, not reading lines in isolation.
2. Duplicates
The same permission expressed twice, often with differently named objects. Harmless in itself, but each duplicate doubles the work of a review and creates the risk of a partial change: one is tightened, the other is forgotten, and the flow stays open.
3. Overly permissive rules
any/any is the most visible case, but rarely the most common. The quieter variants do just as much damage: an "any" destination on a specific port, an object group that has grown until it covers an entire network, an "any" service on an otherwise legitimate source-destination pair. The traffic actually permitted is far wider than the original intent.
4. Unused rules
A rule that has matched no packet for months is either protecting a flow that no longer exists or permitting one nobody watches. It is the best candidate for removal, but the decision needs data the configuration alone does not hold: hit counters.
5. Insecure services
Telnet, FTP, SNMP v1 or v2c, plain HTTP management: protocols still permitted because one old device needed them. The rule often outlives the device that justified it.
6. Missing logging
A rule without logging is invisible during an investigation. You discover it exists at the moment you are trying to explain an incident — that is, too late.
Why manual review fails
None of these defects is visible when reading rules one by one, because they are all relational: they come from the interaction between several rules, the evaluation order and the real contents of object groups. A human reading line 400 has forgotten line 12. This is an analysis task, not a reading task.
The multi-vendor problem compounds it: the same intent is expressed differently on each firewall, which makes comparing sites impossible without normalising first.
What to do with the findings
An audit that produces eight hundred findings will not be acted on. What makes the exercise useful is ranking: first the permissive rules exposed from an untrusted zone, then the insecure services, then the dead rules whose removal carries no risk. Duplicates and cosmetics come last.
The second useful habit is to measure the trend rather than the state: a policy improving by a few points a quarter beats a perfect audit that is never applied. Our firewall rule audit page describes the automated analysis of these defects, and the firewall module shows how risk is attributed rule by rule.
