Firewall Shadow Rule Checker

Ordered firewall rules:

Use `any`, CIDR blocks, single IPv4 hosts, IPv4 ranges, port ranges, or service names such as http, https, ssh, rdp, and smb.

{{ params.rules.length.toLocaleString() }} chars

Firewall profile:

Choose the policy surface closest to the ordered rule export you are checking.

Action precedence model:

Use first-match for normal ACL rulebases; choose another model only when your platform evaluates actions differently.

Object-group interpretation:

Exact names are safest; inferred groups are useful for migration triage when naming conventions carry object membership clues.

Overlap strictness:

Cleanup review preserves the previous broad audit behavior; full-shadow only limits the table to unreachable lower rules.

Cleanup audience:

Choose who will read the remediation queue after the shadow scan.

{{ error }}

Disabled rule handling:

Leave off for active policy behavior; enable only when auditing dormant policy rows.

{{ includeDisabledBool ? 'Evaluate disabled rows' : 'Ignore disabled rows' }}

Finding cap per rule:

Use 3-20; higher values are useful for dense migration exports.

findings

{{ header }}	Copy
{{ cell }}
No rows for the current input.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Firewall rule order is part of the security policy, not just the way the list is displayed. In many access control lists and security policy rulebases, traffic is tested from the top of the rule list downward. When a packet matches a row, that row's action is applied and lower rows are not checked for the same decision. A broad rule near the top can therefore decide traffic that a narrower exception lower down was meant to allow, block, log, or review.

Shadowing happens when an earlier rule covers all or part of a later rule's match conditions. The match conditions usually start with protocol, source address, destination address, and destination port or service, because those fields appear in most firewall exports. Real firewalls often add more conditions, including zones, interfaces, users, applications, schedules, security profiles, route domains, NAT stages, or implied rules. A shadow review is useful because it finds the obvious ordered-rule conflicts first, then tells the reviewer where platform-native checks still matter.

Earlier broad firewall rule matching before a later specific rule, with shadow review based on protocol, source, destination, port, and action.

The most urgent shadow is usually an action conflict. An earlier allow that covers a later deny can leave the deny ineffective for the traffic it was meant to block. An earlier deny that covers a later allow can break an exception that the application owner expects to work. Same-action shadows are less dramatic, but they still create stale access intent, duplicated approvals, misleading hit-count reviews, and larger migration inventories.

Full shadow: The earlier rule covers the later rule in every modeled match field.
Partial overlap: The rules intersect, but at least one match field is only partly covered.
Opaque object: A named address, service, or object group that has not been expanded into concrete values.

Shadow review is common before firewall migrations, rulebase cleanups, recertification work, exception approvals, and change-control meetings. The main tradeoff is speed versus certainty. A CSV-based comparison can quickly reveal likely conflicts and redundant rows, but object groups, application matching, NAT order, and vendor-specific policy stages can change the real enforcement result. Treat the findings as a review queue that needs evidence, not as automatic permission to delete rules.

How to Use This Tool:

Start with the same rule order the firewall uses, then choose the assumptions that match the export.

Paste rows into Ordered firewall rules, browse for a CSV or TXT file, or load the sample. A header row helps map action, protocol, source, destination, port, remark, and enabled state.
Select Firewall profile for the closest policy surface. The profile changes parser aliases, platform warnings, and remediation wording for generic ACLs, Cisco ASA or IOS, Palo Alto security policy, FortiGate, Check Point, iptables or nftables, and cloud network ACLs.
Set Action precedence model. Use First matching rule wins for normal ordered rulebases, Deny rules override allows only when that reflects the policy surface, and Aggregate allow-list review when cumulative allow coverage is the audit goal.
Choose Object-group interpretation. Exact object names only is conservative, Infer group and member names is for rough migration triage, and Require expanded objects warns when named objects still need expansion.
Pick Overlap strictness. Full shadows only keeps the list narrow, Full shadows plus action conflicts adds partial disagreements, and cleanup modes include broader overlap relationships.
Open Advanced when needed. Disabled rule handling controls whether inactive rows participate, and Finding cap per rule limits repeated partial findings for dense policies.
Fix visible warnings before treating a finding as actionable. Invalid ports, malformed IPv4 ranges, unresolved object labels, or profile-specific warnings mean Policy Model assumptions need attention.

Read Shadow Findings for pair-level evidence, Rule Coverage for each lower row's status, Remediation Queue for change-ready cleanup notes, and Policy Model for the assumptions that shaped the scan.

Interpreting Results:

Prioritize different-action full shadows first. A high or critical Action shadow or Deny precedence shadow means the lower rule's allow or deny intent may not affect matching traffic under the selected model. Redundant shadow and Redundant allow coverage findings are cleanup candidates, but they still need owner, logging, and hit-count review before removal.

Partial conflict findings need careful comparison because only part of the lower rule intersects with the earlier rule. A high coverage value can make a partial overlap look close to a full shadow, but one uncovered address, service, or protocol can still be the reason the lower rule exists. Use Evidence and Model cue together rather than relying on the priority label alone.

Firewall shadow result interpretation guide
Output cue	What it means	Verification step
Critical or High	A different-action full shadow or promoted partial conflict needs first review.	Test the exact packet tuple in the firewall policy tester before moving rows.
Coverage at 100%	The earlier rule covers every modeled field of the lower rule.	Confirm object expansion, zones, applications, schedules, NAT, and logging intent.
Policy Model warnings	The selected assumptions do not fully match the parsed source shape.	Expand objects or switch to the profile and action model that match the export.
Ignored disabled	The row appears in coverage output but did not participate in active comparisons.	Enable disabled-row evaluation only for migration inventories or dormant-rule audits.

Technical Details:

Ordered firewall analysis compares each later rule with earlier rules that could have matched the same traffic first. The modeled packet tuple is protocol, source address, destination address, and destination port or service. The action is not part of the containment test; it changes the meaning and priority once a relationship is found.

Address containment is exact when the row contains IPv4 CIDR blocks, single hosts, IPv4 ranges, or supported wildcard-mask forms. Port containment is exact for numeric ports, port ranges, any, and recognized service names such as http, https, ssh, dns, rdp, and smb. Unexpanded names remain opaque, so the selected object-group mode determines whether only exact names match, group-like names may be inferred, or warnings are raised until objects are expanded.

Rule Core

A full shadow is a set-containment condition across all modeled match fields. The earlier rule must be broader than or equal to the later rule in protocol, source, destination, and port.

fullShadow = (P_{early} \supseteq P_{late}) \land (S_{early} \supseteq S_{late}) \land (D_{early} \supseteq D_{late}) \land (T_{early} \supseteq T_{late})

P is protocol, S is source, D is destination, and T is destination port or service. A partial overlap exists when all four fields intersect but at least one field is not fully contained.

Firewall shadow relationship rules
Relationship	Rule condition	Default priority	Cleanup meaning
Action shadow	Earlier rule fully covers the later rule and the actions differ.	High, or critical in aggressive cleanup and selected cloud ACL cases.	Move the specific rule above the broad rule, or narrow the broad rule.
Redundant shadow	Earlier rule fully covers the later rule and the actions match.	Medium, or low for aggregate allow-list coverage.	Validate hit logs and ownership before merge or removal.
Partial conflict	Rules intersect in every modeled field without full containment, and actions differ.	Review, or high in aggressive cleanup.	Split overlapping objects or compare intended exceptions before reordering.
Same-action overlap	Rules intersect in every modeled field without full containment, and actions match.	Low, or medium in aggressive cleanup.	Group only after confirming logging, owner, and request history.

Coverage Score

Partial coverage is estimated by multiplying the share of the later rule covered in each field. Address fields use the IPv4 space, port fields use ports 0 to 65535, and protocol overlap uses exact equality, any, or a midpoint value when protocols intersect without full containment.

coverage = r_{P} \times r_{S} \times r_{D} \times r_{T}

Each ratio is clamped between 0 and 1. A full shadow displays as 100% coverage. A partial overlap can still score high when the uncovered slice is small, so the original address and service definitions remain part of the review evidence.

Supported firewall shadow parser inputs and boundaries
Input or setting	Accepted behavior	Boundary or caution
CSV rows	Header-based columns or common ordered fields for rule, action, protocol, source, destination, port, remark, and enabled state.	Rows with missing headers fall back to positional parsing, so inspect Rule Coverage for mapped values.
IPv4 values	`any`, CIDR, single host, IPv4 range, and selected wildcard-mask syntax.	Malformed addresses become warnings and should be fixed before cleanup decisions.
Ports and services	Numeric ports, ranges, `any`, and common service names.	Valid numeric ports stay within 0 to 65535.
Finding cap per rule	Limits repeated partial evidence while preserving full-shadow findings.	The accepted range is 3 to 50 findings per affected rule.
Severity chart	Stacks action shadows, redundant shadows, and partial overlaps by affected rule.	The chart shows the top affected rules by accumulated severity score, not every parsed row.

Limitations and Privacy Notes:

The analysis models the fields visible in the pasted export. It cannot prove the final firewall decision when the real policy depends on fields that are not present in the row data.

Zones, interfaces, users, applications, schedules, NAT order, security profiles, implied rules, route domains, and dynamic object membership need platform-native review.
Opaque object and service names should be expanded before deleting, merging, or reordering rules.
Rule text and uploaded files are analyzed in the browser for the visible results; avoid pasting sensitive policy data into shared or untrusted browser sessions.
High-priority findings should be confirmed with policy tests, hit counts, owner records, and change-control evidence.

Worked Examples:

A broad rule allows TCP from 10.44.0.0/16 to 10.55.10.10/32 on port 443. A later rule denies TCP from 10.44.80.0/20 to the same destination and port. Shadow Findings should report an Action shadow with Coverage at 100%, and Remediation Queue should recommend moving the specific deny above the broad allow or narrowing the earlier allow.

A same-action cleanup case starts with an allow for 10.44.0.0/16 to an app subnet, followed later by an allow for 10.44.80.50/32 to the same destination and service. Rule Coverage should show the lower rule as redundantly shadowed if every modeled field is covered. That is cleanup evidence, not deletion approval, because hit logs and owner records may still justify keeping the lower row for tracking.

A migration export that contains branch_web_servers and branch_web_all behaves differently by object mode. In Exact object names only, those names do not contain each other unless the normalized names match. In Infer group and member names, Model cue can flag object-name inference as part of the relationship. Use that mode for triage, then expand the real group membership before applying changes.

A troubleshooting case is a row with 70000 as a port or a reversed-looking range outside the valid port space. The visible warning should be fixed before trusting Shadow Severity Map or Remediation Queue, because a malformed service field can hide a real overlap.

FAQ:

Does a shadow finding mean the lower rule can be deleted?

No. It means the lower rule appears covered under the selected model. Confirm object expansion, policy-test results, hit logs, owner intent, and rollback notes before deleting or moving a rule.

What should the pasted rules include?

Use ordered rows with action, protocol, source, destination, port or service, remark, and enabled state when available. A header row helps the parser map exported columns correctly.

Why are object names reported as warnings?

A name such as an address group or service group is not the same as its expanded members. Use Require expanded objects when you want unresolved names called out before cleanup decisions.

Why do partial overlaps appear in the results?

The Overlap strictness setting controls whether partial intersections become findings. They are useful for cleanup review when two rules overlap without one fully covering the other.

Which action precedence model should I choose?

Use First matching rule wins for ordinary ordered ACLs and security policy rulebases. Choose deny precedence or aggregate allow-list review only when that matches the policy surface being audited.

Why did a disabled rule show in coverage but not as evidence?

Disabled rows are ignored during active comparisons unless Disabled rule handling is switched to evaluate them. They can still appear in Rule Coverage so inventories remain visible.

Glossary:

Rulebase: An ordered set of firewall or access control rules.
First-match: An evaluation style where the first matching row decides the action and lower rows are not checked.
Shadowed rule: A lower rule whose traffic is covered by an earlier rule under the selected model.
Action shadow: A full shadow where the earlier and later actions differ, such as allow above deny.
Partial overlap: A relationship where two rules intersect but the earlier rule does not fully cover the later one.
Opaque object: An address, service, application, or group label that has not been expanded into comparable values.

References:

Guidelines on Firewalls and Firewall Policy, National Institute of Standards and Technology, September 2009.
Access Control Lists, Cisco Secure Firewall ASA Firewall CLI Configuration Guide.
Security Policy Rulebase Best Practices, Palo Alto Networks.
Network ACL rules, Amazon Virtual Private Cloud documentation.
Firewall policy, Fortinet FortiGate documentation.