大家好，歡迎來到 Day 5！

昨天我們透過安裝 rsyslog，成功讓 Ubuntu 24.04 重新產出傳統的 /var/log/auth.log。本以為只要實體日誌檔案出現，一切就大功告成了，但就在我將靶機重新開機，準備進行下一步測試時，卻發現了一個非常致命的問題。

詭異的症狀：重開機後，日誌收集直接罷工？

重開機後，我前往 Wazuh 總部後台查看，發現靶機的登入日誌竟然是一片空白！不管我在靶機上怎麼登入測試，總部完全沒有收到任何一筆日誌。

但是，只要我在靶機的終端機手動敲下 sudo systemctl restart wazuh-agent，Wazuh 就會瞬間清醒，開始正常把日誌回傳。在自動化資安防禦的架構中，「必須依賴人工介入重啟」是絕對不合格的，這代表我們的系統缺乏開機即戰的高可用性。

抽絲剝繭：Wazuh 的檔案檢查機制與 Race Condition

去翻閱系統啟動日誌後，我找到了兇手：這是一個經典的啟動順序競態條件（Race Condition）。

在 Linux 開機時，各個服務會透過 systemd 並行喚醒。問題就在於，Wazuh Agent 啟動的速度比負責寫日誌的 rsyslog 還要快！

Wazuh Agent 啟動時，內部的收集模組會去尋找設定檔中指定的 /var/log/auth.log。但此時 rsyslog 都還沒準備好，檔案可能根本還沒生成。Wazuh 找不到目標，就直接略過這個路徑的監控。這導致後續就算 rsyslog 把檔案建出來並開始寫入，Wazuh 也已經「錯過」了，變成完全罷工的狀態。

根治方案：修改 systemd 服務相依性

要解決這個時間差，我們必須從底層強制規範它們的啟動順序，讓 Wazuh 乖乖等 rsyslog 把檔案準備好再啟動。

1. 確認 rsyslog 已設定開機自啟：

sudo systemctl enable rsyslog

2. 修改 Wazuh Agent 啟動腳本：
   打開 Wazuh Agent 的系統服務設定檔：

sudo nano /lib/systemd/system/wazuh-agent.service

找到 [Unit] 區塊底下的 After=，在最後方補上 rsyslog.service，強制要求相依性：

After=network.target network-online.target rsyslog.service

3. 重新載入系統設定：

sudo systemctl daemon-reload

存檔並重新開機測試，Wazuh Agent 這次確實等到 rsyslog 徹底就緒後才啟動，完美抓到了正確的檔案，達成無縫監控。

解決了這個隱蔽的底層 Bug，我們的日誌管線終於徹底穩固了！明天（Day 6），我們將把視角切換到整個防禦體系的大腦——Wazuh Manager 戰情總部，介紹它的核心模組與運作機制。