Suricata规则性能评估以及优化建议

评估规则性能

开启profiling-rules功能：

查看评估日志：

有问题的规则按照以下方式优化。

减少报文匹配的内容
当一个报文到达之后，需要匹配哪些字段的内容是由规则决定的。总的目标是，减少无用的匹配。
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匹配的规则

打赏

微信扫一扫，打赏作者吧～