深入浅出DDoS攻击防御

亦凉 2022-08-07 11:53 50阅读 0赞

敌情篇 ——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][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_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][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下载来说，伪造一些热门视频的种子，发布到搜索引擎，就足以骗到许多用户和流量了，但这只是基础攻击。

高级P2P攻击，是直接欺骗资源管理服务器。如迅雷客户端会把自己发现的资源上传到资源管理服务器，然后推送给其他需要下载相同资源的用户，这样，一个链接就发布出去。通过协议逆向，攻击者伪造出大批量的热门资源信息通过资源管理中心分发出去，瞬间就可以传遍整个P2P网络。更为恐怖的是，这种攻击是无法停止的，即使是攻击者自身也无法停止，攻击一直持续到P2P官方发现问题更新服务器且下载用户重启下载软件时为止。

![攻击和防御][TM_E6_88_AA_E5_9B_BE_E6_9C_AA_E5_91_BD_E5_90_8D5.jpg]

应对篇 ——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小包攻击，数据包结构如下：

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

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

也就是说，一个本来只有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攻击将是所有人的噩梦。

**作者魏兴国，阿里巴巴集团高级安全专家，主要负责阿里云虚拟化业务安全，以及集团范围的网络安全策略。**

**转自：[深入浅出DDoS攻击防御][DDoS]**

[http_www.icylife.net_yunshu_show.php_id_367]: http://www.icylife.net/yunshu/show.php?id=367
[http_www.icylife.net_yunshu_show.php_id_832]: http://www.icylife.net/yunshu/show.php?id=832
[http_ha.ckers.org_slowloris_slowloris.pl]: http://ha.ckers.org/slowloris/slowloris.pl
[TM_E6_88_AA_E5_9B_BE_E6_9C_AA_E5_91_BD_E5_90_8D5.jpg]: /images/20220805/f44d16a839b648c2b24bbca263ddb3d0.png
[DDoS]: http://www.programmer.com.cn/12874/