Configuring and managing Fail2Ban on Linux

This article explains how Fail2Ban works, how to configure it, and how to use common administration commands. Aimed at administrators securing a Linux server against brute force attacks.

Requirements

- Linux server with root access or sudo privileges - Fail2Ban version 0.11.x or 1.x (check with `fail2ban-client --version`) - An active firewall: `ufw`, `iptables`, or `nftables` - Access to log files in `/var/log/` (standard on Debian/Ubuntu)

Steps

1. Check the Fail2Ban version

fail2ban-client --version

Fail2Ban 1.x is the current stable release. Version 0.11.x is still supported but no longer receives new features. The commands in this article work on both versions.

2. Check if the server is running

fail2ban-client ping

The server should respond with `PONG`. If you see `Fail2Ban is not running`, start the service with:

sudo systemctl start fail2ban

3. View the status of a jail

A jail is a rule set that determines which log file is followed, which patterns are searched for, and which action is taken after repeated failed attempts. The default SSH jail is called `sshd`.

fail2ban-client status sshd

This shows the number of currently banned IP addresses, the total bans, and the active firewall rules.

4. Manually add an IP address to a jail

sudo fail2ban-client set sshd banip 203.0.113.25

This blocks the IP address immediately, without waiting for the threshold. Use this for IP addresses you are certain are malicious.

5. Remove an IP address from a jail

sudo fail2ban-client set sshd unbanip 203.0.113.25

This removes the IP address directly from the ban table and lifts the firewall rule. Useful for false positives or after resolving an issue.

6. Test a regular expression with fail2ban-regex

fail2ban-regex /var/log/auth.log 'sshd.<em>Failed password.</em>from <HOST>'

This tests whether the `failregex` patterns in your filter configuration actually match lines in your log file. Replace `` with the IP address you want to match. The command shows how many lines were recognized and which were not.

7. Configure a jail in jail.local

Create a local configuration file that overrides the default values:

sudo nano /etc/fail2ban/jail.local

Add this for an SSH jail with custom thresholds:

[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h

- `maxretry`: number of failed attempts before a ban is imposed - `findtime`: time window within which the attempts must occur - `bantime`: duration of the block in seconds (or with a suffix like `1h`)

Restart Fail2Ban after configuration changes:

sudo systemctl restart fail2ban

8. View the firewall rules managed by Fail2Ban

sudo iptables -L f2b-sshd -n

This shows the active Fail2Ban firewall rules for the sshd jail. The chain `f2b-sshd` contains all banned IP addresses. With `nftables`, use `sudo nft list ruleset` and filter for `f2b-`.

Verification

Check if Fail2Ban is functioning correctly:

sudo fail2ban-client status

This shows all active jails. For each jail, you see the number of banned IP addresses. To confirm that a specific IP address is blocked:

sudo fail2ban-client status sshd | grep "Banned IP list"

An empty list means no IP addresses are blocked. That is normal on a well-secured server.

Common issues

Fail2Ban does not start after a configuration change

Check the configuration for syntax errors:

sudo fail2ban-client -t

This tests all configuration files and shows any errors. Common cause: a missing `[DEFAULT]` section or an invalid `bantime` format.

IP addresses are not blocked despite failed attempts

Check whether the correct log file is being followed. On systems with systemd-journald, you may need to adjust the jail:

[sshd]
backend = systemd

Then test whether the log lines are recognized:

sudo fail2ban-regex systemd[sshd] 'sshd.*Failed password'

Fail2Ban blocks legitimate users

Increase `maxretry` or decrease `findtime` in `jail.local`. You can also set up a whitelist:

[DEFAULT]
ignoreip = 127.0.0.1/8 192.168.1.0/24

This prevents IP addresses from these ranges from being blocked. Note: `ignoreip` applies to all jails. The server itself rarely runs as root, which limits the impact of a vulnerability in Fail2Ban — but an incorrect `ignoreip` configuration can exclude an entire subnet from security.

Fail2Ban reads log files like `/var/log/auth.log` and activates firewall rules via `fail2ban-server`, while `fail2ban-client` provides the configuration interface via a socket connection. This separation between server and client keeps the system stable, but it also means you should always check both processes when making changes — a server running with an outdated configuration is just as dangerous as a server that is not running.

← Back to knowledge base