故事背景

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！）原则，不是吗？