fail2ban: answering brute-force attempts

Every server with open login endpoints knows the picture: night after night, the logs carry hundreds of failed login attempts, patient, automated. This background radiation is normal and mostly harmless, but it has a goal: eventually guessing a password. fail2ban is the classic answer to these attempts, and this post shows how we set it up so it helps in practice instead of merely running.

How fail2ban thinks

The core idea is simple and sturdy: fail2ban reads log output, from the journal or from files, and applies patterns that describe failed login attempts. When enough matches from the same address accumulate within a time window, it bans the address through a firewall rule that holds until the ban time expires. The building blocks are called jails. A jail connects a log source, a detection pattern and an action, and the shipped collection covers the usual suspects.

The most important jail at the start is the one for the server's own login endpoint. Two more are worth a look: the recidive jail, which bans addresses that were already banned and came back, and the jails for publicly reachable web surfaces, where they exist. What we avoid doing is enabling every shipped jail for coverage's sake: jails for services that do not exist on the server only add silent administrative weight without benefit.

The numbers that decide usefulness

A jail is as good as its thresholds. maxretry sets how many matches within findtime trigger a ban, bantime sets how long it lasts. The defaults are defensively chosen and often either too mild or too sharp for the reality of a specific team, depending on how much legitimate failure the operation carries. A team that occasionally mistypes passwords needs more room than a server that only knows machine accounts.

Two additions make the thresholds workable. First, the ignoreip list: our own administrative networks and gateways belong in it, so a forgotten configuration does not lock out our own administration. Care is warranted here, because the list creates blind spots: ignoring too generously opens the door for exactly the source the tool is meant to stop. Second, fail2ban-client status: it shows per jail how many addresses are currently banned and how many historically. Those numbers are the most honest gauge of whether the thresholds match the reality of the server.

What banning can and cannot do

fail2ban treats symptoms. The brute-force attempts do not stop; they just become uneconomical: a banned address loses time and attention without making progress. The structural goal sits one step earlier: services nobody needs from outside are not reachable from outside, and services that must face the open internet carry the hardening that belongs to them, with banning as the second line. In that order, fail2ban is the right hand of exposure control, not its replacement.

The cleanest way to move login endpoints out of reach is the encrypted path to them; the post WireGuard site to site in practice covers the setup.

The cleanest way to move login endpoints out of reach is the encrypted path to them; the post WireGuard site to site in practice covers the setup.

The cleanest way to move login endpoints out of reach is the encrypted path to them; the post WireGuard site to site in practice covers the setup.

The cleanest way to move login endpoints out of reach is the encrypted path to them; the post WireGuard site to site in practice covers the setup.

Two operational details complete the picture. First, the banning should interlock with the log system, so that bans remain traceable and flow into monitoring and reporting. A ban nobody knows about is only half a ban. Second, updates deserve attention: when a system upgrade changes a service's log output, a jail whose pattern no longer matches becomes silently ineffective. A twice-yearly review of the active jails against the real log lines is enough to catch that.

The starting point that holds

Teams starting fresh do best with a small, actively maintained configuration: one jail for the server login, recidive for repeaters, the jails for genuinely reachable surfaces where they exist, all with documented thresholds and an ignoreip list containing only our own networks. That configuration deserves the same seriousness as the rest of the server: it is part of the hardening, not an ornament.

What the numbers say after a quarter

After the first period with active jails, the collection deserves a look back. The banned addresses sort, in our experience, into three groups: the large mass of single attempts that the thresholds process cleanly; a small group of recurring addresses that the recidive jail handles; and occasionally an outlier whose pattern makes one think, because it comes too fast or too specifically. That third group is the real yield of the statistics: it shows attack patterns that would have stayed invisible as background noise.

The second yield is negative and just as valuable: bans hitting our own addresses appear in the first weeks with high probability. Each of those cases is a configuration gap found now instead of during an emergency: a monitoring system missing from the ignoreip list, a job with wrong credentials, a transit network nobody had on the list. Whoever reads those alerts as gifts rather than disturbances ends a quarter with a ban configuration that fits the own environment instead of the template.

A look at measurability belongs to the topic, because banned addresses otherwise vanish silently: whoever does not know how many attempts there were and from which networks cannot assess the trend of recent months. The small upgrade is exporting the ban list into monitoring, there as a number per jail and as a sum over time. Two questions these numbers answer reliably: is the background radiation growing, and is its pattern changing? Both matter more for hardening planning than any single banned address, because they say whether the exposure of the landscape stays stable or shifts.

If you want your login endpoints systematically hardened against brute force, or want a second pair of eyes on existing ban rules, the security hardening and audits page describes the matching service, and the contact page is the fastest way to reach us.

Sources

• fail2ban project, repository and README, https://github.com/fail2ban/fail2ban (accessed 2026-11-03)
• fail2ban-client(1) manual page, https://man.archlinux.org/man/fail2ban-client.1.en (accessed 2026-11-03)
• jail.conf(5) manual page, https://man.archlinux.org/man/jail.conf.5.en (accessed 2026-11-03)