--- title: AI 检测攻击 → Slack 确认 → 自动在防火墙中添加封禁规则的机制已搭建完成 description: "2026.04 ／ 技术博客 ／ BASTION # AI 检测攻击 → Slack 确认 → 自动在防火墙中添加封禁规则 我们在 BASTION 原有的“检测 → 通知”流程中新增了“自动响应”功能。当 AI 检测到端口扫描时，会在 Slack 上发布封禁提案；经人工批准后，封禁规则会立即添加到 OPNsense 防火墙中。24 小时后自动解除。 ## 仅靠检测与通知是不够的 此前 BASTION 的工作方式是分析日志以检测异常，并通过 Slack 发出通知（参见[第一篇](https://bestnetllc.co.jp/zh-hans/docs/%e4%bd%bf%e7%94%a8%e6%9c%ac%e5%9c%b0llm%e8%87%aa%e5%8a%a8%e5%88%86%e6%9e%90%e5%9f%ba%e7%a1%80%e8%ae%be%e6%96%bd%e6%97%a5%e5%bf%97%e7%9a%84%e5%ae%9e%e8%b7%b5/)）。但通知之后的动作——即在防火墙中封禁攻击源 IP——此前需要人工手动打开 OPNsense 管理控制台进行操作。 凌晨 3 点收到通知，第二天早上登录后才执行封禁。在这 6 个小时里，攻击者可以自由地进行扫描。…" url: "https://bestnetllc.co.jp/zh-hans/docs/ai-%e6%a3%80%e6%b5%8b%e6%94%bb%e5%87%bb-%e2%86%92-slack-%e7%a1%ae%e8%ae%a4-%e2%86%92-%e8%87%aa%e5%8a%a8%e5%9c%a8%e9%98%b2%e7%81%ab%e5%a2%99%e4%b8%ad%e6%b7%bb%e5%8a%a0%e5%b0%81%e7%a6%81%e8%a7%84/" updated: "2026-06-08" category: Tech Blog / AI安全运营 --- # AI 检测攻击 → Slack 确认 → 自动在防火墙中添加封禁规则的机制已搭建完成 2026.04 ／ 技术博客 ／ BASTION # AI 检测攻击 → Slack 确认 → 自动在防火墙中添加封禁规则 我们在 BASTION 原有的“检测 → 通知”流程中新增了“自动响应”功能。当 AI 检测到端口扫描时，会在 Slack 上发布封禁提案；经人工批准后，封禁规则会立即添加到 OPNsense 防火墙中。24 小时后自动解除。 ## 仅靠检测与通知是不够的 此前 BASTION 的工作方式是分析日志以检测异常，并通过 Slack 发出通知（参见[第一篇](https://bestnetllc.co.jp/zh-hans/docs/%e4%bd%bf%e7%94%a8%e6%9c%ac%e5%9c%b0llm%e8%87%aa%e5%8a%a8%e5%88%86%e6%9e%90%e5%9f%ba%e7%a1%80%e8%ae%be%e6%96%bd%e6%97%a5%e5%bf%97%e7%9a%84%e5%ae%9e%e8%b7%b5/)）。但通知之后的动作——即在防火墙中封禁攻击源 IP——此前需要人工手动打开 OPNsense 管理控制台进行操作。 凌晨 3 点收到通知，第二天早上登录后才执行封禁。在这 6 个小时里，攻击者可以自由地进行扫描。 为此，我们在 BASTION 中实现了**反应式防御**。当 AI 检测到攻击时，会自动提出添加防火墙封禁的提案，在 Slack 上批准后即可立即将规则应用到 OPNsense。 **不过，我们并没有立即将其做成完全自动化。**赋予 AI 修改防火墙规则的权限，存在因误判而封禁正常流量的风险。我们先采用 Slack 审批把关的方式（“AI 提案 → 人工批准 → 执行”），待积累一定成果后再逐步引入自主化。 ## 整体流程 | 步骤 | 执行主体 | 操作内容 | | --- | --- | --- | | 1. 攻击检测 | analyze.sh（每 15 分钟） | 通过日志分析检测端口扫描与暴力破解尝试，严重程度标记为 HIGH | | 2. 封禁提案 | propose-block.sh | 白名单检查 → 去重 → 将提案发布到 Slack | | 3. 人工批准 | 运维人员 | Slack 命令：`@OpenClaw-Monitor approve block-XXXXX` | | 4. 执行封禁 | fw-action.sh | 通过 OPNsense API 将 IP 添加到 Alias（BASTION_AutoBlock） | | 5. 自动解除 | auto-expire.sh（每小时定时任务） | 24 小时后将 IP 从 Alias 中移除 | ## 实际运行情况 ### 1. 封禁提案发布到 Slack 当每 15 分钟一次的常规分析检测到 severity: HIGH 时，会自动向 Slack 发布针对攻击源 IP 的封禁提案。 incoming-webhook 13:31 ![🛡️](https://s.w.org/images/core/emoji/17.0.2/svg/1f6e1.svg) **封禁提案 [block-20260423-003]** 攻击源 IP：`xxx.xxx.119.51` 检测原因：port_scan — 3,003 次封禁/失败 严重程度：HIGH 自动解除：24 小时后 批准：`@OpenClaw-Monitor approve block-20260423-003` 拒绝：`@OpenClaw-Monitor reject block-20260423-003` *※ 若 30 分钟内无响应，将自动拒绝。* incoming-webhook 13:31 ![🛡️](https://s.w.org/images/core/emoji/17.0.2/svg/1f6e1.svg) **封禁提案 [block-20260423-004]** 攻击源 IP：`xxx.xxx.47.173` 检测原因：port_scan — 977 次封禁/失败 严重程度：HIGH 自动解除：24 小时后 incoming-webhook 13:31 ![🛡️](https://s.w.org/images/core/emoji/17.0.2/svg/1f6e1.svg) **封禁提案 [block-20260423-005]** 攻击源 IP：`xxx.xxx.102.23` 检测原因：port_scan — 965 次封禁/失败 严重程度：HIGH 自动解除：24 小时后 每次分析最多发布 3 条提案。按封禁次数由多到少选取排名靠前的 IP。 ### 2. 批准后立即反映到防火墙 在 Slack 上发送批准命令后，fw-action.sh 会调用 OPNsense API，将该 IP 添加到封禁列表中。 运维人员 13:37 @OpenClaw-Monitor approve block-20260423-003 incoming-webhook 13:37 ![✅](https://s.w.org/images/core/emoji/17.0.2/svg/2705.svg) **封禁执行完成 [block-20260423-003]** IP：`xxx.xxx.119.51` 自动解除：2026-04-24T13:37:14+09:00 在 OPNsense 一侧，该 IP 会被添加到名为 BASTION_AutoBlock 的 Alias 中。系统预先配置了引用该 Alias 的 WAN 封禁规则，因此通过 API 将 IP 加入 Alias 后，封禁会立即生效。 ### 3. 24 小时后自动解除 auto-expire.sh 通过每小时执行一次的定时任务，自动移除已到期的封禁。 incoming-webhook 00:00 ![⏰](https://s.w.org/images/core/emoji/17.0.2/svg/23f0.svg) **自动解除：xxx.xxx.119.51**（已过 24 小时） 如果同一 IP 在解除后再次进行扫描，将在下一次分析中重新被提出封禁提案。 ## 安全机制 由于是通过 AI 来自动化防火墙操作，因此需要有安全机制来防止误判导致封禁正常流量。我们实现了 5 层防御。 | 层级 | 内容 | 目的 | | --- | --- | --- | | 白名单 | 内部 IP、DNS、公司全局 IP 永不封禁 | 防止封禁自身流量 | | Slack 审批把关 | 执行前由人工确认（初期阶段） | 捕捉 AI 的误判 | | 速率限制 | 每小时最多封禁 10 次 | 防止异常的大量封禁 | | 自动解除 | 24 小时后自动移除封禁 | 即使误判也能自动恢复 | | 紧急清空 | 可通过 Slack 即时移除所有封禁 | 业务受到影响时可紧急回滚 | ### 白名单匹配的实现 白名单匹配使用 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 审批把关的方式，但在设计上支持随着成果的积累逐步实现自主化。 | 阶段 | 模式 | 迁移条件 | | --- | --- | --- | | 阶段 1（当前） | Slack 审批把关 | — | | 阶段 2 | 条件性自主 | 高置信度 + 达到一定封禁次数以上 → 自动执行。否则仍走审批把关 | | 阶段 3 | 完全自主 | 连续 3 个月误判率低于 0.1% | ### 为什么要循序渐进？ 在 BASTION 开发过程中，我们遇到过 LLM 出现幻觉、“捏造出并不存在的事件”的情况。有一个账户被报告“被锁定 18 次”，但日志中实际的事件数量为零。如果当时就已经实现了反应式防御，我们可能就会因为这些幽灵攻击而误封 IP。正是这段经历，成为我们决定“执行前先由人工确认”这一设计的依据。 ### Slack 审批把关的局限性已经显现 在通过 OpenClaw 进行 Slack 批准的过程中，我们也遇到过 LLM 在批处理中未能执行部分命令、却报告“已完成”的情况。只要中间存在基于 agent 的 LLM，这种不确定性在结构上就无法避免。而在完全自动化（直接的 analyze.sh → propose-block.sh → fw-action.sh 流水线）中，由于绕过了 LLM 的回复生成环节，这个问题就不会出现。 ## 总结 BASTION 的反应式防御实现了“日志分析 → 封禁提案 → Slack 批准 → OPNsense API 封禁 → 24 小时自动解除”这一流程的全自动化。白名单、审批把关、速率限制、自动解除、紧急清空这 5 层安全机制，将误判带来的业务影响降到最低。 目前我们仍以 Slack 审批把关的方式运行，但今后会不断积累成果数据，逐步引入自主化。此前止步于“检测 → 通知”的监控系统，如今已在“检测 → 判断 → 响应 → 自动解除”这一完整闭环中运转。 BASTION 是一项在隔离环境中实现 AI 安全监控的服务。 [BASTION 服务页面](https://bestnetllc.co.jp/zh-hans/bastion-4/) [联系我们](https://bestnetllc.co.jp/zh-hans/contact-4/)