Protect against DDoS attacks with Nginx and Nginx Plus

original 2015-10-16 Chenyang operation and Maintenance help

DDoS is a way of attacking a target through a high-traffic request, causing the server's resources to run out of service to continue to provide service.

In general, an attacker can saturate a server with a large number of requests and connections so that it cannot accept new requests or become slow.

Characteristics of application Layer DDoS attacks

The application layer (layer seven/http layer) DDoS attacks are usually initiated by Trojan horses, which can be designed to better utilize the vulnerable points of the target system. For example, for a system that cannot handle a large number of concurrent requests, simply by establishing a large number of connections and periodically issuing a small number of packets to keep the session running, the resources of the system can be exhausted, making it unacceptable for the new connection request to be DDoS-capable. There are other forms of attacks that use requests that send large packets of connection requests. Because an attack is initiated by a Trojan, an attacker can quickly establish a large number of connections and make a large number of requests in a very short period of time.

Here are some of the DDoS features that we can follow to resist DDoS (including but not limited to):

• Attacks often originate from relatively fixed IP or IP segments, with each IP having a greater number of connections and requests than the real user.

  Note: This does not indicate that the request represents a DDoS attack. In many network architectures that use NAT, many clients use the gateway's IP address to access public network resources. However, even so, the number of requests and connections is much less than a DDoS attack.

• Because the attack is issued by a Trojan and the purpose is to overload the server, the frequency of requests will be far more than normal requests.

• User-agent is usually a non-standard value

• Referer is sometimes a value that can easily be associated with an attack

Use Nginx, Nginx Plus to resist DDoS attacks

Combined with the characteristics of the above mentioned DDoS attacks, Nginx and Nginx Plus has many features that can be used to effectively defend against DDoS attacks, which can be achieved against DDoS attacks from two aspects of adjusting ingress access traffic and controlling reverse proxy to back-end server traffic.

Limit Request Speed

Setting Nginx and Nginx Plus connection requests is within the reasonable range of a real user request. For example, if you think a normal user can request a login page every two seconds, you can set Nginx to receive a client IP request every two seconds (about the equivalent of 30 requests per minute).

Limit_req_zone $binary _remote_addr zone=one:10m rate=30r/m;

server {

...

location/login.html {

Limit_req Zone=one;

...

}

}

The ' limit_req_zone ' command sets a shared memory area called one to store a specific key value for the request state, in the example above, the client IP ($binary _remote_addr). The ' Limit_req ' in the location block implements the purpose of restricting access to/login.html by referencing the one shared memory area.

Limit number of connections

The number of connections to Nginx and Nginx Plus is within the reasonable range of a real user request. For example, you can set each client IP connection/store to no more than 10.

Limit_conn_zone $binary _remote_addr zone=addr:10m;

server {

...

location/store/{

Limit_conn addr 10;

...

}

}

The ' limit_conn_zone ' command sets a shared memory area called Addr to store the state of a particular key value, in the example above, the client IP ($binary _remote_addr). The maximum number of connections that ' limit_conn ' in the location block is limited to/store/by referencing the addr shared memory area is 10.

Turn off slow connections

Some DDoS attacks, such as Slowlris, are targeted by establishing a large number of connections and periodically sending some packets to hold the session for the purpose of the attack, which typically falls below the normal request. In this case we can defend against the attack by shutting down the slow connection.

The ' client_body_timeout ' command is used to define the timeout period for reading client requests, and the ' client_header_timeout ' command is used to read the time-out of the client request header. The default values for both parameters are 60s, and we can set them to 5s with the following command:

server {

Client_body_timeout 5s;

Client_header_timeout 5s;

...

}

Set IP blacklist

If it is determined that the attack originated from some IP addresses, we can blacklist them and the Nginx will not accept their request. For example, you have determined that the attack came from an IP address from 123.123.123.1 to 123.123.123.16, which you can set:

Location/{

Deny 123.123.123.0/28;

...

}

Or you can be sure that the attack comes from 123.123.123.3, 123.123.123.5, 123.123.123.7 several IPs, so set:

Location/{

Deny 123.123.123.3;

Deny 123.123.123.5;

Deny 123.123.123.7;

...

}

Set IP Whitelist

If your site only allows access to specific IP or IP segments, you can use the Allow and DENY commands in conjunction to restrict access to your site to only the IP addresses that you specify. As below, you can set only allow 192.168.1.0 segment of Intranet user access:

Location/{

Allow 192.168.1.0/24;

Deny all;

...

}

The Deny command rejects access requests for all other IPs except for the IP segment specified by Allow.

Using caching for traffic clipping

By opening the Nginx cache feature and setting specific cache parameters, you can reduce the amount of traffic coming from the attack, as well as reduce the pressure on the backend server for requests. Here are some useful settings:

• The ' Proxy_cache_use_stale ' updating parameter tells Nginx when to update the cached object. Only one update request to the backend is required, and the client's request to that object does not require access to the backend server during the cache validity period. When an attack is carried out by frequent requests for a file, caching can greatly reduce the request to the backend server.

• The key value defined by the ' proxy_cache_key ' command usually contains some inline variables (the default key value $scheme$proxy_host$request_uri contains three variables). If the key value contains ' $query _string ' variable, it will give the Nginx proxy an excessive cache load when the attack request string is random, so we recommend not to include the ' $query _string ' variable in general.

Block a specific request

You can set Nginx, Nginx Plus to mask some types of requests:

• Request for a specific URL

• Requests for user-agent that are not common

• Request for Referer header containing values that can be associated with an attack

• Requests that contain values that can be associated with an attack against other request headers

For example, if you decide that the attack is for a specific url:/foo.php, we can block the request to this page:

location/foo.php {

Deny all;

}

Or if you decide that the user-agent of the attack request contains Foo or bar, we can also block these requests:

Location/{

if ($http _user_agent ~* foo|bar) {

return 403;

}

...

}

The http_name variable refers to a request header, and the above example is the user-agent header. A similar approach can be used to identify attacks against other HTTP headers.

Limit the number of connections to back-end servers

An nginx, Nginx plus instance can handle many more concurrent requests than the backend server. In Nginx Plus, you can limit the number of connections to each back-end server, such as the number of connections that can be set for Nginx plus to each back-end server in website upstream:

Upstream website {

Server 192.168.100.1:80 max_conns=200;

Server 192.168.100.2:80 max_conns=200;

Queue of ten timeout=30s;

}

The ' Max_conns ' parameter allows you to set the maximum number of connections that Nginx plus can establish for each back-end server. The ' queue ' command sets the queue size after each backend server has reached the maximum number of connections, and the ' timeout ' parameter specifies how long the request is to be held in the queue.

Handling specific types of attacks

One attack is to send a request header with a particularly large value, causing a server-side buffer overflow. Nginx and Nginx Plus for this attack type of defense, you can refer to the [Using Nginx and Nginx Plus to Protect against cve-2015-1635] (http://nginx.com/blog/ nginx-protect-cve-2015-1635/?_ga=1.14368116.2137319792.1439284699)

Optimized Nginx Performance

DDoS attacks usually bring high load pressure, can improve nginx, nginx plus processing performance through some tuning parameters, hard anti-DDoS attack, detailed reference: [Tuning Nginx for performance] (http://nginx.com/ blog/tuning-nginx/?_ga=1.48422373.2137319792.1439284699)

Identify DDoS attacks

So far, we've focused on how to mitigate the impact of DDoS attacks with Nginx and Nginx Plus. How do you get Nginx, Nginx Plus to help us identify DDoS attacks? The ' Nginx Plus Status module ' provides detailed statistics of traffic to back-end servers that can be used to identify abnormal traffic. Nginx Plus provides a dashboard page of the current service status, as well as the ability to obtain these statistics via API in a custom system or other third-party system, and to identify abnormal traffic based on historical trend analysis and then issue alarms.

Summarize

Nginx and Nginx Plus can act as a powerful defense against DDoS attacks, and Nginx Plus provides some additional features to better protect against DDoS attacks and identify them when they occur.

Original: https://www.nginx.com/blog/mitigating-ddos-attacks-with-nginx-and-nginx-plus/

Translator: Chenyang (Yun Gang)

Protect against DDoS attacks with Nginx and Nginx Plus