Identify and Remove Redundant and Hidden Firewall Rules

Firewall policies are complex. The networks they are implemented to protect are complex. The last thing you need to deal with is extra, unnecessary complexity. Redundant rules are exactly that. They obscure the rules that are actually needed control traffic through the firewall. Redundant rules represent a tremendous opportunity to clean up a firewall policy because removal of these rules is guaranteed to have no impact on the behavior of the firewall policy. But removing them will improve both the performance of the firewall and the performance of the administrators responsible for managing the firewall policy.

What is a Redundant Rule?

Firewall policies are comprised of a list of rules that are processed in order. When a data packet arrives at the firewall, the firewall attempts to match it to a rule in the policy. Once a rule is matched, the packet is processed according to the defined action such as to drop or pass the data. Since the packet will never be evaluated by any rule lower than the matched rules, any rule defined lower in the policy that would match this same packet is redundant.

However, since many rules define access for more than a single source IP, single destination IP and single service, there are varying degrees of redundant. Portions of one rule may be redundant to portions of another rule. While these present an opportunity for refinement as well, we will focus on the rules that are completely redundant. A completely redundant rule can be removed outright. A partially redundant rule may require modification or may even require creation of additional rules to properly remove the redundancy without affecting behavior. This will be addressed in another post to review these additional intricacies.

Let’s take a look at some example redundant rules that can be easily remedied:

  • Identically Redundant: This first example is an identical rule that is clearly redundant. All matching columns are identical. While the comments are different, the rule number and comments do not affect the behavior of the firewall matching. In this case, the second rule, rule 18, can be removed without affecting the firewall behavior.identical
  • Hidden: The next example is a fully hidden rule. In the below example, the source and service columns are different. However, upon further investigation, you can see that rule 14’s source network of fully includes rule 19’s source address of And the service of “ip” (meaning the entire IP protocol space) includes http (tcp/80). So, while the rules are defined differently, any traffic that rule 19 would match would already have been matched by rule 14, making rule 19 completely hidden.hidden
  • Redundant: An inverse of the hidden case is when a lower rule fully includes the higher rule’s criteriagroup plus more. In this case, while the first rule will match some traffic, you can’t get rid of the lower rule because the lower rule would not only match what the first rule matches, but will also match additional traffic. In the below example, it is not completely obvious because the service column of rule 2 contains a group object. However, on further inspection, you can see that the group object contains icmp-echo-reply that is referenced in rule 1. In this case, it is safe to remove rule 1 without affecting the behavior of the policy.redundant

WARNING: You must take extreme caution when identifying this type of redundancy. Had there been a rule defined between rule 1 and rule 2 that treated some portion of the matched traffic uniquely, then while rule 2 fully encompasses the packet space referenced in rule 1, it would not be safe to remove rule 1 without affecting the policy behavior.

How can FireMon Help?

FireMon is able to perform all of this analysis on the policies to identify these situations and more. In large complex policies with group objects obscuring what each rule is doing it can be extremely difficult to do this analysis manually. FireMon’s Hidden Rule reports will identify these situations and even provide the actionable intelligence on exactly what step to perform. For example, in the Hidden example shown above, FireMon not only shows the rules, but clearly makes the recommendation on what steps to take to remedy the situation.


In addition to generating reports for hidden rules, it is possible to search for all hidden rules across all devices and all policies. Using FMQL, it is possible to find hidden rules with the following query:

rule{ ~ ‘hidden’}

And, using FMQL, it is possible to identify hidden rules matching additional criteria like rules that are not only hidden, but also missing comments.

rule{ ~ ‘hidden’ and comment IS EMPTY}