CC ***的防御（－）通过 Cookie 抵挡 CC ***

转载:http://v2ex.com/t/260392#reply5

CC ***发生在 TCP/IP 协议的第七层，一般方式是在很短的时间里对网站发起大量请求，消耗目标服务器的资源，使目标网站负载过高而不能访问。

CC ***和 UDP Flood, TCP SYN Flood 这类位于 TCP/IP 第四层的***相比，对自己的资源消耗更少，对服务器的***强度更高，有四两拨千斤的效果。如果防御不好，呵呵，一台笔记本打垮一整个服务器集群也不是不可能。

而一般人对网络***是怎样进行的，以及怎样进行防御了解的都不多，这也就给了***者可乘之机。我这段时间在开发 VeryNginx ，对这部分正好有所研究。于是写成《 CC ***的防御》系列文章，主要探讨 CC ***的原理，以及一些可能的防御思路。希望能对大家有所帮助，如同在我无知的时候，互联网上其他无私分享知识给我的人一样。

文中描述的全部方法都已经编写成代码，并实际测试通过，包含在开源项目 VeryNginx 中。开箱即可使用，并且还包含其他诸多强大功能。

传送门: https://github.com/alexazhou/VeryNginx

***方式

为了进行防御，我们首先要了解我们对手的***方式。

通常发起 CC ***是使用专门的***工具，同时模拟成多个用户，向目标网站发起多个请求，一般这些软件为了防止地址被屏蔽，还内置通过代理***的功能。可以通过多个代理服务器对目标发起***，使封 IP 的防御方式变的失效。

防御思路

因为 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 需要满足以下几点要求

• 每个 IP ／客户端的 Token 不同

• 无法伪造

• 一致性，即对相同的客户端，每次生成的 Token 相同

Token 随 IP 地址变化是为了防止通过一台机器获取 Token 之后，再通过代理服务来进行***。一致性则是为了避免在服务器端需要存储已经生成的 Token 。

推荐使用以下算法生成 Token ，其中 Key 为服务器独有的保密字符串，这个算法生成的 Token 可以满足以上这些要求。

Token = Hash( UserAgent + client_ip + key )