前四天分別講了背景、網段、整體架構,還有追一筆事件的完整旅程。今天想往回補一塊細節:Wazuh 本身內部是怎麼分工的,以及我自己遇過的一次「不是規則問題、是容量問題」的插曲。

四個元件,各自負責什麼
Wazuh 官方文件把它拆成四塊:

Agent：裝在受監控主機上,負責採集。日誌與主機狀態從這裡開始。
Manager：核心處理端,做兩件事——decoder 把原始日誌解析成結構化欄位,rule 拿結構化欄位去比對規則,比對成功就產生一筆告警。
Indexer：負責儲存跟索引告警,底層是 OpenSearch。
Dashboard網頁介面,用來查看索引後的告警、規則命中狀況、agent 狀態,底層是 OpenSearch Dashboards。

這四塊裡,Agent 跟 Manager 我在 Day 4 追事件旅程的時候已經實際碰過;Indexer 平常是無感的,除非查詢效能出問題才會意識到它存在;Dashboard 我目前主要拿來做兩件事——核對跟探索。核對是說,如果我懷疑某個分析結論有問題,可以回來 Dashboard 直接查那筆原始告警存不存在、欄位對不對。

值得先說清楚一件事：Wazuh 內建的 Dashboard,跟我後面規劃要做的那個「給人看的 SOC 儀表板」不是同一個東西。內建的是原始告警視角,我自己要做的那個會疊上 AI 分析結果、走攻擊敘事的邏輯。

下面這張是我之前已經截過的,Agent 管理頁面,可以看到三台受監控主機目前都是 Active:

一次跟規則無關的插曲：佇列被塞爆
前面幾天提過「事件可能因為佇列滿載而遺失」這件事,今天想把這個插曲攤開講,因為它跟後面會講到的規則噪音問題,原因完全不一樣。

有一次我回頭查某台主機的告警記錄,看到在很短的時間窗裡(大概三分半鐘)連續出現一串等級遞增的告警:先是「佇列達 90% 滿」(等級 7),接著「佇列已滿,事件可能遺失」(等級 9),再來直接跳到「佇列滿載,請檢查 agent 設定」(等級 12)。同一段時間裡,還夾雜了幾筆 Windows 應用程式錯誤,以及一次 SCA(安全組態評估)基準掃描的結果,分數偏低。

我原本的第一反應是緊張——等級 12 在 Wazuh 的分級裡已經算相當高。但仔細看事件時間線之後,比較合理的解讀是:多個來源(排程掃描、應用程式錯誤、政策測試檔)剛好在很短的時間內一起把事件量衝高,超過了 agent 本地佇列的容量,不是有人在攻擊,是東西一次來得太多。

這件事讓我意識到一個跟規則設計完全不同層次的問題:即便規則寫得再準,如果 agent 端的佇列先滿了,事件根本進不到 Manager,規則也就沒有機會比對。 —這是容量問題,不是偵測邏輯問題,兩者要分開處理。

事後我回頭確認狀態,主機重新回到 Active、設定同步正常,Manager 端接收佇列顯示空的,也沒有訊息被丟棄的記錄。這次算是有驚無險,但我沒辦法保證下一次流量再衝高的時候,佇列一樣撐得住——目前我還沒有針對「佇列多常逼近上限」做長期觀察,這算是一個我知道存在、但還沒有處理的缺口。

明天
接下來想講 Windows 端的事件是怎麼一路走到 Wazuh 手上的,包含稽核政策沒開對、我因此看不到任何事件的那段經過。

明天見。