Rate limiting
Restricting how many requests or connection attempts a single source can make within a given time window, used to slow down brute-force and scraping attempts without blocking legitimate users outright.
Where it fits alongside other defenses
Rate limiting does not stop a brute-force or scraping attempt outright; it slows it down enough that the attack becomes impractical, while still letting legitimate users who occasionally mistype a password through without being locked out.
Common places to apply it
SSH login attempts, web application login forms, and API endpoints are the three most frequently targeted surfaces, and each typically needs its own rate limit tuned to normal usage patterns for that specific service.
Frequently asked questions
Does rate limiting replace the need for a firewall?
No, they solve different problems. A firewall controls which connections are allowed to reach a service at all; rate limiting controls how fast an already-allowed connection can repeat an action.
Can rate limiting block legitimate users by mistake?
Yes, if set too aggressively, particularly for users sharing a single outbound IP address such as an office network. Limits should be tuned against real traffic patterns, not just guessed.
What is a typical tool used for this on Linux?
fail2ban is the most common choice for SSH and other log-based services, while nginx and most web frameworks have their own built-in rate-limiting modules for HTTP traffic.
Want to see where your own server stands?
Run the free, read-only server check, or open the Security Lab and watch the detect, contain, recover, verify loop in action.
Get your free server checkOpen the Security Lab