Fail2Ban best practices

Fail2Ban best practices

Recommended patterns for Fail2Ban jail configuration, firewall backend selection, and IP whitelisting.

Always Use jail.local Instead of Editing jail.conf in Fail2Ban

Fail2Ban's jail.conf is overwritten by package updates. Create /etc/fail2ban/jail.local for all customizations. Fail2Ban reads jail.local after jail.conf, and local settings override default values.

Set the Correct Firewall Backend for Fail2Ban

Fail2Ban defaults to iptables, but modern distributions use nftables. A mismatched backend causes bans that do not block traffic. Check the active firewall ( nft list ruleset or ufw status) and set banaction accordingly in jail.local.

Whitelist Administrator IPs in Fail2Ban

Add the administrator's IP address or office CIDR range to ignoreip in jail.local to prevent accidental lockouts. This is especially important on servers with strict maxretry settings.

Use backend = systemd for Journal-Based Services in Fail2Ban

Services that log to the systemd journal (SSH, Nginx on modern distributions) require backend = systemd for Fail2Ban to detect failures. The default backend = auto may select file-based monitoring on systems without traditional log files, causing Fail2Ban to miss events.

Set Progressive Ban Times in Fail2Ban

Fail2Ban supports bantime.increment = true to progressively increase ban duration for repeat offenders. A first offense gets a short ban; subsequent bans from the same IP grow exponentially. Configure this in jail.local:

[DEFAULT]
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 1w

Test Filters Before Activating Fail2Ban Jails

Always run fail2ban-regex against real log data before enabling a new jail. A filter with no matches provides no protection. A filter that is too broad bans legitimate users.