--- name: leoyeai/acl-rule-analysis source: https://app.decimal.ai/s/leoyeai-acl-rule-analysis@1/SKILL.md source_sha256: e2026bcb6049 --- # 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 ` where subnet is /8 or larger - `permit tcp any any eq ` — 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 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 | 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 ```markdown # 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.