Home 应用安全 Suricata规则性能评估以及优化建议

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

by zinan

评估规则性能

开启profiling-rules功能:

768c9432f8fb26b01f9ef07502192502

查看评估日志:

20495bb78a4d2b7b4880cf4f4c584399

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

 

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

打赏
0 comment

You may also like

Leave a Comment

*

code

error: Alert: Content is protected !!