FWRule MCP——防火墙规则分析器
一个MCP服务器，用于分析跨多供应商防火墙策略的防火墙规则重叠、重复、阴影和冲突。
支持的供应商
| 供应商 | 格式 | 版本 |
|---|---|---|
| Palo Alto PAN-OS/全景 | XML配置导出 | 9.x-11.x |
| 思科ASA | show running-config 文本 | 9.x+ |
| 思科FTD | 从FMC导出JSON | 6.x-7.x |
| 思科IOS/IOS-XE | show running-config 文本 | 12.x-17.x |
| 思科IOS-XR | show running-config 文本 | 6.x+ |
| 检查点 | JSON show-access-rulebase | R80.x-R82.x |
| Juniper SRX | display set 格式 | 19.x+ |
| Juniper Junos（MX/PTX/QFX） | display set 格式 | 18.x+ |
| 诺基亚SR操作系统 | MD-CLI信息/平面格式 | 20.x+ |
| Fortinet FortiOS/FortiGate | show full-configuration 文本 | 6.x-7.x |
快速开始
# Install
uv sync
# Run tests
uv run pytest
# Start the MCP server
uv run fwrule-mcpMCP工具
analyze_firewall_rule_overlap
分析候选防火墙规则是否与现有规则集重叠。支持两种输入模式。
模式1——供应商本地配置 （内置解析器）：
vendor--供应商标识符(panos,asa,ftd,ios,iosxr,checkpoint,juniper,junos,sros,fortios)ruleset_payload--以供应商原生格式完成防火墙配置candidate_rule_payload--供应商原生格式的单一候选规则os_version--可选操作系统版本字符串context_objects--可选JSON，带有补充对象定义
模式2——预规范化JSON （调用者提取结构化规则）：
existing_rules--JSON字符串：规范化规则对象数组candidate_rule--JSON字符串：单个规范化规则对象
共享：
candidate_position--可选的基于1的预期插入位置
规范化规则架构：
{
"id": "rule-1",
"position": 1,
"enabled": true,
"action": "permit",
"source_zones": ["trust"],
"destination_zones": ["untrust"],
"source_addresses": ["10.0.0.0/24", "192.168.1.0/24"],
"destination_addresses": ["any"],
"services": [{"protocol": "tcp", "ports": "443"}],
"applications": ["any"]
}检测：
- 完全重复
- 影子规则（候选人永远不会解雇）
- 行动冲突（交通重叠、行动相反）
- 部分重叠
- 超集/子集关系
parse_policy
解析供应商本地防火墙配置并返回规范化的JSON规则。在运行重叠分析之前，使用此功能检查内置解析器提取的内容。
vendor--供应商标识符ruleset_payload--完成防火墙配置os_version--可选操作系统版本字符串context_objects--可选JSON，带有补充对象定义
返回被接受的相同规范化架构 analyze_firewall_rule_overlap.
batch_analyze_overlap
在一次调用中，根据同一现有规则集分析多个候选规则。比打电话更有效率 analyze_firewall_rule_overlap 多次——现有规则被解析一次，并为每个候选者重用。
existing_rules--规范化规则对象数组（来自parse_policy输出）candidate_rules--要分析的候选规则对象数组
退货 {"success": true, "results": [{"candidate_id": "...", ...analysis result...}, ...]}.
list_supported_vendors
列出所有支持的防火墙供应商及其格式要求。
测试
# Full test suite
uv run pytest
# Mock payload tests (vendor parsers)
uv run pytest tests/test_mock_payloads.py -v
# Normalized input tests
uv run pytest tests/test_normalized_input.py -v
# Testing agent with formatted report
uv run python tests/test_agent.py
# Single vendor / scenario
uv run python tests/test_agent.py --vendor panos --scenario conflict --verbose建筑
MCP Client Request
│
├── Mode 1: vendor + raw config
│ │
│ v
│ Vendor Parser (plugin registry)
│ [PAN-OS │ ASA │ FTD │ IOS │ IOS-XR │ CP │ SRX │ Junos │ SR OS │ FortiOS]
│ │
│ v
│ Normalization Layer (object resolution, address expansion)
│ │
│ └──────────────┐
│ v
├── Mode 2: normalized JSON ──> Schema Validation
│ │
│ v
└──────────────────> Analysis Engine (6-dimension set intersection)
│
v
Result Generator
│
v
Compact JSON Response许可证
Apache 2.0
______________________________________________________________________
附录：为什么有两种输入模式？
此MCP服务器专为大型防火墙规则集的自动合规性检查而设计，在这些规则集中，误报和漏报会产生真正的安全后果。该架构平衡了两个相互竞争的问题：
内置解析器的情况（模式1）
防火墙配置包含 命名对象图 --规则可以引用 PROD-SERVERS，这是一个包含以下内容的地址组 WEB-TIER 和 DB-TIER，每个引用CIDR。正确解决这些问题需要具有循环检测和保守回退的递归扩展（不可求解的引用被视为 any 以避免假阴性）。内置解析器以确定性的方式执行此操作。通过推理实现这一点的LLM偶尔会错过嵌套的组成员或产生幻觉的解决方案——这对安全策略决策很重要。
归一化输入的情况（模式2）
供应商解析器是脆弱性的来源。每个解析器包含约400行特定于格式的代码，当供应商操作系统版本更改输出格式时，这些代码可能会中断。我们已经看到PAN-OS解析器中的错误（包装配置中的XML元素选择错误）。当解析器的格式错误时，分析引擎会产生不正确的结果，调用者无法知道。
混合解决方案
模式2（标准化JSON）在保持正确性的同时解决了脆弱性问题：
- 当调用者已经拥有结构化数据时 （例如，从REST API，或者当AI代理可以可靠地提取字段时），它完全绕过脆弱的解析器，并将解析的地址直接发送到分析引擎。
- 当调用者有原始的CLI/config输出时，模式1的解析器处理复杂的提取和对象解析。
parse_policy弥合差距 --调用者可以检查解析器提取的内容，验证规则计数和地址解析，并决定是信任解析器输出还是手动重新提取。
分析引擎——执行CIDR算法、端口范围交集和多维集比较的部分——是不可替代的价值。它与供应商无关，具有确定性，并且经过充分测试。解析器是一个便利层；规范化的模式是真正的API表面。