Fail2Ban is an excellent foundational defense against brute force attacks, but layering additional protections provides more robust, defense-in-depth security. This guide covers complementary measures.
Fail2Ban as the Foundation
See How to Install and Configure Fail2Ban on Ubuntu & Debian — the starting point, automatically banning IPs showing repeated failed authentication attempts across SSH and other monitored services.
Layer 1: SSH Key-Only Authentication
See SSH Hardening: Change the Port, Disable Root Login & Use SSH Keys — disabling password authentication entirely for SSH eliminates brute force as a viable attack vector for that service altogether, a far stronger defense than any ban-based approach alone.
Layer 2: Rate Limiting at the Network/Firewall Level
sudo ufw limit 22/tcpUFW's limit action specifically throttles repeated connection attempts to a port, providing protection even before Fail2Ban's log-based detection kicks in.
Layer 3: Application-Level Rate Limiting
See How to Rate Limit an API with Nginx — for web application login forms specifically, rate limit at the Nginx/application layer, not just relying on SSH-focused tools for web-based brute force attempts.
Layer 4: Two-Factor Authentication
See How to Enable Two-Factor Authentication (2FA) for SSH on a Linux VPS — even if credentials are somehow obtained, 2FA prevents successful authentication without the second factor, a strong defense beyond just preventing brute force attempts.
Layer 5: IP Allowlisting for Sensitive Endpoints
See How to Set Up Nginx Access Control by IP Address or Geolocation — for admin panels or particularly sensitive login endpoints, restricting access to known trusted IPs eliminates brute force risk from unknown sources entirely.
Layer 6: CAPTCHA for Web-Based Login Forms
Adding CAPTCHA challenges to login forms after a few failed attempts significantly slows down automated brute force tools, complementing rate limiting for web application authentication specifically.
Layer 7: Account Lockout Policies
For application-level authentication, consider temporary account lockout after repeated failed attempts — balance security against the risk of a malicious actor deliberately locking out a legitimate user's account (a denial-of-service consideration worth thinking through).
Layer 8: Monitoring and Alerting
See How to Monitor Auth Logs and Detect Intrusion Attempts on a Linux VPS — even with strong preventive layers, monitoring gives you visibility into attack attempts and confirms your defenses are actually working as intended.
Layer 9: Using a Non-Default Port for SSH
See SSH Hardening: Change the Port, Disable Root Login & Use SSH Keys — reduces exposure to automated scanners specifically targeting the default SSH port, though genuinely targeted attackers can still discover non-default ports.
Building a Defense-in-Depth Strategy
No single measure is perfect alone — combining several layers means a determined attacker must overcome multiple independent defenses, dramatically raising the practical difficulty compared to relying on any single protective measure.
Common Errors
Overly aggressive rate limiting blocks legitimate users — tune thresholds based on realistic legitimate usage patterns; too strict a limit creates its own usability/denial-of-service problem for genuine users.
Continue Reading
- How to Install and Configure Fail2Ban on Ubuntu & Debian
- How to Enable Two-Factor Authentication (2FA) for SSH on a Linux VPS
- How to Rate Limit an API with Nginx
Browse more articles in Server Security & Hardening.
