NGINX is open-source software. It has various uses, including reverse proxies, caching, load balancing, and web servers. With the intention of offering the highest performance and stability, it started out as a web server.
One of NGINX's most crucial features is rate limitation, but it's also one of the least known.
The number of HTTP requests a user can make in a particular interval of time can be specified using this. A request can be straightforward as a GET query for the main page or a POST query for a login form.
Attacks that utilize brute force to guess passwords can be slowed down using a security technique called rate limitation. By reducing the incoming request rate to a level typical for genuine users and identifying the targeted URLs, it can aid in DDoS attacks. It serves as a safeguard against the simultaneous overload of upstream application servers with user requests.
In this blog, we will discuss how to prevent Odoo instances from DDoS attacks using the NGINX rate limiting feature.
Working on NGINX Rate Limiting
A leaky bucket algorithm is used in NGINX rate limiting, which is popular in communications and packet-switched computer networks. According to the algorithm, assume that we have a bucket and we are pouring some water into the bucket in random order. But we need to get water at a fixed rate, for that we put some holes in the button of the bucket. So this ensures that the water is constantly coming, and also needs to take care of the overflow.
Therefore the input rate may not be constant, but the output should remain constant. Likewise in networking, this Leaky bucket algorithm will help to smooth out the bursty traffic. This will regulate the flow of data at an average rate.
NGINX Rate Limiting Configuration
We can configure rate limits using limit_req_zone and limit_req directives.
Example:
limit_req_zone $binary_remote_addr zone=limit:10m rate=100r/s;
server {
location /login/ {
limit_req zone=limit;
proxy_pass http://my_upstream;
}
}
limit_req enables rate limiting inside the context in which it appears, whereas limit_req_zone provides the parameters for rate limiting.
The limit_req_zone directive can be used in various contexts because it is normally defined in the HTTP block. The three following parameters are required:
Key - Defines the request characteristic that the limit is measured against. In the given example, the binary form of a client's IP address is stored in the NGINX variable $binary_remote_addr. This indicates that the number of requests made by each individual IP address will be limited to the third parameter's value.
Zone - Defines a shared memory space that is used to track each of the IP addresses and the frequency that a request-limited URL has been accessed. By remaining in shared memory it can share the data among the NGINX worker processes. This has two parts, zone = keyword identifies the zone name and the size after a colon (zone=limit:10m).
When NGINX has to add a new item but the storage is full, it deletes the previous entry. If the additional room is still insufficient to fit the new record, the 'Service Temporarily Unavailable' (status code 503) error will be returned by NGINX. In order to avoid running out of memory, NGINX also deletes up to two entries that haven't been utilized in the last 60 seconds whenever it generates a new entry.
Rate - The maximum request rate is set. The pace in the example is limited to 100 requests per second. This restriction equates to one request every 100 milliseconds because NGINX really counts requests at a millisecond level (ms). A request is denied if it arrives fewer than 100ms after the last authorized one since we are not allowing for bursts.
The limit_req_zone does not really limit the request rate which is coming to the server, instead, it defines the settings for rate limitation and the shared memory zone. For that, you must include a limit_req directive in the server block or region where you want to apply the limit. We are limiting requests per second to the /login/ page.