Vendor-agnostic ACL and firewall rule analysis with shadowed rule detection, overly permissive rule identification, unused rule discovery, redundant rule flagging, and rule ordering optimization. Covers ACLs (Cisco/JunOS/EOS) and firewall policies (PAN-OS/FortiGate/CheckPoint).
SKILL.md
ACL and Firewall Rule Analysis
Vendor-agnostic rule analysis for access control lists and firewall policies.
Unlike vendor-specific firewall audit skills that evaluate platform features
(App-ID, Security Profile Groups, zone protection), this skill focuses on
universal rule patterns that apply across all platforms: shadowed rules,
redundant rules, overly permissive rules, and unused rules.
Covers ACL-based platforms (Cisco IOS/IOS-XE/ASA, Juniper JunOS, Arista EOS)
and policy-based firewalls (Palo Alto PAN-OS, Fortinet FortiGate, Check Point).
The analysis algorithms are vendor-agnostic — only the rule retrieval commands
differ by platform.
Commands use inline labels [Cisco], [JunOS], [EOS], [PAN-OS],
[FortiGate], [CheckPoint] where syntax diverges. Unlabeled statements
apply universally. See references/cli-reference.md for full command tables
and references/rule-patterns.md for detection algorithm details.
When to Use
Post-migration rule cleanup after converting from one platform to another
Periodic rulebase hygiene to remove accumulated technical debt
Compliance preparation requiring rule-level justification and minimal privilege
Incident investigation — determining whether a rule permitted malicious traffic
Change validation after rulebase modifications to confirm no shadowed rules
Capacity optimization — reducing rule count to improve lookup performance
Read-only access to the target device via SSH, console, or API
Rulebase with hit counters enabled (most platforms enable by default)
For unused rule detection: hit count data accumulated over an extended period
(30+ days minimum, 90 days recommended for seasonal traffic patterns)
Knowledge of intended security policy — which traffic should be permitted
and which should be denied between network segments
Understanding of implicit deny behavior for the platform (varies — see
Troubleshooting)
Procedure
Follow this analysis flow sequentially. Each step builds on prior findings.
The procedure moves from data collection through pattern detection to
consolidated recommendations.
Step 1: Collect Rulebase
Retrieve the full ACL or firewall policy from the target device.
[Cisco] IOS/IOS-XE:
show ip access-lists
show access-lists
[Cisco] ASA:
show access-list
show running-config access-list
[JunOS]
show configuration firewall family inet filter
show firewall filter
[EOS]
show ip access-lists
show access-lists counters
[PAN-OS]
show running security-policy
[FortiGate]
get firewall policy
[CheckPoint] SmartConsole CLI or Expert mode:
fw stat -l
Record each rule: sequence number/name, match criteria (source, destination,
protocol, port/service), action (permit/deny/drop/reject), and hit count.
Normalize the data into a common format for analysis.
Step 2: Identify Shadowed Rules
A rule is shadowed when a preceding rule matches all traffic that the
shadowed rule would match. The shadowed rule never triggers because the
earlier rule always matches first.
Detection algorithm:
For each rule R at position N, examine all rules at positions 1 through N-1.
If any preceding rule P has match criteria that is a superset of R's
criteria and the same or broader action scope, then R is shadowed by P.
A superset means P's source contains R's source, P's destination contains
R's destination, and P's service/port contains R's service/port.
Critical case: A permit rule shadowing a deny rule means traffic intended
to be blocked is actually permitted. This is a security gap — flag as Critical.
Benign case: A deny rule shadowing another deny rule is a redundancy issue,
not a security gap — flag as Medium.
Verify suspected shadows by checking hit counts: a truly shadowed rule has
zero hits despite the traffic pattern existing in the network.
Step 3: Detect Overly Permissive Rules
Identify rules with excessively broad match criteria that violate least
privilege. Risky patterns by platform:
ACL platforms (Cisco, JunOS, EOS):
permit ip any any — allows all IPv4 traffic, bypasses all filtering
permit ip any <broad-subnet> where subnet is /8 or larger
permit tcp any any eq <high-risk-port> — unrestricted source to
sensitive service (e.g., SSH, RDP, SQL)
Policy platforms (PAN-OS, FortiGate, CheckPoint):
Source any + Destination any + Action allow
Application/service set to any or all
Broad service groups containing dozens of ports
For each overly permissive rule found, check its hit count and traffic logs
to determine actual usage patterns. Many "any/any" rules exist as legacy
migration artifacts that can be narrowed to observed traffic.
Step 4: Find Unused Rules
Unused rules are those with zero hit count over an extended observation
period.
[Cisco] Check hit counts inline with show access-lists output.
[EOS]show access-lists counters — per-entry match counts.
[PAN-OS]show rule-hit-count vsys vsys1 security rules all
[FortiGate]diagnose firewall iprope list — per-policy packet/byte counts.
[CheckPoint] SmartConsole → Policy → hit count column, or cpstat fw -f policy
Caveats for unused rule detection:
Hit counters reset on device reboot — verify uptime before concluding
a rule is unused
Seasonal traffic (quarterly reports, annual processes) may not appear in
30-day windows — extend observation to 90+ days when possible
Backup/failover paths only activate during outages — low hit count does
not mean the rule is unnecessary
Unused deny rules are low-risk findings; unused permit rules waste rulebase
space and may indicate abandoned access that should be revoked
Step 5: Identify Redundant Rules
Redundant rules have overlapping match criteria and the same action. They
increase rulebase complexity without adding security value.
Detection approach:
Group rules by action (permit/deny).
Within each group, compare pairs for overlapping source, destination, and
service criteria.
If rule A's match criteria is a subset of rule B's and both have the same
action, rule A is redundant (B already covers it).
If two rules have identical match criteria and the same action, one is a
direct duplicate.
Merge candidates: rules with adjacent or overlapping source/destination
ranges and the same action can often be consolidated into a single rule with
a summarized address range.
Step 6: Rule Ordering Optimization
Rule ordering affects both security and performance.
Performance optimization: Place highest-hit-count rules near the top.
ACL platforms evaluate rules sequentially — a rule matching 80% of traffic at
position 50 forces 49 unnecessary comparisons per packet.
Security optimization: Place most-specific deny rules before broader
permit rules to ensure explicit blocks take precedence.
Conflict analysis: When a permit rule and a deny rule match the same
traffic, the first-match rule determines the outcome. Identify all
permit/deny conflicts and verify the intended rule wins by position.
Review current ordering:
Sort rules by hit count (descending).
Compare current position against hit-count-optimal position.
Identify rules where reordering would improve performance without
changing security posture.
Flag any reordering that would change effective policy (a permit moving
above a deny or vice versa) — these require explicit approval.
Step 7: Generate Consolidated Recommendations
Compile findings from Steps 2–6 into a prioritized remediation list.
Prioritization order:
Critical: Shadowed deny rules (security gap) and any/any permits
High: Overly permissive rules with active traffic, unused permit rules
For each finding, document: the rule identifier, the finding category, the
specific risk, and the recommended action (remove, narrow, reorder, merge).
Threshold Tables
Rule Risk Severity Classification
Finding
Severity
Rationale
Permit rule shadowing a deny rule
Critical
Traffic intended to be blocked is permitted
permit ip any any / any-any-allow
Critical
No filtering — all traffic passes
Broad subnet permit (source or dest ≥/8)
High
Overly wide scope; likely exceeds intent
Unused permit rule (0 hits, 30+ days)
High
Abandoned access — potential unauthorized path
Permit with any source to sensitive service
High
Unrestricted access to high-risk ports
Redundant rules (same action, overlapping match)
Medium
Complexity without security value
Suboptimal rule ordering (high-hit rule low in list)
Medium
Performance impact on sequential evaluation
Shadowed deny by another deny
Medium
Redundancy, not a security gap
Unused deny rule (0 hits, 30+ days)
Low
Minimal risk; cleanup recommended
Missing rule comments/descriptions
Low
Maintainability concern
Hit Count Staleness Thresholds
Observation Period
Confidence
Action
< 7 days
Very Low
Insufficient data — do not remove rules based on hit count
7–29 days
Low
Flag for review; extend observation period
30–89 days
Moderate
Reasonable basis for unused rule identification
90+ days
High
Strong evidence for rule removal or narrowing
180+ days
Very High
Recommend removal with change control documentation
Decision Trees
Remediation Priority
Found a flagged rule
├── Is the rule overly permissive (any/any)?
│ ├── Yes
│ │ ├── Is it actively used (hit count > 0)?
│ │ │ ├── Yes → Analyze traffic logs to narrow match criteria
│ │ │ │ ├── Can it be narrowed to specific IPs/services?
│ │ │ │ │ ├── Yes → Create replacement rules, test, then remove original
│ │ │ │ │ └── No → Document business justification, add compensating controls
│ │ │ │ └── Is there a Security Profile/IPS covering this rule?
│ │ │ │ ├── Yes → Lower priority, but still narrow when feasible
│ │ │ │ └── No → High priority — no inspection on broad permit
│ │ │ └── No (zero hits) → Schedule removal with change control
│ │ └── Severity: Critical
│ └── No
│ ├── Is the rule shadowed?
│ │ ├── Shadowed deny (by a permit) → Critical — security gap
│ │ ├── Shadowed permit (by another permit) → Medium — remove redundancy
│ │ └── Shadowed deny (by another deny) → Low — remove redundancy
│ ├── Is the rule unused?
│ │ ├── Unused permit → High — revoke abandoned access
│ │ └── Unused deny → Low — cleanup at convenience
│ └── Is the rule redundant?
│ └── Merge with covering rule → Medium
Rule Reordering Safety Check
Proposed rule reorder
├── Does the reorder change which rule matches any traffic flow?
│ ├── Yes → STOP — this is a policy change, not just optimization
│ │ ├── Would a deny move below a permit for the same traffic?
│ │ │ ├── Yes → REJECT — security degradation
│ │ │ └── No → Evaluate as an intentional policy change
│ │ └── Submit for change control review
│ └── No → Safe to reorder for performance
│ ├── Validate with test traffic or policy simulation
│ └── Implement during maintenance window
Report Template
# ACL / Firewall Rule Analysis Report
## Executive Summary
- **Device:** [hostname]
- **Platform:** [Cisco IOS / ASA / JunOS / EOS / PAN-OS / FortiGate / CheckPoint]
- **Rulebase Size:** [total rules]
- **Analysis Date:** [timestamp]
- **Performed By:** [operator/agent]
- **Observation Period for Hit Counts:** [start date] to [end date] ([N] days)
**Summary:** [N] findings across [rules examined] rules. [critical count]
Critical, [high count] High, [medium count] Medium, [low count] Low.
## Shadowed Rules
| Rule # | Rule Name | Shadowed By | Match Overlap | Severity | Action |
|--------|-----------|-------------|---------------|----------|--------|
| [seq] | [name] | Rule [seq] | [description] | [sev] | Remove / Reorder |
## Overly Permissive Rules
| Rule # | Rule Name | Source | Destination | Service | Hit Count | Severity |
|--------|-----------|--------|-------------|---------|-----------|----------|
| [seq] | [name] | [src] | [dst] | [svc] | [count] | [sev] |
**Recommendation:** [Narrow to observed traffic / Add compensating controls]
## Unused Rules
| Rule # | Rule Name | Action | Last Hit | Days Observed | Severity |
|--------|-----------|--------|----------|---------------|----------|
| [seq] | [name] | [act] | [date] | [days] | [sev] |
**Recommendation:** [Remove with change control / Extend observation period]
## Redundant Rules
| Rule # | Rule Name | Redundant With | Overlap Type | Recommendation |
|--------|-----------|----------------|--------------|----------------|
| [seq] | [name] | Rule [seq] | [type] | Merge / Remove |
## Ordering Recommendations
| Current Position | Rule # | Hit Count | Optimal Position | Impact |
|-----------------|--------|-----------|------------------|--------|
| [pos] | [seq] | [count] | [new pos] | [desc] |
## Prioritized Remediation Plan
1. [Critical] [Finding description] — [Specific action]
2. [High] [Finding description] — [Specific action]
3. [Medium] [Finding description] — [Specific action]
## Next Review
- **Critical findings present:** Re-audit in 30 days after remediation
- **High findings only:** Re-audit in 90 days
- **Medium/Low only:** Re-audit in 180 days
Troubleshooting
Hit Counters Reset After Reboot
Most platforms reset ACL/policy hit counters on reboot. Before concluding
a rule is unused, verify device uptime:
[Cisco]show version | include uptime,
[JunOS]show system uptime,
[EOS]show uptime,
[PAN-OS]show system info | match uptime,
[FortiGate]get system performance status,
[CheckPoint]cpstat os -f ifconfig.
If uptime is less than the desired observation period, hit count data is
incomplete.
ACL vs Firewall Policy Semantic Differences
ACL-based platforms (Cisco IOS, EOS) evaluate rules top-to-bottom with
first-match semantics. Firewall policy platforms (PAN-OS, FortiGate,
CheckPoint) also use first-match but have additional dimensions (zones,
applications, user identity) that affect matching. Shadowed rule detection
must account for all match dimensions on policy platforms, not just
source/destination/port.
Implicit Deny Handling Varies by Platform
[Cisco] ACLs have an implicit deny ip any any at the end (not shown
in the ACL output). [JunOS] Firewall filters have an implicit discard
at the end of each term list. [EOS] Follows Cisco convention with
implicit deny. [PAN-OS] Has configurable interzone-default and
intrazone-default rules (deny and allow respectively). [FortiGate]
Implicit deny at end of policy list. [CheckPoint] Implicit drop rule
at end of policy (configurable in SmartConsole).
Account for implicit deny when analyzing rule coverage — the absence of an
explicit deny at the bottom is intentional on most platforms.
Large Rulebases (500+ Rules)
Manual analysis of large rulebases is impractical. Export the rulebase
programmatically for automated analysis:
[Cisco] Parse show access-lists output.
[PAN-OS] Use XML API to export the full policy as structured data.
[FortiGate] Use REST API (/api/v2/cmdb/firewall/policy).
[CheckPoint] Use Management API (mgmt_cli show access-rulebase).
Prioritize analysis by hit count — start with the highest-traffic rules
and work down.
False Positives in Shadowed Rule Detection
Object groups, address groups, and nested service groups can create false
positive shadow detections. When rule A uses an address group and rule B
uses individual addresses that are members of that group, automated tools
may report B as shadowed. Expand all groups to their member objects before
running shadow comparisons.
