Black Hat USA 2001 - Fnord: A Loadable Kernel Module for Defense and Honeypots

UNET 是一家中等規模網際網路服務提供商，擁有大量分散在外地的主機。Todd 和 Eric 的團隊開始陸續發現某些主機上出現核心模組型 rootkit。這問題的嚴重性在於：核心模組成為作業系統的一部分，享有無限權限，且可在系統運行時動態載入，系統管理員可能毫無察覺。更糟的是，傳統安全工具（如 tripwire 或 ps 指令）本身依賴系統呼叫，而 rootkit 已經修改了系統呼叫表，導致這些工具回報虛假資訊。用戶層工具基本上無能為力，除非 rootkit 作者留下破綻。

為了解決這個困境，團隊開發了 Fnord。其核心理念是將監控工具也置於核心層，從而獲得比 rootkit 更高的「視野」。Fnord 運作的方式如下：監控系統呼叫表。當 insmod 或 rmmod 執行時，Fnord 會在系統呼叫返回後立即檢查表項是否與匯出的核心符號（如 sys_open）相符；此外，Fnord 也會每秒定時檢查一次，捕捉任何透過不同管道載入的核心模組。任何不匹配都會觸發警報。

但光有偵測還不夠，Fnord 必須對攻擊者完全隱形。其隱形設計層次分明。首先，字元設備介面（用於管理員與 Fnord 通訊）不是常駐的，而是動態的——Fnord 監聽 /proc，當偵測到建立名為 "S-pipe" 的字元設備檔案時，才在對應編號上註冊自己；當檔案被刪除時，它立即註銷。這樣，攻擊者掃描所有 256 個設備編號時根本找不到它，除非在管理員實際操作時的一瞬間。其次，Fnord 透過記錄檔案的 dev/inode 對（而非檔案路徑或名稱）來隱藏檔案與進程，這樣即使攻擊者建立同名檔案也不會被誤隱藏。第三，檔案內容的篡改技術應用了 4KB 滑動緩衝區：Fnord 不知道檔案實際長度（因為它修改了內容），但透過每次讀取時重新處理一份 4KB 緩衝、修改其內容、然後分次返回給使用者，可以在緩衝邊界落在隱藏記錄上時仍正確處理。第四，環境變數密碼機制：只有設定 LEET_VAR 環境變數的進程才能看到隱藏的檔案和進程，而且 Fnord 儲存的只是該變數的 MD5 雜湊，無法反推密碼。環境變數本身也會被隱藏，使用者進程查看其他進程的環境變數時看不到它。

日誌機制是另一個巧妙的設計。Fnord 不依賴標準 syslog，而是建立平行的 /proc/sk_message 介面，同樣有 16KB 環形緩衝區。所有可疑活動都被靜默記錄到此：模組載入卸載、系統呼叫被攔截、檔案被修改、開啟敏感裝置。攻擊者完全看不到這份日誌，也無法刪除它（因為刪除本身也會被記錄，而且刪除操作會失敗）。他們被帶入一種虛假的安全感——認為自己成功清除了痕跡，殊不知所有行動早已被記錄。這給了運維團隊寶貴的情報蒐集機會。

演講中也展示了 Fnord 對其他防禦工具的保護。企業可以在 Fnord 隱藏的掩護下運行 Tripwire、主機型防火牆或蜜罐監控腳本，攻擊者即使取得 root 權限也無法發現這些工具的存在。更進一步，Fnord 會嘗試欺騙偵測工具如 Kstat：Kstat 透過比對系統呼叫位址與符號來發現 rootkit，但當 Kstat 試圖讀取 /dev/kmem 時，Fnord 會回傳虛假的系統呼叫表位址，讓 Kstat 看到一個「乾淨」的系統。

當然，Fnord 也有其局限性。如果攻擊者在 Fnord 載入之前就已入侵系統，或者攻擊者具備充分的核心知識，他們可以採取反制措施——例如在系統呼叫表重新封裝前後交替修改、偽造系統呼叫表位址、甚至在核心記憶體中尋找並刪除 Fnord 的程式碼段。然而這些都需要高度的技術知識。更根本的限制是：一旦允許攻擊者在核心層執行程式碼，防禦就變成了攻防遊戲。Fnord 選擇的「軟性」防禦策略（允許入侵換取隱形與情報）在這個約束下是實用的折衷。