How to Protect from DDoS Attacks with Nginx

How to Protect from DDoS Attacks with Nginx

Distributed denial-of-service (DDoS) attacks are a serious threat to any online business or web application. In this article, we take a closer look at application-layer attacks and explain how to use Nginx to protect against them. We provide instructions and code snippets to help you configure the Nginx reverse proxy instance to confidently defend your online presence against DDoS attacks at the application layer.

Application-Layer DDoS Attacks

Application-layer attacks, also known as layer 7 DDoS attacks, target the top layer of the OSI (Open Systems Interconnection) model, the application layer, where common internet requests such as HTTP GET and HTTP POST occur. These attacks are particularly effective as they consume both server and network resources, causing significant disruption with less total bandwidth compared to other types of DDoS attacks. Additionally, application layer attacks are often more sophisticated and harder to detect and mitigate than other types of DDoS attacks.

Examples of application layer attacks:

  • HTTP flood: An HTTP flood involves sending a large number of HTTP requests to the target, for example, using a botnet or a network of compromised devices. The target may become unavailable if it is unable to process a large number of requests.
  • Slowloris: Slowloris is a type of application-layer attack that involves sending partial HTTP requests to the target and keeping the connections open for as long as possible. This can exhaust the resources of the target. For example, the code perl slowloris.pl -dns 192.0.2.1 uses a Perl-based Slowloris.pl tool to initiate a Slowloris attack against the target web server at IP address 192.0.2.1 by sending partial HTTP requests and keeping the connections open for an extended period of time, making the target unavailable.

DDoS Protection or Mitigation with Nginx

Nginx is a high-performance, stable, and resource-efficient open source web server and reverse proxy. It can be configured to act as a load balancer, reverse proxy, and HTTP cache and is often used by web-based applications to handle large amounts of traffic.

DDoS protection, or DDoS mitigation, is the process of protecting a network or system from DDoS attacks. This can involve a variety of measures, including setting up firewalls and load balancers to filter out malicious traffic, implementing rate limiting to prevent excessive requests, and using cloud-based DDoS protection services to absorb and filter out malicious traffic.

Using Nginx for DDoS protection can be an effective way to protect your servers from DDoS attacks. By configuring Nginx as a reverse proxy and implementing appropriate rate limiting and timeout parameters, you can absorb and mitigate the impact of DDoS attacks and help protect your servers from being overwhelmed by malicious traffic. The following sections cover several methods you can use to implement DDoS protection using Nginx.

Limiting the Number of Connections

Limiting the number of connections that can be made from a single IP address can help prevent a single source from flooding your servers with requests. You can implement this method with Nginx using the limit_conn directive.

For example, the following configuration limits the number of connections to 100 per IP address:

limit_conn_zone $binary_remote_addr zone=conn_limit_per_ip:10m;
server {
    ...
    limit_conn conn_limit_per_ip 100;
}

When setting a limit on connections to protect against DDoS attacks, you need to find the right balance between protection and performance. Setting the limit too low can harm legitimate users, while setting it too high won’t effectively protect against attacks. Setting the limit to a low number, such as 10 or 20, is a good starting point, and then you can gradually increase it until you find the sweet spot that works for your server. Determining your sweet spot involves monitoring your server’s performance and making adjustments based on how it handles incoming traffic. You also need to consider the number of NAT clients while configuring the limit, as this can affect the number of connections. As a general recommendation, you should test your application with a variety of connection limits to find the optimal value that offers both protection and performance.

This method can effectively protect against DDoS attacks that involve a large number of connections, such as SYN floods.

Limiting the Request Size

You can use the limit_req directive to limit request rates in Nginx. This directive limits the request rate to a specified number of requests per second for a particular key, which is typically based on the client’s IP address.

The following is an example configuration that limits the request rate to 10 requests per second per IP address:

limit_req_zone $binary_remote_addr zone=req_limit_per_ip:10m rate=5r/s;
server {
    ...
    limit_req zone=req_limit_per_ip burst=10 nodelay;
}

In this example, the limit_req_zone directive defines the rate limit zone, and the rate parameter sets the limit to five requests per second (10r/s). The ‘burst‘ parameter specifies the number of requests that are allowed to exceed the limit, and the nodelay parameter ensures that requests that exceed the limit are immediately rejected.

Your request rate limit should be fine-tuned to find the appropriate threshold that works for your application. You should start with a relatively low number of requests per second, such as five requests per second per IP address, and gradually increase the request rate until you find the optimal threshold.

Your server’s CPU and RAM consumption should also be monitored while fine-tuning the request rate limit. If the server is under too much load, you may need to reduce the request rate limit to prevent performance issues.

When implementing request rate limiting, you should choose an appropriate limit key that identifies the source of the request. The ‘limit_req_zone‘ directive defines the rate limit zone and the key used to identify the request.

By default, the ‘$binary_remote_addr‘ variable is used as the limit key, which is based on the client’s IP address. However, if your website uses a proxy or load balancer, you may need to use a different variable or combination of variables to ensure that the rate limit is applied correctly.

For example, if your website is behind a load balancer, you can use the ‘X-Forwarded-For‘ header as the limit key to identify the client’s IP address. The following is an example configuration that uses the X-Forwarded-For header as the limit key:

limit_req_zone $http_x_forwarded_for zone=req_limit_per_ip:10m rate=10r/s;
server {
    ...
    limit_req zone=req_limit_per_ip burst=5 nodelay;
}

Nginx Timeout Parameters

Setting limits on how long Nginx will wait for certain events to occur, such as establishing a connection or receiving a response from a server, can prevent resources from being consumed by connections that take too long to complete.

You can use the proxy_connect_timeout, proxy_send_timeout, and proxy_read_timeout directives to implement this method. For example, the following configuration sets the timeout parameters to 10 seconds:

server {
    ...
    proxy_connect_timeout10s;
    proxy_send_timeout 10s;
    proxy_read_timeout 10s;
}

However, these timeout parameters need to be chosen with care. If they are set too low, legitimate connections may be terminated prematurely. For the appropriate timeout value for your server, you also need to consider the average response time of your server and the maximum response time your users are willing to tolerate. Monitor your server logs, track response time metrics, and adjust the timeout parameters accordingly to find the right balance between security and usability.

This method can be effective at protecting against DDoS attacks that involve slow connections, such as Slowloris attacks.

Blacklisting and Whitelisting IP Ranges

Blacklisting and whitelisting IP ranges is a method of DDoS protection that involves specifying which IP addresses are allowed or denied access to your servers. Blacklisting involves blocking access to a particular range of IP addresses, while whitelisting involves only allowing access to a particular range of IP addresses.

To implement this method using Nginx, you can use the deny and allow directives. For example, the following configuration blocks access to all IP addresses except for those in the 192.0.2.0/24 range:

server {
    ...
    deny all;
    allow 192.0.2.0/24;
}

These directives must be used carefully, as blocking access to certain IP ranges could potentially affect legitimate users. When defining which IPs to block, monitor server logs for patterns of excessive requests from specific IPs, refer to IP reputation databases for known malicious IPs, and consider using geolocation data to block IP ranges associated with a high rate of DDoS attacks.

This could be useful if you’re experiencing a DDoS attack from a specific IP range or even from a specific country.

Blocking Access to a File Targeted by a DDoS Attack

Blocking access to a file targeted by a DDoS attack is a method of protection that involves denying access to a particular file or resource that is being targeted by the attack. This can help prevent the targeted file or resource from being overwhelmed and ensure that your servers remain available to legitimate users.

To implement this method using Nginx, you can use the location directive. For example, the following configuration blocks access to a file called targeted.txt:

server {
    ...
    location /targeted.txt {
        deny all;
    }
}

One way to protect against DDoS attacks is to block access to files that are not necessary for your website’s functionality. These could include backup files, resource-intensive media files, git files, source code directories, and configuration files, all of which could be potential targets for malicious access.

However, you need to make sure you don’t block access to critical files such as marketing pages and static files that are essential for your website’s functionality, as this could cause issues for legitimate users. Therefore, you should review your website’s file structure and identify which files could be potential targets for DDoS attacks.

This method can protect against DDoS attacks that involve targeting a particular file or resource, such as file injection attacks. However, it may not be effective against other types of attacks, such as volumetric attacks.

Conclusion

By following the instructions and code snippets we’ve provided in this article, you can effectively use Nginx to implement a variety of DDoS protection measures. With these measures, you can help ensure that your web application remains available and accessible to legitimate users, even in the face of a DDoS attack.

If you’re looking for an all-in-one DDoS solution at the L3, L4, and L7 layers, check out Gcore DDoS Protection. Out solution has over 1 Tbps total filtering capacity and blocks DDoS attack from the first request by sessions, not IPs. Keeps your websites, servers, and apps safe with us!

Request free trial of Gcore DDoS Protection

Written by Raushan Raj

Subscribe and discover the newest
updates, news, and features

We value your inbox and are committed to preventing spam