浅谈CC攻击防御

CC攻击的原理就是攻击者控制某些主机不停地发大量数据包给对方服务器造成服务器资源耗尽，一直到宕机崩溃。CC主要是用来攻击页面的，每个人都有这样的体验：当一个网页访问的人数特别多的时候，打开网页就慢了.

CC就是模拟多个用户(多少线程就是多少用户)不停地进行访问那些需要大量数据操作(就是需要大量CPU时间)的页面，造成服务器资源的浪费，CPU长时间处于100%，永远都有处理不完的连接直至就网络拥塞，正常的访问被中止。

大家明白了的吧 如果这两个有固定的特征就可以直接用程序屏蔽了）

这里用useragent做了一个判断逻辑是这样的

缓存最近访问的二十条记录， 如果到了二十条就开始做对比，如果这二十条的user-agent 一样就把这个user-agent 给封了.

如果不一样就继续回到0 开始， 为了避免网站一个人访问的情况下误杀，加上一个时间判断效果最好 比如 三秒内。

上代码

这里缓存十条 最新的

 然后对比

计算时间差

我这里是根据实际情况判断的 （考虑到白名单， 黑名单， ip断等场景需要）

好了 userAgent 防御大概就说这么多。

上面也说了用userAgent可以根据情况来屏蔽， 但是这个玩意还是可以伪造的(ps： 虽然 比较困难)，如果伪造了我们就要像其它办法了；我们知道一般的

攻击软件一般来说功能都比较简单，只有固定的发包功能，是不支持完成的http协议的 而浏览器会完整的支持 Http 协议，我们可以利用这一点来进行一下防御。

用户初次访问的时候我们定义个规则 token（ps：这个应该是有唯一key 生成的），保存在 COOKIE 中作为 Token ，用户必须要带有正确的 Token 才可以访问后端服务。当用户第一次访问时，会

检测到用户的 COOKIE 里面并没有这个 Token ，则返回一个 302 重定向跳转，目标地址为当前页面，同时在返回的 Http 头中加入 ，对 COOKIE 进行设置，使用户带有这个 Token 。

客户端如果是一个正常的浏览器，那么就会支持 HTTP 头中的 SET COOKIE 和 302 重定向指令，将带上正确的 Token 再次访问页面，这时候后台检测到正确的 Token ，就会放行，

这之后用户的 Http 请求都会带有这个 Token ，所以并不会受到阻拦。客户端如果是 CC 软件，那么一般不会支持这些指令，那么就会一直被拦在最外层，并不会对服务器内部造成压力。

代码：

token 生成算法 大致这样    UserAgent + client_ip + key   这样就避免了无法伪造，保证了相同的客户端的 token　的一致性。

对 CC 攻击者来说，在使用固定或者唯一 Token 的情况下，攻击成本是有差别的。

很多攻击软件是可以设置 http 头的，如果使用固定 Token ，攻击者只需要在本机获取一次 Token ，然后设置好 http 头就可以直接发起攻击了，攻击成本低的可以,

但是如果使用可变 Token ，基本市面上所有 CC 软件全都无法使用了 ,我们这个就是可变的token (随 IP 地址变化是为了防止通过一台机器获取 Token 之后，再通过代理服务来进行攻击)

实际上 token 只能挡普通攻击，计算 token 这个事情本身就消耗 CPU 资源，攻击的时候为了省带宽也有只发不收，只要入口带宽没有被塞满，普通 cc 攻击都可以挡住。

但是如果暴力发包，只发不收的攻击来说，带宽都满了，并并不能通过这种方式进行防御。

弊端： 这样的token 对搜索引擎不够友好，这 token 校验第一波挡住的是搜索引擎的爬虫。所以，最好只是在被攻击的时候开启这个功能，平时关闭掉.

OTHER

如果你的网站是使用的是Nginx做的反向代理，那么可以利用Nginx原生的limit_req模块来针对请求进行限制，ngx_http_limit_req_module

总结：

综上所述：最好在受到攻击的时候才开启token。

ps: 并没有绝对的防御方式，我们所能做的也就是不断提高攻击者的成本。通过手段把不合法的流量拦住。

谢谢!