一、什麼是 FIM？

FIM 的核心概念其實很簡單：

持續監控重要檔案與目錄，當檔案發生異常變化時產生警報。

假設今天伺服器上有一個重要設定檔：

/etc/ssh/sshd_config

正常情況下，它不應該頻繁被修改。

但如果某一天這個檔案突然被變更，可能只是系統管理員正常修改 SSH 設定，也可能是攻擊者入侵系統後試圖修改 SSH 服務。

單純看到「檔案被修改」並不能直接判斷這一定是攻擊。

真正重要的是：

這個檔案原本是什麼狀態？現在又變成什麼狀態？

這就是 FIM 想解決的問題。

二、FIM 到底在監控什麼？

很多人第一次聽到「檔案完整性監控」，可能會以為它只是檢查檔案還在不在。

實際上，能觀察的內容更多。

以 Wazuh 的 FIM 功能來說，可以針對指定的檔案與目錄監控多種變化，例如：

檔案被建立
檔案被修改
檔案被刪除
檔案大小改變
檔案權限改變
擁有者或群組改變
檔案雜湊值改變

其中「雜湊值」是非常重要的一項資訊。

假設某個檔案原本的 SHA-256 是：

Hash A

修改之後變成：

Hash B

即使檔名完全沒有改變，我們仍然可以知道：

這個檔案的內容已經跟之前不一樣了。

因此，FIM 的目的並不是阻止所有檔案修改，而是讓管理者能夠知道：

「哪些重要檔案，在什麼時間，發生了什麼變化？」

三、為什麼只有防毒軟體還不夠？

假設攻擊者成功取得一台 Linux Server 的存取權限。

他不一定會立刻丟一個明顯的惡意程式進去。

更有可能做的是：

修改 SSH 設定、加入新的帳號、竄改系統設定、建立持久化機制，甚至修改原本存在的腳本。

這些行為的共同點是：

攻擊者正在改變系統原本的狀態。

這也是為什麼 FIM 在端點防禦中很重要。

防毒軟體比較像是在問：

「這個檔案是不是已知的惡意程式？」

而 FIM 更關心：

「這個原本不應該改變的東西，為什麼突然變了？」

兩者解決的問題並不完全相同。

四、FIM 與 APT 攻擊有什麼關係？

APT（Advanced Persistent Threat，進階持續性威脅）通常不是「攻擊一次就離開」。

攻擊者可能會嘗試長時間停留在目標環境中，並逐步取得更多權限、蒐集資訊或建立持久化機制。

因此真正值得注意的，不只有「入侵發生的那一刻」。

還包括入侵之後產生的各種系統變化。

例如：

攻擊者取得初始存取
↓
提升權限
↓
修改系統設定
↓
建立持久化機制
↓
存取或修改敏感檔案
↓
持續停留在系統中

如果我們只看登入紀錄，可能只看到第一階段。

但如果重要檔案與目錄有 FIM 監控，當攻擊者修改這些內容時，就可能留下另一條可以追查的線索。

所以我不會把 FIM 當成「偵測 APT 的萬靈丹」。

比較準確的說法是：

FIM 是用來觀察端點重要檔案與系統狀態變化的重要偵測機制之一。

五、Wazuh 怎麼做到 FIM？

在 Wazuh 中，負責 FIM 的核心模組是：

syscheck

我們可以在 Agent 的設定中指定：

「我要監控哪些目錄？」

例如：

概念上就是告訴 Wazuh：

請幫我注意 /etc 底下的檔案是否發生變化。

當 Wazuh Agent 偵測到符合監控條件的變更後，相關事件會被處理並傳送到 Manager，最後透過規則產生安全警報，讓我們能在 Dashboard 中進一步查看。

整個流程可以簡化成：

重要檔案
↓
Wazuh Agent
↓
Syscheck / FIM
↓
偵測檔案變化
↓
Wazuh Manager
↓
Rules
↓
Alert
↓
Wazuh Dashboard

這也代表 Wazuh 並不是一直把整個硬碟的所有內容傳送回 Manager 比對。

真正的端點監控工作，是由 Agent 執行。

六、那是不是把整台主機全部監控起來最好？

看到這裡可能會產生一個很直覺的想法：

「既然 FIM 可以發現檔案異動，那我乾脆把 / 全部監控起來不就好了？」

理論上監控範圍越大，可以看到的變化確實越多。

但實務上這反而可能造成另一個問題：

大量 Noise（雜訊）。

Linux 系統本來就有很多檔案會正常變動。

套件更新、Log、暫存檔、服務執行過程，都可能產生大量檔案異動。

如果什麼都監控，最後 Dashboard 可能充滿正常事件。

真正重要的警報反而被淹沒。

所以 FIM 真正困難的地方，不是：

「能不能監控？」

而是：

「哪些東西值得監控？」

這也是資安監控很重要的一個觀念：

更多 Log，不一定代表更好的安全性。

我們真正需要的是有意義的事件。

七、我的實驗：如果放一個「不應該被碰」的檔案呢？

因此，我想做一個比單純監控 /etc 更有趣的實驗。

假設系統中存在一個看起來非常敏感的檔案，例如：

pqc_secret_keys.conf

從名字來看，它似乎存放了與 PQC（Post-Quantum Cryptography，後量子密碼學）相關的秘密金鑰設定。

但在我的實驗環境中，它真正的用途不是保存正式金鑰。

而是：

誘餌。

也就是 Honeyfile。

正常使用者與正常服務沒有理由去修改這個檔案。

所以如果它突然被修改、刪除或權限遭到變更，就值得我們進一步調查。

這個概念跟一般大量監控有點不同。

一般 FIM 是：

重要檔案
↓
有人修改
↓
產生警報

加入 Honeyfile 的思維之後則變成：

建立誘餌檔案
↓
正常情況沒有人需要碰它
↓
發生異常存取或變更
↓
提高事件的調查價值

也就是從單純的「監控重要檔案」，進一步思考：

能不能主動設計一個容易暴露可疑行為的監控點？

這會是接下來幾天實驗的核心。

八、今天的實驗目標

Day 08 主要先建立 FIM 的觀念，因此今天暫時不急著進入複雜設定。

我們先確定三件事情：

第一，FIM 的目的不是阻止檔案被修改，而是偵測與記錄重要檔案的狀態變化。

第二，不是監控越多越好，而是應該優先監控具有安全價值的檔案與目錄。

第三，除了被動監控既有的重要檔案之外，我們還可以加入 Honeyfile 的概念，建立一個正常情況下不應該被碰觸的誘餌。

接下來我的目標就是建立：

pqc_secret_keys.conf

並讓 Wazuh 對它進行監控。

不過在真正開始設定之前，還有一個問題值得先弄懂。

當 Linux 上的檔案發生變化時，Wazuh 到底是怎麼知道的？

難道 Agent 每一秒都把所有檔案重新讀一次嗎？

答案當然沒有這麼單純。
下一篇，我們就要往 Linux 底層再挖一層。
下一篇會開始研究 Linux 如何通知程式「檔案發生變化」，以及 Wazuh 的 Real-time FIM 背後到底是怎麼運作的。