Challenge 3: A DoS Scenario Rate Limiting Wouldn't Stop — Solution Walkthrough

A realistic scenario:

A distributed denial-of-service attack using a large number of
genuinely different, real IP addresses (a botnet spread across
thousands of compromised machines, for example), each individual
address sending requests comfortably under the configured per-IP rate
limit (say, well below 5 requests per second each), but collectively
overwhelming the backend with sheer aggregate volume.

Why this chapter's rate limiting wouldn't stop it:

Per this chapter's own warning box, limit_req and limit_conn both key
on a per-client identifier, most commonly the IP address. Each
individual attacking IP in this scenario never exceeds its own
per-key limit, so Nginx never triggers a rejection for any of them
individually — the attack succeeds specifically by staying under the
per-IP threshold while using enough distinct IPs to still generate
overwhelming total traffic.

Why this doesn't mean rate limiting is useless:

This scenario doesn't invalidate rate limiting as a control — it
still stops a much more common and much cheaper attack (a single
attacker, or a small handful of IPs, hammering an endpoint). It simply
confirms this chapter's own point that Nginx-level rate limiting is
one useful layer, not a complete defense against every kind of
denial-of-service traffic, particularly a genuinely distributed one.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise applies this chapter's own warning box to a concrete,
plausible attack scenario, correctly identifying that the per-key
nature of these directives is exactly what a distributed attack is
designed to exploit, rather than describing a vague "it's not
perfect" answer.