IIS defenses against small scale DDoS attack instances (reverse proxy) _win server

In recent days the company's official website and Business System registration page frequently encountered DDoS attacks, resulting in the IIS application pool CPU occupancy rate of 100%, access to the site 503 errors. The following is a summary of the response measures.

First, enable the CPU monitoring features of IIS

For low frequency DDoS, this approach can be taken. W3wp.exe is an application pool-related process, and w3wp.exe consumes a large amount of system resources when Web access is large. Under the DDoS attack, the obvious phenomenon is that the w3wp.exe occupies 100% CPU, the website refuses to visit, this time the remote login server is very difficult. For this situation, do the following optimizations:

1. Set up a separate application pool for each Web site in IIS.

2. Set CPU monitoring for each application pool: When the W3wp.exe CPU exceeds 50% or higher, the W3wp.exe process is automatically killed and the monitoring frequency is 1 minutes. Whenever an access request comes in, W3wp.exe restarts without affecting user access.

Second, Flow cleaning

When hackers find low-level DDoS is not working, they will increase the attack strength. At the beginning of our official website, the average number of concurrent only thousands of, then increased to an average of 16,000 concurrent, up to 70,000 concurrent, so that the CPU monitoring on top of the effect, because the w3wp.exe restart, in a very short period of time the CPU to reach 100%.

Number of concurrent connections monitored at that time:

CPU usage and traffic (bandwidth limit 10M):

Fortunately, the official website domain name just in Ali Cloud on the record, we migrated to Ali Cloud, the use of Cloud Shield DDoS protection will wash off most of the abnormal flow, the CPU immediately normal, the official website full of blood resurrection.

Here are the parameters for the cloud server:

  Configuration: CPU2 kernel, Memory 4GB 
  mirroring: Windows Server 2008 R2 Standard Version SP1 64-bit Chinese 
  storage: 1 Common Cloud Disk (100GB) 
  Network: Bandwidth 10Mbps (Classic network) 

Parameter configuration is not high, but can withstand the high intensity of DDoS attacks, which benefited from Ali's powerful technical strength, secretly do an ad, Hey hei.

Third, Nginx reverse proxy

But hackers also often attack our business System registration page, this time is not so lucky, because the business system is in our physical room, this depends on our own.

So we take the front-end Nginx reverse proxy, back-end dual IIS to do load balancing, the use of nginx powerful performance and Httplimitreqmodul module to limit the number of times the same IP access in a certain time period. The optimization of Nginx is not mentioned here, only the relevant configuration is posted below:

First, add the following in the HTTP configuration section of nginx.conf:

Map $http _x_forwarded_for $clientRealIp {" 
  " $remote _addr; 
  ~^(? P<firstaddr>[0-9\.] +),?. *$ $firstAddr; 
  } 
  # return 599 limit_req_status 599 after restricted access 
  ; 
  # define a limit_req_zone named Allips to store session, size 100M memory, 
  # with $clientrealip as key, limit average of 100 requests per second, 
  

This limits the number of requests per second of the same IP to no more than 100, or the extra requests return a 599 error directly. Limit the frequency to be configured according to the actual situation, the configuration is too low will affect the normal access, appear the page display is not congruent problem.

Then edit/etc/nginx/conf.d/upstream.conf:

server { 
 listen    1334; 
 server_name _; 
 
 # Add the following line 
 limit_req zone=allips burst=5 nodelay; 
 
 Location/{ 
  # Reverse proxy 
  proxy_set_header x-forwarded-for $proxy _add_x_forwarded_for; 
  Proxy_pass Http://wskh_IIS; 
 } 
  
 # Open Stub_status Module monitor 
 location/nginx_status{ 
  stub_status on; 
  Access_log off; 
  Allow 127.0.0.1; 
  # Allow Intranet to view Nginx status 
  allow 192.168.1.100; 
  Deny all; 
 } 
 
# Back-end Web server 
upstream Wskh_iis { 
 server 192.168.1.39:1334; 
 Server 192.168.1.40:1334; 
 Ip_hash; 
}

OK, simple configuration complete.

Here is a small script that counts the frequency of IP requests in the Nginx access log access.log:

#!/bin/bash 
# 
Filename:  count_req.sh 
# Revision:  1.0 
# Author: Qicheng 
# Website :   http://qicheng0211.blog.51cto.com 
# Description: Statistics nginx log IP access frequency 
 
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 ' All requests top50-->> '
# all requests cat ' 
$NGINXLOG ' | awk ' {++s[$1]} end {for (A-S) print s[a], "\ T", a} ' | Sort-rn-k1 | Head-n 
Echo '--------------------------------------------------'
echo ' successful request top50-->> '
# A successful request 

Put the script in the same directory as the Access.log to execute it. The partial output is as follows:

After filtering out these attack source IPs, add to Iptables:

Iptables-i input-s {IP}-j DROP;

This article from the "Start Linux blog" blog, declined to reprint!