雅寶社區 · 頂客論壇 (AHPAL.COM)

📊 軟體評測

Wazuh 與 Suricata，自架 IDS/IPS 的偵測率與資源佔用

發表時間：2026 年 11 月 14 日 | 更新日期：2026 年 11 月 14 日 | 編輯：雅寶社區編輯團隊

因此，本文的比較重點不會停留在「誰比較強」，而是放在「在有限資源下，兩者的偵測覆蓋率與資源效率如何取捨」，以及「整合後能否用可接受的成本補齊盲區」。這樣的比較角度，對實際要動手自架的人才有意義。

二、測試環境與方法論

為了讓數據具備可比性，本次測試將 Wazuh 與 Suricata 部署在兩台規格相近的獨立主機上，避免資源互相干擾。網路流量透过交換器鏡像埠複製到 Suricata 主機，Wazuh 則以 Agent 模式監控測試區內的 15 台虛擬主機。測試期為 14 天，分為「基準期」與「攻擊期」兩階段：基準期只跑正常業務流量，用來觀察誤報；攻擊期則依序注入預先設計的攻擊樣本。

硬體與軟體組態

項目

Suricata 主機

Wazuh 主機

CPU

8 vCPU（Xeon Gold 等級）

8 vCPU（同型號）

記憶體

16 GB

32 GB

儲存

NVMe SSD 500 GB

NVMe SSD 1 TB

網路

雙埠 10GbE，鏡像流量約 400 Mbps，峰值 900 Mbps

1GbE

軟體版本

Suricata 7.0.3，ET Open 規則約 42,000 條，啟用約 28,000 條

Wazuh 4.8.0，Manager、Indexer、Dashboard 同機部署，15 個 Agent

作業系統

Ubuntu Server 22.04 LTS

Ubuntu Server 22.04 LTS

Suricata 採用 AF_PACKET 模式搭配多 worker 執行緒，關閉不需要的協議解析器以降低負載；Wazuh 則使用官方 all-in-one 安裝，Indexer 採單節點配置，保留 30 天索引。兩台主機皆關閉不必要服務，並使用相同的時間同步來源，確保事件時間軸可以對齊。

測試攻擊樣本與評分方式

攻擊樣本涵蓋網路層與主機層兩大類，每一類都設計多個變體，避免只測單一工具就能命中的情況。網路層包含：Nmap 全埠掃描與隱蔽掃描、SSH 與 FTP 暴力破解、Nikto 網頁弱點掃描、SQL injection 與 XSS 嘗試、模擬 C2 心跳的週期性外連，以及帶有已知惡意雜湊的檔案下載。主機層則包含：網站目錄檔案竄改、新增可疑 cron 排程、Linux 本地提權腳本執行、異常程序啟動、系統帳號變更，以及登入失敗次數異常。

評分方式採用入侵偵測領域常用的 TP、FP、FN 架構。True Positive 是指攻擊實際發生且工具產生告警；False Negative 是攻擊發生但沒有告警；False Positive 則是沒有攻擊卻告警。每個樣本至少重複三次，由人工複核告警內容與時間戳，避免只看告警數量而忽略告警品質。偵測率以 TP 除以 TP 加 FN 計算，誤報則以基準期的每日平均告警數為基準。

資源佔用的量測方式

資源量測分為待機與負載兩種情境。待機情境下，系統只處理正常流量與例行日誌，連續觀察 72 小時取平均值；負載情境則在攻擊期與流量峰值時取樣，記錄 CPU 使用率、記憶體 RSS、磁碟寫入量與網路延遲。Suricata 另外記錄丟包率，因為丟包會直接影響偵測率，是評估 NIDS 效能時不能忽略的指標。Wazuh 則記錄 Manager 的 EPS 處理量與 Indexer 的 JVM 記憶體壓力。

三、偵測率實測對比

先說結論：在這次測試中，Suricata 在網路層攻擊的偵測率明顯領先，Wazuh 則在主機層攻擊幾乎全面勝出。兩者的偵測率差距並不是「誰比較好」的問題，而是「設計目標不同」的必然結果。以下分別就網路層與主機層說明實測結果，並整理綜合表格與誤報討論。

網路層攻擊：掃描、暴力破解、C2 通訊

Suricata 面對連接埠掃描的表現相當穩定。Nmap 的 SYN 掃描、FIN 掃描與 NULL 掃描都能被 ET Open 規則中的掃描偵測簽章命中，整體偵測率約 96%。少數漏網的情況是掃描速度極慢、分散在多個來源 IP 的低速掃描，這類行為需要靠流量基線或關聯規則補強，單靠簽章不容易抓到。Wazuh 在這一項的偵測率約 35%，而且幾乎都是間接命中：例如防火牆或系統日誌留下大量連線拒絕紀錄，Wazuh 透過頻率規則產生告警。如果沒有這些日誌來源，Wazuh 對純網路掃描幾乎無感。

SSH 暴力破解是兩者重疊度較高的項目。Suricata 有針對 SSH 登入失敗的閾值規則，偵測率約 88%，但對於慢速、低頻率的密碼噴灑攻擊較不敏感。Wazuh 直接解析 auth.log 中的 failed password 事件，配合頻率與時間窗規則，偵測率約 97%，而且能直接指出被嘗試的帳號與來源 IP。這說明一件事：當攻擊行為會在主機留下日誌時，主機型工具的偵測精度往往更高。

網頁攻擊方面，Suricata 對 SQL injection、XSS、路徑穿越等常見樣本的偵測率約 84%，ET Open 規則對這類特徵的覆蓋相當完整。Wazuh 若沒有額外解析網頁伺服器日誌，偵測率只有約 62%，而且多半是從 HTTP 狀態碼或異常請求頻率推斷，較難判斷攻擊是否成功。C2 心跳偵測則是 Suricata 略勝一籌，約 72%，主要靠已知惡意域名、TLS 憑證特徵與週期性連線規則；Wazuh 約 55%，需要依賴 DNS 日誌或代理伺服器日誌才能補強。

主機層攻擊：檔案竄改、提權、惡意程序

來到主機層，情勢完全逆轉。檔案完整性監控是 Wazuh 的招牌功能，測試中對網站目錄的檔案竄改、新增 cron 排程、SSH 設定變更等樣本，偵測率達到 100%。只要預先將目錄納入監控清單，任何內容或權限變更都會產生告警，並附帶變更前後的雜湊比對。Suricata 在這一項的偵測率為 0%，因為檔案竄改不一定會產生網路流量，即使有，封包層也看不到檔案內容的變化。

本地提權行為的測試結果也值得注意。Wazuh 透過 rootcheck、程序監控與日誌規則，對常見提權腳本與異常 sudo 行為的偵測率約 78%，漏掉的部分主要是自訂編譯的提權程式，因為沒有對應的規則特徵。Suricata 對提權行為的偵測率僅約 12%，只有在提權後產生明顯的網路外連時才有機會命中。惡意程式落地的情況類似：Wazuh 透過 FIM 與雜湊比對，偵測率約 85%；Suricata 若啟用檔案提取與雜湊比對，偵測率約 25%，否則幾乎無法察覺。

系統帳號變更與登入行為異常，Wazuh 的表現也明顯較好。它能直接解析 /etc/passwd 變更、群組成員異動、新增 sudo 權限等事件，並對照 MITRE ATT&CK 對應的技術編號。這對於需要做事件調查與合規報表的環境來說，價值相當高。

偵測率總表與誤報率討論

攻擊類型

Suricata 偵測率

Wazuh 偵測率

備註

連接埠掃描

96%

35%

Wazuh 需有防火牆或系統日誌來源

SSH 暴力破解

88%

97%

Wazuh 可直接指出帳號與來源

網頁 SQLi／XSS

84%

62%

Wazuh 需額外解析網頁日誌

C2 心跳連線

72%

55%

兩者都需情報或規則補強

檔案竄改

0%

100%

Suricata 無法看到檔案內容變化

本地提權

12%

78%

Suricata 僅在被動外連時可能命中

惡意程式落地

25%

85%

Suricata 需啟用檔案提取與雜湊比對

帳號與權限變更

5%

92%

Wazuh 可對照 ATT&CK 技術

誤報方面，Suricata 在基準期的每日平均告警約 120 筆，經過關閉雜訊規則、設定 HOME_NET 與調整閾值後，降至每日約 15 筆。ET Open 規則集的誤報主要來自幾個面向：內部弱掃工具被誤判為攻擊、CDN 或雲端服務的異常路徑、以及部分老舊規則對現代協議解析的誤解。Wazuh 基準期每日平均告警約 40 筆，調校後降至約 8 筆，誤報來源多是套件更新造成的檔案變更，以及正常維運腳本觸發的程序告警。

這裡要強調一個觀念：偵測率不是單一數字，而是「在什麼規則集、什麼調校程度、什麼流量特性下」的結果。把 Suricata 的規則全開而不調校，帳面偵測率可能更高，但誤報會多到讓告警失去意義；把 Wazuh 的 FIM 掃描頻率拉到最高，檔案變更無所遁形，但磁碟 I/O 與 CPU 成本也會跟著上升。真正該追求的是「在可接受的誤報與資源成本下，覆蓋最重要的攻擊路徑」。

四、資源佔用實測

資源佔用是自架環境最現實的門檻。很多評測只講功能不講成本，結果讀者照著裝才發現記憶體不夠、磁碟兩週就滿。以下數據來自本次測試環境，實際數值會隨流量、規則數、日誌量與保留策略而有明顯差異，請當作量級參考而非絕對標準。

CPU 與記憶體

Suricata 在待機狀態下（約 400 Mbps 正常流量）CPU 使用率約 0.8 至 1.2 核，記憶體 RSS 約 1.8 GB，其中大部分是規則集載入後佔用的記憶體。當流量峰值達到 900 Mbps 且攻擊樣本注入時，CPU 上升到 3.5 至 4.5 核，記憶體約 2.6 GB。八個 vCPU 的配置在這次測試中仍有餘裕，但若規則數再增加、或啟用更多協議解析與檔案提取，CPU 會是第一個瓶頸。Suricata 的多執行緒架構讓它可以透過增加 worker 數來橫向吃滿 CPU，但也意味著它對核心數相當敏感。

Wazuh 的資源結構比較複雜，因為它是三個元件同機部署。待機狀態下，Manager 約佔 0.3 核、Indexer 約佔 0.5 至 0.8 核，整體 CPU 約 0.8 至 1.1 核；記憶體方面，Manager 約 1.5 GB，Indexer 的 JVM 依設定約 4 至 6 GB，加上作業系統與快取，總記憶體使用約 6 至 8 GB。15 個 Agent 的日誌量約在 200 至 500 EPS 之間，Manager 處理起來相當輕鬆。真正的資源大戶是 Indexer，尤其在告警量暴增或執行大量聚合查詢時，JVM 記憶體壓力會明顯上升。

磁碟 I/O 與儲存成長

Suricata 的磁碟寫入主要來自 EVE JSON 日誌。在本次流量條件下，每日約產生 2 至 6 GB 的 EVE 日誌，若同時啟用 PCAP 錄製，成長速度會數倍增加。建議將 EVE 輸出精簡，只保留必要事件類型，並搭配 logrotate 或外部輪替機制，避免磁碟被寫滿。Suricata 本身不太需要資料庫，儲存壓力相對單純。

Wazuh 的儲存成長則來自 Indexer 中的事件索引。15 個 Agent 加上系統與安全事件，每日索引量約 3 至 8 GB，若保留 30 天，大約需要 100 至 250 GB 的磁碟空間，還要加上 OpenSearch 的副本與合併暫存空間。這次測試使用 1 TB NVMe，30 天保留策略下仍有餘裕，但若 Agent 數量增加到 50 台以上，或開啟更細緻的 FIM 與程序監控，磁碟成長會明顯加快。建議一開始就設定好索引生命週期管理（ILM），區分熱、溫、冷階段，並定期清理不必要的事件類型。

網路吞吐與延遲影響

Suricata 以旁路模式部署時，對網路延遲幾乎沒有影響，只有鏡像埠與交換器的複製成本。若切換到 inline IPS 模式，則會引入額外的處理延遲。本次測試在 inline 模式下量測，平均延遲增加約 0.1 至 0.2 毫秒，對一般企業應用影響有限，但對高頻交易或極低延遲場景仍需謹慎評估。丟包率在 900 Mbps 峰值時約 0.3%，調校 AF_PACKET 的 ring buffer 與 worker 配置後可壓到 0.1% 以下。丟包一旦發生，偵測率會直接下降，這是 NIDS 部署時最容易被忽略的隱形成本。

Wazuh 本身不處理網路封包，對網路吞吐沒有直接影響，但 Agent 與 Manager 之間的溝通會產生少量流量。15 個 Agent 的日常通訊量不大，對頻寬的影響可以忽略。需要注意的是，若 Agent 與 Manager 跨網段，或經過防火牆，連線中斷會導致日誌緩衝與重送，間接影響即時性。

資源佔用總表與規模建議

項目

Suricata（1Gbps 環境）

Wazuh（15 Agents）

待機 CPU

0.8–1.2 核

0.8–1.1 核

峰值 CPU

3.5–4.5 核

2–3 核

記憶體

1.8–2.6 GB

6–8 GB

每日磁碟成長

2–6 GB（EVE JSON）

3–8 GB（索引）

網路延遲影響

旁路 0 ms；inline 約 0.1–0.2 ms

無直接影響

建議最低配置

4 核 / 8 GB / 500 GB SSD

8 核 / 16 GB / 500 GB SSD

若以「小規模自架、50 台以內主機、1Gbps 以下流量」為目標，Suricata 用 4 核 8 GB 可以跑得不錯，Wazuh 則建議至少 8 核 16 GB，並把 Indexer 獨立出來會更穩定。若兩者要整合在同一台機器，建議規格拉到 8 核 32 GB 以上，並將 Indexer 的 JVM 記憶體上限設好，避免與 Suricata 的規則記憶體互相排擠。

五、兩者整合：Wazuh 加 Suricata 的互補架構

看完前面的數據，應該不難理解為什麼多數進階自架環境會選擇整合而非二選一。Suricata 補上了 Wazuh 看不到的網路視角，Wazuh 補上了 Suricata 看不到的主機視角，兩者的告警還能互相關聯，形成更完整的事件脈絡。這一節說明整合架構、實作要點與常見的坑。

架構設計與資料流

最常見的整合方式是：Suricata 部署在網路鏡像節點，將 EVE JSON 輸出到本機目錄；同一台主機（或鄰近的日誌收集主機）安裝 Wazuh Agent，透過 logcollector 的 json 格式讀取 EVE 日誌，再送往 Wazuh Manager。Manager 端的解碼器會解析 Suricata 的事件欄位，規則則負責將重要告警升級為資安事件。這樣做的優點是部署簡單，不需要修改 Suricata 的輸出邏輯，也不會增加額外的中介服務。

另一種做法是讓 Wazuh Agent 直接安裝在 Suricata 主機上，同時監控 Suricata 的設定檔與規則檔完整性。這樣一來，如果有人竄改 Suricata 規則以規避偵測，Wazuh 的 FIM 會立刻發現。這種「監控監控者」的設計，在實務上相當有價值，因為攻擊者若取得主機權限，第一件事往往就是關閉或修改 IDS 規則。

資料流的方向可以整理為：封包 → Suricata → EVE JSON → Wazuh Agent → Wazuh Manager → Indexer → Dashboard。若規模較大，可以將 Manager 與 Indexer 分離，並使用多個 Agent 分散收集，避免單點瓶頸。

實作要點與常見坑

第一個要點是時間同步。Suricata 的告警時間與 Wazuh 的主機日誌時間必須一致，否則關聯分析會對不上。建議全部主機使用同一個 NTP 來源，並在 Wazuh 規則中保留原始時間戳欄位。第二個要點是 EVE 輸出精簡。Suricata 預設會輸出大量事件類型，若全部送往 Wazuh，EPS 會暴增，Indexer 也會迅速膨脹。建議只保留 alert、dns、tls、http 等與偵測相關的事件，必要時再開啟 flow 或 fileinfo。

第三個要點是規則映射。Wazuh 內建部分 Suricata 解碼器與規則，但不同版本的欄位名稱可能略有差異，建議先在測試環境確認 EVE JSON 的實際結構，再調整解碼器。第四個要點是避免告警重複。同一攻擊可能同時觸發 Suricata 網路告警與 Wazuh 主機告警，這時應該利用 Wazuh 的規則關聯功能，將兩者合併為一個高階事件，而不是讓分析師看到兩筆獨立的告警。第五個要點是資源隔離。若 Suricata 與 Wazuh Agent 同機，建議設定 CPU affinity，避免 Suricata 的 worker 執行緒與 Agent 的日誌處理互相搶資源。

整合後的偵測率與成本變化

在本次測試中，將兩者整合後，整體攻擊樣本的加權偵測率從 Suricata 單獨的約 58%、Wazuh 單獨的約 72%，提升到約 91%。提升最明顯的是「網路加主機」的複合攻擊鏈，例如攻擊者先掃描連接埠、再嘗試 SSH 暴力破解、成功登入後竄改網站檔案。單一工具只能看到其中一段，整合後則能看到完整鏈條，並在 Wazuh 中呈現為一組相關事件。

成本方面，整合後的資源需求約為兩者相加再打八折，因為部分日誌與索引可以共用。以本次環境為例，若將 Suricata 與 Wazuh 整合到一台 8 核 32 GB 的主機，執行 1Gbps 以下流量與 15 個 Agent，整體 CPU 峰值約 5 至 6 核，記憶體約 12 至 14 GB，仍在可接受範圍。若流量或 Agent 數量再往上，建議拆分為網路監控與主機監控兩台，會比硬塞在一台更穩定。

六、調校與優化建議

無論選哪一套，預設值通常都不是最佳值。Suricata 的規則集與擷取參數、Wazuh 的解碼器與索引策略，都會直接影響偵測率與資源佔用。以下整理本次測試中效果最明顯的調校項目。

Suricata 規則集與效能調校

規則集方面，ET Open 適合預算有限的環境，但誤報較多，需要定期檢視與停用雜訊規則。若環境允許，ET Pro 的規則品質與更新頻率更好，對偵測率的提升相當有感。建議依照實際服務開啟規則類別，例如有對外網頁服務就保留 HTTP 相關規則，沒有 SMB 服務就關閉 SMB 規則，這樣可以同時降低誤報與 CPU 負載。

效能方面，AF_PACKET 的 ring buffer 與 worker 數量是關鍵。worker 數不宜超過實體核心數，否則 context switch 會抵銷多執行緒的效益。CPU affinity 可以將 Suricata 綁定到特定核心，避免與其他服務爭搶。HOME_NET 與 EXTERNAL_NET 的設定必須正確，否則大量內部流量會被誤判為外部攻擊。若流量較大，可以考慮關閉檔案提取與 PCAP 錄製，只保留必要的事件輸出。最後，定期更新規則並觀察丟包率，丟包率上升通常意味著效能已達瓶頸，需要調整硬體或擷取模式。

Wazuh 解碼器、規則與資源控制

Wazuh 的調校重點在於「減少雜訊」與「控制索引成長」。規則方面，建議先跑一段基準期，找出高頻且無害的告警，透過規則層級、頻率與忽略清單將其抑制。FIM 方面，不需要監控整個檔案系統，只需針對設定檔、網站目錄、系統二進位檔等關鍵路徑設定監控，並依重要性調整掃描頻率。程序監控與 rootcheck 也應依實際需求開啟，避免產生大量低價值事件。

資源控制方面，Indexer 的 JVM 記憶體應依照主機記憶體設定，一般建議不超過實體記憶體的 50%，並保留足夠空間給作業系統快取。索引生命週期管理要儘早設定，區分熱資料與冷資料，並定期刪除或歸檔舊索引。Manager 端則可調整 Agent 的緩衝區大小與批次傳送參數，避免日誌暴量時掉資料。若 Agent 數量較多，可以考慮部署多個 Manager 或使用叢集，分攤解碼與規則比對的負載。

七、選型建議：什麼情況該用哪一個

回到最初的問題：Wazuh 與 Suricata 到底該選哪一個？答案取決於你的環境特性與防禦目標。以下用表格整理常見場景，並在表格後補充說明。

使用場景

建議方案

理由

只有主機日誌與合規需求

Wazuh

日誌分析、FIM、SCA 與法規報表一次到位

需要網路層 IPS 主動阻擋

Suricata

inline 模式可丟棄惡意封包，Wazuh 不具備此能力

預算與機器資源有限，想最大化覆蓋

兩者整合

互補盲區，加權偵測率提升最明顯

10Gbps 以上高流量環境

Suricata（搭配 DPDK）＋ 獨立 Wazuh

避免資源互相排擠，網路與主機分開調校

以事件調查與 ATT&CK 對應為主

Wazuh

事件脈絡與技術編號對應較完整

以對外服務防護為主

Suricata 為主，Wazuh 為輔

網路攻擊面較大，需封包層偵測與阻擋

如果只能選一個，而環境以伺服器主機為主、對外流量不大，Wazuh 的整體價值通常較高，因為它同時涵蓋日誌、檔案、漏洞與合規，對日常維運的幫助更直接。如果環境是對外服務、流量較大、且需要主動阻擋，Suricata 會是較合理的起點。但只要你有一點餘裕，強烈建議兩者都上，因為它們的偵測盲區幾乎不重疊，整合後的效益遠大於各自單打獨鬥。

還有一個常被忽略的考量是「維運人力」。Suricata 的規則調校需要一定的網路與攻擊手法知識，Wazuh 的規則與解碼器調校則需要熟悉日誌格式與系統行為。兩者整合後，維運複雜度會上升，但若能建立標準作業流程與定期檢視機制，長期下來反而能減少重複排查的時間。

八、結論

這次實測再次驗證了一個老結論：Wazuh 與 Suricata 不是替代關係，而是互補關係。Suricata 在網路層的掃描、網頁攻擊與 C2 偵測上表現突出，資源佔用相對線性，適合部署在流量節點；Wazuh 在主機層的檔案竄改、提權、帳號變更與合規檢查上幾乎沒有對手，但需要較多的記憶體與磁碟資源，尤其是 Indexer 部分。

若以數字總結本次測試：Suricata 單獨的加權偵測率約 58%，Wazuh 單獨約 72%，兩者整合後約 91%。資源方面，Suricata 在 1Gbps 環境下約需 4 核 8 GB，Wazuh 在 15 個 Agent 下約需 8 核 16 GB，整合後建議 8 核 32 GB 起跳。這些數字會隨環境變動，但量級可以作為規劃參考。

自架 IDS/IPS 最迷人的地方，在於你可以完全掌控資料與規則，不必把流量交給第三方。但這也意味著調校與維運的責任在自己身上。與其追求帳面上最高的偵測率，不如先弄清楚自己的攻擊面在哪裡，再選擇對應的工具與規則。把 Wazuh 與 Suricata 放在正確的位置，讓它們各自發揮所長，會比單純比較「誰比較強」更有意義。

最後提醒，本文的測試數據來自特定硬體、特定流量與特定規則集，僅供參考。實際部署前，建議先在自己的環境跑一段基準期，觀察誤報與資源曲線，再逐步調整規則與保留策略。資安沒有一次到位的設定，只有持續調校的過程。

本文同步發表於雅寶社區 · 頂客論壇，歡迎在討論區分享你的自架經驗與調校參數。

🏠 返回首頁