晚上23点左右收到大量的监控报警,公司网站直接不能访问了,立即登录服务器,直接top看到情况如下:
发现负载都达到了800了,机器眼看就要爆了,首先先停了mysql,发现负载有点下降,联系了开发同事一同查看,因为今天新上线了一些代码,可能是新上代码的问题,随后看到负载依然没降,然后将php和nginx都重启了,虽然短暂的降了一些,过一会立马负载又起来了,这时看了下nginx日志,看是不是用户访问导致的问题,结果一看就发现问题了,如下:
30分钟发了60w+的请求。
发现这个ip不停的发请求,很明显,是被***了,临时将这个ip在nginx中deny掉,直接返回给它503,配置如下:在server中加入
负载也慢慢降下来了,服务也正常了,当时太晚了,洗洗就睡了,结果第二天早上一来又发现网站打不开了,直接看nginx日志,***者换了一个ip,跟昨晚的现象一样,这次直接在源头把他干掉了,就是添加iptables,如下:
将***的ip全部写入iptables里面,然后联系机房看能不能做策略协助解决这种CC***,最后机房那边也将这些ip给封了,但是***者在换ip怎么办?不可能他换一个我加一条把,看来只能发大招了,写了个iptables脚本,如下:
统计tcp连接,同一ip超过500次tcp连接的肯定就是***者的ip了,正常用户也不可能一下去开500个窗口去访问我的网站吧,然后将这个ip直接在iptables上面干掉,现在好了,问题解决了,这种CC***有一个特点就是用的源ip基本都是固定的,DDOS有些可能是用不同原ip进行***,那么这种防御就显得有些吃力了。那遇到不同源ip***怎么防御呢?
首先要联系机房,一般机房都有监控和防御设备,让机房帮忙解决一些问题可能更有效,
不能在iptable上面去防御,就只能通过nginx去防御了,让nginx去识别哪些是***者,哪些是真正的用户?其实nginx有2个模块:ngx_http_limit_conn_module和ngx_http_limit_req_module 可以参考官方文档:
http://nginx.org/cn/docs/http/ngx_http_limit_req_module.html
http://nginx.org/cn/docs/http/ngx_http_limit_conn_module.html
首先在http中定义,如下:
limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
然后到你需要限制的目录下面,server段中,一般就是php请求,如下:
location ~* ^/(.*)\.php?$ {
limit_conn addr 3;
limit_req zone=one burst=2 nodelay;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $host_path/$fastcgi_script_name;
include fastcgi_params;
}
应用这2条规则后,只要需要执行php脚本的这些页面同一个IP只许建立3个连接,并且每秒只能有1个请求(突发请求可以达到2个)。
虽然这样的规则一般来说对正常的用户不会产生影响(极少有人在1秒内打开3个页面),但是为了防止影响那些手快的用户访问,可以在nginx中自定义503页面,503页面对用户进行提示,然后自动刷新,这个参数可以根据自己的情况进行更改,这样不管***者是多个ip还是单个ip***都可以防御到.
如果在nginx日志中能找到***者特有的代码,这样就更容易防御,
比如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;
}
原文地址:http://www.myjishu.com/?p=240
转载于:https://blog.51cto.com/lxshopping/1583866