Table 47: Rule Shadowing Example - Juniper NETWORK AND SECURITY MANAGER 2010.3 - ADMINISTRATION GUIDE REV1 Administration Manual

Copyright © 2010, Juniper Networks, Inc.
NOTE: We highly recommend that you validate a policy before installing it. A security
policy that has internal problems can leave your network vulnerable.
Rule Duplication
Rule duplication occurs when an administrator configures the same rule in a rulebase
more than once. Rule duplication can also occur during the rule validation process for
devices running ScreenOS 5.0 and later. NSM treats each element of the rule as a separate
rule. For example, when a rule with two service objects (AOL and DNS) is sent to the
device, NSM sends it as two rules, one rule with AOL and another with DNS.
NOTE: For ScreenOS 5.0 and later, NSM sends rules with multiple objects or elements.
For example, NSM can send a rule with two or more service objects as one rule.
You should delete all duplicate rules to maintain policy lookup efficiency.
A ScreenOS 5.0 and later device passes the policy validation process for HTTP; however,
Rule 2 is not needed. To correct this problem, you should delete Rule 2.
Rule Shadowing
Rule shadowing occurs when an administrator selects or configures a policy in such as
way that the next rules have no effect on traffic. Rule shadowing can introduce system
vulnerabilities and packet dropping. Policy validation identifies rule shadowing. You
should modify or delete all rules that overshadow others.
When a packet comes in, a security device compares it to the first rule in the policy. If a
match occurs, the device executes the action associated with the rule. If no match occurs,
the rule has no effect. Then, the device compares the packet to the next rule in the policy
(unless the prior rule was a " terminal" rule.) So, each packet gets compared to every
rule in the policy until a match occurs or a terminal rule ends the match process.
For example, if Rule 1 is a terminal rule, and a packet matches Rule 1, then the device will
never compare the packet to the next rules. Or, if Rule 1 causes the packet to be dropped,
and Rule 2 adds a diffserv marking, the diffserv marking will never be added.
In Table 47 on page 503 Rule 1 shadows Rule 2. Rule 1 allows any service to a web server,
but Rule 2 denies the service HTTP. When the security device receives a packet requesting
HTTP service with the web server, Rule 1 allows the traffic. Rule 2 which denies HTTP is
never checked.

Table 47: Rule Shadowing Example

Rule From Zone Source
1 Untrust Any
2 Untrust Any
Chapter 9: Configuring Security Policies
To Zone Destination
DMZ Web server
DMZ Web server
Service Action
Any Allow
HTTP Deny
503