{"id":851,"date":"2026-08-10T23:24:25","date_gmt":"2026-08-10T23:24:25","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=851"},"modified":"2026-09-23T22:03:58","modified_gmt":"2026-09-23T22:03:58","slug":"fail2ban-setup-vps-ssh-bruteforce-protection","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/fail2ban-setup-vps-ssh-bruteforce-protection\/","title":{"rendered":"Custom Fail2ban Filters and Recidive Jails for VPS Bruteforce Defense"},"content":{"rendered":"\n

The default sshd<\/code> jail in Fail2ban bans an IP after repeated failures \u2014 but the moment an attacker rotates source addresses, a per-IP ban is worthless. This article focuses on what most tutorials skip: writing custom filters for services that log in non-standard formats, using recidive<\/code> to catch repeat offenders across jails, and testing filters before they go live. Set the base protections up first, then extend with the jails below.<\/p>\n\n\n\n

Diagnose which jail is doing the work<\/h2>\n\n\n\n

Before tuning blind, confirm what is actually being banned. The default sshd<\/code> jail catches password guesses, but if your box only allows key auth, most failures are pre-auth probes that still count. Look at the distribution of banned addresses over a week.<\/p>\n\n\n\n

grep \" Ban \" \/var\/log\/fail2ban.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head\nfail2ban-client status sshd<\/code><\/pre>\n\n\n\n
If the same source subnet keeps reappearing after short bans, the default bantime<\/code> is too short for that source. That is the exact case the escalating and recidive jails are built for.<\/p>\n\n\n\n
Confirm what is actually being banned<\/h2>\n\n\n\n
Before adding jails, check the numbers. On a default instance the log tells the truth; a grep over the last day shows the real attack surface.<\/p>\n\n\n\n
journalctl -u ssh --since yesterday | grep -c \"Failed password\"\nfail2ban-client status sshd<\/code><\/pre>\n\n\n\n
If status sshd<\/code> shows a healthy ban count but failures keep climbing, the noise is distributed across many single-shot IPs. That is the signal to move to aggregated bans.<\/p>\n\n\n\n
Write a custom filter for a non-standard log<\/h2>\n\n\n\n
Fail2ban ships filters for common services only. For anything else, point a filter at the log and give it a regex with a named <HOST><\/code> group. Example for an app that writes JSON lines to its own log:<\/p>\n\n\n\n
# \/etc\/fail2ban\/filter.d\/myapp.conf\n[Definition]\nfailregex = ^.*\"ip\":\"<HOST>\".*\"event\":\"auth_fail\".*$\nignoreregex =<\/code><\/pre>\n\n\n\n
Test the filter before enabling it<\/h2>\n\n\n\n
A wrong regex bans innocent traffic. Always dry-run against real log lines.<\/p>\n\n\n\n
fail2ban-regex \/var\/log\/myapp\/access.log \/etc\/fail2ban\/filter.d\/myapp.conf<\/code><\/pre>\n\n\n\n
The output shows matched and missed lines. Only wire the filter into a jail once the match count is non-zero and the missed lines are genuinely unrelated traffic.<\/p>\n\n\n\n
Catch repeat offenders with recidive<\/h2>\n\n\n\n
Single-IP bans expire. The recidive<\/code> jail watches Fail2ban’s own log for IPs that trigger multiple bans, then applies a long ban. That is what turns a nuisance filter into a real deterrent.<\/p>\n\n\n\n
# \/etc\/fail2ban\/jail.d\/recidive.local\n[recidive]\nenabled  = true\nlogpath  = \/var\/log\/fail2ban.log\nbanaction = iptables-allports\nbantime  = 1w\nfindtime = 1d\nmaxretry = 3<\/code><\/pre>\n\n\n\n
Setting<\/th>Nuisance jail<\/th>Recidive jail<\/th><\/tr><\/thead>
bantime<\/td>1h<\/td>1w<\/td><\/tr>
findtime<\/td>10m<\/td>1d<\/td><\/tr>
maxretry<\/td>5<\/td>3<\/td><\/tr>
Scope<\/td>Single service<\/td>All ports<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Whitelist before you widen the net<\/h2>\n\n\n\n
Aggressive jails ban everything they see. Protect your own access and monitoring before enabling them.<\/p>\n\n\n\n
# \/etc\/fail2ban\/jail.d\/ignoreips.local\n[DEFAULT]\nignoreip = 127.0.0.1\/8 ::1 203.0.113.7 198.51.100.0\/24<\/code><\/pre>\n\n\n\n