文章Articles

Suricata 规则与告警

用 Suricata 做协议级检测，规则怎么写、告警怎么降噪、以及一条规则从加入到真正可信的过程。

更新Updated 2026.09.24monitoringidssuricata

定位

Suricata 做的是基于特征和协议状态的检测。它比 ntopng 知道得深，但也更容易误报。两者的关系是：ntopng 告诉你「这台机器今天出网 40 GB」，Suricata 告诉你「其中 38 GB 来自一个被标记为 PUA 的域名解析」。

单独上 Suricata 的人通常两周内就会放弃告警。先有 ntopng 的流量基线，再上 Suricata，规则才有调优依据。

部署形态

suricata -c /etc/suricata/suricata.yaml \
         -l /var/log/suricata \
         -S /etc/suricata/rules/local.rules \
         --af-packet

-S 只加载本地规则，-s 才是追加到默认规则集后面。本地规则永远放前面，先匹配自己关心的。
EVE JSON 输出是唯一推荐的日志格式，下游告警和后续统计都靠它。

outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: eve.json
      types:
        - alert:
            payload: yes
            payload-printable: yes
            http-body: yes
        - http
        - dns
        - tls
        - flow

写一条能用的规则

规则匹配与告警产出

规则的头部四段分别是动作、协议、源、目的，缺一不可：

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"ET EXPLOITION 常见 Web 后门文件名访问";
    flow:established,to_server;
    http.uri; content:".jsp;.php;.aspx"; nocase;
    http.uri; content:"/upload"; nocase;
    sid:1000001; rev:1;
    classtype:web-application-attack;
)

写规则时的几条硬约定：

sid 自己分段。本地规则用 1000000+，跟官方规则库的 rev 迭代不会撞。
每条规则必须有 classtype。没有分类的告警没法做抑制，也没法按严重度分派。
先写 flow:。flow:established,to_server 能砍掉大量 SYN 阶段的噪声。
不写 sid 递增就等于没写规则。规则文件里出现重复 sid 时，Suricata 只用第一条。

降噪

降噪的目标不是「少报警」，是「少报无意义的警」。三条最有效的：

聚合。同一条规则的重复告警在 EVE 里按 flow_id 合并，只在首次和末次记录。
抑制。为已知扫描器（内网资产探测平台）单独写 suppress 规则，按 src_ip + dest_port 抑制，别按签名抑制。
限速。threshold: type limit, track by_src, count 1, seconds 300 —— 同一源 5 分钟内同类只报一次。

不要做的降噪：直接把告警规则删掉。噪声来自规则不合适，不是规则没用。删掉之后，真实的那一次也跟着没了。

从「有告警」到「可信」

一条规则要满足下面三条才算落地：

在测试环境用真实流量触发过一次，payload 抓出来看过。
在生产上跑满两周，误报为零，或者误报来源已经被记录在规则注释里。
有明确的处置动作——收到这条告警要做什么。没有处置动作的告警，只会训练所有人忽略告警。

几个坑

规则更新不重启。suricata -T 测过之后要 systemctl reload，reload 是平滑的，但规则的 priority 变化不会立即生效于已有流。
EVE 日志写爆磁盘。开了 payload-printable 之后单条告警能到几 KB。按天数加 logrotate，别等磁盘满。
HOME_NET 配错。默认是 [192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]，如果内网用了 100.64.0.0/10（CGNAT）或 172.20 以外的段，方向会全部反。