iT邦幫忙

2026 iThome 鐵人賽

DAY 28
0
Security

從零打造 Wazuh 自動化防禦與威脅狩獵戰情中心系列 第 28 篇

Day 28|Active Response 實戰驗證:SSH 連線終於被阻擋了!

  • 分享至 

  • xImage
  •  

經過前幾天的 Active Response 設定與除錯,今天終於要進行最後的 SSH 自動封鎖測試。

前面已經完成自訂 Rule 100002,並將它與 firewall-drop 連接起來。

這次不只是確認 Dashboard 有沒有 Alert,而是要實際觀察:

當 SSH 登入異常被偵測到後,來源主機還能不能繼續連線?


1. 再次進行 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 伺服器有回應連線,只是拒絕了錯誤的登入資訊。


2. 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

https://ithelp.ithome.com.tw/upload/images/20261011/20184260mZYQWW2w4B.png

這就是這次實驗最重要的觀察結果。

原本 SSH 連線可以正常抵達 Ubuntu,只是因為密碼錯誤而被拒絕。

但後來連線卻直接逾時,無法像之前一樣進入密碼驗證階段。


3. Permission denied 與 Connection timed out 有什麼不同?

這次測試中,兩種訊息代表不同的連線狀態。

測試結果 代表的情況
Permission denied SSH 伺服器有回應,但登入驗證失敗
Connection timed out SSH 連線未能在指定時間內取得預期回應

這次最大的差別,就是從原本可以進行密碼驗證,變成後續無法正常建立 SSH 連線。

這個現象符合我希望透過 Active Response 暫時阻擋來源 IP 的測試目標。

不過,連線逾時也可能由網路或防火牆的其他因素造成,因此仍需要搭配 Wazuh 的執行紀錄確認原因。


4. 確認 Active Response 的封鎖效果

這次設定的預期流程為:

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 端實際執行的防禦動作對應起來。


5. 從被動偵測走向主動防禦

回顧這幾天的實作,最大的改變其實不是多了一條 Rule,而是系統開始具備自動處理異常事件的能力。

最初只能做到:

SSH 異常
    ↓
Wazuh Alert
    ↓
人工查看

現在則建立了:

SSH 異常
    ↓
Rule 100002
    ↓
Active Response
    ↓
firewall-drop
    ↓
自動封鎖

雖然中間遇到了 Rule ID 對應與執行環境確認等問題,但也因此更了解 Wazuh 的偵測與回應是如何互相配合的。


今日總結

今天重新進行 SSH 登入測試,終於觀察到與之前不同的結果。

從:

Permission denied

變成:

Connection timed out

表示 SSH 連線在測試過程中確實出現了無法正常連接的情況,也符合這次 Active Response 封鎖測試的預期現象。

這次實驗讓我更清楚理解:

資安防禦不只是發現異常,還需要確認系統是否真的採取了有效的回應措施。

接下來,我希望在自動封鎖之外,再加入即時通知功能,讓管理者不用一直盯著 Dashboard,也能知道系統發生了什麼事情。


Day 29 預告

Wazuh × Python × Discord:讓資安警報自動推播到手機

下一篇將使用 Python 讀取 Wazuh 的 alerts.json,並透過 Discord Webhook 發送通知。

讓整個系統除了自動偵測與封鎖之外,也能主動通知管理者。


上一篇
Day 27|修正 Active Response:讓 SSH 偵測與自動封鎖正確連接
下一篇
Day 29|Wazuh × Python × Discord:打造 SSH 異常即時警報通知系統
系列文
從零打造 Wazuh 自動化防禦與威脅狩獵戰情中心 共 30 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言