同一批開源元件，單獨裝起來會怎麼反應？接上 BeakPlatform 之後多了什麼、沒有改變什麼？本篇先給一張總表，再用六個具體情境走一遍。
今天這篇很多要對照／比較的，我覺得製表是最直接的呈現，所以就簡化說明，都在表中。
有一些會特別呈現時段或階段，如果您是校長兼撞鐘的一個人的SOC，可以多了解無人時自動處置案件的做法。
WAF 擋不擋、Suricata 抓不抓，與平台無關。平台不會讓 CRS 多擋一種攻擊，也不會讓 ET 規則多抓一條。攻擊當下的即時阻擋 100% 由 WAF 自己完成，403 早在平台收到事件之前就回給攻擊者了。
平台改變的是「擋掉之後」與「沒擋到但看到了之後」：這些告警有沒有人負責、要不要進一步封鎖來源、封多久、由誰決定、怎麼解除、事後查不查得到。單獨使用時，這些問題的答案全部是「沒有」。
| 面向 | 系統預設（單獨使用各元件） | 與 BeakPlatform 整合後 |
|---|---|---|
| 攻擊當下 | WAF 回 403；Suricata 寫一行告警；CrowdSec 依情境計數 | 完全相同 |
| 告警去哪 | 躺在 audit.log、eve.json；EveBox／Grafana 可以看，但要有人去看 | 正規化為同一格式，篩過後推進平台成為案件；全量仍在 ClickHouse |
| 誰負責 | 沒有指派概念。log 沒有「這筆歸誰」 | 案件依角色進入資安人員的待辦；簽核授權依角色、單位與代理判定；二線可升級到資安主管 |
| 時限 | 無 | 高危 15 分鐘、中危 60 分鐘 SLA；團隊版逾時催辦再升級；單人版逾時自動處置 |
| 累犯 | WAF 與 Suricata 都無跨請求記憶；每次都當第一次 | 60 分鐘內同 IP 同規則併案並計數；24 小時內重複數與歷史封鎖次數進風險分數 |
| 封鎖來源 IP | CrowdSec 可以下決策，但本安裝包沒有 bouncer，決策不落地；nftables blocklist 是空的，沒有人會往裡面寫 | 人一鍵或流程自動寫決策 → od-bridge 5 秒內落地到 nftables blocklist、CrowdSec LAPI、EDL 檔 |
| 封鎖多久、怎麼解 | CrowdSec 預設 4 小時；手動 nft 加的元素若沒帶 timeout 就是永久，得有人記得去刪 | 每筆決策帶 TTL（1h／24h／7d 依流程）；kernel timeout 與平台 cron 雙層到期，到期自動產生 unblock 落地；可人工撤銷、可改判 |
| 誤封自家設備 | 沒有防護。反向代理後面的偵測器看到的來源常是代理自己，照封 | 服務層保護清單：RFC1918、回送、CGNAT、平台可信代理等命中即拒寫；企業可加自訂與豁免；覆寫要留痕 |
| 給外部防火牆用 | 無 | 兩份 EDL：防禦端 :8500/edl（只含標了 edl 執行點的決策）與平台端每企業一份（該企業所有有效封鎖）。純 IP 一行一個，防火牆定期抓 |
| 通知 | 無（Grafana 可另設 alert） | 流程內建緊急廣播；可接 Email／Telegram 節點；封鎖完成通報、SLA 催辦、夜間自動處置通報 |
| 跨系統關聯 | 要自己在 ClickHouse 或 EveBox 裡用 IP 查 | 案件頁「跨系統關聯」分頁即時查 ClickHouse，列出同一 IP 在時間窗內被各系統各自看到的紀錄 |
| 稽核與證據 | log 輪替後就沒了；誰做過什麼沒有紀錄 | 案件、簽核歷程（含以誰的身分、代理誰）、決策、執行結果、覆寫痕跡全部落 DB；原始事件整包保留 |
| 多租戶 | 不適用，一台一套 | 每個企業各自的金鑰、路由、案件、決策、EDL；防禦端每家一台，租戶歸屬取自驗簽後的金鑰 |
| 事件量控制 | log 有多少寫多少；EveBox 靠人翻 | Vector 三道閘門在源頭壓量；平台再併案。代價是平台上的數字不代表攻擊總量（第 5 篇） |
| 誰被平台入侵影響 | 不適用 | 決策是防禦端拉的，平台不能主動對防禦端下指令；狀態流轉受限，執行端無法偽造 expired；保護清單在平台端，流程怎麼寫都繞不過 |
| - | 預設 | 整合後 |
|---|---|---|
| 即時 | WAF 403 | WAF 403 |
| 之後 | audit.log 一行，一小時後輪替 | 案件 OD-…，攻擊者 IP 是 CF-Connecting-IP（因為直連 WAF 的是可信的 cloudflared），國別一併帶入。SOC 在處置中心看到 payload、規則、UA；按「封鎖攻擊來源」後 5 秒內落地，TTL 1 小時 |
| 封鎖效果 | — | nftables 只擋該 IP 直連主機 B 的封包；經 Cloudflare 進來的請求封包來源是 Cloudflare，nftables 不會擋，仍由 WAF 逐請求擋。要在邊界擋掉，得讓外部防火牆抓 EDL，或未來實作 Cloudflare 執行點 |
| - | 預設 | 整合後 |
|---|---|---|
| 即時 | WAF 擋掉命中 913／920／930 的那些，其餘（存在的路徑）放行到後端 | 相同 |
| 之後 | audit.log 幾百行；放行的那些到後端時 Suricata 可能另有 ET SCAN／WEB_SERVER 告警 | Vector 封頂：同 IP 同規則 5 分鐘只放 5 筆、全域每分鐘 8 筆；平台再把同 IP 同規則併成一案。SOC 看到的是「一個 IP、幾條規則、事件數」而不是三百張單。ClickHouse 仍有全部 300 筆可查 |
| 差異重點 | 人翻 log 才知道是同一個人 | 風險分數因 24 小時內重複數加成而上升，建議處置變 block |
| - | 預設 | 整合後 |
|---|---|---|
| 即時 | WAF 對每個請求回 502 | 相同 |
| 之後 | audit.log 記下 5xx 交易（RelevantOnly 包含 5xx） | 建案，但沒有規則編號、actor 是正常訪客。這是刻意保留的：後端異常也是事件，可用性也是 C.I.A. 的一環。量由封頂控制，SOC 看到的是「很多不同 IP 對同一 host 的 502」 |
| 注意 | — | 這種案件不該封 IP，訪客是無辜的。單人版的自動封鎖條件要求 severity ≥ 4，5xx 事件的嚴重度來自 ModSecurity 等級對映，通常到不了門檻 |
| - | 預設 | 整合後 |
|---|---|---|
| 即時 | sshd 逐次拒絕；開了 --ssh-guard 的話 nftables 直接 drop 非白名單來源 | 相同 |
| 偵測 | CrowdSec ssh-bf 情境命中，LAPI 產生一筆 ban；沒有 bouncer，不落地。Suricata 可能有 ET SCAN SSH 告警 | Suricata 那條告警若通過 Vector 篩選（來源是公網、嚴重度 ≥ 2）會進平台建案；CrowdSec 的決策不會進平台（Vector 不讀 CrowdSec） |
| 差異重點 | 走 tunnel 部署時攻擊者根本碰不到主機 B 的 22 埠，這個情境只在內網或主機 B 有公網 IP 時成立 | 同左；整合沒有補上「CrowdSec 決策進平台」這條線，這是目前的缺口 |
| - | 預設 | 整合後 |
|---|---|---|
| 第一道 | nftables ingest_guard_forward：來源不在平台主機與 ADMIN_IPS 內 → drop，連 WAF 都到不了 | 同左 |
| 第二道（來源在白名單內時） | WAF 正常處理；Suricata 的 XFF 覆寫會把 src_ip 換成標頭裡的第三方 IP（Suricata 沒有「信任代理」概念） | Vector 對 WAF 事件比對 client_ip 是否為可信直連來源（只有 cloudflared 的 172.18.0.250）；不是，就「誰打的記誰」，第三方 IP 不會被歸因。Suricata 那條線 Vector 補不了（eve.json 已無原始來源），所以 8080 的來源管制是這條線的唯一防線；即使歸因錯了，保護清單也擋得住封到內網，但擋不住封到外部關鍵服務 |
| - | 預設 | 整合後（小企業單人版流程） |
|---|---|---|
| 即時 | WAF 403（如果是 WAF 抓到的） | 相同 |
| 之後 | 沒有人看，也沒有東西會做任何事 | 分流：severity ≥ 4 且 actor 是公網 IP → 判斷非上班時段 → 立即寫 block 決策 TTL 24 小時 → 落地 → 發「待複核」提示。若 actor 是內網 IP 或缺 IP → 改走人工，不自動處置 |
| 早上 | — | 複核任務在待辦：確認是攻擊 → 延長到 7 天；誤判 → 立即解除；不確定 → 什麼都不做，24 小時後自動解封 |
| 週末 | — | 時間變數沒有星期幾，週六日會被判成上班時段；靠「上班時段 30 分鐘無人處理也自動封鎖」補上 |
| 代價 | 說明 |
|---|---|
| 多一台主機與一條依賴 | 平台掛了，防禦端照常擋（WAF 與 nftables 現有元素不受影響），但新決策不會產生、到期的 unblock 不會產生。kernel timeout 仍會自己剔除，所以最壞情況是「封鎖只會少不會多」 |
| 平台上的數字不是全量 | Vector 封頂是丟棄。要回答「今天被打幾次」一律查 ClickHouse，不要看案件數 |
| 自動處置需要人設定邊界 | 保護清單、豁免、TTL、上班時段（UTC）都是設定值，第一次導入要逐一確認，尤其時區 |
| 需要企業與角色 | 平台側必須另建一家企業（不能用系統預設企業）、至少一位持 SECURITY_STAFF 角色的成員、一條路由規則、一個已發行的流程，缺一件事件就進不來，症狀是處置中心永遠是 0 |
iThome鐵人賽
看影片追技術