Nginx服务器防CC攻击设置

2016-06-16/0次

Nginx虽然可以比Apache处理更大的连接数，但是HTTP GET FLOOD针对的不仅仅是WEB服务器，还有数据库服务器。大量HTTP请求产生了大量的数据库查询，可以在几秒之内使数据库停止响应，系统负载升高，最终导致服务器当机。

1.主动抑制
为了让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;

						        }

						    }

						}

其中“limit_req_zone $binary_remote_addr zone=my_req_zone:10m rate=1r/s”的意思是定义一个名称为my_req_zone的存储区域，my_req_zone内容为远程IP地址，my_req_zone大小为10M，my_req_zone中的平均请求速率只能为1个每秒；“location /somedir/”的意思是针对somedir目录应用规则；“limit_req_zone zone= my_req_zone burst=2”的意思是针对上面定义的my_req_zone记录区记录的IP地址在请求指定的目录中的内容时最高2个每秒的突发请求速率。
当有连接触发上诉规则时，Nginx会报“503 Service Temporarily Unavailable”的错误，停止用户请求。返回一个503，对服务器来说影响不大，只占用一个nginx的线程而已，相对来说还是很划算的。
为了测试效果，我将以上代码放入Nginx的配置文件，并编写了一个php文件显示phpinfo；另外还写了一个html文件，其中嵌入了多个 iframe调用php文件。当我打开这个html文件了，可以看到只有一个iframe中的php文件正常显示了，其他的iframe都显示503错误。

2.被动防御
虽然主动防御已经抵挡了大多数HTTP GET FLOOD攻击，但是道高一尺魔高一丈，攻击者会总会找到你薄弱的环节进行攻击。所以我们在这里也要介绍一下被动防御的一些方法。

1)封IP地址
访问者通过浏览器正常访问网站，与服务器建立的连接一般不会超过20个，我们可以通过脚本禁止连接数过大的IP访问。
以下脚本通过netstat命令列举所有连接，将连接数最高的一个IP如果连接数超过150，则通过 iptables阻止访问：

						#!/bin/sh

						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

运行crontab -e，将上述脚本添加到crontab每分钟自动运行：
通过apache自带的ab工具进行服务器压力测试：
ab -n 1000 -c 100 http://www.xxx.com/bbs/index.php
测试完成后，我们就可以看到系统中有IP被封的提示：

						[root@xxxxxx ~]#tail /var/spool/mail/root

						Content-Type: text/plain; charset=ANSI_X3.4-1968

						Auto-Submitted: auto-generated

						X-Cron-Env: <SHELL=/bin/sh>

						X-Cron-Env: <HOME=/root>

						X-Cron-Env: <;PATH=/usr/bin:/bin>

						X-Cron-Env: <LOGNAME=root>

						X-Cron-Env: <USER=root>

						IP:58.246.xx.xx is over 1047, BAN IT!

至此，又一次HTTP GET FLOOD防御成功。

2)根据特征码屏蔽请求（对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”的请求全部拒绝访问：

						if ($http_user_agent ~ must-revalidate) {

						return 403;

						}

Nginx服务器防CC攻击设置

相关信息