CC 攻击可以归为 DDoS 攻击的一种。他们之间都原理都是一样的，即传送大量的请求资料来导致站群服务器拒绝服务，是一种连线攻击。 CC 攻击又可分为代理 CC 攻击，和肉鸡 CC 攻击。代理 CC 攻击是黑客借助代理站群服务器生成指向受害 WordPress 主机的合法 WordPress 网页请求，实现 DOS，和伪装就叫：cc（ChallengeCollapsar）。而肉鸡 CC 攻击是黑客使用 CC 攻击站群软件，控制大量肉鸡，发动攻击，相比来后者比前者更难防御。因为肉鸡可以模拟正常使用者访问网站的请求。伪造成合法资料包。防御 CC 攻击可以通过多种方法，禁止网站代理访问，尽量将网站做成静态页面，限制连线数量等。
Nginx 是一款轻量级的 Web 站群服务器，由俄罗斯的程式设计师 Igor Sysoev 所开发，最初供俄国大型的入口网站及搜寻引 Rambler 使用。 其特点是占有内存少，并发能力强，事实上 Nginx 的并发能力确实在同型别的网站站群服务器中表现较好。
Nginx 虽然可以比 Apache 处理更大的连线数，但是 HTTP GET FLOOD 针对的不仅仅是 WEB 站群服务器，还有资料库站群服务器。大量 HTTP 请求产生了大量的资料库查询，可以在几秒之内使资料库停止响应，系统负载升高，最终导致站群服务器当机。
本文主要介绍 CentOS+Nginx 下如何快速有效得防御 CC 攻击。至于如何安装 Nginx 就不详细介绍了，有兴趣的读者可以在 Nginx 官方网站（http://www.nginx.org/）下载原始码进行编译。如果你使用的是 Centos5，也可以使用 rpm 包进行安装（http://centos.alt.ru/repository/centos/5/i386/nginx-stable-0.7.65-1.el5.i386.rpm）。
主动抑制方法
为了让 Nginx 支援更多的并发连线数，根据实际情况对工作执行绪数和每个工作执行绪支援的最大连线数进行调整。例如设定 “worker_processes 10” 和 “worker_connections 1024”，那这台站群服务器支援的最大连线数就是 10×1024=10240 。
worker_processes 10;
events {
use epoll;
worker_connections 10240;
}
Nginx 0.7 开始提供了 2 个限制使用者连线的模组：NginxHttpLimitZoneModule 和 NginxHttpLimitReqModule 。 NginxHttpLimitZoneModule 可以根据条件进行并发连线数控制。
例如可以定义以下程式码：
http {
limit_zone my_zone $binary_remote_addr 10m;
server {
location /somedir/ {
limit_conn my_zone 1;
}
}
}
其中 “limit_zone my_zone $binary_remote_addr 10m” 的意思是定义一个名称为 my_zone 的储存区域、 my_zone 中的内容为远端 IP 地址、 my_zone 的大小为 10M；“location /somedir/” 的意思是针对 somedir 目录应用规则；“limit_conn my_zone 1” 的意思是针对上面定义的 my_zone 记录区记录的 IP 地址在指定的目录中只能建立一个连线。
NginxHttpLimitReqModule 可以根据条件进行请求频率的控制。例如可以定义以下程式码：
http {
limit_req_zone $binary_remote_addr zone=my_req_zone:10m rate=1r/s;
…
server {
…
location /somedir/ {
limit_req_zone zone= my_req_zone burst=2;
}
Discuz! 是使用比较多的一个 php 论坛程式。以 Discuz!7.0 为例，程式目录下有比较多的可以直接访问的 php 档案，但其中最容易受到攻击的一般有 index.php（首页）、 forumdisplay.php（板块显示）、 viewthread.php（帖子显示）。攻击者一般会对这些页面发起大量的请求，导致 HTTP 站群服务器连线数耗尽、 mysql 资料库停止响应，最终导致站群服务器崩溃。为了防止上述页面被攻击，我们可以设定以下的规则进行防御：
http {
limit_zone myzone_bbs $binary_remote_addr 10m;
limit_req_zone $binary_remote_addr zone=bbs:10m rate=1r/s;
…
server {
…
location ~ ^/bbs/(index|forumdisplay|viewthread).php$ {
limit_conn myzone_bbs 3;
limit_req zone=bbs burst=2 nodelay;
root html;
fastcgi_pass unix:/dev/shm/php-cgi.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /usr/share/nginx/html$fastcgi_script_name;
includefastcgi_params;
}
}
}
应用这条规则后，bbs 目录下的 index.php 、 forumdisplay.php 和 viewthread.php 这些页面同一个 IP 只许建立 3 个连线，并且每秒只能有 1 个请求（突发请求可以达到 2 个）。虽然这样的规则一般来说对正常的使用者不会产生影响（极少有人在 1 秒内开启 3 个页面），但是为了防止影响那些手快的使用者访问，可以在 nginx 中自定义 503 页面，503 页面对使用者进行提示，然后自动重新整理。在 Nginx 中自定义 503 页面：
error_page 503 /errpage/503.html;
503 页面的原始码：
< /table> 被动防御方法 #!/bin/sh 执行 crontab -e，将上述指令码新增到 crontab 每分钟自动执行： #tail /var/spool/mail/root 至此，又一次 HTTP GET FLOOD 防御成功。 if ($http_user_agent ~ must-revalidate) { 本文主要介绍了 nginx 下的 HTTP GET FLOOD 防御，如果有不对的地方，希望大家可以向我提出。同时，也希望大家能够举一反三，把这种思路应用到 apache 、 lighttpd 等常见的 web 站群服务器中。
< head>
< title>页面即将载入….
< meta http-equiv=content-type c>
< META NAME=”ROBOTS” C>
< /head>
< body bgcolor=”#FFFFFF”>
< table cellpadding=”0″ cellspacing=”0″ border=”0″ width=”700″ align=”center”height=”85%”>
< /body>
< /html>
< SCRIPT language=javascript>
function update()
{
window.location.reload();
}
setTimeout(“update()”,2000);
< /script>
虽然主动防御已经抵挡了大多数 HTTP GET FLOOD 攻击，但是道高一尺魔高一丈，攻击者会总会找到你薄弱的环节进行攻击。所以我们在这里也要介绍一下被动防御的一些方法。
封 IP 地址
访问者通过浏览器正常访问网站，与站群服务器建立的连线一般不会超过 20 个，我们可以通过指令码禁止连线数过大的 IP 访问。以下指令码通过 netstat 命令列举所有连线，将连线数最高的一个 IP 如果连线数超过 150，则通过 iptables 阻止访问：
status=`netstat -na|awk ‘$5 ~ /[0-9]+:[0-9]+/ {print $5}’ |awk -F “:” –‘{print $1}’ |sort -n|uniq -c |sort -n|tail -n 1`
NUM=`echo $status|awk ‘{print $1}’`
IP=`echo $status|awk ‘{print $2}’`
result=`echo “$NUM > 150” | bc`
if [ $result = 1 ]
then
echo IP:$IP is over $NUM, BAN IT!
/sbin/iptables -I INPUT -s $IP -j DROP
fi
* * * * * /root/xxxx.sh
通过 apache 自带的 ab 工具进行站群服务器压力测试：
# ab -n 1000 -c 100 http://www.xxx.com/bbs/index.php
测试完成后，我们就可以看到系统中有 IP 被封的提示：
Content-Type: text/plain; charset=ANSI_X3.4-1968
Auto-Submitted: auto-generated
X-Cron-Env:
X-Cron-Env:
X-Cron-Env: <;PATH=/usr/bin:/bin>
X-Cron-Env:
X-Cron-Env:
IP:58.246.xx.xx is over 1047, BAN IT!
根据特征码遮蔽请求（对 CC 攻击效果较好）
一般同一种 CC 攻击工具发起的攻击请求包总是相同的，而且和正常请求有所差异。当站群服务器遭遇 CC 攻击时，我们可以快速检视日志，分析其请求的特征，比如 User-agent 。下面的是某一次 CC 攻击时的 User-agent，Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0; MyIE 3.01)Cache-Control: no-store, must-revalidate 几乎没有正常的浏览器会在 User-agent 中带上 “must-revalidate” 这样的关键字。所以我们可以以这个为特征进行过滤，将 User-agent 中带有 “must-revalidate” 的请求全部拒绝访问：
return 403;
}
原文连结：http://www.centoscn.com/CentosSecurity/SoftSecurity/2015/0525/5528.html