WAF摸到了什么天花板？

对于 WAF 这类按照流程执行的安全检测类产品而言，在现代化商业环境下，其能力上限往往被禁锢住了。

这是因为WAF的检测策略选择（例如根据数据的元信息选择要执行的检测模块）、检测逻辑（对于特定检测模块内部运行细节的调整）以及拦截动作（如何封禁、如何放行、如何记录日志）等，在投入使用时已经确定。在实际检测过程中，WAF按照预设定执行，很难“临阵”快速调整，但业务却十分复杂多变。

「更进一步，WAF的核心检测能力对于大部分用户而言像是一个“黑箱”，封装在内部。
对于传统安全厂商的此类设备而言，组合检测能力的方式通常是使用一些被称为“胶水”的代码，以某种确定性的方式，将自身产品所提供的若干个检测“黑箱”组合起来：这些“黑箱”们按照固定的流程与组合策略，共同完成对于用户数据的安全检测功能。

这种传统方式的缺点很明显：一切流程都是固定的，产品在交付之后无法对流程进行更改，很难满足不同业务场景之下的实际需求。

“黑箱”风格的安全产品逻辑对于使用者而言非常不便并且难以理解。一方面，使用者很难真正理解一个安全产品的功能组合逻辑与执行细节，另一方面，即使能够理解某些局部细节，但也很难对其进行一定的“魔改”，以提升其安全效果。

一个通用的改进方法是在固定流程基础之上，对于其中某些重要环节，暴露一些预定义的配置给用户，让用户可以更改配置，在一定程度上对检测流程进行微调，从而能够更好的适应不同的场景。

但是配置文件也有其局限性。配置文件往往是在一个确定的代码框架内、对于代码已实现的可配置功能进行控制，其生效的边界仍然是局限在代码给定的控制范围内，无法超越已有代码所限定的边界。

一个最简单的例子：一个功能模块如果完全没有暴露出必要的配置接口或根本没有实现某个功能，那自然也就无法对其进行任意粒度的控制哪怕只是最简单的开/关。


不同种类的业务所需要的检测引擎的种类、执行次序、规则强弱程度均有差别，通过灵活组合“黑箱”的能力，才能最大效用地保证各个业务的安全，而不会对不同业务产生非预期的安全效果，例如过于严格或者过于宽松。

由此诞生了雷池（SafeLine）FVM可编排引擎。

FVM（Fusion Virtual Machine）可编排引擎是一个由高级语言虚拟机实现的调度引擎，可以将流量检测引擎转化为一个可编程“内核”，让雷池（SafeLine）不依赖于既有代码，最大限度的灵活配置安全能力。

FVM的核心：动态编排

长亭过去一直尝试通过管理界面暴露更多的引擎配置接口，让雷池（SafeLine）的检测引擎能够尽可能的满足不同业务场景，但这通常需要修改代码，以及在已有业务逻辑抽象之上继续叠加新的抽象。调整一个特定检测逻辑的功能，从需求分析、开发、验证、到最终交付往往需要耗时几个月，非常不灵活。

借助 FVM，流量检测引擎不再是一个由代码+配置所决定的、确定性的执行流程，而是变成了由 FVM 程序所表达的、可以在运行时进行控制和编排的执行流，能够被更加细粒度的控制和调整，甚至在不改动代码的条件下扩展雷池（SafeLine）的功能。

在编排的同时，FVM 同样能够细粒度控制各类检测逻辑行为。FVM 将各个核心检测逻辑分割、抽象为独立的、自治的逻辑单元，通过提供有状态和无状态的逻辑实例，动态控制这些核心逻辑的呈现形式与行为，为不同业务场景提供最大化差异的检测逻辑组织与控制。通过提供“状态”的创建与维护机制，雷池（SafeLine）让相同的检测逻辑针对不同业务（例如域、API 路径等）呈现出完全不同的行为。

FVM 的本质：高级语言虚拟机

FVM 本质是一个高级语言虚拟机，它定义了一套 64 位计算机指令集，面向现代 64 位 CPU 指令集架构设计，充分利用了 64 位寄存器、多寄存器等特性来提升运行时效率。这些指令组成了 FVM 程序，作为雷池（SafeLine）流量检测引擎逻辑的承载；在运行时，FVM 通过解释执行这些指令，驱动着所有安全检测模块的运行；同时为了提升执行性能，FVM 利用 JIT 将程序动态编译成本地代码，加快检测流程的执行效率。

为了方便对 FVM 和雷池（SafeLine）流量检测引擎进行编程，FVM 提供了类似于 SQL 的声明式语言，让用户可以使用更简单的方式来控制流量检测引擎的执行逻辑。FSL（Fusion Selector Language）即为 FVM 所支持的前端语言，提供了描述式的、强类型约束的流程与检测匹配逻辑的描述与表达能力。FSL 语法上非常类似于 SQL，以一种接近自然语言的方式来控制逻辑的执行过程。

规则和表是 FSL 的两个最基本的抽象。规则实际上是一个个相互独立的 FVM「程序」，由 FVM 来解释执行，规则会返回用于控制表跳转逻辑的「控制状态」；而表则是规则的「容器」，决定了规则的执行顺序与调用关系。通常用户需要指定一个表作为「入口」，FVM 从该表的第一个规则开始执行，直到全部规则都执行完成为止，或遇到某个规则返回了终止状态。规则可以通过返回特定的「控制状态」来控制如何在表之间「跳转」，从而决定哪些规则被实际执行。

上面使用 FVM 所支持的声明式语言，定义了一个名为 process 的表，并将其设置为雷池（SafeLine）检测逻辑的入口。在该表里面有一个 ID 为 1 的规则，用来拦截访问 www.chaitin.cn/bbs.rar 的请求。可以看到其语法与 SQL 具有高度相似性，对于直接编写或者使用程序来生成都非常友好。

这个例子可以继续扩充。当业务需要更加复杂的处理逻辑时，可以通过定义更多的表、以及通过表之间的跳转来组合这些表，从而描述出更加复杂的、贴合用户业务场景的复杂执行逻辑。另外，还可以通过这些程序动态调整和改变不同检测功能的行为，例如控制是否执行特定逻辑、控制特定检测模块的开关、改变特定模块的检测敏感度、调整不同模块的执行次序等。

下图定义了一个针对不同业务的黑白名单功能：

FVM 可扩展：灵活调度安全算子

FVM 目标并不是直接执行某些复杂的、冗长的判定逻辑，而是作为编排和调度这些逻辑的动态“胶水”。因为，即使是再高效的虚拟机实现、有着再低开销的运行时效率、甚至有 JIT 的加成，这些代码的执行效率在同样情况下也不会超过高度优化的本地代码。

一个例子是，JVM 的 JIT 效率通常可以被认为“在最好情况下”能够达到 GCC -O2 的效果。

因此在实践中，这些核心的“复杂”逻辑通常以更高效的方式被实现，例如使用 C 或者 C++ 等，作为 FVM 的「扩展」；而用户使用 FSL 将这些「扩展」组织起来，利用 FVM 零开销的 FFI 调用这些扩展逻辑。即，FSL 更像是被使用来控制“执行流程”，而实际的复杂判定逻辑由「扩展」来执行，从而达到最高的执行效率。

FVM 提供了标准的扩展方式（FVM Extensions）。在该方式下，雷池（SafeLine）的各个安全功能，例如语义引擎、频率控制、动态防护等都被定义为一个个的“算子”。

FVM 的作用就是将这些算子组合起来，按照 FSL 所定义的流程将所需要的数据传递给流程中需要执行的各个算子，并从各个算子收集计算结果，将其作为数据来驱动后续算子的执行。

FVM 就像是一个强大的编排器或调度器，将雷池（SafeLine）全部的安全功能组合起来，以一种用户可控的方式来定义各个安全功能的组合与顺序，同时对各个安全功能进行细粒度的调控以适应不同的安全场景。

此外，FVM 为雷池（SafeLine）引入了一种全新的安全功能开发方式。基于这种方式，用户不仅能够对 WAF 已有逻辑动态地进行重新编排和调整，甚至还能动态地在现有系统中引入新的功能，例如实现一种新型的检测逻辑来应对某种突发的漏洞，而不仅仅只是基于当前产品所支持的检测能力。

FVM 能够支持使用 C、C++、JavaScript、Rust 等语言进行动态扩展，用户只需要通过 FVM 所支持的语言来编写一段特定的检测程序，动态加载到雷池（SafeLine）的检测引擎中，便可以实现对检测功能的扩充。

不被束缚的下一代WAF

由于 FVM 可以控制雷池（SafeLine）的完整检测流程，因此可以在处理过程中灵活插入任意检测相关的逻辑，甚至与其它类型安全产品实时互动。

例如可以直接在雷池（SafeLine）的检测逻辑中对接自有风控平台，根据风控平台返回的结果来选择对当前请求的处理动作（阻断或放行）；也可以将已有的封装好的检测逻辑直接插入到雷池（SafeLine）的检测流程中，根据客户的需求来按需扩充WAF的能力；甚至将流量动态牵引到其它环境，进行更加深度的检测或返回具有欺骗性的内容给攻击者（例如蜜罐）。

至此，下一代WAF的能力上限将不再被束缚。