昨天已經在 Wazuh 的 ossec.conf 中完成 Active Response 設定，原本預期只要 SSH 偵測規則成功觸發，系統就會自動封鎖來源 IP。

但實際測試時，卻發現一個問題：

Wazuh Dashboard 明明有 Alert，SSH 連線卻沒有被成功阻擋。

這代表前面的偵測功能正常，但後面的自動回應可能出了問題。

1. 重新進行 SSH 測試

首先從 Windows PowerShell 再次連線到 Ubuntu：

ssh hacker@192.168.212.128

接著故意輸入錯誤密碼，讓 Wazuh 產生 SSH 登入失敗事件。

測試後回到 Dashboard，可以找到相關的 SSH Alert。

但當我再次嘗試 SSH 連線時，卻發現來源 IP 並沒有如預期被阻擋。

原本預期的流程是：

SSH 登入失敗
      ↓
Rule 100002
      ↓
Active Response
      ↓
firewall-drop
      ↓
來源 IP 被封鎖

實際觀察到的情況卻是：

SSH 登入失敗
      ↓
Wazuh Alert ✓
      ↓
Active Response ?
      ↓
來源 IP 未被阻擋 ✗

2. 有 Alert 不代表自動封鎖成功

一開始我以為只要 Dashboard 出現警報，就代表整個設定已經正常運作。

但這次實驗讓我發現：

Detection 成功，不代表 Response 一定成功。

Wazuh 的偵測與自動回應是不同階段。

即使已經產生 Alert，仍然需要確認 Active Response 是否真的被觸發，以及封鎖命令有沒有成功執行。

因此不能只看 Dashboard，就直接認定防禦機制已經完成。

3. 開始確認 Active Response 設定

既然 SSH Alert 已經正常產生，我先回頭檢查前一天修改的設定檔：

sudo nano /var/ossec/etc/ossec.conf

確認 Active Response 的設定：

<active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>100002</rules_id>
    <timeout>60</timeout>
</active-response>

這裡有幾個需要確認的地方：

• command 是否指定正確的封鎖命令
• location 是否符合預期的執行位置
• rules_id 是否對應實際觸發的規則
• timeout 是否設定正確

其中我特別注意：

<rules_id>100002</rules_id>

因為 Active Response 必須符合指定的觸發條件，才會執行後續動作。

4. 下一步要從 Log 找原因

光看設定檔還不夠。

接下來需要進一步確認 Active Response 是否真的收到執行要求。

Wazuh 可以透過相關日誌協助排查，例如在執行回應的端點查看：

sudo tail -f /var/ossec/logs/active-responses.log

也可以在 Manager 查看：

sudo tail -f /var/ossec/logs/ossec.log

透過這些紀錄，可以進一步區分問題究竟發生在哪個階段：

Rule 沒有符合觸發條件？
          ↓
Active Response 沒有執行？
          ↓
封鎖命令執行失敗？
          ↓
防火牆沒有正確套用？

目前還不能只憑 Dashboard 的 Alert 就確定是哪個環節出錯。

今日總結

今天原本是要驗證 Active Response 的自動封鎖效果，結果卻發現：

SSH 偵測正常
      ✓

Dashboard Alert 正常
      ✓

自動封鎖
      ✗

這次測試讓我了解到，偵測規則與回應機制必須分開驗證。

接下來不能再只看有沒有 Alert，而是要從 Rule ID、Active Response Log 與執行環境繼續排查。

Day 26 預告

Active Response Debug：從 Rule ID 與 Log 找出封鎖失敗原因

下一篇開始深入檢查：

Alert Rule ID
      ↓
Active Response rules_id
      ↓
執行紀錄
      ↓
找出問題

看看為什麼明明有偵測到 SSH 異常，卻沒有執行預期的封鎖動作。