Suricata 规则误报的分层排查思路

我第一条自写规则上线那天，告警突然刷屏，几百条全是同一个 sid。我第一反应是规则写错了，改了三遍匹配内容才发现，问题根本不在规则本身。后来我慢慢摸出一套顺序：从流量、加载、语义到日志，一层层往下剥，比盯着规则文本硬猜快得多。

先确认流量到底有没有到网卡

误报和漏报在现象上常常混在一起。我现在的习惯是，一边开着 tcpdump 或者留一份 PCAP，一边看告警，把“流量有没有到网卡”和“规则有没有命中”当成两件事分别判断。很多所谓误报，其实是同一条规则被同一段流量反复匹配，而那段流量的来源我压根没搞清楚。流量层没弄明白之前，后面的调整基本都只能靠猜。

再确认规则是不是真的在跑

-S 会覆盖配置文件里的规则列表，只加载你指定的文件。这一点做实验很方便，但也容易坑自己：以为只挂了一条本地规则，实际某处把整套社区规则也带进来了，噪声自然一下子炸开。启动前用 -T 校验一遍，看加载数量和有没有报错行，比对着日志一行行猜省事得多。加载数为零通常不是规则写错，而是路径没挂对。

语义层最容易出问题

方向写反是我踩过最多的坑。flow:to_server 和实际流量方向对不上，或者匹配条件写得过宽，比如只在 User-Agent 里抓一个很常见的词，结果把所有正常请求都算进去了。遇到告警数量异常多，我一般只保留单条规则做二分定位，哪条一开就爆，问题就在哪条。改的方向基本是把匹配条件收紧，而不是急着加白名单去压制。

还有个不算误报但极容易误判的点：日志默认是 UTC，和本地时间差八小时。我有一次盯了半天以为告警没更新，其实只是时间对不上，统一按 UTC 比对就好。

真正让这套流程稳定的，是把有问题的流量固化成 PCAP 离线回放。每次改完规则跑一遍，命中数从几百掉到零，我才认为修好了。实时抓包受时序影响，同一场景很难复现，离线回放才能让“改一条规则、跑一次、比一次告警”变成十几分钟的短循环。规则文件和这些用例值得留着，环境本身随时可以扔掉。