Security: advanced Rack Attack
This course extends Rack::Attack from throttling to banning. It explains why a throttle has no memory across windows and how Fail2Ban and Allow2Ban add that memory through maxretry, findtime and bantime. The lessons cover escalation ladders with capped exponential backoff, tiered throttle windows and the problems with permanent bans. They also cover signals beyond request counts, the split between the edge and the application, challenges, instrumentation, blocked-page design and unban commands. The final lesson assembles a layered defense with a track-first rollout.
What you'll learn
- ✓How Fail2Ban and Allow2Ban differ and when to use each
- ✓Escalating bans with capped exponential backoff and tiered throttles
- ✓Combining request signals such as paths, headers and honeypot fields into a score
- ✓Which defenses belong at the edge and which belong in the application
- ✓Instrumenting, alerting on and reviewing ban rules, including an unban path
- ✓Rolling out rules as track first and converting them based on data
From throttling to banning
The previous course ended with a working set of throttles: sign-in limited by address and by account, signup and password reset bounded, a general volume limit. Against a script that hammers as fast as it can, that is enough.
Read the full lesson free →Curriculum
7 lessonsFrom throttling to banning
Why a throttle has no memory across windows, and how banning with maxretry, findtime and bantime adds it.
Fail2Ban and Allow2Ban
How Fail2Ban counts suspicious requests, Allow2Ban counts every matching request, and why ban keys need a namespace.
Escalation and backoff
Escalation ladders, capped exponential backoff with expiring offense counts, tiered throttles, and the case against permanent bans.
Signals beyond the count
Paths, headers, honeypot fields and timing as signals, combined into a score that tracks the middle band first.
The edge, and what your app should not do
What the edge should reject, what only the application knows, client IP headers behind a CDN, and challenges.
Abuse response and operations
Instrumenting rack_attack events, alerting on ban rates, designing the blocked page, and building a recorded unban path.
Putting it together: a layered defense
A six-layer defense configuration, a track-first rollout, and the limits of what rate limiting and banning stop.