A
AIops-tools/Firewall-AIops
Governed AI-ops for OPNsense + pfSense firewalls — gateway/rule/traffic RCA, guarded rule/alias writes, with audit/budget/undo (preview)
SECURITY.md ✓
在 GitHub 查看 ↗链接已于 2026-11-12 核查 · HTTP 200 · 打开的是厂商自己的官网
安装与配置
- 复制上面的命令
- 粘成
claude_desktop_config.json里mcpServers的一项（本地服务器用 command + args，示例见 客户端接法） - 重启客户端
客户端配置（取自该仓库的安装命令）
{
"mcpServers": {
"aiops-tools-firewall-aiops": {
"command": "uv",
"args": ["tool", "install", "firewall-aiops"]
}
}
}解析自我们于 2026-10-26 抓取的该仓库 README；我们未执行过。
command/args 来自仓库写明的安装命令；不确定时请以该项目 README 为准。
VS Code（.vscode/mcp.json —— 键名是 servers）
{
"servers": {
"aiops-tools-firewall-aiops": {
"command": "uv",
"args": ["tool", "install", "firewall-aiops"]
}
}
}VS Code 顶层键是 <code>servers</code>，其余与上面那份相同。
Claude Code（命令行）
claude mcp add --transport stdio aiops-tools-firewall-aiops -- uv tool install firewall-aiops
Claude Code 不收 JSON 文件，用这条命令直接加。
配置项的键名以你的客户端为准：客户端与 CLI
- ★ 数取值
- 2 ★ · AIops-tools/Firewall-AIops · 取自 GitHub 搜索 API · （2026-11-13 20:00:50 核对）
- 来源明细
- 收录自 punkpeye/awesome-mcp-servers 榜单（我们从中收集的条目之一） · 条目类型：MCP 服务
- 收录与活跃
- 收录于 2026-10-23 · 最近见到 2026-11-14 · 共见到 26 次 · 被 23 个来源列出
- 评分构成
- 综合分 2,300 · 2 ★ · 23 个来源 · mcp
- 安装
uv tool install firewall-aiops
常见问题（答案都来自我们的记录）
怎么安装？
该仓库给出的安装命令是
uv tool install firewall-aiops。我们的记录里它是仓库自己提供的；不保证在你的客户端上直接可用。它适合谁 / 用来做什么？
我们把它归在这些标签下: MCP 服务。标签来自条目自身，不是我们强加的分类。
谁维护它、还在更新吗？
仓库
AIops-tools/Firewall-AIops；我们收录于 2026-10-23；最近见到 2026-11-14。这里没有"官方认证"或"质量评级"——我们只记录来源与时间。# Firewall AIops
以下摘录自该仓库的 README（片段） · 在 GitHub 读完整 README →
Governed, audited AI-ops for OPNsense and pfSense firewalls — for AI agents (via MCP) and humans (via CLI).
> Disclaimer: Community-maintained open-source project. Not affiliated with, endorsed by, or sponsored by the OPNsense project, Deciso, Netgate, or the pfSense project. OPNsense, pfSense and Netgate are trademarks of their respective owners. MIT licensed.
firewall-aiops speaks to two firewall platforms behind one MCP server — OPNsense
(REST API under /api/..., API key+secret via HTTP Basic auth) and pfSense
(REST API v2 under /api/v2/... from the pfSense-pkg-RESTAPI package, API key via
an X-API-Key header) — with the same tools working on both. Each target in the
config names its own platform; a name-keyed platform registry selects the API shape
(auth + resource paths), so an agent never has to know which firewall it is talking to.
Every tool runs through a built-in governance harness (vendored, zero external
dependency): audit log, token/call budget with runaway circuit-breaker, descriptive
risk-tier labelling, undo-token recording, and prompt-injection sanitisation.
## Why this exists
One server, both firewalls — OPNsense and pfSense in a mixed estate, spoken to
through identical tool names. Adding a third firewall later is a new platform
descriptor, not a rewrite.
Read the whole firewall — firmware/health, interfaces & gateways, filter rules
(with hit counts and state table), NAT (port-forward / outbound / 1:1), aliases,
VPN (WireGuard / OpenVPN / IPsec), DHCP leases & reservations, and the firewall log.
Flagship RCA analyses — transparent heuristics that show their numbers, never a
black-box verdict: gatewayhealthrca (WAN loss/latency/down → cause + action),
rulehitandshadowanalysis (never-hit + shadowed/redundant rules), and
blockedtrafficrca (top blocked sources/ports → scan / brute-force / probe).
Governed writes — toggle a rule, add/remove an alias entry (reversible,
undo-recorded from the fetched before-state), flush states, restart a service, and
the "make it live" commit (applychanges / reconfigure) and reboot at
risk=high with a dry-run preview. Every write, reversible or not, lands an
audit row.
## What this tool does, and does not, decide
It delivers firewall operations — reads and writes — accurately and efficiently,
and records every one of them. It does not decide whether a write is allowed
to happen. That is the agent's judgement, or the permission of the account you
connect it with: give the OPNsense/pfSense API user a read-only role, and the
writes fail at the server — the place that actually owns the permission.
So there is no read-only switch, no policy file, no approval gate to configure.
The one thing the tool guarantees is that nothing is silent: every call, over
MCP and over the CLI alike, lands an audit row in ~/.firewall-aiops/audit.db,
and reversible writes still capture their before-state and record an inverse
where one exists.
> Each tool declares a risklevel, matched to its [READ]/[WRITE]
> documentation tag, and carried into the audit row as a descriptive tier — so a
> reviewer can see at a glance that a row was a high-risk write. It is a label,
> not a gate.
Running a smaller / local model? See
> Disclaimer: Community-maintained open-source project. Not affiliated with, endorsed by, or sponsored by the OPNsense project, Deciso, Netgate, or the pfSense project. OPNsense, pfSense and Netgate are trademarks of their respective owners. MIT licensed.
firewall-aiops speaks to two firewall platforms behind one MCP server — OPNsense
(REST API under /api/..., API key+secret via HTTP Basic auth) and pfSense
(REST API v2 under /api/v2/... from the pfSense-pkg-RESTAPI package, API key via
an X-API-Key header) — with the same tools working on both. Each target in the
config names its own platform; a name-keyed platform registry selects the API shape
(auth + resource paths), so an agent never has to know which firewall it is talking to.
Every tool runs through a built-in governance harness (vendored, zero external
dependency): audit log, token/call budget with runaway circuit-breaker, descriptive
risk-tier labelling, undo-token recording, and prompt-injection sanitisation.
## Why this exists
One server, both firewalls — OPNsense and pfSense in a mixed estate, spoken to
through identical tool names. Adding a third firewall later is a new platform
descriptor, not a rewrite.
Read the whole firewall — firmware/health, interfaces & gateways, filter rules
(with hit counts and state table), NAT (port-forward / outbound / 1:1), aliases,
VPN (WireGuard / OpenVPN / IPsec), DHCP leases & reservations, and the firewall log.
Flagship RCA analyses — transparent heuristics that show their numbers, never a
black-box verdict: gatewayhealthrca (WAN loss/latency/down → cause + action),
rulehitandshadowanalysis (never-hit + shadowed/redundant rules), and
blockedtrafficrca (top blocked sources/ports → scan / brute-force / probe).
Governed writes — toggle a rule, add/remove an alias entry (reversible,
undo-recorded from the fetched before-state), flush states, restart a service, and
the "make it live" commit (applychanges / reconfigure) and reboot at
risk=high with a dry-run preview. Every write, reversible or not, lands an
audit row.
## What this tool does, and does not, decide
It delivers firewall operations — reads and writes — accurately and efficiently,
and records every one of them. It does not decide whether a write is allowed
to happen. That is the agent's judgement, or the permission of the account you
connect it with: give the OPNsense/pfSense API user a read-only role, and the
writes fail at the server — the place that actually owns the permission.
So there is no read-only switch, no policy file, no approval gate to configure.
The one thing the tool guarantees is that nothing is silent: every call, over
MCP and over the CLI alike, lands an audit row in ~/.firewall-aiops/audit.db,
and reversible writes still capture their before-state and record an inverse
where one exists.
> Each tool declares a risklevel, matched to its [READ]/[WRITE]
> documentation tag, and carried into the audit row as a descriptive tier — so a
> reviewer can see at a glance that a row was a high-risk write. It is a label,
> not a gate.
Running a smaller / local model? See
收录徽章（可选）
想把收录标记放进 README 就复制这行，可选，不影响收录。
[](https://anclum.com/zh/s/aiops-tools-firewall-aiops/)
- 来源
- awesome · https://github.com/AIops-tools/Firewall-AIops
- 按领域浏览
- MCP 服务
- Traction
- 2 ★
- 收录来源
- 23 个独立来源
- 收录于
- 今天
- 安全策略
- 该仓库根目录有
SECURITY.md（我们只核文件存在，未核内容）
同类推荐
所属领域与标签
每个标签都能点进去看同类的全部条目。数字是当前库里的真实条数。