拒绝服务攻击

本文是翻译,版权归原作者所有


3月11号,星期二,GitHub由于分布式拒绝服务攻击(DDos)宕机两小时。我知道你希望GitHub一直是可访问的,我非常抱歉让你失望了。我想解释发生了什么,我们如何应对的,以及我们正在做未来减少这种攻击的影响的工作。

背景

从去年开始,我们已经注意到了大量的、形式多样的、针对GitHub基础设施各个部分的拒绝服务攻击。我们在建立减弱策略时要考虑的两种大概的攻击类型有:容量耗尽的攻击和复杂的攻击。

我们已经设计的DDos减弱策略可以响应这两种攻击。

容量耗尽攻击

容量耗尽攻击目的是通过陡增的攻击来消耗某些资源。随着基于使用DNS、SNMP或NTP之类的协议的放大攻击的、UDP的越来越快频率的延迟,这种攻击逐渐显现。抵御攻击的唯一办法是拥有比所有攻击节点总量还要多的可用网络容量,或者在它达到你的网络之前过滤掉攻击流量。

对付容量耗尽攻击是一个数量游戏。谁有更多的容量谁就获胜。在这个思路下,我们采取了一些步骤让我们防御这些种类的攻击。

我们以非常低效的方式操作外部网络连接。我们内部运输环路能够处理比正常每日峰值差不多更多的流量。我们也继续评估扩展网络容量的机会。这给我们更大流量的净空,尤其是,一段时间内它们倾向于加速增长到其最大峰值的吞吐量。

除了管理我们自己网络的容量,我们和一家领先的DDoS减弱服务提供商进行合作。一个简单的Hubot命令能够重新路由我们的流量到他们的网络,而他们的网络每秒处理T字节数据。他们能够吸收攻击,过滤恶意流量,把合法的流量引向我们做正常处理。

复杂的攻击

复杂的攻击也被设计为消耗资源,但通常是运行昂贵的操作,而不是大量占用网络连接。这些例子就像SSL协商攻击,请求web应用程序的计算密集部分,和”Slowloris”攻击。这些种类的攻击经常需要深入理解应用程序的架构,因此我们宁可自己处理它们。这允许我们在选择对策以及把它们对合法请求的影响最小化时,做出最好的决定。

首先,我们投入了巨大的工程师资源来加固计算基础设施的所有环节。比如调优Linux的网络缓冲区大小,配置载入平衡为合适的超时,在应用层做速率限制等等。在我们的基础设施建立恢复机制对于我们来说是一个核心工程,需要持续迭代和提高。

我们也购买、安装了一个软件和硬件平台,用来检测、减弱复杂DDoS攻击。这让我们执行详细的流量监控,便于能够应用流量过滤和访问控制规则来阻止攻击流量。拥有平台的操作控制使我们能够快速调整对付展开的攻击的对策。

我们的DDoS减弱伙伴也能够抵御这些种类的攻击,我们把他们作为最后一道防线。

发生了什么?

在21:25 UTC,我们开始调查关于连接到github.com的问题报告。21:29 UTC 我们在状态网站上建立了一个事件,让客户知道我们注意到了问题,并正在解决。

随着排查的展开,我们注意到我们的负载均衡层的一个明显的连接积压。当我们看到这点时,它通常和 我们后端应用程序的某些地方出现的性能问题 一致。

排查了一会儿,我们发现每秒有分散于成千上万个IP地址的、数千个HTTP请求一个精心构造的URL。这些请求被发送到非SSL HTTP端口,然后被重定向到HTTPS,这消耗了我们负载均衡和应用层的容量。不幸的是,我们没有阻止这些请求的预配置方案,它花了好一会儿时间才部署了一个修改来阻止它们。

在22:35 UTC,我们阻止了恶意请求,网站开始正常运行。

不管一切好像稳定的事实,我们在负载均衡里仍然看到大量的SSL连接。经过进一步排查,我们断定攻击正在用这个额外的vector努力消耗我们的SSL处理容量。我们能够快速使用我们的减弱平台,但是决策需要大量的调整才能把影响合法用户的伪造请求降为零。这导致了在23:05-23:30 UTC 大约多于25分钟的宕机。

在23:34 UTC,网站完全恢复了。这次攻击持续了一段时间,甚至在我们已经成功减弱它之后,但是没有再有客户受影响。

我们学到了什么?

我们在过去的几个月看到的大部分攻击一直是与带宽有关的容量耗尽,我们已经习惯了使用吞吐量来作为验证我们正被攻击的方式。这种攻击没有产生明显的更多带宽,但是它每秒产生了明显的更多的数据包。它不像是我们一直期望的攻击,我们也没有监控方法,它正是我们喜欢的快速监控方法。

一旦我们定位到了问题,它会花费比减弱它更多的时间。我们有能力在我们的负载均衡层和DDoS减弱平台来减弱这种性质的攻击。配置、测试、调整这些策略花费了相当的时间,这比必要的宕机时间还要长些。

下一步?

  1. 我们已经调整了监控,便于更好地探测并提醒我们标示出攻击的流量特征变化。另外,我们的机器人现在能够自动减弱我们在攻击中看到的特定流量特征。这些变化应该能够极大地减少我们未来响应一个更宽泛攻击的时间总量,也能够降低服务影响。

  2. 我们正在寻求能够以可控方式累计攻击的方法,便于我们能够在减弱工具和提高我们的响应时间到一个可承受范围上增加更多的信心,以此为基础来测试我们的策略。

  3. 我们正和一些第三方安全咨询公司讨论、分析我们的DDoS监测和减弱能力。以前能看得到,我们在减弱攻击上做得不错,但是我们乐于更加前瞻性地规划我们还没有遇到的攻击。

  4. Hubot能够通过我们的减弱合作伙伴路由流量,对于已知的攻击类型,应用模板来操作减弱平台。我们已经增加了像这种工具的新模板,便于它未来能够帮助我们快速恢复。

总结

这次攻击是痛苦的,即使我们能够成功地减弱其影响,它也花了我们太长的时间。我们知道你依靠GitHub和我们的整个公司是因为你对我们信任。就我个人而言我是这样看待问题的。我们将竭尽所能提高我们对问题的响应,确保你在需要我们的时候,你能够依赖可用的GitHub。

感谢你的支持!

原文地址:https://github.com/blog/1796-denial-of-service-attacks

译文:拒绝服务攻击 》| 腊八粥