深刻浅出DDoS***

敌情篇 ——DDoS***原理

DDoS***基础

DDoS（Distributed Denial of Service，分布式拒绝服务）***的主要目的是让指定目标没法提供正常服务，甚至从互联网上消失，是目前最强大、最难防护的***之一。

按照发起的方式，DDoS能够简单分为三类。

第一类以力取胜，海量数据包从互联网的各个角落蜂拥而来，堵塞IDC入口，让各类强大的硬件防护系统、快速高效的应急流程无用武之地。这种类型的***典型表明是ICMP Flood和UDP Flood，如今已不常见。

第二类以巧取胜，灵动而难以察觉，每隔几分钟发一个包甚至只须要一个包，就可让豪华配置的服务器再也不响应。这类***主要是利用协议或者软件的漏洞发起，例如Slowloris***、Hash冲突***等，须要特定环境机缘巧合下才能出现。

第三类是上述两种的混合，轻灵浑厚兼而有之，既利用了协议、系统的缺陷，又具有了海量的流量，例如SYN Flood***、DNS Query Flood***，是当前的主流***方式。

本文将一一描述这些最多见、最具表明性***方式，并介绍它们的防护方案。

SYN Flood

SYN Flood是互联网上最经典的DDoS***方式之一，最先出现于1999年左右，雅虎是当时最著名的受害者。SYN Flood***利用了TCP三次握手的缺陷，可以以较小代价使目标服务器没法响应，且难以追查。

标准的TCP三次握手过程以下：

• 客户端发送一个包含SYN标志的TCP报文，SYN即同步（Synchronize），同步报文会指明客户端使用的端口以及TCP链接的初始序号；

• 服务器在收到客户端的SYN报文后，将返回一个SYN+ACK（即确认Acknowledgement）的报文，表示客户端的请求被接受，同时TCP初始序号自动加1；

• 客户端也返回一个确认报文ACK给服务器端，一样TCP序列号被加1。

  
  

经 过这三步，TCP链接就创建完成。TCP协议为了实现可靠传输，在三次握手的过程当中设置了一些异常处理机制。第三步中若是服务器没有收到客户端的最终 ACK确认报文，会一直处于SYN_RECV状态，将客户端IP加入等待列表，并重发第二步的SYN+ACK报文。重发通常进行3-5次，大约间隔30秒 左右轮询一次等待列表重试全部客户端。另外一方面，服务器在本身发出了SYN+ACK报文后，会预分配资源为即将创建的TCP链接储存信息作准备，这个资源 在等待重试期间一直保留。更为重要的是，服务器资源有限，能够维护的SYN_RECV状态超过极限后就再也不接受新的SYN报文，也就是拒绝新的TCP链接 创建。

SYN Flood正是利用了上文中TCP协议的设定，达到***的目的。***者假装大量的IP地址给服务器发送SYN报文，因为伪造的IP地址几乎不可能存在，也 就几乎没有设备会给服务器返回任何应答了。所以，服务器将会维持一个庞大的等待列表，不停地重试发送SYN+ACK报文，同时占用着大量的资源没法释放。 更为关键的是，被***服务器的SYN_RECV队列被恶意的数据包占满，再也不接受新的SYN请求，合法用户没法完成三次握手创建起TCP链接。也就是说， 这个服务器被SYN Flood拒绝服务了。

对SYN Flood有兴趣的能够看看http://www.icylife.net/yunshu/show.php?id=367，这是我2006年写的代码，后来作过几回修改，修改了Bug，并下降了***性，纯作测试使用。

DNS Query Flood

做 为互联网最基础、最核心的服务，DNS天然也是DDoS***的重要目标之一。打垮DNS服务可以间接打垮一家公司的所有业务，或者打垮一个地区的网络服 务。前些时候风头正盛的***组织anonymous也曾经宣布要***全球互联网的13台根DNS服务器，不过最终没有得手。

UDP ***是最容易发起海量流量的***手段，并且源IP随机伪造难以追查。但过滤比较容易，由于大多数IP并不提供UDP服务，直接丢弃UDP流量便可。因此现 在纯粹的UDP流量***比较少见了，取而代之的是UDP协议承载的DNS Query Flood***。简单地说，越上层协议上发动的DDoS***越难以防护，由于协议越上层，与业务关联越大，防护系统面临的状况越复杂。

DNS Query Flood就是***者操纵大量傀儡机器，对目标发起海量的域名查询请求。为了防止基于ACL的过滤，必须提升数据包的随机性。经常使用的作法是UDP层随机伪 造源IP地址、随机伪造源端口等参数。在DNS协议层，随机伪造查询ID以及待解析域名。随机伪造待解析域名除了防止过滤外，还能够下降命中DNS缓存的 可能性，尽量多地消耗DNS服务器的CPU资源。

关于DNS Query Flood的代码，我在2011年7月为了测试服务器性能曾经写过一份代码，连接是http://www.icylife.net/yunshu/show.php?id=832。一样的，这份代码人为下降了***性，只作测试用途。

HTTP Flood

上 文描述的SYN Flood、DNS Query Flood在现阶段已经能作到有效防护了，真正令各大厂商以及互联网企业头疼的是HTTP Flood***。HTTP Flood是针对Web服务在第七层协议发起的***。它的巨大危害性主要表如今三个方面：发起方便、过滤困难、影响深远。

SYN Flood和DNS Query Flood都须要***者以root权限控制大批量的傀儡机。收集大量root权限的傀儡机很花费时间和精力，并且在***过程当中傀儡机会因为流量异常被管理 员发现，***者的资源快速损耗而补充缓慢，致使***强度明显下降并且不可长期持续。HTTP Flood***则不一样，***者并不须要控制大批的傀儡机，取而代之的是经过端口扫描程序在互联网上寻找匿名的HTTP代理或者SOCKS代理，***者经过 匿名代理对***目标发起HTTP请求。匿名代理是一种比较丰富的资源，花几天时间获取代理并非难事，所以***容易发起并且能够长期高强度的持续。

另外一方面，HTTP Flood***在HTTP层发起，极力模仿正经常使用户的网页请求行为，与网站业务紧密相关，安全厂商很难提供一套通用的且不影响用户体验的方案。在一个地方工做得很好的规则，换一个场景可能带来大量的误杀。

最后，HTTP Flood***会引发严重的连锁反应，不只仅是直接致使被***的Web前端响应缓慢，还间接***到后端的Java等业务层逻辑以及更后端的数据库服务，增大它们的压力，甚至对日志存储服务器都带来影响。

有 意思的是，HTTP Flood还有个很有历史渊源的昵称叫作CC***。CC是Challenge Collapsar的缩写，而Collapsar是国内一家著名安全公司的DDoS防护设备。从目前的状况来看，不只仅是Collapsar，全部的硬件 防护设备都还在被挑战着，风险并未解除。

慢速链接***

提起***，第一反应就是海量的流量、海量的报文。但有一种***却反其道而行之，以慢著称，以致于有些***目标被打死了都不知道是怎么死的，这就是慢速链接***，最具表明性的是rsnake发明的Slowloris。

HTTP 协议规定，HTTP Request以\r\n\r\n结尾表示客户端发送结束，服务端开始处理。那么，若是永远不发送\r\n\r\n会如何？Slowloris就是利用这 一点来作DDoS***的。***者在HTTP请求头中将Connection设置为Keep-Alive，要求Web Server保持TCP链接不要断开，随后缓慢地每隔几分钟发送一个key-value格式的数据到服务端，如a:b\r\n，致使服务端认为HTTP头 部没有接收完成而一直等待。若是***者使用多线程或者傀儡机来作一样的操做，服务器的Web容器很快就被***者占满了TCP链接而再也不接受新的请求。

很 快的，Slowloris开始出现各类变种。好比POST方法向Web Server提交数据、填充一大大Content-Length但缓慢的一个字节一个字节的POST真正数据内容等等。关于Slowloris攻 击，rsnake也给出了一个测试代码，参见http://ha.ckers.org/slowloris/slowloris.pl。

DDoS***进阶

混合***

以上介绍了几种基础的***手段，其中任意一种均可以用来***网络，甚至击垮阿里、百度、腾讯这种巨型网站。但这些并非所有，不一样层次的***者可以发起彻底不一样的DDoS***，运用之妙，存乎一心。

高 级***者历来不会使用单一的手段进行***，而是根据目标环境灵活组合。普通的SYN Flood容易被流量清洗设备经过反向探测、SYN Cookie等技术手段过滤掉，但若是在SYN Flood中混入SYN+ACK数据包，使每个伪造的SYN数据包都有一个与之对应的伪造的客户端确认报文，这里的对应是指源IP地址、源端口、目的 IP、目的端口、TCP窗口大小、TTL等都符合同一个主机同一个TCP Flow的特征，流量清洗设备的反向探测和SYN Cookie性能压力将会显著增大。其实SYN数据报文配合其余各类标志位，都有特殊的***效果，这里不一一介绍。对DNS Query Flood而言，也有独特的技巧。

首 先，DNS能够分为普通DNS和受权域DNS，***普通DNS，IP地址须要随机伪造，而且指明服务器要求作递归解析；但***受权域DNS，伪造的源IP 地址则不该该是纯随机的，而应该是事先收集的全球各地ISP的DNS地址，这样才能达到最大***效果，使流量清洗设备处于添加IP黑名单仍是不添加IP黑 名单的尴尬处境。添加会致使大量误杀，不添加黑名单则每一个报文都须要反向探测从而加大性能压力。

另 一方面，前面提到，为了加大清洗设备的压力不命中缓存而须要随机化请求的域名，但须要注意的是，待解析域名必须在伪造中带有必定的规律性，好比说只伪造域 名的某一部分而固化一部分，用来突破清洗设备设置的白名单。道理很简单，腾讯的服务器能够只解析腾讯的域名，彻底随机的域名可能会直接被丢弃，须要固化。 但若是彻底固定，也很容易直接被丢弃，所以又须要伪造一部分。

其次，对DNS的***不该该只着重于UDP端口，根据DNS协议，TCP端口也是标准服务。在***时，能够UDP和TCP***同时进行。

HTTP Flood的着重点，在于突破前端的cache，经过HTTP头中的字段设置直接到达Web Server自己。另外，HTTP Flood对目标的选取也很是关键，通常的***者会选择搜索之类须要作大量数据查询的页面做为***目标，这是很是正确的，能够消耗服务器尽量多的资源。 但这种***容易被清洗设备经过人机识别的方式识别出来，那么如何解决这个问题？很简单，尽可能选择正经常使用户也经过APP访问的页面，通常来讲就是各类Web API。正经常使用户和恶意流量都是来源于APP，人机差异很小，基本融为一体难以区分。

之 类的慢速***，是经过巧妙的手段占住链接不释放达到***的目的，但这也是双刃剑，每个TCP链接既存在于服务端也存在于自身，自身也须要消耗资源维持 TCP状态，所以链接不能保持太多。若是能够解决这一点，***性会获得极大加强，也就是说Slowloris能够经过stateless的方式发动***， 在客户端经过嗅探捕获TCP的序列号和确认维护TCP链接，系统内核无需关注TCP的各类状态变迁，一台笔记本便可产生多达65535个TCP链接。

前 面描述的，都是技术层面的***加强。在人的方面，还能够有一些别的手段。若是SYN Flood发出大量数据包正面强攻，再辅之以Slowloris慢速链接，多少人可以发现其中的秘密？即便服务器宕机了也许还只发现了SYN***想去增强 TCP层清洗而忽视了应用层的行为。种种***均可以互相配合，达到最大的效果。***时间的选择，也是一大关键，好比说选择维护人员吃午餐时、维护人员下班 堵在路上或者在地铁里无线上网卡都没有信号时、目标企业在举行大规模活动流量飙升时等。

这里描述的只是纯粹的***行为，所以不提供代码，也不作深刻介绍。

来自P2P网络的***

前面的***方式，多多少少都须要一些傀儡机，即便是HTTP Flood也须要搜索大量的匿名代理。若是有一种***，只须要发出一些指令，就有机器自动上来执行，才是完美的方案。这种***已经出现了，那就是来自P2P网络的***。

大 家都知道，互联网上的P2P用户和流量都是一个极为庞大的数字。若是他们都去一个指定的地方下载数据，使成千上万的真实IP地址链接过来，没有哪一个设备能 够支撑住。拿BT下载来讲，伪造一些热门视频的种子，发布到搜索引擎，就足以骗到许多用户和流量了，但这只是基础***。

应对篇 ——DDoS防护方案

防护基础

***流量到底多大

谈到DDoS防护，首先就是要知道到底遭受了多大的***。这个问题看似简单，实际上却有不少鲜为人知的细节在里面。

以SYN Flood为例，为了提升发送效率在服务端产生更多的SYN等待队列，***程序在填充包头时，IP首部和TCP首部都不填充可选的字段，所以IP首部长度刚好是20字节，TCP首部也是20字节，共40字节。

对 于以太网来讲，最小的包长度数据段必须达到46字节，而***报文只有40字节，所以，网卡在发送时，会作一些处理，在TCP首部的末尾，填充6个0来知足 最小包的长度要求。这个时候，整个数据包的长度为14字节的以太网头，20字节的IP头，20字节的TCP头，再加上由于最小包长度要求而填充的6个字节 的0，一共是60字节。

但这尚未结束。以太网在传输数据时，还有CRC检验的要求。网卡会在发送数据以前对数据包进行CRC检验，将4字节的CRC值附加到包头的最后面。这个时候，数据包长度已再也不是40字节，而是变成64字节了，这就是常说的SYN小包***，数据包结构以下：

|14字节以太网头部|20字节IP头部|20字节TCP|6字节填充|4字节检验|
|目的MAC|源MAC|协议类型| IP头 |TCP头|以太网填充 | CRC检验 |

到64字节时，SYN数据包已经填充完成，准备开始传输了。***数据包很小，远远不够最大传输单元（MTU）的1500字节，所以不会被分片。那么这些数据包就像生产流水线上的罐头同样，一个包连着一个包紧密地挤在一块儿传输吗？事实上不是这样的。

以 太网在传输时，还有前导码（preamble）和帧间距（inter-frame gap）。其中前导码占8字节（byte），即64比特位。前导码前面的7字节都是10101010，1和0间隔而成。但第八个字节就变成了 10101011，当主机监测到连续的两个1时，就知道后面开始是数据了。在网络传输时，数据的结构以下：

|8字节前导码|6字节目的MAC地址|6字节源MAC地址|2字节上层协议类型|20字节IP头|20字节TCP头|6字节以太网填充|4字节CRC检验|12字节帧间距|

也就是说，一个原本只有40字节的SYN包，在网络上传输时占的带宽，实际上是84字节。

有 了上面的基础，如今能够开始计算***流量和网络设备的线速问题了。当只填充IP头和TCP头的最小SYN包跑在以太网络上时，100Mbit的网络，能支 持的最大PPS（Packet Per Second）是100×106 / (8 * (64+8+12)) = 148809，1000Mbit的网络，能支持的最大PPS是1488090。

SYN Flood防护

前文描述过，SYN Flood***大量消耗服务器的CPU、内存资源，并占满SYN等待队列。相应的，咱们修改内核参数便可有效缓解。主要参数以下：

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_synack_retries = 2

分别为启用SYN Cookie、设置SYN最大队列长度以及设置SYN+ACK最大重试次数。

SYN Cookie的做用是缓解服务器资源压力。启用以前，服务器在接到SYN数据包后，当即分配存储空间，并随机化一个数字做为SYN号发送SYN+ACK数 据包。而后保存链接的状态信息等待客户端确认。启用SYN Cookie以后，服务器再也不分配存储空间，并且经过基于时间种子的随机数算法设置一个SYN号，替代彻底随机的SYN号。发送完SYN+ACK确认报文 以后，清空资源不保存任何状态信息。直到服务器接到客户端的最终ACK包，经过Cookie检验算法鉴定是否与发出去的SYN+ACK报文序列号匹配，匹 配则经过完成握手，失败则丢弃。固然，前文的高级***中有SYN混合ACK的***方法，则是对此种防护方法的反击，其中优劣由双方的硬件配置决定

tcp_max_syn_backlog 则是使用服务器的内存资源，换取更大的等待队列长度，让***数据包不至于占满全部链接而致使正经常使用户没法完成握手。 net.ipv4.tcp_synack_retries是下降服务器SYN+ACK报文重试次数，尽快释放等待资源。这三种措施与***的三种危害一一对 应，完彻底全地对症下药。但这些措施也是双刃剑，可能消耗服务器更多的内存资源，甚至影响正经常使用户创建TCP链接，须要评估服务器硬件资源和***大小谨慎 设置。

除 了定制TCP/IP协议栈以外，还有一种常见作法是TCP首包丢弃方案，利用TCP协议的重传机制识别正经常使用户和***报文。当防护设备接到一个IP地址的 SYN报文后，简单比对该IP是否存在于白名单中，存在则转发到后端。如不存在于白名单中，检查是不是该IP在必定时间段内的首次SYN报文，不是则检查 是否重传报文，是重传则转发并加入白名单，不是则丢弃并加入黑名单。是首次SYN报文则丢弃并等待一段时间以试图接受该IP的SYN重传报文，等待超时则 断定为***报文加入黑名单。

首 包丢弃方案对用户体验会略有影响，由于丢弃首包重传会增大业务的响应时间，有鉴于此发展出了一种更优的TCP Proxy方案。全部的SYN数据报文由清洗设备接受，按照SYN Cookie方案处理。和设备成功创建了TCP三次握手的IP地址被断定为合法用户加入白名单，由设备假装真实客户端IP地址再与真实服务器完成三次握 手，随后转发数据。而指定时间内没有和设备完成三次握手的IP地址，被断定为恶意IP地址屏蔽必定时间。除了SYN Cookie结合TCP Proxy外，清洗设备还具有多种畸形TCP标志位数据包探测的能力，经过对SYN报文返回非预期应答测试客户端反应的方式来鉴别正常访问和恶意行为。

清洗设备的硬件具备特殊的网络处理器芯片和特别优化的操做系统、TCP/IP协议栈，能够处理很是巨大的流量和SYN队列。

HTTP Flood防护

HTTP Flood***防护主要经过缓存的方式进行，尽可能由设备的缓存直接返回结果来保护后端业务。大型的互联网企业，会有庞大的CDN节点缓存内容。

当 高级***者穿透缓存时，清洗设备会截获HTTP请求作特殊处理。最简单的方法就是对源IP的HTTP请求频率作统计，高于必定频率的IP地址加入黑名单。 这种方法过于简单，容易带来误杀，而且没法屏蔽来自代理服务器的***，所以逐渐废止，取而代之的是JavaScript跳转人机识别方案。

HTTP Flood是由程序模拟HTTP请求，通常来讲不会解析服务端返回数据，更不会解析JS之类代码。所以当清洗设备截获到HTTP请求时，返回一段特殊JavaScript代码，正经常使用户的浏览器会处理并正常跳转不影响使用，而***程序会***到空处。

DNS Flood防护

DNS***防护也有相似HTTP的防护手段，第一方案是缓存。其次是重发，能够是直接丢弃DNS报文致使UDP层面的请求重发，能够是返回特殊响应强制要求客户端使用TCP协议重发DNS查询请求。

特殊的，对于受权域DNS的保护，设备会在业务正常时期提取收到的DNS域名列表和ISP DNS IP列表备用，在***时，非此列表的请求一概丢弃，大幅下降性能压力。对于域名，实行一样的域名白名单机制，非白名单中的域名解析请求，作丢弃处理。

慢速链接***防护

Slowloris***防护比较简单，主要方案有两个。

第 一个是统计每一个TCP链接的时长并计算单位时间内经过的报文数量便可作精确识别。一个TCP链接中，HTTP报文太少和报文太多都是不正常的，过少多是 慢速链接***，过多多是使用HTTP 1.1协议进行的HTTP Flood***，在一个TCP链接中发送多个HTTP请求。

第二个是限制HTTP头部传输的最大许可时间。超过指定时间HTTP Header尚未传输完成，直接断定源IP地址为慢速链接***，中断链接并加入黑名单。

企业级防护

互联网企业防护DDoS***，主要使用上文的基础防护手段，重点在于监控、组织以及流程。

监 控须要具有多层监控、纵深防护的概念，从骨干网络、IDC入口网络的BPS、PPS、协议分布，负载均衡层的VIP新建链接数、并发链接数、BPS、 PPS到主机层的CPU状态、TCP新建链接数状态、TCP并发链接数状态，到业务层的业务处理量、业务连通性等多个点部署监控系统。即便一个监控点失 效，其余监控点也可以及时给出报警信息。多个点信息结合，准确判断被***目标和***手法。

一 旦发现异常，当即启动在虚拟防护组织中的应急流程，防护组织须要囊括到足够全面的人员，至少包含监控部门、运维部门、网络部门、安所有门、客服部门、业务 部门等，全部人员都须要2-3个备份。流程启动后，除了人工处理，还应该包含必定的自动处理、半自动处理能力。例如自动化的***分析，肯定***类型，自动 化、半自动化的防护策略，在安全人员到位以前，最早发现***的部门能够作一些缓解措施。

除 了DDoS到来之时的流程等工做以外，更多的工做是在***到来以前。主要包含CDN节点部署、DNS设置、流程演习等。对于企业来讲，具有多个CDN节点 是DDoS防护容量的关键指标。当一个机房承担不住海量数据时，能够经过DNS轮询的方式，把流量引导到多个分布节点，使用防护设备分头处理。所以DNS 的TTL值须要设置得足够小，可以快速切换，每一个CDN节点的各类VIP设置也须要准备充分。

在 虚拟化时代，各类用户的不一样业务共处在相同的物理机平台，遭受DDoS***的可能性愈来愈高，并且一个用户被***可能牵扯到大量的其余用户，危害被显著放 大，所以防护显得尤其重要。阿里云的虚拟化业务，平均天天遭受约20起DDoS***，最大流量达到接近20Gbit/s，全部这些***都在15分钟内自动 处理完成，让客户远离DDoS的威胁，专心发展业务。

总地来讲，对DDoS防护，主要的工做是幕后积累。台上十分钟，台下十年功，没有充分的资源准备，没有足够的应急演练，没有丰富的处理经验，DDoS***将是全部人的噩梦。

相关连接：http://blog.aliyun.com/author/aliyun_blog?spm=0.0.0.0.qTzxdl