Suricata高性能配置

Love The Way You Lie 2023-07-11 11:09 15阅读 0赞

# 一.Suricata对包的规则检测 #

**1.为了高性能，将规则按照一定算法分很多组(例如如果出现带有UDP协议的数据包，则不需要TCP协议的所有签名)**  
**2.更多的分组有用更高的性能，但占用更多的内存，默认配置选项**

detect:
      profile: medium
      custom-values:
        toclient-groups: 2
        toserver-groups: 25
      sgh-mpm-context: auto
      inspection-recursion-limit: 3000

**profile**:可选high,medium,low,custom,high表示系统高性能配置分组，但会占用更高内存(在实际中,及时配置了high也不会占用多少内存);在使用custom的时候，custom-values中的配置才会生效，最大值为65000;  
**sgh-mpm-context**:表示是否MPM共享一个上下文，跟具体的匹配算法有关，有些规则分组需要可以使用共享上下文，有些需要独立上下文ac和ac-gfbs，auto会自动选择这些,默认就好  
**Inspection-recursion-limit**有时候匹配会发生错误进入死循环，这里可以配置重复操作的次数，默认就好。  
以下就是对包进行检测的分组树样例:  
![在这里插入图片描述][20200305100000925.png]![在这里插入图片描述][20200305100008438.png]  
所以如果想要高性能就这样配置:

detect:
      profile: custom
      custom-values:
        toclient-groups: 65000
        toserver-groups: 65000
      sgh-mpm-context: auto
      inspection-recursion-limit: 3000

**3.选择使用的分组匹配算法**

mpm-algo: auto(默认就是ac)
    spm-algo: auto(默认就是ac)

可以安装性能更好的Hyperscan，属于高性能的正则匹配表达库，suricata推荐使用。  
安装步骤如下:  
https://blog.csdn.net/u011311291/article/details/104388783  
然后更改配置文件:

mpm-algo: hs
    spm-algo: hs

# 二.Suricata运行模式和线程 #

默认配置为:

runmode: autofp

可选为single，workers，autofp  
**高性能官方推荐使用worker模式:**

runmode: worker

**1.默认runmode: autofp启动**  
这边使用了pfring,启动命令，捕抓2个网口的流量:  
/usr/local/bin/suricata --pfring-int=em1 --pfring-int=em2 --pfring-cluster-id=99 --pfring-cluster-type=cluster\_flow -c /usr/local/etc/suricata/suricata.yaml -D  
每一个网口会有单个线程进行捕抓，suricata.yaml中的pfring抓包配置失效。效果如下图的左侧，可以使用top -H -p pid可以查看进程的线程情况  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEzMTEyOTE_size_16_color_FFFFFF_t_70]  
**2.默认runmode: autofp读取pcap数据包分析**  
/usr/local/bin/suricata -r /xxx/xx.pcap  
Suricata会启动和CPU相等的个数线程进行解析处理，如上图的右侧  
**3.runmode: single**  
Single模式就是worker模式的单线程，一般用于开发。  
![在这里插入图片描述][2020030513595948.png]  
**4.runmode: worker**  
Suricata推荐使用worker模式，更具高性能.  
![在这里插入图片描述][20200305140006727.png]  
**5.runmode模式autofp和worker模式的不同**

**Autofp模式线程分为3大块**  
**(1)pcaket capture thread  
(2)pcaket process thread  
(3)management thread**  
Suricata中可以为每个模块进行CPU的配置设置，默认

set-cpu-affinity: no
    cpu-affinity:
      - management-cpu-set:
          cpu: [ 0 ]  # include only these cpus in affinity settings
      - receive-cpu-set:
          cpu: [ 0 ]  # include only these cpus in affinity settings
      - worker-cpu-set:
          cpu: [ "all" ]
          mode: "exclusive"
          # Use explicitely 3 threads and don't compute number by using
          # detect-thread-ratio variable:
          # threads: 3
          prio:
            low: [ 0 ]
            medium: [ "1-2" ]
            high: [ 3 ]
            default: "medium"
      - verdict-cpu-set:
          cpu: [ 0 ]
          prio:
            default: "high"

其中:  
**management-cpu-set** \- used for management (example - flow.managers, flow.recyclers)  
对应management thread模块，这块占CPU很少，基本上1个CPU就够了  
**receive-cpu-set** \- used for receive and decodeworker-cpu-set - used for  
对应的pcaket capture thread模块，这块占用资源适中，从实际部署看,一般2-4个CPU就够  
**worker-cpu-set** \-streamtcp,detect,output(logging),reject  
对应的是pcaket process thread模块，这块占用资源最大，可从默认配置中看到CPU分配ALL  
为了提高性能，可以将**set-cpu-affinity**设置为yes，这意味着每个线程都会绑定到指定的CPU运行。除了这个功能外，还可以通过top命令查看每一块CPU运行的状况，你会发现在高峰时期，经常处于100%的那一块CPU绑定的线程，发生丢包的数量会比别的线程大很多。

**Worker模式线程分为2大块**  
**(1)pcaket process thread  
(2)management thread**  
基本意思就是pcaket capture合并到pcaket process合并里面了。可配的情况变成了:  
**management-cpu-set** \- used for management (example - flow.managers, flow.recyclers)  
**worker-cpu-set** \- used for receive,streamtcp,decode,detect,output(logging),respond/reject  
为啥合并，我猜测是当服务器拥有足够的性能，把处理逻辑都集中在同一条线程可以减少数据包的分发，能更紧凑利用CPU处理数据包。  
所以高性能配置如下

threading:
      set-cpu-affinity: yes
      cpu-affinity:
        - management-cpu-set:
            cpu: [ 0 ]  # include only these CPUs in affinity settings
            #threads: 1
        - worker-cpu-set:
            cpu: [ "1-30" ]
            mode: "exclusive"
            threads: 30
            prio:
              #low: [ 0 ]
              #medium: [ "1-2" ]
              high: [ "1-30" ]
              default: "high"

注意:如果你的采集服务器还部署了其它组件，注意CPU要合理绑定,尽量不要出现CPU和其它消耗高资源的进程使用同一个CPU

# 三.max-pending-packets配置 #

表示每一条线程可以同时处理的数据包的个数，0-65000建议是10000或者更高，但是如果配置过高也可能会出现性能下降问题

# 四.IP分片重组 #

超过MTU的包会进行分段，在网卡处进行重组。假设网络环境中存在数据包分片，那么Suricata会对这些分片进行重组。相关的配置如下:

defrag:
      memcap: 20gb #可以使用的内存
      hash-size: 65536
      trackers: 65535 # 对一个流跟踪的分片数量number of defragmented flows to follow
      max-frags: 65535 # number of fragments to keep (higher than trackers)
      prealloc: yes #当出现一个分片流，是否先开辟内存
      timeout: 60

注意:其实网络中IP分片比较少，但是也根据情况而定，20gb只是一个最大值的设定，并不会直接占用

# 五.suricata的flow #

Suricata对流的定义是5元祖(协议，源IP，目标IP，源端口，目标端口),关于flow的配置由:

flow:
      memcap: 1gb #管理flow列表可以使用的内存，就一个表
      hash-size: 250000 #流表
      prealloc: 150000 #初始化的时候预设置的流表
      emergency-recovery: 30 #这里是流过多设置的的一些紧急处理机制，恢复到30%
      managers: 5 # default to one flow manager
      recyclers: 5 # default to one flow recycler thread

建议在大流量下将memcap，hash-size，prealloc进行调整，如上

# 六.stream引擎 #

Stream引擎用于跟踪TCP连接，主要用于跟踪流和重组。  
和flow的区别在于flow只是用于区别流，Stream更注重于整个流的数据包重组。

stream:
      memcap: 2gb				#stream列表可用的内存大小，和flow一样，可以设置较小
      checksum-validation: yes      # reject wrong csums
      inline: no                  # auto will use inline mode in IPS mode, yes or no set it statically
      prealloc-sessions: 100000
      bypass: yes	#如果超出了depth,后续的数据包可以直接滤过
      reassembly:
        memcap: 20gb					#重组可以设置的内存大小
        depth: 128kb                  # 最多还原steam大小，reassemble 1mb into a stream，初始值是1Mb
        toserver-chunk-size: 2560
        toclient-chunk-size: 2560
        randomize-chunk-size: yes
        #randomize-chunk-range: 10
        #raw: yes
        #segment-prealloc: 2048
        #check-overlap-different-data: true

主要修改的配置为memcap，prealloc-sessions，bypass，reassembly.memcap,depth

# 七.应用层解析配置 #

![在这里插入图片描述][20200305102002425.png]  
比较关注的是http,可观察suricata输出的state.json观察其占用，设置合理的值  
![在这里插入图片描述][20200305102011487.png]

# 八.高性能下suricata启动的配置 #

**(1)原始的开启方式，无法启用suricata.yaml中的pfring配置:**

/usr/local/bin/suricata --pfring-int=em1 --pfring-cluster-id=99 --pfring-cluster-type=cluster_flow -c /usr/local/etc/suricata/suricata.yaml -D

**(2)高性能配置，采用配置文件来设置抓包**  
例如:

pfring:
      - interface: em1
        threads: 1
        cluster-id: 99
        cluster-type: cluster_flow
        #bypass: yes #这里可以配置如果stream的重组达到depth,由pfring来丢弃后续的包，但是这个配置要高版本的pfring才能启动
      - interface: em2
        threads: 1
        cluster-id: 98
        cluster-type: cluster_flow
      - interface: em3
        threads: 30
        cluster-id: 97

**注意:启用的线程数和CPU的配置要协调，尽量多少线程就占多少CPU**

/usr/local/bin/suricata --pfring -c /usr/local/etc/suricata/suricata_test.yaml -D

# 九.Dns,flow信息异常原因 #

可能suricata输出的dns.json和flow.json统计异常  
网卡中存在带有Vlan标签的数据包，可能会导致flow的跟踪出现问题，需要如下配置才能正确跟踪流，关闭使用vlanid来匹配流

vlan:
      use-for-tracking: false

[20200305100000925.png]: https://img-blog.csdnimg.cn/20200305100000925.png
[20200305100008438.png]: https://img-blog.csdnimg.cn/20200305100008438.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEzMTEyOTE_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200305135947780.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTEzMTEyOTE=,size_16,color_FFFFFF,t_70
[2020030513595948.png]: https://img-blog.csdnimg.cn/2020030513595948.png
[20200305140006727.png]: https://img-blog.csdnimg.cn/20200305140006727.png
[20200305102002425.png]: https://img-blog.csdnimg.cn/20200305102002425.png
[20200305102011487.png]: https://img-blog.csdnimg.cn/20200305102011487.png