昨天我們探討了 Windows 環境下的 Python 虛擬環境（Virtual Environment）設定，成功排除依賴衝突，把 FastAPI 獨立運行起來。現在我們的 API 正在 0.0.0.0:8000 順利監聽請求。

不過，在完整的 SecOps（資安營運）架構中，若依賴後端程式不斷去向監控中心發送請求來確認狀態（這種作法稱為 API Polling），不僅會產生不必要的網路開銷，也無法達到威脅聯防所需的「即時性」。

因此，今天我們將採取事件驅動（Event-driven）的設計邏輯，在 Wazuh 內設定 Webhook 整合模組，讓系統在偵測到威脅時，能第一時間「主動推播」告警給我們的後端接收站

網路路由考量：Docker 容器與本機的通訊

在實作前，我們必須先釐清系統間的網路拓樸（Network Topology），這是開發者常踩的雷區。

由於我們的 Wazuh Server 是封裝在 Docker 的虛擬網路環境（Bridge Network）中執行，而 FastAPI 是直接運行在 Windows 本機（Host）上。如果我們在 Wazuh 裡將 webhook 目標設為 http://localhost:8000，Wazuh 僅會在「自己的容器內部」尋找這個 Port，進而導致連線失敗。

解決方案：
我們需要取得 Windows 本機的實體 IP 作為跨環境通訊的橋樑。請在 PowerShell 輸入 ipconfig，找到目前的 IPv4 位址（例如 192.168.X.X），我們將以此作為 Docker 容器向外發送請求的端點（Endpoint）。

配置 Wazuh 核心設定檔 (ossec.conf)

取得正確的 IP 後，我們回到 Wazuh Dashboard 進行全域設定檔的配置：

依序點擊左側選單：Server management ➔ Settings ➔ Configuration。

點擊右上角的 Edit configuration 進入編輯模式。

將檔案捲動至最底部，在結束標籤 </ossec_config> 之前，加入以下 區塊：

<integration>
    <name>custom-webhook</name>
    <hook_url>http://192.168.X.X:8000/webhook/wazuh</hook_url>
    <level>3</level>
    <alert_format>json</alert_format>
  </integration>

(記得把 192.168.X.X 換成你剛剛查到的 Windows IP )

參數解析：

name：宣告整合模式。我們使用 custom-webhook 來發送標準的 HTTP POST 請求。

hook_url：負責接收資料的 API 路由。

level：觸發告警的風險門檻（範圍為 1-15）。為了便於開發階段的連線測試，我們先將門檻下調至 3，讓一般的系統常規事件也能觸發推播。

alert_format：將傳遞的 Payload 格式化為 json，這能大幅降低後端 Python 進行資料解析與序列化的成本。

設定完成後點擊右上角的 Save，並依提示點擊 Restart Manager。系統大約需要一分鐘載入新規則。

驗證跨環境連線

設定生效後，我們將視角切換回 FastAPI 運行的 PowerShell 終端機。

由於觸發門檻已調低至 Level 3，Wazuh 在背景進行例行性檢測時，很快就會捕捉到符合條件的系統事件。稍候片刻，你就會在終端機的標準輸出（stdout）中，看到我們寫好的提示訊息以及 HTTP 狀態碼：

！收到一筆來自 Webhook 的資料！
INFO: 192.168.X.X:54321 - "POST /webhook/wazuh HTTP/1.1" 200 OK

當伺服器成功回傳 200 OK，代表從 Wazuh 到 FastAPI 的資料流已正式打通！我們的系統成功完成了從「被動日誌記錄」到「主動威脅通報」的架構升級。

明天，我們將進一步解析這包 Wazuh 傳遞過來的 JSON Payload，學習如何從海量的欄位中，精準萃取出 CVE 漏洞編號與受害主機等關鍵情報。大家明天見！