故事背景

2022年5月16日，雲原生安全公司Isovalent的CTO宣佈開源了其內部開發了多年的基於eBPF安全監控和阻斷的方案：Tetragon (WayBackMachine 20220516)。 由於Tetragon宣稱可以防禦容器逃逸的Linux內核漏洞，但從Tetragon的設計來看只支援post-exploitation階段的檢測和阻斷，這種基於規則的檢測和阻斷遭到了安全研究人員Felix Wilhelm的質疑，此後幾天的討論引起了更多安全研究人員的注意，PaX/GRsecurity團隊成員Pawel Wieczorkiewicz在5月20日研究了兩個小時后基於CVE-2021-22555公開exploit擊穿了Tetragon的防禦機制， 隨後PaX/GRsecurity公開了其細節以及探討了為什麼防禦機制中不能單一依賴post-exploitation階段的檢測和阻斷機制。

為什麼Tetragon和大部分安全產品都會失敗

針對漏洞利用的方法（注：不是漏洞）的防禦機制通常會針對三個階段：Pre-exploitation（前漏洞利用階段），Exploitation（漏洞利用階段），Post-exploitation（後漏洞利用階段）。 越是工作於早期階段的防禦機制設計和開發難度越高而攻擊者繞過的難度也極高，比如PaX/GRsecurity的KERNSEAL/AUTOSLAB，而越是後期階段的防禦機制（更準確的說是檢測機制）設計和開發難度越低而攻擊者的繞過難度也非常低，比如常規的EDR/XDR。 下面是我們整理之前CVE-2021-26708漏洞利用防禦時給出的評估：

典型的安全產品比如EDR/XDR自身的防禦等級大約是「L1： I can win！“，Tetragon的防禦能力和它們幾乎在一個等級上，但Tetragon事件會帶來更大風險的問題是在於錯誤的威脅模型，因為Tetragon需要防護Linux內核而非應用層的攻擊，此次PaX/ GRsecurity團隊公開的針對kprobes的繞過方法也可適用於任何以hook機制實現的技術，此次大部分基於LKM（Linux Kernel Module）的防護方案都被此種方法攻陷，幸運的是VED的自防護機制對這種攻擊方法免疫，在面對高等級威脅場景時，安全產品須具備自防護能力，不然會陷入“who’s watching the watcher“的無限循環當中。

為什麼VED可以免疫

在我們之前的文章中介紹過面對多攻擊方的場景必須要求基於LKM機制實現的安全方案具備自防護能力：

在高級防護領域，這種防禦技術只是冰山一角。

eBPF/LKM實現面臨的問題

• 任何安全防禦機制的代碼引入Linux內核中可能會產生副作用比如鎖的問題，更嚴重的情況可能會導致競態從而變成可利用的漏洞。

• 特定场景才能验证的缺陷，安全机制在内核中很多实现都必须特殊处理。

• 性能問題，安全機制在設計之初至少得把目標場景納入考量，不然可能會出現底層代碼沒人維護而企業使用者也不關心中間配置的情況。

• 自防護，任何安全產品都有關具備自防護能力。

• 威脅模型，錯誤的威脅模型會導致“設計->實現->測試->交付->集成->部署->生產環境”的蝴蝶效應，最終複雜性會吞噬你。 比如在你的威脅是腳本小子，那或許普通的GNU/Linux發行版+最佳實踐（CIS/STIG）足以應對，而你的對手是最下面的隱藏玩家時恐怕在Linux內核層面就連VED也無法勝任，這種情況我們只會建議用戶選擇PaX/GRsecurity。

總結

隨著雲原生的流行，Linux內核安全成為了一個無法繞開的問題，某個容器被攻陷后可以向Linux內核發起攻擊，一旦成功則整個主機都會被攻擊者控制，如果你不想你的產品耗資上百萬美金后攻擊者兩個小時就攻陷的話，那應該認真的考慮是否應該從一開始就建立正確的威脅模型。 另外，eBPF機制更適合實現審計監控類的安全方案而非防護阻斷類，VED的eBPF版本也僅僅是為審計而設計，剩下的事情你應該讓SIEM和SOC團隊去做，在安全流程上我們也應該遵循KISS（Keep it simple， stupid！ ）原則，不是嗎？