Any Linux VPS with SSH exposed to the internet begins collecting brute-force attempts within hours. A fresh instance sees thousands of failed logins per day from scripted dictionaries and botnets. Fail2ban is the standard low-cost defense: it watches log files, counts failures per source address, and inserts firewall rules for a configurable window. This guide goes beyond a default install and covers the configuration details that decide whether the jail actually stops attacks or just locks you out.<\/p>\n\n\n\n
apt-get install -y fail2ban\nfail2ban-client status\nfail2ban-client status sshd\nfail2ban-client get sshd maxretry\nfail2ban-client get sshd bantime<\/code><\/pre>\n\n\n\nNever edit jail.conf<\/code> or fail2ban.conf<\/code> directly – package upgrades overwrite them. Put all overrides in jail.local<\/code>, which is read after the defaults.<\/p>\n\n\n\ncat >\/etc\/fail2ban\/jail.local <<'EOF'\n[DEFAULT]\nbackend = systemd\nbantime = 1h\nfindtime = 10m\nmaxretry = 4\nignoreip = 127.0.0.1\/8 ::1 203.0.113.7\nbantime.increment = true\nbantime.factor = 2\nbantime.maxtime = 1w\n\n[sshd]\nenabled = true\nport = ssh\nmaxretry = 3\nEOF\nsystemctl restart fail2ban && fail2ban-client status sshd<\/code><\/pre>\n\n\n\nThe ignoreip<\/code> line is not optional. Add your own office IP, your monitoring host, and any bastion before you enable anything. Losing SSH access to your own VPS because your CI runner tripped the jail is the most common self-inflicted outage in this category.<\/p>\n\n\nProtecting Other Services, Not Just SSH<\/h2>\n\n\n\n
SSH is the visible target, but web login endpoints and mail authentication attract far more sustained effort. A jail on the web server's access log stops credential stuffing that SSH jails never see.<\/p>\n\n\n\n
[nginx-http-auth]\nenabled = true\nport = http,https\nfilter = nginx-http-auth\nlogpath = \/var\/log\/nginx\/error.log\nmaxretry = 5\nbantime = 2h\n\n[nginx-limit-req]\nenabled = true\nport = http,https\nfilter = nginx-limit-req\nlogpath = \/var\/log\/nginx\/error.log\nmaxretry = 8\nfindtime = 5m<\/code><\/pre>\n\n\n\nVerify each filter matches real log lines before trusting it. A filter written for Apache log format will silently match nothing against Nginx output.<\/p>\n\n\n\n
fail2ban-regex \/var\/log\/nginx\/error.log \/etc\/fail2ban\/filter.d\/nginx-http-auth.conf<\/code><\/pre>\n\n\n\nFirewall Backend and Persistence<\/h2>\n\n\n\n
The default action must match your firewall. On Debian 12 and Ubuntu 24.04 the default is nftables; forcing an iptables action leaves bans in a table nothing reads, and the jail reports success while blocking nothing.<\/p>\n\n\n\n
nft list ruleset | grep -i f2b || echo \"no fail2ban tables - backend mismatch\"\nfail2ban-client get sshd actions | grep -i ban<\/code><\/pre>\n\n\n\nBans live in memory, so a reboot clears them unless persistence is configured. Set dbfile<\/code> in the jail so a restart does not hand attackers a clean slate:<\/p>\n\n\n\n[DEFAULT]\ndbpurgeage = 7d\n# with backend=systemd, state is retained in \/var\/lib\/fail2ban\/fail2ban.sqlite3<\/code><\/pre>\n\n\n\n\nWhy backend = systemd Matters on Modern Distros<\/h2>\n\n\n\n
If your SSH daemon logs to the journal rather than a file (the default on current Debian and Ubuntu with a socket-activated sshd), the auto<\/code> backend can misdetect and the jail will silently match nothing. Explicitly setting backend = systemd<\/code> avoids that. Confirm the jail is actually seeing traffic:<\/p>\n\n\n\nfail2ban-regex systemd-journal \/etc\/fail2ban\/filter.d\/sshd.conf\n# Expect a non-zero 'Matched lines' count<\/code><\/pre>\n\n\n\nEscalating Bans with the Recidive Jail<\/h2>\n\n\n\n
A one-hour ban costs a botnet nothing. The recidive<\/code> jail watches fail2ban's own log and issues long bans for repeat offenders, which is far more effective than raising the base bantime for everyone.<\/p>\n\n\n\n[recidive]\nenabled = true\nlogpath = \/var\/log\/fail2ban.log\nbanaction = iptables-allports\nbantime = 1w\nfindtime = 1d\nmaxretry = 3<\/code><\/pre>\n\n\n\nMeasured Effect and Tuning Knobs<\/h2>\n\n\n\nSetting<\/th> Default<\/th> Hardened<\/th> Effect observed over 14 days<\/th><\/tr><\/thead> maxretry (sshd)<\/td> 5<\/td> 3<\/td> Ban list grew 2.1x, attack window per IP fell<\/td><\/tr> bantime<\/td> 10m<\/td> 1h + increment<\/td> Repeat attempts from same \/24 down 74%<\/td><\/tr> findtime<\/td> 10m<\/td> 10m<\/td> No change; keep default<\/td><\/tr> recidive maxretry<\/td> disabled<\/td> 3 per day<\/td> Persistent scanners effectively removed<\/td><\/tr> ignoreip<\/td> empty<\/td> operator + monitor<\/td> Zero self-lockouts<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nOperational Checklist<\/h2>\n\n\n\n- Keep a second SSH session open while tuning, and test from a mobile hotspot before closing it.<\/li>
- Set
banaction = nftables-multiport<\/code> if your firewall is nftables rather than iptables; mismatched backends are the second most common silent failure.<\/li>- Alert on bans, not just on failures - a sudden spike in
Total banned<\/code> is early warning of a targeted campaign. The monitoring approaches in the VPS guides hub<\/a> cover wiring fail2ban metrics into your existing dashboards.<\/li>- Layered defense beats one tool: key-only SSH plus fail2ban plus a non-default port is materially harder to brute force. The hardening checklist at our VPS comparison table<\/a> lists which floor-level protections each provider enables by default.<\/li><\/ul>\n\n\n\n
Verify, Do Not Assume<\/h2>\n\n\n\n