美文网首页
suricata 配置1(suricata.yaml)

suricata 配置1(suricata.yaml)

作者: lx_jian | 来源:发表于2019-04-30 17:28 被阅读0次

    1.  suricata.yaml

    Suricata使用Yaml格式进行配置。源代码中包含的Suricata.yaml文件是Suricata的示例配置。在YAML文件的顶部,您将找到%YAML 1.1。Suricata读取文件并将文件标识为YAML。

    (1.1)Max-pending-packet

    通过设置max-pending-packets,您可以设置允许Suricata同时处理的包的数量。这可以从一个包到数万/数十万个包。它是一种更高性能和更多内存(RAM)使用的交换,或者是更低的性能和更少的内存使用。处理的数据包数量越多,性能就越好,内存也就越大。包的数量越少,性能越差,内存的使用越少。在拥有许多CPU /CPU核心的同时,选择处理的数据包数量较低,可能会导致不能充分利用整个计算机的容量。(例如:使用一个内核,同时有三个等待处理包。)

    如:

    max-pending-packets: 1024

    (1.2)Runmodes

    默认情况下,runmode选项是禁用的,您可以使用runmode设置来设置您想要使用的runmode。对于所有可用的运行模式,在命令行中输入-list-runmodes.

    如;

    runmode: autofp

    (1.3)Default-packet-size

    对于max-pending-packets选项,Suricata必须将数据包保留在内存中。

    使用default-packet-size选项,您可以设置网络上数据包的大小。有时可能需要处理更大的数据包。引擎仍然可以处理这些更大的数据包,但处理它会降低性能。

    如:

    default-packet-size: 1514

    (1.4)User and group

    可以将用户和组设置到运行的Suricata。如:

    run-as:

        user:suri

        group:suri

    (1.5)PID File

    Suricata在守护程序模式下运行时,此选项设置PID文件的名称。此文件记录Suricata进程ID.

    pid-file : /var/run/suricata.pid

    注意:

    此配置文件选项仅在守护程序模式下运行时设置PID文件。要在未以守护程序模式运行时强制创建PID文件,请使用--pidfile 命令行选项。此外,如果运行多个Suricata进程,则每个进程都需要指定不同的pid文件位置。

    (1.6)Action-order(动作顺序)

    所有签名/规则都具有不同的属性。其中一个是Action属性。这个确定签名/规则匹配时会发生什么。Action有四种类型。签名/规则匹配并包含以下操作之一时将发生的情况:

    (1.6.1)Pass

    如果签名/规则匹配并包含Pass,Suricata将停止扫描数据包并跳到所有规则的末尾(仅针对当前数据包)。

    (1.6.2)Drop

    这只涉及IPS/内联模式。如果程序发现匹配的签名/规则并包含drop,它将立即停止。这个数据包不会再发送出去了。缺点:接收方不接收正在发生的消息,导致超时(当然是TCP)。Suricata为这个包生成一个警报。

    (1.6.3)Reject

    这是对数据包的主动拒绝。接收方和发送方都接收到一个拒绝包。将自动选择两种类型的拒绝包。

    (1.6.3.1)如果有问题的数据包与TCP有关,它将是一个重置包。

    (1.6.3.2)对于所有其他协议,它将是一个icmp错误包。

    Suricata还生成警报。当处于内联/IPS模式时,违规包也会像“drop”操作一样被删除。

    (1.6.4)Alert

    如果签名匹配并包含alert,则包将被视为与任何其他非威胁包一样,除了这个之外,Suricata还将生成一个警报。只有系统管理员才能注意到此警告。

    Inline / IPS可以通过两种方式阻止网络流量。一种方法是drop ,另一种方式是reject。

    规则将按照它们在文件中出现的顺序加载。但它们将以不同的顺序处理。签名有不同的优先级。最重要的签名将首先被扫描。有可能改变优先次序。默认顺序是:pass、drop、reject、alert。

    action-order:

        -pass

        -drop

        -reject

        -alert

    这意味着在drop规则之前考虑pass规则,在reject规则之前考虑drop规则等等。

    (1.7)在多个文件中拆分配置

    有些用户可能需要或希望将他们的suricata.yaml文件拆分为单独的文件,这可以通过'include'和'!include'关键字获得。

    第一个例子是获取输出部分的内容并将它们存储在outputs.yaml中:

    图1

    第二种情况是将多个部分迁移到不同的YAML文件。

    图2

    如果是同一节,则在include语句之后重新定义输出,它将覆盖包含的文件。因此,文档末尾的任何include语句都将覆盖已配置的部分。

    (1.8)Event output(事件输出)

      (1.8.1)默认日志目录

    在 /var/log/suricata目录中,将存储Suricata的所有输出(alerts 和events).

    default-log-dir : /var/log/suricata

    可以通过输入-l命令行参数或直接在Yaml中更改目录来覆盖此目录。要使用-l命令行参数更改它,请输入以下内容:

    suricata  -c  suricata.yaml  -i  eth0  -l   /var/log/suricata-logs/

    (1.8.2) stats(统计)

    可以通过多种方式记录 数据包计数器、内存使用计数器等引擎的统计信息。默认情况下启用单独的文本日志'stats.log' 和 EVE记录类型'stats'来记录。

    统计信息具有全局配置和每个记录器配置。这里记录了全局配置。

    图3

    可以在此处启用或禁用统计信息。

    统计数据按间隔(interval)转储。由于线程是如何在内部同步的,因此将此值设置为3秒或4秒以下是没有用的。

    解码层生成的解码器事件可以为每个事件类型创建计数器。默认情况下启用此行为。可以将decoder-events选项设置为false以禁用。

    在4.1.x 版本decoder计数器和decoder-event计数器之间存在命名冲突。这将导致大量 decoder-event 在EVE.stats中没有记录并显示。为了在不破坏现有设置的情况下解决这个问题,添加了一个配置选项decoder-events-prefix来更改decoder-events的名称。由decoder.<proto>.<event > 改为decoder.event.<proto>.<event >。 在5.0中,它将成为默认值,见问题2225

    与decoder-events选项类似,stream-events选项控制是否将流事件添加为计数器。默认情况下禁用此功能。

    (1.8.3)输出

    有几种类型的输出。一般结构是:

    图4

    启用所有日志将导致性能大大降低并占用更多磁盘空间,因此仅启用所需的输出。

    (1.8.3.1)基于行的警报(alerts )日志(fast.log)

    此日志包含由一行组成的警报。单个fast.log文件行的外观示例:

    图5 图6

    (1.8.3.2)Eve (可扩展事件格式)

    这是警报和事件( alerts and events)的JSON输出。它允许与第三方工具(如logstash)轻松集成。

    图7

    有关更高级的配置选项,请参Eve JSON 输出

    格式以Eve JSON格式记录

    (1.8.3.3)用于Barnyard2的警报输出(unified2.alert)

    此日志格式是与另一种流行的IDS格式的unified2输出兼容的二进制格式,设计用于Barnyard2或其他使用unified2日志格式的工具。

    默认情况下,将创建具有给定文件名和时间戳(unix epoch格式)的文件,直到文件达到配置的大小限制,然后将创建具有新时间戳的新文件。这是类似其他工具的工作形式,比如Barnyard2来清理旧的unified2文件。

    如果设置了nostamp选项,则日志文件将不会附加时间戳。该文件将像其他日志文件一样在SIGHUP上重新打开,允许外部日志轮换工具按预期工作。但是,如果达到限制,文件将被删除并重新打开。

    此输出支持IPv6和IPv4事件。此警报输出需要Barnyard2。

    图8

    (1.8.3.4)基于行的HTTP请求日志(http.log)

    此日志记录所有HTTP流量事件。它包含HTTP请求,主机名,URI和User-Agent。此信息将存储在http.log中(默认名称,在suricata日志目录中)。也可以通过使用Eve-log功能来执行此日志记录 。

    图9

    具有非扩展日志记录的HTTP日志行示例:

    图10

    具有扩展日志记录的HTTP日志行示例:

    图11

    (1.8.3.5)基于行的DNS查询和回复日志(dns.log)

    此日志记录所有DNS事件(查询和回复)。它包含已执行的DNS活动的类型,请求/回复的域名以及作为客户端,服务器,ttl,资源记录数据的相关数据。此日志记录也可以通过使用Eve-log功能来执行,该功能可以更轻松地进行解析。

    配置选项

    图12

    具有前一个回复的查询的DNS日志的外观示例:

    图13

    通过回复中rcode字段的文本表示来记录不存在的域和其他DNS错误(有关列表,请参阅RFC1035和RFC2136)。在下面的示例中,解析了不存在的域并记录了NXDOMAIN错误:

    图14

    (1.8.3.6) 包日志(pcap-log)

    使用pcap-log选项,您可以将Suricata注册的所有数据包保存在名为log.pcap_的日志文件中。这样,您可以随时查看所有数据包。在正常模式下,将在default-log-dir中创建pcap文件。如果在yaml文件中设置了绝对路径,也可以在别处创建它。

    可以使用支持pcap文件格式的程序打开default -log-dir  /var/log/suricata保存的文件。可以是Wireshark,TCPdump,Suricata,Snort等等。

    可以启用和禁用pcap-log选项。

    可以设置的pcap-log文件有一个大小限制。默认限制为32 MB。如果日志文件达到此限制,则将轮换该文件并创建一个新文件。pcap-log选项具有“Sguil”的额外功能:http://sguil.sourceforge.net/ 可以在'mode'选项中启用。在sguil模式中,“sguil_base_dir”表示基目录。在这个基础目录中,pcaps是在基于日期的一个Sguil-specific目录结构中创建的:

    $sguil_base_dir/YYYY-MM-DD/$filename.<timestamp>

    如果您想将Suricata与Sguil一起使用,请不要忘记在suricata.yaml文件中启用(并在必要时修改)基础目录。请记住,在“正常”模式下,文件将保存在default-log-dir或绝对路径中(如果已设置)。

    通过将compression选项设置为lz4,可以在写入磁盘之前压缩pcap文件。此选项与sguil模式不兼容。注意:在Windows上,此选项会增加磁盘I/O而不是减少磁盘I/O. 使用lz4压缩时,可以使用lz4-checksum选项启用校验和,并且可以将压缩级别lz4-level设置为0到16之间的值,其中较高级别会导致更高的压缩。

    默认情况下将记录所有数据包,除了:

    a .超出stream.reassembly.depth的TCP流

    b. 密钥交换后的加密流

    图15

    (1.8.3.7)详细警报日志(alert-debug.log)

    这是一种日志类型,提供有关警报的补充信息。对于调查误报和签名/规则的人来说,它特别方便。但是,由于必须存储大量信息,因此会降低性能。

    图16

    (1.8.3.8)警报输出到前奏(alert-prelude)

    为了能够使用此类型,您必须首先连接前奏管理器(--enable-prelude)。

    Prelude警报包含大量信息和字段,包括触发警报的数据包的IP字段。这些信息可分为三个部分:

    A.警报描述(传感器名称,日期,规则的ID(sid)等),这总是包括在内

    B.数据包标题(几乎所有IP字段,TCP UDP等,如果相关)

    C.整个数据包的二进制形式。

    由于最后两个部分可能非常大(特别是因为它们存储在Prelude SQL数据库中),因此它们是可选的,由两个选项'log_packet_header'和'log_packet_content'控制。默认设置是记录标题,但不记录内容。

    配置文件名称是用于连接到前奏管理器的Prelude配置文件的名称。必须使用外部命令(prelude-admin)注册此配置文件,并且必须与将运行Suricata的用户的uid / gid匹配。完整程序详见“ 前奏手册”

    图17

    (1.8.3.9) Stats

    在统计信息中,您可以设置stats.log的选项。启用stats.log时,您可以设置希望将输出数据写入日志文件的时间量(以秒为单位)

    图18

    间隔和其他几个选项取决于如上所述的全局统计部分。

    (1.8.3.10) Syslog(系统日志)

    使用此选项,可以将所有警报和事件输出发送到syslog。

    图19

    (1.8.3.11)Drop.log(丢弃数据包的基于行的信息)

    如果Suricata在IPS模式下工作,它可以根据规则丢弃数据包。正在删除的数据包保存在drop.log文件中,即Netfilter日志格式。

    图20

    (1.8.3.12)file-stor(文件提取)

    该文件的存储输出使提取的文件到磁盘的存储和配置它们的存储位置。以下显示了文件存储输出的版本2的配置选项 。

    图21

    (1.9)检测引擎

    (1.9.1)检测配置

    检测引擎构建内部签名/规则组。Suricata加载签名/规则,用于比较网络流量。事实是,许多规则肯定不是必要的。(例如:如果出现带有UDP协议的数据包,则不需要TCP协议的所有签名/规则)因此,所有签名/规则将按组分组。但是,包含许多组的分发将使用大量内存。并非每种类型的签名/规则都有自己的组。有可能将具有多个共同属性的不同签名放在一个组中。组的数量将决定内存和性能之间的平衡。少量组会降低性能,但占用的内存很少。相反的情况是组多占用内存也多。该引擎允许您管理内存和性能之间的平衡。为了管理这个问题,(通过确定组的数量)profile有几个常规选项:

    (1.9.1)high :高性能和更多内存使用

    (1.9.2)low :低性能和低内存使用。

    (1.9.3)medium :性能和内存使用之间的平衡。这是默认设置。

    自定义(custom )选项适用于高级用户。此选项具有可由用户管理的值。

    图22

    在所有这些选项中,您可以添加(或更改)值。大多数签名/规则都有调整以专注于一个方向,这意味着专注于服务器,或专注于客户端。

    如果您看一下示例9.1检测引擎分组树,您会看到它有许多分支。在每个分支的末尾,实际上有一个'sig group head'。在该sig group head有一个容器,其中包含一个具有对特定组/分支的特定端有重要意义的签名的列表。同样在 sig group head 内,可以找到Multi-Pattern-Matcher(MPM)的设置:MPM-context。

    如将在“Multi-Pattern-Matcher(MPM)”部分再次描述的,可以从中选择几种MPM算法。因为每个sig group head都有自己的MPM-context,一些算法使用大量内存。因此,可以选择sgh-mpm-context来设置组是否共享一个MPM-context,还是设置每个组都有自己的MPM-context。

    要设置选项sgh-mpm-context,您可以选择auto,full或single。默认设置为“auto”,表示Suricata根据您使用的算法自动选择full或single。“full”意味着每个组都有自己的MPM-context;“single”表示所有组共享一个MPM-context。这两种算法ac和ac-gfbs是1.03中的新算法,如果Sgh-MPM-context 设置为“auto”,则这些算法使用single MPM-context。在这种情况下,其余算法使用full。

    inspect-recursion-limit选项必须减轻Suricata中可能出现的大问题。通常Suricata必须处理复杂的问题。由于一个错误,它可能最终处于“无限循环”,这意味着它将一遍又一遍地重复其动作。使用选项inspection-recursion-limit,您可以限制此操作.

    示例9.1 检测引擎分组树

    图23 图24

    示例5详细分组树

    图25

    (1.9.2)Prefilter Engines(预滤器引擎)

    预过滤的概念是有太多的规则不能单独检查。预过滤器采用的方法是,从每个规则中向预过滤器添加一个条件,然后在一个步骤中检查该条件。最常见的例子是MPM(也称为fast_pattern)。这将每个规则接收一个模式并将其添加到MPM。仅对那些在MPM阶段中至少有一个模式匹配的规则,执行单独的检查。

    除了MPM之外,其他类型的关键字也支持预过滤。例如ICMP itype、icode、icmp_seq和icmp_id。TCP窗口、IP TTL都是其他例子。

    有关支持预过滤器的关键字的完整列表,请参阅:

    suricata  --list-keywords=all

    Suricata可以自动选择预过滤器选项,也可以手动设置

    图26

    默认情况下,仅使用MPM/fast_pattern。然后,可以使用'prefilter'关键字在特定规则中启用其他非MPM关键字的预过滤器引擎,如

    alert  ip any any->any any(ttl:123; prefilter; sid:1;)

    要让Suricata做出这些决定,请将默认设置为“自动”

    图27

    (1.9.3)模式匹配器设置

    多模式匹配器(MPM)是Suricata中检测引擎的一部分,可以一次搜索多个模式。通常,签名/规则具有一种或多种模式。在每个签名/规则中,多模式匹配器使用一个模式。这样,Suricata可以排除许多签名被检查,因为签名只能在其所有模式匹配时匹配。

    这些程序是:

    a.一个数据包进来

    b.打包将由搜索中的多模式匹配器进行分析匹配的模式

    c.匹配的所有模式将由Suricata(签名)进一步处理

    例9.3 Multi-pattern-matcher 

    图28

    Suricata提供不同的多模式匹配算法的各种实现。这些可以在下面找到。

    要设置多模式匹配算法:

    mpm-algo : b2gc

    在“mpm-algo”之后,您可以输入以下算法之一:b2g,b2gc,b2gm,b3g,wumanber,ac和ac-gfbs(最后两个是1.0.3中的新增功能)。有关后两者的更多信息,请再次阅读“检测引擎”部分的结尾。这些算法没有选择,因此下面没有提到任何选项的事实是没有遗漏的。

    随后,您可以设置mpm算法的选项。

    hash_size选项确定模式匹配器内部使用的哈希表的大小。低哈希值(小表)会导致内存使用率降低,但会降低性能。对于高哈希大小,相反的计数:更高的内存使用率,但(通常)更高的性能。算法的哈希大小的内存设置可以从最低lowest (2048) - 低low (4096) - 中medium (8192) - 高high (16384) - 更高higher (32768) - 最大max (65536)变化。(YAML 1.0 -1.0.2中的“highest”为'更高')

    bf_size选项确定布隆过滤器的大小,该大小与模式匹配器的最后一步一起使用,即模式的验证。对于此选项,与hash-size选项的计数相同:将其设置为低将导致内存使用率降低,但会降低性能。相反,bf_size的设置较高:内存使用率较高,但(通常)性能较高。布隆过滤器的大小可以从低low (512) - 中medium (1024) - 高high(2048)变化。

    图29

    (1.10 )线程

    Suricata是多线程的。Suricata使用多个CPU‘s / CPU内核,因此可以同时处理大量网络数据包。(在单核引擎中,数据包将一次处理一个)

    有四个线程模块:数据包获取,解码和流应用层,检测和输出。

    a.数据包获取模块从网络读取数据包。

    b.解码模块解码数据包,流应用程序应用程序层有三个任务:

            首先:它执行流跟踪,这意味着它将确保采取所有步骤来建立正确的网络连接。

            第二:TCP-network流量以包的形式出现。流组装引擎重构原始流。

            最后:将检查应用层。将分析HTTP和DCERPC。

    c.检测线程将比较签名/规则。可以有多个检测线程,因此它们可以同时运行。

    d.在输出中,将处理所有警报和事件。

    例1.10.1 线程

    图30

    Packetacquisition:从网络中读取数据包

    Decode:解码数据包。

    Streamapp.Layer:执行流跟踪和重新组装。

    Detect:比较签名。

    Outputs:处理所有事件和警报。

    大多数计算机都有多个CPU / CPU内核。默认情况下,操作系统确定哪个核心在哪个线程上工作。当核心已被占用时,将指定另一个核心在该线程上工作。那么,哪个核心在哪个线程上运行,可能会不时发生变化。

    线程中有一个选项:

    set-cpu-affinity:  no

    使用此选项,您可以为每个线程设置Suricata设置固定核心。在那种情况下,1,2和4处于核心0(零)。每个核心都有自己的检测线程。在核心0上运行的检测线程的优先级低于在核心0上运行的其他线程。如果要占用这些其他核心,则核心0上的检测线程没有太多要处理的数据包。在其他核心上运行的检测线程将处理更多数据包。仅在将选项设置为“是”之后才会出现这种情况。

    例1.10.2 平衡工作负载

    图31

    您可以设置detect-thread-ratio

    detect-thread-ratio: 1.5

    detect thread-ratio将确定检测线程的数量。默认情况下,它将是计算机上CPU / CPU核心数量的1.5倍。这将导致拥有更多的检测线程在CPU / CPU内核。这意味着您超额订阅了核心数量。当必须等待检测线程时,这可能很方便。剩余的检测线程可以激活。

    在“cpu affinity”选项中,您可以设置哪个CPU /核心在哪个线程上工作。在此选项中有几组线程。management-, receive-, worker- and verdict-set,这些是固定名称,无法更改。对于每个设置,有几个选项:cpu,mode和prio。

    在选项“cpu”中,您可以设置cpu /内核的数量,这些cpu /内核将运行该设置中的线程。您可以将此选项设置为“all”,使用范围(0-3)或逗号分隔的列表(0,1)。

    选项“mode”可以设置为“balance”或“exclusive”。当设置为“平衡”时,各个线程可以由选项“cpu”中设置的所有内核处理。如果选项“mode”被设置为“exclusive”,那么每个线程都有固定的内核。如前所述,线程可以具有不同的优先级。

    在选项' prio '中,可以为每个线程设置优先级。该优先级可以是低、中、高,也可以将优先级设置为“default”。如果您没有为CPU设置优先级,那么“default”中的设置将会被计算在内。默认情况下,Suricata为每个可用的CPU/CPU内核创建一个“检测”(worker)线程。

    图32

    (1.10.1)   IDS / IPS模式的相关 cpu-affinity 设置

    (1.10.1.1) IDS mode

    Runmode AutoFp

    图33

    Rumode Workers

    图34

    (1.10.1.2) IPS mode

    Runmode AutoFp

    图35

    Runmode Workers

    图36

    (1.11)IP碎片整理

    网络数据包偶尔会出现碎片。在某些网络上,它发生的频率高于其他网络。碎片包存在许多部分。在Suricata能够准确地检查这些类型的数据包之前,必须重建数据包。这将由Suricata的一个组成部分完成; 碎片整理引擎。在碎片整理引擎重建碎片包之后,引擎将重新组装的数据包发送到Suricata的其余部分。

    碎片整理中有三个选项:max-frags,prealloc和timeout。在Suricata接收到数据包的一个片段时,它会在内存中保留该数据包,其他片段很快就会出现,便可以完成数据包。但是,有可能没有出现其中一个片段。为了防止Suricata等待该数据包(从而使用内存),Suricata会在一段时间后丢弃这些数据。默认情况下,这会在60秒后发生。

    图37

    相关文章

      网友评论

          本文标题:suricata 配置1(suricata.yaml)

          本文链接:https://www.haomeiwen.com/subject/uudunqtx.html