Snort规则怎么写才有效？

在实际部署中，Snort的价值往往取决于规则的精准度。写出一条“有效”的规则，不是把所有流量都塞进去，而是抓住攻击的关键痕迹，让告警既及时又可信。

规则结构拆解

每条规则由规则头和规则选项两大块组成。规则头固定顺序：动作 协议 源IP 源端口 方向 目的IP 目的端口，动作常见的有 alert、log、pass。选项则是键值对，msg、content、sid、rev、classtype、threshold 等交织成检测逻辑。只有当头部和所有选项都满足时，Snort 才会触发对应的动作。

常见误区

• 把 any 当作默认安全阈值，导致大量噪声。
• 仅依赖 content 字符串，却忽视了协议层的解码或分段重组。
• 规则 ID（sid）冲突或留空，管理平台难以追踪。
• 忘记为每条规则设定 rev，后续修订难以辨别。

实战写法技巧

针对 Web 攻击，常用的三层过滤思路是：①限制协议范围（如仅 TCP 且端口 80/443），②锁定关键负载（content+nocase），③加入频率阈值（threshold）防止爆炸式告警。举例来说，SQL 注入常伴随 select、union、-- 等关键字，使用 pcre 正则可以一次匹配多种变形。

alert tcp $HOME_NET any -> $EXTERNAL_NET 443 (msg:"WEB-ATTACK possible SQLi"; flow:to_server,established; pcre:"/select.+(from|where)/i"; pcre:"/unions+select/i"; threshold:type limit, track by_src, count 5, seconds 60; sid:2100001; rev:3; classtype:web-application-attack;)

调优与测试

规则写好后，别急着投入生产。使用 snort -T -c /etc/snort/snort.conf 语法检查，随后借助 tcpreplay 或 hping3 重放已知攻击流量，观察 unified2 或 syslog 中的告警是否符合预期。若误报率偏高，可尝试加入 depth、offset 限制匹配位置，或在 threshold 中调高 count。