一个由贪婪匹配导致计算量剧增、CPU耗尽的事故

背景

2019年，七月二日，互联 安全和 络公司 Cloudflare 全球曾出现中断服务事件，其根源是一个不当的正则表达式耗尽了 CPU 资源。 这篇文章 分析了这个祸首，其简化后是 .*.*=.* ，它包含了三个贪婪匹配，进而导致计算量急剧增长，而耗尽 CPU 。Cloudflare 在该事件发生后是如何响应的呢？我们继续往后看。【篇幅太长，这里节选部分重点进行翻译。】

Cloudflare 之前做了什么

Cloudflare 有一个团队的工程师们负责 WAF 管理规程产品，他们经常致力于提高 WAF 的检测速率、降低误 率，提高新暴露威胁的快速响应能力。

最近 60 天，WAF 管理规则已经处理了 476 个变更请求，平均三小时一个。

引起此次中断服务的是一个特殊的变更，它被部署在一个叫 “ simulate ” 的模块中，在那里，客户真实的流量只是通过规则、但不会被拦截。这个模块是我们用来测试规则的效率、测量误 比率的。

虽然如此，但是，这个模块中的规则会执行，执行结果不会影响流量的通行。恰恰是这个模块中包含了一个不当的正则表达式，它消耗了过量的 CPU ，从而引发了此次事故。

故障在哪儿

正如前面所提及的，我们每周都要部署一沓新规则到 WAF 中，而且我们有大量的系统来阻止这些部署产生的任何负面影响。所以，出现状况的时候，这通常是多种原因汇聚成的结果，并且让人感觉不太可能发生。

找到一个简单的根源，虽然能让大家满意，但可能会掩盖现实。下面是一个脆弱性列表，每一项都是 Cloudflare 的 HTTP/HTTPS 服务中断的诱因：

1. 一个工程师写了一个很容易引发大量回溯的正则；
2. 本该保护 CPU 、避免其过度使用的功能，在几周之前的一次 WAF 重构中被错误地移除了，而这个重构的本意是为了减少 WAF对 CPU 的消耗；
3. 目前使用的正则表达式引擎没有复杂性保证能力；
4. 测试用例中没有辨别 CPU 过载消耗的案例；
5. 标准作业过程【SOP】的问题，它允许非紧急规则变更不经过阶段性地推出，就能直接进入全球产品中的；
6. 回滚计划需要完整的编译 WAF 两次，这耗费了太长的时间；
7. 第一次全球流量下降告警过了很长时间才被触发；
8. 我们的状态页面更新得不够及时；
9. 由于服务中断，系统访问是很困难的，而其他的访问路径又没有得到很好的训练；
10. 由于安全认证超时问题，导致SRE 无法访问一些系统；
11. 我们的客户不能访问 Cloudflare 的仪表盘或者 API 。

种种机缘巧合下，于是发生了 7 月 2 日的那场混乱！

上周四以后又发生了什么

首先，我们完全停止了所有 WAF 的发布工作，并且同时做了这些事情：

1. 移除导致 CPU 过度使用的保护能力【已完成】
2. 手动检查 WAF 管理规则中所有 3868 个规则，找出和修正其他任何可能导致过度回溯的实例【检查完成】
3. 将所有规则的性能分析引入测试用例中【计划完成时间： 7 月 19 日】
4. 切换到具有运行时保障的 re2 或 Rust regex engine 正则引擎【计划完成时间：7 月 31】
5. 改变了标准作业过程【SOP】，分阶段推出在 Cloudflare 的其他软件中以相同方式被使用的规则，但是仍然保留全局紧急部署的能力；
6. 把应急处理能力放置到重要位置，将原来的仪表盘和 API 从边缘地带挪出；
7. 自动化更新 Cloudflare 的状态页面。

从长远来看，Lua WAF 跟我多年前写的内容已经相差甚远。我们还会将 WAF 移植到新的防火墙引擎上，这样做不仅使得我们的 WAF 更快，而且还为它增加了一层保护能力。

我们的结论

对我们的客户和团队来说，这是一次令人苦恼的服务中断事件。我们对此快速响应，修正了这个问题，并且正在修正那些导致这些错误出现的有缺陷流程。替换了所使用的底层技术，更深入地了解正则表达式，以防止正则表达式使用可能出现的任何问题。

我们对此次的服务中断的发生，感到非常羞愧，给客户带来的影响深感歉意。我们相信，这样的事情将来不会再发生的！

启示录

看过了 Cloudflare 的处理过程，作为同行，能体会到这个事件在的 Cloudflare 内部引起的紧张氛围。这个处理过程跟我们日常查找问题的流程看似差异不大，修正问题后针对各种脆弱性问题，迅速修正、加固，这种企业行为模式值得学习。

亡羊补牢，犹未为晚！

这是一篇官宣的服务中断处理 告，中英的文化差异，加上能力有限，翻译出来的内容看着多少有些不顺溜。目前 络安全形势严峻，了解一点安全领域的大事件，也是必要的。姑且当作自己的写作训练了吧。