---
name: firewall-rule-deduplicator
description: Analyse a firewall ruleset to find shadowed, redundant, overly-broad, and unused rules. Outputs a prioritised cleanup backlog with specific remediation per rule.
version: 1.0.0
author: VantagePoint Networks
audience: Network Engineers, Security Engineers, Firewall Administrators, Auditors
output_format: Markdown report — duplicate groups, shadowed rules, broad rules, unused-candidate rules, cleanup backlog.
license: MIT
---

# Firewall Rule Deduplicator

A Claude Code skill that finds the mess in your firewall ruleset and tells you exactly how to clean it up. Works with ruleset text exports from Cisco ASA/FTD, Palo Alto, Fortinet, Check Point, Juniper SRX, pfSense/OPNsense, AWS Security Groups, Azure NSGs, GCP firewall rules, and iptables/nftables.

## How to use this skill

1. Download this `SKILL.md` file.
2. Place it in `~/.claude/commands/` (macOS/Linux) or `%USERPROFILE%\.claude\commands\` (Windows).
3. In Claude Code, run `/firewall-rule-deduplicator`. Paste your rule export (or attach as a file). Optionally include hit-count data.

## When to use this

- An auditor has flagged "excessive firewall rules" and you need a defensible remediation plan.
- A performance review of a large ruleset shows CPU spikes; you suspect rule-base bloat.
- You're migrating between platforms (see also `/migration-planner`) and want to trim before you translate.
- You're prepping for a pen test and want to reduce attack surface.
- Quarterly ruleset review is due and you want a structured output rather than staring at a 4000-line config.

## What you'll get

A single Markdown report with these sections:

1. **Summary stats** — total rules, unique sources, unique destinations, unique services, any/any rules count.
2. **Shadowed rules** — rules that can never match because an earlier rule covers their traffic.
3. **Redundant rules** — rules that duplicate the policy effect of another rule.
4. **Overly-broad rules** — rules with `any` in source, destination, service, or service with obvious risk.
5. **Aliasable rules** — clusters of similar rules that should become one rule with an alias/group.
6. **Unused candidates** — rules whose hit count is zero (if hit data provided) or whose objects no longer exist.
7. **Comment / description hygiene** — rules missing descriptions, ticket references, or expiry.
8. **Cleanup backlog** — sorted by risk + effort, ready to drop into Jira.

## Clarifying questions I will ask you

Before analysing:

1. **Platform** — paste the first 5 lines or tell me vendor + version (so I parse correctly).
2. **Full ruleset or a subset?** Security policy / NAT / threat-prevention — paste the layer you want reviewed.
3. **Hit count data** — do you have hit counts per rule? If yes, paste alongside.
4. **Object definitions** — if your rules use named objects/groups, include the object export so I can resolve them.
5. **Change freeze** — are there rules I should not recommend removing (e.g., compliance-pinned)?
6. **Expected output** — cleanup backlog, audit-response letter, or both?

## How I analyse

For each rule:
1. **Normalize** source, destination, services to canonical form (IPs, CIDR, ports, protocols).
2. **Expand groups** where definitions are supplied.
3. **Build an ordered decision tree** — for each rule, what earlier rules either fully or partially cover its traffic?

Shadow detection:
- Rule B is shadowed by rule A if `A.source ⊇ B.source AND A.destination ⊇ B.destination AND A.services ⊇ B.services AND A.action != B.action OR A.action == B.action`.
- If `A.action == B.action`, B is redundant.
- If `A.action != B.action` (e.g., A denies, B allows), B is shadowed and **never fires** — usually indicates misconfiguration.

Broad-rule detection:
- `service any` on any allow rule → flag.
- `source any` on allow + `destination any` → immediate flag; this is a "permit any any" in disguise.
- `source any` with specific destination is usually fine (inbound-service pattern).

Aliasable rules:
- 3+ allow rules with same services and destinations but different sources → consolidate into a source group.
- 3+ allow rules with same source/services but different destinations → consolidate into a destination group.

## Example output

```markdown
# Firewall Rule Review — fw-core-01 (Cisco ASA 9.20)

## Summary
- 847 rules analysed
- 23 shadowed (never match)
- 61 redundant (duplicate effect)
- 12 overly-broad allow rules (service any / source any)
- 8 groupable clusters
- 34 rules without a description
- 156 rules with zero hits in the last 90 days

## Shadowed rules (HIGH priority — confusing + risky)

### Rule 214 — shadowed by rule 12
- **Rule 12:** `permit tcp any any eq 443`
- **Rule 214:** `permit tcp 10.20.0.0/24 10.30.0.0/24 eq 443`  ← can never match (rule 12 always fires)
- **Recommendation:** remove rule 214; if the specific log trail is wanted, move it above rule 12 with a narrower description.

[... per rule ...]

## Overly-broad rules (HIGH priority — audit risk)

### Rule 72
- `permit ip 10.10.0.0/16 any`
- **Risk:** internal subnet has unconstrained egress.
- **Recommendation:** scope destination to required services (e.g., 80/443 + DNS) and any known internal dependencies. See `/siem-rule-writer` for detection-of-new-egress alert.

[...]

## Groupable clusters (MEDIUM priority — maintainability)

### Cluster A — 6 rules (lines 120–125), differ only by source
All permit tcp to 10.30.0.10 port 3389. Sources:
`10.10.0.5, 10.10.0.6, 10.10.0.7, 10.10.0.12, 10.10.0.13, 10.10.0.55`
**Recommendation:** create object-group `ADMIN_RDP_SOURCES` and collapse to 1 rule.

[...]

## Unused candidates (LOW-MEDIUM — cleanup)
156 rules with 0 hits in last 90 days. Sorted by last-hit where available:
[...]

## Cleanup backlog

| Priority | Action | Rules | Effort |
|---|---|---|---|
| P1 | Remove shadowed rules | 214, 302, 445, 609, ... | 1 hour |
| P1 | Scope broad-egress rules 72, 91, 203 | 3 | 2 hours (needs app discovery) |
| P2 | Consolidate cluster A, B, C into object groups | 6+5+4 | 1 hour |
| P3 | Re-test and remove unused candidates | 156 | Ongoing — stage over 3 change windows |

Total shrink potential: **~25% rule reduction** without functional change.
```

## What I won't do

- I won't blindly recommend deleting rules with zero hits. Low traffic doesn't mean unused. I'll flag as candidates with a rollback plan (disable + monitor for 30 days before delete).
- I won't rewrite your whole ruleset — you get a backlog, you make the decisions.
- I won't guess at object definitions; if they're not provided I'll flag what I couldn't resolve.
- I won't claim to find every issue with certainty on exports that are ambiguous — I'll flag ambiguities.

## Reference

- NIST SP 800-41 Rev 1 — Guidelines on Firewalls and Firewall Policy
- NSA Firewall Best Practice
- Palo Alto Networks + Cisco documentation on rule optimisation
- [Firewall Analyzer patterns](https://owasp.org/www-community/controls/Firewall_Analysis) (OWASP)

## Attribution

Built by **Hak** at **VantagePoint Networks**. MIT licensed.