suricata 流和流处理
1.流设置
在Suricata中，Flows非常重要。它们在Suricata内部组织数据的方式中发挥了重要作用。流有点类似于连接，此外流更通用。所有相同元组（协议，源IP，目的IP，源端口，目的端口）的包分组属于同一流。属于流的数据包在内部连接到它。
如：
图1
图2
跟踪所有这些流量，需要使用内存。流量越多，内存就越多。为了控制内存使用情况，有以下几种选择设置（suricata.yaml文件中flow设置）：
（1）选择memcap设置流引擎将使用的最大字节数
（2）使用hash-size设置哈希表的大小
（3）使用prealloc用于以下内容设置：
（3.1）对于尚未属于流的数据包，Suricata会创建新流。这是一个相对昂贵的动作。随之而来的风险是，攻击者/黑客可以攻击这一部分的引擎系统。当他们攻击使计算机获得大量具有不同元组的数据包时，引擎必须创建大量新流。这样，攻击者就可以淹没系统。为了减轻引擎过载，该选项指示Suricata在内存中保留一定数量的流。这样Suricata就不那么容易受到这种攻击。
流引擎有一个流管理器，具有独立于分组处理操作的管理线程。该线程确保尽可能在memcap中将准备10000个流。
在仍然可以达到memcap的时候，尽管设置了prealloc，但是流量引擎仍然进入紧急模式（emergency）。在此模式下，引擎将使用更短的超时。它允许流以更激进的方式过期，因此将有更多空间用于新流。有两个选项：emergency_recovery 和 prune_flows。
紧急模式恢复设置为30（这是prealloc'd流量的百分比，即30%），当10000流量的30％完成时，之后流量引擎将恢复正常模式。
如果在紧急模式期间，激进的超时没有达到预期的结果，则此选项是最终的选择。它结束了一些流，即使他们还没有达到他们的超时。prune-flows选项显示每次设置新流时将终止的流量。
2.流超时
Suricata在内存中保持流量的时间量由流量超时决定。流可以有不同的状态。Suricata区分TCP有三个流状态 、UDP有两个流状态。
对于TCP: New、Established 、Closed
对于UDP: New、Established .
对于这些状态中的每一个，Suricata可以使用不同的超时。
TCP流中：New状态表示三次握手期间的时间段。Established 状态是三次握手完成时的状态。Closed状态，有几种方法可以结束流程，通过重置或四次FIN握手。
UDP流中：New 状态仅从一个方向发送数据包的状态。Established 数据包从两个方向发送。
在如下示例配置中，每个协议都是设置。TCP，UDP，ICMP和默认（所有其他协议）
图3
3.流引擎
Stream-engine跟踪TCP连接。引擎存在两部分：流跟踪和重组引擎。流跟踪引擎监视连接的状态。重组引擎像以前一样重建流程，因此它将被Suricata识别。流引擎有两个可以设置的memcaps。一个用于流跟踪引擎，一个用于重组引擎。流跟踪引擎将流的信息保存在内存中。信息包括：有关状态，TCP序列号和TCP窗口的信息。为了保留这些信息，它利用memcap分配的容量。TCP数据包具有所谓的校验和。这是一个内部代码，可以查看数据包是否已达到良好状态。流引擎不会处理具有错误校验和的数据包。可以通过输入“no”而不是“yes”来设置此选项。
图4
为了减轻Suricata因快速会话创建而过载，选项prealloc_sessions指示Suricata在内存中保留一定数量的会话。
TCP会话以三次握手开始。之后，可以收发数据。会话可以持续很长时间。在几个TCP会话已经启动之后，可能会启动Suricata。这样，Suricata错过了这些会话的原始设置。这些原始设置始终包含大量信息。如果您希望Suricata从该时间开始检查流，您可以通过将“midstream”选项设置为“true”来实现。默认设置为“false”。通常，Suricata能够查看连接的所有数据包。尽管有些网络使它变得更加复杂。一些网络流量遵循与其他部分不同的路由，换句话说：流量变为异步。为了确保Suricata能够检查它确实看到的那一部分，而不是让人感到困惑，选项“async-oneside”将变为现实。这个选项默认为“false”。
Suricata以块的形式检查 正常/ IDS模式下的内容。在内联/ IPS模式下，它以滑动窗口方式执行（参见示例..）在Suricata设置为内联模式的情况下，它必须在将数据包发送到接收器之前立即检查数据包。这样Suricata就可以根据需要直接丢弃数据包。（参见示例...）Suricata必须注意它正在处理哪个操作系统，因为操作系统在处理流中的异常方面有所不同。请参阅Host-os-policy。'drop-invalid'选项可以设置为no，以避免阻止流引擎看到无效的数据包。这可以用于覆盖某些第2层IPS设置中看到的一些奇怪情况。
图5
Normal/IDS mode：Suricata以块的形式检查数据包。
图6
Inline/IPS模式： Suricata以滑动窗口的形式检查数据包。
图7
Normal/IDS (reasembly on ACK’D data)
图8
Inline/IPS (reassembly on UNACK’D data)
图9
重组引擎必须将数据段保留在内存中，以便能够重建流。为避免资源匮乏，使用memcap来限制使用的内存。重新组装流是一项昂贵的操作。使用选项depth ，您可以控制流重组的完成程度。默认情况下，这是1MB。执行文件提取的协议解析器可以按流覆盖此设置。重新组装的数据的检查是以块的形式完成的。这些块的大小设置为toserver_chunk_size和toclient_chunk_size。为了避免使边界可预测，可以通过添加随机因子来改变尺寸。
图10
“Raw”重组是由简单的检查content完成，pcre 关键字使用和其他的有效载荷检查不是在等特定协议缓冲区如http_uri完成。下面选项可以关闭此类型的重组：
reassembly:
raw:no
传入的段存储在流的列表中。为了避免使用每线程池进行常量内存分配。
reassembly:
segment-prealloc:2048 # pre-alloc 2k segments per thread
在相同序列号上重新发送不同数据是混淆网络检查的一种方法。
reassembly:
check-overlap-different-data:true
流重组示例：
图11
