Use Nginx and Nginx Plus to prevent DDoS attacks

Use Nginx and Nginx Plus to prevent DDoS attacks

Distributed Denial of Service (DDoS) attacks) it refers to an attack that uses multiple machines to send a large number of seemingly legitimate data packets to a service or website, blocking the network, exhausting resources, and thus failing to provide normal services to normal users. With the increase of Internet bandwidth and the continuous release of related tools, the implementation of such attacks becomes increasingly difficult. A large number of IDC hosting machine rooms, commercial sites, and game service providers have been suffering from DDoS attacks, so how can we mitigate or even solve DDoS attacks? Rick Nelson recently published an article on the official Nginx blog about how to mitigate DDoS attacks through Nginx and Nginx Plus.

Rick Nelson first introduced some features of DDoS attacks. For example, the attack traffic usually comes from some fixed IP addresses. Each IP address creates many connections and requests than real users; at the same time, because all traffic is generated by machines, the rate is much higher than that of human users. In addition, the User-Agent header of the target machine is not a standard value, and the Referer header is sometimes set to a value that can be associated with the attack. To address these features, Rick Nelson believes that Nginx and Nginx Plus have many features that can cope with or mitigate DDoS attacks by adjusting or controlling traffic.

Limit Request Rate
Limit the inbound request rate acceptable to Nginx and Nginx Plus to a value suitable for real users. For example, the following configuration allows a real user to access the logon page every two seconds:

limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;server {    ...    location /login.html {        limit_req zone=one;    ...    }}

In this configuration, the limit_req_zone command configures a shared memory zone named one to store the Request status of $ binary_remote_addr. The limit_req command of/login.html in the location block references the shared memory zone.

Limit the number of connections
Limit the number of connections that can be opened by a client IP address to a reasonable value for a real user. For example, limit the number of connections opened by each IP address to the website/store section to no more than 10:

limit_conn_zone $binary_remote_addr zone=addr:10m;server {    ...    location /store/ {        limit_conn addr 10;        ...    }}

In this configuration, the limit_conn_zone command configures a shared memory zone named addr to store $ binary_remote_addr requests. The/store/limit_conn command in the location block references the shared memory zone, set the maximum number of connections to 10.

Close slow connection
Close connections that keep reading and writing data frequently, because they reduce the server's ability to accept new connections. Slowloris is an attack of this type. You can use the client_body_timeout and client_header_timeout commands to control the Request body or request header timeout. For example, you can use the following configuration to control the wait time within 5s:

server {    client_body_timeout 5s;    client_header_timeout 5s;    ...}

Set IP blacklist
If the IP address of the client used by the attacker can be identified, use the deny command to shield Nginx and Nginx Plus from the connection or request from these addresses. For example, the following command is used to reject requests from 123.123.123.3, 123.123.123.5, and 123.123.7:

location / {    deny 123.123.123.3;    deny 123.123.123.5;    deny 123.123.123.7;    ...}

Set IP whitelist
If the IP addresses allowed for access are relatively fixed, use the allow and deny commands to allow websites or applications to only accept requests from a certain IP address or IP address segment. For example, use the following command to restrict access to an IP segment of the local network:

location / {    allow 192.168.1.0/24;    deny all;    ...}

Reduces traffic peaks through caching
Enable caching and set some cache parameters to enable Nginx and Nginx Plus to absorb most of the traffic peaks generated by attacks. For example, the updating parameter of the proxy_cache_use_stale Command tells Nginx when to update expired cache objects, so as to avoid the pressure on backend servers due to repeated update requests. In addition, the keys defined by the proxy_cache_key command usually contain embedded variables. For example, the default key $ scheme $ proxy_host $ request_uri contains three variables. if it contains the $ query_string variable, therefore, attackers can consume the cache by sending random query_string values. Therefore, if there is no special reason, do not use the $ query_string variable in this key.

Blocking requests
Configure Nginx and Nginx Plus to block the following types of requests:

The value in the User-Agent header of the request with a specific URL as the target is not within the scope of the normal client. The value in the request Referer header can be associated with the attack. Other headers of the request can be associated with the attack. requests with the same value

For example, use the following configuration to block attacks targeting/foo. php:

location /foo.php {    deny all;}

Or use the following configuration to block the recognized User-Agent header with a value of foo or bar:

location / {    if ($http_user_agent ~* foo|bar) {        return 403;    }    ...}

Limit the number of connections to backend servers
Generally, Nginx and Nginx Plus instances can process a large number of connections than backend servers. Therefore, Nginx Plus can be used to limit the number of connections to each backend server. For example, the following configuration limits the number of connections established between Nginx Plus and each backend server to no more than 200:

upstream website {    server 192.168.100.1:80 max_conns=200;    server 192.168.100.2:80 max_conns=200;    queue 10 timeout=30s;}

In addition, Rick Nelson also talked about how to deal with range-based attacks and how to handle high loads, and how to use the Nginx Plus Status module to discover abnormal traffic patterns and locate DDoS attacks.