昨天我們成功修改了：

/etc/pqc_secret_keys.conf

並且在 Wazuh Dashboard 中看到 Rule 550：Integrity checksum changed。

這代表 Wazuh 確實發現 Honeyfile 遭到修改。

不過在實際事件調查中，只知道：

「檔案被修改了」

其實還不太夠。

我們還希望知道檔案什麼時候被修改，以及修改前後的完整性資訊有什麼不同。

所以今天就來拆解昨天產生的 FIM Alert。

1. 重新查看昨天的 FIM Alert

回到 Wazuh Dashboard，找到昨天產生的 FIM Event。

可以看到：

Decoder：
syscheck_integrity_changed

Rule ID：
550

Rule Level：
7

Description：
Integrity checksum changed.

這代表 Wazuh 判斷監控中的檔案完整性資訊發生了變化。

不過真正值得看的資訊，其實在事件的詳細內容裡。

2. Hash 是什麼？

在 FIM Alert 中，可以看到：

MD5
SHA1
SHA256

這些都是雜湊演算法（Hash Algorithm）。

可以簡單把 Hash 想成：

根據檔案內容計算出來的一組「數位指紋」。

例如原本的檔案：

PRIVATE_KEY=quantum_safe_key_99887766

可能得到：

SHA256 → Hash A

當我加入：

PRIVATE_KEY=hacked_by_attacker_0000

檔案內容改變後：

SHA256 → Hash B

因此：

修改前 → Hash A
修改後 → Hash B

即使只是修改一小部分內容，計算出來的 Hash 通常也會完全不同。

這讓我們可以判斷：

目前的檔案是否仍然與先前記錄的狀態一致。

3. Wazuh 記錄 Before / After

這也是昨天 Dashboard 截圖裡很重要的一部分。

在事件詳細資訊中，可以看到類似：

hash_before
hash_after

概念上就是：

原始 pqc_secret_keys.conf
        ↓
SHA256 Before
        ↓
檔案遭到修改
        ↓
SHA256 After
        ↓
Before != After
        ↓
Integrity Changed

所以 Wazuh 不只是單純收到：

「有人動過檔案」

而是能留下修改前後的完整性資訊。

這些資料對後續事件調查非常有幫助。

4. 除了 Hash 還能看到什麼？

FIM Alert 不只有 Hash。

依照監控設定與事件類型，我們還可能看到：

• 檔案路徑
• 檔案大小
• 修改時間
• 權限
• Owner / Group
• inode
• MD5
• SHA1
• SHA256

例如：

/etc/pqc_secret_keys.conf

如果原本檔案大小是：

100 bytes

攻擊者加入新的內容後變成：

138 bytes

除了 Hash 改變之外，檔案大小也可能跟著改變。

這些資訊都可以成為判斷事件的線索。

5. Hash 能不能告訴我「改了哪一行」？

這裡有一個很重要的觀念。

Hash 可以告訴我們：

「檔案內容跟以前不一樣了。」

但單靠 Hash 本身，不能告訴我們：

「攻擊者修改了第幾行、加入了什麼內容。」

例如：

SHA256 Before：
abc123...

SHA256 After：
def456...

我們可以確定檔案變了，但不能只靠這兩個 Hash 反推出修改內容。

因此 Hash 比較像是：

完整性驗證的證據。

而不是完整的檔案修改紀錄。

6. 從「警報」變成「調查線索」

經過昨天與今天的實驗，整個流程已經不只是：

檔案被修改
    ↓
Alert

而是：

Honeyfile 遭到修改
        ↓
Wazuh FIM 偵測
        ↓
產生 Alert
        ↓
查看檔案路徑
        ↓
比較 Before / After
        ↓
檢查 Hash、大小、時間等資訊
        ↓
進行後續事件調查

這也是我覺得 FIM 真正有價值的地方。

Alert 只是告訴我們「有事情發生」。

而 Alert 裡面的資料，才是後續分析的重要線索。

7. 但警報越多真的越好嗎？

做到這裡，FIM 看起來非常方便。

那是不是乾脆：

/etc
/home
/var
/usr
...

全部打開 Real-time Monitoring？

其實這樣反而可能產生新的問題。

Linux 本身每天就有大量正常檔案異動。

如果全部都產生 Alert：

正常系統更新
      ↓
大量檔案改變
      ↓
大量 FIM Alert
      ↓
真正重要的警報被淹沒

這就是資安維運很常遇到的：

False Positive 與 Alert Noise。

因此下一篇，我們就來處理 FIM 的另一個重要問題：

怎麼讓 Wazuh 不要什麼都叫？

今日總結

今天從昨天的 Rule 550 Alert 中進一步了解了 Wazuh FIM 所留下的資訊。

其中最重要的是：

檔案原始狀態
      ↓
Hash Before
      ↓
檔案被修改
      ↓
Hash After
      ↓
完整性發生變化
      ↓
Wazuh Alert

Hash 可以協助我們驗證檔案完整性，但它本身並不能直接告訴我們檔案的哪一行遭到修改。

所以真正進行事件調查時，還需要搭配檔案資訊、Log 與其他事件一起分析。

下一篇將完成 FIM 這一週的最後一塊拼圖：

如何避免大量正常檔案異動，把真正重要的資安事件淹沒？

也會回頭看看為什麼我們前面要特別設計：

pqc_secret_keys.conf

這種正常情況下不應該被修改的 Honeyfile。