We are drowning in information and starving for knowledge.
CC攻击原理学习笔记
作为站长或者公司的网站的网管，什么最可怕？
　　显然是网站受到的DDoS攻击。大家都有这样的经历,就是在访问某一公司网站或者论坛时,如果这个网站或者论坛流量比较大,访问的人比较多,打开页面的速度会比较慢,对不?!一般来说,访问的人越多,网站或论坛的页面越多,数据库就越大,被访问的频率也越高,占用的系统资源也就相当可观,。
　　CC攻击是DDoS(分布式拒绝服务)的一种，相比其它的DDoS攻击CC似乎更有技术含量一些。这种攻击你见不到虚假IP，见不到特别大的异常流量，但造成服务器无法进行正常连接，一条ADSL的普通用户足以挂掉一台高性能的Web服务器。由此可见其危害性，称其为“Web杀手”毫不为过。最让站长们忧虑的是这种攻击技术含量不是很高，利用工具和一些IP代理，一个初、中级的电脑水平的用户就能够实施DDoS 攻击。
　　那么怎样保证这些网站服务器的安全呢？冰盾DDoS防火墙专家认为，防护CC攻击大家有必要了解CC攻击的原理及如果发现CC攻击和对其的防范措施（参阅：）。
一、 CC攻击的原理：
　　CC攻击的原理就是攻击者控制某些主机不停地发大量数据包给对方服务器造成服务器资源耗尽，一直到宕机崩溃。CC主要是用来攻击页面的，每个人都有这样的体验：当一个网页访问的人数特别多的时候，打开网页就慢了，CC就是模拟多个用户(多少线程就是多少用户)不停地进行访问那些需要大量数据操作(就是需要大量CPU时间)的页面，造成服务器资源的浪费，CPU长时间处于100%，永远都有处理不完的连接直至就网络拥塞，正常的访问被中止。
二、CC攻击的种类：
　　CC攻击的种类有三种，直接攻击，代理攻击，僵尸网络攻击，直接攻击主要针对有重要缺陷的 WEB 应用程序，一般说来是程序写的有问题的时候才会出现这种情况，比较少见。僵尸网络攻击有点类似于 DDOS 攻击了，从 WEB 应用程序层面上已经无法防御，所以代理攻击是CC 攻击者一般会操作一批代理服务器，比方说 100 个代理，然后每个代理同时发出 10 个请求，这样 WEB 服务器同时收到 1000 个并发请求的，并且在发出请求后，立刻断掉与代理的连接，避免代理返回的数据将本身的带宽堵死，而不能发动再次请求，这时
WEB 服务器会将响应这些请求的进程进行队列，数据库服务器也同样如此，这样一来，正常请求将会被排在很后被处理，就象本来你去食堂吃饭时，一般只有不到十个人在排队，今天前面却插了一千个人，那么轮到你的机会就很小很小了，这时就出现页面打开极其缓慢或者白屏。
三、 攻击症状
　　CC攻击有一定的隐蔽性，那如何确定服务器正在遭受或者曾经遭受CC攻击呢?我们可以通过以下三个方法来确定。
　　(1).命令行法
　　一般遭受CC攻击时，Web服务器会出现80端口对外关闭的现象， 因为这个端口已经被大量的垃圾数据堵塞了正常的连接被中止了。我们可以通过在命令行下输入命令netstat -an来查看，如果看到类似如下有大量显示雷同的连接记录基本就可以被CC攻击了：
　　TCP 192.168.1.3:80 192.168.1.6:2205 SYN_RECEIVED 4
　　TCP 192.168.1.3:80 192.168.1.6: 2205 SYN_RECEIVED 4
　　TCP 192.168.1.3:80 192.168.1.6: 2205 SYN_RECEIVED 4
　　TCP 192.168.1.3:80 192.168.1.6: 2205 SYN_RECEIVED 4
TCP 192.168.1.3:80 192.168.1.6: 2205 SYN_RECEIVED 4 ……
其中“192.168.1.6”就是被用来代理攻击的主机的IP，“SYN_RECEIVED”是TCP连接状态标志，意思是“正在处于连接的初始同步状态 ”，表明无法建立握手应答处于等待状态。这就是攻击的特征，一般情况下这样的记录一般都会有很多条，表示来自不同的代理IP的攻击。
(2).批处理法
　　上述方法需要手工输入命令且如果Web服务器IP连接太多看起来比较费劲，我们可以建立一个批处理文件，通过该脚本代码确定是否存在CC攻击。打开记事本键入如下代码保存为CC.bat：
　　time /t &&log.log
　　netstat -n -p tcp |find ":80"&&Log.log
　　notepad log.log
上面的脚本的含义是筛选出当前所有的到80端口的连接。当我们感觉服务器异常是就可以双击运行该批处理文件，然后在打开的log.log文件中查看所有的连接。如果同一个IP有比较多的到服务器的连接，那就基本可以确定该IP正在对服务器进行CC攻击。
(3).查看系统日志
　　上面的两种方法有个弊端，只可以查看当前的CC攻击，对于确定Web服务器之前是否遭受CC攻击就无能为力了，此时我们可以通过Web日志来查，因为Web日志忠实地记录了所有IP访问Web资源的情况。通过查看日志我们可以Web服务器之前是否遭受CC攻击，并确定攻击者的IP然后采取进一步的措施。
　　Web日志一般在C:\WINDOWS\system32\LogFiles\HTTPERR目录下，该目录下用类似httperr1.log的日志文件，这个文件就是记录Web访问错误的记录。管理员可以依据日志时间属性选择相应的日志打开进行分析是否Web被CC攻击了。默认情况下，Web日志记录的项并不是很多，我们可以通过IIS进行设置，让Web日志记录更多的项以便进行安全分析。其操作步骤是：
　　“开始→管理工具”打开“Internet信息服务器”，展开左侧的项定位到到相应的Web站点，然后右键点击选择“属性”打开站点属性窗口，在“网站”选项卡下点击“属性”按钮，在“日志记录属性”窗口的“高级”选项卡下可以勾选相应的“扩展属性”，以便让Web日志进行记录。比如其中的“发送的字节数”、“接收的字节数”、“所用时间”这三项默认是没有选中的，但在记录判断CC攻击中是非常有用的，可以勾选。另外，如果你对安全的要求比较高，可以在“常规”选项卡下对“新日志计划”进行设置，让其“每小时”或者“每一天”进行记录。为了便于日后进行分析时好确定时间可以勾选“文件命名和创建使用当地时间”。
四、 CC攻击防御策略
确定Web服务器正在或者曾经遭受CC攻击，那如何进行有效的防范呢?
(1).取消域名绑定
　　一般cc攻击都是针对网站的域名进行攻击，比如我们的网站域名是“www.abc.com”，那么攻击者就在攻击工具中设定攻击对象为该域名然后实施攻击。
对于这样的攻击我们的措施是在IIS上取消这个域名的绑定，让CC攻击失去目标。具体操作步骤是：打开“IIS管理器”定位到具体站点右键“属性”打开该站点的属性面板，点击IP地址右侧的“高级”按钮，选择该域名项进行编辑，将“主机头值”删除或者改为其它的值(域名)。
经过模拟测试，取消域名绑定后Web服务器的CPU马上恢复正常状态，通过IP进行访问连接一切正常。但是不足之处也很明显，取消或者更改域名对于别人的访问带来了不变，另外，对于针对IP的CC攻击它是无效的，就算更换域名攻击者发现之后，他也会对新域名实施攻击。
(2).域名欺骗解析
　　如果发现针对域名的CC攻击，我们可以把被攻击的域名解析到127.0.0.1这个地址上。我们知道127.0.0.1是本地回环IP是用来进行网络测试的，如果把被攻击的域名解析到这个IP上，就可以实现攻击者自己攻击自己的目的，这样他再多的肉鸡或者代理也会宕机，让其自作自受。
另外，当我们的Web服务器遭受CC攻击时把被攻击的域名解析到国家有权威的政府网站或者是网警的网站，让其网警来收拾他们。
现在一般的Web站点都是利用类似“新网”这样的服务商提供的动态域名解析服务，大家可以登录进去之后进行设置。
(3).更改Web端口
　　一般情况下Web服务器通过80端口对外提供服务，因此攻击者实施攻击就以默认的80端口进行攻击，所以，我们可以修改Web端口达到防CC攻击的目的。运行IIS管理器，定位到相应站点，打开站点“属性”面板，在“网站标识”下有个TCP端口默认为80，我们修改为其他的端口就可以了。
(4).IIS屏蔽IP
　　我们通过命令或在查看日志发现了CC攻击的源IP，就可以在IIS中设置屏蔽该IP对Web站点的访问，从而达到防范IIS攻击的目的。在相应站点的“属性”面板中，点击“目录安全性”选项卡，点击“IP地址和域名现在”下的“编辑”按钮打开设置对话框。在此窗口中我们可以设置“授权访问”也就是“白名单”，也可以设置“拒绝访问”即“黑名单”。比如我们可以将攻击者的IP添加到“拒绝访问”列表中，就屏蔽了该IP对于Web的访问。
五、针对CC攻击的商业解决方案
　　很多的网站管理者是等到网站遭到攻击了，受到损失了，才去寻求解决的方案，在将来的互联网飞速发展的时代，一定要有安全隐患意识，不要等到损失大了，再去想办法来补救，这样为时已晚。
　　然而当网站受到攻击时，大多数人想到的是-----快点找硬防，基本上都步了一个误区，就是认为网站或者服务器被攻击，购买硬件防火墙，什么事都万事大吉了，实际上这样的想法是极端错误的。多年的统计数据表明，想彻底解CC攻击是几乎不可能的，就好比治疗感冒一样，我们可以治疗，也可以预防，但却无法根治，但我们若采取积极有效的防御方法，则可在很大程度上降低或减缓生病的机率，防治DDOS攻击也是如此， 实际上比较理想解决方案应该是“软件+硬件”的解决方案。此方案对于资金较为充足的企业网站来说，这个方案适合他们；硬件在DDOS防护上有优势，软件CC防护上有优势；
　　相对于一些对于ICP内容网站、论坛社区BBS、电子商务eBusiness、音乐网站Music、电影网站File等网站服务器越来越普及，但由于种种原因往往会遭受竞争对手或打击报复者的恶意DDOS攻击，持续的攻击会导致大量用户流失，严重的甚至因人气全失而被迫关闭服务器，为了最大程度的保护运营者的利益，冰盾科技结合多年抗DDOS的实践经验给出了最少的安全投资可获得最大安全回报的抗DDOS解决方案。
首先攻击者拥有一个流量巨大的网站，这个网站的流量，很可能是他花钱买回来的，当然也可能是他控制的肉鸡，在控制的肉鸡上面访问他的网站。黑客的网站首页非常简单，但是在他的源代码中，却隐藏了达到上百个&iframe&标签。对！聪明的你，应该想得出他的&iframe&标签里面放的是什么了吧？没错！他的&iframe&里面，放的就是他要攻击的网站的地址。
举一个例子来说明一下攻击者的威力，假设黑客的网站是aaa.com，你的网站是BBB.com。如果有人在163的首页代码中，有这么一段：&iframe src="http://aaa.com" border="0" width="0" height="0"&&/iframe&，那么在所有人访问163的主页时，也会不知不觉的访问http://aaa.com。然后http://aaa.com的首页中可能有100个如下的代码：&iframe src=http://BBB.com border="0"
width="0" height="0"&&/iframe&，当然他还可能放上bbb.com这个网站十个甚至更多不同的地址。那就表明：凡是有一个人访问了163，就可能会访问BBB.com十次。以每秒300个请求来说，一天就是个请求，再加上页面上的图片和其它文件等，估计就是上亿个请求了。1天上亿个请求，普通的网站受得了吗？有很多被攻击的网站用的是虚拟主机，每秒不到100个连接可能就无法提供服务了。即使是那种单独几台服务器的网站，也根本就无法承受！即使WEB Server可以承受，那带宽呢？即使带宽可以承受，那么Db
Server呢？
朋友的网站就受到此种攻击，他试着将网站转移到他朋友的服务器上面，当然最后的结果还是照样拖累他朋友的服务器瘫痪。
这种就是是典型的CC攻击。CC攻击比DDOS攻击更可怕的就是，CC攻击一般是硬防很难防止住的。为什么呢？一、因为CC攻击来的IP都是真实的，分散的；二、CC攻击的数据包都是正常的数据包；三、CC攻击的请求，全都是有效的请求，无法拒绝的请求。
其实只要仔细研究了一下这种攻击的模式，发现这种攻击，理论上是可以防止的，即只要通过有效的手段，完全可以将危害降低到最轻。因为这种攻击有一个致命的弱点。它致命的弱点在哪里呢？当然就是在&iframe&上面。通过&iframe&进行CC攻击，攻击者的想法和创意，确实很让人惊叹，但这正好造成了他的完美失败。熟悉网页程序的朋友应该都知道，用&iframe&嵌入的网页，自然都会有HTTP_REFERER值，而有了这个值，从这个值上面屏蔽或是转发掉来源的网站即可。也就是说，你可以访问我，但是我不将真实的页面返回给你，我可以把你随意打发掉，或是将你随意转到另外一个网站上去（如：公安部？哈哈，我就见过有人类似这样做的），这样我就可以大量的节省我的带宽、我的DB
Server资源、我的Web Server资源。你最多就是占用了我大量的TCP连接罢了。
下面贴一段Web server的配置代码，用于解决此类攻击：
valid_referers none blocked server_names google.com google.cn *.google.com *.google.cn baidu.com *.baidu.com *.你自己的域名(在这里还可以加入其他的，比如说SOSO，YAHOO，SOGOU YOUDAO等);
if ($invalid_referer) {
上面的代码，很简单的设置了，只要不是HTTP_REFERER来源于上面设置网址来源的请求，通通转发至404。
CC攻击大家都懂的，就是消耗服务器资源，资源，可以是哪些？
1.CPU，2.内存，3.网络，4.连接，5.数据库资源，6.服务应用池，7.。。。。
CC攻击，就是伪造N多请求，瞬间同时访问。可以造成服务端溢出、报错、系统崩溃、硬盘烧坏、网卡发热、数据库不能连接、查询、内存溢出。
另外，32位系统最多占用4G内存也是一个瓶颈【所以建议大内存VPS/独服装64BIT】。
解决办法：
烧钱，砸硬防。
如果资金不充裕，或者处于创业成长期，可以考虑下面几处：
1.升级服务器（哪是瓶颈就升哪里）。
2.优化程序，数据库使用NOSQL【非查询式数据库】，比如memcached。
3.前端使用一部分防火墙规则，注意最好使用被动防御【有攻击了再启动规则】。
别信啥CDN可防C的。除非他家是GOV开的，否则他砸不起这钱。
我们公司用的CHINACACHE，可是有屁防C的功能。
这里主要讲解一下针对数据库瓶颈的CC攻击。
比如一search.php?keyword=1992year，查询一次需要0.01秒，那么查询100次就可以占满1秒 CPU时间，如果再加大并发量，
比如加大10倍，那么这些请求就得排队让CPU处理 10秒钟。
这就是一种CC攻击。当然也可以有大便那种60万并发的CC，静态页面都能C死，当然这除了砸钱是无解的，我们讨论也没意义。
传统CC针对的瓶颈主要就是数据库查询瓶颈。
应对：memcached【内存缓存】
比如，查询 search.php?keyword=1992year，就可以
$mem-&set("search_keyword_".md5($_GET['keyword']),$mysql_data,600)将查询得到的数据缓存在内存中，
600是指过期时间，是指在10分钟过后，缓存可能会被新插入的缓存覆盖。
这样，如果内存不出现瓶颈，数据库压力可以被分担很多。
但。。。新的问题又来了，每个请求keyword不同，那么不也同样可以C死？
所以，必需限制总的处理量
用nginx_limit_req，将seach.php为key，把search.php总的【非单IP】并发限制在5个/秒。
超时弹回一个php js算法验证【有效期一次】，
这样，就算SEARCH.PHP被C住，也影响不大。
最重要的，还是那句话：千万别装B，装B遭雷P。
转自：http://www.hostloc.com/thread--2.html
http://www.admin5.com/article/695.shtml
http://www.bingdun.com/cc/1158.htm
没有更多推荐了，一、 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)慢速攻击的分类
发展到今天，慢速攻击也多种多样，其种类可分为以下几种：
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。
　　3)哪些服务器易被慢速攻击
慢速攻击主要利用的是thread-based架构的服务器的特性，这种服务器会为每个新连接打开一个线程，它会等待接收完整个HTTP头部才会释放连接。比如Apache会有一个超时时间来等待这种不完全连接（默认是300s），但是一旦接收到客户端发来的数据，这个超时时间会被重置。正是因为这样，攻击者可以很容易保持住一个连接，因为攻击者只需要在即将超时之前发送一个字符，便可以延长超时时间。而客户端只需要很少的资源，便可以打开多个连接，进而占用服务器很多的资源。
经验证，Apache、httpd采用thread-based架构，很容易遭受慢速攻击。而另外一种event-based架构的服务器，比如nginx和lighttpd则不容易遭受慢速攻击。
　　4)如何防护慢速攻击
Apache服务器现在使用较多的有三种简单防护方式。
mod_reqtimeout：Apache2.2.15后，该模块已经被默认包含，用户可配置从一个客户端接收HTTP头部和HTTPbody的超时时间和最小速率。如果一个客户端不能在配置时间内发送完头部或body数据，服务器会返回一个408REQUEST TIME OUT错误。配置文件如下：
& IfModule mod_reqtimeout.c &
RequestReadTimeout header=<span style="color: #-<span style="color: #,MinRate=<span style="color: #0 body=<span style="color: #,MinRate=<span style="color: #0
& /IfModule &
mod_qos：Apache的一个服务质量控制模块，用户可配置各种不同粒度的HTTP请求阈值，配置文件如下：
& IfModule mod_qos.c &
/# handle connections from up to <span style="color: #0000 different IPs
QS_ClientEntries <span style="color: #0000
/# allow only <span style="color: # connections per IP
QS_SrvMaxConnPerIP <span style="color: #
/# limit maximum number of active TCP connections limited to <span style="color: #6
MaxClients <span style="color: #6
/# disables keep-alive when <span style="color: #0 (<span style="color: #%) TCP connections are occupied
QS_SrvMaxConnClose <span style="color: #0
/# minimum request/response speed (deny slow clients blocking the server, keeping connections open without requesting anything
QS_SrvMinDataRate <span style="color: #0 <span style="color: #00
& /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:’′”
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:’′”
传统的流量清洗设备针对CC攻击，主要通过阈值的方式来进行防护，某一个客户在一定的周期内，请求访问量过大，超过了阈值，清洗设备通过返回验证码或者JS代码的方式。这种防护方式的依据是，攻击者们使用肉鸡上的DDoS工具模拟大量http request，这种工具一般不会解析服务端返回数据，更不会解析JS之类的代码。因此当清洗设备截获到HTTP请求时，返回一段特殊JavaScript代码，正常用户的浏览器会处理并正常跳转不影响使用，而攻击程序会攻击到空处。
而对于慢速攻击来说，通过返回验证码或者JS代码的方式依然能达到部分效果。但是根据慢速攻击的特征，可以辅助以下几种防护方式：1、周期内统计报文数量。一个TCP连接，HTTP请求的报文中，报文过多或者报文过少都是有问题的，如果一个周期内报文数量非常少，那么它就可能是慢速攻击；如果一个周期内报文数量非常多，那么它就可能是一个CC攻击。2、限制HTTP请求头的最大许可时间。超过最大许可时间，如果数据还没有传输完成，那么它就有可能是一个慢速攻击。
简单的Nginx防CC方式&
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
#限制每ip每秒不超过20个请求，漏桶数burst为5
#brust的意思就是，如果第1秒、<span style="color: #,<span style="color: #,4秒请求为19个，
#第5秒的请求为25个是被允许的。
#但是如果你第1秒就25个请求，第2秒超过20的请求返回503错误。
#nodelay，如果不设置该选项，严格使用平均速率限制请求数，
#第1秒25个请求时，5个请求放到第2秒执行，
#设置nodelay，25个请求将在第1秒执行。
burst=<span style="color: #
上面样本的配置是什么意思呢？
$binary_remote_addr 表示：客户端IP地址
zone 表示漏桶的名字
rate 表示nginx处理请求的速度有多快
burst 表示峰值
nodelay 表示是否延迟处理请求，还是直接503返回给客户端，如果超出rate设置的情况下。
详细的可以参考官方说明文档：
这里我们需要Apache Benchmark这个小工具来生成请求
//<span style="color: #个用户持续100s的时间向服务器发送请求
ab -t <span style="color: #0 -c <span style="color: # -vvv http://example.com/
Nginx配置样本一
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
burst=<span style="color: #
ab测试结果如下所示：
数据成功的请求数失败的请求数请求时间每秒成功的请求数
以上失败的请求在Nginx上生成的错误日志如下显示
<span style="color: #15/<span style="color: #/<span style="color: # <span style="color: #:<span style="color: #:<span style="color: # [error] <span style="color: #64#<span style="color: #: *<span style="color: #19 limiting requests, excess: <span style="color: #.273 by zone "one", client: <span style="color: #.0.<span style="color: #.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com"
<span style="color: #15/<span style="color: #/<span style="color: # <span style="color: #:<span style="color: #:<span style="color: # [error] <span style="color: #64#<span style="color: #: *<span style="color: #20 limiting requests, excess: <span style="color: #.272 by zone "one", client: <span style="color: #.0.<span style="color: #.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com"
<span style="color: #15/<span style="color: #/<span style="color: # <span style="color: #:<span style="color: #:<span style="color: # [error] <span style="color: #64#<span style="color: #: *<span style="color: #21 limiting requests, excess: <span style="color: #.271 by zone "one", client: <span style="color: #.0.<span style="color: #.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com"
<span style="color: #15/<span style="color: #/<span style="color: # <span style="color: #:<span style="color: #:<span style="color: # [error] <span style="color: #64#<span style="color: #: *<span style="color: #22 limiting requests, excess: <span style="color: #.270 by zone "one", client: <span style="color: #.0.<span style="color: #.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com"
<span style="color: #15/<span style="color: #/<span style="color: # <span style="color: #:<span style="color: #:<span style="color: # [error] <span style="color: #64#<span style="color: #: *<span style="color: #23 limiting requests, excess: <span style="color: #.269 by zone "one", client: <span style="color: #.0.<span style="color: #.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com"
<span style="color: #15/<span style="color: #/<span style="color: # <span style="color: #:<span style="color: #:<span style="color: # [error] <span style="color: #64#<span style="color: #: *<span style="color: #24 limiting requests, excess: <span style="color: #.268 by zone "one", client: <span style="color: #.0.<span style="color: #.2, server: example.com, request: "GET / HTTP/1.0", host: "example.com"
如上ab测试中如果是失败的请求，nginx的limit_req模块会统一返回503给客户端，浏览器上面显示的是这个样子的。
Nginx配置样本二
在配置二里面，我把burst（峰值）提高到了10
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
burst=<span style="color: #
数据成功的请求数失败的请求数请求时间每秒成功的请求数
从数据来看，提高了burst值，明显nginx成功的请求数上去了。
Nginx配置样本三
在样本二的基础上，我们把nodelay去除掉
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
burst=<span style="color: #;
数据成功的请求数失败的请求数请求时间每秒成功的请求数
从这里的数据可以看到将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。
七、 简易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站点的访问，从而达到防范攻击的目的。
文章 - 130}