阵地防御案例

IIS防御小规模DDOS***实例

最近几天，公司网站和业务管理系统的注册页面经常遭受DDOS***，导致IIS应用池CPU使用率100%，浏览网站出现503服务不可用。下面总结一下对策。

一、开启IIS的CPU监控功能

这种方法可以用于低频DDOS。这是w3wp.exe应用程序池的关系过程。当网页浏览量很大时，w3wp.exe会占用大量的服务器资源。在DDOS***，明显的情况是w3wp.exe有100%的CPU，网站被拒绝访问。此时，远程登录网络服务器是非常困难的。针对这种情况，进行以下改进:

1.在IIS中为每个URL设置一个独立的应用程序池。

2.为每个应用池设置CPU监控功能:当w3wp.exe的CPU超过50%或更高时，会自动杀死w3wp.exe进程，监控频率为1分钟。如果有浏览请求，w3wp.exe会重启，这不会危及客户的浏览。

二。流动清洗

当***发现基层的DDOS已经失效时，就会加大***的幅度。一开始我们官网平均并发数只有几千，后来增加到平均1.6万高并发，最高8万高并发。这样一来，上面CPU的监控功能就没有实际作用了。w3wp.exe重新启动后，CPU将在很短的时间内再次达到100%。

当时监控的高并发线程数:

CPU利用率和总流量(网络带宽限制10m):

幸运的是，官网的域名刚好注册在阿里云服务器上。大家搬到阿里云服务器后，使用云盾的DDOS安全防护功能会清理绝大多数异常总流量，CPU马上正常，官网脱胎换骨。

注:阿里云免费DDoS基础安全防护阈值为5Gbps。如果***的总流量高于这个值，就会是一个超级黑洞，业务流程无法浏览。

下面是云主机的主要参数:

    配备： CPU2核、运行内存4gB     镜像系统： Windows Server 2008 R2 专业版 SP1 64位汉化版     储存： 1块一般网盘（100GB）     互联网： 网络带宽10Mbps（經典互联网）

配置不高，却能抵御高韧性的DDOS***攻击，这得益于阿里巴巴强大的技术水平。私底下打个广告哈哈哈。

三。Nginx反向代理

但是***经常***人人商务管理系统的注册页面这次就没那么幸运了。由于业务管理系统位于每个人物理线的主机房，所以需要靠自己。

所以我们采用了Nginx反向代理的前端开发，双IIS的后端开发作为三层交换机，利用Nginx和HttpLimitReqModul控制模块的强大功能，将一个ip的浏览频率限制在一定的时间范围内。这里不提Nginx的推广，下面只贴相关设备:

首先，升级nginx.conf的http配备部分的以下内容:

    map $http_x_forwarded_for  $clientRealIp {     "" $remote_addr;     ~^(?P<firstAddr>[0-9\.]),?.*$  $firstAddr;     }     # 访问受限制后回到599     limit_req_status 599;     # 界定一个名叫allips的limit_req_zone用于储存session，尺寸是100M运行内存，     # 以$clientRealIp 为key,限定均值每秒钟的要求为一百个，     limit_req_zone $clientRealIp zone=allips:100m rate=100r/s;

这里对同一个IP的每秒请求数限制为不超过一百，否则不必要的请求会立即返回到599，这是不正确的。限频要根据具体情况配备。如果设备太低，会危及一切正常浏览，导致网页显示的信息不是等腰的问题。

然后编写/etc/nginx/conf.d/upstream.conf:

server {   listen       1334;   server_name  _;   # 加上以下一行   limit_req zone=allips burst=5 nodelay;   location / {     # 反向代理     proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;     proxy_pass http://wskh_IIS;   }   # 打开stub_status控制模块监管   location /nginx_status{     stub_status on;     access_log off;     allow 127.0.0.1;     # 容许内部网某IP查询nginx status     allow 192.168.1.100;     deny all;   } } # 后端开发web服务器 upstream wskh_IIS {   server 192.168.1.39:1334;   server 192.168.1.40:1334;   ip_hash; }

好吧，简单的设备。

在Nginx浏览日志access.log下面贴一个统计分析IP所需频率的小脚本:

#!/bin/bash # # Filename:    count_req.sh # Revision:    1.0 # Author:      Qicheng # Website:     http://qicheng0211.blog.51cto.com # Description: 统计分析Nginx日志里IP浏览頻率 NGINXLOG="./access.log" start_time=$(head -n1 "$NGINXLOG" | grep -o " \[.*\] ") stop_time=$(tail -n1 "$NGINXLOG" | grep -o " \[.*\] ") echo -e "start:\t\e[92m$start_time\033[0M" echo -e "stop:\t\e[92m$stop_time\033[0M" echo '全部的要求TOP50-->>' # 全部的要求 cat "$NGINXLOG" | awk '{S[$1]} END {for(a in S) print S[a],"\t", a}' | sort -rn -k1 | head -n 50 echo '--------------------------------------------------' echo '取得成功的要求TOP50-->>' # 取得成功的要求 grep ' 200 ' "$NGINXLOG" | awk '{S[$1]} END {for(a in S) print S[a],"\t", a}' | sort -rn -k1 | head -n 50

把脚本making放在access.log同一个文件目录下实现就行了。部分输出如下所示:

考虑此***源IP后，将其添加到iptables:

iptables -I INPUT -s {ip} -j DROP;