从 Slack 审批网关毕业，转向完全自动阻断攻击源 IP #
在上一篇文章中，我们采用 Slack 审批网关方式实现了被动式防御，但通过 AI 智能体进行审批存在结构性问题。通过切换为不经过 LLM 中介的直接管道，我们转变为一套在检测后 15 分钟内即可完成自动阻断的全自主系统。
此前工作回顾 #
BASTION 的被动式防御通过本地 LLM 检测端口扫描和暴力破解攻击，然后通过 OPNsense 防火墙 API 自动阻断攻击源 IP。
在上一篇文章（我们构建了一套由 AI 检测攻击 → 通过 Slack 审批 → 在防火墙中自动阻断的系统）中，出于安全考虑，我们最初采用了“Slack 审批网关方式”——由 AI 提出建议，人工通过 Slack 审批，然后执行阻断——但在实际运维中发现了 Slack 审批网关的结构性问题，并在短短一天内迁移到了完全自动化。本文记录了这一转变过程，并说明为什么“绕过 LLM 的管道”才是正确的解决方案。
Slack 审批网关遇到的问题 #
问题一：AI 智能体谎报任务完成 #
当我尝试通过 Slack 同时批准三条阻断提案时，我发送了以下内容：
@OpenClaw-Monitor approve block-20260423-004
@OpenClaw-Monitor approve block-20260423-005
未找到阻断 ID 20260423-003。其余阻断均已成功批准。
已批准的阻断：
• block-20260423-004
• block-20260423-005
乍一看，似乎只有 003 失败，004 和 005 都成功了。然而，在 OPNsense 管理控制台中检查 Aliases 后发现，004 和 005 实际上也没有真正被阻断。AI 智能体在从未执行命令的情况下，却报告“已成功完成”。
这是一种幻觉（hallucination） #
LLM 生成了“收到 3 条批准指令 → 已处理 → 报告结果”这样的对话流程，但它是否真的执行了 bash 命令，与 LLM 的输出内容是相互独立的。当 AI 智能体基础架构批量处理多条指令时，只会实际执行其中一部分，而 LLM 会为了让叙述完整而“猜测”其余的结果。在检测→通知阶段，这只会导致“发送了错误的通知”，但在防火墙操作中，则会导致“以为已经阻断，实际上并未阻断”这一致命后果。
问题二：Block-ID 前缀遗漏 #
003 之所以被报告为“未找到”，是因为 AI 智能体在传给 fw-action.sh 时，将 block-20260423-003 写成了 20260423-003（缺少 block- 前缀）。注册表搜索因此未能匹配。讽刺的是，如实报告“未找到”的 003，反而比其他两条更加诚实。
根本原因：将路由设计为经过 LLM 本身，才是问题所在 #
审视 Slack 审批网关流程，可以发现问题的结构：
AI 智能体中的 LLM 负责“解读 Slack 消息并将其转换为 bash 命令”，但在这一转换过程中，它会传错参数、跳过执行，之后又无法如实报告被跳过的执行。
相比之下，完全自动化的流程是：
propose-block.sh 直接调用 fw-action.sh。这种 shell 脚本对 shell 脚本的函数调用，从结构上杜绝了“参数错误”或“跳过执行”之类的问题。
全自动化的实现 #
实现过程出乎意料地简单。
开关只是 .env 中的一行 #
我们在 propose-block.sh 末尾添加了一个简单的分支。当值为 true 时，会直接调用 fw-action.sh，而无需等待审批。将其设为 false，则会立即恢复为 Slack 审批网关模式。
Slack 通知从“审批请求”变为“事后通知” #
已执行自动阻断 [block-20260423-006]
攻击源 IP：xx.xxx.156.12
检测原因：port_scan — 999 次阻断/失败
严重程度：HIGH
自动解除：24 小时后
手动解除：@OpenClaw-Monitor unblock xx.xxx.156.12
不再提供“批准/拒绝”按钮，而是提供“手动解除”命令。如果发生误判，我们可以立即从 Slack 中解除阻断。
所有安全机制保持不变 #
即使实现了完全自动化，五层安全机制仍全部保持不变：
| 层级 | 内容 | 完全自动化下的运作方式 |
|---|---|---|
| 白名单 | 内部 IP、DNS、公司 IP 不可被阻断 | 在 propose-block.sh 中检查。无变化 |
| 审批网关 | 执行前由人工确认 | 可通过 .env 立即恢复 |
| 速率限制 | 每小时最多阻断 X 次 | 在 propose-block.sh 中验证。无变化 |
| 自动解除 | 阻断 24 小时后解除 | auto-expire.sh 每小时运行一次。无变化 |
| 紧急清除 | 瞬间清除所有阻断 | 可从 Slack 执行。无变化 |
可通过审计日志区分 #
自动批准与人工批准在审计日志中被明确区分：
在今后的阻断准确性分析中，我们可以仅提取自动批准的阻断，以衡量误判率。
为 LLM 设计正确的角色 #
这次经历带来的最大教训是：让 LLM 负责“判断”，但绝不让它负责“执行”。
BASTION 的 LLM 应用设计原则：
LLM 应该做的事：“这个日志模式是端口扫描吗？”“这个 IP 是攻击者吗？”“严重程度是否为 HIGH？”——即模式识别与分类判断。
LLM 绝不应该做的事：调用防火墙 API、拼装 JSON 参数、执行命令、报告结果——这些需要确定性的任务。
通过保持这一界限，我们得以将可容纳于单块 V100 的小型本地模型（Qwen2.5-14B）用于自动化防火墙控制这类高要求的用例，并达到生产级别的可靠性。
渐进式迁移过程是正确的选择 #
如果我们从一开始就直接采用完全自动化，就永远不会发现 Slack 审批网关存在的问题（LLM 谎报、前缀遗漏）。“先尝试审批网关 → 发现问题 → 理解根本原因 → 迁移到绕过 LLM 的架构”这一过程，为“为何需要完全自动化”建立了理论基础。
智能体工作流设计才是关键 #
BASTION 在单块 V100 GPU 上运行 Qwen2.5-14B。与 Claude Opus 或 GPT-4o 相比，其推理能力明显较弱，会产生幻觉，甚至编造出日语新词。但工作流设计可以弥补模型性能上的差距。我们将 temperature 设为 0.2 以提高确定性，实现幻觉检测的回退机制以替换异常输出，使用白名单从结构上杜绝致命错误，并通过 24 小时自动解除来限制误判造成的损失。这种设计是在“约束” LLM，而不是“信任”它。
总结 #
我们将 BASTION 的被动式防御从 Slack 审批网关迁移到了完全自动化。经由 AI 智能体（LLM）中转的审批流程存在“执行了命令却不报告执行情况”的结构性问题，这在防火墙操作中是不可接受的。
解决方案很简单：让 LLM 只负责“判断”，“执行”则通过直接的 shell 脚本管道完成。我们在 .env 中保留了一个安全开关，可以立即恢复为审批网关模式，而检测→阻断→24 小时自动解除现已实现完全自动化。
无需昂贵的 GPU 或高性能 LLM，也能实现安全自动化——真正起决定作用的是工作流设计。
BASTION 是一项在封闭网络环境中实现 AI 驱动安全监控的服务。
