在 Day20，我們建立了 Response Engine 的初步架構，可以根據 Alert 的風險等級，產生對應的回應建議。

不過，目前的 Response Engine 還停留在 Dry Run 階段，並沒有真正終止程序、封鎖 IP 或隔離主機。

因此，Day21 我們先不急著加入實際阻斷功能，而是將先前完成的 Detection Engine 與 Response Engine 串接起來，確認真實的 Linux 程序事件能夠經過偵測、產生 Alert，再進入模擬回應流程。

今天也會利用 HIGH 等級的模擬事件與真實測試程序，驗證目前的回應邏輯及 Dry Run 的安全性。

在 Day20，我們也建立了 Response Engine 的第一個版本，讓 BehaviorGuard 可以根據 Alert 的風險等級，產生不同的事件回應建議。

例如：

• MEDIUM：建議進一步調查
• HIGH：建議終止可疑程序
• CRITICAL：建議隔離主機

不過，Day20 使用的是手動建立的測試 Alert，Response Engine 還沒有真正連接到 Linux 的即時偵測流程。

因此，Day21 我們要解決這個問題。

今天的目標是讓 BehaviorGuard 從真正的 Linux 程序取得資訊，經過 Detection Engine 分析後，自動將 Alert 送進 Response Engine。

另外，我們也會驗證 Dry Run 的安全性，確認系統不會因為 HIGH Alert 就直接終止正常程序。

一、Detection 與 Response 為什麼需要整合？

在之前的實作中，BehaviorGuard 已經具備以下功能：

1. Process Monitor：監控 Linux 程序。
2. Detection Engine：根據規則識別可疑行為。
3. Correlation Engine：進行事件關聯分析。
4. Alert Logger：將警告儲存成 JSONL。
5. Alert Summary：統計不同風險等級的警告。
6. Response Engine：根據 Severity 產生回應建議。

但如果這些功能都是獨立執行，就還不能算是一條完整的事件處理流程。

例如，Detection Engine 發現可疑程序後，應該能自動將事件交給 Response Engine，而不是需要我們手動建立另一筆 Alert。

因此，今天要建立以下流程：

Kali Linux
     ↓
Process Monitor
     ↓
Detection Engine
     ↓
產生 Alert
     ↓
Alert Normalization
     ↓
 ┌───────────────────────────┐
 │                           │
 ↓                           ↓
Correlation Engine       Alert Logger
事件關聯分析              儲存 JSONL
 │
 └────────────┐
              ↓
       Response Engine
              ↓
      判斷 Severity
              ↓
       DRY RUN 模式
              ↓
        顯示回應建議

需要注意，目前 Response Engine 接收的是正規化後的 Detection Alert，並不是等待 Correlation Engine 分析完成後才執行，因此還不能算是完整的關聯式自動回應。

二、串接 Response Engine

今天主要修改 agent/process_monitor.py。

首先匯入之前建立的 Response Engine：

from response.engine import handle_alert

接著找到之前 Day16 建立的 normalized_alert。

這個物件會將不同偵測規則產生的 Alert 整理成統一格式，內容包含：

normalized_alert = {
    "rule": alert["rule_id"],
    "name": alert["rule_name"],
    "severity": alert["severity"],
    "description": alert["description"],
    "category": "Process/Command",
    "pid": process["pid"],
    "ppid": process["ppid"],
    "process": process["name"],
    "parent": parent_name,
    "ancestors": ancestors,
    "command": process["command"]
}

我們只需要在原本的事件處理流程中增加：

# Correlation Engine
add_alert(normalized_alert)

# Alert Logger
save_alert(normalized_alert)

# Day21：Response Engine
handle_alert(normalized_alert)

這三個函式分別負責不同工作：

• add_alert()：將事件送進 Correlation Engine。
• save_alert()：保存事件日誌。
• handle_alert()：根據警告內容選擇回應建議。

這次實際新增的程式碼不多，原因是之前已經把 Detection、Logging 和 Response 分別設計成獨立模組。

今天的重點不是增加新的偵測規則，而是完成模組之間的整合。

三、測試一：真實 Linux 程序觸發 Response

完成程式修改後，我們先使用 Kali Linux 進行真實程序測試。

啟動 BehaviorGuard：

cd ~/behaviorguard
PYTHONPATH=. python3 agent/process_monitor.py

系統顯示：

========== BehaviorGuard ==========
[INFO] Continuous monitoring started.
[INFO] Press Ctrl+C to stop.

接著開啟另一個 Terminal，執行：

python3 -c 'import time; print("Day21 Test"); time.sleep(5)'

這是一段無害的測試程式，會顯示文字並暫停五秒。

因為我們之前建立的 BG-CMD-002 規則會偵測 Python Inline Code Execution，因此這個測試應該會觸發 MEDIUM Alert。

實際偵測結果

[ALERT] BG-CMD-002
Rule      : Python Inline Code Execution
Severity  : MEDIUM

PID       : 2527870
PPID      : 2527691
Process   : python3
Parent    : zsh
Ancestors : [2527691, 2527683, 1]

Command   : python3 -c import time; print("Day21 Test"); time.sleep(5)

Reason    : Python executed code directly from the command line.

代表 BehaviorGuard 成功從 Kali Linux 取得真實程序資訊，並透過 Detection Engine 觸發警告。

接著系統自動輸出：

========== BehaviorGuard Response ==========
Rule       : BG-CMD-002
Severity   : MEDIUM
PID        : 2527870
Action     : Recommend further investigation
Mode       : DRY RUN
Executed   : False
============================================

同時也顯示：

[INFO] Alert saved to logs/alerts.jsonl

這次我們成功確認，BehaviorGuard 已經可以將真實 Linux 程序產生的 Alert，自動送入 Response Engine。

另外，我們也透過 tail 指令確認 JSONL 中確實保存了這筆事件。

tail -n 1 logs/alerts.jsonl

日誌中包含 Rule、Severity、PID、PPID、Parent、Ancestors、Command 與 Timestamp 等資訊。

四、測試二：HIGH Alert 能不能進入 Response？

第一個測試使用的是 MEDIUM Alert，但如果遇到更高風險的行為，Response Engine 是否也能正常運作？

因此，我們進一步測試之前建立的 BG-PROC-001。

這條規則的目的是偵測 Web Server 啟動 Shell 的可疑程序關係。

例如：

apache2
   ↓
bash
   ↓
BG-PROC-001
   ↓
HIGH

在真實環境中，Web Server 啟動 Shell 可能與 Web Shell、遠端命令執行或某些管理操作有關，需要進一步調查。

今天為了安全，不實際執行攻擊，而是建立一筆模擬 Process Event，交給真正的 Detection Engine 分析。

建立測試檔案：

nano test_day21_high.py

核心程式如下：

from detection.engine import analyze_process_event
from response.engine import handle_alert

process_event = {
    "parent": "apache2",
    "child": "bash"
}

alerts = analyze_process_event(process_event)

for alert in alerts:

    normalized_alert = {
        "rule": alert["rule_id"],
        "name": alert["rule_name"],
        "severity": alert["severity"],
        "description": alert["description"],
        "category": "Process/Command",
        "pid": 9999,
        "ppid": 8888,
        "process": "bash",
        "parent": "apache2",
        "ancestors": [8888],
        "command": "bash"
    }

    print("[DETECTION]")
    print(f"Rule     : {normalized_alert['rule']}")
    print(f"Severity : {normalized_alert['severity']}")

    handle_alert(normalized_alert)

執行：

PYTHONPATH=. python3 test_day21_high.py

實際測試結果

[INFO] Simulated Process Event:
{'parent': 'apache2', 'child': 'bash'}

[DETECTION]
Rule     : BG-PROC-001
Severity : HIGH

========== BehaviorGuard Response ==========
Rule       : BG-PROC-001
Severity   : HIGH
PID        : 9999
Action     : Recommend process termination
Mode       : DRY RUN
Executed   : False
============================================

[INFO] Day21 HIGH integration test finished.

這次成功證明，Detection Engine 產生的 HIGH Alert 也能正確傳送到 Response Engine。

不過，PID 9999 是模擬資料，並非真實的 Linux 程序。

五、測試三：驗證 Dry Run 不會誤殺程序

完成 Detection 與 Response 整合後，我認為還有一個很重要的問題：

如果 Response Engine 建議終止程序，它會不會真的把 Linux 程序關閉？

因為我們目前的偵測規則仍然有可能發生 False Positive（誤判），因此必須確認 Dry Run 不會影響正常程序。

這次使用 Python 的 subprocess 建立一個真正的測試程序：

import subprocess
from response.engine import handle_alert

# 建立一個安全的測試程序
proc = subprocess.Popen(["sleep", "30"])

print(f"[TEST] Started process PID: {proc.pid}")

# 模擬 HIGH Alert
handle_alert({
    "rule": "BG-TEST-001",
    "severity": "HIGH",
    "pid": proc.pid
})

# 確認程序是否仍然存在
if proc.poll() is None:
    print("[PASS] Dry Run did not terminate the process.")
else:
    print("[FAIL] Test process exited unexpectedly.")

# 清理測試程序
if proc.poll() is None:
    proc.terminate()

proc.wait()

print("[INFO] Test cleanup completed.")

其中 sleep 30 只是讓程序等待三十秒，不會執行任何攻擊。

proc.poll() 可以檢查程序是否已經結束，如果回傳 None，代表程序當下仍然在執行。

實際執行結果

[TEST] Started process PID: 2532855

========== BehaviorGuard Response ==========
Rule       : BG-TEST-001
Severity   : HIGH
PID        : 2532855
Action     : Recommend process termination
Mode       : DRY RUN
Executed   : False
============================================

[PASS] Dry Run did not terminate the process.
[INFO] Test cleanup completed.

可以看到，即使 Severity 是 HIGH，Response Engine 仍然沒有終止 PID 2532855。

最後的 proc.terminate() 是測試程式自行清理建立的程序，而不是 Response Engine 執行的處置。

這次測試成功驗證目前的 Dry Run 不會直接終止指定的測試程序。

六、今天學到的資安觀念

1. Detection-to-Response Integration

Detection-to-Response Integration 是指將偵測引擎產生的事件，傳送給回應模組進一步處理。

這樣系統就不需要依賴人工重新輸入 Alert，能夠建立更完整的事件處理流程。

2. Automated Response 與 Dry Run 的差別

Automated Response 是讓系統依照策略，自動執行或安排對應的安全處置。

例如終止程序、封鎖 IP 或隔離主機。

而 Dry Run 則是模擬這些決策，不真正執行處置。

目前 BehaviorGuard 完成的是自動回應建議流程，還不是真正的自動阻斷。

3. False Positive（誤判）

False Positive 指系統將正常行為誤認為可疑或惡意行為。

在 Detection 階段，誤判可能只會增加不必要的 Alert。

但是在 Response 階段，如果誤判導致自動終止重要程序，就可能造成服務中斷。

因此，真正執行 Response 之前，應該加入身分確認、白名單、授權條件與處置結果驗證等保護措施。

七、今日心得

Day21 的程式修改量其實不多，但這次讓我更加了解模組化設計的重要性。

之前我們花了很多時間分別開發 Detection、Correlation、Logger 和 Response Engine。

今天只需要透過少量程式碼，就能讓原本獨立的模組開始共同處理真實事件。

除了成功將真實 Linux 程序的 Alert 傳入 Response Engine，我們也利用模擬 Web Server 啟動 Shell 的事件，確認 HIGH 等級的偵測結果能產生正確的回應建議。

最後，我們還使用真正的 Linux 測試程序，確認目前 Dry Run 模式不會誤殺程序。

不過，在實作過程中，我也開始思考一個更重要的問題：

如果 Response Engine 永遠只顯示建議，卻沒有真正阻斷攻擊，那它和一般的警告系統有什麼差別？

因此，我認為接下來應該逐步加入真正的安全處置功能。

目前的 BehaviorGuard 雖然已經完成 Detection-to-Response 的初步串接，但還沒有辦法真正終止惡意程序、封鎖可疑 IP 或隔離主機。

未來也需要加入更完整的 Response Policy，避免只依照 Severity 就直接處置，降低誤判對正常系統造成的影響。

下一篇 Day22，我們將開始實作真正的 Process Termination，在受控測試環境中安全地終止指定程序，並驗證回應是否成功。

目標是讓 BehaviorGuard 逐步從單純的可疑行為偵測工具，發展成具有實際處置能力的 Linux Endpoint Detection & Response 原型系統。