不知不覺，30 天的 Wazuh 實作挑戰終於來到最後一天。

一開始選擇 Wazuh 作為主題，是因為我想了解資安系統在實際環境中，究竟是如何從日誌收集、異常偵測，一步步走到自動化防禦。

過去接觸資安相關知識時，經常會看到 SIEM、IDS、EDR 等名詞，但真正開始動手建置後，才發現要讓一套系統正常運作，還有許多細節需要處理。

這 30 天不只是學習 Wazuh 的功能，也是一段不斷測試、遇到問題、查找原因，再重新驗證的過程。

今天就來回顧這次完成的內容，以及整個挑戰帶給我的收穫。

1. 從零開始建置 Wazuh 環境

這次實作最初從環境建置開始。

我使用 VMware 建立 Ubuntu 虛擬機，並逐步完成 Wazuh Manager 與 Agent 的部署。

一開始就遇到了不少問題，包括 Ubuntu 24.04 的日誌機制、rsyslog 設定，以及 Wazuh Manager 啟動異常等。

其中讓我印象比較深刻的是 systemd 啟動順序造成的問題。

當時服務無法正常啟動，原本以為是 Wazuh 設定錯誤，後來才逐步確認與服務啟動時序有關。

這也讓我了解到，資安工具並不是安裝完成就能正常使用，還需要理解底層作業系統與服務之間的關係。

完成環境建置後，才正式開始後續的安全監控實驗。

2. FIM：從檔案變更開始認識端點監控

環境完成後，我開始接觸 Wazuh 的 File Integrity Monitoring（FIM）。

FIM 可以監控指定檔案的變更情況，例如：

• 檔案被建立
• 檔案內容被修改
• 檔案遭到刪除

這次也建立了模擬敏感資訊的 Honeyfile：

/etc/pqc_secret_keys.conf

透過修改檔案內容，觀察 Wazuh 是否能偵測到異動，並產生對應的警報。

在實作過程中，也接觸到檔案雜湊值、即時監控，以及可能產生誤報的情況。

這讓我了解到，端點防禦不只是監控網路連線，檔案完整性同樣是重要的一環。

3. SSH 異常偵測與自訂 Rule

接下來是這次實作中花費比較多時間的部分：SSH 登入異常偵測。

我從 Windows PowerShell 對 Ubuntu 進行 SSH 登入測試，故意輸入錯誤密碼，觀察 Wazuh 如何收集並分析相關日誌。

在這個過程中，逐步理解：

SSH 登入失敗
      ↓
Linux Log
      ↓
Wazuh Agent
      ↓
Decoder
      ↓
Rule
      ↓
Alert

除了使用 Wazuh 內建規則，我也嘗試建立自己的 SSH 偵測規則：

Rule ID：100002

透過指定條件，讓系統能針對多次 SSH 登入失敗產生警報。

這部分讓我了解到，Wazuh 不只是把日誌顯示在 Dashboard，而是可以透過 Decoder 與 Rule，將原始紀錄轉換成有意義的安全事件。

4. Active Response：從偵測走向自動防禦

完成 SSH 偵測後，我開始思考另一個問題：

如果系統已經知道有人持續嘗試登入，能不能直接採取防禦措施？

因此後續加入了 Active Response，並嘗試使用 firewall-drop 封鎖來源 IP。

預期的流程是：

SSH 登入異常
      ↓
Rule 100002
      ↓
Active Response
      ↓
firewall-drop
      ↓
暫時阻擋來源 IP

但這個部分並不是一次就成功。

測試時曾經遇到 Dashboard 已經出現 Alert，卻沒有成功阻擋來源 IP 的情況。

後來重新檢查 Rule ID 的對應關係，以及 Active Response 的執行環境，逐步調整設定。

在後續測試中，終於觀察到 SSH 連線從原本的：

Permission denied

變成：

Connection timed out

這個結果符合自動封鎖的預期現象，也讓我看到 Wazuh 從單純產生警報，進一步走向自動化回應的可能性。

不過，要完整確認封鎖原因，仍然需要搭配 Active Response 日誌與防火牆規則進行驗證。

5. Python × Discord：讓資安事件主動通知

除了自動封鎖，我也希望系統能夠主動通知管理者。

因此最後加入 Python 與 Discord Webhook，讓程式讀取 Wazuh 的 alerts.json，將 SSH 異常資訊整理後發送到 Discord。

這次實際完成的通知內容包含：

🚨 SSH 登入失敗警報 🚨

受害主機：kuoyiting-VMware-Virtual-Platform
遭鎖定帳號：hacker
攻擊者 IP：192.168.212.1
已失敗次數：5 次

另外也嘗試透過 Docker Compose Sidecar，讓 Python 通知程式可以持續執行。

完成後，整個系統就能將事件偵測、自動回應與通知功能整合在一起：

              SSH 異常事件
                    ↓
               Wazuh Alert
                    │
          ┌─────────┴─────────┐
          │                   │
          ▼                   ▼
    Active Response         Python
          │                   │
          ▼                   ▼
     firewall-drop      Discord Webhook
          │                   │
          ▼                   ▼
      自動封鎖 IP         警報通知

這也是我這次 30 天挑戰中，最希望完成的系統架構。

6. 這 30 天最大的收穫

回顧整個過程，我認為最大的收穫並不是學會了多少個 Wazuh 功能，而是開始理解一套資安監控系統如何實際運作。

尤其是遇到問題時，不能只看最後有沒有成功，而是需要確認每個環節。

例如 Active Response 沒有成功封鎖 IP 時，就需要逐步確認：

Log 是否正常產生？
      ↓
Decoder 是否正確解析？
      ↓
Rule 是否成功觸發？
      ↓
Active Response 是否執行？
      ↓
防火牆是否正確套用？

這種從日誌、設定到實際測試結果的排查方式，是我認為這次最重要的學習經驗。

另外，連續 30 天整理實作紀錄，也讓我練習如何把技術內容轉換成其他人能夠理解的文章。

有時候自己操作時覺得很簡單，但真正要寫清楚原理、流程與結果，才會發現還有很多地方需要重新確認。

7. 未來可以繼續延伸的方向

雖然這次完成了基本的資安監控與自動化回應，但整套系統仍然有不少可以改進的地方。

例如：

第一，擴充偵測情境。

目前主要針對 SSH 登入異常進行測試，未來可以加入更多網路掃描、異常連線或端點行為的偵測規則。

第二，改善自動化回應機制。

未來可以針對不同風險程度採取不同處理方式，而不是所有事件都使用相同的封鎖動作，並加入白名單與誤判處理機制。

第三，結合更進階的風險評估。

除了單純依照 Rule 觸發警報，也希望未來能結合多種事件特徵，建立更完整的風險評估與