影响suricata性能的因素

本篇文章简单聊一下规则对于性能的影响以及如何评价一个规则写的好坏，即规则的评价标准。

对于网络处理的产品来说，性能是非常重要的一个方面。影响性能主要包含两个方面：
1，一条流需要匹配的报文数量。
2，每个报文需要匹配的内容长短，比如是匹配payload的全部长度还是部分长度。
3，每个报文需要匹配的次数，即规则集的大小。规则集决定了最终编译成为suricata内部的模式结构的规模。
4，不同类型的规则，一般来说字符串匹配的规则比较耗时，而传输层一下都是二进制协议规则，匹配相对耗时较少。

减少报文匹配数量
1，在减少报文匹配数量方面，suricata的做法是分组。按照规则中的端口分布以及TCP，UDP传输层的协议，将规则分成若干个组，当相应端口的报文到来之后，送到对应的分组中匹配，这样能够有效的减少无用规则的匹配。例如一条ssh协议的规则，只有当22端口到来的时候才会进行匹配，其他的端口则不会去匹配该条规则。

2，除此之外，一般的网络产品的做法还包括，当一条流命中之后，后续的报文不在进入匹配引擎进行匹配。

3，通常对于DPI的产品来说，一般只需要识别一条流前16个报文甚至更少的报文，但是IDS产品来说，有的威胁可能隐藏的比较深，这样的话可能需要对整条流进行匹配，那么性能将会十分的低下。但是一般的漏洞利用多数在于HTTP请求部分，在HTTP响应的包多数在个位数的包都能够传输完毕，因此处于性能的考量，也可以设置像DPI那样前若干个报文的扫描，依,此来提高IDS的处理能力。

减少报文匹配的内容
当一个报文到达之后，需要匹配哪些字段的内容是由规则决定的。总的目标是，减少无用的匹配。
1，针对TCP的流量，如果能够加上offset,distance,within,depth等关键字，缩小需要匹配的报文长度，能够有效的减少匹配的耗时。通常初学者来说直接使用content是能够满足功能需求，但是对于性能的影响并没有考量。

2，针对一个HTTP的威胁流量，如果直接使用content匹配而不加入任何的修饰符的话，将会直接从传输层的上层进行匹配。字符串的匹配虽然有ac以及hs等高效的匹配方法，但是面对非常长的依然非常的耗时。相反好的规则写法是利用suricata提供的http关键字，去匹配对应的内容，例如http_uri,http_method,http_cookie等等。这样利用解码出来的http buffer中的内容，能够极大的减少无效内容的匹配，提高效率。

减少报文匹配的次数
1，一个报文可能会需要跟多个规则进行匹配，最简单粗暴的方法就是减少规则集的数量，从而减少单个报文的匹配次数。
2，suricata的prefilter机制，先匹配规则中的一个条件，将条件命中的规则筛选出来进入后续的全部条件的匹配。这样能够将不必要的规则提前剔除。关于prefilter我在前面的文章中有单独的分析。
3，suricata提供了大量的关键字用以编写检测规则，不同关键字的组合实对于检测引擎的检测效率是由影响的。因为不同的关键字意味着不同的检测流程，不同检测流程的组合效率肯定有高低之分，从这个角度来说有的规则写的比较好，有的规则写的就不太好。

那么什么样的规则是好的规则？什么样的规则是不好的规则呢？由于实际的业务场景不同，规则集的数量，以及需要送引擎的报文数量可能需要分局实际的业务场景来定。但是一个规则的好坏,suricata是给出了具体的评价标准。根据suricata提供的规则优化评价方法，可以指导我们如何写出更加好的规则。

最后，本身suricata内部的识别机制决定了好的规则流程只需要走一遍，而不好规则则需要走两边。
首先suricata的性能与规则集的规模是存在非常直接的关系。通常来说规则集的规模越大，suricata处理的性能越低。在规则匹配阶段，主要消耗性能的是字符串的匹配。而字符串的匹配分为单模的匹配以及多模的匹配。多模的匹配主要是Prefilter函数中 每条规则的fast pattern字符串构成的模式集合去匹配报文，多数情况下是匹配payload部分的内容。而单模的匹配主要是DetectRulePacketRules函数中，每条被prefilter命中的规则，规则中的每一个条件依次去匹配报文。由于经过prefilter之后，过滤出来的规则已经大大的减少，因此单模匹配消耗的性能并不是十分的突出。性能的消耗主要集中在prefilter的多模匹配部分。是想一下一个几万条左右的规则集，也将会拥有很庞大的多模模式集，每个报文都要去匹配，还是非常的耗性能。因此去除并不必要的规则，是规则优化的第一步。

按照之前的理解，肯定是匹配次数少的规则是好的规则。纯IP规则以及纯协议检测的规则可以能比之于字符串匹配规则性能高。关于规则的优劣suricata也是根据内部对于关键字的处理流程，给出了对于规则的意见分析建议，主要是EngineAnalysisFP和EngineAnalysisRules函数。EngineAnalysisFP主要是针对fast pattern的分析，EngineAnalysisRules针对的是整个规则的分析。

if (RunmodeGetCurrent() == RUNMODE_ENGINE_ANALYSIS) {
    fp_engine_analysis_set = SetupFPAnalyzer();
    rule_engine_analysis_set = SetupRuleAnalyzer();
}

比较影响性能的规则：
1，由于PCRE关键字对于性能的消耗比较大，为了避免频繁的PCRE匹配。PCRE通常和CONTENT关键字同时使用，在这种情况下，会先匹配content关键字，匹配成功之后
才会匹配PCRE的内容，以此来减少PCRE的匹配。因此如果一个规则中只有PCRE没有CONTENT，则该规则需要进行优化。

2，如果content使用了http等buffer的修饰符，规则中共同时存在PCRE的时候，同样建议PCRE使用这样的http buffer修饰符。使用修饰符的目的就是减少匹配，没有修饰符则会去匹配payload部分的内容。

3，如果规则头部的协议是HTTP，则所有的contentcontent以及PCRE同样应该使用HTTP buffer的修饰符进行修饰。

4，如果一个规则中使用了http buffer 修饰符修饰了content,则所有的content 都应该使用http buffer修饰符修饰，这样能够明显的减少内容的匹配。
5，如果协议头部明确了是TCP协议规则，建议加上flow 或者 flags 等关键字提高性能
6，如果规则头部指示规则是双向的，但是flow关键字指示规则是单向的，则不是一个好规则。
7，如果规则仅仅针对于客户端的端口，可能需要考虑是否合理。因为客户端的端口通常来说都是随机的，服务器的端口一般是有特定含义的。
8，如果规则中content或则和pcre匹配的是HTTP request的内容，比如http_method,这个时候使用了flow:to_client or from_server等下行的标志，则不合理，同样的像http_method不能和http_server_body等同时使用。
9，对于http_method这种很短的buffer，不建议使用pcre进行匹配.
10，对于使用depth/offset等关键字修饰raw content的情况，这时候对于payload以及steam的匹配流程都会进行检测，为了避免这种情况，该种情况建议使用alert tcp-pkt形式
11，协议头部规则是HTTP，但是fast pattern被设置为raw stream(非HTTP buffer修饰)，应该将fast pattern设置为http buffer。
11,规则头部没有方向标识符，则不是一个好规则。
12，不建议规则中使用双向检测的标识。
13，单包匹配的规则优于基于stream匹配的规则

本文为CSDN村中少年原创文章，未经允许不得转载，博主链接这里。