仅靠检测与通知是不够的 #

此前 BASTION 的工作方式是分析日志以检测异常，并通过 Slack 发出通知（参见第一篇）。但通知之后的动作——即在防火墙中封禁攻击源 IP——此前需要人工手动打开 OPNsense 管理控制台进行操作。

凌晨 3 点收到通知，第二天早上登录后才执行封禁。在这 6 个小时里，攻击者可以自由地进行扫描。

为此，我们在 BASTION 中实现了反应式防御。当 AI 检测到攻击时，会自动提出添加防火墙封禁的提案，在 Slack 上批准后即可立即将规则应用到 OPNsense。

整体流程 #

实际运行情况 #

1. 封禁提案发布到 Slack #

当每 15 分钟一次的常规分析检测到 severity: HIGH 时，会自动向 Slack 发布针对攻击源 IP 的封禁提案。

每次分析最多发布 3 条提案。按封禁次数由多到少选取排名靠前的 IP。

2. 批准后立即反映到防火墙 #

在 Slack 上发送批准命令后，fw-action.sh 会调用 OPNsense API，将该 IP 添加到封禁列表中。

在 OPNsense 一侧，该 IP 会被添加到名为 BASTION_AutoBlock 的 Alias 中。系统预先配置了引用该 Alias 的 WAN 封禁规则，因此通过 API 将 IP 加入 Alias 后，封禁会立即生效。

3. 24 小时后自动解除 #

auto-expire.sh 通过每小时执行一次的定时任务，自动移除已到期的封禁。

如果同一 IP 在解除后再次进行扫描，将在下一次分析中重新被提出封禁提案。

安全机制 #

由于是通过 AI 来自动化防火墙操作，因此需要有安全机制来防止误判导致封禁正常流量。我们实现了 5 层防御。

白名单匹配的实现 #

白名单匹配使用 Python 的 ipaddress 模块实现，支持 CIDR 表示法（如 10.0.0.0/8），并通过内置检查自动排除私有 IP、回环地址、链路本地地址、组播地址与保留地址。

# Whitelist matching flow
1. Built-in check: is_private / is_loopback / is_link_local / is_multicast / is_reserved
2. File matching: Check each line in block-whitelist.txt (single IP or CIDR)
3. Result: exit 0=block prohibited / exit 1=block allowed

OPNsense API 集成 #

封禁机制本身是一个 OPNsense Alias（IP 地址组）。我们预先创建一个名为“BASTION_AutoBlock”的 Alias，并配置一条以该 Alias 为来源的 WAN 封禁规则。

# Add IP (execute block)
curl -k -u "${API_KEY}:${API_SECRET}" \
  -X POST "${OPNSENSE}/api/firewall/alias_util/add/BASTION_AutoBlock" \
  -d '{"address":"attack_source_ip"}'

# Remove IP (remove block)
curl -k -u "${API_KEY}:${API_SECRET}" \
  -X POST "${OPNSENSE}/api/firewall/alias_util/delete/BASTION_AutoBlock" \
  -d '{"address":"attack_source_ip"}'

alias_util 会直接操作运行时表，因此仅需一次 API 调用即可立即生效，无需重新加载防火墙规则。

审计日志 #

所有的封禁、解除、批准、拒绝以及超时都会被记录到审计日志中。

2026-04-23 13:31:33 [PROPOSE] new block-20260423-003 ip=xxx.xxx.119.51 reason=port_scan count=3003
2026-04-23 13:37:14 [BLOCK]   approved block-20260423-003 ip=xxx.xxx.119.51 expires=2026-04-24T13:37:14
2026-04-24 00:00:03 [EXPIRE]  auto-expire block-20260423-003 ip=xxx.xxx.119.51 api=done

可通过标签（[PROPOSE] / [BLOCK] / [EXPIRE] 等）进行 grep，仅提取特定操作。

逐步自主化 #

目前我们采用的是 Slack 审批把关的方式，但在设计上支持随着成果的积累逐步实现自主化。

总结 #

BASTION 的反应式防御实现了“日志分析 → 封禁提案 → Slack 批准 → OPNsense API 封禁 → 24 小时自动解除”这一流程的全自动化。白名单、审批把关、速率限制、自动解除、紧急清空这 5 层安全机制，将误判带来的业务影响降到最低。

目前我们仍以 Slack 审批把关的方式运行，但今后会不断积累成果数据，逐步引入自主化。此前止步于“检测 → 通知”的监控系统，如今已在“检测 → 判断 → 响应 → 自动解除”这一完整闭环中运转。