来自218.30.117.72的黑客攻击想到的nginx ip 限制方法

笔者比较懒，因此网站流量也不高，这样的小站从2010年建立以来受到的黑客攻击次数寥寥无几。今天，无意中查看了下网站日志，发现几乎每秒都有2-3web个请求，这和博客的流量不相符合，于是赶紧翻看日志仔细看看，果然，受到来自IP地址218.30.117.72的肆意黑客攻击，从下午18点开始一直到晚上22点笔者发现之前，总共接收到来自这个ip的26373条请求。基本上都是采用web请求方式提交sql、获取root shell等等。解决办法很简单iptables+nginx ip 限制 模块

使用goaccess统计日志文件的结果果然很邪恶啊～～～

goaccess -f access.log

goaccess统计结果

对于这种暴力破解解决办法也很简单，使用iptables直接限制该IP地址即可：

iptables -I INPUT -s 218.30.117.72 -j DROP
service iptables save
service iptables restart

当然，我们要有防患于未燃的意识，nginx服务器有两个模块有限制ip地址并发连接数、下载速度（http_limit_conn_module

）、以及限制ip地址web请求速率的模块(http_limit_req_module)。
limit_conn_module 的用法比较简单主要有两个，它可以用在http server location作用域中，具体其他的用法可以参考官方手册。

server {
limit_conn one 20;          #连接数限制
limit_rate 500k;            #带宽限制,对单个连接限数，如果一个ip两个连接，就是500x2k
}

下面着重说下limit_req_module，它允许针对来自单个请求ip地址上处理的用户请求速率进行限制，限制将基于特定key进行。限制是通过使用“漏桶”的方法。

（漏桶算法(Leaky Bucket)是网络世界中流量整形（Traffic Shaping）或速率限制（Rate Limiting）时经常使用的一种算法，它的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。

WIKI：

http://wiki.nginx.org/HttpLimitReqModule

漏桶原理（leaky bucket）：

http://en.wikipedia.org/wiki/Leaky_bucket

实例：

#以用户二进制IP地址，定义三个漏桶，滴落速率1-3req/sec，桶空间1m，1M能保持大约16000个(IP)状态
limit_req_zone  $binary_remote_addr  zone=qps1:1m   rate=1r/s;
limit_req_zone  $binary_remote_addr  zone=qps2:1m   rate=2r/s;
limit_req_zone  $binary_remote_addr  zone=qps3:1m   rate=3r/s;

server {

#速率qps=1，峰值burst=5，延迟请求
#严格按照漏桶速率qps=1处理每秒请求
#在峰值burst=5以内的并发请求，会被挂起，延迟处理
#超出请求数限制则直接返回503
#客户端只要控制并发在峰值[burst]内，就不会触发limit_req_error_log
# 例1：发起一个并发请求=6，拒绝1个，处理1个，进入延迟队列4个：
#time    request    refuse    sucess    delay
#00:01        6        1        1            4
#00:02        0        0        1            3
#00:03        0        0        1            2
#00:04        0        0        1            1
#00:05        0        0        1            0
location /delay {
limit_req zone=qps1 burst=5;
}

#速率qps=1，峰值burst=5，不延迟请求
#加了nodelay之后，漏桶控制一段时长内的平均qps = 漏桶速率，允许瞬时的峰值qps > 漏桶qps
#所以峰值时的最高qps=(brust+qps-1)=5
#请求不会被delay，要么处理，要么直接返回503
#客户端需要控制qps每秒请求数，才不会触发limit_req_error_log
# 例2：每隔5秒发起一次达到峰值的并发请求，由于时间段内平均qps=1 所以仍然符合漏桶速率：
#time    request refuse    sucess
#00:01         5         0          5
#00:05         5         0          5
#00:10         5         0          5
# 例3：连续每秒发起并发请求=5，由于时间段内平均qps>>1，超出的请求被拒绝：
#time    request refuse     sucess
#00:01         5         0           5
#00:02         5         4           1
#00:03         5         4           1

location /nodelay {
limit_req zone=qps1 burst=5 nodelay;
}

}