The Policy Anomalies sub-section in Firewall Analyzer provides a view of all the firewall policy anomalies reports. This section can be accessed from the Policy Optimization > Policy Anomalies link under the path Reports > Rule Management.
Refer the Rule Management Report Support page, for the list of firewall devices.
Firewall Analyzer offers an exhaustive set of Firewall policy anomaly reports in the policy optimization section.
In the policy optimization sub-section, you get a variety of policy anomaly reports, which will aid you to optimize the performance of firewall policies.
The Rule Management Anomaly reports are, Correlation, Generalization, Grouping, Redundancy, and Shadow. The reports will be displayed in the graphical and tabular format.
Anomaly Classification
1. Shadow anomaly
Example:
Source | Destination | Service | Action |
10.0.0.1-10.0.0.10 | 20.0.0.1-20.0.0.10 | http,https | Allow |
10.0.0.5 | 20.0.0.3 | http | Deny |
In this case, second rule will never get hit. It is shadowed. Also, action is different for both the Rules.
2. Redundancy anomaly
Shadow and Redundant Rules are more or less similar. If Action differs it is shadow, otherwise it is redundant.
Case 1 (R1 is subset/equal of R2): Administrator can remove R1
Case 2 (R2 is subset of R1): Administrator can remove R2
Example:
Source | Destination | Service | Action |
10.0.0.1-10.0.0.10 | 20.0.0.1-20.0.0.10 | http,https | Allow |
10.0.0.5 | 20.0.0.3 | http | Allow |
3. Correlation anomaly
Example:
Source | Destination | Service | Action |
10.0.0.5 | 20.0.0.1-20.0.0.10 | http,https | Allow |
10.0.0.1-10.0.0.10 | 20.0.0.3 | http | Deny |
From the above example, in Rule 1, HTTP Traffic from 10.0.0.5 to 20.0.0.3 is allowed. If you re-order this by moving the second to top and first rule to bottom, HTTP Traffic from 10.0.0.5 to 20.0.0.3 will be blocked. The effect of the policy has changed.
Correlation is considered an anomaly warning and no suggestion required. This anomaly has to be handled explicitly by the firewall administrator.
4. Generalization anomaly:
Example:
Source | Destination | Service | Action |
10.0.0.5 | 20.0.0.3 | http | Allow |
10.0.0.1-10.0.0.10 | 20.0.0.1-20.0.0.10 | http,https | Deny |
In the above example, rule 2 is a generalization of rule 1. If the order of the two rules is reversed, the effect of the resulting policy will be changed and rule 1 will not be effective anymore, as it will be shadowed by rule 2. As a general guideline, if there is an inclusive match relationship between two rules, the superset (or general) rule should come after the subset (or specific) rule.
Generalization is considered only an anomaly warning because inserting a specific rule makes an exception of the general rule. The firewall administrator should handle it.
5. Rule Grouping
This is not an standard anomaly. It is additional one provided by Firewall Analyzer
Example:
Source | Destination | Service | Action |
10.0.0.11-10.0.0.20 | 20.0.0.1-20.0.0.10 | http,https | Allow |
10.0.0.1-10.0.0.10 | 20.0.0.1-20.0.0.10 | http,https | Allow |
Administrator can create a network object with some name say 'InternalTest' and can remove both the rules and recreate it like below:
Source | Destination | Service | Action |
InternalTest (or) 10.0.0.1-10.0.0.20 | 20.0.0.1-20.0.0.10 | http,https | Allow |
where InternalTest - 10.0.0.11-10.0.0.20 and 10.0.0.1-10.0.0.10 or instead of creating new network object it is suggested to group two rules with source as '10.0.0.1-10.0.0.20'.
Featured links