在18年github受到一次超大规模ddos
这次重大的分布式拒绝服务（DDoS）攻击，是历史上规模最大的几次攻击之一。 到最后的处理办法是请了一个团队, 这个团队有着可以解决18年以前最大规模的ddos攻击规模的5倍来创立解决方案的, 即使这样也是非常困难的解决了.
如何造成的
前言
在18年有一个广泛使用的高性能内存对象缓存系统Memcached, 这个系统就像是现在广泛使用的redis.
不同的是, 在当时Memcached设计上可以通过UDP接口接收请求, 然后响应给请求者.
正文
这种攻击方式被称为放大攻击（Amplification Attack），特别是在这个案例中，它是一种反射放大攻击（Reflection Amplification Attack）。
攻击的基本过程如下：
- 攻击者首先寻找并利用了大量开放的、配置不当的Memcached服务器，这些服务器监听在UDP端口上。
- 攻击者向这些Memcached服务器发送大量小型UDP请求，请求中伪造（即“反射”）目标地址为GitHub的地址。
- 当Memcached服务器接收到这些请求后，它们会对每个请求作出响应。由于Memcached的设计允许它返回比请求本身大得多的数据，因此这些响应数据的体积会远远大于原始请求的体积，实现了所谓的“放大”效果。
- 这些大量的、体积庞大的响应数据因而被发送到了攻击者伪造的目标地址，即GitHub的服务器，导致GitHub的网络资源被大量占用，从而引发DDoS攻击。
UDP报文格式
这是部分ip数据报, 类型是udp.
这也是部分ip数据报, 类型是udp
推荐第一张图和第二张图片对应看, 可以发现这两个图片是一样的, 前三行就是伪首部, 中间两行是udp首部, 最后是数据段.
这是全部ip数据报.
第三张图片和前两张图片一起看, 可以看到出现一个之前没有提到的可变部分
这个部分就是第一张图的第3行, 第二张图的0,17(0x11),UDP长度. 其中0是填充. 17(0x11)是udp协议, 如果是tcp协议就是6(0x06).
这个知识很重要, 因为实战抓包的时候没有这个可变部分.
再提一嘴, udp数据报或tcp数据报是包含在ip数据报里面的.第三张图的数据部分就是图二中的IP数据报的数据部分, 里面有UDP首部和UDP数据部分.
这是抓到的udp数据包.
- 源IP地址：10.170.59.191（0x0AAA 0x3BBF）
- 目的IP地址：210.14.150.13（0xD20E 0x960D）
- 源端口：53539（0xD123）
- 目的端口：10050（0x2742）
- UDP长度：28（0x001C）
- 校验和：(0x285C)
可以发现在目的IP地址后, 紧接着就是源端口, 并没有可选部分.
使用UDP进行攻击
UDP的通信方式就是发送一次, 就可以收到一次消息, 与TCP需要握手不一样, 所以我们可以修改UDP的源地址和原端口, 这样我们发送给内存对象缓存系统Memcached时, 缓存系统就可以把我们要的数据, 发送给你修改后的源地址和原端口了. 就是这样github收到了如潮水般的攻击.数以万计的Memcached的回应发送过来.
拓展阅读, tcp也可以更改源地址, 但因为要三次握手, 所以攻击不了.
- 如果你在第一次请求服务器时修改了源地址, 那么你不会收到回来的数据, 通信不了
- 如果你在第二次请求服务器时修改了源地址, 那么你和第一次的源地址不一样了, 通信不了.
怎么解决的
限制或禁用Memcached的UDP支持, 和一些别的手段, 我就不太清楚了.
延伸
我也终于知道了, 为什么我买的节点是禁用UDP协议的了, 如果不禁用的话, 我也可以用这种方式来攻击任何可以接收UDP的电脑了, 只要改了源地址就可以了.