昨天進行 Active Response 測試時，遇到了一個問題：

SSH 登入測試
      ↓
Wazuh Alert ✓
      ↓
Active Response ?
      ↓
IP 沒有被封鎖 ✗

明明 Wazuh 已經成功偵測到 SSH 登入異常，卻沒有執行預期的封鎖動作。

因此今天不再修改偵測邏輯，而是開始檢查 Active Response 的執行流程，找出問題到底發生在哪裡。

1. 先確認真正觸發的 Rule ID

首先回到 Wazuh Dashboard，查看 SSH Alert 的詳細資訊。

這次最重要的不是 Rule Description，而是：

rule.id

因為 Active Response 是根據指定的規則條件來決定是否執行。

假設 Dashboard 顯示：

Rule ID：100002

那麼 Active Response 的設定也必須對應：

<rules_id>100002</rules_id>

如果兩邊的 Rule ID 不一致，就可能出現：

SSH Alert 已產生
        ↓
不符合 Active Response 觸發條件
        ↓
沒有執行封鎖

這也讓我發現，有 Alert 不代表觸發的就是 Active Response 所指定的那條 Rule。

2. 檢查 Active Response 的執行紀錄

接著要確認 Wazuh 是否真的執行了回應動作。

在 Ubuntu Agent 上查看：

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

這份 Log 可以協助確認 Active Response 是否有留下執行紀錄。

如果沒有看到預期的紀錄，就需要往前檢查規則觸發與設定。

如果有執行紀錄，但來源 IP 仍然沒有被封鎖，就需要繼續確認防火牆指令是否正常。

因此可以把問題分成兩種：

情況 A：
Alert 出現
    ↓
Active Response 沒有執行
    ↓
檢查 Rule ID / 觸發設定

情況 B：
Alert 出現
    ↓
Active Response 有執行
    ↓
IP 沒有被封鎖
    ↓
檢查 firewall-drop / 防火牆

3. 查看 Wazuh Manager Log

除了 Agent 端，也可以從 Manager 查看系統日誌：

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

如果想先找出 Active Response 相關訊息，也可以使用：

sudo grep -i "active-response" /var/ossec/logs/ossec.log

透過這些紀錄，可以協助判斷設定是否正常載入，以及系統有沒有出現相關錯誤。

不過要注意，沒有搜尋到特定字串，不一定代表 Active Response 完全沒有執行，仍然需要搭配 Agent 端紀錄一起判斷。

4. 檢查 Rule ID 是否一致

回頭比較兩個地方：

Dashboard：

rule.id = 100002

ossec.conf：

<rules_id>100002</rules_id>

這兩個數字必須對得起來。

而我在排查過程中，也把 Rule ID 的對應問題列為重要檢查項目。

因為如果自訂 Rule 已經調整過，但 Active Response 仍然使用舊的規則編號，就會造成偵測與回應無法正確連接。

Custom Rule
     ↓
實際觸發的 Rule ID
     ↓
Active Response rules_id
     ↓
必須一致

這也是為什麼不能只確認 XML 格式正確，就認為設定一定沒有問題。

5. 確認封鎖機制是否正常

如果 Rule ID 與 Active Response 的設定都沒有問題，下一步就是確認防火牆。

因為這次使用的是：

firewall-drop

它需要依賴端點上的防火牆機制來封鎖來源 IP。

因此可以先確認 Ubuntu 是否有對應的 iptables 工具：

sudo iptables -L -n

這個指令可以查看目前 iptables 規則，但還不能單靠它就判定 Active Response 是否成功。

還需要搭配執行紀錄，以及實際連線測試，才能確認封鎖效果。

6. 找到下一步修正方向

經過這次排查，我把需要確認的地方整理成：

SSH Alert
    ↓
確認實際 Rule ID
    ↓
比對 rules_id
    ↓
確認 Active Response 執行紀錄
    ↓
檢查 firewall-drop
    ↓
確認防火牆規則

這次也讓我了解到，Active Response 失敗時，不能直接認定是防火牆的問題。

因為有可能根本還沒有進入封鎖階段。

所以應該從前面的 Rule 開始，一步一步確認每個環節。

今日總結

今天主要針對 Active Response 沒有成功封鎖 IP 的問題進行排查。

最重要的發現是：

Wazuh 偵測成功、Rule 成功產生 Alert，以及 Active Response 成功執行，是三件需要分別確認的事情。

尤其是：

rule.id

和：

rules_id

兩者是否一致，會直接影響自動回應能否被觸發。

接下來就要根據排查結果，正式修正設定並重新測試。

Day 27 預告

修正 Active Response：讓 Rule 100002 正確觸發 firewall-drop

下一篇將重新確認：

Rule 100002
      ↓
Active Response
      ↓
firewall-drop
      ↓
iptables

並調整相關設定，讓偵測規則與封鎖機制真正連接起來，準備進行最後的自動封鎖驗證。