What makes firewall-aiops notable?

2.3K downloads. Trust evidence available

How should firewall-aiops be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

firewall-aiops

Use this skill whenever the user needs to operate an OPNsense or pfSense firewall — a one-shot overview, firmware/health, interfaces and gateways, firewall rules with hit-counts and shadow analysis, NAT (port-forward/outbound/1:1), aliases and their entries, VPN (WireGuard/OpenVPN/IPsec), DHCP leases and static mappings, the firewall log and state table, three flagship RCAs (gateway health, rule hit/shadow, blocked traffic), and governed writes (toggle a rule, add/remove an alias entry, kill states, restart a service, apply/reconfigure to make edits live, reboot). Always use this skill for "OPNsense", "pfSense", "firewall rule", "port forward", "NAT", "alias", "WireGuard", "OpenVPN", "IPsec", "DHCP lease", "firewall log", "blocked traffic", "why is my WAN down", "gateway loss/latency", "unused / shadowed rules", "apply firewall changes", "reboot the firewall" when the context is an OPNsense/pfSense firewall. Do NOT use when the target is something other than an OPNsense/pfSense firewall (a hypervisor, storage appliance, backup product, container-orchestration cluster, multi-vendor router/switch config, or OT/industrial equipment) — route those to the appropriate other AIops-tools skill. Cloud security groups and vendor firewall appliances are out of scope. Governed firewall operations with a built-in governance harness (audit, policy, token budget, undo, risk-tiers). Live-verified against real OPNsense 26.7 and pfSense CE 2.7.2 on top of the mock test suite; see docs/VERIFICATION.md for exactly what each run proved and what is still untested.

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

2.3k

Updated

Oct 9, 2026

Version

0.12.5

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 2.3K downloads reported by the source. Last updated 10/9/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 9, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 9, 2026
Adoption signal: 2.3K downloadsadoption · observed Oct 9, 2026
Latest release: 0.12.5release · observed Sep 16, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s171xgnmqse0nqvgqvqnaq5f9183kyre:firewall-aiops

Install using `clawhub skill install s171xgnmqse0nqvgqvqnaq5f9183kyre:firewall-aiops` in an isolated environment before connecting it to live workloads.
No published capability contract is available yet, so validate auth and request/response behavior manually.
Review the upstream CLAWHUB listing at https://clawhub.ai/zw008/firewall-aiops before using production credentials.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-zw008-firewall-aiops/snapshot"

Documentation

CLAWHUB

150,158 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: firewall-aiops
slug: firewall-aiops
displayName: "Firewall AIops"
summary: "Governed OPNsense + pfSense firewall ops: rules, NAT, VPN, DHCP, RCA. 35 tools."
license: MIT
homepage: https://github.com/AIops-tools/Firewall-AIops
tags: [aiops, mcp, governance, firewall]
description: >
  Use this skill whenever the user needs to operate an OPNsense or pfSense firewall — a one-shot overview, firmware/health, interfaces and gateways, firewall rules with hit-counts and shadow analysis, NAT (port-forward/outbound/1:1), aliases and their entries, VPN (WireGuard/OpenVPN/IPsec), DHCP leases and static mappings, the firewall log and state table, three flagship RCAs (gateway health, rule hit/shadow, blocked traffic), and governed writes (toggle a rule, add/remove an alias entry, kill states, restart a service, apply/reconfigure to make edits live, reboot).
  Always use this skill for "OPNsense", "pfSense", "firewall rule", "port forward", "NAT", "alias", "WireGuard", "OpenVPN", "IPsec", "DHCP lease", "firewall log", "blocked traffic", "why is my WAN down", "gateway loss/latency", "unused / shadowed rules", "apply firewall changes", "reboot the firewall" when the context is an OPNsense/pfSense firewall.
  Do NOT use when the target is something other than an OPNsense/pfSense firewall (a hypervisor, storage appliance, backup product, container-orchestration cluster, multi-vendor router/switch config, or OT/industrial equipment) — route those to the appropriate other AIops-tools skill. Cloud security groups and vendor firewall appliances are out of scope.
  Governed firewall operations with a built-in governance harness (audit, policy, token budget, undo, risk-tiers). Live-verified against real OPNsense 26.7 and pfSense CE 2.7.2 on top of the mock test suite; see docs/VERIFICATION.md for exactly what each run proved and what is still untested.
installer:
  kind: uv
  package: firewall-aiops
argument-hint: "[a rule/alias id, an IP, or describe your firewall task]"
allowed-tools:
  - Bash
metadata: {"openclaw":{"requires":{"anyBins":["firewall-aiops","uvx"]},"optional":{"env":["FIREWALL_AIOPS_CONFIG","FIREWALL_AIOPS_MASTER_PASSWORD"]},"homepage":"https://github.com/AIops-tools/Firewall-AIops","emoji":"🛡️","os":["macos","linux"]}}
compatibility: >
  Standalone, self-governed firewall operations across OPNsense (REST API /api/..., API key+secret via HTTP Basic auth) and pfSense (REST API v2 /api/v2/..., API key via X-API-Key header). Each target in the config names its own platform, and a name-keyed platform registry selects the API shape, so the same tools work on both and one config can span a mixed estate. The governance harness (audit, policy, token/runaway budget, undo, risk-tiers) is bundled in the package — no external skill-family dependency.
  All write operations are audited to a local SQLite DB under ~/.firewall-aiops/ (relocatable via FIREWALL_AIOPS_HOME).
  Credentials: the OPNsense API secret (paired with the API key) or the pfSense API key i

_meta.json

{
  "ownerId": "kn7b067awq2s97bn3d7p5qfhw5827pxc",
  "slug": "firewall-aiops",
  "version": "0.12.5",
  "publishedAt": 1789601135182
}

references/agent-guardrails.md

# Agent guardrails — running firewall-aiops with a smaller / local model

If you drive these tools with a local model (Llama, Qwen, Mistral … via Goose,
Ollama, LM Studio, or any OpenAI-compatible runtime), you will get noticeably
better results with a short system prompt. This page gives you one, and — more
importantly — tells you which guardrails you **no longer need to write**, because
the tool now enforces them itself.

The distinction matters. A guardrail in a prompt is a request. A guardrail in the
harness is a guarantee. Anything below that we could move into the harness, we did.

## Authorization is not this tool's job — decide it where it belongs

Whether a write should happen is your decision, or the account's. The tool does
not gate it — there is no read-only switch and no approval prompt to configure.
The two right places to control read vs write:

- **The account you connect with.** Give the OPNsense/pfSense API user a
read-only role. A write then fails at the server, which is the only place the
permission actually lives — no skill-side flag can be argued around by a model,
but a revoked permission cannot be.
- **Your agent's system prompt.** If you want an observe-only session, tell the
model not to call the write tools (they are clearly tagged `[WRITE]`).

What the tool *does* guarantee is that you can always see what happened:

## What the tool now enforces — do not waste prompt budget on these

| You might be tempted to prompt | Why you don't need to |
|---|---|
| "Never restart the web GUI / lock yourself out" | **Already enforced.** `restart_service` refuses the daemon serving this appliance's own API (`nginx`, `lighttpd`, `configd`, `webgui`, ...), and `apply_changes` / `reconfigure` refuse a staged rule set that would provably cut management access. Both are exact and fail open — see `capabilities.md`. Do not spend prompt budget on it. |
| "Don't invent a value when a field is missing" | OPNsense and pfSense populate different keys for the same concept. A field neither platform returned comes back as `null`, never as `""`. Absent and empty are distinguishable in the payload. |
| "Tell me if the output was cut off" | `firewall_log`, `states_table` and `top_talkers` all return `{"<items>": [...], "returned": N, "limit": L, "truncated": true/false}` — the list key is `entries`, `states` and `topTalkers` respectively. Truncation is measured, not guessed from a length coincidence. |
| "Make it show the number it judged on" | Gateway and blocked-source entries carry the numbers they were judged on — `lossPercent` and `rttMs` for a gateway (`lossPct`/`latencyMs` are the *thresholds* they were compared against, reported separately under `thresholds`), `hits`, `distinctPorts` and `topPort` for a blocked source — so those claims can be checked against a figure. `blocked_traffic_rca` orders `topSources` by `hits`, which is in the payload. Rule findings are qualitative: they carry `uuid`, `description`, `interface`, `shadowedBy`/

references/capabilities.md

# firewall-aiops capabilities

> **35 MCP tools** (26 read, 9 write) across OPNsense (REST `/api/...`, API key+secret
> via HTTP Basic) and pfSense (REST v2 `/api/v2/...`, API key via `X-API-Key`). The
> concrete REST paths below are modelled from each project's public API and have not
> yet been exercised against a live firewall — see `docs/VERIFICATION.md`.

A per-target `platform` field (`opnsense` / `pfsense`) selects the API shape; the same
tool name resolves to the right path on each firewall via the platform registry.

## System (read)

| Tool | OPNsense path | pfSense path | Returns |
|------|---------------|--------------|---------|
| `firmware_status` | `/api/core/firmware/status` | `/api/v2/system/version` | version, product, updates available |
| `health_status` | `/api/diagnostics/system/systemInformation` | `/api/v2/status/system` | hostname, uptime, CPU %, mem %, load |
| `interface_status` | `/api/diagnostics/interface/getInterfaceNames` | `/api/v2/status/interfaces` | interfaces with link status + address (down first) |
| `gateway_status` | `/api/routes/gateway/status` | `/api/v2/status/gateways` | gateways with status, loss %, RTT |

## Rules (read)

| Tool | OPNsense path | pfSense path | Returns |
|------|---------------|--------------|---------|
| `list_rules` | `/api/firewall/filter/searchRule` | `/api/v2/firewall/rules` | filter rules normalized (uuid, enabled, action, if, src/dst, evaluations) |
| `rule_detail` | `/api/firewall/filter/getRule/{uuid}` | `/api/v2/firewall/rule?id=` | one rule's full detail |
| `rule_stats` | `/api/diagnostics/firewall/pfStatistics` | `/api/v2/firewall/rules` | per-rule hit counts / evaluations, busiest first |
| `rule_states` | `/api/diagnostics/firewall/queryStates` | `/api/v2/firewall/states` | active state-table entries tied to rules |
| `pending_changes` | (derived from `searchRule`) | (derived from `firewall/rules`) | the staged rule set `apply_changes` would commit + its lockout assessment |

## NAT (read)

| Tool | Returns |
|------|---------|
| `nat_port_forwards` | inbound port-forward (DNAT) rules |
| `nat_outbound` | outbound (source) NAT mappings |
| `nat_one_to_one` | 1:1 NAT mappings (external ↔ internal) |

## Aliases (read)

| Tool | Returns |
|------|---------|
| `list_aliases` | all aliases (name, type, description, member count) |
| `alias_entries` | the member entries (hosts/networks/ports) of one alias |

## VPN (read)

| Tool | Returns |
|------|---------|
| `wireguard_status` | WireGuard peers with connected state, last handshake, transfer |
| `openvpn_sessions` | OpenVPN sessions / connected clients (name, address, bytes) |
| `ipsec_sas` | IPsec security associations (phase-1/phase-2) with state |

## DHCP (read)

| Tool | Returns |
|------|---------|
| `dhcp_leases` | active DHCP leases (IP, MAC, hostname, state); `online_only` filter |
| `dhcp_static_mappings` | DHCP static (reserved) mappings (MAC ↔ IP) |

## Diagnostics (read)

| Tool | Returns |
|------|---------

references/cli-reference.md

# firewall-aiops CLI reference

> Covers OPNsense (REST `/api/...`) and pfSense (REST v2 `/api/v2/...`). Responses are
> validated against mocks; see `docs/VERIFICATION.md` for the live-run checklist.

## Setup & diagnostics

```bash
firewall-aiops init                      # interactive wizard (asks for the platform: opnsense/pfsense)
firewall-aiops doctor                    # check config, secrets, connectivity
                                         #   firmware/version query on both platforms
firewall-aiops doctor --skip-auth        # config/secret checks only (no network)
firewall-aiops mcp                       # start the MCP server (stdio)
```

## Secrets (encrypted store)

```bash
firewall-aiops secret set <target> [--value <secret>]  # store OPNsense secret / pfSense key (hidden prompt if no --value)
firewall-aiops secret list                             # list target names with a stored secret (values never shown)
firewall-aiops secret rm <target>                      # delete a stored secret
firewall-aiops secret migrate                          # import legacy plaintext .env into the encrypted store
firewall-aiops secret rotate-password                  # re-encrypt under a new master password
```

## Overview & rules

```bash
firewall-aiops overview                        # one-shot: version + gateway/interface health + rule count
firewall-aiops rules list [--interface wan]    # list filter rules (optionally on one interface)
firewall-aiops rules show <uuid>               # one rule's full detail
firewall-aiops rules toggle <uuid> --disable   # governed write: dry-run + double-confirm
firewall-aiops rules toggle <uuid> --enable --dry-run
```

## Firewall log

```bash
firewall-aiops log                             # recent firewall-log entries
firewall-aiops log --action block --limit 50   # only blocked traffic
```

## Notes

- `--target/-t` selects a named target from `config.yaml`; omit for the default (first).
- `overview`, `rules`, and `log` are the CLI subset; the full read surface (NAT,
  aliases, VPN, DHCP, diagnostics), the three flagship analyses, and the remaining
  governed writes (alias entry add/remove, kill_states, restart_service, apply_changes,
  reconfigure, reboot) are exposed through the MCP server (`firewall-aiops mcp`).
- High-risk writes (`apply_changes`, `reconfigure`, `reboot`) are labelled risk=high
  and audited. `FIREWALL_AUDIT_APPROVED_BY` (and `FIREWALL_AUDIT_RATIONALE`) are
  optional audit annotations, recorded when set but never required.

Github ReposUpdated 2h agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.