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.

Step 7: Generate Consolidated Recommendations

Compile findings from Steps 2–6 into a prioritized remediation list.

Prioritization order:

1. Critical: Shadowed deny rules (security gap) and any/any permits
2. High: Overly permissive rules with active traffic, unused permit rules
3. Medium: Redundant rules, suboptimal ordering, unused deny rules
4. Low: Cosmetic issues (naming, comments, organization)

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

Hit Count Staleness Thresholds

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.