Cloudflare WAF 接入实时威胁情报

Cloudflare WAF 接入实时威胁情报，自动拦截高危流量

Cloudflare 在 2026 年 6 月宣布了一项重要的安全能力升级：把 Cloudforce One 的实时威胁情报直接接入 WAF 引擎，允许安全团队基于"谁在攻击、攻击谁、用什么方式攻击"等信号编写主动拦截规则。过去，安全团队往往在 Threat Events 平台上看到某个 IP 与特定攻击组织（如 Tycoon 2FA、RaccoonO365）关联，却只能手动复制 IP 列表去配置规则；现在这些情报可以直接变成 WAF 规则，在攻击者触达你的基础设施之前完成拦截。

新增的 WAF 字段

为了让威胁情报可用于规则匹配，Cloudflare 在 WAF 中暴露了以下 cf.intel 字段：

字段	说明
cf.intel.ip.attacker_names	已知攻击组织的名称（如 CRAVENFLEA）
cf.intel.ip.target_industries	该 IP 曾经攻击的行业（如加密货币、汽车）
cf.intel.ip.attacker_countries	威胁事件的来源国家
cf.intel.ip.target_countries	威胁事件针对的国家
cf.intel.ip.datasets	数据来源（如 ddos、waf）

由于一个 IP 可能同时关联多个攻击者或行业，这些字段以数组形式存在，配合 any() 函数和 [*] 通配符即可写复杂规则，例如：

拦截针对你所在地区发起的已知 DDoS 参与方：any(cf.intel.ip.target_countries[*] == "FR") and any(cf.intel.ip.datasets[*] == "ddos")
防护针对金融行业的具体攻击者：any(cf.intel.ip.target_industries[*] == "Banking & Financial Services") and any(cf.intel.ip.attacker_names[*] == "BLACKBASTA")

Always-on 检测：检测与拦截分离

这套能力构建在 Cloudflare 的 always-on 检测框架上：威胁情报在后台持续运行，为每个 HTTP 请求补充威胁元数据，而不是等规则命中才产生日志。这样做消除了传统"日志模式 vs 拦截模式"二选一的困境——因为一旦拦截，你就看不到其他签名对这条请求的判断。

性能方面，威胁情报数据集会被压缩并分发到全球每个数据中心，WAF 用 O(1) 常数时间完成本地查找，无论比对 10 条还是 1000 万条指标，延迟开销都只有微秒级。当前版本聚焦 IP 匹配，下一步将扩展到 JA3/JA4 指纹和域名匹配，应对攻击者轮换 IP 的情况。

使用方式与对建站的意义

这些字段完全集成到 WAF 自定义规则与速率限制规则中，支持通过 Cloudflare API 和 Terraform 以基础设施即代码的方式管理；命中记录会进入 Security Analytics，方便审计与事后分析；Threat Events 仪表盘的筛选视图也可以一键导出为 WAF 规则。

对普通网站来说，这意味着安全防护从"静态规则"走向"动态情报"。先做好基础配置，可以参考WAF 入门指南和网站安全最佳实践，再结合安全加固分类下的内容逐步完善防护体系。

用 Terraform 管理威胁情报规则

文章提到规则可通过 Cloudflare API 与 Terraform 管理。用 Terraform 写一条"拦截已知 DDoS 参与者且针对本地区"的规则大致如下：

resource "cloudflare_ruleset" "waf_threat_intel" {
  zone_id = var.zone_id
  kind    = "zone"
  phase   = "http_request_firewall_custom"

  rules {
    action = "block"
    expression = <<EOT
any(cf.intel.ip.target_countries[*] == "FR") and
any(cf.intel.ip.datasets[*] == "ddos")
EOT
    description = "block known DDoS participants targeting France"
  }
}

把规则纳入 terraform plan / apply 的流程后，团队就能对"改了哪条规则、为什么改"留痕，也方便一键回滚。相比在控制台里点选，这种方式更适合规则数量多、需要多人协防的团队。

参考：https://developers.cloudflare.com/ruleset-engine/rules-language/expressions/

落地路线：从小站点到高价值目标

对绝大多数站点，不建议一上来就订阅威胁情报。更务实的落地顺序是：

先开托管规则：启用 Cloudflare 自带的 WAF 托管规则集与速率限制，把最常见的注入、扫描与暴力破解挡在门外；
用 Security Analytics 观察：花一两周看哪些地区、哪些路径在持续探测你的站点，把发现沉淀成自定义规则；
再考虑情报规则：当业务暴露面变大、或遭遇过针对性的 DDoS 与钓鱼团伙时，再评估 cf.intel 字段与付费威胁情报；
配合其他安全措施：威胁情报只解决"已知攻击者"这一层，证书、双重验证、备份与补丁仍然不可省略（参见网站安全最佳实践）。

常见问题

cf.intel 字段需要付费订阅才能用吗？ 字段是否可用取决于套餐层级与威胁情报的授权范围，建议先在自己的套餐里试写一条规则确认；托管规则与速率限制则随套餐内置。
Always-on 检测会增加请求延迟吗？ 官方设计是 O(1) 本地查找、微秒级开销，正常流量几乎无感知；真担心可以用对比测试验证。
误拦怎么办？ 先以"仅记录（log）"模式上线，观察几天命中情况再切"拦截"，并给规则加上明确的描述与 tag，方便事后审计。
只靠 WAF 就够了吗？ 不够。WAF 只是流量入口的一层防护，源站安全、访问控制、备份与恢复同样重要，分层防御比堆单点更强。

16IDC 观察

"情报驱动的实时拦截"把安全运营从"事后封禁"推向"事前拦截"，但对绝大多数中小网站来说，直接订阅商业化威胁情报并不现实。更务实的做法是分层：先启用 CDN 自带的 WAF 托管规则与速率限制，把常见攻击挡在门外；再结合安全分析日志，观察哪些地区、哪些路径在持续探测你的站点，针对性编写自定义规则。当业务体量增长、暴露面变大时，再评估是否引入威胁情报订阅。安全投入应该跟着风险走，而不是跟着厂商的功能清单走。

原文来源：https://blog.cloudflare.com/realtime-threat-intel-waf-rules/

Cloudflare WAF 接入实时威胁情报，自动拦截高危流量