Turning Cloudflare’s threat indicators into real-time WAF rules

一条 threat indicator 刚进系统，规则就开始挡流量，这种动作看起来很利落。节奏快，反馈快，报表也好看。可一旦把这件事放到生产里，真正难的就不再是把 indicator 变成 rule，而是让这条 rule 在流量、误报和回滚之间站得住。

读到 Turning Cloudflare’s threat indicators into real-time WAF rules 时，脑子里浮出来的不是“情报接入自动化”这种漂亮话，而是几个很实际的画面：一个 IP 被标红，十分钟后就进了拦截；一个 ASN 被标成高风险，结果把一整片共享出口都卷进去；一个短时攻击样本刚进入规则库，攻击流量已经切走，留下的是一条持续生效的旧规则。实时化在这里不只是速度问题，它会把规则生命周期、数据可信度和处置责任一起压缩进同一个窗口。

规则能快，前提是它能被收回

威胁指标进 WAF 之后，最先失去耐心的通常不是攻击者，而是值班的人。因为一条规则一旦生效，后面跟着的不是抽象的“安全提升”，而是具体的误伤、申诉、回滚和审计。IP 级别的指标最容易下放，单点命中、存活时间短、回收成本低；ASN、网段、TLS 指纹、请求组合这类指标就要谨慎得多，它们覆盖面更大，命中时的副作用也更难兜。

这件事真正值钱的部分，在于规则不是一次性写进去就结束，而是要带着 TTL、来源、命中范围和撤销条件一起出现。没有这些字段，实时规则很快会退化成一堆过期的封禁记录，今天挡过一次攻击，明天就开始挡正常用户。生产里最常见的坏味道，就是规则库越积越厚，保留下来的却不是有效判断，而是历史情绪。

指标层和动作层之间要留缓冲

把 threat indicator 直接翻译成 block rule，速度当然最快，但这一步也最容易把情报误差放大成线上事故。更稳的做法，通常要在 indicator 和 action 之间留一层缓冲，让同一条信号先经历观察、挑战、限速，再决定要不要真的封掉。这个缓冲层一旦缺失，指标更新得越快，规则误伤得也越快。

实际落地时，规则最好不是一个扁平的 on/off 开关，而是一组能表达动作强度的状态：先记录，再挑战，再限流，最后才进入拦截。这样做的好处很直接，规则可以随着证据变强逐步升级，也可以在证据变弱时快速降级。对安全团队来说，这比一次性把规则打满更能保住信誉；对业务侧来说，至少还能在异常波动刚冒头时看见它，而不是等到客服单堆起来才知道发生了什么。

{
  "action": "challenge",
  "scope": "path:/login",
  "ttl": "15m",
  "confidence": 0.82
}

这种结构看着朴素，实际很关键。confidence 低的时候，先挑战比直接拦截更像工程判断；ttl 到期后自动失效，才能避免旧情报一直挂在边上；scope 缩到路径或流量段之后，误伤面才不会无限放大。

没有回看，规则只会越长越像垃圾堆

实时 WAF 最怕的不是命中率低，而是命中以后没人知道后面发生了什么。规则打出去之后，必须能回看三件事：挡住了多少真实攻击，误杀了多少正常请求，命中后有没有带来新的绕过方式。只有把这三件事连起来，rule 才算是可运维的；少了任意一个，最后都会变成“反正先挡着”的惯性动作。

这也是 threat indicator 自动化里最容易被低估的部分。指标来源可能很多，情报更新也可能很频繁，但如果没有一条稳定的反馈回路，规则永远只是在往前推。真正成熟的系统，会把每条 rule 的命中率、回滚次数、人工放行次数、相关告警和业务损失一起记下来。到了这一步，规则已经不是单纯的安全配置，而是带着证据链的处置记录。

这套东西只适合已经有处置能力的团队

实时把 threat indicators 变成 WAF rules，并不适合所有场景。流量小、攻击面窄、人工值守也足够快的系统，继续靠静态规则和手工更新，往往更省事。真正需要这种能力的，通常是流量大、攻击密度高、规则变化频繁，而且已经有日志、回看和值班流程的团队。

这类系统一旦起来，价值并不只是“拦得更快”。更重要的是，把安全处置从一次性的人工判断，变成一条可撤回、可回看、可分级的执行链。Cloudflare 这类平台做这件事的优势，也不只是它能拿到更多威胁信号，而是它有能力把信号压到规则层，再把规则层接回监控、回滚和审计。没有这条链，实时化只会让错误更快发生；有了这条链，规则才算真正进入生产。