差不多九年前，Cloudflare还是一家小公司，我是客户而不是员工。Cloudflare在一个月前发布，有一天警报告诉我，我的小网站，jgc.org网站，似乎不再有可用的DNS。Cloudflare已经对协议缓冲区的使用进行了修改，并且破坏了DNS，我直接给Matthew Prince写了一封题为"我的DNS在哪里？"他回复了一个冗长、详细、技术性的回复（你可以在这里阅读完整的电子邮件交流）回答：来自：约翰·格雷厄姆·卡明日期：2010年10月7日星期四上午9:14主题：回复：我的域名系统在哪里？收件人：马修·普林斯很棒的报告，谢谢。如果有什么事我一定会打电话给你问题。在某种程度上，最好把它写为当你有所有技术细节的博客文章，因为我认为人们真的很欣赏这些事情的坦诚。尤其是如果你把它和你发布后的图表结合起来交通量增加。我对我的网站有很强的监控能力，所以当任何事都失败了。监控显示我从13:03:07到14： 04时12分。每五分钟做一次测试。我相信你会过去的。但你确定你在欧洲不需要人吗？:-)对他来说回答：来自：马修·普林斯日期：2010年10月7日星期四上午9:57主题：回复：我的域名系统在哪里？收件人：John Graham Cumming谢谢。我们已经回信给每一个写信的人。我要去办公室现在，我们会在博客上写些东西或者给一个官员下针张贴到我们的公告栏系统的顶端。我100%同意透明度最好。因此，今天，作为一个更大的Cloudflare的员工，我可以透明地写下我们犯下的错误、它的影响以及我们正在做什么它。那个7月2日的事件7月2日，我们在WAF管理的规则中部署了一个新规则，该规则导致处理HTTP/HTTPS流量的每个CPU核心上的CPU耗尽全球Cloudflare网络。我们不断改进WAF管理的规则，以应对新的漏洞和威胁。例如，在5月份，我们使用了更新WAF的速度来推动一个规则来防止严重的SharePoint漏洞。能够快速、全局地部署规则是我们哇。很不幸，上周二的更新包含一个正则表达式，该表达式极大地回溯并耗尽了用于HTTP/HTTPS服务的CPU。这降低了Cloudflare的核心代理、CDN和WAF功能。下图显示了专用于服务HTTP/HTTPS流量的CPU，在我们的网络.CPU在意外事件期间，我们的一个POP的利用率这导致我们的客户（及其客户）在访问任何Cloudflare域时看到502错误页。502个错误是由一线Cloudflare web服务器生成的，这些服务器仍有CPU核心可用，但无法访问服务于HTTP/HTTPS的进程交通。我们知道这对我们的顾客有多大的伤害。我们为这事的发生感到羞耻。这也对我们自己的业务造成了负面影响意外。它如果你是我们的客户，一定会感到非常紧张、沮丧和恐惧。更令人不安的是，我们已经六年没有全球停电了。CPU耗尽是由一个WAF规则引起的，该规则包含一个写得不好的正则表达式，最终导致了过度的回溯。处于中断核心的正则表达式是（？）？:(?：\"|''| \]| \}| \ \ |\d |（？：nan |无穷大|真|假|空|未定义|符号|数学）| \` | \-| \+）+[）]*；？((?：\s |-| ~ |！|{}|\|\||\+)*.*(?：.*=.*））尽管正则表达式本身是许多人感兴趣的（下面将详细讨论），但是Cloudflare服务中断27分钟的真实情况比"正则表达式坏了"要复杂得多。我们已经花时间写下了导致停机并阻止我们快速响应的一系列事件。如果你想知道更多关于正则表达式回溯的知识，你可以在后面的附录中找到波斯特。什么happenedLet从事件的顺序开始。在这个博客里的所有时间UTC.时间13： 42一位在防火墙团队工作的工程师通过一个自动过程对XSS检测规则做了一个小小的修改。这生成了一个变更请求单。我们用Jira来管理这些票，截图是下面。三几分钟后，第一个页面显示出WAF有故障。这是一个综合测试，从Cloudflare外部检查WAF的功能（我们有数百个这样的测试），以确保它正常工作。紧接着的页面显示，Cloudflare服务的许多其他端到端测试失败、全球流量下降警报、普遍存在的502个错误，以及我们在全球各地城市的存在点（pop）的许多报告都表明存在CPU精疲力竭。有些这些警报击中了我的手表，我跳出了我参加的会议在我回到办公桌的路上，我们解决方案工程组的一位领导告诉我，我们的流量减少了80%。我跑去SRE那里小组正在调试情况。在停机的最初时刻，有人猜测这是一次我们从未见过的攻击云闪之前SRE的团队分布在世界各地，全天候持续报道。像这样的警报，其中绝大多数都注意到局部地区范围有限的非常具体的问题，这些警报在内部仪表板中进行监控，并且每天处理多次。然而，这种页面和警报模式表明发生了严重的事件，SRE立即宣布发生了P0事件，并上报给工程领导和系统工程部。The当时，伦敦工程队正在我们的主会场里听一场内部技术讲座。谈话被打断了，大家聚集在一个大会议室里，其他人都拨了进来。这不是一个正常的问题，SRE可以单独处理，它需要每个相关团队在线一次。在14： 00 WAF被确定为导致问题的部件，并排除了攻击的可能性。性能团队从一台明确显示WAF负责的机器上提取了实时CPU数据。另一名队员用斯特拉斯证实了这一点。另一个团队看到错误日志，表明WAF有问题。14时02分，当有人提议我们使用"全局终止"时，整个团队都看着我，这是一种内置于Cloudflare中的机制，用于在全球范围内禁用单个组件。但全球WAF的终止则是另一回事。事情阻碍了我们。我们使用自己的产品，在访问服务关闭的情况下，我们无法对内部控制面板进行身份验证（一旦我们回来，我们会发现有些团队成员由于安全功能而失去访问权限，如果他们不经常使用内部控制面板，则会禁用他们的凭据）。我们无法访问其他内部服务，如Jira或构建系统。为了找到他们，我们必须使用一个不常用的旁路机制（另一个在事件发生后要钻的东西）。最终，一名团队成员在14:07执行了全球WAF终止，到14:09流量级别和CPU恢复到全球预期水平。Cloudflare的其他保护机制继续操作。然后我们继续恢复WAF功能。由于情况的敏感性，我们进行了两个阴性测试（问自己"是不是那个特定的变化导致了问题？"）在去除付费用户的流量后，在一个城市中使用流量子集进行的阳性测试（验证回滚是否有效）位置。在14： 52我们100%满意，因为我们了解原因，并已修复到位，WAF重新启用全球。怎么做Cloudflare运营Cloudflare有一个工程师团队我们的WAF管理规则产品；他们不断努力提高检测率，降低误报率，并在新的威胁出现时迅速作出反应。在过去60天内，针对WAF管理的规则处理了476个更改请求（平均每3小时处理一个）。此特定更改将以"模拟"模式部署，在该模式下，真实的客户流量通过规则，但没有任何内容被阻止。我们使用该模式来测试规则的有效性，并测量其假阳性率和假阴性率。但即使在模拟模式下，规则实际上也需要执行，在本例中，规则包含一个消耗过多的正则表达式中央处理器从上面的变更请求可以看出，对于这种类型的部署，有一个部署计划、一个回滚计划和一个指向内部标准操作过程（SOP）的链接。规则更改的SOP特别允许将其推送到全局。这与我们在Cloudflare发布的所有软件都有很大不同，在这里，SOP首先将软件推送到内部dogfooding网络存在点（PoP）（我们的员工通过PoP），然后将软件推送到一个孤立位置的少数客户，接着一推一大批客户，最后世界。世界我们内部使用的是一个bucket软件。负责变更的工程师将推送TeamCity构建的代码，当构建通过时，将指派审阅者。一旦pull请求被批准，代码就被构建并运行测试套件（再次）。如果构建和测试通过，那么将生成一个变更请求Jira，并且变更必须得到相关经理或技术负责人的批准。一旦批准部署到我们称之为"动物PoPs"的地方：狗、猪和金丝雀DOG PoP是一个Cloudflare PoP（就像我们在全球的任何一个城市一样），但它只供Cloudflare员工使用。这种dogfooding PoP使我们能够在任何客户流量触及代码之前及早发现问题。而且经常这样是的。如果DOG测试成功通过，代码转到PIG（如"豚鼠"）。这是一个Cloudflare PoP，其中一小部分客户tra