大家好！歡迎來到鐵人賽第十八天。

前幾天我們已經完成了：
Wazuh 告警 ➡ Gemini AI 分析 ➡ 建立工單 ➡ LINE 審批 ➡ SSH 執行處理

不過，目前的流程主要還是針對「單一主機」。如果今天 Web-01 偵測到一個惡意 IP 正在進行 SSH 暴力破解，我們只封鎖 Web-01，其他主機可能仍然會收到來自相同 IP 的攻擊。

因此今天要讓 SOAR 再往前一步：當一台主機發現惡意 IP 時，同時通知其他防線進行封鎖。

這就是今天要實作的「多節點自動化聯防」。

聯防情境

今天不處理漏洞修補，而是模擬一個正在發生的攻擊事件。
假設 Wazuh 偵測到：

• Attack Type：SSH Brute Force
• Source IP：192.168.1.100

我們希望最後的流程變成：

Wazuh
 ↓
n8n (取得攻擊來源 IP)
 ↓
LINE 人工審批
 ↓
Wait 等待授權
 ↓
┌──────────────┐
↓              ↓
Web-01         DB-01
(封鎖 IP)      (封鎖 IP)
└──────────────┘
 ↓
Google Sheets 紀錄
 ↓
LINE 通知

第一步：從 Wazuh 取得攻擊來源 IP

首先回到 Wazuh ➡ n8n 的 Webhook。假設 Webhook 收到的資料中包含：

• Source IP：{{ $json.body.data.srcip }}
• Attack Type：{{ $json.body.rule.description }}

我們今天最重要的資料就是 srcip。例如：srcip = 192.168.1.100。後面的 SSH 節點就會使用這個 IP 來建立防火牆規則。

第二步：使用 Switch 分流不同事件

我們現在的 SOAR 已經不只處理漏洞，因此需要先判斷：這次到底是什麼類型的資安事件？

在 Webhook 後加入一個 Switch 節點，設定兩個分支：

• 分支 1：漏洞事件
  如果事件屬於 vulnerability，就進入前幾天完成的：
  漏洞分析 ➡ HITL ➡ SSH 修補 ➡ 工單結案
• 分支 2：攻擊事件
  如果事件包含 authentication_failed 或 brute_force，就進入今天的：
  惡意 IP 聯防封鎖流程

這樣同一套 n8n 工作流，就可以根據不同事件選擇不同的處理方式。

第三步：加入 HITL 審批

因為「封鎖 IP」可能會造成服務無法連線，所以不建議讓所有事件都直接自動執行。因此我們沿用 Day 16 的 HITL 機制。

先透過 LINE 發送：

🚨 資安事件通知
偵測到 SSH 暴力破解
攻擊來源 IP：192.168.1.100
是否封鎖此 IP？

接著進入 Wait 節點 等待管理員確認。

• 如果選擇「拒絕」，就結束流程。
• 如果選擇「授權」，才繼續執行後面的防火牆更新。

第四步：建立多節點 SSH

通過人工審批後，就是今天最重要的部分。
在 n8n 中建立兩個並排的 SSH 節點，分別連線到不同的 Ubuntu 測試主機：

              ┌─➡ SSH (Web-01)
Wait ➡ 分流 ──┤
              └─➡ SSH (DB-01)

第五步：在主機上封鎖惡意 IP

這裡以 Linux iptables 作為示範。

Web-01 的 SSH Command：

sudo iptables -A INPUT -s {{ $('Webhook').item.json.body.data.srcip }} -j DROP

DB-01 也使用相同的概念：

sudo iptables -A INPUT -s {{ $('Webhook').item.json.body.data.srcip }} -j DROP

假設攻擊來源是 192.168.1.100，實際執行後就會變成：

sudo iptables -A INPUT -s 192.168.1.100 -j DROP

執行後可以分別登入兩台 Ubuntu 主機確認：

sudo iptables -L

如果看到對應的 DROP 規則，就代表兩台主機都成功加入了封鎖。

(💡 實務環境也可以將這個概念延伸到 FortiGate 等防火牆，透過 API 讓 n8n 自動更新邊界防火牆規則。)

第六步：記錄聯防結果

前面的 Day 17 已經建立了 Google Sheets 資安工單，因此今天可以直接沿用。在 SSH 執行成功後，更新工單：

• Status：✅ 已完成聯防封鎖
• Action：Web-01、DB-01
• Blocked IP：192.168.1.100
• Approval Time：{{ $now }}

最後再透過 LINE 發送完成通知：

✅ SOAR 聯防完成
封鎖 IP：192.168.1.100
處理主機：Web-01、DB-01
狀態：已完成封鎖

完整流程

完成後，今天的 SOAR 流程就會變成：

Wazuh
 ↓
Webhook
 ↓
Switch (判斷事件類型)
 ↓
(偵測到 Brute Force) ➡ 取得 Source IP
 ↓
LINE 審批 ➡ Wait
 ↓
(管理員授權)
 ↓
┌──────────────┐
↓              ↓
SSH            SSH
Web-01         DB-01
(封鎖 IP)       (封鎖 IP)
└──────────────┘
 ↓
Google Sheets
 ↓
LINE 通知

這樣一來，當同一個惡意 IP 被確認需要封鎖時，就可以透過 n8n 將相同的防禦動作套用到多個節點。

今天的成果

今天我們將原本針對單一主機的自動化流程，擴充成了多節點聯防。目前的 SOAR 已經可以根據不同事件選擇不同 Playbook：

• 漏洞事件 ➡ 漏洞修補
• 攻擊事件 ➡ 惡意 IP 封鎖

而且在執行重要防禦動作之前，仍然保留了 HITL 人工審批，最後再透過 Google Sheets 保存處理結果。

到這裡，我們的流程已經從：
「發現一個問題 ➡ 處理一台主機」
進一步進化成：
「發現一個事件 ➡ 協調多個節點共同處理」
這也更接近 SOAR 中「協調（Orchestration）」的核心概念。

明天 Day 19，我們將繼續處理「惡意 IP 到底是誰？」這個問題。我們將加入 Threat Intelligence 情資豐富化，讓 n8n 自動查詢 VirusTotal 等威脅情報來源，再將查詢結果交給 AI 進行分析。我們明天見！