0x00 CC攻击的基本原理
CC攻击利用代理服务器向网站发送大量需要较长计算时间的URL请求，如数据库查询等，导致服务器进行大量计算而很快达到自身的处理能力而形成DOS。而攻击者一旦发送请求给代理后就主动断开连接，因爲代理并不因爲客户端这边连接的断开就不去连接目标服务器。因此攻击机的资源消耗相对很小，而从目标服务器看来，来自代理的请求都是合法的。
以前防CC攻击的方法
为了防范CC，以前的方法一个是限制每个IP的连接数，这在地址范围很广阔的情况下比较难实现;二是限制代理的访问，因为一般的代理都会在HTTP头中带 X_FORWARDED_FOR字段，但也有局限，有的代理的请求中是不带该字段的，另外有的客户端确实需要代理才能连接目标服务器，这种限制就会拒绝一些正常用户访问。
CC攻击用硬防难防住
CC攻击比DDOS攻击更可怕的就是，CC攻击一般是硬防很难防止住的。
个人分析原因有三：
一、因为CC攻击来的IP都是真实的，分散的;
二、CC攻击的数据包都是正常的数据包;
三、CC攻击的请求，全都是有效的请求，无法拒绝的请求。
防CC攻击思路
防CC有效性在于攻击方不接受服务器回应的数据，发送完请求后就主动断开连接，因此要确认连接是否是CC，服务器端不立即执行URL请求命令，而是简单的返回一个页面转向的回应，回应中包含新的URL请求地址。如果是正常访问，客户端会主动再次连接到转向页面，对用户来说是透明的;而对于CC攻击者，由于不接收回应数据，因此就不会重新连接，服务器也就不需要继续进行操作。
0x01 验证浏览器行为
简易版
我们先来做个比喻。
社区在搞福利，在广场上给大家派发红包。而坏人派了一批人形的机器人(没有语言模块)来冒领红包，聪明工作人员需要想出办法来防止红包被冒领。
于是工作人员在发红包之前，会给领取者一张纸，上面写着“红包拿来”，如果那人能念出纸上的字，那么就是人，给红包，如果你不能念出来，那么请自觉。于是机器人便被识破，灰溜溜地回来了。
是的，在这个比喻中，人就是浏览器，机器人就是攻击器，我们可以通过鉴别cookie功能(念纸上的字)的方式来鉴别他们。下面就是nginx的配置文件写法。
if ($cookie_say != "hbnl"){ add_header Set-Cookie "say=hbnl"; rewrite .* "$scheme://$host$uri" redirect;}让我们看下这几行的意思，当cookie中say为空时，给一个设置cookie say为hbnl的302重定向包，如果访问者能够在第二个包中携带上cookie值，那么就能正常访问网站了，如果不能的话，那他永远活在了302中。你也可以测试一下，用CC攻击器或者webbench或者直接curl发包做测试，他们都活在了302世界中。
当然，这么简单就能防住了？当然没有那么简单。
增强版
仔细的你一定会发现配置文件这样写还是有缺陷。如果攻击者设置cookie为say=hbnl（CC攻击器上就可以这么设置），那么这个防御就形同虚设了。我们继续拿刚刚那个比喻来说明问题。
坏人发现这个规律后，给每个机器人安上了扬声器，一直重复着“红包拿来，红包拿来”，浩浩荡荡地又来领红包了。
这时，工作人员的对策是这样做的，要求领取者出示有自己名字的户口本，并且念出自己的名字，“我是xxx，红包拿来”。于是一群只会嗡嗡叫着“红包拿来”的机器人又被撵回去了。
当然，为了配合说明问题，每个机器人是有户口本的，被赶回去的原因是不会念自己的名字，虽然这个有点荒诞，唉。
