显然是网站受到的DDoS***。大家都有这样的经历,就是在访问某一公司网站或者论坛时,如果这个网站或者论坛流量比较大,访问的人比较多,打开页 面的速度会比较慢,对不?!一般来说,访问的人越多,网站或论坛的页面越多,数据库就越大,被访问的频率也越高,占用的系统资源也就相当可观,。
CC***是DDoS(分布式拒绝服务)的一种，相比其它的DDoS***CC似乎更有技术含量一些。这种***你见不到虚假IP，见不到特别大的异常流量， 但造成服务器无法进行正常连接，一条ADSL的普通用户足以挂掉一台高性能的Web服务器。由此可见其危害性，称其为“Web杀手”毫不为过。最让站长们 忧虑的是这种***技术含量不是很高，利用工具和一些IP代理，一个初、中级的电脑水平的用户就能够实施DDoS ***。
一、 CC***的原理：
CC***的原理就是***者控制某些主机不停地发大量数据包给对方服务器造成服务器资源耗尽，一直到宕机崩溃。CC主要是用来***页面的，每个人都有这样 的体验：当一个网页访问的人数特别多的时候，打开网页就慢了，CC就是模拟多个用户(多少线程就是多少用户)不停地进行访问那些需要大量数据操作(就是需 要大量CPU时间)的页面，造成服务器资源的浪费，CPU长时间处于100%，永远都有处理不完的连接直至就网络拥塞，正常的访问被中止。
假 设服务器A对Search.asp的处理时间需要0.01S(多线程只是时间分割,对结论没有影响),也就是说他一秒可以保证100个用户的Search 请求,服务器允许的最大连接时间为60s,那么使用CC模拟120个用户并发连接,那么经过 1分钟,服务器的被请求了7200次,处理了6000次,于是剩下了1200个并发连接没有被处理.有的朋友会说:丢连接!丢连接!问题是服务器是按先来 后到的顺序丢的,这1200个是在最后10秒的时候发起的,想丢?!还早,经过计算,服务器满负开始丢连接的时候,应该是有7200个并发连接存在队列, 然后服务器开始120个/秒的丢连接,发动的连接也是120个/秒,服务器永远有处理不完的连接,服务器的CPU 100%并长时间保持,然后丢连接的60秒服务器也判断处理不过来了,新的连接也处理不了,这样服务器达到了超级繁忙状态.
假设服务器处理 Search只用了0.01S,也就是10毫秒(这个速度你可以去各个有开放时间显示的论坛看看),使用的线程也只有120,很多服务器的丢连接时间远比 60S长,使用线程远比120多,可以想象可怕了吧,而且客户机只要发送了断开,连接的保持是代理做的,而且当服务器收到SQL请求,肯定会进入队列,不 论连接是否已经断开,而且服务器是并发的,不是顺序执行,这样使得更多的请求进入内存请求,对服务器负担更大。
二、CC***的种类：
CC***的种类有三种，直接***、代理***、僵尸网络***，直接***主要针对有重要缺陷的 WEB 应用程序，一般说来是程序写的有问题的时候才会出现这种情况，比较少见。僵尸网络***有点类似于 DDOS ***了，从 WEB 应用程序层面上已经无法防御，所以代理***是CC ***者一般会操作一批代理服务器，比方说 100 个代理，然后每个代理同时发出 10 个请求，这样 WEB 服务器同时收到 1000 个并发请求的，并且在发出请求后，立刻断掉与代理的连接，避免代理返回的数据将本身的带宽堵死，而不能发动再次请求，这时 WEB 服务器会将响应这些请求的进程进行队列，数据库服务器也同样如此，这样一来，正常请求将会被排在很后被处理，就象本来你去食堂吃饭时，一般只有不到十个人 在排队，今天前面却插了一千个人，那么轮到你的机会就很小很小了，这时就出现页面打开极其缓慢或者白屏。
三、 ***症状
CC***有一定的隐蔽性，那如何确定服务器正在遭受或者曾经遭受CC***呢?我们可以通过以下三个方法来确定。
1、 服务器端分析方法
（1）SYNFlood***判定
一 般遭受CC***时，Web服务器会出现80端口对外关闭的现象， 因为这个端口已经被大量的垃圾数据堵塞了正常的连接被中止了。我们可以通过在命令行下输入命令netstat -an来查看，如果看到比较多的SYN_send、SYN_RECEIVED 如下有大量显示雷同的连接记录基本就可以被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 ……
A：网上邻居->右键选“属性”->双击网卡，每秒收到的包数量大于500。
B：开始->程序->附件->命令提示符->C:\>netstat –na，观察到大量的SYN_RECEIVED的连接状态。
C：网线插上后，服务器立即凝固无法操作，拔出后有时可以恢复，有时候需要重新启动机器才可恢复。
（2）TCP多连接***判定
与WEB端口建立了几十个以上ESTABLISHED
打开记事本键入如下代码保存为CC.bat：
@echo off
time /t >>log.log
netstat -n -p tcp |find ":80">>Log.log
notepad log.log
exit
Linux
netstat -natl |grep :80 |wc -l
（3）查看系统日志
上 面的两种方法有个弊端，只可以查看当前的CC***，对于确定Web服务器之前是否遭受CC***就无能为力了，此时我们可以通过Web日志来查，因为Web 日志忠实地记录了所有IP访问Web资源的情况。通过查看日志我们可以Web服务器之前是否遭受CC***，并确定***者的IP然后采取进一步的措施。一般 CC***一个页面，基本为同一个URL，或者相同的HTTP_REFERER。
实际上，不使用网站卫士类、CDN的服务，直接通过分析网站日志，还是很容易分辨出哪个IP是CC***的，因为CC***毕竟是通过程序来抓取网页，与普通 浏览者的特性区别还是很大的，例如普通浏览者访问一个网页，必定会连续抓取网页的HTML文件、CSS文件、JS文件和图片等一系列相关文件，而CC*** 者仅仅只会抓取一个URL地址的文件，不会抓取其他类型的文件，其User Agent也大部分和普通浏览者不同，这就可以在服务器上很容易分辨出哪些访问者是CC***了，既然可以判断出***者的IP，那么预防措施就很简单，只需 要批量将这些IP屏蔽。
2、客户端现象
（1）用户无法访问网站页面或打开过程非常缓慢。
（2）正在访问的用户突然变得非常缓慢甚至中断。
四、 CC***防御策略
1、直接CC***：
特点：IP数量少，***发起***的IP与目标服务器的连接数量多
防御：限制每IP的TCP连接数，可在防火墙上做限制
2、代理***：
防御：
被动防御
1. 统计单位时间内单个 IP 的访问次数
2. 统计单位时间内单个 UA 的访问次数（针对火车头）
主动防御
1.302 跳转
2.js 跳转
3.cookie 验证 前两个没啥好说的，很简单的，着重说一下后面三个的实现方式
302跳转
302 跳转主要是对访问的ip随机的进行一次302跳转，而跳转的时候在原始url后面加上几个参数，一般抓取程序或者cc***不会去识别header，设定一 个阀值，当一个IP多次不跳转的时候就可以干掉他了。而如果成功进行了跳转的话，一般就可以认为是正常的用户，那么我们可以设置一个cookie值以及时 效，当然cookie的值是经过ip和一些特殊参数计算出来的，不能让别人给破解了，然后在这个时效内不会再对用户进行探测
js跳转
其实js跳转也跟上面类似，不过跳转的方式是通过js来进行的。当一个请求来的时候可以吐出一个简单的js跳转，然后再原始的url后面加上一些参数，接下来的一些验证什么的就跟上面302跳转一样了
cookie验证
cookie验证是当用户第一次访问的时候就给他种下cookie，并记录访问次数，如果第二次来访问没cookie的话可以再次尝试种cookie，当cookie回传失败次数大于某个阀值就可以干掉这个IP了。
其实这些都有现成的实现了，用的nginx+lua来实现的，项目地址是： HttpGuard 我给他加上了文件黑名单功能以及对UA的封锁
3、僵尸网络***
特点：
首先***者拥有一个流量巨大的网站，这个网站的流量，很可能是他花钱买回来的，当然也可能是他控制的肉鸡，在控制的肉鸡上面访问他的网站。***的网站首页 非常简单，但是在他的源代码中，却隐藏了达到上百个<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个请求来说，一天就是25920000个请求，再加上页面上的图片和其它文件等，估计就是上 亿个请求了。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连接罢了。
防御：
可通过HTTP_REFERER做限制
下面贴一段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) {
return 404;
}
然而当网站受到***时，大多数人想到的是-----快点找硬防，基本上都步了一个误区，就是认为网站或者服务器被***，购买硬件防火墙，什么事都万事大吉 了，实际上这样的想法是极端错误的。多年的统计数据表明，想彻底解CC***是几乎不可能的，就好比治疗感冒一样，我们可以治疗，也可以预防，但却无法根 治，但我们若采取积极有效的防御方法，则可在很大程度上降低或减缓生病的机率，防治DDOS***也是如此， 实际上比较理想解决方案应该是“软件+硬件”的解决方案。此方案对于资金较为充足的企业网站来说，这个方案适合他们；硬件在DDOS防护上有优势，软件 CC防护上有优势；