Detections
Analytics

5.2.5 Ensure rate limits by IP address are set

Information

NGINX's ngx_http_limit_req_module provides a mechanism to limit the rate of incoming requests from a single client IP address, based on the \"leaky bucket\" algorithm. This is configured in two steps:

1. limit_req_zone : This directive, defined in the http block, creates a shared memory zone that defines the bucket's parameters, such as the average request rate.

2. limit_req : This directive, applied in a server or location block, enforces the rate limit using a specific zone and defines how \"bursts\" of traffic are handled.

When a client exceeds the defined rate, NGINX will reject new requests with a 503 Service Temporarily Unavailable error.

Rate limiting is the primary defense against application-level, high-frequency attacks. Its main purpose is to prevent brute-force password guessing on login endpoints, API abuse by automated scripts, and aggressive content scraping. Unlike connection limiting ( limit_conn ), which focuses on slow, simultaneous connections, rate limiting ( limit_req ) targets clients making an excessive number of requests in a short period.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

First, define a shared memory zone in the http block. Then, apply a carefully tuned limit only to the specific location blocks that require protection.

Understanding the \"Leaky Bucket\" Parameters:

 - rate : The average rate at which the bucket \"leaks\" (requests are processed). 5r/s means 5 requests per second.
 - burst : The size of the bucket. It's the number of \"token\" requests a client can make in excess of the defined rate. A burst=10 allows a client to burst up to 10 requests instantly before the rate limit kicks in.
 - nodelay : Without nodelay, excess requests in a burst are queued and processed at the defined rate (slowing the client down). With nodelay, excess requests are processed immediately as long as they fit in the burst \"bucket\", and only requests beyond the burst limit are rejected. For APIs and login pages, nodelay is generally preferred for a better user experience.

Example Configuration:

http {

 # Define a 10MB zone for login attempts.
 # Rate: 1 request per second average.
 limit_req_zone $binary_remote_addr zone=login_limit:10m rate=1r/s;

 server {

 # NO global rate limit here!

 location / {
 # Normal traffic, no rate limit
 }

 # Apply a strict rate limit ONLY to the login endpoint
 location /login {

 # Use the 'login_limit' zone.
 # Allow a burst of 5 requests, then enforce the 1r/s limit.
 # 'nodelay' ensures a user can quickly resubmit a form without being artificially slowed down.
 limit_req zone=login_limit burst=5 nodelay;

 # ... other settings ...
 }
 }
}

Impact:

Applying a global, aggressive rate limit is extremely dangerous and will almost certainly block legitimate users accessing your site from behind a shared NAT (e.g., corporate offices, datacenters, mobile networks). Rate limiting is a surgical tool that must be applied only to specific, sensitive locations (e.g., /login, /api/v1/authenticate ) where abuse is likely. Incorrectly configured rate limits are a common source of user complaints and support tickets.

See Also

https://workbench.cisecurity.org/benchmarks/18528

Item Details

Category: SYSTEM AND SERVICES ACQUISITION

References: 800-53|SA-3, CSCv7|18.1

Plugin: Unix

Control ID: 2bb412c5f9a9f5ffdfa638a77a7f4375eb27ee4265d2d7edea1904de61938b32