ISCA2022 体系结构顶会 Fidas（阿里云）

Fidas: fortifying the cloud via comprehensive FPGA-based offloading for intrusion detection: industrial product

Authors:

Jian Chen, Xiaoyu Zhang, Tao Wang, Ying Zhang, Tao Chen, Jiajun Chen, Mingxu Xie,Qiang Liu
Alibaba Group, Hangzhou, Zhejiang, China

ABSTRACT:

网络入侵检测系统（IDS）是安全云计算的关键，但随着网络带宽的增加，它们也受到CPU计算能力的严重限制。因此，硬件卸载对于IDS服务器来说至关重要，以支持不断增长的数据包处理吞吐量需求。基于大规模IDS部署的经验，我们发现现有的硬件卸载解决方案存在根本的局限性，这些局限性阻碍了它们在生产环境中的大规模部署。在本文中，我们提出了一种基于FPGA的入侵检测卸载系统Fidas，该系统通过全面卸载主NIC、规则模式匹配和流量分类，避免了现有硬件解决方案的局限性。Fidas中的模式匹配模块使用了一种基于多级滤波器的方法来进行有效的正则表达式处理，而流速分类模块则采用了一种新颖的双堆栈内存方案来识别体积攻击下的热流。我们的评估表明，Fidas在模式匹配和流量分类方面实现了最先进的吞吐量，同时为其他安全相关功能腾出了处理器。Fidas部署在生产数据中心，并经过了性能、成本效益和DevOps灵活性的实战测试。

概述：

近年来，云计算中心在云计算的地位随着范式的转换 而变得越来越重要，成为网络攻击的高价值目标。对云计算中心的攻击包括基于web的攻击（跨站点脚本、SQL注入、路径遍历）、IP欺骗、DNS中毒、端口扫描和DDoS攻击等等。入侵检测和防御系统（IDS/IPS）作为一种有效的网络攻击防御方式，在建立安全的云环境方面中发挥这关键作用。IDS通常以集群的方式部署在互联网服务提供商（ISP）和云服务提供商（CSP）的内部骨干网络之间，通常由商品Linux服务器组成，并依赖于Snort和Suricata等开源IDS系统，提供用于数据包预处理、深度数据包检查和数据包日志记录等服务。然而，随着大数据技术的不断发展，现有的CPU计算能力限制了IDS的性能，无法满足网络带宽对不断增加的分组处理吞吐量的需求。例如，在40Gbps的网络带宽下，IDS服务器需要大约12个CPU内核才能与500个规则相匹配，ISP的聚合传入流量在数十Tbps数量级，这意味着仅仅匹配签名规则集就需要数百台服务器。ISP的聚合网络带宽每年几乎翻一番，这使得IDS集群的纵向和横向扩展在经济上是不可持续的。因此，有必要将IDS的软件堆栈卸载到硬件上。

最近，专家们提出了许多基于硬件的解决方案来加速IDS的操作，包括集成硬件设备和基于现场可编程门阵列（FPGA）的加速器。

1. 灵活性：已有的部分商业硬件产品（如Titan和GRegex）为了单一类型的数据提供高吞吐量和大型规则集支持，有着严格的软件结构与接口协议，为灵活的扩展与功能升级造成了阻碍。与此相对的，大型的CSP每周甚至每周都在为IDS生产集群部署软件堆栈。
2. 更新难度：目前的基于fpga的硬件解决方案在对更新后的规则进行重新合成，有可能耗时数小时才能自动生成，并且会触发更耗时的验证过程。同时，fpga在生产集群中的滚动升级操作难度也很大，需要对每个fpga进行流量引导/离线/位流上传和恢复在线等等操作。据作者考察，这些基于fpga的解决方案的规则更新总耗时可能长达数天，这在IDS生产系统中是不能接受的。
3. 单任务加速：现有的大多数硬件解决方案都关注于加速特定的功能，尤其是耗时的正则表达式匹配。然而实验证明，想要实现目标的吞吐量加速效果，仅靠单任务加速是无法实现的。即使假设加速器无限快，也无法在单个服务器占用空间实现100Gbps的线路速率。
4. 不平衡卸载：现在最先进的解决方案如Pigasus，高度偏向于加速基于签名的入侵检测，而很少偏向于加速对DDoS攻击的流量分类检测。只加速基于签名的入侵检测是不平衡的，其在DDoS攻击检测中消耗的大量CPU算力会导致性能和成本效益达不到预计的提升。

这些问题主要是由于IDS加速器部署过于复杂而导致的。由于以上的限制，目前的硬件解决方法无法大规模部署在生产数据中心。为了解决这些限制，我们提出了Fidas，一个基于fpga的入侵检测卸载引擎，全面卸载网络数据包预处理，规则模式匹配和流量速率分类。Fidas通过协调基于软件的规则预处理与基于硬件的多级过滤和正则表达式匹配来加快规则模式匹配。规则预处理组件将原始规则分解并转换为适合每个过滤阶段的子规则。多级过滤器使用自定义的规则将大部分无害流量过滤掉，然后到达更耗时的正则表达式匹配引擎。将规则预处理重新定位到软件中可以在硬件中实现更有效的规则模式匹配，同时促进快速的规则更新，这是Fidas与其他现有解决方案之间的关键区别。另一方面，为了加快流量分类速度，Fidas采用了一种新的双堆栈内存管理方案，根据网络流量的速率信息将网络流量划分为多个区域。然后利用硬件引擎有效地收集流量统计信息，并对流量进行分类，以便进行DDoS检测。总的来说，Fidas实现了IDS服务器中主要计算密集型任务的卸载平衡，同时保持了扩展的灵活性和规则更新的快速性。

背景：

基于网络的入侵检测通常依靠两种方法：基于签名的入侵检测法和基于异常的入侵检测法。前者从数据包中提取签名信息，并将其定义为一组规则或模式，并将其与已知的攻击签名进行比较。该方法可以在发现新的攻击时将其添加到签名库中，在不修改攻击特效的前提下进行扩展，具有一定的灵活性。Snort是一种流行的开源IDS，它使用基于签名的技术，已在多个云平台中采用，以保护网络免受恶意活动的侵害。Snort所使用的描述攻击签名的规则集由专门的安全团体进行更新与维护。后者使用基于异常的方法，凭借有效的大容量DDoS攻击检测能力被广泛应用在各大csp的IDS服务器中。IDS通常在一段时间内构建当前网络活动的配置文件，并使用行为分析程序对收集的配置文件进行分析，从而区分恶意流量和正常流量。通过将流量与给定阈值进行比较，IDS可以识别恶意流量并将其转发给黑洞路由器。

IDS中的正则表达式匹配通常优先使用自动机进行处理，包括DFA与NFA。前者一次只有一个活动状态，只需要对状态转换表进行一次查询就可以进入下一个状态。相比之下，基于NFA的方法可以并行处理多个匹配状态，但同时也需要同时维护多个活动状态。一般来说，DFA适用于较简单的正则表达式的匹配，一旦复杂度提升，状态的数量变会大大增加，构建可管理的状态转移表的难度也大大增加。另一方面，基于NFA的方法由于其对多状态处理的并行处理能力，在IDS的实际构造中被广泛采用。

下图展示了正则表达式 ( A B ∣ C D ) A F F { 1 , 8 } G (AB|CD)AFF\{1,8\}G (AB∣CD)AFF{1,8}G的NFA状态转移图和对应的位图，包含16个状态，每个状态包括一个ID和一个ASCII字符，简洁的表明了状态之间的转移关系。右边的位图通过0/1表示了所以可以向前过渡的状态，距离$k$即表示两个状态之间的跨度。具体来说，给定当前的状态集$S$，$(S\&shift-kbitmap)>>k$即可计算出和S相距为k的所有可能得后续状态，得到过渡距离不大于𝑡的后继状态集$S_{k\_all}$。

如果存在任何当前状态的Extra-trans位图，则使用$S_{k\_all}$对它们进行处理，以获得最终的后继状态集$S_{succ}$。因此，可以使用以下步骤执行正则表达式模式匹配:

1. 从当前状态集计算$S_{succ}$；
2. 根据输入字符和图形获取可达状态集；
3. 对$S_{succ}$和可达状态集进行逻辑与运算，得到一个新的状态集；
4. 如果这个新的状态集包含NFA图中的最终状态，则输入字符串匹配正则表达式模式；否则，流程将从步骤(1)继续，新状态集作为当前状态集。

Snort 3.0 + hyperscan是目前比较先进的NFA正则表达式匹配方法，其缓解了基于状态机的设计非常消耗内存/逻辑这一挑战。Snort规则由三类模式组成：头匹配、一组精确匹配字符串和一组正则表达式。如果所有模式都被识别，则数据包将触发该规则。为了避免检查每个索引和每个数据包的每个模式，规则集被设计为两步匹配过程。在Snort中，MSPM（Multi-String Pattern Matching）负责检查报头匹配和一个高度选择性的精确匹配字符串(称为快速模式)，其结构如下图所示。只有同时匹配报头和快速模式的数据包才会被转发到完全匹配阶段，该阶段会检查正则表达式和任何次要精确匹配字符串。

hyperscan首先检查包的报头是否匹配。在所有10K规则中，只有大约400个唯一的报头匹配值。共享相同报头匹配字段的规则被称为属于相同的端口组，端口组模块输出数据包匹配的一组端口组id，平均一个数据包匹配2个端口组。然后检查数据包的快速模式字符串匹配。对于每个端口组，都存在一个字符串匹配器，用于检查该端口组中所有规则的快速模式。Snort必须检查数据包匹配的每个端口组的每个字符串匹配器。在字符串匹配器中，Snort必须遍历负载的每个索引，检查它是否与端口组中的任何快速模式匹配，这一过程在hypercan中使用哈希表集合而不是状态机。

为了减少昂贵的顺序查找次数，每个字符串匹配器在哈希表之前包含一个simd优化的Shift-Or过滤器。Shift-Or算法是一种基于前缀搜索的字符串匹配算法，它基于将模式串转换为一个位向量（称为掩码），用于在文本串中检测是否存在匹配。掩码是一个与模式串长度相等的位向量，其中每个位表示该位是否出现在模式串中。

在运行期，Shift-Or算法对每个位置的输入字符查表得到对应的位掩码，并将状态掩码左移后与当前字符的位掩码做OR运算得到新的状态掩码。在处理单字符串匹配时，每个位置的状态只需一个位来表达。在处理多字符串匹配时，若字符串规则数量为$k$，那么每个位置的状态可用$k$位来表达。状态掩码中每个位置每位表示该位置上对应字符串的匹配状态。

SHIFT-OR算法可描述为：
$$state=(state<<k)|mask(c)$$
其中$k$为字符串规则数量，$c$为运行期某位置的输入字符，$mask(c)$为字符$c$对应的位掩码，$state$为运行期状态掩码。

Shift-Or过滤器为数据包的每个字节索引输出‘0’或‘1’，表明该索引是否与哈希表中的任何快速模式匹配；不需要检查从Shift-Or阶段产生‘0’输出的索引。

总览：

Fidas由三个主要单元组成:数据包预处理、规则匹配和流量分类，如下图所示。包预处理单元完成主网卡的功能，包括包收发、解析、排队和重组。规则匹配单元处理报文内部的正则表达式模式匹配，而流量分类单元则负责对报文的发生情况进行分流处理，以便进行DDoS检测。

与Pigasus相比，Fidas对IDS服务器中使用的基于签名和基于异常的入侵检测方案都进行了加速，实现了均衡的卸载。与GRex相比，Fidas和Pigasus都实现了基本的数据包处理功能，允许在有效负载数据上立即应用字符串匹配算法，并且对于在单个服务器中实现100Gbps线速率的正则模式匹配至关重要。从长远来看，Fidas体系结构代表了IDS服务器更全面、更均衡的卸载趋势。

规则匹配：

Fidas的规则匹配模块采用与pigasus类似的分层模式匹配方法，因为两者都使用一组分层过滤器来减轻完全匹配阶段的负担。Fidas的优势在于更加强调规则的分析与分解。作者发现，每个规则都包含一个或者多个模式，并且规则集中的多个规则可能共享一些公共模式。通过将规则分解成多个子规则，可以使用唯一的子规则来驱动匹配过程，从而减少有效规则集的大小，提高匹配效率。为了促进这种以规则为中心的匹配过程，在模式匹配期间为每个规则和子规则分配了各自的ID，用于索引、查找和标记。规则匹配驱动的架构如下图所示：

在正则匹配上，Fidas提出了软硬协同，数控分离的面向DevOps的卸载设计模式。它将规则分析和拆解，子规则编排等工作交由软件处理，硬件根据编排好的子规则分级进行匹配。

首先，软件进行规则的预处理，生成硬件子模块对应的各种数据结构。通过这种将控制层与数据层解耦的思想，实现通过控制路径来动态地更新规则并分派到硬件的软硬件协同设计方法，达到一定的灵活性与敏捷性。它还带来了硬件透明优化的机会，在离线规则处理中利用更复杂的算法来进一步提高性能，而无需升级FPGA位流。

其次规则匹配引擎分为四个子模块，Pre-filter、S-filter、rule lookup以及NFA引擎。Pre-filter使用规则集中的一组关键字来过滤掉无害的报文；S-filter使用转移较远的子字符串作为子规则集，在数据包到达NFA前进行进一步的筛选；rule lookup用来从子规则ID中恢复规则ID，为基于NFA的正则表达式匹配做准备。

• Pre-filter：
  Pre-filter是第一级过滤器，使用从给定规则集中的所有模式中提取的关键字字符串，有效地过滤掉尽可能多的无害数据包。在匹配的情况下，预过滤器还负责确定要与下一级过滤器比较的子规则候选项。因此，预过滤器包含关键字字符串匹配组件和子规则ID查找组件。关键字字符串匹配的算法与Hyperscan类似，他选择所有模式中尽可能唯一的关键字字符串，并将这些关键字字符串编码为2D位图列表，每个2D位图表示一个两字节的字符串，行和列对应第一个和第二个字节。通过使用位图列表来执行两字节的字符串匹配，但是两字节的关键字过短，有可能导致关键字匹配误判，从而无法达到理想的过滤速度。相反，如果关键字过长，银河灰产生大量不成比例的位图，对有限的fpga资源造成压力。在fidas中，经过对速度与性能的权衡，将关键字的长度设置为4字节，为每个关键字生成三个位图。作者还将位图大小从256 × 256位缩小到64 × 64位，以减少FPGA资源的消耗。

  哈希表解析位图中潜在的混叠，并为匹配的关键字提供子规则id。如上图种的b所示，每个哈希表槽由关键字字符串及其对应子规则的ID组成。它还有一个位表示是否有两个以上的子规则具有相同的关键字，在这种情况下，ID字段被解释为指向保存这些ID的链表的指针。在Fidas中，哈希表的每个条目都有6个这样的槽。通过这种方式，匹配的4字节关键字使用哈希函数索引到哈希表，并通过将自身与相应的关键字字符串进行比较来解决位图混叠问题。

• S-filter：
  S-filter对预过滤器通过的候选子规则进行处理，进一步对网络数据包进行筛选。Pre-filter使用4字节的关键字作为子规则，但大多数子规则由许多其他子字符串组成，S-filter可以利用这些子字符串进行进一步过滤。经过Pre-filter后，只有一小部分数据包可以到达S-filter，因此使用更复杂的移位或算法进行字符串匹配。为了平衡字符串匹配速度和硬件资源，作者将每个子规则的子字符串长度限制为不超过16字节，子字符串数量限制为不超过5个，然后为所有子规则设计一个子字符串表。

  S-Filter根据子规则ID从子字符串表中检索一个或多个子字符串，并使用shift-OR算法进行字符串匹配，如上图中的c所示。只有当每个子字符串都产生匹配时，子规则才被认为是匹配，否则将被丢弃。

• Rule Lookup：
  规则查找模块实现了两个目标:从子规则ID中查找规则ID，并进一步过滤掉不需要在NFA引擎中处理的子规则候选。作者利用了一下原理：只有当所有子规则都匹配并包含在候选列表中时，规则才被认为是匹配的。因此，如果子规则不在候选列表中，则对应的规则不匹配，并且所有子规则都不需要处理，除非它们也属于其他规则。

  具体来说，Rule Lookup执行两个步骤，（1）规则ID查找；（2）子规则ID匹配。首先查找每个子规则候选$S{R}_c$的规则，并根据其ID来检索其所有子规则$S{R}_i$。对于找到的每个规则，我们将其子规则$S{R}_i$与$S{R}_c$进行比较。如果$S{R}_i$是$S{R}_c$的子集，则将其子规则放入最终子规则候选列表中，并记录规则ID；否则，规则i被丢弃。

• NFA引擎：
  NFA引擎使用上文中描述的多状态转换方案，对在前一个过滤阶段幸存下来的数据包执行复杂的正则表达式模式匹配。它的硬件成本主要取决于NFA状态的数量，它决定了与状态转换相关的数据结构的大小，包括状态转换向量的长度和所需位图的数量。因此，有必要通过最小化其状态数来优化NFA图处理。

  

  作者发现，可以在基于NFA的正则表表达式匹配过程中，通过将最常见的模式之一“$Cm,n$”（其中C表示一个字符或字符集，m和n是其出现的下限与上限）进行状态简化，进一步降低匹配时产生的硬件成本。如上图所示，作者在规则预处理阶段对NFA图生成函数进行修改，使其能将原式中从状态7到状态14间的8个字符‘F’整合为一个可接受字符集S，从而避免其重复状态过大导致难以承受的开销。更新后的NFA与相关位图如上图所示，字符集的上限与下限被编码到了一个被称为loop-count的位图中。loop-count的具体控制逻辑如下：用计数器记录状态S第一次进入后执行的状态转换的次数。系统通过比较计数器值与下限和上限来确定S的后继状态。

  • 如果计数器在这两个限制之间，则允许其所有原始状态转换。
  • 如果小于下限，则S保持相同的状态，即S可以转换到的所有其他状态都被禁用。
  • 如果计数器大于上限，则S可以转换到原始转换位图中所指示的所有状态，除了S本身。

表现：

通过这样的设计，我们可以实现在100Gps线速下的正则匹配；同时支持10M流的流量分类而无丢包现象。与传统上采用Hyperscan的Snort相比，在达到相同的匹配吞吐量时，Fidas可以节省30～120个CPU核。这些省下的CPU核可以带来相对应的服务器节省，或者为其他应用提供算力，带来可观的成本降低和性能收益。

下图显示了在使用RT跟踪运行时，在Pre-filter、S-filter和Rule查找中每个包调用的子规则的平均数量。可以看到，对于规则集A，在预过滤之后的后续阶段处理只需要500个子规则中的2.7个。随着规则集大小的增加，每个数据包调用的平均子规则数也会增加，但其占子规则总数的比例大致保持不变。

下图(a)显示了不同数据包大小下Fidas的吞吐量。正如我们所看到的，对于大于800字节的数据包，Fidas可以达到100Gbps的线路速率。对于较小的数据包大小，有效负载吞吐量较低，因为对于较小的数据包，数据包头的开销更大。

总结：

Fidas已经在数据中心上规模化生产部署了两年。本文也对Fidas在实际生产部署中的经验, 总结了以下三点：

• 正则匹配和流量分类的综合卸载给入侵检测的效率提供了合力。具体来说，流量分类的卸载加速为DDoS攻击的检测响应时间减少了100多纳秒，从而更快的将DDoS流量从总流量中移除，这相应的也减少了正则匹配花在处理DDoS流量上的无效处理时间，提高了入侵检测的整体效率。

• 针对DevOps敏捷性的设计是具有很高价值的。在生产过程中，规则更新十分频繁，最短需在一天之内完成；而且整个IDS软件也经历了数次更新，但无需重新更改硬件。这体现了规则预处理和模式匹配解耦的面向DevOps的软硬协同设计在实际生产中带来的价值。

• 一个完全开放的软件栈是CSP采用卸载方案的重要因素。与基于DPU的商业方案相比，自研FPGA方案成本上不具优势，毕竟DPU有规模效应的优势。但是现有主流DPU软件栈并不完全开放，可能依赖于私有的库或运行时；而自研FPGA可以确保整个软件栈的兼容性和可控性，这对CSP来说是一个重要的考量因素。如果未来相关芯片厂商采取更加开放的策略，DPU开放式软件生态才有可能健康成长