光靠偵測與通知還不夠 #

BASTION 原本的運作方式是分析日誌以偵測異常，並透過 Slack 通知（上篇）。然而，通知之後的動作——在防火牆中封鎖攻擊來源 IP——需要人工手動開啟 OPNsense 管理主控台進行操作。

通知在凌晨 3 點送達，隔天早上才登入套用封鎖。在這 6 個小時之內，攻擊者可以自由地進行掃描。

我們為 BASTION 導入了反應式防禦（reactive defense）。當 AI 偵測到攻擊時，會自動提議新增防火牆封鎖，在 Slack 上核准後即可立即將規則套用至 OPNsense。

整體流程 #

實際運作情形 #

1. 封鎖建議送達 Slack #

當每 15 分鐘一次的定期分析偵測到嚴重程度為 HIGH 時，攻擊來源 IP 的封鎖建議會自動發佈至 Slack。

每次分析最多提出 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 以每小時的 cron 執行，自動移除已到期的封鎖。

若相同 IP 在解除後再次進行掃描，下次分析時會再度提出建議。

安全機制 #

由於我們正以 AI 自動化防火牆操作，因此需要安全機制來防止誤判封鎖正常流量。我們建置了 5 層防護。

白名單比對的實作 #

白名單比對是使用 Python 的 ipaddress 模組實作。它支援 CIDR 標記法（10.0.0.0/8 等），並透過內建檢查自動排除私有 IP、loopback、link-local、multicast 以及保留位址。

# 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 會直接操作 runtime table，因此單次 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 核准閘門的方式運作，但今後將累積成果資料，逐步導入自主性。過去止步於「偵測 → 通知」的監控系統，如今已能將迴圈延伸至「偵測 → 判斷 → 應對 → 自動解除」。