Acl Rule Analysis

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
• Merger/acquisition integration — consolidating overlapping rulebases

Prerequisites

• 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:

1. For each rule R at position N, examine all rules at positions 1 through N-1.
2. 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.
3. 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.

[JunOS] show firewall filter <name> counter — per-term counters.

[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:

1. Group rules by action (permit/deny).
2. Within each group, compare pairs for overlapping source, destination, and service criteria.
3. 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).
4. 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:

1. Sort rules by hit count (descending).
2. Compare current position against hit-count-optimal position.
3. Identify rules where reordering would improve performance without changing security posture.
4. Flag any reordering that would change effective policy (a permit moving above a deny or vice versa) — these require explicit approval.