GitHub 遭遇史上最大规模 DDoS 攻击
点击上方“CSDN”，选择关注
关键时刻，第一时间送达！
据外媒 Wired 报道，美国东部时间本周三下午 12:15，知名代码托管网站 GitHub 遭遇了史上最大规模的 DDoS 网络攻击，每秒 1.35 TB 的流量瞬间冲击了这一开发者平台。
来自 DDoS 攻击的实时流量
尽管 GitHub 曾试图反抗，但最终还是借助 DDoS 防御服务提供商 Akamai Prolexic 提供的帮助才得以艰难度过。Prolexic 接管了 GitHub 所有的信息流，通过清除和阻止恶意数据包迫使袭击者停止了攻击。Akamai 网络安全副总裁 Josh Shau 表示，“我们是基于互联网所见过的最大规模攻击的五倍来建模的，以前从没有遇到过这么大的流量”。
作为全球最大的社交编程及代码托管网站，GitHub 一直很受攻击者的欢迎。2013 年 1 月 15 日，来自 12306 抢票插件用户的大量访问导致 GitHub 访问大幅放缓。2015 年 3 月 26 日，攻击者利用劫持百度 JS 文件、跨域 <img> 攻击、DDoS 攻击、TCP SYN 攻击等方式持续狂轰 GitHub 达六天之久。然而本周三的猛攻，却是 GitHub 有史以来面临的最严重的 DDoS 攻击事件。
据悉，本次攻击并非依赖于传统的僵尸网络，而是使用了 Memcached 服务器。该服务器的设计初衷是提升内部网络的访问速度，而且是不应该被暴露在互联网中的，但是根据 Akamai 的调查，至少有超过 5 万台此类服务器连接到了服务器上，因此非常容易受到攻击。犯罪分子可利用 Memcache 服务器通过非常少的计算资源发动超大规模的 DDoS 攻击，该漏洞是由于 Memcache 开发人员对 UDP 协议支持方式不安全所导致的，黑客能通过它轻易实现“反射型 DDoS 攻击”。
那么什么是反射型 DDoS 攻击？犯罪分子是如何利用 UDP 协议进行攻击的？我们应该采取什么方式去减少它所带来的危害？360CERT 昨日发布的 Memcrashed 预警公告进行了解答。
事件背景
黑客利用 Memcache 协议，会发送大量带有被害者 IP 地址的 UDP 数据包给放大器主机，然后放大器主机对伪造的 IP 地址源做出大量回应，形成分布式拒绝服务攻击，从而形成 DDoS 反射。
攻击强度
根据 360netlab DDoSMon 监测结果显示， 近期内 Memcrashed 事件攻击情况不断上升，且由于 Memcache 作为放大器的利用，近几天攻击事件开始陡增，影响极为广泛。
漏洞细节
关于 DDoS 放大：
作为攻击者，需要伪造 IP，发送海量量伪造来源的请求。未采取 BCP38 的机房（firewallrules and uRPF）；
作为反射服务器，需要满足 2 个条件。第一，上面运行着容易放大的 UDP 协议，即使用设计不当的 UDP 服务，能够满足特定条件下，响应包远远大于请求包。第二，该协议或服务在互联网上有一定的使用量，如 DNS、NTP 等基础服务；
受害者一般是金融、游戏、政治等目标，或出于破坏、炫技等目的。
关于 Memcrashed：
由于 Memcache 同时监听 TCP 和 UDP，天然满足反射 DDoS 条件；
Memcache 作为企业应用组建，其业务特性保证了具有较高上传带宽；
Memcache 不需要认证即可进行交互；
很多用户在编译安装时，将服务错误监听在 0.0.0.0，且未进行 iptables 规则配置或云安全租户配置。
攻击流程：
扫描全网端口服务；
进行指纹识别，获取未认证的 Memcache；
过滤所有可以反射的 UDP Memcache；
插入数据状态进行反射。
缓解措施
对于 Memcache 使用者：
Memcache 的用户建议将服务放置于可信域内，有外网时不要监听 0.0.0.0，有特殊需求可以设置 ACL 或者添加安全组；
为预防机器器扫描和 SSRF 等攻击，修改 Memcache 默认监听端口；
升级到最新版本的 Memcache，并且使用 SASL 设置密码来进行权限控制。
对于网络层防御：
多个 ISP 已经对 UDP11211 进行限速；
打击攻击源，互联网服务提供商应当禁止在网络上执行 IP 欺骗；
ISP 应允许用户使用 BGP flowspec 限制入站 UDP11211 的流量，以减轻大型 DRDoS 攻击时的拥堵。
参考链接：
https://www.wired.com/story/github-ddos-memcached/
https://cert.360.cn/warning
本文关于 Memcrashed 的技术解读来源于 360CERT。