acl-rule-analysis

Files (4)

• SKILL.md
• _meta.json
• cli-reference.md · references/
• rule-patterns.md · references/

SKILL.md (first lines)

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

From LeoYeAI/openclaw-master-skills, Apache-2.0.

More from LeoYeAI/openclaw-master-skills