摘要

  • 2019 年 7 月 2 日，一条通过功能审批的 Cloudflare WAF 规则在数秒内传播到全球边缘；特定输入触发正则表达式灾难性回溯，HTTP/HTTPS 服务进程耗尽 CPU，客户连续 27 分钟看到 502 错误。
  • 真正的修复不是放弃快速防护，而是把普通变更与紧急全球发布拆成两种权限：上线前强制证明资源上界，逐级扩大真实流量，并确保终止操作、认证与状态通告不依赖正在故障的边缘系统。

先看四只钟

13:31，变更请求合并；13:37，构建与测试完成；13:42，自动流程开始部署；几秒之后，新规则已经可以在遍布全球的边缘节点上执行。Cloudflare 的完整事后分析称，配置分发系统 Quicksilver 当时覆盖 180 多座城市，平均每秒处理约 350 次变更，全球传播的第 99 百分位延迟为 2.29 秒。

这是一只被精心优化的钟：传播钟。

另外三只钟却没有同样快。第一只是准入钟——规则用什么证据取得全球执行资格；第二只是发现钟——系统何时能确认新规则正在伤害正常流量；第三只是撤权钟——它能多快让已经分发的能力停止生效。7 月 2 日的故障不是单纯因为第一只钟“走得太快”，而是四只钟没有形成一个控制系统。

快速分发本来有清楚的安全价值。WAF 面对正在利用的漏洞时，晚几分钟可能意味着更多客户暴露。Cloudflare 也以此前快速部署 SharePoint 漏洞防护为例，说明全球即时下发是核心能力。问题在于，这次只是普通的 XSS 检测规则更新，却通过了与紧急响应同样的直接全球通道。

测试证明了预期样本会被拦截、合法样本可以通过。它没有测量最坏输入会要求多少 CPU。一次“功能正确”的批准，于是连带授予了另一项未被审议的权力：让全球 HTTP/HTTPS 服务进程为这个判断支付计算成本。

正确答案也可能毁掉服务

故障表达式运行在基于 PCRE 的回溯引擎中。回溯并不等于错误。引擎会尝试表达式中不同的匹配路径，通常可以很快成功或失败。但某些结构遇到特定输入时，候选路径急剧膨胀，引擎为了得到最后那个“匹配”或“不匹配”的正确答案，可能花费指数级时间。

因此，安全规则有两种互不替代的正确性。语义正确性问：应该挡住的请求是否挡住了？资源正确性问：无论输入如何，一个请求最多能索取多少计算、内存与排队时间？Cloudflare 当时的测试覆盖了前者，没有覆盖后者。

WAF 又不在一个可以轻易隔离的离线工具里。它位于 HTTP/HTTPS 请求处理路径，大量请求需要经过数千条规则。新表达式在特定请求上持续消耗 CPU 后，负责代理、CDN 与 WAF 的服务进程失去处理能力。

这里需要保留一个常被摘要抹掉的细节。产生 502 页面的前端 Web 服务器仍有可用 CPU 核心；它们只是无法连接到真正处理 HTTP/HTTPS 流量的进程。不是“所有机器全部停止”，而是关键执行层被耗尽，外层只能报告内部不可达。

Cloudflare 列出的因果链还包括一项架构回退：系统原本存在 CPU 保护，但此前一次性能重构意外移除了它。所用引擎没有排除灾难性回溯的复杂度保证，测试没有检查失控的资源消耗，普通操作流程又允许直接全球部署。把事故归结为“工程师写坏了一行正则”，会让其他三个失效边界从复盘里消失。

告警追上来时，世界已经收敛

13:45，也就是部署后三分钟，外部 WAF 合成测试触发第一条 PagerDuty 告警。随后是其他端到端检查失败、全球流量下降、广泛 502，以及各地 PoP 报告 CPU 耗尽。Cloudflare 的短篇通报称，最严重时其流量下降 82%。这不是“82% 的互联网”，也不能被当作全球网站数量。

响应人员最初怀疑遇到前所未见的攻击。到 14:00，实时性能数据、strace 与错误日志共同把问题指向 WAF，攻击假设被排除。14:02，团队提出使用 global terminate，即从全球禁用整个 WAF 组件。

普通回滚却追不上。恢复上一版规则需要把完整 WAF 构建两次，对正在发生的全球故障来说太慢。最终有效的动作并不是“撤掉这一条规则”，而是先拿走整个 WAF 的执行权，再定位、回滚、测试，最后恢复。

撤权还受到自身依赖的妨碍。Cloudflare 的内部认证使用自家的 Access；边缘出问题后，常用控制面板、Jira 和构建系统也难以到达。团队不得不启用一个很少演练的绕行机制，部分 SRE 又发现长期未使用的凭据已被安全机制过期处理。

14:07，全球终止被执行；14:09，流量与 CPU 恢复到预期水平，其他防护机制继续运行。随后 Cloudflare 在一座城市先移走付费客户流量，用少量流量做正反两类测试。14:52，团队确认原因和修复后，才在全球重新启用 WAF。

完整事后分析把不可用时间写为 27 分钟，初步通报写“约 30 分钟”，二者并不矛盾。真正重要的是不对称：规则几秒钟取得全球执行，告警在全面暴露后才出现，精确回滚又比组件级紧急终止慢得多。

把“能表达什么”也当成治理

事故后，Cloudflare 宣布恢复 CPU 保护、检查全部 3,868 条 WAF 规则、加入性能分析，并迁移到 RE2 或 Rust 正则引擎。2020 年的后续文章称，WAF 已在 2019 年 7 月从基于 PCRE 的引擎转向受 RE2 启发的实现。

RE2 把安全目标写进了执行模型。其文档承诺匹配时间相对于输入长度是渐近线性的，内存受可配置预算限制，预算耗尽时平稳失败。为获得这个性质，它不支持反向引用、通用前后查找等只能依赖回溯实现的结构。

这不是说 RE2 对所有表达式都更快。项目自己说明，复杂表达式可能有更大的常数开销。迁移也未必只是替换库：依赖被排除特性的规则需要重新设计。其意义在于，系统不再要求每位规则作者和审批人凭经验识别每一棵指数级搜索树，而是从语言能力上收窄意外权限。

PCRE2 文档同样提供匹配、深度和堆内存限制。回溯引擎并非只能无界运行。但资料没有证明 2019 年的 Cloudflare 路径启用了这些限制。更一般地，文档里存在的阈值不等于生产系统中的有效边界。

Cloudflare 的后续测量也值得准确解读：引擎迁移本身没有带来可测的平均 CPU 下降，却降低了第 95 和第 99 百分位的执行时间离群值。韧性的目标恰恰在尾部，不是让每个普通请求都便宜一点，而是不让一个异常输入独占共享机器。

引擎仍不能独自完成全部防护。WAF 还有解码、规范化、分词、缓存与多规则交互。单次正则匹配有线性边界，不代表整条请求处理链都有边界。系统仍需在完整路径上测量代表性流量和恶意输入。

把普通通道与紧急通道分开

Cloudflare 的改进计划保留紧急全球部署，同时让日常规则走渐进发布。这比笼统要求“以后都慢一点”更成熟，因为安全系统确实需要在活跃攻击中迅速行动。

两条通道的差别应当是授权条件，而不只是界面上的按钮。普通规则先通过静态复杂度检查、对抗输入与全链路资源预算；再以不执法的影子模式观察；随后进入单一站点、小比例真实流量和区域阶段。每一步都同时监测安全命中、CPU、尾延迟、错误率与服务进程可达性，并设定自动中止阈值。

紧急通道可以跳过部分观察时间，却需要更明确的事故编号、负责人、威胁依据、到期时间和实时撤权人。紧急不是“不受约束”，而是把风险交换公开化：已知漏洞正在造成的损失，大于快速规则可能带来的损失。

金丝雀阶段也必须具有真正的隔离。如果所谓 5% 节点仍共享同一个会被拖垮的队列，或者故障会同时破坏测量系统，那么比例小并没有产生可用证据。合格的阶段需要代表性请求、独立容量、对照组和仍能工作的遥测。

撤权不能以“重新构建两次”作为默认路径。一条规则获得独立标识和立即禁用能力，整个 WAF 又保留组件级终止，二者应当分层存在。演练必须假设主控制台、身份认证和构建服务同时失效；否则测试的只是平时的便利路径。

控制面必须在被控制对象之外留一口气

Cloudflare 使用自身服务不是事故起点，却放大了恢复难度。客户的控制台和 API 也经过受影响边缘。服务最需要被操作时，操作入口恰好与它共同失效。

独立控制面不等于在另一家公司复制整套 Cloudflare。它可以很窄：独立状态通告、紧急认证、全局终止、最少配置变更、证据读取，以及足以减少客户损失的控制能力。它需要隔离容量、不同故障域和定期使用的凭据。没有正常流量的绕行路径，也属于生产系统。

Heng Lu 的“运行代码优先”在这里不是反对流程，而是给流程设验证条件。合并记录、审批票据和书面回滚方案都是协调物；只有真实机器上的执行结果才能赋予它们运行意义。规则已经耗尽服务 CPU 时，“它通过了审批”不再构成安全事实。

“技术控制”与“实际控制”的区分同样适用。组织在技术上可能拥有全局终止命令，但如果认证、人员凭据、构建与控制台都依赖正在故障的边缘，这项权力在最需要的时刻就不是完整的实际控制。控制能力必须按危机中能否行使来计量。

证据边界

详细时间线、内部架构、原因和改进计划主要来自 Cloudflare 自身。公开复盘具有重要价值，但仍是公司自述；现有来源没有独立审计客户数量、域名数量、失败请求或经济损失。

Cloudflare 明确表示这不是一次攻击。本文不推断有人恶意构造或主动触发输入。Quicksilver 没有制造表达式缺陷，也没有移除 CPU 防护；它的作用是放大器，因为普通审批可以调用它完整的全球能力。

2020 年文章为引擎迁移和尾部性能改善提供了后续证据，却不能证明 2019 年列出的每项流程和控制面承诺此后一直完整。这个案例支持一套权限设计，不支持“某种引擎或某家公司已经不会再失败”的结论。

来源