Nginx protection against DDoS attack configuration

To defend against DDoS is a systematic project, the attack pattern is many, the defense cost is high bottleneck, the defense is passive and helpless. DDoS is characterized by distributed, targeted bandwidth and service attacks, which are four-layer traffic attacks and seven-layer application attacks, corresponding to the defense bottleneck of four layers in bandwidth, seven layers of multi-architecture throughput. For seven-layer application attacks, we can still do some configuration to defend, such as the front-end is nginx, mainly using Nginx http_limit_conn and Http_limit_req module to defend. Ngx_http_limit_conn_module can limit the number of connections to a single IP, ngx_http_limit_req_module can limit the number of requests per second for a single IP, and can protect against CC attacks relatively effectively by restricting the number of connections and the number of requests. Here are the configuration methods:

I. Limit the number of requests per second

The Ngx_http_limit_req_module module limits the number of requests per unit time by the leaky bucket principle, and returns a 503 error if the number of requests exceeds the limit within a unit time. The configuration needs to be set up in two places:

• Nginx.conf defined trigger conditions within an HTTP segment, can have multiple conditions
• Define the action that Nginx performs when the trigger condition is reached within the location

For example:

http {     limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s; //触发条件，所有访问ip 限制每秒10个请求     ...     server {         ...         location  ~ \.php$ {             limit_req zone=one burst=5 nodelay;   //执行的动作,通过zone名字对应                }            }      

Parameter description:

$binary_remote_addr  二进制远程地址 zone=one:10m    定义zone名字叫one，并为这个zone分配10M内存，用来存储会话（二进制远程地址），1m内存可以保存16000会话 rate=10r/s;     限制频率为每秒10个请求 burst=5         允许超过频率限制的请求数不多于5个，假设1、2、3、4秒请求为每秒9个，那么第5秒内请求15个是允许的，反之，如果第一秒内请求15个，会将5个请求放到第二秒，第二秒内超过10的请求直接503，类似多秒内平均速率限制。 nodelay         

Two. Limit the number of IP connections

Ngx_http_limit_conn_module configuration method and parameters are very similar to the Http_limit_req module, the parameters are few, much simpler

http {     limit_conn_zone $binary_remote_addr zone=addr:10m; //触发条件     ...     server {         ...         location /download/ {             limit_conn addr 1;    // 限制同一时间内1个连接，超出的连接返回503                 }            }      

Three. Whitelist settings

The Http_limit_conn and Http_limit_req modules limit the number of concurrent and requests in a single IP unit time, but if Nginx is preceded by a load balancer or reverse proxy such as LVS or Haproxy, Nginx gets all the connections or requests from the load balancer, and should not limit load-balanced connections and requests, the GEO and map modules are required to set the whitelist:

geo $whiteiplist { default 1; 10.11.15.161 0; } map $whiteiplist $limit { 1 $binary_remote_addr; 0 ""; } limit_req_zone $limit zone=one:10m rate=10r/s; limit_conn_zone $limit zone=addr:10m;

The GEO module defines a variable whiteiplist with a default value of 1, and when the IP is in the whitelist, the value of the variable whiteiplist is 0 and vice versa is 1
If you're on the whitelist--whiteiplist=0--$limit = ""--no storage to 10m session state (one or addr)--Unlimited
Conversely, not in the whitelist--whiteiplist=1--$limit = binary remote address--stored in 10m session state--Limited

Four. Testing

Using the AB command to simulate CC attacks, the Http_limit_conn and Http_limit_req modules are tested separately, noting that the Http_limit_conn module only counts the connections that are being processed (the headers of these requests have been fully read into). If the request has been processed and the connection is not closed, it will not be counted. At this point, the Netstat can see that the number of connections is more than the limit and will not be blocked.

ab -n 请求数 -c 并发 http://10.11.15.174/i.php

If blocked the foreground will return 503, and in the Nginx Error_log, you will see the following error log:
The number of connections is limited:

2015/01/28 14:20:26 [error] 4107#0: *65525 limiting connections by zone "addr", client: 10.11.15.161, server: , request: "GET /i.php?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 HTTP/1.1", host: "10.11.15.174", referrer: "http://10.11.15.174/i.php"

Number of requests being throttled:

2015/01/28 14:18:59 [error] 4095#0: *65240 limiting requests, excess: 5.772 by zone "one", client: 10.11.15.161, server: , request: "GET /i.php?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 HTTP/1.1", host: "10.11.15.174", referrer: "http://10.11.15.174/i.php"

Five. Some other anti-CC methods

1.Nginx modules modsecurity, Http_guard, Ngx_lua_waf

• Modsecurity Application layer WAF, powerful, defense-rich attack, configuration complex
• Ngx_lua_waf Ngx_lua-based Web application firewall with simple, high performance and lightweight
• Http_guard based on Openresty

2. Software +iptables

• Fail2ban analyze logs to determine if iptables interception is used
• DDoS Deflate determines the number of IP connections by netstat and uses iptables masking

First said anti-DDoS is a system engineering, by optimizing the system and software configuration, only to protect against small-scale cc attacks, for large-scale attacks, four-layer traffic attacks, mixed attacks, basically the system and application software is not hanging, the bandwidth is full. Here are some of the ways I used to defend against DDoS in my work:

1. High-protection servers and ISPs with flow-cleaning are usually servers in the US and Korea, and some ISP backbone providers have traffic-cleaning services, such as PCCW in Hong Kong. Can usually protect against small attacks of around 10G
2. Traffic cleaning services such as: Akamai (prolexic), Nexusguard we have been hit by a maximum of 80G traffic, successfully cleaned, but very expensive
3. CDN For example: Blue message Network Homestay CloudFlare, CDN for the distributed characteristics of DDoS, the flow of drainage is dispersed, while the site has accelerated effect, the effect is good, the cost is relatively low.

To summarize: It is easy to launch an attack and it is difficult to defend. Seven layers of good protection, four layers difficult to prevent, small can prevent, large-scale burn money

Reference article:
Http://nginx.org/en/docs/http/ngx_http_limit_req_module.html
Http://www.nginx.cn/446.html
http://www.ttlsa.com/nginx/nginx-limited-connection-number-ngx_http_limit_conn_module-module/

• This article is from: Linux Tutorial Network

Nginx protection against DDoS attack configuration