标签:
本系列文章是Suricata官方文档的翻译加上自己对其的理解,部分图片也是来自那篇文章,当然由于初学,很多方面的理解不够透彻,随着深入后面会对本文进行一定的修正和完善。
Suricata使用Yaml作为其配置文件的格式,关于Yaml可以参考YAML-维基百科。 其中Suricata默认的配置文件是suricata.yaml,以硬编码的形式写在源代码中,当然也可以在执行的时候添加-c+指定位置的yaml文 件来自定义配置文件。配置文件的第一行内容是%YAML 1.1表示其使用了Yaml 1.1的语法。由于配置项较多,因此将分为多篇文章来进行说明,本文是第一篇。
该选项设置了suricata能够同时处理的数据包的数量,最少为1,最大值取决于内存的大小,更大的内存可以设置更大的值并拥有更好的性能,默认值是1024。但是官方文档中并没有指出其数量与内存之间的具体关系。设置格式为:
max-pending-packets: 1024
该选项设置了suricata的运行方式,使用命令./suricata --list-runmodes
可以查看所有的运行方式,部分截图如下:
在介绍运行方式(Runmodes)之前首先了解一下suricata的基本组成。Suricata是由所谓的线程(threads)、线程模块 (thread-modules)和队列(queues)组成。Suricata是一个多线程的程序,因此在同一时刻会有多个线程在工作。线程模块是依据 功能来划分的,比如一个模块用于解析数据包,另一个模块用于检测数据包等。每个数据包可能会有多个不同的线程进行处理,队列就是用于将数据包从一个线程传 递到另一个线程。与此同时,一个线程可以拥有多个线程模块,但是在某一时刻只有一个模块在运行(原文是If they have more modules, they can only be active on a a time.看不大懂,感觉是这个意思)。
Suricata的运行方式就是上面介绍的线程(threads)、线程模块(thread-modules)和队列(queues)三种元素的不 同组合方式。上图中的RunMode Type并不是配置文件中的runmodes选项,而是后面的Custom Mode也就是自定义模式才可以在此处设置。比如默认的Runmodes是autofp,在线实时检测流量的模式中其结构如下,单线程模块获取数据包和解 码,多线程模块检测,单模块输出:
而在pfring模式下的autofp则有所不同,可以看到它有多个模块获取及解码数据包,通过流绑定队列分配到多个检测模块中进行检测,这应该是pfring模式获取数据包效率更高的原因:
之前的max-pending-packets选项设置了最多同时处理的数据包数量,这些同时处理的数据包都是需要存储在内存中的,所以需要对每个 数据包的大小进行限制,而当前选项就是做这个事的。虽然有时候可能需要检测较大的数据包,但是大部分情况下为了性能还是需要做出一定的限制。其配置方式如 下,默认值是1514,这也是TCP数据包的最大长度(当数据超过这个长度便会使用TCP报文重组技术):
default-packet-size: 1514
用于设置启动suricata的用户及其分组。
action指的是每条规则匹配时需要执行的操作,比如下面这条规则执行alert警告操作:
而当前字段设置的是多条规则同时匹配的时候的执行顺序。action共有四种:pass、drop、reject、alert。
pass指的是处理的数据包匹配当前规则时直接跳过后面的所有规则,也就是说不匹配后面的规则
drop只能工作在IPS模式下,当数据包匹配到drop的规则时则会被丢弃并且产生一个警告
reject会给数据包的发送和接收端都发生一个拒绝的数据包,如果原本的协议是TCP,则发生reset数据包,否则发送ICMP错误的数据包,同时产生一个警告。在IPS模式下也会丢弃匹配到的数据包
alert则对发送和接收者都没有影响,只会生成一个警告
Suricata按照规则的出现顺序依次加载,但是处理的顺序则根据配置文件中设置的action重要程度来排列。默认的顺序如下,表示当一个数据包匹配多条规则时,优先处理的是pass的规则,其次是drop,然后是reject,最后是alert:
action-order:
- pass
- drop
- reject
- alert
标题并不是关键字,而是指一个配置文件可以按照功能分割成多个文件,这样后面修改某一方面的配置就可以到指定的配置文件中修改,同样可以增加可读性。配置文件通过include进行包含,比如outputs.yaml:
# outputs.yaml
- fast
enabled: yes
filename: fast.log
append: yes
- unified2-alert:
enabled: yes
...
主配置文件如下:
# suricata.yaml
...
outputs: !include outputs.yaml
...
Suricata默认的日志存储目录是/var/log/suricata,在配置文件中可以通过当前选项指定,比如程序目录下的log文件夹,也可以在运行时的-l参数指定:
default-log-dir:./log
outputs选项下有很多可以输出的配置选项,包括警告、检测的数据包、产生的结果等。在配置的过程中并不需要开启每一种输出,根据自己的需求进行配置。
这个日志输出由单行的警告信息组成,比如下面这个输出例子由四个警告组成:
其配置如下:
# a line based alerts log similar to Snort‘s fast.log
- fast:
enabled: yes
filename: fast.log
append: yes
Suricata可以在匹配一条规则后记录一条信息,该条信息包括数据包的时间戳、五元组信息、对应的签名信息等,默认存储在日志目录下的 eve.log文件中。下面是几条典型的eve日志,这些日志是json格式的,因此很多其他的程序可以对其进行处理产生进一步的输出:
可以对其进行如下配置,输出的类型可以多种多样,包括文件、系统日志、输出到socket等,输出的内容可以包括匹配到有alert、http、 dns等规则的数据包信息。简单的说比如一条规则的action是alert,检测到有一个数据包匹配这条规则,那数据包和规则的信息则会储存到事件日志 中:
# Extensible Event Format (nicknamed EVE) event log in JSON format
- eve-log:
enabled: yes
type: file #file|syslog|unix_dgram|unix_stream
filename: eve.json
# the following are valid when type: syslog above
#identity: "suricata"
#facility: local5
#level: Info ## possible levels: Emergency, Alert, Critical,
## Error, Warning, Notice, Info, Debug
types:
- alert
- http:
extended: yes # enable this for extended logging information
- dns
- tls:
extended: yes # enable this for extended logging information
- files:
force-magic: no # force logging magic on all logged files
force-md5: no # force logging of md5 checksums
#- drop
- ssh
当然也可以把不同类别的信息输出到不同的日志文件中,如下配置表明alert和drop输出到eve-ips.json,http等协议输出到eve-nsm.json:
outputs:
- eve-log:
enabled: yes
type: file
filename: eve-ips.json
types:
- alert
- drop
- eve-log:
enabled: yes
type: file
filename: eve-nsm.json
types:
- http
- dns
- tls
还有一些其他的输出方法及格式可以参考EveJSONFormat。
当suricata检测到一个可疑的数据包时便可以将整个数据包以二进制的方式存储到文件中,目前已经支持了IPv4和IPv6的数据包。其输出的格式可以被Barnyard2 (参考网页)程序处理,这是一个用于将suricata输出的包存储到数据库中的程序,可以配合
Sguil(参考网页)进行对网络流量的实时监控和输出。一般上的配置格式如下,由于这里对每个文件的大小有32M的限制,所以在文件大于这个值时便会新建一个文件继续存储:
- unified2-alert: #The log-name.
enabled: yes #This log is enabled. Set ‘no‘ to disable.
filename: unified2.alert #The name of the file in the default logging directory.
limit: 32mb #The file size limit in megabytes.
在这个选项里还有一个X-Forwarded-For功能,这个功能是用来记录经过多个HTTP代理服务器之后真正的客户端IP地址,而不是代理服 务器的IP地址,HTTP协议会在头里面加入一个X-Forwarded-For字段以记录原始IP以及经过的每个代理服务器的IP,详细可参考X-Forwarded-For-维基百科,无论是在客户端的代理还是服务端的反向代理(百度百科)都非常有用,默认是关闭的:
# HTTP X-Forwarded-For support by adding the unified2 extra header that
# will contain the actual client IP address or by overwriting the source
# IP address (helpful when inspecting traffic that is being reversed
# proxied).
xff:
enabled: no
# Two operation modes are available, "extra-data" and "overwrite". Note
# that in the "overwrite" mode, if the reported IP address in the HTTP
# X-Forwarded-For header is of a different version of the packet
# received, it will fall-back to "extra-data" mode.
mode: extra-data
# Header name were the actual IP address will be reported, if more than
# one IP address is present, the last IP address will be the one taken
# into consideration.
header: X-Forwarded-For
HTTP日志会记录所有的HTTP流量信息,包含了http请求、HOST字段、URI字段和User-Agent字段,这里是普通的输出,除此之 外也可以在eve-log中指定http以便输出json格式的内容。另外也可以设置是否扩展以输出更多的信息,未扩展时输出的内容:
07/01/2014-04:20:14.338309 vg.no [**] / [**] Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36 [**]
192.168.1.6:64685 -> 195.88.54.16:80
扩展之后输出的内容:
07/01/2014-04:21:06.994705 vg.no [**] / [**] Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36 [**] <no referer> [**]
GET [**] HTTP/1.1 [**] 301 => http://www.vg.no/ [**] 239 bytes [**] 192.168.1.6:64726 -> 195.88.54.16:80
关于此项的配置如下,扩展选项默认关闭,用户还可以通过customformat来自定义输出的格式,同时也可以配置输出到socket文件:
- http-log: #The log-name.
enabled: yes #This log is enabled. Set ‘no‘ to disable.
filename: http.log #The name of the file in the default logging directory.
append: yes/no #If this option is set to yes, the last filled http.log-file will not be
# overwritten while restarting Suricata.
#extended: yes # If set to yes more information is written about the event.
#custom: yes # enabled the custom logging format (defined by customformat)
#customformat: "%{%D-%H:%M:%S}t.%z %{X-Forwarded-For}i %H %m %h %u %s %B %a:%p -> %A:%P"
#filetype: regular # ‘regular‘, ‘unix_stream‘ or ‘unix_dgram‘
还有一个存储DNS流量的配置,与HTTP的类似,就不做过多解释了。
通过pcap-log选项可以保存所有的数据包,这样在检测到问题数据包时就能更容易地找到之前的流量以便对整个事件进行确认和分析。基本配置如 下,与之前的HTTP日志一样,pcap文件也是可以限定大小和文件数的,当一个文件达到限制的大小时便会创建一个新文件,同时这里还有文件数量的限制:
- pcap-log:
enabled: yes
filename: log.pcap
# Limit in MB.
limit: 32mb
# If set to a value will enable ring buffer mode. Will keep Maximum of "max-files" of size "limit"
max-files: 2000
mode: normal # "normal" (default) or sguil.
#sguil_base_dir: /nsm_data/
#ts-format: usec # sec or usec second format (default) is filename.sec usec is filename.sec.usec
use-stream-depth: no #If set to "yes" packets seen after reaching stream inspection depth are ignored. "no" logs all packets
配置中的mode有两种情况,一个是普通的normal,会将文件存储在之前指定的日志存储目录,而sguil模式则需要sguil_base_dir选项指定目录,并且存储的文件按照日期划分目录,并加上时间戳:
$sguil-base-dir/YYYY-MM-DD/$filename.<timestamp>
最后一个use-stream-depth选项,如果设为“yes”只会存储不大于stream.reassembly.depth长度的数据,后面的将会舍弃(在一个stream中),“no”则会存储所有的数据包。
如果开启这一选项,suricata会记录每一个警告产生的详细信息,包括数据包、规则等各种信息。一个典型的输出如下所示,这些信息可以使得维护人员更快的排除误报、检查规则的问题等:
虽然这个功能非常有用,但是在生产环境中启动并不是一个明智的行为,它会在检测流时处理和输出大量的信息,导致性能有很大的下降,因此默认的配置是不开启的:
- alert-debug: #The log-name.
enabled: no #This log is not enabled. Set ‘yes‘ to enable.
filename: alert-debug.log #The name of the file in the default logging directory.
append: yes/no #If this option is set to yes, the last filled fast.log-file will not be
# overwritten while restarting Suricata.
这个选项决定了是否将suricata的警告输出到syslog文件中,配置如下:
- syslog: #This is a output-module to direct log-output to several directions.
enabled: no #The use of this output-module is not enabled.
facility: local5 #In this option you can set a syslog facility.
level: Info #In this option you can set the level of output. The possible levels are:
#Emergency, Alert, Critical, Error, Warning, Notice, Info and Debug.
可以看到syslog选项默认是关闭的,如果开启,facility字段表示产生日志的分类为local5。关于syslog日志处理系统的更多信息可以参考Syslog-维基百科。
当suricata工作在IPS模式下的时候,可以使用drop操作的规则,这些drop掉的数据包信息就会存储在drop.log文件中,配置如下:
- drop:
enabled: yes #The option is enabled.
filename: drop.log #The log-name of the file for dropped packets.
append: yes #If this option is set to yes, the last filled drop.log-file will not be
#overwritten while restarting Suricata. If set to ‘no‘ the last filled drop.log file will be overwritten.
Suricata在对流量检测之前需要将所有的规则签名加载到内存,而数据包在匹配规则时并不需要匹配所有的规则,事实上大量的规则是完全没必要匹 配的,比如当前数据包时基于UDP协议的,那TCP的所有规则都是没有必要匹配的。因此需要根据一定的依据对所有的规则进行分组,这样数据包只需要与符合 条件的分组内的所有规则进行匹配即可。而需要如何分组则是一个关键的问题。
下面是detect-engine的一种配置。profile选项有high、low和medium三种。high表示分组较多,但是会占用更多的 内存,性能也会更好;low则正好相反,占用更少的内存,性能也相对较差;medium是默认配置,是性能和内存使用的折中选择。除此之外高级用户可以在 custom-values字段自定义分组的配置,如下是根据数据包来源、源地址、目的地址、源端口、目的端口来进行分组,这些数字可以根据实际需要的性 能和需求进行调整:
detect-engine:
-profile: medium #The balance between performance and memory usage. This is the default setting.
- custom-values:
toclient_src_groups: 2
toclient_dst_groups: 2
toclient_sp_groups: 2
toclient_dp_groups: 3
toserver_src_groups: 2
toserver_dst_groups: 4
toserver_sp_groups: 2
toserver_dp_groups: 25
- sgh-mpm-context: auto
- inspection-recursion-limit: 3000
数据包检测规则的分组图可以看得更清楚:
接下来是sgh-mpm-context,这个字段指明MPM算法使用的content是否公用。当其值为auto时,是否公用取决于配置文件中指 定MPM的算法,若为ac或ac-gfbs,则使用single模式,表示所有的规则分组使用单个MPM-content,其余算法则使用full模式, 每个分组拥有自己的MPM-content。而当sgh-mpm-context字段的值为single或full时则不受MPM算法的影响。关于 suricata的MPM机制可以参考fast_parttern,后面的配置也会做进一步的说明。
最后的inspection-recursion-limit则是为了减少suricata的出错次数,因为网络流量状况非常复杂,suricata难免会遇上无限循环或是递归地处理数据包的情况,这时指定一个最大值,当循环或递归次数大于这个值则停止处理当前数据包。
CUDA的翻译是统一计算设备架构,为的是让CPU和GPU在执行运算的时候发挥自身的优势,协同处理,详细可参考CUDA-维基百科。 由于这项技术是NVIDIA主导的,且出现时间并不长,因此suricata只是在MPM多模匹配中可以使用,并且只有在编译前的configure时加 入–enable-cuda才具有这项功能,并且目前其他的GPU并不支持这项功能。因此这里就不做过多介绍,等后面这项技术推广开来,便有更加实用的意 义。
之前已经了解过,suricata在content的多模匹配支持很多算法,不同的算法有不同的优缺点。设置如下,可选的算法包括b2g, b2gc, b2gm, b3g, wumanber, ac和ac-gfbs(最后两个是1.0.3版本才加入的):
mpm-algo: b2gc
部分算法的详细配置如下,search_algo表示当前算法所使用的扫描或搜索算法,比如b2gc算法的扫描算法(scan algorithms)有B2gScan和B2gScanBNDMq,搜索算法(search algorithms)有B2gSearch和B2gSearchBNDMq;hash_size表示每种算法的hash表的最大空间,从小到大依次是 lowest (2048) - low (4096) - medium (8192) - high (16384) - higher (32768) – max (65536),越大匹配的性能越好,但对内存的要求也更高;bf_size选项决定了布隆过滤器(Bloom filter-维基百科)占用内存的大小,可选的值为low (512) - medium (1024) - high (2048),也是从小到大排列,性能也是越来越好:
pattern-matcher:
- b2gc:
search_algo: B2gSearchBNDMq
hash_size: low #Determines the size of the hash-table.
bf_size: medium #Determines the size of the bloom- filter.
- b3g:
search_algo: B3gSearchBNDMq
hash_size: low #See hash-size -b2gc.
bf_size: medium #See bf-size -b2gc.
- wumanber:
hash_size: low #See hash-size -b2gc.
bf_size: medium #See bf-size -b2gc.
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Suricatayaml
http://zh.wikipedia.org/wiki/YAML
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Runmodes
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/EveJSONOutput
https://github.com/firnsy/barnyard2
http://en.wikipedia.org/wiki/Sguil
http://zh.wikipedia.org/wiki/X-Forwarded-For
http://baike.baidu.com/link?url=D2rVWCZz7t62A3ZgDEosF2-sgOdIAaoAk4iwrGkTqF3KRVE_14n-B0eUypHJDa8zCygUhRTbtDYF4i-k0kgMvq
http://de.wikipedia.org/wiki/Syslog
http://zh.wikipedia.org/wiki/CUDA
http://zh.wikipedia.org/wiki/%E5%B8%83%E9%9A%86%E8%BF%87%E6%BB%A4%E5%99%A8
标签:
原文地址:http://www.cnblogs.com/UnGeek/p/5796934.html