這套設計信任誰、不信任誰；封鎖清單實際擋得住什麼；Suricata 看不到什麼；哪一份資料才是「發生了多少事」的真相；以及各元件掛掉時會發生什麼。導入前讀完這篇，能省掉多數「為什麼沒動作」的排查。
整條鏈最後會封鎖的是「攻擊者 IP」，而這個 IP 在反向代理架構下不是封包來源，是標頭裡寫的值。誰能寫這個標頭、系統信不信，決定了會不會有人陷害第三方。
nftables 的 blocklist 掛在 input hook。這一句話決定了它的效力範圍：注意！表格底色與圖5-1的對應
所以在「純 tunnel 部署」下，nftables 執行點的意義是保護主機 B 自己，以及作為決策落地的參考實作與驗證手段（--test-event 那一圈驗的就是它）。要讓封鎖真的在邊界生效，讀者要接的是 EDL 到自己的邊界防火牆，或補上 bouncer。Cloudflare 執行點目前是預留的空殼。這不是缺陷被藏起來，安裝文件的驗證章節寫的就是 nftables 這一圈，本篇只是把效力範圍講白。
全架構的八個放行點集中列在總覽第三節。與「不會被封」直接相關的是下面三個。
| 機制 | 內容 | 限制 |
|---|---|---|
| nftables allowlist（總覽第三節第 1 條） | 平台主機 IP 與 ADMIN_IPS，在 input chain 最前面 accept，blocklist 對它們無效 | 只救 input。ssh_guard_input priority -150 比它早，開了 --ssh-guard 又把自己排除在 ADMIN_IPS 外，allowlist 救不了，只能從主控台救 |
| 平台端保護清單（總覽第三節第 5 條） | DecisionWriter 寫 block 前比對：企業內建 16 條（RFC1918、回送、link-local、CGNAT、群播、保留、IPv6 ULA 與 link-local）、平台設定的可信代理與額外網段、企業自訂。命中即拒寫 | 在平台端做一次，防禦端不帶本地清單（避免兩份要同步）。TEST-NET 段（203.0.113.0/24 等）刻意不納入，端對端驗證用它當公網攻擊者 |
| 豁免與覆寫 | 企業可加豁免項目（目標須完全落在豁免網段內）；流程節點可設 allow_protected_target 覆寫並留稽核痕跡 | 豁免一台主機不會讓整段變成可封 |
| EDL 允許清單（總覽第三節第 4 條） | 平台「放行」決策落地成 :8500/edl/allow，外部防火牆把它放在 deny 規則之上，就能保證名單內的來源即使日後被誤判也不會在邊界被擋 | 只對有抓 EDL 的防火牆生效；nftables 與 CrowdSec 執行點不支援 allow 動作 |
注意！表格底色與圖5-1的對應
| 憑證 | 存放位置 | 持有者能做什麼 | 補救 |
|---|---|---|---|
| 事件受理金鑰（INTAKE_KEY_ID + secret） | 主機 B .env（600）；平台 api_keys 表加密存 | 以該企業身分注入任意事件 → 建案 → 在自動處置流程下等於處置權。這是「注入權＝處置權」的由來，也是每家企業一台防禦端、金鑰不集中的理由 | 平台「安全中心 → API Key」停用，重跑配對 |
| 執行帳號（SA_ID + secret） | 同上；平台 od_service_accounts | 拉取與回報決策。能把決策標成 applied 卻不真的落地；不能標 expired／revoked、不能建新決策 | 平台「開放防禦 → 服務帳號」停用 |
| BRIDGE_INGEST_TOKEN | 主機 B .env | 直接對 od-bridge 8500 注入事件（繞過 Vector 的過濾與封頂，但仍要能打到 8500，而 8500 只放行平台主機） | 改 .env 後 --reconfigure |
| CrowdSec machine 憑證 | od-bridge/state/crowdsec_machine.json（600） | 對本機 LAPI 寫決策 | cscli machines delete 後 --reconfigure |
| Cloudflare Tunnel token | 主機 B .env | 在任何地方起一個 connector 接管對外 hostname 的流量 | Cloudflare 後台刪 tunnel 重建 |
| ClickHouse / Grafana 密碼 | 主機 B .env | 讀全量事件（含 payload、UA、XFF） | 改密後重建容器 |
注意！表格底色與圖5-1的對應是圖5-1！不是5-1啦同學們，5-2沒紅色
一個已知的靜默丟失。主機 B 每小時整點過後的 log 輪替是 copy + truncate，Vector 會短暫「停止監看 → 重新發現檔案」，這 3～4 秒內寫入的那幾行會被清掉。每小時固定一次、只影響那幾秒，實務上損失接近零，但它是「ClickHouse 也不是 100% 全量」的原因之一。
| 沒做的事 | 理由或現況 |
|---|---|
| 防禦端不帶本地保護清單 | 保護判定只在平台端做一次，避免兩份清單要同步而漂移 |
| CrowdSec 沒有 bouncer、其決策不進平台 | 本安裝包把 CrowdSec 當第二份決策落地點與 SSH 行為偵測；要讓它自己擋，讀者自行加 bouncer |
| Cloudflare 執行點未實作 | 指「把封鎖推到 Cloudflare IP List」這個落地點，需要帳戶層 API token；目前決策帶 cloudflare 執行點會回 not_configured。Cloudflare Tunnel 作為對外入口是建議做法且完整支援，兩件事不要混為一談 |
| HTTP 登入暴力破解沒有專責偵測 | CRS PL1 沒有速率規則；CrowdSec 需要 access log 解析器。平台端只能靠併案計數看出重複 |
| Vector 到 od-bridge 用靜態 token 而非 HMAC | Vector 0.41 的 http sink 先 batch 再編碼，VRL 算不出最終 body 的簽章；8500 另有來源管制 |
| 金鑰的 allowed_source_systems 未在收件時強制比對 | 已知未生效、優先度低；同企業多台防禦端之間採君子協定 |
| 事件從防禦端到平台沒有離線緩衝 | 平台不在時事件丟失，但 ClickHouse 有全量可回查；案件本來就不是全量 |
iThome鐵人賽
看影片追技術