在這個開源專案與資訊都唾手可得的時代，選擇太多反而成了阻礙。光是「選」就是一門課題：怎麼選才對？選錯的代價負擔得起嗎？大家都在用的就一定對嗎？說起來，愈紅的專案，好像也愈容易上資安新聞。

使用開源資安專案的資安人員，心力應該放在「資安」本身，而不是開源系統的安裝、維護與整合。這個系列用我寫的工具一鍵安裝、裝完立即可用，接著直接從操作、調整參數到修改程式，實際體會這些資安系統如何搭配，避免光是安裝就卡關，消磨了學習的意願。

本文介紹的 Integrated-WAF（以下簡稱防禦主機 B）整合了六套開源系統，再由自寫的 od-bridge 串接 BeakPlatform，往後可以延伸出自訂的應用：報表、SOC、案件分析、AI 處理等自動化後續流程。

這是由六套開源專案安裝在同一台ubuntu 24.x為基底，我在這台只撰寫整合工具od-bridge，一切榮耀都歸原作者(鍋也是)，我只是站在巨人的肩膀寫這篇。

六套核心系統各自都能偵測、判斷、儲存或處理事件：

就算只有這一台，能做到什麼

od-bridge 與 BeakPlatform 負責的是「有人簽核、可追蹤的後續處置」。但在那之前，防禦主機 B 本身就是一條完整的防線。以下能力都在這台主機內部完成，不依賴任何外部系統。

一、入口先收斂：不該被碰到的，一律碰不到

對外公開時，流量經由 Cloudflare Tunnel 進來。cloudflared 是由主機 B 主動向外建立連線，因此這台主機不需要在路由器上開任何入站埠，攻擊者從 Internet 掃描也找不到它的真實位址。

主機上的 nftables 另外做了三件事：

• 來源管制：WAF 直連埠、Vector 事件注入口、od-bridge 與所有管理介面（Grafana、EveBox、Portainer），只放行指定的管理來源。能直連 WAF 的人可以偽造攻擊者 IP，能碰到注入口的人可以灌假事件，所以這些入口本來就不該對外。
• 自鎖保險：管理來源放在 allowlist，永遠排在封鎖規則之前，不會因為一筆錯誤的封鎖把自己鎖在門外。
• 帶時效的封鎖集合：blocklist 支援 timeout，封鎖時間到自動解除。沒有平台時也能手動加入，例如封鎖某個 IP 一小時。

二、應用層即時阻擋：攻擊在到達網站之前就結束

WAF 以反向代理的形式擋在被保護網站前面，所有請求都先經過 OWASP CRS 的規則比對。CRS 採用「異常計分」：一個請求命中多條可疑特徵時分數會累加，超過門檻就直接回 403，請求根本不會送到後端網站。SQL Injection、XSS、路徑穿越、指令注入、常見掃描工具的特徵，都在預設規則的涵蓋範圍內。

實務上最常遇到的問題是誤判。主機 B 保留了兩個調整手段：先把規則引擎切到 DetectionOnly 觀察模式，只記錄不阻擋，確認誤判的樣態後，再針對特定路徑放寬規則，最後切回阻擋模式。這正是這個系列想讓讀者親手操作的部分。

三、網路層偵測：看見 WAF 看不到的東西

WAF 只看得懂 HTTP。Suricata 則以旁路方式監聽網卡，搭配每日更新的 Emerging Threats Open 規則集，辨識各種網路層的可疑行為，例如針對其他服務的掃描、已知惡意程式的通訊特徵、可疑的 DNS 查詢。安裝時已經關閉網卡的封包合併卸載，避免 Suricata 收到被截斷的封包；也預先停用了幾條誤判率極高的規則，免得告警一開始就被雜訊淹沒。

CrowdSec 則從系統日誌判斷行為，例如 SSH 的暴力破解嘗試，並把判斷結果保存為決策。

四、事件留得住、查得到

WAF 與 Suricata 的告警格式完全不同。Vector 把兩者轉成同一套 OCSF 結構，並處理攻擊者 IP 的歸因：只有來自 cloudflared 的轉送標頭才被採信，其他來源一律「誰連進來就記誰」，避免攻擊者自帶標頭嫁禍給別人。

正規化後的事件全量寫入 ClickHouse，保留 90 天。可以直接用 SQL 查詢「過去一週哪個 IP 命中最多規則」，或透過已接好 ClickHouse 資料來源的 Grafana 自建儀表板；Suricata 的原始告警則可以用 EveBox 逐筆瀏覽。

單機的邊界

一台主機能擋、能看、能記，但有兩件事它自己做不到：

• 偵測不會自動變成封鎖。Suricata 是 IDS，只告警不阻擋；CrowdSec 的決策在這套配置中也沒有安裝 bouncer 落地到防火牆。nftables 的封鎖集合要自動填入，需要平台端核可的決策經由 od-bridge 送回來。
• 沒有「人」的判斷與紀錄。一筆告警是誤判還是真實攻擊、該封鎖多久、誰核可的，這些都需要案件流程來承接。

這兩個缺口，正是 od-bridge 與 BeakPlatform 要補上的部分：主機 B 送出經過封頂的事件，平台建立資安案件、交由資安人員簽核，核可的封鎖決策再回到主機 B，同時落地到 nftables、CrowdSec 與 EDL 黑名單。這條完整的循環，留待後續篇章說明。