fail2ban

fail2ban watches log files for patterns indicating failed authentication and adds firewall rules blocking the source address after a threshold. A jail is a combination of a log file, a filter defining the failure pattern, and an action, with a ban duration.

It is old, simple, and does one thing. That narrowness is the reason it remains worth deploying.

What it actually accomplishes

It does not stop a determined attacker. Anyone with a botnet distributes attempts across enough addresses that per-address thresholds never trigger.

What it stops is the automated background noise of the internet, which is the overwhelming majority of what an internet-facing host sees. Any host with SSH on port 22 receives continuous credential-stuffing attempts from compromised machines running the same script against the whole address space. fail2ban removes essentially all of it.

The value is as much operational as it is security. Logs full of thousands of daily failed attempts are logs nobody reads, and a real anomaly is invisible in that volume. Cutting the noise makes the remaining entries meaningful, which matters more for detection than the blocking does.

Configuration that matters

Never edit jail.conf. Put overrides in jail.local, or package upgrades will overwrite the configuration.

Ban duration is the trade to think about. Long bans are more effective and more likely to lock out a legitimate user with a bad password and a fixed IP. Incremental banning — short first offence, escalating on repeats — handles both, and is what I would use.

ignoreip for known-good networks is worth setting before the first lockout rather than after. Locking yourself out of a remote host is the characteristic fail2ban experience.

Where it sits now

It is showing its age. It parses logs with regular expressions, which is fragile when log formats change, and it acts only on what a single host observes. CrowdSec addresses both — modern parsing, and shared reputation across participating installations so an address attacking someone else can be blocked before it reaches you.

I would not consider fail2ban the strongest option available. I would consider it the one most likely to be running correctly, because it is simple enough to configure once and forget, and a defence that is actually deployed beats a better one that is half-configured.

See also: CrowdSec, nftables which enforces the bans, OpenSSH, and host hardening patterns.