Distributed Denial of Service (DDoS) attacks involve sending a massive volume of seemingly legitimate packets from multiple machines to a service or website, causing network congestion and resource exhaustion, thereby preventing normal users from accessing the service. With increasing internet bandwidth and the continuous release of related tools, the difficulty of executing such attacks has decreased significantly. Many IDC hosting facilities, commercial websites, and game service providers have long suffered from DDoS attacks. So, how can we mitigate or even resolve DDoS issues? Recently, Rick Nelson published an article on the official Nginx blog introducing how to mitigate DDoS attacks using Nginx and Nginx Plus.
Rick Nelson first outlines some characteristics of DDoS attacks. For instance, attack traffic often originates from fixed IP addresses, with each IP creating far more connections and requests than real users. Additionally, since the traffic is generated by machines, its rate is much higher than that of human users. Furthermore, the User-Agent headers of attacking machines are not standard values, and Referer headers are sometimes set to values that can be associated with the attack. Based on these characteristics, Rick Nelson believes that Nginx and Nginx Plus have many features that can respond to or mitigate DDoS attacks by regulating or controlling traffic.
Limit Request Rate
Limit the acceptable inbound request rate for Nginx and Nginx Plus to a value suitable for real users. For example, the following configuration allows a genuine user to access the login page only once 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 directive configures a shared memory zone named one to store the request status of $binary_remote_addr, and the limit_req directive in the /login.html location block references this shared memory zone.
Limit Connection Count
Limit the number of connections a client IP address can open to a reasonable value for real users. For example, limit the number of connections each IP opens to the /store section of the website 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 directive configures a shared memory zone named addr to store requests for $binary_remote_addr. The limit_conn directive in the /store/ location block references this shared memory zone and sets the maximum connection count to 10.
Close Slow Connections
Close connections that remain open while writing data very frequently, as they reduce the server’s ability to accept new connections. Slowloris is an example of this type of attack. You can control the timeout for the request body or headers using the client_body_timeout and client_header_timeout directives. For example, the following configuration limits the wait time to within 5 seconds:
server {
client_body_timeout 5s;
client_header_timeout 5s;
...
}
Set IP Blacklist
If you can identify the client IP addresses used by attackers, use the deny directive to block them, causing Nginx and Nginx Plus to reject connections or requests from these addresses. For example, the following directives deny requests from 123.123.123.3, 123.123.123.5, and 123.123.123.7:
location / {
deny 123.123.123.3;
deny 123.123.123.5;
deny 123.123.123.7;
...
}
Set IP Whitelist
If the allowed IP addresses are relatively fixed, use the allow and deny directives to ensure the website or application only accepts requests from specific IP addresses or IP ranges. For example, the following directives restrict access to an IP range within a local network:
location / {
allow 192.168.1.0/24;
deny all;
...
}
Reduce Traffic Peaks via Caching
Enable caching and set certain cache parameters so that Nginx and Nginx Plus absorb most of the traffic peaks generated by the attack. For example, use the updating parameter of the proxy_cache_use_stale directive to tell Nginx when to update expired cache objects, avoiding pressure on backend servers caused by repeated update requests. Additionally, the key defined by the proxy_cache_key directive usually contains embedded variables. For instance, the default key $scheme$proxy_host$request_uri contains three variables. If it includes the $query_string variable, attackers could exhaust the cache by sending random query_string values. Therefore, unless there is a specific reason, do not use the $query_string variable in this key.
Block Requests
Configure Nginx and Nginx Plus to block the following types of requests:
- Requests targeting a specific URL
- Requests where the User-Agent header value is outside the normal client range
- Requests where the Referer header value can be associated with the attack
- Requests containing other header values that can be associated with the attack
For example, block attacks targeting /foo.php with the following configuration:
location /foo.php {
deny all;
}
Or block DDoS attacks with identified User-Agent header values of “foo” or “bar” using the following configuration:
location / {
if ($http_user_agent ~* foo|bar) {
return 403;
}
...
}
Limit Connections to Backend Servers
Typically, Nginx and Nginx Plus instances can handle many more connections than backend servers. Therefore, you can use Nginx Plus 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;
}
Additionally, Rick Nelson mentions how to handle range-based attacks and manage high-load issues, as well as how to use the Nginx Plus Status module to detect abnormal traffic patterns and locate DDoS attacks.