入侵检测规则匹配算法--单模匹配算法、多模匹配算法、hyperscan

入侵检测规则匹配算法，分为单模式匹配算法和多模式匹配算法。

1. 单模式匹配

单模式匹配，就是一个串跟一个串进行匹配，常见算法有：BM算法和KMP算法。

1.1 BF （Brute Force）暴力匹配算法

作为最简单、最暴力的字符串匹配算法，BF 算法的思想可以用一句话来概括，那就是，我们在主串中，检查起始位置分别是 0、1、2…n-m 且长度为 m 的 n-m+1 个子串，看有没有跟模式串匹配的。

• 理论上的最坏情况时间复杂度是 O(n*m)，但是，统计意义上，大部分情况下，算法执行效率要比这个高很多。
• 朴素字符串匹配算法思想简单，代码实现也非常简单。简单意味着不容易出错，如果有 bug 也容易暴露和修复。

2.2 RK（Rabin-Karp） 算法

BF算法每次检查主串与子串是否匹配，需要依次比对每个字符，所以 BF 算法的时间复杂度就比较高，是 O(n*m)。

RK 算法的思路是这样的：
我们通过哈希算法对主串中的 n-m+1 个子串分别求哈希值，然后逐个与模式串的哈希值比较大小。如果某个子串的哈希值与模式串相等，那就说明对应的子串和模式串匹配了。

模式串哈希值与每个子串哈希值之间的比较的时间复杂度是 O(1)，总共需要比较 n-m+1 个子串的哈希值，所以，这部分的时间复杂度也是 O(n)。所以，RK 算法整体的时间复杂度就是 O(n)。

跟 BF 算法相比，效率提高了很多。不过这样的效率取决于哈希算法的设计方法，如果存在冲突的情况下，时间复杂度可能会退化。极端情况下，哈希算法大量冲突，时间复杂度就退化为 O(n*m)。

2.3 BM（Boyer-Moore）算法

参考：http://www.cs.jhu.edu/~langmea/resources/lecture_notes/boyer_moore.pdf

我们把模式串和主串的匹配过程，看作模式串在主串中不停地往后滑动。当遇到不匹配的字符时，BF 算法和 RK 算法的做法是，模式串往后滑动一位，然后从模式串的第一个字符开始重新匹配。

如果我们可以一次性往后滑动好几位，那匹配的效率岂不是就提高了？

BM 算法，本质上其实就是在寻找这种规律，当模式串和主串某个字符不匹配的时候，能够跳过一些肯定不会匹配的情况，将模式串往后多滑动几位。

BM 算法构建的规则有两类，坏字符规则和好后缀规则。

• 坏字符规则：If we mismatch, use knowledge of the mismatched text character to skip alignments
• 好后缀规则：If we match some characters, use knowledge of the matched characters to skip alignments

2.4 KMP算法

KMP 算法的核心思想，跟上一节讲的 BM 算法非常相近。我们假设主串是 a，模式串是 b。在模式串与主串匹配的过程中，当遇到不可匹配的字符的时候，我们希望找到一些规律，可以将模式串往后多滑动几位，跳过那些肯定不会匹配的情况

2. 多模式匹配

多模式匹配，在一个串中同时查找多个串，常见算法有：AC自动机算法和Trie树算法。

2.1 Trie树

Trie 树，也叫“字典树”。顾名思义，它是一个树形结构。它是一种专门处理字符串匹配的数据结构，用来解决在一组字符串集合中快速查找某个字符串的问题。

举个简单的例子来说明一下。我们有 6 个字符串，它们分别是：how，hi，her，hello，so，see。我们希望在里面多次查找某个字符串是否存在。如果每次查找，都是拿要查找的字符串跟这 6 个字符串依次进行字符串匹配，那效率就比较低，有没有更高效的方法呢？这个时候，我们就可以先对这 6 个字符串做一下预处理，组织成 Trie 树的结构，之后每次查找，都是在 Trie 树中进行匹配查找。

Trie 树的本质，就是利用字符串之间的公共前缀，将重复的前缀合并在一起。

如果要在一组字符串中，频繁地查询某些字符串，用 Trie 树会非常高效。

构建 Trie 树的过程，需要扫描所有的字符串，时间复杂度是 O(n)（n 表示所有字符串的长度和）。

但是一旦构建成功之后，后续的查询操作会非常高效。如果要查询的字符串长度是 k，那我们只需要比对大约 k 个节点，就能完成查询操作。跟原本那组字符串的长度和个数没有任何关系。所以说，构建好 Trie 树后，在其中查找字符串的时间复杂度是 O(k)，k 表示要查找的字符串的长度。

字符串中包含的字符集不能太大，要求字符串的前缀重合比较多，如果字符集太大，那存储空间可能就会浪费很多。即便可以优化，但也要付出牺牲查询、插入效率的代价。

2.2 AC( Aho-Corasick)自动机

假设需要模式串有上万个，通过单模式串匹配算法（比如 KMP 算法），需要扫描几千遍。很显然，这种处理思路比较低效。

Trie 树就是一种多模式串匹配算法。我们用Trie树可以对上千个模式串字典进行预处理，构建成 Trie 树结构。这个预处理的操作只需要做一次，如果字典动态更新了，比如删除、添加了一个模式串，那我们只需要动态更新一下 Trie 树就可以了。

AC 自动机算法，全称是 Aho-Corasick 算法。其实，Trie 树跟 AC 自动机之间的关系，就像单串匹配中朴素的串匹配算法，跟 KMP 算法之间的关系一样，只不过前者针对的是多模式串而已。所以，AC 自动机实际上就是在 Trie 树之上，加了类似 KMP 的 next 数组，只不过此处的 next 数组是构建在树上罢了。

3. Hyperscan

Hyperscan是一款来自于Intel的高性能的正则表达式匹配库。它是基于X86平台以PCRE为原型而开发的，并以BSD许可开源在https://01.org/hyperscan。在支持PCRE的大部分语法的前提下，Hyperscan增加了特定的语法和工作模式来保证其在真实网络场景下的实用性。与此同时，大量高效算法及IntelSIMD*指令的使用实现了Hyperscan的高性能匹配。Hyperscan适用于部署在诸如DPI/IPS/IDS/FW等场景中,目前已经在全球多个客户网络安全方案中得到实际的应用。此外，Hyperscan还支持和开源IDS/IPS产品Snort(https://www.snort.org)和Suricata (https://suricata-ids.org)集成，使其应用更加广泛。

3.1 功能

功能多样

作为纯软件产品，Hyperscan支持Intel处理器多平台的交叉编译，且对操作系统无特殊限定，同时支持虚拟机和容器场景。Hyperscan 实现了对PCRE语法的基本涵盖，对复杂的表达式例如”.”和”[^>]”不会有任何支持问题。在此基础上，Hyperscan增加了不同的匹配模式(流模式和块模式)来满足不同的使用场景。通过指定参数，Hyperscan能找到匹配的数据在输入流中的起始和结束位置。更多功能信息请参考http://01org.github.io/hyperscan/dev-reference/。

大规模匹配

根据规则复杂度的不同，Hyperscan能支持几万到几十万的规则的匹配。与传统正则匹配引擎不同，Hyperscan支持多规则的同步匹配。在用户为每条规则指定独有的编号后，Hypercan可以将所有规则编译成一个数据库并在匹配过程中输出所有当前匹配到的规则信息。

流模式（streaming mode）

Hyperscan主要分为两种模式：块模式 (blockmode)和流模式 (streaming mode). 其中块模式为状态正则匹配引擎具有的模式，即对一段现成的完整数据进行匹配，匹配结束即返回结果。流模式是Hyperscan为网络场景下跨报文匹配设计的特殊匹配模式。在真实网络场景下，数据是分散在多报文中。若有数据在尚未到达的报文中时，传统匹配模式将无法适用。在流模式下，Hyperscan可以保存当前数据匹配的状态，并以其作为接收到新数据时的初始匹配状态。如图3所示，不管数据”xxxxabcxxxxxxxxdefx”以怎样的形式被分散在以时间顺序到达的报块中，流模式保证了最后匹配结果的一致性。另外，Hyperscan对保存的匹配状态进行了压缩以减少流模式对内存的占用。Hyperscan流模式解决了数据完整性问题，极大地简化用户网络流处理的过程。

3.2 原理

Hyperscan以自动机理论为基础，其工作流程主要分成两个部分：编译期(compiletime)和运行期(run-time)。

编译期
Hyperscan 自带C++编写的正则表达式编译器。如图1所示，它将正则表达式作为输入，针对不同的IA平台，用户定义的模式及特殊语法，经过复杂的图分析及优化过程，生成对应的数据库。另外，生成的数据库可以被序列化后保存在内存中，以供运行期提取使用。
运行期
Hyperscan的运行期是通过C语言来开发的。
用户需要预先分配一段内存来存储临时匹配状态信息，之后利用编译生成的数据库调用Hyperscan内部的匹配引擎(NFA, DFA等)来对输入进行模式匹配。Hyperscan在引擎中使用Intel处理器所具有的SIMD指令进行加速。同时，用户可以通过回调函数来自定义匹配发生后采取的行为。由于生成的数据库是只读的，用户可以在多个CPU核或多线程场景下共享数据库来提升匹配扩展性。

参考

数据结构与算法之美 王争
Intel高性能正则表达式匹配库——Hyperscan