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

{{ error }}

Disabled rule handling:

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

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

Partial overlap alerts:

Keep on for cleanup reviews; the table still separates partial overlaps from full shadows.

{{ flagPartialBool ? 'Report partial overlaps' : 'Full shadows only' }}

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.

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Firewall rule order decides which policy action a packet sees first. In many ordered firewall rulebases, traffic is compared with the first rule, then the next rule, and processing stops as soon as a rule matches. A broad rule near the top can therefore make a narrower rule below it unreachable, even when the lower rule was added as an exception, cleanup block, or temporary migration entry.

A shadowed rule is not the same as a harmless duplicate. If an earlier allow rule covers the protocol, source, destination, and port of a later deny rule, the later deny may never take effect for that traffic. If both actions are the same, the lower row may still add clutter, confuse reviewers, or hide the fact that a parent rule already grants the same access.

Diagram showing a broad earlier firewall rule matching before a later specific rule, with shadow review based on protocol, source, destination, and port coverage.

Shadow review is useful before rulebase cleanup, migration, exception approval, and change review. It helps answer whether a new block rule would actually block traffic, whether a narrow allow rule sits below a wider allow, and whether partial overlaps need a human comparison before anyone moves rules around.

A shadow finding is still a model of the supplied rows, not a substitute for production hit counts, object expansion, zone rules, application matching, NAT order, or a firewall vendor's own commit checks. The result should start a focused review, not close the change by itself.

Technical Details:

Ordered packet-filter rules are usually evaluated as a tuple of match fields plus an action. For this review, the important fields are protocol, source address, destination address, and destination port or service. An earlier row fully shadows a later row when every packet that could match the later row is already covered by the earlier row's match fields.

The action determines the practical severity. Full coverage with different actions is an action shadow because the lower rule expresses a different decision that may never happen. Full coverage with the same action is a redundant shadow because the lower rule repeats an outcome that the earlier rule already provides. Partial overlaps are weaker signals: they mean the two rows intersect, but the earlier row does not cover the entire lower row.

The full-shadow test can be read as a coverage condition across all four dimensions:

full shadow = (P_{earlier} \supseteq P_{later}) \land (S_{earlier} \supseteq S_{later}) \land (D_{earlier} \supseteq D_{later}) \land (T_{earlier} \supseteq T_{later})

Here, P is protocol, S is source, D is destination, and T is destination port or service. The superset symbol means the earlier row covers the later row for that field. If any field only intersects instead of fully covering the later row, the finding becomes a partial overlap rather than a full shadow.

Firewall shadow finding rules and priorities
Finding type	Rule condition	Priority	Practical reading
Action shadow	Earlier row fully covers the later row and the actions differ.	High	The lower allow or deny may not affect matching traffic.
Redundant shadow	Earlier row fully covers the later row and the actions match.	Medium	The lower row may be a duplicate, stale exception, or cleanup candidate.
Partial conflict	Rows intersect in all match fields, do not form full coverage, and the actions differ.	Review	Some traffic may be affected by both intents, so ownership and intended order matter.
Same-action overlap	Rows intersect in all match fields, do not form full coverage, and the actions match.	Low	The overlap may be safe, but it can still point to rulebase clutter.

Coverage percentage is exact for full shadows and estimated for partial overlaps by multiplying the overlap share across protocol, source, destination, and port. IPv4 CIDR blocks, single IPv4 hosts, IPv4 ranges, numeric ports, port ranges, any, and recognized service names can be compared by containment. Object names or unrecognized service labels are treated as opaque values, so they match only when the text is the same.

Accepted firewall rule fields and review outputs
Surface	Accepted or returned values	Why it matters
`Ordered firewall rules`	CSV or plain text rows with optional headers for rule, action, protocol, source, destination, port, remark, and enabled.	Row order is the evidence base for shadow detection.
`Action`	Allow-style words such as `allow`, `accept`, and `permit`; deny-style words such as `deny`, `drop`, `block`, and `reject`.	Action difference separates high-priority shadows from same-action duplicates.
`Protocol`	`tcp`, `udp`, `icmp`, numeric protocol tokens `6`, `17`, `1`, or `any`.	Protocol coverage must match before a lower row can be fully shadowed.
`Source` and `Destination`	`any`, IPv4 CIDR, single IPv4 hosts, IPv4 ranges, or exact text labels.	Address containment decides whether a broad subnet covers a specific host or smaller subnet.
`Port`	`any`, numeric ports, ranges, and service names such as `http`, `https`, `ssh`, `rdp`, `smb`, and `postgres`.	Service parsing turns common names into comparable port numbers.
Shadow Findings	Affected rule, earlier rule, finding type, action pair, coverage, evidence, and next action.	This is the main evidence table for change review.
Rule Coverage	Each parsed rule, normalized fields, earlier overlap counts, and status.	The table shows which rows were clear, shadowed, overlapped, or ignored as disabled.
Remediation Queue	Priority, affected rule, problem, recommendation, and change note.	The queue orders the cleanup work before anyone edits the rulebase.

The model does not expand vendor object groups, zones, users, schedules, applications, NAT translations, or live hit counters. Treat IPv6 rules and complex vendor objects as items that need firewall-native review unless they have been expanded into comparable IPv4, protocol, and port fields first.

Everyday Use & Decision Guide:

Start with a firewall export that preserves the real top-to-bottom order. Paste the rows into Ordered firewall rules with a header when you have one. Header names can vary, so a spreadsheet export with columns such as action, protocol, source, destination, service, comment, and enabled is usually easier to audit than a pasted vendor command dump.

Leave Disabled rule handling set to ignore disabled rows for active policy review. Turn it on only for migration inventory work where dormant rows still need cleanup notes. Keep Partial overlap alerts on for cleanup reviews because many risky exceptions are not full shadows; they are partial conflicts where the earlier row and later row overlap on only part of the address or port space.

Use Load sample when you want to see the expected CSV shape before pasting a real export.
Use Normalize spacing after pasting rows copied from a ticket, spreadsheet, or terminal output.
Raise Finding cap per rule for dense migration exports where a lower row intersects many earlier rows.
Check the yellow warning list before trusting results. Invalid IPv4, CIDR, or port values can reduce the value of the review.
Read Rule Coverage before deleting anything. It shows ignored disabled rows and lower-priority same-action overlap that may not appear urgent in the summary.

A good fit is a cleaned export where each row has one clear action, protocol, source, destination, and port. A poor fit is a raw policy with unresolved object groups, application IDs, dynamic address lists, user identities, or zone logic that changes which traffic can match. Expand those objects first or use the finding as a prompt for firewall-native testing.

Do not read No shadows as approval. It means the parsed rows did not produce full shadows or reported partial overlaps under the current settings. Confirm hit counts, object expansion, vendor commit warnings, and intended business access before moving, merging, or removing rules.

Step-by-Step Guide:

Review one ordered rule export at a time so the summary, tables, and chart describe the same rulebase.

Paste rows into Ordered firewall rules, or use Browse rules to load a CSV or text file under the displayed size limit.
Include a header row when possible. Columns such as rule, action, protocol, source, destination, port, remark, and enabled give the parser the strongest signal.
Use Normalize spacing if pasted rows include blank lines or inconsistent row spacing. The rule count in the summary should still match the active rows you expect to audit.
Open Advanced and set Disabled rule handling. Choose Ignore disabled rows for active behavior, or Evaluate disabled rows when reviewing dormant rules for cleanup.
Leave Partial overlap alerts enabled unless you only want full shadows. If partial alerts are disabled, Shadow Findings will omit intersecting rows that are not fully covered.
Set Finding cap per rule high enough for the export. Hidden partial evidence still appears in counters, but a low cap can keep repeated earlier-row examples out of the visible finding table.
Fix warnings before acting. A message such as invalid CIDR, invalid IPv4 address, invalid port, or no parsed rules means the input needs cleanup before the tables are useful.
Read the summary, then open Shadow Findings. Start with Action shadow rows because they show lower rules whose allow or deny decision can be bypassed by an earlier rule.
Use Remediation Queue for the handoff note. Its recommendation and change note columns translate each finding into review work such as reordering, narrowing, splitting, merging, or validating logs.
Open Shadow Severity Map when many rules are affected. Tall stacked bars identify the lower rules with the largest mix of action shadows, redundant shadows, and partial overlaps.

A useful handoff has parsed rows without warnings, high-priority shadows reviewed first, and any proposed reorder checked against the firewall's own policy test before deployment.

Interpreting Results:

The most important output is the highest-priority row in Shadow Findings or Remediation Queue. Coverage of 100% means the earlier row covers the lower row across protocol, source, destination, and port. Coverage below 100% means the rows intersect, but only part of the lower row is affected.

Firewall shadow result cues and follow-up checks
Visible cue	Best first reading	What to verify next
Action shadow with `100%` coverage	A lower rule's opposite action may never be applied for the covered traffic.	Move the specific row above the broad row, or narrow the broad row after testing intended matches.
Redundant shadow with `100%` coverage	The lower row repeats an action already covered above it.	Check hit logs and ownership before merging or removing the duplicate intent.
Partial conflict	Only some traffic overlaps, and the two actions disagree.	Split address or port objects, then retest the intended order.
Same-action overlap	The rules overlap without changing the action.	Confirm whether the overlap is a named exception, a temporary row, or rulebase clutter.
Ignored disabled	The row was not evaluated because disabled rows are excluded.	Turn on `Evaluate disabled rows` only if the inventory review needs dormant rows.
No shadows	No checked full shadows were found, and partial findings may be absent under current settings.	Verify object expansion, hit counts, zones, application rules, NAT behavior, and vendor commit checks.

The chart is a triage aid, not the authority for a firewall change. Use it to find crowded problem rows, then make the actual decision from the evidence and recommendation columns in the tables.

Worked Examples:

A migration export starts with rule 10, allow tcp 10.44.0.0/16 10.55.10.10/32 443, followed by rule 20, deny tcp 10.44.80.0/20 10.55.10.10/32 443. The earlier allow covers every protocol, source, destination, and port value in the later deny. Shadow Findings reports an Action shadow with 100% coverage, and Remediation Queue recommends moving the specific rule above the broad rule or narrowing the broad rule first.

A cleanup review has rule 40, deny tcp 203.0.113.0-203.0.113.255 10.55.20.0/24 22, followed by rule 50, deny tcp 203.0.113.15/32 10.55.20.10/32 ssh. The service name ssh maps to port 22, and the earlier deny contains the later host, destination, and port. The finding becomes a Redundant shadow, which is a cleanup candidate only after hit logs and rule ownership are checked.

A branch policy contains rule 100, allow tcp 10.0.0.0/24 10.2.0.0/25 443, then rule 110, deny tcp 10.0.0.128-10.0.0.255 10.2.0.64-10.2.0.191 443. The source and port are covered, but only half of the later destination range overlaps the earlier destination. With Partial overlap alerts on, the result is a Partial conflict around 50% coverage, which calls for splitting the destination range before reordering.

A troubleshooting case starts with pasted rows that include 2001:db8::/64 or a port such as 70000. The warning list reports invalid IPv4, CIDR, or port evidence, and the affected rows should not drive cleanup decisions. Replace unsupported address notation with expanded comparable fields, or review those rows in the firewall platform that owns the objects.

FAQ:

Does a shadow finding prove the lower rule is unused?

No. It proves that the supplied rows show coverage under the parsed protocol, source, destination, and port fields. Production hit counters, zone logic, object expansion, application rules, NAT order, and vendor policy tests can still change the final operational answer.

Why did a disabled rule not appear in the findings?

Disabled rows are ignored by default because they do not participate in active top-down evaluation. Turn on Evaluate disabled rows when the purpose is migration inventory or cleanup of dormant policy rows.

Can vendor object names be compared?

Object names and unrecognized service labels are treated as exact text. Two matching labels can compare with each other, but a label cannot be expanded into its member addresses or ports unless you paste those expanded values into the rule rows.

Why does ssh match port 22?

Common service names are normalized to their usual destination ports, including ssh, http, https, rdp, smb, mysql, postgres, and several mail and directory services.

What should I do with a partial conflict?

Compare the earlier and later rules, then split the overlapping source, destination, or port range so the intended exception can be tested directly. Partial conflicts are review prompts, not automatic delete recommendations.

Where is the rule text processed?

The pasted or loaded rule text is parsed in your browser session, and there is no upload step in the checker workflow. Treat firewall exports as sensitive operational data and follow your organization's approved handling rules.

Glossary:

Shadowed rule: A lower rule whose matching traffic is already covered by an earlier rule.
Action shadow: A full shadow where the earlier and later actions differ, such as allow above deny.
Redundant shadow: A full shadow where the earlier and later actions are the same.
Partial conflict: An overlap where the rules intersect on all checked fields, the actions differ, and the earlier rule does not fully contain the later rule.
CIDR: Address notation such as 10.44.0.0/16 that represents an IP network and prefix length.
Opaque value: An object or service label that can only be compared by exact text because its members are not expanded.
First match: The firewall behavior where evaluation stops when traffic matches the first applicable rule.

References:

SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy, National Institute of Standards and Technology, September 2009.
Cisco Secure Firewall ASA Access Control Lists, Cisco, November 7, 2024.
Security Policy Rulebase Best Practices, Palo Alto Networks.
Firewall Policy Advisor for Anomaly Discovery and Rule Editing, Al-Shaer and Hamed, IFIP/IEEE Integrated Network Management, 2003.