主機 B 上有五個會「看」流量的東西：nftables、WAF、Suricata、CrowdSec、Vector。它們看的層次不同、判斷方式不同、能做的反應也不同。本篇逐一說明，最後用一張矩陣對照「哪種行為由誰負責」。
WAF 是唯一會讀完整 HTTP 內容並即時阻擋的元件。它以 OWASP CRS 的規則對每個請求打分數：每條命中的規則依嚴重度加 2～5 分（CRITICAL 5、ERROR 4、WARNING 3、NOTICE 2），請求階段總分達 ANOMALY_INBOUND=5 就回 403，回應階段達 ANOMALY_OUTBOUND=4 就攔下回應。安裝包用 Paranoia Level 1（最保守、誤判最少的一級），並在覆寫檔補上 REST 常用的 PUT / DELETE / PATCH / OPTIONS 方法白名單，否則每個非 GET/POST 的 API 呼叫都會被當 CRITICAL 擋掉。同一個覆寫檔也是路徑層規則排除的位置（總覽第三節第 8 條）：對特定 API 路徑移除某些規則的檢查目標，其餘照常檢查。
| CRS 規則群 | 抓什麼 | 典型例子 | 階段 |
|---|---|---|---|
| 911 | HTTP 方法 | 不在白名單內的方法（TRACE、TRACK、自訂方法） | 請求 |
| 913 | 掃描器偵測 | sqlmap、nikto、nmap 等工具的 User-Agent 與指紋；已知的掃描路徑 | 請求 |
| 920 | 協定強制 | 缺 Host、Content-Length 不合法、編碼錯誤、畸形 URL、不允許的副檔名與 Content-Type | 請求 |
| 921 | 協定攻擊 | HTTP request smuggling、response splitting、標頭注入 | 請求 |
| 922 | multipart 攻擊 | 檔案上傳邊界異常 | 請求 |
| 930 / 931 | 本機 / 遠端檔案引入 | ../../etc/passwd、?page=http://evil/shell.txt | 請求 |
| 932 | 遠端命令執行 | shell 命令注入、Shellshock、Windows 命令 | 請求 |
| 933 / 934 / 944 | PHP、Node.js、Java 注入 | PHP 函式名、原型污染、Java 反序列化與 Log4Shell 類字串 | 請求 |
| 941 | 跨站腳本 XSS | 、事件屬性、libinjection XSS 偵測 | 請求 |
| 942 | SQL injection | ' OR 1=1--、UNION SELECT、libinjection SQLi 偵測、盲注函式 | 請求 |
| 943 | Session fixation | 從參數塞 session id | 請求 |
| 950～954 | 回應外洩 | SQL 錯誤訊息、PHP / Java 堆疊、原始碼、目錄列表 | 回應 |
| 949 / 959 / 980 | 評分與攔截 | 把上面累計的分數換成 403 或攔截回應，並記一筆關聯摘要 | 兩者 |
WAF 的紀錄：audit engine 設成 RelevantOnly，只有「有規則命中」或「回應碼是 4xx／5xx」的交易才寫一行 JSON 到 audit.log。正常流量不留痕跡，所以這份 log 天生就是告警清單，不是存取紀錄。後端掛掉時 WAF 回 502，也會被記下來，這是刻意的：後端異常本身就是事件（維運可用性也是 C.I.A. 的一環），量由後面的封頂規則控制。
WAF 沒有記憶。它一次判斷一個交易，不會因為「這個 IP 剛才已經被擋 50 次」而改變對第 51 次的態度。「累犯要不要封 IP」這個判斷，單獨的 WAF 做不到，正是平台介入的地方。
Suricata 以 af-packet 被動抓實體網卡（NODE_IFACE）上的所有封包，用 Emerging Threats Open 規則集（安裝時下載，約四萬條，每日可更新）做特徵比對，並解碼 HTTP、DNS、TLS 三種應用層協定。inline: no，永遠不能丟包。安裝包會用 ethtool 關掉網卡的 GRO / LRO / TSO / GSO 卸載，否則抓到的是被合併過的大封包，規則比對會失準。
| ET 規則類別 | 抓什麼 | 在本架構下什麼時候會看到 |
|---|---|---|
| ET SCAN | 掃描器指紋、埠掃描、目錄暴力猜測 | 只在 $EXTERNAL_NET → $HOME_NET 方向觸發。HOME_NET 預設涵蓋整個 RFC1918，所以內網對內網的掃描不會觸發；走 tunnel 時攻擊者根本碰不到主機 B 的埠 |
| ET WEB_SERVER / WEB_SPECIFIC_APPS | 對 web 伺服器與特定應用（WordPress、phpMyAdmin、各種 CMS）的攻擊特徵 | WAF 放行後轉往後端的那一跳；與 CRS 部分重疊，但特定 CVE 的覆蓋比 CRS 廣 |
| ET EXPLOIT | 已知漏洞的利用碼 | 同上 |
| ET MALWARE / ET CNC | 惡意程式回連、C2 通訊、已知惡意網域 | 主機 B 或容器自己往外連時；這是「主機被入侵」的訊號，方向是出站 |
| ET USER_AGENTS / ET HUNTING | 可疑 User-Agent（例：帶 .exe 的 UA）、狩獵型規則 | 出站 HTTP 常見；驗證管線最簡單的方式就是在主機 B 上用可疑 UA 對外 curl 一次 |
| ET POLICY / ET INFO | 不一定是攻擊但值得知道的事：明文 Basic Auth、可疑 DNS 查詢、雲端服務存取 | 大量出現在正常維運中。用 URL 帶密碼查 ClickHouse 會觸發「Outgoing Basic Auth」；cloudflared 每次重連查的 tunnel 網域曾觸發 sid 2047122，已在 disable.conf 停用 |
| ET DOS | 已知 DoS 工具特徵 | 特徵式，不是流量統計式 |
| ET ATTACK_RESPONSE | 攻擊成功的回應特徵（例：回應本文出現 uid=0(root)、目錄列表） | 後端回應經實體網卡回來時；這是 WAF 回應檢查之外的第二雙眼睛 |
Suricata 的嚴重度只有 1（高）、2（中）、3（低）、4（資訊），Vector 會對映成 OCSF 的 4、3、2、1；大部分 ET INFO 與 POLICY 是 3（低），對映後是 2，不會被「只丟 severity 1」的過濾規則丟掉，這也是為什麼 INFO 類規則要靠 disable.conf 個別停用。另有三條 TCP stream 重組的 sanity-check 規則（2210020、2210029、2210045）對正常流量誤判率極高，在本文的實測環境曾於三小時內產生四千多筆告警（這是本地實測數字，不是 Suricata 或 ET 官方統計），出廠即停用。
CrowdSec 的判斷單位不是「一個請求」而是「一段時間內同一來源做了幾次」。它用 leaky bucket 情境（scenario）計數，例如 ssh-bf：同一 IP 在短時間內多次 SSH 認證失敗就產生一筆決策。安裝包載入的 collection 是 linux、sshd、http-cve、base-http-scenarios，採集來源是 sshd 的 journal 與 Suricata 的 eve.json。
CrowdSec 在本安裝包裡是輔助角色，有兩件事要先知道。第一，docker-compose.yml 沒有任何 bouncer，CrowdSec 自己產生的決策只會存在 LAPI 裡（cscli decisions list 看得到），不會被落地到防火牆。第二，載入的 collection 沒有 Suricata 專用的解析器，eve.json 雖然被採集，HTTP 類情境需要的是 web 伺服器 access log 格式，所以實際能穩定產出情境命中的是 sshd 這一條。它在架構裡真正的用途是平台決策的第二份落地點：od-bridge 會把平台核可的封鎖同時寫進 LAPI，未來要接 bouncer（例如放在另一台機器上的 firewall bouncer）時，那台不需要認識 BeakPlatform，只要跟 LAPI 拿決策就好。
Vector 不偵測任何東西，但它決定「哪些告警會離開主機 B」，這對後面的案件量與平台負載影響最大。它做四件事，順序固定：
兩路輸出：ClickHouse 拿第 1 步之後的全量（批次 500 筆或 5 秒），od-bridge 只拿走完四步的事件，一筆一送。所以「平台上有幾張案件」永遠不等於「發生了幾次攻擊」，要看攻擊面統計得查 ClickHouse，這點大約再三篇就會談。
「主責」表示這種行為主要靠該系統抓到；「輔助」表示會看到但不是設計目的或覆蓋有限；灰色表示看不到或不處理。
表中的缺口是範圍取捨，不是做不到。本次發表聚焦在「單一請求層級的偵測 → 案件 → 封鎖落地」這一圈，所以 HTTP 登入暴力破解、跨請求的速率統計這類需要長時間累積的偵測沒有納入。在企業環境裡，長期的機械式攻擊（掃描器、撞庫、爬蟲）其實不必靠 WAF 逐請求硬擋：從 ClickHouse 或 WAF log 做統計，找出重複來源後直接封鎖，一來消耗對方的 IP 資源，二來減輕 WAF 負擔，因為防火牆通常擋在 WAF 前面，在那裡丟掉的封包根本不會進到規則引擎。本架構已備好這條路要用的材料：ClickHouse 的全量事件、平台的併案計數與風險分數、以及能餵給邊界防火牆的 EDL。
iThome鐵人賽
看影片追技術