CC攻击的原理就是攻击者控制某些主机不停地发大量数据包给对方服务器形成服务器资源耗尽,一直到宕机崩溃。CC主要是用来消耗服务器资源的,每一个人都有这样的体验:当一个网页访问的人数特别多的时候,打开网页就慢了,CC就是模拟多个用户(多少线程就是多少用户)不停地进行访问那些须要大量数据操做(就是须要大量CPU时间)的页面,形成服务器资源的浪费,CPU长时间处于100%,永远都有处理不完的链接直至就网络拥塞,正常的访问被停止。html
CC攻击的种类有三种,直接攻击,代理攻击,僵尸网络攻击,直接攻击主要针对有重要缺陷的 WEB 应用程序,通常说来是程序写的有问题的时候才会出现这种状况,比较少见。僵尸网络攻击有点相似于 DDOS 攻击了,从 WEB 应用程序层面上已经没法防护,因此代理攻击是CC 攻击者通常会操做一批代理服务器,比方说 100 个代理,而后每一个代理同时发出 10 个请求,这样 WEB 服务器同时收到 1000 个并发请求的,而且在发出请求后,马上断掉与代理的链接,避免代理返回的数据将自己的带宽堵死,而不能发动再次请求,这时 WEB 服务器会将响应这些请求的进程进行队列,数据库服务器也一样如此,这样一来,正常请求将会被排在很后被处理,就象原本你去食堂吃饭时,通常只有不到十我的在排队,今天前面却插了一千我的,那么轮到你的机会就很小很小了,这时就出现页面打开极其缓慢或者白屏。node
1) 什么是DDoS攻击?nginx
DDoS攻击就是分布式的拒绝服务攻击,DDoS攻击手段是在传统的DoS攻击基础之上产生的一类攻击方式。单一的DoS攻击通常是采用一对一方式的,随着计算机与网络技术的发展,DoS攻击的困难程度加大了。因而就产生了DDoS攻击,它的原理就很简单:计算机与网络的处理能力加大了10倍,用一台攻击机来攻击再也不能起做用,那么DDoS就是利用更多的傀儡机来发起进攻,以比从前更大的规模来进攻受害者。经常使用的DDoS软件有:LOIC。git
在这里补充两点:第一就是DDOS攻击不只能攻击计算机,还能攻击路由器,由于路由器是一台特殊类型的计算机;第二是网速决定攻击的好和快,好比说,若是你一个被限制网速的环境下,它们的攻击效果不是很明显,可是快的网速相比之下更加具备攻击效果。github
2)什么是CC攻击?web
3)二者区别算法
DDoS是针对IP的攻击,而CC攻击的是服务器资源。数据库
1)什么是慢速攻击后端
一提及慢速攻击,就要谈谈它的成名历史了。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时,会认为客户端没有发送完头部,而持续的等等客户端发送数据。
慢速攻击主要利用的是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代码的方式依然能达到部分效果。可是根据慢速攻击的特征,能够辅助如下几种防御方式:一、周期内统计报文数量。一个TCP链接,HTTP请求的报文中,报文过多或者报文过少都是有问题的,若是一个周期内报文数量很是少,那么它就多是慢速攻击;若是一个周期内报文数量很是多,那么它就多是一个CC攻击。二、限制HTTP请求头的最大许可时间。超过最大许可时间,若是数据尚未传输完成,那么它就有多是一个慢速攻击。
简单的Nginx防CC方式
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; } }
上面样本的配置是什么意思呢?
详细的能够参考官方说明文档:Module ngx_http_limit_req_module
这里咱们须要Apache Benchmark这个小工具来生成请求
//1个用户持续100s的时间向服务器发送请求 ab -t 100 -c 1 -vvv http://example.com/
http { limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; server { limit_req zone=one burst=1 nodelay; } }
ab测试结果以下所示:
数据 | 成功的请求数 | 失败的请求数 | 请求时间 | 每秒成功的请求数 |
---|---|---|---|---|
1 | 100 | 19438 | 101.195 | 0.98 |
2 | 100 | 17651 | 100.655 | 0.99 |
3 | 97 | 25735 | 100.424 | 0.96 |
4 | 101 | 26791 | 100.000 | 1.01 |
5 | 98 | 19051 | 100.514 | 0.98 |
平均 | 99 | 21733.2 | 100.557 | 0.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给客户端,浏览器上面显示的是这个样子的。
在配置二里面,我把burst(峰值)提升到了10
http { limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; server { limit_req zone=one burst=10 nodelay; } }
数据 | 成功的请求数 | 失败的请求数 | 请求时间 | 每秒成功的请求数 |
---|---|---|---|---|
1 | 110 | 19042 | 100.144 | 1.09 |
2 | 111 | 22271 | 101.714 | 1.09 |
3 | 111 | 18466 | 100.504 | 1.10 |
4 | 111 | 16468 | 101.285 | 1.09 |
5 | 111 | 12770 | 100.596 | 1.10 |
平均 | 110 | 17803 | 100.788 | 1.09 |
从数据来看,提升了burst值,明显nginx成功的请求数上去了。
在样本二的基础上,咱们把nodelay去除掉
http { limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; server { limit_req zone=one burst=10; } }
数据 | 成功的请求数 | 失败的请求数 | 请求时间 | 每秒成功的请求数 |
---|---|---|---|---|
1 | 96 | 0 | 100.223 | 1.09 |
2 | 98 | 0 | 100.238 | 0.97 |
3 | 100 | 0 | 100.761 | 0.99 |
4 | 96 | 0 | 100.074 | 0.95 |
5 | 97 | 0 | 100.021 | 0.96 |
平均 | 97.4 | 0 | 100.263 | 0.97 |
从这里的数据能够看到将nodelay的参数去掉的话,成功的请求数在100左右而失败的请求数变成0了,为何呢?
虽然用limit_req_module能够必定上的防止CC攻击,可是有误杀几率;国内宽带用户的IP地址已经大量内网化,几百人共享一个IP的可能性是很大的。
问题模型描述:
每个页面,都有其资源消耗权重,静态资源,权重较低,动态资源,权重较高。对于用户访问,有以下:
用户资源使用频率=使用的服务器总资源量/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。
肯定Web服务器正在或者曾经遭受CC攻击,那如何进行有效的防范呢?
(1).取消域名绑定
通常cc攻击都是针对网站的域名进行攻击,好比咱们的网站域名是“www.abc.com”,那么攻击者就在攻击工具中设定攻击对象为该域名而后实施攻击。 对于这样的攻击咱们的措施是取消这个域名的绑定,让CC攻击失去目标。
(2).域名欺骗解析
若是发现针对域名的CC攻击,咱们能够把被攻击的域名解析到127.0.0.1这个地址上。咱们知道127.0.0.1是本地回环IP是用来进行网络测试的,若是把被攻击的域名解析到这个IP上,就能够实现攻击者本身攻击本身的目的,这样他再多的肉鸡或者代理也会宕机,让其自食其果。
(3).更改Web端口
通常状况下Web服务器经过80端口对外提供服务,所以攻击者实施攻击就以默认的80端口进行攻击,因此,咱们能够修改Web端口达到防CC攻击的目的。运行IIS管理器,定位到相应站点,打开站点“属性”面板,在“网站标识”下有个TCP端口默认为80,咱们修改成其余的端口就能够了。
(4).屏蔽IP 咱们经过命令或在查看日志发现了CC攻击的源IP,就能够在防火墙中设置屏蔽该IP对Web站点的访问,从而达到防范攻击的目的。