在过去，我们已经讨论过Cloudflare是如何构建以支持最大的DDoS攻击的。在流量激增期间，我们将流量分散在大量的边缘服务器上。这种体系结构使我们能够避免出现单一的瓶颈，因为流量在外部分布在多个数据中心，在内部分布在多个服务器上。我们通过使用Anycast和ECMP来做到这一点。我们不使用单独的清理箱或专用硬件-如果需要，我们的每台边缘服务器都可以执行高级流量过滤。这使我们能够在增长时扩大DDoS容量。我们添加到数据中心的每台新服务器都增加了我们最大的理论DDoS"净化"能力。它还可以很好地缩小规模——在较小的数据中心，我们不必在昂贵的专用硬件上过度投资。在正常行动中，我们对攻击的态度相当务实。由于入站流量分布在数百台服务器上，我们可以在周期性峰值和小型攻击中不采取任何措施。香草Linux对于意外的网络事件具有非常强的弹性。尤其是在内核4.4中，SYN cookies的性能大大提高。但在某些时候，恶意流量会变得如此之大，以至于我们必须从网络堆栈中卸下负载。我们必须将处理攻击数据包所花费的CPU数量最小化。Cloudflare运行多租户服务，我们必须始终拥有足够的处理能力来处理有效的流量。我们不能耗尽我们的HTTP代理（nginx）或自定义DNS服务器（名为RRDNS，用Go编写）的CPU。当攻击规模超过预先设定的阈值时（根据具体的攻击类型，这会有很大的变化），我们必须进行干预。缓解措施在大型攻击期间，我们部署缓解措施以减少恶意流量消耗的CPU。我们有多个防御层，每一层都调整到特定的攻击向量。首先是"散射"。由于我们控制DNS解析，我们能够在IP地址之间移动我们服务的域（我们称之为"分散"）。只要攻击不遵循更新的DNS解析，这是一种有效的技术。这种情况通常发生在攻击者硬编码目标IP地址的L3攻击中。下一步，还有一系列利用iptables的缓解技术，iptables是Linux内核中内置的防火墙。但我们并不像传统的防火墙那样使用它，它有一套静态的规则。我们根据特定的攻击特征不断添加、调整和删除规则。多年来，我们已经掌握了最有效的iptables扩展：下一个bpfipsets公司哈希限制连接限制为了充分利用iptables，我们建立了一个系统来管理我们整个舰队的iptables配置，允许我们在任何地方快速部署规则。这很适合我们的架构：由于Anycast，针对单个IP的攻击将被传递到多个位置。在所有服务器上为该IP运行iptables规则是有意义的。使用库存iptables给了我们足够的信心。如果可能，我们更喜欢使用现成的工具来处理攻击。有时，即使这样也不够。Iptables在一般情况下很快，但也有其局限性。在每台服务器每秒超过1M包的非常大的攻击中，我们将攻击流量从内核iptables转移到一个绕过内核的用户空间程序（我们称之为floodgate）。我们使用了一个部分内核旁路解决方案，使用Solarflare EFüVI接口。在每台服务器上，我们可以每秒处理超过5百万个攻击包，同时只消耗一个CPU核心。使用floodgate，即使在最大的网络事件中，我们也可以为应用程序留下足够的CPU。最后，我们可以在HTTP层进行一些调整。对于特定的攻击，我们禁用HTTP保持有效，从而迫使攻击者为每个请求重新建立TCP会话。这也会牺牲一些性能来获得有效的流量，但却是一个令人惊讶的强大工具，可以抑制许多攻击。对于其他攻击模式，我们打开"我在攻击"模式，迫使攻击攻击攻击我们的JavaScript挑战页面。手动攻击处理早期，这些缓解措施是由我们孜孜不倦的系统可靠性工程师（SRE）手动实施的。不幸的是，事实证明人类在压力下。。。好吧，犯错吧。我们艰难地学会了这一点——2013年3月，一个简单的打字错误导致整个网络瘫痪，这是最著名的事件之一。人类也不善于运用精确的规则。随着我们的系统不断增长，缓解变得越来越复杂，有许多特定的切换，我们的sre被细节淹没了。所有关于攻击的信息都是向操作员提出的。我们经常采取不必要的、不必要的缓解措施。随着Gatebot的引入，一切都改变了。认识Gatebot为了帮助我们的SRE，我们开发了一个全自动的缓解系统。我们称之为Gatebot[1]。Gatebot的主要目标是尽可能多地自动化缓解工作流程。这意味着：观察网络并注意异常情况，了解攻击目标及其元数据（例如涉及的客户类型），并执行适当的缓解措施。现在我们有多个Gatebot实例-我们称之为"缓解管道"。每条管道有三部分："攻击检测"或"信号"-专用系统检测网络流量中的异常。这通常是通过抽样一小部分网络数据包到达我们的网络，并分析他们使用流算法。这样我们就可以实时查看网络的当前状态。堆栈的这一部分是用Golang编写的，尽管它只检查采样的数据包，但它占用了大量的CPU资源。在这个时刻，两台大型Xeon服务器烧掉了所有48个Skylake CPU核心，他们在计算数据包和执行复杂的分析以寻找攻击，这可能会让你感到安慰。"反应式自动化"或"业务逻辑"。对于每一个异常（攻击），我们可以看到目标是谁，我们是否可以减轻它，以及使用什么参数。根据具体的管道，业务逻辑可以是任何东西，从一个简单的过程到一个多步骤的过程，需要大量的数据库查找，并且可能需要人工操作员的确认。这段代码不是性能关键的，是用Python编写的。为了让公司的其他人更容易访问和阅读，我们开发了一个简单的功能，反应式编程引擎。它帮助我们保持代码的整洁和可理解性，即使我们添加了更多的步骤、更多的管道和更复杂的逻辑。让您了解一下复杂性：想象一下，如果客户在攻击期间升级了计划，系统应该如何运行。"缓解"。上一步将特定的缓解指令输入集中式缓解管理系统。这些缓解措施部署在世界各地的服务器、应用程序、客户设置，有时还部署到网络硬件上。晚上睡觉Gatebot不停地工作，午餐不休息。仅就iptables缓解管道而言，Gatebot每天参与30到1500次。以下是过去6个月每天的缓解情况图表：Gatebot比我们最有经验的sre要快得多，也要精确得多。如果没有Gatebot，我们将无法以适当的信任级别运行我们的服务。此外，Gatebot已经被证明具有很强的适应性——我们从自动处理第三层攻击开始，但很快我们就证明了通用模型在自动化其他事情方面很有效。今天，我们有10多个独立的Gatebot实例，从减轻第7层攻击到通知我们的客户支持团队客户源服务器的不当行为。自从Gatebot诞生以来，我们从"检测/逻辑/缓解"工作流程中学到了很多东西。我们在自动网络系统中重新使用了该模型，用于缓解网络拥塞[2]。Gatebot允许我们保护我们的用户，不管计划如何。无论你是一个免费，专业，商业或企业计划，Gatebot是为你工作。这就是为什么我们能够为所有客户提供相同级别的DDoS保护[3]。处理攻击听起来很有趣？加入我们在伦敦、奥斯汀、旧金山和波兰华沙的全球知名DDoS团队。有趣的事实：我们在这个领域的所有组件都被称为"门的东西"，比如：看门人，看门人，洪水门，看门人，看门人。。。谁说给事物命名一定很难？↩︎我们有些人认为这个系统应该被称为上网本。↩︎注意：有一些注意事项。向你的成功工程师询问具体细节！↩︎