IP reputation and rate limiting

Two related things usually get discussed together. Rate limiting counts requests per address, subnet or ASN over a sliding window and refuses past a threshold. IP reputation checks the address against a blocklist — Spamhaus, Project Honey Pot, a commercial feed, or your CDN’s own scoring — and refuses known-bad ones outright.

Both belong at the edge, in front of the application, where a refusal costs you nothing to serve.

Bursts from a small number of origins, which is still the most common shape of attack because it is the cheapest to run. This is the defense that would have blunted the 665-fills-in-seventy-six-minutes case, and blunting that is worth real money: your database stays usable, your notification email stays readable, your team does not spend an afternoon on cleanup.

Reputation lists add a slice on top — datacentre ranges, known scanners, addresses that hit a spam trap last week. Useful, cheap, and lagging by design.

By distribution. Residential proxy networks resell access to millions of consumer connections, and an attacker who sends one submission per address never approaches any threshold you could set without blocking real traffic. There is no rate limit that distinguishes “one submission from a home connection in Ohio” from “one submission from a home connection in Ohio.”

Reputation lists lose the same race. The pools are large, rotating, and fresh; a list that updates daily is describing last week’s addresses. The addresses that matter are the ones nobody has reported yet, because they belong to somebody’s actual router.

And then the false-positive shape, which is specific enough to be worth planning around. A large company egresses hundreds or thousands of employees through a handful of addresses. A tight per-IP limit does not block a bot farm; it blocks the third person at your enterprise prospect who tried to register for the webinar that morning.

That second sentence is the reason rate limiting is not optional even though it is insufficient. When your form builder meters you by the submission, an unmetered attack is a bill — and, past the cap, a closed door in front of the real buyer. See per-response pricing.

Always, at the edge, set to catch catastrophes rather than spam. A generous limit — say twenty submissions per address per hour — costs no real user anything and removes the outcome where you wake up to four thousand rows.

• Limit per address and per form, so a busy office does not inherit a limit calibrated for a contact page.
• Prefer challenging over refusing when you are near the threshold: escalate to Turnstile rather than returning an error.
• Block datacentre ASNs before you touch consumer ranges. That is most of the cheap traffic and almost none of your buyers.
• Alert on the limit firing. A rate limit that engages is the earliest warning you get that something has started.