前面幾天，我們從 FIM 的基本概念開始，一路完成：

認識 FIM
   ↓
理解 inotify
   ↓
建立 Honeyfile
   ↓
設定 Real-time Monitoring
   ↓
模擬檔案竄改
   ↓
Wazuh 成功產生 Alert
   ↓
分析 Hash Before / After

做到這裡，FIM 基本上已經可以正常運作。

但實際使用時還有一個很重要的問題：

是不是監控越多檔案，系統就越安全？

答案其實不是。

今天就來談談 FIM 很容易遇到的另一個問題：False Positive 與 Alert Noise。

1. 為什麼不能什麼都監控？

假設我直接把大量系統目錄全部加入 Real-time Monitoring：

/etc
/home
/usr
/var

乍看之下非常安全，因為任何檔案發生變化都有機會被發現。

但問題是：

Linux 系統本來就一直在改變。

例如：

• 系統更新
• 安裝或移除套件
• 修改設定檔
• 程式產生暫存資料
• 使用者正常修改檔案
• 系統服務正常運作

這些行為都可能造成檔案變化。

如果全部產生警報，最後可能變成：

大量正常檔案變化
        ↓
大量 FIM Event
        ↓
大量 Alert
        ↓
管理者一直收到通知
        ↓
真正重要的事件被淹沒

這就是所謂的 Alert Noise（警報雜訊）。

2. False Positive 是什麼？

在資安監控中，我們常常會聽到：

False Positive（誤報）

簡單來說，就是系統偵測到某個行為並產生警報，但經過分析之後，發現它其實是正常行為。

例如：

系統管理員修改設定檔
        ↓
Wazuh FIM 偵測到修改
        ↓
產生 Alert
        ↓
調查後發現是正常維護

FIM 本身並不知道：

「這次修改到底是管理員還是攻擊者做的。」

它只能告訴我們：

「這個檔案的狀態發生變化。」

所以產生 Alert 並不代表一定遭到攻擊。

3. 真正重要的是監控範圍

因此在設定 FIM 時，比起把整台主機全部監控，我認為更重要的是：

找出真正具有安全價值的檔案。

例如：

/etc/ssh/sshd_config

如果 SSH Server 的設定突然遭到修改，就值得進一步確認。

除此之外，也可以針對特定敏感設定檔或重要目錄進行監控。

這樣可以減少大量沒有調查價值的事件。

4. 這也是我設計 Honeyfile 的原因

這幾天我特別建立：

/etc/pqc_secret_keys.conf

並不是因為系統真的需要這個檔案。

反而正好相反。

正常情況下根本沒有人需要修改它。

因此它的邏輯是：

一般系統檔案
     ↓
被修改
     ↓
可能正常，也可能異常


Honeyfile
     ↓
正常情況不應該被修改
     ↓
發生異動
     ↓
更值得進一步調查

這就是 Honeyfile 搭配 FIM 的價值。

它不是讓 Wazuh 變得「更會抓駭客」，而是讓我們主動建立一個具有較高調查價值的監控點。

5. 排除不需要監控的內容

除了選擇重要的監控位置之外，Wazuh FIM 也可以針對不需要的內容進行排除。

例如某些經常正常變化的檔案，可以使用 <ignore> 排除：

<syscheck>

  <directories realtime="yes">/important/path</directories>

  <ignore>/important/path/temp.log</ignore>

</syscheck>

這樣就可以保留重要目錄的監控，同時減少部分不需要的事件。

不過排除規則也不能設定得太寬鬆。

如果把真正重要的檔案一起排除，反而可能形成監控盲點。

所以實際維運時需要持續調整：

監控
  ↓
觀察 Alert
  ↓
找出正常行為
  ↓
調整監控範圍
  ↓
再次觀察

FIM 並不是設定一次之後就永遠不用修改。

6. 從「看得到」進一步到「看得懂」

經過這一週，我對 FIM 最大的感受是：

資安監控並不是資料越多越好。

如果每天產生 10,000 個 Alert，但其中絕大多數都沒有調查價值，那麼真正重要的事件反而更容易被忽略。

比起追求：

我監控了多少檔案？

更重要的問題應該是：

為什麼我要監控這個檔案？

如果它發生變化，代表什麼？

這個事件值得我調查嗎？

這也是我設計 pqc_secret_keys.conf Honeyfile 最主要的目的。

第二週總結

到今天為止，我們完成了整個 FIM 實驗：

Day 08
認識 FIM
     ↓
Day 09
Linux inotify
     ↓
Day 10
設計 Honeyfile
     ↓
Day 11
Real-time FIM
     ↓
Day 12
模擬檔案竄改
     ↓
Day 13
分析 Hash 與 Alert
     ↓
Day 14
降低 Alert Noise

從一開始單純知道：

「Wazuh 可以監控檔案。」

到現在已經實際完成了一套：

誘餌設計 → 即時監控 → 模擬竄改 → 告警 → 事件分析

的簡單偵測流程。

不過到目前為止，我們都在等待「檔案被修改」。

下一週，我準備換一種方式。

第三週：開始進攻

前面都是站在防禦者的角度觀察系統。

接下來我要從攻擊者的角度出發，從 Windows 攻擊機對 Ubuntu Server 進行 SSH 高頻率登入測試。

並且開始研究：

攻擊行為
   ↓
Linux Log
   ↓
Wazuh Decoder
   ↓
Wazuh Rule
   ↓
MITRE ATT&CK
   ↓
Security Alert

看看 Wazuh 到底是怎麼從一行普通的 Linux Log，判斷：

「這可能不是普通的登入失敗，而是一場攻擊。」

下一篇正式進入第三週。

在真正開始 SSH 攻擊之前，先來認識資安領域很重要的一套框架：

MITRE ATT&CK

以及接下來會實際測試的：

T1110 - Brute Force

先搞懂攻擊者「在做什麼」，再開始真正動手。