背景：
在近期的安全工作中，由于被DDOS搞的有点烦，计划上一批抗DDOS设备，所以需要学习梳理和总结DDOS攻防相关的内容。
DDoS是Distributed Denial of Service的简称，中文是分布式拒绝服务。
先说下什么是拒绝服务：DoS（Denial of Service），DoS攻击就是攻击者通过发送大量正常或不正常服务请求，来占用服务器资源，导致服务器资源被占满从而无法再为新的合法用户提供服务响应。尤其是当目标服务器资源性能不高的时候（例如CPU速度低、内存小或者网络带宽小等等），DoS攻击非常容易执行并且效果显著。
随着计算机与网络技术的发展，计算机的处理能力与网络带宽迅速增长。这使得DoS攻击的困难程度大大增加了，因为攻击目标对这些恶意服务请求的“消化能力”加强了很多。既然一个攻击者无法使目标“拒绝服务”，那么就需要多个攻击者同时发起分布式攻击了，这时DDoS攻击也就应运而生了。DDoS攻击是指攻击者控制僵尸网络中的大量僵尸主机（肉鸡）向攻击目标发送大流量数据，耗尽攻击目标的系统资源，导致其无法响应正常的服务请求。
一张图生动的描绘出DDOS的攻击过程：
DDoS攻击按TCP/IP协议分层划分有：网络层攻击、传输层攻击、应用层攻击。具体如下：
|
分层 |
DDoS攻击 |
|
网络层 |
IP地址扫描攻击、大部分特殊控制报文攻击、Teardrop攻击、Smurf攻击、IP分片报文攻击、ICMP Flood攻击 |
|
传输层 |
SYN Flood、SYN-ACK Flood、ACK Flood、FIN/RST Flood、TCP连接耗尽攻击、UDP Flood（包括各种反射攻击）、TCP/UDP分片报文攻击、DNS Flood、DNS缓存投毒、其余各种与TCP、UDP报文和端口相关的攻击 |
|
应用层 |
HTTP Flood、HTTP慢速攻击、HTTPS Flood、SSL DDoS攻击、SIP Flood |
目前全球范围内占比比较大的攻击类型一般是SYN Flood、UDP Flood（包括UDP类反射放大攻击）、HTTP Get Flood、DNS Query Flood
下面根据实例来逐个分析下每个ddos攻击类型原理：
说起DNS Flood，就要想起“519暴风断网”的严重事件。
“暴风”这件事儿的起因是两个游戏私服互相竞争，来回发动DDoS攻击。在达不到预期效果的情况下，干脆直接向对方的域名服务器下手了。
5月18日开始，DNS服务提供商DNSPod的6台服务器开始受到攻击。
18日晚20点33分，在史无前例的大流量攻击下，DNSPod的6台服务器开始陆续失效，大量网站开始间歇性无法访问。第一波攻击的流量在21点30分左右达到高峰，流量超过了10Gbps。要知道那可是2009年，奥运会才开过一年，北京的房价还是可以接受的，一个电信核心机房的带宽最多也只有几十G。
18日当晚，由于DNSPod耗尽了整个机房近乎三分之一的带宽资源，为了不影响机房其他用户，DNSPod服务器被运营商下线。
如果事情到此为止，其实也不会造成多大的影响。可是发动攻击的黑客忘了，运营商的管理员也忘了，DNSPod并不仅仅为这个被攻击的网游私服提供域名解析服务，还支持数十万其他的网站，这其中就包括大名鼎鼎的暴风影音。普通用户遇到上网失败，试几次就放弃了；暴风影音软件的设计，使它在请求失败后持续不断地重新发起请求。再考虑到暴风影音巨大的装机量，悲剧发生了。
19日晚，由于DNSPod网络服务被中断，致使其无法为包括baofeng.com在内的域名提供域名解析服务，诸多采用DNSPod服务的网站无法访问，DNS请求涌向了本地DNS缓存服务器，DNS缓存服务终于顶不住了，发生了大面积的堵塞。
19日晚21点左右，浙江电信DNS缓存服务开始瘫痪，之后的两个小时内天津、北京、上海、河北、山西、内蒙古、辽宁、吉林、江苏、黑龙江、浙江、安徽、湖北、广西、广东等地区的DNS缓存服务器也陆续瘫痪。全国各省市出现大面积断网。
事件中涉及的几个关键角色
DNSPod
DNSPod是国内最大的一家免费DNS解析服务提供商，暴风影音和前面恶性竞争的游戏私服都是DNSPod的客户。
运营商
由于中国特色的运营商市场，导致DNSPod这样的网络基础服务提供商无法独立承建数据中心，只能租用运营商IDC的机房和服务器资源。
暴风影音
影音软件起家，后来向媒体提供商转型。暴风影音软件中，有一项强制随机启动的名为stormliv.exe的进程，只要用户安装了暴风影音，该进程就会自动运行，并不断连接暴风影音网站，下载广告或升级。
私服与黑客
这个就很容易理解了，一个是为了一己私欲，策划这场攻击事件的背后指示者；一个是为了牟取暴利的攻击事件执行者。
从事件整个过程来看，一共有几个关键点：
1、游戏私服攻击竞争对手DNS服务，打蛇打七寸，间接攻击了整个DNSPod的业务。
2、运营商对DNSPod流量进行了阻断，粗暴的对流量进行了黑洞处理。
3、几亿安装了暴风影音客户端的PC充当“肉鸡”，导致运营商DNS缓存服务器无法提供服务，进而导致大面积断网。
如果把这次事件看成是“多米诺骨牌”效应，那被推倒的第一张“骨牌”是DNSPod服务器；第二张“骨牌”毫无疑问就是暴风影音充当“肉鸡”导致服务耗尽的运营商DNS缓存服务器；而第三张“骨牌”就是全国范围瘫痪的网络了。如果想深入理解这次互联网灾难，就要了解下DNS DDOS攻击的分类和原理。
(author https://www.cnblogs.com/Shepherdzhao/)
要想弄明白DNS攻击的原理，就要先明白DNS协议的基础，我们还是从DNS协议本身讲起。DNS由RFC1034、1035协议定义规范，属于应用层协议。在前一篇中，我们也说了，DNS域名解析是互联网上非常重要的一项服务，我们每天上网都伴随着大量的DNS服务来支撑。在Internet上，用户更容易记住的是域名，但是网络中的计算机互相进行访问是通过IP地址，DNS最常用的是给用户提供域名解析服务，将用户的域名解析成网络上能够访问的IP地址。
DNS报文格式：
下面结合DNS查询报文和响应报文的抓包信息来看理解一下报文格式中的几个关键字段，先看一下DNS查询报文的抓包：
DNS报文由12字节长的首部和4个长度可变的字段组成。标识字段由客户端程序设置并由服务器返回结果，客户端通过标识来确定响应与查询是否匹配。报文中涉及的字段很多，我们重点解释几个和本节相关的字段。
- UDP：表示DNS查询基于UDP协议传输数据。DNS服务器支持TCP和UDP两种协议的查询方式。
- Destination port：目的端口默认是53。
- QR：0表示查询报文；1表示回应报文。
- TC：表示“可截断的”。如果使用UDP时，当应答报文超过512字节时，只返回前512个字节。
通常情况下，DNS查询都是使用UDP查询，UDP提供无连接服务器，查询速度快，可降低服务器的负载。当客户端发送DNS请求，并且返回响应中TC位设置为1时，就意味着响应的长度超过512个字节，而仅返回前512个字节。这种情况下，客户端通常采用TCP重发原来的查询请求，并允许返回的响应报文超过512个字节。直白点说，就是UDP报文的最大长度为512字节，而TCP则允许报文长度超过512字节。当DNS查询超过512字节时，协议的TC标志位会置1，这时则使用TCP发送。
- Queries：表示DNS请求的域名和类型。
再来看一下DNS回应报文的抓包：
- 在回应报文中，比查询报文多了后三个字段：回答字段、授权字段和附加信息字段。其中回答字段是放置的域名对应的IP地址等信息。
- Name：DNS查询中的请求域名。
- Type：每一个查询都有一个查询类型，每一个响应也都有一个类型。这个类型大约有20多种，但是很多种类型现在已经过时了。最常用的查询类型是A类型，表示期望获得查询域名的IP地址。查询类型也可以是CNAME，这个在后面的详细介绍。
- TTL：生存时间，表示客户端保留该解析资源记录的时间。
DNS request flood攻击原理其实很简单，就是黑客控制僵尸网络向DNS服务器发送大量的不存在域名的解析请求，最终导致服务器因大量DNS请求而超载，无法继续响应正常用户的DNS请求，从而达到攻击的目的。
在DNS request flood攻击过程中，攻击的目标可能是DNS授权服务器，也可能是DNS缓存服务器。黑客伪造的客户端IP地址可能是虚假源IP地址，也可能是现网真实存在的IP地址。如果攻击的是DNS授权服务器，大量不存在的域名解析请求会导致服务器应接不暇，最终耗尽服务器性能；如果攻击的是缓存服务器，同时会导致缓存服务器不停的向授权服务器发送这些不存在域名的解析请求，一收一发更加重服务器的负担，直到最终导致服务器瘫痪。
对于缓存服务器和授权服务器，虽然都是DNS request flood攻击，但由于请求的客户端类型不同，所以防御的手段也不同。对于缓存服务器，正常向它发送DNS请求的是上网的终端用户，所以防御过程中，需要判定的是这个DNS请求是否由真实、正常的浏览器客户端发出；而对于授权服务器，向它发送DNS请求的可能就是缓存服务器了。所以对于不同的对象，认证方式当然也就不同了。
对于DNS request flood攻击的防御，目前典型的抗DDOS设备比如华为的Anti-DDoS系统一般是采用被动防御的模式。
被动防御
被动模式，就是“以不变应万变”，利用DNS协议的重传机制，不对DNS查询报文进行反弹，而是直接不处置，直接丢弃，然后看客户端是否重传，
1、抗DDOS设备在第一次收到DNS请求后，就会记录DNS请求的域名、源IP等基本信息，并HASH成一个值，记录到系统一张表里。
2、后续一定时间戳内，如果再收到这个HASH值相同的DNS请求，就认定为重传包，放行。时间戳会随着收到的每一个相同HASH值的DNS请求包而不断的刷新。
抓包看看：
1、第一次DNS请求。这个DNS查询报文会被丢弃，并且不回应任何报文。
2、第二次DNS请求。客户端一段时间内没有收到DNS回应报文，重新发送DNS请求。
被动防御模式是一种比较通用的防御手段，适用于攻击源不断变换的DNS请求攻击。对客户端的类型没有限制，无论缓存服务器还是授权服务器都适用。
DNS查询过程通常都是基于UDP协议的，UDP协议是无连接状态的。所以这一弱点很容易被黑客所利用，DNS服务器收到DNS reply报文时，不管自己有没有发出去过解析请求，都会对这些DNS reply报文进行处理。DNS reply flood就是黑客发送大量的DNS reply报文到DNS缓存服务器，导致缓存服务器因为处理这些DNS reply报文而资源耗尽，影响正常业务。
DNS reply flood大多都是虚假源攻击，黑客控制僵尸主机发出的DNS reply报文的源IP地址通常都是伪造的，是不存在的。所以在防御的时候，就可以从回应源IP地址的真假性入手，判定这个源IP是否是真实源。
针对这种攻击行为，抗DDOS设备一般可使用源认证方式进行防御。源认证的方法就是构造一个DNS request报文，看客户端是否能正常回应。此处依然是用华为的anti-ddos设备举例
1、Anti-DDoS系统部署在防护目标前，并对到达防护目标的DNS reply报文进行统计。当到达防护目标的DNS reply报文超过告警阈值时，Anti-DDoS系统启动防御。
2、Anti-DDoS系统收到某个源IP地址发来的DNS reply报文后，会重新构造一个新的DNS request报文，然后记录构造查询报文的Query ID和源端口号。
3、如果是虚假源，则不会对这个DNS request报文进行回应，认证不通过。
4、如果是真实DNS授权服务器，则会重新回应DNS reply报文。
5、Anti-DDoS系统收到DNS reply报文后，会与之前记录的Query ID和源端口号进行匹配。如果完全一致，则判定此DNS reply报文就是反弹DNS request报文的回应，源认证成功，加入白名单。
6、后续这个源再发送的DNS reply报文，直接通过，直到白名单老化。
近几年，还有一种升级版的DNS reply flood攻击，因为杀伤力巨大，而备受安全界的关注，那就是DNS反射攻击。
DNS反射攻击
DNS反射攻击是DNS reply flood的一种变异，是一种更高级的DNS reply flood。
DNS服务器是互联网最基础的设施之一，网络中有很多开放的免费DNS服务器。DNS反射攻击正是利用这些开放的DNS服务器制造的攻击。这种DNS反射攻击通常比普通的DNS reply flood攻击性更强，追踪溯源困难，更善于伪装。
从图中我们可以看到，黑客将自己的源IP地址伪造成被攻击目标的IP地址，然后向一系列网络中开放的DNS服务器发送大量的查询请求。通过伪造DNS请求报文的源IP地址，控制DNS回应报文的流向，这些DNS回应报文就会都被引导到被攻击目标，导致被攻击目标的网络拥塞，拒绝服务。而开放式的DNS服务器在全球有超过几千万台，这些服务器接入带宽往往都比较高，而且，DNS reply报文大小通常也是DNS request报文的几倍甚至几十倍，还可达到放大攻击的效果。对于控制成千上万台僵尸主机的黑客来说，制造几G乃至数十G的DNS攻击流量并不太困难。
DNS反射攻击和前面介绍的传统DNS reply flood有两点本质的不同：
1、传统DNS reply flood一般攻击目标是DNS缓存服务器；而DNS反射攻击一般攻击目标是客户端。
2、传统DNS reply flood大多是虚假源攻击，而DNS反射攻击中，DNS请求是真实的，所以DNS回应报文也都是真实的，是由网络中真实的DNS服务器发出的，属于真实源攻击。这种情况下，再使用前面刚讲过的源认证方式，对于DNS反射攻击就不适用了。
目前对于DNS反射攻击的应对方法一般是会话检查，会话表五元组信息包含：源IP地址、目的IP地址、源端口、目的端口和协议。当DNS request报文经过抗DDOS设备时，设备会创建一张会话表，记录DNS请求报文的这五元组信息。当再收到DNS reply报文时，就会查会话表：
- 如果匹配会话表，就判定是真实的DNS reply报文，允许通过。
- 如果没有匹配会话表，则判定这个DNS reply报文为攻击报文，禁止通过。
DNS缓存投毒，是一种典型的DNS攻击。
前面也讲过，缓存服务器并不知道域名和IP地址的映射关系，一旦从授权服务器获取了映射关系后，会存储在内存中一段时间。直到记录老化。老化时间由DNS reply报文中的TTL决定。在这个有效期内如果再有客户端请求这个相同域名的解析，缓存服务器就会直接用缓存中的IP地址进行回应。老化以后，如果有客户端再次请求这个域名时，缓存服务器就会重新向授权服务器请求。
缓存投毒攻击就是黑客伪造了恶意的DNS reply报文，导致缓存服务器无意中将恶意的域名和IP地址映射关系存储到自己的缓存中。当客户端再通过缓存服务器请求这个域名解析时，就会被指向恶意主机。
1. 黑客向DNS缓存服务器发送一个不存在的子域名（gh1.ddos.com），请求解析。
2. 缓存服务器查找本地缓存项查不到，就会向授权服务器发起查询请求。
3. 在授权服务器回应这个请求前，黑客就会伪造大量的DNS reply报文发向缓存服务器。
为了达到攻击的目的，黑客伪造的DNS reply报文的源IP地址必须是授权服务器的源IP地址；目的端口也必须是缓存服务器的源端口；同时DNS reply报文的Query ID和DNS request报文的Query ID也要一致。
源IP地址和目的端口都很好伪造，但是Query ID伪造成功是有一定难度的。所以黑客伪造大量DNS reply报文时，会不断变换Query ID字段。可能就会有一个Query ID字段命中DNS request的Query ID。一旦先于授权服务器发送给缓存服务器，缓存服务器就会将黑客发送的伪解析IP地址作为解析地址，保存到本地的缓存表中。
4. 后续当授权服务器再将真正的回应报文发送到缓存服务器时，缓存服务器也不会接收，直接丢弃。
在DNS缓存服务器中，如果仅仅gh1.ddos.com的解析地址是假的，这个其实也没有多大影响。毕竟黑客利用投毒的这个子域名gh1.ddos.com通常都是不存在的，正常客户端也不会请求这个不存在的子域名。
但是我们再仔细看一下下面这个DNS reply报文就会发现，蓝框内是对子域名gh1.ddos.com的解析地址，而红框内则是主域名ddos.com所在的DNS授权服务器和IP地址的对应关系。授权服务器在回答缓存服务器请求时，也会将这部分内容一起发送过去。而缓存服务器不仅仅存储子域名的解析地址，还会将主域名的解析地址一并更新到自己的缓存列表中。
这样后续再有客户端请求这个主域名时，也会一并被指向虚假的IP地址。
对于缓存投毒，Anti-DDoS系统采用会话检查模式进行防御。在防御过程中，检查DNS reply报文的会话五元组信息（源IP地址、目的IP地址、源端口号、目的端口号、协议），Query ID和域名是否和缓存服务器发出的DNS request报文一致。
1. 当缓存服务器向授权服务器发出域名查询请求时，Anti-DDoS系统记录会话信息及请求报文中的Query ID和域名。
2. 当Anti-DDoS系统收到回应报文时，检查会话五元组、回应报文中的Query ID和域名与请求报文中的Query ID和域名是否匹配。
a. 如果命中会话五元组，并且Query ID和域名与记录的请求报文中的Query ID和域名匹配，则放行该报文。
b. 如果没有命中会话，则丢弃该报文。
c. 如果命中会话，但是域名或Query ID与请求报文不匹配，则丢弃该报文，同时要删除该会话，以免后续投毒报文完成投毒。