fwrule-analyzer

name fwrule-analyzer description Multi-vendor firewall rule analysis — overlap detection, shadowing, conflict identification, duplication checking across PAN-OS, ASA, FTD, IOS/IOS-XE, IOS-XR, Check Point, SRX, Junos, Nokia SR OS, and Fortinet FortiOS/FortiGate. Use when validating firewall rule changes, auditing rulesets for conflicts, or normalizing vendor configs to a common schema. version 1.1.0 license Apache-2.0 tags ["firewall","rule-analysis","overlap","shadowing","conflict","multi-vendor","security","fortios","fortigate"] metadata {"openclaw":{"requires":{"bins":"[Truncated]"}}} Firewall Rule Analyzer MCP Server Repository : AutomateIP/fwrule-mcp Transport : stdio (Python via uv run fwrule-mcp ) Install : git clone + uv sync (or pip 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 format candidate_rule_payload : Single rule in vendor format os_version : Optional version hint for parser selection context_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 objects candidate_rule : Single normalized JSON rule object Workflow: Pre-Change Rule Validation When adding a new firewall rule to a policy: Parse existing policy : parse_policy with 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_policy for each vendor config — normalize all rules Cross-analyze : For each rule in vendor A, use analyze_firewall_rule_overlap against 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