慢速DDoS攻击-zhyjc6's Blog

前言

我们这次主要讲的是DDoS攻击也是CC攻击中的一种另类攻击（DDoS真是个让大多数网站无可奈何的攻击）

拒绝服务攻击问题一直得不到合理的解决，目前还是世界性难题，究其原因是因为这是由于网络协议本身的安全缺陷造成的，（这里不细说，详情自行百度）从而拒绝服务攻击也成为了攻击者的终极手法。

DDoS攻击的前身是DoS(Denial of Service,拒绝服务攻击)。DoS的精华是“大”，攻击网站的流量要大。但是DoS是一对一攻击，就很难达到很大流量的效果。所以后来出现了DDoS(Distributed Denial of Service,分布式拒绝服务攻击)。DDoS在DoS的基础上加入了代理，也就是常说的傀儡机。攻击者不会直接对目标网站发动攻击，而是调起一堆受其控制的其它主机（真实主机），通过操纵其他主机使得其他主机向目标网站发动DDoS攻击。这样的话，网站的站主就很难找到真正的攻击者。比较大型的DDoS攻击可能会使用二级或者多级代理，攻击者在攻击完毕后只需要抹除少数的第一级代理机器的攻击信息就可以继续逍遥法外。

CC(Challenge CoHapsar，挑战黑洞，为什么叫挑战黑洞呢？因为以前的抵抗DDoS攻击的安全设备叫黑洞，顾名思义挑战黑洞就是说黑洞拿这种攻击没办法，新一代的抗DDoS设备已经改名为ADS(Anti-DDoS System)，基本上已经可以完美的抵御CC攻击了 )攻击是DDoS攻击的一种类型，使用代理服务器向受害服务器发送大量貌似合法的请求。

CC攻击的原理就是攻击者控制某些主机不停地发大量数据包给对方服务器造成服务器资源耗尽，一直到宕机崩溃。CC主要是用来攻击网页的，每个人都有这样的体验：当一个网页访问的人数特别多的时候，打开网页就慢了。CC就是模拟多个用户（多少线程就是多少用户）不停地进行访问那些需要大量数据操作（就是需要大量CPU时间）的页面，造成服务器资源的浪费，CPU长时间处于100%，永远都有处理不完的连接直至就网络拥塞，正常的访问被中止。

DDoS攻击和CC攻击区别：

DDoS攻击是主要针对IP的攻击，而CC攻击的主要是网页。
CC攻击相对来说，攻击的危害不是毁灭性的，但是持续时间长;
而DDoS攻击就是流量攻击，这种攻击的危害性较大，通过向目标服务器发送大量数据包，耗尽其带宽，更难防御。
CC不像DDoS可以用硬件防火墙来过滤攻击，因为CC攻击本身的请求就是正常的请求。

具体区别：

DDoS攻击打的是网站的服务器，而CC攻击是针对网站的页面攻击的，用术语来说就是，一个是WEB网络层拒绝服务攻击（DDoS），一个是WEB应用层拒绝服务攻击（CC），网络层就是利用肉鸡的流量去攻击目标网站的服务器，针对比较本源的东西去攻击，服务器瘫痪了，那么运行在服务器上的网站肯定也不能正常访问了。而应用层就是我们用户看得到的东西，就比如说网页，CC攻击就是针对网页来攻击的，CC攻击本身是正常请求，网站动态页面的正常请求也会和数据库进行交互的，当这种”正常请求”达到一种程度的时候，服务器就会响应不过来，从而崩溃。

好了，终于到了今天要讲的主题了。

我们今天要讲的主题就是慢速攻击——CC攻击的一种。

慢速DDoS攻击

1. 来历

HTTP Post慢速DoS攻击第一次在技术社区被正式披露是2012年的OWASP大会上，由Wong Onn Chee 和 Tom Brennan共同演示了使用这一技术攻击的威力。

这个攻击的基本原理如下：攻击者对任何一个开放了HTTP访问的服务器HTTP服务器，先建立了一个连接，指定一个比较大的content-length，然后以非常低的速度发包，比如1-10s发一个字节，然后维持住这个连接不断开。如果客户端持续建立这样的连接，那么服务器上可用的连接将一点一点被占满，从而导致拒绝服务。

2. 分类

发展到今天，慢速攻击也多种多样，其种类可分为以下几种：

Slow headers
Slow body
Slow read

Slow headers：Web应用在处理HTTP请求之前都要先接收完所有的HTTP头部，因为HTTP头部中包含了一些Web应用可能用到的重要的信息。而HTTP协议规定，HTTP Request以\r\n\r\n（0d0a0d0a）结尾表示客户端发送结束，服务端开始处理。那么，如果永远不发送\r\n\r\n会如何？攻击者利用这点，发起一个HTTP请求，一直不停的发送HTTP头部，消耗服务器的连接和内存资源。抓包数据可见，攻击客户端与服务器建立TCP连接后，每30秒才向服务器发送一个HTTP头部，而Web服务器再没接收到2个连续的\r\n时，会认为客户端没有发送完头部，而持续的等待客户端发送数据。如果攻击者使用多线程或者傀儡机来做同样的操作，服务器的Web容器很快就被攻击者占满了TCP连接而不再接受新的请求。

Slow body：攻击者发送一个HTTP POST请求，该请求的Content-Length头部值很大，使得Web服务器或代理认为客户端要发送很大的数据。服务器会保持连接准备接收数据，但攻击客户端每次只发送很少量的数据，使该连接一直保持存活，消耗服务器的连接和内存资源。抓包数据可见，攻击客户端与服务器建立TCP连接后，发送了完整的HTTP头部，POST方法带有较大的Content-Length，然后每10s发送一次随机的参数。服务器因为没有接收到相应Content-Length的body，而持续的等待客户端发送数据。

Slow read：客户端与服务器建立连接并发送了一个HTTP请求，客户端发送完整的请求给服务器端，然后一直保持这个连接，以很低的速度读取Response，比如很长一段时间客户端不读取任何数据，通过发送Zero Window到服务器，让服务器误以为客户端很忙，直到连接快超时前才读取一个字节，以消耗服务器的连接和内存资源。抓包数据可见，客户端把数据发给服务器后，服务器发送响应时，收到了客户端的ZeroWindow提示（表示自己没有缓冲区用于接收数据），服务器不得不持续的向客户端发出ZeroWindowProbe包，询问客户端是否可以接收数据。

哪些服务器容易被慢速攻击

慢速攻击主要利用的是thread-based架构的服务器的特性，这种服务器会为每个新连接打开一个线程，它会等待接收完整个HTTP头部才会释放连接。比如Apache会有一个超时时间来等待这种不完全连接（默认是300s），但是一旦接收到客户端发来的数据，这个超时时间会被重置。正是因为这样，攻击者可以很容易保持住一个连接，因为攻击者只需要在即将超时之前发送一个字符，便可以延长超时时间。而客户端只需要很少的资源，便可以打开多个连接，进而占用服务器很多的资源。

经验证，Apache、httpd采用thread-based架构，很容易遭受慢速攻击。而另外一种event-based架构的服务器，比如nginx和lighttpd则不容易遭受慢速攻击。

thread-based architecture 基于线程的体系结构通常会使用多线程来处理客户端的请求，每当接服务端主程序收到一个请求，便开启一个独立的线程来处理客户端的事件。这种方式仅适用于并发访问量不大的场景，因为线程需要占用一定的内存资源，且操作系统在线程之间的切换也需要一定的开销，当线程数过多时显然会降低web服务器的性能。并且线程阻塞等待I/O操作时也会造成CPU资源的浪费。

event-driven architecture 事件驱动体系结构是目前比较广泛使用的一种。这种方式会定义一系列的事件处理器来响应事件的发生，并且将服务端接受连接与对事件的处理分离。其中，事件是一种状态的改变。比如，tcp中socket的new incoming connection、ready for read、ready for write。

四、如何防护慢速攻击

Apache防御

Apache服务器现在使用较多的有三种简单防护方式 :

mod_reqtimeout
mod_qos
mod_security

mod_reqtimeout：Apache2.2.15后，该模块已经被默认包含，用户可配置从一个客户端接收HTTP头部和HTTPbody的超时时间和最小速率。如果一个客户端不能在配置时间内发送完头部或body数据，服务器会返回一个408REQUEST TIME OUT错误。

配置文件如下：

< IfModule mod_reqtimeout.c >

RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

< /IfModule >

mod_qos: Apache的一个服务质量控制模块，用户可配置各种不同粒度的HTTP请求阈值，配置文件如下：

< IfModule mod_qos.c >

/# handle connections from up to 100000 different IPs

QS_ClientEntries 100000

/# allow only 50 connections per IP

QS_SrvMaxConnPerIP 50

/# limit maximum number of active TCP connections limited to 256

MaxClients 256

/# disables keep-alive when 180 (70%) TCP connections are occupied

QS_SrvMaxConnClose 180

/# minimum request/response speed (deny slow clients blocking the server, keeping connections open without requesting anything

QS_SrvMinDataRate 150 1200

< /IfModule >

mod_security：一个开源的WAF模块，有专门针对慢速攻击防护的规则，配置如下 :

SecRule RESPONSE_STATUS “@streq 408” “phase:5,t:none,nolog,pass, setvar:ip.slow_dos_counter=+1, expirevar:ip.slow_dos_counter=60, id:’1234123456′”

SecRule IP:SLOW_DOS_COUNTER “@gt 5” “phase:1,t:none,log,drop,

msg:’Client Connection Dropped due to high number of slow DoS alerts’, id:’1234123457′”

一般防御思路

因为CC攻击通过工具软件发起，而普通用户通过浏览器访问，这其中就会有某些区别。想办法对这二者作出判断，选择性的屏蔽来自机器的流量即可。

初级

普通浏览器发起请求时，除了要访问的地址以外，Http头中还会带有Referer，UserAgent等多项信息。遇到攻击时可以通过日志查看访问信息，看攻击的流量是否有明显特征，比如固定的Referer或UserAgent，如果能找到特征，就可以直接屏蔽掉了。

中级

如果攻击者伪造了Referer和UserAgent等信息，那就需要从其他地方入手。攻击软件一般来说功能都比较简单，只有固定的发包功能，而浏览器会完整的支持Http协议，我们可以利用这一点来进行防御。

首先为每个访问者定义一个字符串，保存在Cookies中作为Token，必须要带有正确的Token才可以访问后端服务。当用户第一次访问时，会检测到用户的Cookies里面并没有这个Token，则返回一个302重定向，目标地址为当前页面，同时在返回的Http头中加入set cookies字段，对Cookies进行设置，使用户带有这个Token。

客户端如果是一个正常的浏览器，那么就会支持http头中的set cookie和302重定向指令，将带上正确的Token再次访问页面，这时候后台检测到正确的Token，就会放行，这之后用户的Http请求都会带有这个Token，所以并不会受到阻拦。

客户端如果是CC软件，那么一般不会支持这些指令，那么就会一直被拦在最外层，并不会对服务器内部造成压力。

高级

高级一点的，还可以返回一个网页，在页面中嵌入JavaScript来设置Cookies并跳转，这样被伪造请求的可能性更小。

Token生成算法。Token需要满足以下几点要求

每个IP地址的Token不同
无法伪造
一致性，即对相同的客户端，每次生成的Token相同

Token随IP地址变化是为了防止通过一台机器获取Token之后，再通过代理服务区进行攻击。一致性则是为了避免在服务器端需要存储已经生成的Token。

推荐使用以下算法生成Token，其中Key为服务器独有的保密字符串，这个算法生成的Token可以满足以上这些要求。

Token = Hash( UserAgent + client_ip + key )

应用层DDoS防御理论

问题模型描述

每一个页面，都有其资源消耗权重，静态资源，权重较低，动态资源，权重较高。对于用户访问，有如下：

用户资源使用频率=使用的服务器总资源量/s

命题一：对于正常访问的用户，资源使用频率必定位于一个合理的范围，当然会存在大量正常用户共享ip的情况，这就需要日常用户访问统计，以得到忠实用户ip白名单。

命题二：资源使用频率持续异常的，可断定为访问异常的用户。

防御体系状态机

在系统各项资源非常宽裕时，向所有ip提供服务，每隔一段时间释放一部分临时黑名单中的ip成员；
在系统资源消耗达到某一阈值时，降低SYN包接受速率，循环：分析最近时间的日志，并将访问异常的ip加入临时黑名单；
若系统资源消耗慢慢回降至正常水平，则恢复SYN包接受速率，转到状态1；若目前策略并未有效地控制住系统资源消耗的增长，情况继续恶劣至一极限阈值，转到状态4；
最终防御方案，使用忠实用户ip白名单、异常访问ip黑名单策略，其他访问可慢慢放入，直到系统资源消耗回降至正常水平，转到状态1。

上述的防御状态机，对于单个攻击IP高并发的DDOS，变化到状态3时，效果就完全体现出来了，但如果防御状态机进行到4状态，则有如下两种可能：

站点遭到了攻击群庞大的、单个IP低并发的DDOS攻击；
站点突然间有了很多访问正常的新用户。