建一个网站的费用,wordpress副标题代码,郑州高端建站,石龙网站仿做一、 CC攻击的原理#xff1a; CC攻击的原理就是攻击者控制某些主机不停地发大量数据包给对方服务器造成服务器资源耗尽#xff0c;一直到宕机崩溃。CC主要是用来消耗服务器资源的#xff0c;每个人都有这样的体验#xff1a;当一个网页访问的人数特别多的时候#xff0c…一、 CC攻击的原理  　　CC攻击的原理就是攻击者控制某些主机不停地发大量数据包给对方服务器造成服务器资源耗尽一直到宕机崩溃。CC主要是用来消耗服务器资源的每个人都有这样的体验当一个网页访问的人数特别多的时候打开网页就慢了CC就是模拟多个用户(多少线程就是多少用户)不停地进行访问那些需要大量数据操作(就是需要大量CPU时间)的页面造成服务器资源的浪费CPU长时间处于100%永远都有处理不完的连接直至就网络拥塞正常的访问被中止。 二、CC攻击的种类 　　 CC攻击的种类有三种直接攻击代理攻击僵尸网络攻击直接攻击主要针对有重要缺陷的 WEB 应用程序一般说来是程序写的有问题的时候才会出现这种情况比较少见。僵尸网络攻击有点类似于 DDOS 攻击了从 WEB 应用程序层面上已经无法防御所以代理攻击是CC 攻击者一般会操作一批代理服务器比方说 100 个代理然后每个代理同时发出 10 个请求这样 WEB 服务器同时收到 1000 个并发请求的并且在发出请求后立刻断掉与代理的连接避免代理返回的数据将本身的带宽堵死而不能发动再次请求这时 WEB 服务器会将响应这些请求的进程进行队列数据库服务器也同样如此这样一来正常请求将会被排在很后被处理就象本来你去食堂吃饭时一般只有不到十个人在排队今天前面却插了一千个人那么轮到你的机会就很小很小了这时就出现页面打开极其缓慢或者白屏。   三、CC攻击与DDOS的区别        1) 什么是DDoS攻击 DDoS攻击就是分布式的拒绝服务攻击DDoS攻击手段是在传统的DoS攻击基础之上产生的一类攻击方式。单一的DoS攻击一般是采用一对一方式的随着计算机与网络技术的发展DoS攻击的困难程度加大了。于是就产生了DDoS攻击它的原理就很简单计算机与网络的处理能力加大了10倍用一台攻击机来攻击不再能起作用那么DDoS就是利用更多的傀儡机来发起进攻以比从前更大的规模来进攻受害者。常用的DDoS软件有LOIC。 在这里补充两点第一就是DDOS攻击不仅能攻击计算机还能攻击路由器因为路由器是一台特殊类型的计算机第二是网速决定攻击的好和快比如说如果你一个被限制网速的环境下它们的攻击效果不是很明显但是快的网速相比之下更加具有攻击效果。           2)什么是CC攻击   　　 3)两者区别 DDoS是针对IP的攻击而CC攻击的是服务器资源。   四、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了。 鉴于此攻击简单的利用程度、拒绝服务的后果、带有逃逸特性的攻击方式这类攻击一炮而红成为众多攻击者的研究和利用对象。 　　2)慢速攻击的分类 发展到今天慢速攻击也多种多样其种类可分为以下几种 Slow headersWeb应用在处理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。 3)哪些服务器易被慢速攻击 慢速攻击主要利用的是thread-based架构的服务器的特性这种服务器会为每个新连接打开一个线程它会等待接收完整个HTTP头部才会释放连接。比如Apache会有一个超时时间来等待这种不完全连接默认是300s但是一旦接收到客户端发来的数据这个超时时间会被重置。正是因为这样攻击者可以很容易保持住一个连接因为攻击者只需要在即将超时之前发送一个字符便可以延长超时时间。而客户端只需要很少的资源便可以打开多个连接进而占用服务器很多的资源。 经验证Apache、httpd采用thread-based架构很容易遭受慢速攻击。而另外一种event-based架构的服务器比如nginx和lighttpd则不容易遭受慢速攻击。 4)如何防护慢速攻击 Apache服务器现在使用较多的有三种简单防护方式。 mod_reqtimeoutApache2.2.15后该模块已经被默认包含用户可配置从一个客户端接收HTTP头部和HTTPbody的超时时间和最小速率。如果一个客户端不能在配置时间内发送完头部或body数据服务器会返回一个408REQUEST TIME OUT错误。配置文件如下 IfModule mod_reqtimeout.c RequestReadTimeout header20-40,MinRate500 body20,MinRate500 /IfModule mod_qosApache的一个服务质量控制模块用户可配置各种不同粒度的HTTP请求阈值配置文件如下 IfModule mod_qos.c /# handle connections from up to 100000 different IPsQS_ClientEntries 100000/# allow only 50 connections per IPQS_SrvMaxConnPerIP 50/# limit maximum number of active TCP connections limited to 256MaxClients 256/# disables keep-alive when 180 (70%) TCP connections are occupiedQS_SrvMaxConnClose 180/# minimum request/response speed (deny slow clients blocking the server, keeping connections open without requesting anythingQS_SrvMinDataRate 150 1200 /IfModule mod_security一个开源的WAF模块有专门针对慢速攻击防护的规则配置如下 SecRule RESPONSE_STATUS “streq 408” “phase:5,t:none,nolog,pass, setvar:ip.slow_dos_counter1, expirevar:ip.slow_dos_counter60, 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配置 http {limit_req_zone $binary_remote_addr zoneone:10m rate1r/s;server {#限制每ip每秒不超过20个请求漏桶数burst为5#brust的意思就是如果第1秒、2,3,4秒请求为19个#第5秒的请求为25个是被允许的。#但是如果你第1秒就25个请求第2秒超过20的请求返回503错误。#nodelay如果不设置该选项严格使用平均速率限制请求数#第1秒25个请求时5个请求放到第2秒执行#设置nodelay25个请求将在第1秒执行。limit_req zoneone burst1 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 zoneone:10m rate1r/s;server {limit_req zoneone burst1 nodelay;} } ab测试结果如下所示 数据成功的请求数失败的请求数请求时间每秒成功的请求数110019438101.1950.98210017651100.6550.9939725735100.4240.96410126791100.0001.0159819051100.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 zoneone:10m rate1r/s;server {limit_req zoneone burst10 nodelay;} } 数据成功的请求数失败的请求数请求时间每秒成功的请求数111019042100.1441.09211122271101.7141.09311118466100.5041.10411116468101.2851.09511112770100.5961.10平均11017803100.788 1.09   从数据来看提高了burst值明显nginx成功的请求数上去了。 Nginx配置样本三 在样本二的基础上我们把nodelay去除掉 http {limit_req_zone $binary_remote_addr zoneone:10m rate1r/s;server {limit_req zoneone burst10;} } 数据成功的请求数失败的请求数请求时间每秒成功的请求数1960100.2231.092980100.2380.9731000100.7610.994960100.0740.955970100.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.站点突然间有了很多访问正常的新用户。 六、建议后续工作 保守站点应尽快进行服务能力升级。 积极尽所能追溯攻击者。 追溯攻击者 CCproxy-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头中还会带有RefererUserAgent等多项信息。遇到攻击时可以通过日志查看访问信息看攻击的流量是否有明显特征比如固定的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。   七、 简易CC攻击防御策略  确定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站点的访问从而达到防范攻击的目的。  转载于:https://www.cnblogs.com/wpjamer/p/9030259.html