從 Slack 批准閘道器畢業，遷移至攻擊來源 IP 全自動封鎖 #
在前一篇文章中，我們以 Slack 批准閘道器的方式實作了被動式防禦，但透過 AI 代理進行批准存在結構性的問題。藉由改用不經 LLM 中介的直接管線，我們轉移至一套完全自主的系統，能在偵測後 15 分鐘內完成自動封鎖。
前次工作回顧 #
BASTION的被動式防禦透過本機 LLM 偵測連接埠掃描與暴力破解攻擊，接著透過 OPNsense 防火牆 API 自動封鎖攻擊來源 IP。
在前一篇文章中（我們建構了一套由 AI 偵測攻擊 → 透過 Slack 批准 → 於防火牆中自動封鎖的系統），我們最初出於安全考量採用「Slack 批准閘道器方式」──AI 提案、由人類透過 Slack 批准，再執行封鎖──但在實際運作中發現 Slack 批准閘道器存在結構性問題，並在短短一天內遷移至全自動化。本文將記錄此次轉移過程，並說明為何「繞過 LLM 的管線」才是正確的解決方案。
Slack 批准閘道器所遇到的問題 #
問題 1：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 則對其餘結果進行「猜測」以補足敘事。在偵測→通知階段，這僅表示「發送了錯誤的通知」，但在防火牆操作中，卻會導致「以為已封鎖，實際上卻沒有」這種致命的後果。
問題 2：Block-ID 前綴遺漏 #
003 之所以被回報為「找不到」，是因為 AI 代理將 block-20260423-003 傳遞給 fw-action.sh 時寫成了 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，而非「信任」LLM。
總結 #
我們將 BASTION 的被動式防禦從 Slack 批准閘道器遷移至全自動化。透過 AI 代理（LLM）進行路由的批准流程，存在「執行指令卻未如實回報執行結果」的結構性問題，這在防火牆操作中是無法接受的。
解決方案很簡單：讓 LLM 僅負責「判斷」，「執行」則透過直接的 shell 腳本管線進行。我們在 .env 中保留一個安全開關，可立即恢復為批准閘道器，而偵測→封鎖→24 小時自動解除的流程如今已完全自動化。
安全自動化並不需要昂貴的 GPU 或高效能 LLM──工作流程設計才是決定性的關鍵。
BASTION 是一項在封閉式網路環境中實現 AI 驅動安全監控的服務。
