Firewall rulebases grow until nobody remembers what half the entries do — and the audit nobody wants to run is the one that finds the holes. AI changes the math. Here are five prompts that turn Claude into a tireless firewall reviewer, plus the privacy guardrails to keep you safe.
$ claude "audit this ACL — find shadowed and overly permissive rules" ip access-list extended OUTSIDE_IN 10 permit tcp any any eq 443 20 permit tcp 10.0.0.0 0.255.255.255 any eq 443 ← [SHADOW] never matches 30 permit ip any any ← [PERMISSIVE] effectively no firewall 40 deny tcp any any eq 23 ← [DEAD CODE] line 30 already permitted [!] 1 shadowed rule, 1 dead-code rule, 1 catch-all permit [→] Recommend reordering or removing lines 20, 30, 40
To audit firewall rules with Claude, export your rulebase, replace real public IPs with RFC 5737 placeholders (198.51.100.x), strip embedded secrets, then paste the sanitized config with a prompt asking Claude to find shadowed rules, overly permissive entries, and dead code. Claude reads a 400-line ACL in seconds and catches issues — like a permit ip any any buried mid-rulebase — that take humans hours to find manually. This post has five paste-ready prompts, each targeting a specific class of firewall problem.
Don’t paste production firewall configs into any AI without thinking about it. Even with a paid plan, even with privacy guarantees, treat the export like you’d treat any other place sensitive data shouldn’t go.
The two minimum sanitization steps:
# Replace your real public IP ranges with placeholders
sed -i 's/203\.0\.113\.\([0-9]*\)/198.51.100.\1/g' export.txt
# Strip any embedded secrets (SNMP communities, RADIUS keys, IKE PSKs)
sed -i 's/snmp-server community [^ ]*/snmp-server community REDACTED/g' export.txt
sed -i 's/key 7 [^ ]*/key 7 REDACTED/g' export.txtWhat’s safe enough to paste:
What to redact every time:
For most audits, the sanitized version is just as auditable as the real one — Claude doesn’t need to know whose IP it is to spot that rule 30 is shadowing rule 80.
A shadowed rule is one that never matches because an earlier rule already handles its traffic. They clutter the rulebase and trick you into thinking a policy is in effect when it isn’t.
Prompt:
You are a senior network security engineer doing a firewall audit. Below is an extended ACL from a Cisco IOS device. Identify any rules that are shadowed (never match because an earlier rule covers their traffic) or redundant (multiple rules doing the same thing). For each finding, give me the rule number, what shadows it, and a one-line recommendation.
[paste sanitized ACL here]
Sample finding:
Rule 50: permit tcp 10.0.5.0/24 any eq 443
→ SHADOWED by rule 20 (permit tcp any any eq 443)
→ Recommendation: remove rule 50, or reorder if 50 was intended to be more specific
Rule 110: permit udp 192.168.1.0/24 any eq 53
→ REDUNDANT with rule 90 (permit udp 192.168.0.0/16 any eq 53)
→ Recommendation: remove rule 110 unless intentional documentationTwo cleanups in 30 seconds. A human doing this manually checks every rule against every preceding rule — O(n²) attention.
permit ip any any is the obvious one, but the dangerous version is subtler — rules that look specific but effectively allow far more than intended.
Prompt:
Audit the following firewall rules for overly permissive entries. Flag any rule that:
- Uses
anyas source ANDanyas destination- Permits a wide port range (more than 100 ports) outbound or inbound
- Permits a /16 or larger network without justification
- Permits dangerous services (RDP/3389, SMB/445, SSH/22, telnet/23) from untrusted sources
- Has a destination of
0.0.0.0/0from internal sources without proxy intermediationFor each finding, return: rule number, what’s permissive about it, the realistic exposure if exploited, and a tighter alternative.
[paste sanitized rules here]
Why this prompt works: specificity. “Find permissive rules” gets you garbage. “Find rules with these five specific patterns” gets you a real audit, because Claude has explicit criteria to evaluate against.
Sample finding:
Rule 80: permit tcp any 10.0.0.0/8 eq 3389
→ Permissive: RDP open to entire internal /8 from any source
→ Exposure: any compromised internal host (or VPN user) can pivot to every
Windows machine in the org
→ Tighter: permit tcp <jump-host> 10.0.0.0/8 eq 3389
+ allow specific admin source IPs onlyFirewall rules are evaluated top-down, first-match-wins. A deny placed below a permit for the same traffic is dead code. So is a specific permit placed below a broad permit.
Prompt:
I’m going to paste a firewall rulebase. Walk through it in evaluation order (top to bottom). For each rule, ask “given the rules above this one, is this rule reachable, and does it change behavior?” Return a list of:
- Rules that are unreachable (will never be evaluated because earlier rules already match)
- Rules whose order should be reversed for security reasons (e.g., a specific deny placed below a broader permit that defeats it)
- The recommended new ordering
[paste sanitized rulebase here]
This one finds the bugs that look fine line-by-line but break when you read them as a flow.
Half of every old firewall rulebase is “what does this rule even do?” Claude can read the rule, infer the intent, and produce inline comments — which is the version your future self will thank you for.
Prompt:
For each rule below, generate a single-line comment in the firewall’s native syntax (
remarkfor Cisco, descriptions for Palo Alto, etc.) that explains:
- The intent in plain English
- The likely business reason (what the rule enables — e.g., “users → M365”, “DMZ web → DB tier”)
- Any caveats (overly broad, legacy, etc.) that should prompt review
Output in the original rule order, with the comment placed immediately above each rule.
[paste sanitized rules here]
Sample output:
remark Allow internal users to reach M365 (HTTPS to Microsoft endpoints)
permit tcp 10.0.0.0/8 13.107.0.0/16 eq 443
remark Legacy: review — guest VLAN to printer subnet, may pre-date BYOD policy
permit tcp 192.168.20.0/24 192.168.50.0/24 eq 9100The “review” tags are gold. They give you a punch list of rules to ask owners about, and most of the time the answer is “remove it.”
Migrating from one platform to another is where ACL audits suddenly become unavoidable. Claude is unusually good at vendor-to-vendor syntax translation, and it’ll preserve the policy intent rather than just doing a literal command swap.
Prompt:
Convert the following Cisco IOS extended ACL into an equivalent Palo Alto Networks security policy. Preserve the policy intent, not just the syntax. Use named address objects and service objects rather than inline literals — propose object names that reflect the rule’s purpose. For each rule, output:
- The proposed object definitions (address, service)
- The security policy entry referencing those objects
- A note flagging any Cisco-specific behavior (implicit deny, established, log-input) that maps differently in Palo Alto
[paste sanitized Cisco ACL here]
This gets you a policy you can review and refine, not a literal translation that papers over the platform differences. Same prompt structure works for Fortinet, Check Point, or pfSense — just swap the target platform.
A few things to be honest about:
show access-list, Palo Alto rule usage report) before you delete anything.A few practical rules that have aged well:
Once these prompts are in your toolbox, the audit doesn’t have to be a two-week project anymore. A workable cadence:
Quarterly:
├─ Export rulebase, sanitize, run prompts 1–3
├─ Pull hit counters, cross-reference unused rules
├─ Email rule owners for any "review" tagged rules
└─ Implement removals/tightenings via change control
Annually:
├─ Run prompt 4 to refresh inline documentation
└─ Consider a vendor translation (prompt 5) as a forcing function
for rebuilding the rulebase cleanlyThe goal isn’t to let AI run your firewall — it’s to take the parts of the audit a computer should do off your plate, so the human time goes to the calls that actually need judgment. That’s the entire premise of every useful AI workflow, and firewall audits are an unusually good fit.
Is it safe to paste firewall configs into Claude?
Not without sanitization first. Replace your real public IP ranges with RFC 5737 documentation addresses (198.51.100.x, 203.0.113.x), strip SNMP community strings, RADIUS keys, IKE pre-shared keys, and any hostnames that identify your internal naming scheme. The sed one-liners in Step 0 of this guide do this in under a minute.
What is a shadowed firewall rule?
A shadowed rule is one that can never match because a broader rule above it already covers the same traffic. For example, permit ip any any on line 10 shadows any specific rule below it — those rules are dead code. They don’t cause harm, but they create confusion and give a false sense of security.
How do I export my Cisco ACL for Claude review?
Run show run | section ip access-list or show access-lists from privileged EXEC mode. Copy the output, run the sanitization commands from Step 0, and paste the result into Claude with your audit prompt.
Can Claude audit pfSense, FortiGate, or Palo Alto configs? Yes. Claude handles pfSense XML exports, FortiGate config files, Palo Alto security policies, iptables rules, and most vendor-specific ACL formats. Specify the platform and version in your prompt so Claude applies the correct syntax expectations.
How accurate is AI at finding firewall problems? Claude reliably finds structural issues: shadowed rules, implicit deny gaps, overly broad permit statements, and dead code. It’s less reliable on semantic issues — rules that are syntactically correct but wrong for your specific environment. Always cross-reference AI findings with your hit counters and application owner knowledge before making changes.
Q: Can AI audit my firewall rules?
A: Yes. Paste your firewall ruleset into Claude with a prompt like "Review these rules for shadowed rules, any/any permits, and missing egress filtering." Claude identifies shadowed rules (rules that are never matched because a broader rule above already captures the traffic), overly permissive permits, and common rule ordering issues.
Q: What firewall rule mistakes can AI detect?
A: AI models reliably detect: shadowed rules (a rule that is never reached because a broader rule above it matches first), any/any permit rules, missing egress filtering, inbound rules allowing unnecessary services, and rule ordering problems. They are less reliable for stateful inspection logic and vendor-specific behavior edge cases.
Q: How do I export my firewall rules to audit with Claude?
A: On pfSense: export config.xml from Diagnostics > Backup & Restore. On Cisco ASA: run `show run access-list` from the CLI. On Palo Alto: export from Device > Setup > Operations > Export named configuration snapshot. Paste the relevant sections into Claude with a clear audit prompt. Redact sensitive internal hostnames or IP ranges before pasting if needed.