4. Suricata配置文件精讲
Suricata 的运行时行为几乎全部由 suricata.yaml 决定。规则写得再好，如果 YAML 中的线程数、抓包接口、流表容量或输出通道配置不当，检测结果也会失真。本节围绕“配置如何影响检测结果”这一主线，梳理核心配置项、默认值、调优参数，并给出工程环境中的配置管理策略。
一、配置文件的结构与加载顺序
Suricata 启动时按以下顺序确定配置：命令行参数（如 -i、-S）优先级最高，其次是通过 --set 传入的键值覆盖，最后才是 suricata.yaml 中的默认值。YAML 使用缩进表达层级，同一层级用空格（通常 2 或 4 个）对齐，禁止使用 Tab，否则解析会直接失败。配置中大量使用 default 与 custom 两套值：default 是 Suricata 内置的保守值，custom 是留给用户覆盖的入口，实际生效的是 custom（若存在）。
二、核心配置项与默认值
下面这张图展示了 suricata.yaml 的主要配置块及其对检测链路的影响关系，可作为阅读配置时的“地图”。
几个最常被忽视的默认值：max-pending-packets 默认 1024，在高 PPS 场景下容易成为瓶颈；flow.memcap 默认 32MB，大流量下流表会提前淘汰，导致长连接检测中断；stream.memcap 默认 64MB，重组大文件或长会话时可能触发内存回收。这些值在测试环境往往“够用”，但生产环境必须重新评估。
三、调优参数的实际取舍
调优不是把所有值调大。以 runmode 为例：autofp 适合多队列网卡，由多个抓包线程分发到流线程；workers 则让每个线程独立完成抓包、流处理和检测，减少锁竞争，适合 CPU 核数充足且流量分布均匀的场景。选择错误会导致 CPU 利用率不均或丢包。
再看 detect.profile：medium 是默认值，平衡了规则分组与内存；high 会为每条规则建立更细的匹配结构，提升检测速度但增加内存占用。若规则集超过 3 万条且内存充裕，可切到 high；若内存紧张，则保持 medium 并优化规则集。
输出侧，eve-log 是工程中最常用的 JSON 日志通道。默认开启 alert、http、dns、tls 等类型，但每类日志都会带来磁盘 I/O。建议按需裁剪：只保留与告警研判相关的类型，并设置 rotate-interval 与 max-files 控制磁盘占用。
四、工程环境中的配置管理策略
生产环境最忌讳“直接改 suricata.yaml 然后重启”。推荐做法是：将配置拆分为 base.yaml（通用项）与 env-<环境>.yaml（环境差异项），通过 --set 或配置合并脚本生成最终文件。所有变更纳入 Git，提交信息注明变更原因与影响范围。
变更前必须执行语法校验：
suricata -T -c /etc/suricata/suricata.yaml -v
校验通过后，先在镜像流量或旁路环境运行 10～30 分钟，观察 stats.log 中的 capture.kernel_drops、flow.memcap 使用率和 detect.alert 数量。若丢包率上升或内存告警，说明参数需要回调。确认稳定后再切换生产，并保留上一版配置以便快速回滚。
五、一个可参考的配置片段
以下片段展示了高流量场景下常见的调整方向，数值仅为示例，需按实际硬件和流量测试后确定：
max-pending-packets: 4096
runmode: workers
default-packet-size: 1514
flow:
memcap: 256mb
hash-size: 65536
prealloc: 10000
stream:
memcap: 512mb
reassembly:
memcap: 256mb
detect:
profile: medium
custom-values:
toclient-groups: 50
toserver-groups: 50
outputs:
- eve-log:
enabled: yes
filetype: regular
filename: eve.json
rotate-interval: 1h
types:
- alert
- http
- dns
- tls
- stats:
enabled: yes
interval: 30s
配置管理的核心不是记住每个默认值，而是建立“改前校验、改中观察、改后可回滚”的闭环。当你能从 stats.log 的丢包计数和内存使用率反推出该调哪个参数时，才算真正掌握了 suricata.yaml。