前面幾天，我們已經陸續完成了 BehaviorGuard 的程序監控、網路監控、檔案監控、持久化偵測、事件關聯分析，以及受控自動回應功能。

但是一直有個問題：雖然每個功能都能獨立執行，卻還不算真正整合成一套完整的監控系統。

例如，Process Monitor 可以偵測可疑 Python 指令，File Monitor 可以發現新增的可疑腳本，而 Persistence Detection 可以偵測 Cron 設定異動。

如果這三件事情發生在短時間內，而且彼此有關聯，系統應該不只分別發出三筆 Alert，而是進一步判斷它們是否可能形成一條攻擊鏈。

因此 Day27 的目標有兩個：

1. 建立跨來源事件關聯規則 BG-CORR-006。
2. 整合 Process、Network、File Monitor，讓 BehaviorGuard 可以透過同一個主程式持續監控 Linux。

一、什麼是 Multi-Source Correlation？

Multi-Source Correlation（多來源事件關聯）是指將不同監控來源取得的安全事件整合分析，找出事件之間可能存在的關係。

例如：

BG-CMD-002
Python Inline Code Execution
        ↓
BG-FILE-003
Suspicious Script Creation
        ↓
BG-PERSIST-001
Cron Persistence
        ↓
BG-CORR-006
Command Script Persistence Chain
        ↓
HIGH Alert

第一筆事件代表有人使用 Python 直接執行命令列程式碼。

第二筆事件代表系統暫存目錄出現新的腳本檔案。

第三筆事件代表 Cron 設定發生變動。

單獨來看，這三件事不一定就是惡意活動。但如果它們引用同一個腳本路徑、屬於相同 UID，而且依照合理的時間順序發生，就值得進一步調查。

這也是 Correlation 與一般 Detection 最大的不同。

Detection 是判斷單一行為是否符合規則；Correlation 是分析多筆事件之間的關係。

二、新增 BG-CORR-006 關聯規則

這次新增了：

correlation/multi_source.py

主要負責跨來源事件的比對。

我們設定三個必要條件：

• 必須依序出現 BG-CMD-002、BG-FILE-003、BG-PERSIST-001。
• 三筆事件必須在 30 秒時間窗口內出現，且 UID 相同。
• Python 命令、建立的腳本檔案，以及 Cron 設定內容必須引用相同的腳本路徑。

核心概念如下：

RULES = (
    "BG-CMD-002",
    "BG-FILE-003",
    "BG-PERSIST-001"
)

WINDOW = 30

當新的 Persistence Alert 進入系統時，Correlation Engine 會往前檢查暫存的事件，尋找符合條件的 Command 和 File Alert。

成功後，產生：

Rule     : BG-CORR-006
Name     : Command Script Persistence Chain
Severity : HIGH
Category : Correlation

我們也加入 related_event_ids，保存構成這次關聯的三筆原始事件 ID，方便後續追查。

但這裡有個限制：相同 UID、路徑及時間順序只能提供關聯證據，不能直接證明某個 Python 程序就是實際建立檔案的人。若要進一步確認，需要更深入的程序與檔案操作追蹤技術。

三、為什麼原本的 Correlation Engine 不夠？

先前建立的 BG-CORR-001～005 主要針對 Process 和 Network。

這些事件通常可以取得：

PID
PPID
Process Name
Ancestors
Command

因此我們可以使用 Process Tree（程序樹），判斷兩筆 Alert 是否屬於相同程序或父子程序關係。

但是 File Monitor 不一樣。

它通常能取得：

Action
Path
Filename
UID
SHA256
Mode

卻不一定知道是哪個 PID 建立或修改了檔案。

因此 Day27 補上 Process Alert 的 UID，並從模擬 Cron 設定內容中提取腳本路徑，讓不同來源的事件能使用共同欄位進行比對。

這個過程讓我理解，資安系統要做關聯分析，不能只靠蒐集大量 Alert，還必須在資料設計階段考慮各個監控來源有哪些可以比對的欄位。

四、真實 Linux 端到端測試

完成 BG-CORR-006 後，我們先測試不同 UID、不同腳本路徑及錯誤事件順序，確認系統不會只因為三條規則都出現就直接產生關聯告警。

接著進行真正的 Linux 監控測試。

這次不是手動建立 Alert，而是讓 Process Monitor 與 Watchdog File Monitor 從系統取得實際事件。

第一步：Process Detection

我們啟動一個無害的 Python 測試程序，使用 python3 -c 執行變數設定與休眠，並在命令列中加入測試腳本路徑。

Process Monitor 從 Linux /proc 收集到程序資訊：

Rule    : BG-CMD-002
Process : python3
PID     : 2923041
UID     : 1000
Severity: MEDIUM

成功觸發 Python Inline Code Execution。

第二步：File Detection

在監控中的實驗目錄建立 .sh 檔案：

/tmp/behaviorguard_test/tmp/day27_chain_f304ffb3b3.sh

Watchdog 收到 CREATED 事件，接著 Detection Engine 成功產生：

Rule     : BG-FILE-003
Name     : Suspicious Script Creation
Severity : MEDIUM

第三步：Persistence Detection

接著在實驗目錄建立模擬 Cron 設定：

/tmp/behaviorguard_test/etc/cron.d/day27_chain_f304ffb3b3

設定內容引用相同的測試腳本路徑。

結果觸發：

Rule     : BG-PERSIST-001
Name     : Cron Persistence
Severity : HIGH

這裡沒有修改真正的 /etc/cron.d，也沒有安裝實際的排程工作。

第四步：產生關聯告警

最後，Unified Pipeline 成功產生：

BG-CORR-006
Command Script Persistence Chain

Severity  : HIGH
Decision  : REVIEW_REQUIRED
Execution : DRY RUN

測試結果：

[PASS] Real BG-CMD-002 detected
[PASS] Real BG-FILE-003 detected
[PASS] Real BG-PERSIST-001 detected
[PASS] BG-CORR-006 generated
[PASS] Three original Event IDs linked
[PASS] Same UID verified
[PASS] Real monitoring chain completed
[PASS] Correlation Response Audit linked

這代表三個不同來源的真實偵測結果，已經能夠透過 Correlation Engine 進行關聯分析，並將結果送入 Response Dispatcher 和 Audit Log。

五、整合 All-in-One Monitoring Agent

完成關聯分析後，我們發現另一個問題。

原本的 agent/behaviorguard.py 只能同時執行 Process Monitor 和 Network Monitor。

File Monitor 雖然已經可以獨立執行，卻還沒有正式加入統一啟動器。

所以這次修改了：

agent/behaviorguard.py

使用 Python 的 threading 同時啟動三個監控器。

核心架構：

agent/behaviorguard.py
        │
        ├── Process Monitor
        │       └── Process / Command Rules
        │
        ├── Network Monitor
        │       └── Network Rules
        │
        └── File Monitor
                ├── File Rules
                └── Persistence Rules
                        │
                        ▼
                Unified Pipeline
                        │
                        ▼
                Correlation Engine
                        │
                        ▼
                Response Dispatcher
                        │
                        ▼
                    Audit Logs

Persistence Detection 不需要另外開啟一個監控器，因為它可以直接分析 File Monitor 收集到的檔案異動。

什麼是 Thread？

Thread（執行緒）可以理解成同一個程式裡面，同時進行不同工作的執行單位。

例如：

Thread 1：持續檢查程序

Thread 2：持續檢查網路連線

Thread 3：等待檔案系統事件

三個 Thread 都在同一個 Python 行程內，因此可以共用同一個 Unified Pipeline 和 Correlation Engine。

整合完成後，只要執行：

cd ~/behaviorguard
source .venv/bin/activate
PYTHONPATH=. python3 -u agent/behaviorguard.py

就可以啟動整套監控系統。

實際輸出：

========== BehaviorGuard ==========

[INFO] Unified Monitoring Agent
[INFO] Process + Network + File
[INFO] Persistence detection via File Monitor
[INFO] Multi-Source Correlation enabled
[INFO] Live response policy: DRY RUN

[START] Process Monitor
[START] Network Monitor
[START] File Worker
[START] File Monitor

[INFO] Watching: /tmp/behaviorguard_test
[INFO] Three monitor workers launched

這次修改的不只是啟動器，也調整了 monitor_files()，加入 stop_event，讓主程式收到停止要求時，可以通知 Watchdog 正常關閉。

六、Polling 與 Event-Driven 的差別

這次整合的過程中，我也重新了解了 BehaviorGuard 到底是怎麼持續監控 Linux 的。

其實我們目前有兩種不同的監控方式。

1. Polling（輪詢）

Process Monitor 會定期讀取 Linux /proc，Network Monitor 則定期透過 ss 取得 TCP 連線狀態。

簡單來說，就是每隔一段時間重新檢查一次。

優點是實作較簡單，不需要額外開發核心模組。

缺點是如果某個程序或連線存在時間太短，可能在兩次掃描之間出現又消失，導致系統沒有偵測到。

2. Event-Driven（事件驅動）

File Monitor 使用 Watchdog，在 Linux 上透過 inotify 接收檔案系統事件。

例如建立檔案時：

建立檔案
   ↓
Linux inotify
   ↓
Watchdog
   ↓
File Monitor
   ↓
Detection Engine
   ↓
Alert

這種方式不需要一直重新掃描全部檔案，而是等待檔案變化通知。

不過它只能監控指定的目錄，也不能直接取得所有檔案事件的操作程序 PID。

七、遇到的問題與解決方法

問題一：BG-FILE-003 沒有觸發

一開始建立：

/tmp/behaviorguard_test/day27_test.sh

但沒有產生 Alert。

後來檢查才發現，原本的 Detection Rule 會透過 normalize_lab_path() 把實驗根目錄映射成 /。

因此真正符合可疑暫存路徑條件的位置是：

/tmp/behaviorguard_test/tmp/day27_test.sh

調整測試位置後成功觸發。

這次讓我學到，規則沒有觸發不一定是程式錯誤，也可能是測試資料沒有符合規則的判斷條件。

問題二：Python 虛擬環境沒有啟用

我們發現最近使用的是 Kali 系統 Python，而不是原本建立的 .venv。

檢查後確認 .venv 還存在，但缺少 psutil。

因此重新啟用虛擬環境並安裝套件：

source .venv/bin/activate
python3 -m pip install psutil

最後將版本記錄到 requirements.txt：

psutil==7.2.2
watchdog==6.0.0

這樣未來可以比較容易重建相同的 Python 執行環境。

問題三：原本的主程式沒有啟動 File Monitor

雖然 File Detection 已經成功，但平常執行 agent/behaviorguard.py 時，只有 Process 和 Network 兩個監控器。

因此我們修改主程式，新增第三個 Thread，並將 File Monitor 接入統一 Pipeline。

最後透過實際建立檔案，確認 Watchdog 的 CREATED、MODIFIED、DELETED 事件都能正常被接收。

問題四：如何安全關閉監控系統？

原本 File Monitor 主要依賴自己的 KeyboardInterrupt 處理。

但當它被放進背景 Thread 後，主程式收到 Ctrl+C，不一定會直接把中斷送到 File Monitor 的 Thread。

因此新增 stop_event，讓主程式可以通知 Watchdog 停止。

測試結果：

^C
[INFO] Shutdown requested
[STOP] File Monitor
[INFO] Process/Network daemon workers will stop with the Python process
[INFO] BehaviorGuard shutdown complete

目前 File Monitor 可以正常結束，Process 和 Network 則仍依靠主 Python 行程結束時停止 daemon threads。完整的三個監控器優雅關閉機制還有改善空間。

八、Day27 成果與心得

今天最重要的成果不是增加更多 Detection Rules，而是把之前寫好的功能真正整合起來。

目前已經完成：

• File 與 Persistence Alert 接入 Unified Pipeline。
• 新增 BG-CORR-006 跨來源關聯規則。
• 使用 UID、腳本路徑、時間順序與 Event ID 進行關聯分析。
• 完成真正 Linux 事件的端到端測試。
• 整合 Process、Network、File 三個 Monitor。
• 使用同一個主程式持續監控。
• 保留 Response Dispatcher 的 DRY RUN 安全機制。
• 完成 Watchdog 的正常停止流程。

我原本以為 EDR 主要就是偵測可疑程序或網路連線，但做到今天才發現，單一偵測功能和完整監控系統之間還有很大差距。

一套系統除了要能發現異常，還需要統一事件格式、管理不同監控來源、建立事件之間的關聯，最後再決定應該如何回應。

目前的 BehaviorGuard 仍然是原型，還沒有商用 EDR 的完整可見性，也不能證明每條關聯事件都存在直接因果關係。

不過 Day27 讓整個專案從多個獨立的監控功能，往真正整合的 Linux Endpoint Detection & Response 系統更進一步。

下一篇 Day28，我們將開始改善 Detection Reliability 和 Response Safety，包含重複告警、誤報控制與回應安全性，讓 BehaviorGuard 不只可以偵測，更能穩定且謹慎地處理安全事件。