CC攻击

什么是CC攻击

CC攻击(Challenge Collapsar)CC攻击的本名叫做HTTP-FLOOD,是一种专门针对于Web的应用层FLOOD攻击,攻击者操纵网络上的肉鸡,对目标Web服务器进行海量http request攻击,是DDOS(分布式拒绝服务)的一种,也是一种常见的网站攻击方法,攻击者通过代理服务器或者肉鸡向向受害主机不停地发大量数据包,造成对方服务器资源耗尽,一直到宕机崩溃。

DDoS攻击与CC攻击的区别

什么是DDoS攻击?

DDoS攻击就是分布式的拒绝服务攻击,DDoS攻击手段是在传统的DoS攻击基础之上产生的一类攻击方式。单一的DoS攻击一般是采用一对一方式的,随着计算机与网络技术的发展,DoS攻击的困难程度加大了。于是就产生了DDoS攻击,它的原理就很简单:计算机与网络的处理能力加大了10倍,用一台攻击机来攻击不再能起作用,那么DDoS就是利用更多的傀儡机来发起进攻,以比从前更大的规模来进攻受害者。常用的DDoS软件有:LOIC。

下载地址https://sourceforge.net/projects/loic/files/latest/download

什么是CC攻击?

1.CC攻击来的IP都是真实的,分散的;

2.CC攻击的数据包都是正常的数据包;

3.CC攻击的请求,全都是有效的请求,无法拒绝的请求;

4.因为cc攻击的是网页,服务器什么都可以连接,ping也没问题,但是网页就是访问不;

5.但是iis一开服务器一会就死,而且被攻击后就老丢包。不知道是不是cc攻击,syn 攻击频率才78ack攻击频率663.

两者区别:

DDoS是针对IP的攻击,而CC攻击的是网页。

CC攻击的变异品种 慢速攻击

什么是慢速攻击

一说起慢速攻击,就要谈谈它的成名历史了。HTTP Post慢速DoS攻击第一次在技术社区被正式披露是2012年的OWASP大会上,由Wong Onn Chee 和 Tom Brennan共同演示了使用这一技术攻击的威力。

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

和CC攻击一样,只要Web服务器开放了Web服务,那么它就可以是一个靶子,HTTP协议在接收到request之前是不对请求内容作校验的,所以即使你的Web应用没有可用的form表单,这个攻击一样有效。

在客户端以单线程方式建立较大数量的无用连接,并保持持续发包的代价非常的低廉。实际试验中一台普通PC可以建立的连接在3000个以上。这对一台普通的Web server,将是致命的打击。更不用说结合肉鸡群做分布式DoS了。

鉴于此攻击简单的利用程度、拒绝服务的后果、带有逃逸特性的攻击方式,这类攻击一炮而红,成为众多攻击者的研究和利用对象。

慢速攻击的分类

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

Slow headers:Web应用在处理HTTP请求之前都要先接收完所有的HTTP头部,因为HTTP头部中包含了一些Web应用可能用到的重要的信息。攻击者利用这点,发起一个HTTP请求,一直不停的发送HTTP头部,消耗服务器的连接和内存资源。抓包数据可见,攻击客户端与服务器建立TCP连接后,每30秒才向服务器发送一个HTTP头部,而Web服务器再没接收到2个连续的\r\n时,会认为客户端没有发送完头部,而持续的等等客户端发送数据。

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

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

使用较多的慢速攻击工具有:Slowhttptest和Slowloris。

哪些服务器易被慢速攻击

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

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

如何防护慢速攻击

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

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攻击,主要通过阈值的方式来进行防护,某一个客户在一定的周期内,请求访问量过大,超过了阈值,清洗设备通过返回验证码或者JS代码的方式。这种防护方式的依据是,攻击者们使用肉鸡上的DDoS工具模拟大量http request,这种工具一般不会解析服务端返回数据,更不会解析JS之类的代码。因此当清洗设备截获到HTTP请求时,返回一段特殊JavaScript代码,正常用户的浏览器会处理并正常跳转不影响使用,而攻击程序会攻击到空处。

而对于慢速攻击来说,通过返回验证码或者JS代码的方式依然能达到部分效果。但是根据慢速攻击的特征,可以辅助以下几种防护方式:1、周期内统计报文数量。一个TCP连接,HTTP请求的报文中,报文过多或者报文过少都是有问题的,如果一个周期内报文数量非常少,那么它就可能是慢速攻击;如果一个周期内报文数量非常多,那么它就可能是一个CC攻击。2、限制HTTP请求头的最大许可时间。超过最大许可时间,如果数据还没有传输完成,那么它就有可能是一个慢速攻击。

简单的Nginx防CC方式

使用nginx提供给我们的limit_req_module模块来限制单个IP的请求次数

实验

Nginx配置

http {

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

server {

#限制每ip每秒不超过20个请求,漏桶数burst为5

#brust的意思就是,如果第1秒、2,3,4秒请求为19个,

#第5秒的请求为25个是被允许的。

#但是如果你第1秒就25个请求,第2秒超过20的请求返回503错误。

#nodelay,如果不设置该选项,严格使用平均速率限制请求数,

#第1秒25个请求时,5个请求放到第2秒执行,

#设置nodelay,25个请求将在第1秒执行。

limit_req zone=one burst=1 nodelay;

}

}

上面样本的配置是什么意思呢?

$binary_remote_addr 表示:客户端IP地址

zone 表示漏桶的名字

rate 表示nginx处理请求的速度有多快

burst 表示峰值

nodelay 表示是否延迟处理请求,还是直接503返回给客户端,如果超出rate设置的情况下。

详细的可以参考官方说明文档:Module ngx_http_limit_req_module

模拟请求

这里我们需要Apache Benchmark这个小工具来生成请求

//1个用户持续100s的时间向服务器发送请求

ab -t 100 -c 1 -vvv http://example.com/

Nginx配置样本一

http {

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

server {

limit_req zone=one burst=1 nodelay;

}

}

ab测试结果如下所示:

数据成功的请求数失败的请求数请求时间每秒成功的请求数

110019438101.1950.98

210017651100.6550.99

39725735100.4240.96

410126791100.0001.01

59819051100.5140.98

平均9921733.2100.5570.98

以上失败的请求在Nginx上生成的错误日志如下显示

2015/05/09 12:48:57 [error] 6564#0: *2219 limiting requests, excess: 1.273 by zone "one", client: 10.0.2.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com"

2015/05/09 12:48:57 [error] 6564#0: *2220 limiting requests, excess: 1.272 by zone "one", client: 10.0.2.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com"

2015/05/09 12:48:57 [error] 6564#0: *2221 limiting requests, excess: 1.271 by zone "one", client: 10.0.2.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com"

2015/05/09 12:48:57 [error] 6564#0: *2222 limiting requests, excess: 1.270 by zone "one", client: 10.0.2.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com"

2015/05/09 12:48:57 [error] 6564#0: *2223 limiting requests, excess: 1.269 by zone "one", client: 10.0.2.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com"

2015/05/09 12:48:57 [error] 6564#0: *2224 limiting requests, excess: 1.268 by zone "one", client: 10.0.2.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com"

如上ab测试中如果是失败的请求,nginx的limit_req模块会统一返回503给客户端,浏览器上面显示的是这个样子的。

Nginx配置样本二

在配置二里面,我把burst(峰值)提高到了10

http {

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

server {

limit_req zone=one burst=10 nodelay;

}

}

数据成功的请求数失败的请求数请求时间每秒成功的请求数

111019042100.1441.09

211122271101.7141.09

311118466100.5041.10

411116468101.2851.09

511112770100.5961.10

平均11017803100.7881.09

从数据来看,提高了burst值,明显nginx成功的请求数上去了。

Nginx配置样本三

在样本二的基础上,我们把nodelay去除掉

http {

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

server {

limit_req zone=one burst=10;

}

}

数据成功的请求数失败的请求数请求时间每秒成功的请求数

1960100.2231.09

2980100.2380.97

31000100.7610.99

4960100.0740.95

5970100.0210.96

平均97.40100.2630.97

从这里的数据可以看到将nodelay的参数去掉的话,成功的请求数在100左右而失败的请求数变成0了,为什么呢?

有nodelay参数的时候,nginx正常是及时处理当前的请求的并响应数据给客户端,但是如果超过limit_req_module的限制,那么会统一返回503给客户端。

无nodelay参数的时候,nginx正常是及时处理当前的请求的并响应数据给客户端,但是如果超过limit_req_module的限制,那么会将此此请求缓存「就先这么理解」起来稍后再处理,所以也就不会出现大量的失败请求数了。

存在的问题

虽然用limit_req_module可以一定上的防止CC攻击,但是有误杀概率;国内宽带用户的IP地址已经大量内网化,几百人共享一个IP的可能性是很大的。

应用层DDoS的防御理论:

问题模型描述:

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

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

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

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

防御体系状态机:

1.在系统各项资源非常宽裕时,向所有ip提供服务,每隔一段时间释放一部分临时黑名单中的ip成员;

2.在系统资源消耗达到某一阈值时,降低Syn包接受速率,循环:分析最近时间的日志,并将访问异常的ip加入临时黑名单;

3.若系统资源消耗慢慢回降至正常水平,则恢复Syn包接受速率,转到状态1;若目前策略并未有效地控制住系统资源消耗的增长,情况继续恶劣至一极限阈值,转到状态4;

4.最终防御方案,使用忠实用户ip白名单、异常访问ip黑名单策略,其他访问可慢慢放入,直到系统资源消耗回降至正常水平,转到状态1。

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

1.站点遭到了攻击群庞大的、单个IP低并发的DDOS攻击;

2.站点突然间有了很多访问正常的新用户。

建议后续工作:

保守:站点应尽快进行服务能力升级。

积极:尽所能,追溯攻击者。

追溯攻击者:

CC:proxy-forward-from-ip

单个IP高并发的DDOS:找到访问异常的、高度可疑的ip列表,exploit,搜集、分析数据,因为一个傀儡主机可被二次攻占的概率很大(但不建议这种方法)

单个IP低并发的DDOS:以前极少访问被攻击站点,但是在攻击发生时,却频繁访问我们的站点,分析日志得到这一部分ip列表

追溯攻击者的过程中,snat与web proxy增加了追踪的难度,如果攻击者采用多个中继服务器的方法,追溯将变得极为困难。

防御者:

1.应对当前系统了如指掌,如系统最高负载、最高数据处理能力,以及系统防御体系的强项与弱点

2.历史日志的保存、分析

3.对当前系统进行严格安全审计

4.上报公安相关部分,努力追溯攻击者

5.网站,能静态,就一定不要动态,可采取定时从主数据库生成静态页面的方式,对需要访问主数据库的服务使用验证机制。

6.防御者应能从全局的角度,迅速及时地发现系统正在处于什么程度的攻击、何种攻击,在平时,应该建立起攻击应急策略,规范化操作,免得在急中犯下低级错误

对历史日志的分析这时将会非常重要,数据可视化与统计学的方法将会很有益处:

1.分析每个页面的平均访问频率

2.对访问频率异常的页面进行详细分析 分析得到ip-页面访问频率

3.得到对访问异常页面的访问异常ip列表

4.对日志分析得到忠实用户IP白名单

5.一般一个页面会关联多个资源,一次对于这样的页面访问往往会同时增加多个资源的访问数,而攻击程序一般不会加载这些它不感兴趣的资源,所以,这也是一个非常好的分析突破点

防御思路

因为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需要满足以下几点要求

1,每个IP地址的Token不同

2, 无法伪造

3, 一致性,即对相同的客户端,每次生成的Token相同

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

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

Token = Hash( UserAgent + client_ip + key )

本文主要讲述了DDoS攻击之一的CC攻击工具实现,以及如何防御来自应用层的DDoS攻击的理论总结。接下来的文章,笔者将会实现一个工作于内核态的、具有黑名单功能的防火墙模块,以对应于上述防御状态机中的防火墙单元,它实现了自主地动态内存管理,使用hash表管理ip列表,并可以自定义hash表的modular。

http://blog.nsfocus.net/cc-attack-defense/

http://xrong.net/2015/05/07/Nginx%E9%98%B2CC%E6%94%BB%E5%87%BB/

https://www.zhihu.com/question/41909337

推荐阅读更多精彩内容