fail2ban: block repeated failed logins

fail2ban watches log files or the systemd journal for failed logins and adds a temporary firewall rule for any address that fails too often. It does not make a weak password strong, but it turns thousands of guesses per hour into a handful, keeps the logs readable and makes brute force against any service with a log unattractive.

Install

# Debian / Ubuntu
sudo apt install -y fail2ban

# RHEL / Rocky / Alma (from EPEL)
sudo dnf install -y epel-release
sudo dnf install -y fail2ban

sudo systemctl enable --now fail2ban
sudo fail2ban-client status

On Debian 12 the service fails to start right after installation if rsyslog is not installed, because the default sshd jail looks for /var/log/auth.log, which does not exist on a journal-only system. The configuration below fixes that by reading the journal instead.

Configure: jail.local, never jail.conf

/etc/fail2ban/jail.conf is overwritten on updates. Put your settings in /etc/fail2ban/jail.local (or a file in jail.d/), which is read afterwards and overrides it.

sudo tee /etc/fail2ban/jail.local >/dev/null <<'EOF'
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 ::1 203.0.113.10 198.51.100.0/24
bantime.increment = true
bantime.maxtime = 1w

[sshd]
enabled = true
backend = systemd
mode    = aggressive
EOF

sudo fail2ban-client reload
sudo fail2ban-client status sshd

• maxretry failures within findtime lead to a ban of bantime. Units: m, h, d, w.
• ignoreip: addresses that are never banned. Careful: put your own office, home or VPN address here before you start testing; a ban applies to you too, and from a banned address you cannot even log in to lift it.
• bantime.increment = true: an address that comes back after a ban is banned for longer each time, up to bantime.maxtime.
• backend = systemd: read the journal instead of a log file. Works everywhere systemd is used and avoids the Debian 12 problem above.
• mode = aggressive for sshd also matches preauth disconnects and other noise that the default mode ignores.

See who is banned, and unban

sudo fail2ban-client status                 # list of active jails
sudo fail2ban-client status sshd            # counts and currently banned addresses
sudo fail2ban-client banned                 # every ban in every jail

sudo fail2ban-client set sshd unbanip 203.0.113.55
sudo fail2ban-client unban --all            # lift every ban

sudo fail2ban-client set sshd banip 203.0.113.99   # ban by hand
sudo journalctl -u fail2ban -n 50           # what it did and why

The bans themselves are nftables or iptables rules in a chain named after the jail (f2b-sshd); sudo nft list ruleset | grep f2b shows them if you want to see the mechanism.

Protect another service

fail2ban ships filters for many programs in /etc/fail2ban/filter.d/ (nginx, Postfix, Dovecot, vsftpd and more). Enabling one is a section in jail.local that names the log file:

[nginx-http-auth]
enabled  = true
logpath  = /var/log/nginx/error.log

[nginx-botsearch]
enabled  = true
logpath  = /var/log/nginx/access.log
maxretry = 2

Before enabling a jail, confirm the filter actually matches your log lines:

sudo fail2ban-regex /var/log/nginx/error.log /etc/fail2ban/filter.d/nginx-http-auth.conf

The output ends with how many lines matched. Zero matches means the jail will never ban anyone, usually because the log format differs; the filter files are small regular expressions you can adapt in a .local copy.

Does it replace other measures?

No. With SSH passwords disabled, fail2ban is mostly about log noise and load. Attackers with many addresses are barely slowed down. The order of importance is keys only, a firewall that exposes little, then fail2ban. For services behind a reverse proxy, make sure the real client address reaches the log (the X-Forwarded-For header and your proxy’s configuration), otherwise fail2ban bans the proxy itself.

Official documentation

• fail2ban wiki
• jail.conf(5)
• fail2ban-client(1)