大家好，歡迎來到 Day 3！

在確定了 Wazuh 架構後，今天我們要來建置這套系統的「受害者」——也就是準備用來挨打、並安裝 Wazuh Agent 的端點靶機。在靶機環境的選擇上，我經歷了一段不小的撞牆期，今天就來跟大家分享這個架構抉擇的血淚史。

最初的誘惑：輕量便捷的 WSL2

一開始為了貪圖方便，我選擇了 Windows 內建的 WSL2 (Windows Subsystem for Linux 2) 來運行 Ubuntu 環境。WSL2 啟動極快、與 Windows 宿主機檔案互通方便，看起來是個完美的輕量級靶機選擇。

但當我把 Wazuh Agent 安裝上去，準備進行「系統弱點盤點 (Vulnerability Detection)」時，惡夢就開始了。我發現 Wazuh 產出的 CVE (通用漏洞披露) 報表出現嚴重漏報，甚至無法正確讀取系統套件資訊。

發現痛點：核心共用與命名空間的限制

經過一番排錯，我發現問題出在 WSL2 的底層架構。Wazuh 的弱點掃描與底層監控，高度依賴對 Linux Kernel、系統套件庫狀態以及完整日誌管線的讀取權限。

然而，WSL2 本質上是透過輕量級虛擬化技術，與 Windows 共用底層硬體，並在受限的命名空間 (Namespace) 內運行。這導致了兩個致命傷：

1. 系統資訊衝突： Wazuh Agent 抓不準真實的 Linux 核心狀態與套件依賴關係。
2. 網路與防火牆限制： WSL2 的底層網路橋接與原生的 iptables/nftables 有落差，這會導致我們後續想做 Active Response (防火牆自動阻斷) 時處處碰壁。

斷尾求生：轉向純 VMware 虛擬機

認清了這是一個「架構層級」的硬傷後，我果斷停損，改採 VMware Workstation 部署純 Ubuntu 24.04 Desktop 虛擬機。

擁有獨立、完整 Linux Kernel 與網路堆疊的虛擬機，徹底解開了 Wazuh Agent 的封印。重新部署後，Wazuh 順利掃描出完整的套件清單，並產出了極度精準的系統 CVE 弱點報表。

今日總結： 做底層資安防禦測試，千萬別在容器或閹割版的系統上妥協。
完整的地基打好後，明天（Day 4），我們將正式在 Ubuntu 24.04 上啟動 Wazuh Agent，並準備迎戰系統日誌機制帶來的下一個「大魔王」！