Menu
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/CyberStrikeus/CyberStrike --skill cis-nginx-v300-5-2-5The command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Showing SKILL.md
macOS post-exploitation for credential harvesting, DTrace monitoring, TCC bypass, and stealth operations via native tools
Windows userland post-exploitation for credential harvesting, monitoring, AMSI/ETW bypass, and stealth operations
Kubernetes post-exploitation for container escape, secret extraction, RBAC abuse, and cluster persistence
Based on SOC occupation classification
| name | cis-nginx-v300-5-2-5 |
| description | Ensure rate limits by IP address are set (Manual) |
| category | cis-nginx |
| version | 3.0 |
| author | cyberstrike-official |
| tags | ["cis","nginx","web-server","reverse-proxy","request-limits","request-filtering"] |
| cis_id | 5.2.5 |
| cis_benchmark | CIS NGINX Benchmark v3.0.0 |
| tech_stack | ["nginx","linux","web-server"] |
| cwe_ids | [] |
| chains_with | [] |
| prerequisites | [] |
| severity_boost | {} |
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.
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.
This is a manual check requiring context.
1. Run the following command to find rate-limiting rules:
nginx -T 2>/dev/null | grep -E '^\s*(limit_req_zone|limit_req)'
2. Manually evaluate the findings:
limit_req_zone defined in the http block?limit_reqserverlocation //loginrate and burst values reasonable for the protected endpoint?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 ...
}
}
}
By default, no rate limits are configured. NGINX will process requests from a single IP address as fast as the client can send them.
| Controls Version | Control | IG 1 | IG 2 | IG 3 |
|---|---|---|---|---|
| v8 | 16.1 Establish and Maintain a Secure Application Development Process | N | Y | Y |
| v7 | 18.1 Establish Secure Coding Practices | N | Y | Y |
| Tactic | Technique |
|---|---|
| Impact | T1499 - Endpoint Denial of Service |
| Credential Access | T1110 - Brute Force |