Firewall Shadow Rule Checker

A firewall rule can be correct in isolation and ineffective in its rulebase. In an ordered policy, an earlier rule may already match every packet that a later rule describes. The later rule is then shadowed: traffic reaches the earlier decision first, so the later intent cannot take effect under a first-match model.

Each packet-filter rule describes a tuple of protocol, source, destination, and service or port. Full shadowing occurs when an earlier tuple contains the later tuple in all four dimensions. Partial overlap means the two rules intersect in every dimension but neither necessarily covers the other completely.

Action semantics vary across platforms and policy layers. Some lists are first-match, some apply explicit deny precedence, and some reviews aggregate allows. Implied rules, zones, interfaces, state, application identity, schedules, NAT, and nested chains can also change the real outcome. A shadow finding is therefore a structured review lead, not permission to delete a rule.

Named address and service objects create another uncertainty. Equal expanded ranges can hide behind unrelated names, while similar names may describe different members. Exact-name comparison is conservative; inferred-name comparison is heuristic; fully expanded exports give the strongest containment evidence.

Safe cleanup requires more than static overlap. Confirm the active platform and policy layer, inspect hit logs, identify the owner and business purpose, test the intended traffic, prepare rollback, and validate the policy with the vendor's own parser or simulator before deployment.

How to Use This Tool:

Export one ordered policy layer and keep the original rule order intact.

1. Paste or load CSV rows containing action, protocol, source, destination, and port. Include order, remark, and enabled state when the export provides them.
2. Choose the closest Firewall profile and confirm the Action precedence. These assumptions decide which earlier and later action pairs can be reported.
3. Use exact object names for a conservative first pass. Select inferred groups only for triage, or provide expanded addresses and services when cleanup decisions need stronger evidence.
4. Choose full shadows for the narrowest review. Add action conflicts or broader cleanup overlaps only when partial intersections are useful to the review audience.
5. Leave disabled rules out of active-policy comparison unless historical or migration analysis needs them. Set the evidence cap high enough to reveal material partial overlaps without burying each affected rule.
6. Resolve invalid-token and model warnings before acting on findings. Review action shadows before redundant and partial-overlap candidates.

Technical Details:

The analysis models ordered IPv4 packet-filter tuples. It understands IPv4 hosts, CIDR blocks, address ranges, any, numeric ports, port ranges, and common service names such as HTTPS and SSH. Cisco-style wildcard masks are interpreted only for the generic ACL and Cisco profiles. Unknown objects remain opaque rather than being invented.

Transformation Core:

1. Map the supplied columns or standard positions into ordered rules.
2. Normalize action aliases, protocols, IPv4 ranges, service names, and enabled state.
3. Compare each later rule with every earlier considered rule.
4. Test containment and intersection separately across protocol, source, destination, and port.
5. Apply the selected precedence and overlap policy, then classify and prioritize each retained finding.

Rule Core:

Full containment requires the earlier rule to contain the later rule in all four tuple dimensions. Partial intersection requires at least one intersection in every dimension. The displayed coverage estimate multiplies dimension-level overlap ratios and rounds the result to a whole percent; full containment is always 100%. This estimate is a sorting clue, not a traffic probability.

Containment Example:

An earlier allow for TCP from 10.0.0.0/8 to 192.0.2.10/32 on port 443 fully contains a later deny from 10.1.0.0/16 to the same destination and service. Under first-match precedence, the later deny is an action shadow. Replacing https with numeric port 443 does not change the result.

Opaque objects with the same normalized name can match in every object mode. In inferred-group mode, a group-like parent may contain another name when at least 60% of the child's meaningful name tokens correspond. That rule is deliberately heuristic and always needs membership verification.

The evidence cap applies only to partial findings for each later rule and accepts 3 through 50. Full shadows are not hidden by that cap. Invalid IPv4 or port tokens are excluded from overlap matches and counted as warnings rather than coerced into valid ranges.

Interpreting Results:

Start with Action shadow or Deny precedence shadow findings because an earlier decision may defeat the later intent. Redundant shadow suggests duplicate behavior, while Partial conflict and Same-action overlap require expanded tuple review.

A clean result means no relationship met the selected local model. It does not prove the deployed firewall is correct. Compare the finding with the native configuration, object membership, implied rules, logs, and a controlled traffic test before reordering, narrowing, merging, or deleting anything.

Limitations and Security Notes:

Rule text is parsed in the browser and is not placed in the page URL. The input limit is 2,000,000 characters and only the first 5,000 rule rows are analyzed.

• The model is not a vendor-native parser, compiler, policy simulator, or live firewall query.
• IPv6, NAT, interfaces, zones, application identity, users, time schedules, connection state, nested chains, and implied defaults are outside tuple comparison unless already reflected in the supplied fields.
• Object-name inference can create false positives or miss equivalent groups with unrelated names.
• Never apply cleanup directly from a finding. Preserve the source policy, approval record, validation plan, monitoring plan, and rollback path.

References:

• NIST SP 800-41 Rev. 1: Guidelines on Firewalls and Firewall Policy, National Institute of Standards and Technology, September 2009.
• How to replace an iptables rule, Simplified Guide.
• How to configure a basic stateful firewall with iptables, Simplified Guide.