經過前幾天的 Active Response 設定與除錯,今天終於要進行最後的 SSH 自動封鎖測試。
前面已經完成自訂 Rule 100002,並將它與 firewall-drop 連接起來。
這次不只是確認 Dashboard 有沒有 Alert,而是要實際觀察:
當 SSH 登入異常被偵測到後,來源主機還能不能繼續連線?
首先回到 Windows PowerShell,對 Ubuntu Agent 發起 SSH 連線:
ssh hacker@192.168.212.128
這次的測試環境為:
Windows(測試來源)
192.168.212.1
Ubuntu Agent(SSH 目標)
192.168.212.128
接著故意輸入錯誤密碼,模擬多次 SSH 登入失敗的情況。
一開始仍然可以看到:
Permission denied, please try again.
這代表 SSH 伺服器有回應連線,只是拒絕了錯誤的登入資訊。
在持續進行登入測試後,PowerShell 出現了與之前不同的訊息:
ssh_dispatch_run_fatal: Connection to 192.168.212.128 port 22: Connection timed out
再次嘗試連線時,則出現:
ssh: connect to host 192.168.212.128 port 22: Connection timed out

這就是這次實驗最重要的觀察結果。
原本 SSH 連線可以正常抵達 Ubuntu,只是因為密碼錯誤而被拒絕。
但後來連線卻直接逾時,無法像之前一樣進入密碼驗證階段。
這次測試中,兩種訊息代表不同的連線狀態。
| 測試結果 | 代表的情況 |
|---|---|
Permission denied |
SSH 伺服器有回應,但登入驗證失敗 |
Connection timed out |
SSH 連線未能在指定時間內取得預期回應 |
這次最大的差別,就是從原本可以進行密碼驗證,變成後續無法正常建立 SSH 連線。
這個現象符合我希望透過 Active Response 暫時阻擋來源 IP 的測試目標。
不過,連線逾時也可能由網路或防火牆的其他因素造成,因此仍需要搭配 Wazuh 的執行紀錄確認原因。
這次設定的預期流程為:
Windows SSH 登入失敗
↓
Ubuntu 產生 SSH Log
↓
Wazuh Agent 收集事件
↓
觸發 Rule 100002
↓
Active Response
↓
firewall-drop
↓
暫時阻擋來源 IP
而實際從 PowerShell 觀察到的結果是:
測試前
SSH 可連線
↓
密碼錯誤
↓
Permission denied
測試後
再次 SSH 連線
↓
Connection timed out
如果要進一步確認這次逾時確實由 Active Response 造成,可以在 Ubuntu Agent 查看:
sudo tail -n 30 /var/ossec/logs/active-responses.log
以及防火牆規則:
sudo iptables -L -n
確認是否有對應來源 IP 的封鎖紀錄。
這樣才能把 Windows 端的連線結果,與 Ubuntu 端實際執行的防禦動作對應起來。
回顧這幾天的實作,最大的改變其實不是多了一條 Rule,而是系統開始具備自動處理異常事件的能力。
最初只能做到:
SSH 異常
↓
Wazuh Alert
↓
人工查看
現在則建立了:
SSH 異常
↓
Rule 100002
↓
Active Response
↓
firewall-drop
↓
自動封鎖
雖然中間遇到了 Rule ID 對應與執行環境確認等問題,但也因此更了解 Wazuh 的偵測與回應是如何互相配合的。
今天重新進行 SSH 登入測試,終於觀察到與之前不同的結果。
從:
Permission denied
變成:
Connection timed out
表示 SSH 連線在測試過程中確實出現了無法正常連接的情況,也符合這次 Active Response 封鎖測試的預期現象。
這次實驗讓我更清楚理解:
資安防禦不只是發現異常,還需要確認系統是否真的採取了有效的回應措施。
接下來,我希望在自動封鎖之外,再加入即時通知功能,讓管理者不用一直盯著 Dashboard,也能知道系統發生了什麼事情。
下一篇將使用 Python 讀取 Wazuh 的 alerts.json,並透過 Discord Webhook 發送通知。
讓整個系統除了自動偵測與封鎖之外,也能主動通知管理者。