排查规则不告警与误报膨胀的常见故障

约 25 分钟

能按步骤排查规则不加载、不告警、误报膨胀等问题，定位配置或规则缺陷。

上一课，我们在授权攻击 PCAP 与正常背景流量中对比回放，验证针对分片、编码与协议混淆的规则命中与误报——但如果回放跑完，fast.log 却一片空白，先冷静：引擎不会无缘无故沉默，日志会告诉你它看到了什么、拒绝了什么。

排查「不告警」有一条固定路径——把链路拆开，逐层验证：规则有没有被加载？流量有没有被检测到？匹配条件是否真的成立？输出有没有落盘？四层全过，告警才会出现。

Suricata 的配置集中在 suricata.yaml。规则文件放错位置时，启动日志会给出路径线索，请对照日志逐条核对配置中的路径。验证检测效果用离线回放最稳妥：-r path-to-pcap 只读 PCAP 文件，不碰线上流量。别忘了，fast.log 输出要在 suricata.yaml 中启用，否则匹配到了也不会有告警记录。

核心概念

规则排查：分层定位故障

类比：厨房的烟雾报警器在你炸糊菜时不响。你不会先拆天花板，而是按顺序验证：报警器通电了吗（规则加载了吗）？探头对着灶台吗（流量经过检测了吗）？警报器本身会响吗（输出链路正常吗）？一层层排除，问题自然现身。

定义：规则排查（rule-troubleshooting）是把「规则不告警」或「误报膨胀」拆成独立层次、逐层验证的方法。四个层次依次是：解析层——用测试模式确认规则语法可读；加载层——确认规则文件被 suricata.yaml 引用，启动日志中没有规则加载错误；检测层——确认流量特征与规则条件真实相交，地址、端口、方向、content 都要对上；输出层——确认 fast.log 与 eve.json 输出已启用并写入。误报膨胀是同一根链路的反面：不是「没匹配」，而是「匹配得太宽」——回到检测层收紧规则边界，再在抑制层补 threshold 或 suppress。

遇到问题：启动或离线回放后，fast.log 始终没有目标告警；suricata.log 中出现规则解析错误，或自定义规则文件被整体跳过。

可能原因

  • 规则语法错误：括号或引号不配对、关键字拼写错误，整条规则被引擎拒绝。
  • 规则文件路径与 suricata.yaml 中的配置不一致，引擎根本没有读取该文件。
  • 规则文件不在引擎读取的规则目录（如 /var/lib/suricata/rules 下的 suricata.rules）中，也未被配置引用。
  • fast.log 输出未在 suricata.yaml 中启用，规则匹配成功但告警无处落盘。

排查步骤

  1. 先用测试模式校验规则：suricata -T（沿用第一章 suricata-test-mode 的用法）。解析报错时把规则逐条拆分，用二分法定位问题行。
  2. 对照 suricata.log 中列出的每条路径，逐一核对 suricata.yaml 中的配置是否指向真实存在的文件。
  3. 确认自定义规则文件被 suricata.yaml 引用，或放入 /var/lib/suricata/rules；运行服务时用 sudo systemctl restart suricata 重新加载。
  4. 确认 suricata.yaml 中 fast.log 输出处于启用状态；用 tail /var/log/suricata/suricata.log 观察启动信息。
  5. 用 ET Open 自带的测试规则（sid:2100498，content 为 uid=0|28|root|29|）回放，确认输出链路能产出告警，再回头查自己的规则。

按层定位「规则不告警」

  1. 1

    校验语法。用第一章的测试模式运行，解析错误会直接指出问题行；修复后重跑，直到校验通过。

    bash
    sudo suricata -T
  2. 2

    查加载层。用 tail 查看启动日志，确认引擎正常启动、没有规则加载错误；同时核对 suricata.yaml 中的规则文件路径与实际文件是否一致。

    bash
    sudo tail /var/log/suricata/suricata.log
  3. 3

    核对 HOME_NET 与接口配置。默认 HOME_NET 覆盖 192.168.0.0/16、10.0.0.0/8、172.16.0.0/12，EXTERNAL_NET 是其补集；若你的内网不在其中，带方向的规则可能永远匹配不上。af-packet 段中的接口名要与实际网卡一致。

  4. 4

    验证检测层。用离线回放跑授权 PCAP；若仍无告警，换 ET Open 测试规则 sid:2100498 回放含 uid=0(root) 的样本，判断是规则问题还是链路问题。

    bash
    suricata -r path-to-pcap
  5. 5

    查输出层。确认 suricata.yaml 中 fast.log 输出已启用；再检查 eve.json 是否记录了事件，两条日志交叉验证。EVE JSON 可用官方推荐的 jq 工具查看。

  6. 6

    修复并复验。改完配置或规则后重新回放同一 PCAP，确认目标 sid 的告警同时出现在 fast.log 与 eve.json；把故障原因写进规则注释，避免重复踩坑。

你应该看到

定位并修复至少一类「规则不告警」故障（解析错误、规则路径或 HOME_NET 配置错误、fast.log 未启用），再次回放授权 PCAP 后，目标规则告警同时出现在 fast.log 与 eve.json 中。

遇到问题：某条规则的告警在短时间内爆炸式增长，同一 sid 在 fast.log 中刷屏，分析人员开始习惯性忽略它——误报疲劳正在形成。

可能原因

  • content 匹配串太短或太常见，命中大量正常业务流量；未用 depth、offset、distance、within 收窄匹配位置。
  • 规则未用 flow 限定会话方向，客户端与服务端流量都被计入命中。
  • 规则边界过宽：端口、地址或协议限定太松，与生产流量形态不匹配。
  • 缺少 threshold 或 suppress 抑制配置，同一会话反复触发同一 sid。

排查步骤

  1. 回溯规则边界：把 content 换成更长、更唯一的匹配串，或用第二章的修饰符把匹配收窄到关键位置。
  2. 用 flow 限定方向（to_server / to_client），排除无关方向的命中。
  3. 对照流量基线收紧地址与端口范围，让规则只覆盖目标资产和协议。
  4. 对该 sid 配置 threshold 或 suppress（第五章已覆盖），在授权 PCAP 上复验告警量是否回到合理水平。
  5. 上线前用规则性能分析评估该规则的匹配开销，避免为了压误报反而拖垮吞吐。
自检：规则通过了测试模式校验，回放授权 PCAP 后 fast.log 仍然没有目标告警。按分层排查的顺序，接下来应该检查哪些点？请至少说出三个检查点，并给出顺序。

先查加载层：用 tail /var/log/suricata/suricata.log 确认规则被加载，核对 suricata.yaml 中的规则文件路径与实际文件一致、文件被配置引用。再查检测层：核对 HOME_NET 是否覆盖内网地址、方向是否与流量一致，确认 suricata -r path-to-pcap 指向正确的样本。最后查输出层：确认 fast.log 输出已在 suricata.yaml 中启用。修复后重新回放，目标告警应同时出现在 fast.log 与 eve.json 中。