nginx防DDos

nginx 上有两个限制连接的模块一个是 limit_zone 另一个是 limie_req_zone,两个都可以限制连接，但具体有什么不同呢？
下面是 nginx 官网上给的解释
limit_req_zone
Limit frequency of connections from a client.
This module allows you to limit the number of requests for a given session, or as a special case, with one address.
Restriction done using leaky bucket.

limit_zone
Limit simultaneous connections from a client.
This module makes it possible to limit the number of simultaneous connections for the assigned session or as a special case, from one address.

按照字面的理解，lit_req_zone的功能是通过 令牌桶原理来限制 用户的连接频率，(这个模块允许你去限制单个地址 指定会话或特殊需要 的请求数 )
而 limit_zone 功能是限制一个客户端的并发连接数。(这个模块可以限制单个地址 的指定会话 或者特殊情况的并发连接数)
一个是限制并发连接一个是限制连接频率，表面上似乎看不出来有什么区别，那就看看实际的效果吧~~~
在我的测试机上面加上这两个参数下面是我的部分配置文件
http{
limit_zone one  $binary_remote_addr  10m;
#limit_req_zone  $binary_remote_addr  zone=req_one:10m rate=1r/s;
server
{
......
limit_conn   one  1;
#limit_req   zone=req_one  burst=120;
......
}
}

解释一下 limit_zone one  $binary_remote_addr  10m;
这里的 one 是声明一个 limit_zone 的名字，$binary_remote_addr是替代 $remore_addr 的变量，10m 是会话状态储存的空间
limit_conn one 1 ,限制客户端并发连接数量为1
先测试 limit_zone 这个模块
我找一台机器 用ab 来测试一下 命令格式为
ab -c 100 -t 10 http://192.168.6.26/test.php

test.php 内容是phpinfo
看看日志里的访问

似乎随着数量的增多效果也会发生一些变化，并不是完全达到模块说明中的效果
看看当前的tcp连接数
# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 29
FIN_WAIT1 152
FIN_WAIT2 2
ESTABLISHED 26
SYN_RECV 16

这次测试下 limit_req_zone,配置文件稍微改动一下
http{
#limit_zone one  $binary_remote_addr  10m;
limit_req_zone  $binary_remote_addr  zone=req_one:10m rate=1r/s;
server
{
......
#limit_conn   one  1;
limit_req   zone=req_one  burst=120;
......
}
}
restart 一下 nginx
简单说明一下， rate=1r/s 的意思是每个地址每秒只能请求一次，也就是说根据令牌桶(经过网友冰冰的指正应该是漏桶原理)原理 burst=120 一共有120块令牌，并且每秒钟只新增1块令牌，
120块令牌发完后 多出来的那些请求就会返回503
测试一下
ab -c 100 -t 10 http://192.168.6.26/test.php
看看这时候的访问日志

确实是每秒请求一次，那多测试一会儿呢？把时间从10秒增加到30秒

这个时候应该是120 已经不够用了，出现很多503，还有两种情况会出现,请看图

客户端自己等不及断开了，返回499
看看当前的tcp连接数
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 51
FIN_WAIT1 5
ESTABLISHED 155
SYN_RECV 12

虽然这样会让nginx 一秒钟只处理一个请求，但是仍然会有很多还在队列里面等待处理，这样也会占用很多tcp连接，从上面那条命令的结果中就能看得出来。
如果这样呢
limit_req   zone=req_one  burst=120 nodelay;
加上 nodelay之后超过 burst大小的请求就会直接 返回503，如图

<a href="http://blog.goyiyo.com/wp-content/uploads/2014/03/7.jpg" class="cboxElement" rel="example4" 1941"="" style="text-decoration: none; color: rgb(1, 150, 227);">

也是每秒处理1个请求，但多出来的请求没有象刚才那样等待处理，而是直接返回503。
当前的tcp连接
# netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'
TIME_WAIT 30
FIN_WAIT1 15
SYN_SENT 7
FIN_WAIT2 1
ESTABLISHED 40
SYN_RECV 37

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每分钟自动运行：
* * * * * /root/xxxx.sh
通过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下的HTTP GET FLOOD防御，如果有不对的地方，希望大家可以向我提出。同时，也希望大家能够举一反三，把这种思路应用到apache、lighttpd等常见的web服务器中。