gabrielmoreira Firewall Rule Analyzer
MCP Server
- Repository: AutomateIP/fwrule-mcp
- Transport: stdio (Python via
uv run fwrule-mcp) - Install:
git clone+uv sync(orpip install -e .) - Requires: No environment variables — standalone analysis engine
- Dependencies:
fastmcp>=2.0,pydantic>=2.0, Python 3.11+
Available Tools (3)
| Tool | What It Does |
|---|---|
analyze_firewall_rule_overlap |
Compare a candidate rule against an existing ruleset using 6-dimensional set intersection (zones, addresses, ports, protocols, actions, applications). Detects overlaps, shadowing, conflicts, and duplicates. Supports two input modes: vendor-native config via built-in parsers, or pre-normalized JSON. |
parse_policy |
Convert vendor-native firewall configurations into a standardized JSON schema. Enables inspection of parser output — rule counts, object resolution, address expansion — before running overlap analysis. |
list_supported_vendors |
Enumerate all supported firewall vendors, their aliases, configuration formats, and explain how to use normalized JSON input to bypass vendor-specific parsers. |
Supported Vendors (10)
| Vendor | Config Format | Versions | Identifiers |
|---|---|---|---|
| Palo Alto PAN-OS | XML export | 9.x–11.x | panos, paloalto, panorama |
| Cisco ASA | show running-config | 9.x+ | asa, cisco-asa |
| Cisco FTD | FMC JSON | 6.x–7.x | ftd, firepower, fmc |
| Cisco IOS/IOS-XE | show running-config | 12.x–17.x | ios, iosxe, cisco-ios |
| Cisco IOS-XR | show running-config | 6.x+ | iosxr, ios-xr, xr |
| Check Point | JSON rulebase | R80.x–R82.x | checkpoint, cp, check-point |
| Juniper SRX | display set | 19.x+ | juniper, srx |
| Juniper Junos | display set | 18.x+ | junos, mx, ptx, qfx |
| Nokia SR OS | MD-CLI format | 20.x+ | sros, nokia, sr-os |
| Fortinet FortiOS | Full backup config | 5.x–7.x | fortios, fortigate, fortinet, forti, fgt, fmg |
⚠️ FortiOS parser contributed by SIA/NetClaw (Airowire Networks). PR open at AutomateIP/fwrule-mcp#1. Install from the fork until merged upstream:
pip install git+https://github.com/akshaysiddaram/fwrule-mcp.git
Key Concepts
| Concept | What It Means |
|---|---|
| Overlap | Candidate rule matches traffic already handled by existing rules |
| Shadowing | Candidate rule is fully covered by a higher-priority existing rule — it will never match |
| Conflict | Rules match the same traffic but have different actions (allow vs deny) |
| Duplication | Candidate rule is functionally identical to an existing rule |
| 6-Dimensional Analysis | Comparison across source/dest zones, source/dest addresses, services/ports, protocols, actions, and applications |
| Normalized JSON | Vendor-agnostic rule schema with standardized fields (id, position, enabled, action, zones, addresses, services, applications) |
Two Input Modes
Mode 1: Vendor-Native Config
Pass raw vendor configuration text and let the built-in parsers normalize it:
vendor: Vendor identifier (e.g.,panos,asa,ftd,ios,checkpoint,srx,junos,nokia,fortios)ruleset_payload: Complete firewall config in vendor formatcandidate_rule_payload: Single rule in vendor formatos_version: Optional version hint for parser selectioncontext_objects: Supplemental object definitions as JSON
Mode 2: Pre-Normalized JSON
Bypass parsers when structured data is already available:
existing_rules: JSON array of normalized rule objectscandidate_rule: Single normalized JSON rule object
Workflow: Pre-Change Rule Validation
When adding a new firewall rule to a policy:
- Parse existing policy:
parse_policywith vendor config — normalize to JSON, verify rule count and object resolution - Analyze candidate:
analyze_firewall_rule_overlap— check the proposed rule against the existing ruleset - Review findings: Examine overlap type (shadow, conflict, duplicate, partial overlap), severity, and affected dimensions
- Decision: Approve, modify, or reject the candidate rule based on findings
- Report: Formatted analysis with vendor, policy, candidate rule, and overlap results
Workflow: Cross-Vendor Policy Audit
When auditing firewall rules across multiple platforms:
- Enumerate vendors:
list_supported_vendors— confirm supported platforms - Parse each policy:
parse_policyfor each vendor config — normalize all rules - Cross-analyze: For each rule in vendor A, use
analyze_firewall_rule_overlapagainst vendor B's normalized rules - Identify: Cross-platform conflicts, redundant rules, shadowed entries
- Report: Multi-vendor rule consistency analysis
Workflow: Ruleset Hygiene Audit
When cleaning up an existing firewall policy:
- Parse policy:
parse_policy— normalize the full ruleset - For each rule:
analyze_firewall_rule_overlap— check the rule against all others in the same policy - Flag: Shadowed rules (dead rules that never match), duplicates, and internal conflicts
- Report: Cleanup recommendations with rule positions and overlap details
Integration with Other Skills
| Skill | How They Work Together |
|---|---|
fmc-firewall-ops |
FMC policy search + fwrule overlap analysis on retrieved rules |
paloalto-panorama |
Panorama policy export + fwrule cross-policy analysis |
pyats-security |
Device ACL retrieval via pyATS + fwrule overlap detection |
pyats-asa-firewall |
ASA config retrieval + fwrule ASA parser for rule normalization |
fortimanager-ops |
FortiManager policy export + fwrule FortiOS parser for cross-VDOM analysis |
servicenow-change-workflow |
ServiceNow CR gating + fwrule validation before rule deployment |
github-ops |
Commit firewall rule change analysis results to Git |
gait-session-tracking |
Audit trail for all firewall rule analysis operations |
Important Rules
- Read-only analysis — all 3 tools are pure analysis; no firewall modifications
- No credentials required — works entirely on config text/JSON input, no API connections to firewalls
- Vendor parsers are best-effort — use Mode 2 (normalized JSON) when parsers produce unexpected results
- Record in GAIT — log all firewall rule analysis for compliance audit trail