fail2ban: Log-Scanning Intrusion Prevention

fail2ban is a log-scanning intrusion prevention daemon: it tails service logs (e.g. `/var/log/auth.log` or journald), matches repeated failures against regex filters, and temporarily bans the offending IP by inserting iptables/nftables rules. Core model — a *jail* combines a log source, a *filter* (regexes defining a failure), and an *action* (usually a firewall ban). Key parameters: `maxretry` (failures allowed), `findtime` (window in which they must occur), and `bantime` (how long the ban lasts). Local config belongs in `/etc/fail2ban/jail.local` or drop-in files — never edit `jail.conf`, which package upgrades overwrite. A typical SSH jail: 5 failures within 600 seconds bans the IP for 3600 seconds. If SSH runs on a non-standard port, the jail's `port` setting must be updated to match or bans won't apply to the actual traffic (see Hardening SSH on Ubuntu). Operational notes: - `fail2ban-client status sshd` lists currently banned IPs; `fail2ban-client set sshd unbanip X.X.X.X` lifts a ban — including your own after locking yourself out. - fail2ban is mitigation, not primary defense: with password authentication disabled and key-only login, brute force is already ineffective — fail2ban then mainly cuts log noise and resource waste. - A fail2ban ban resets connections before key exchange, so it can be the hidden cause of kex_exchange_identification "connection reset" errors for legitimate users (see SSH kex troubleshooting). - Limits: largely ineffective against distributed brute force (each IP stays under `maxretry`), and behind a reverse proxy it bans the proxy's IP unless configured to see real client addresses. Background: created by Cyril Jaquier and first released in October 2004; written in Python and licensed under GPLv2. Still actively maintained (1.1.x as of 2026), with both IPv4 and IPv6 support.