How to Install Fail2Ban on Ubuntu (26.04, 24.04, 22.04)

This guide walks through how to install Fail2Ban on Ubuntu, configure its jails, and manage bans from the command line. Fail2Ban is a log-parsing security framework that monitors service logs for suspicious activity, such as repeated failed login attempts, and automatically bans offending IP addresses by updating firewall rules. It is highly configurable, allowing administrators to define custom filters, ban durations, and actions for any networked service.

Ubuntu ships Fail2Ban in its default repositories, so installation takes a single APT command. The sections below cover the SSHD jail, UFW integration, incremental ban timing, log monitoring, and removal. All commands are tested on Ubuntu 26.04, 24.04, and 22.04 LTS.

Update Ubuntu Before Installing Fail2Ban

Refresh your package metadata and bring existing packages current so Fail2Ban installs against the latest dependencies. Use the following command to update everything in one pass:

sudo apt update && sudo apt upgrade

This command pulls current repository data and upgrades any pending packages, reducing the chance of dependency conflicts during the Fail2Ban install.

Some commands in this guide use sudo. If your account is not yet in the sudo group, see how to add a user to sudoers on Ubuntu.

Default Fail2Ban Versions by Ubuntu Release

Fail2Ban version and default configuration differ across Ubuntu LTS releases. The following table summarizes each version, its default firewall backend, and the SSHD log backend:

Ubuntu Release	Default Fail2Ban	Firewall Backend	SSHD Log Backend
Ubuntu 26.04	Fail2Ban 1.1.x	nftables	systemd (explicit journalmatch)
Ubuntu 24.04	Fail2Ban 1.0.x	nftables	systemd
Ubuntu 22.04	Fail2Ban 0.11.x	iptables-multiport	auto (file-based)

These steps cover Ubuntu 26.04 LTS, 24.04 LTS, and 22.04 LTS. While the Fail2Ban version and firewall backend differ between releases, all installation and configuration commands remain identical across supported LTS versions.

Install Fail2Ban from Ubuntu Default Repositories

Fail2Ban is available in Ubuntu’s default repositories, so a single APT command installs it with the correct dependencies and registers the service with systemd:

sudo apt install fail2ban

Confirm the binary is ready by checking its version:

fail2ban-client --version

Expected output on Ubuntu 26.04 (version varies by release; see the comparison table above):

Fail2Ban v1.1.0

Enable and Verify the Fail2Ban Service on Ubuntu

Enable the systemd unit so Fail2Ban starts immediately and persists after reboots:

sudo systemctl enable fail2ban --now

Confirm the service is healthy:

sudo systemctl status fail2ban

The output confirms the service is active and running:

● fail2ban.service - Fail2Ban Service
     Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2026-02-05 14:23:45 UTC; 2min ago
       Docs: man:fail2ban(1)
   Main PID: 12345 (fail2ban-server)
      Tasks: 5 (limit: 4915)
     Memory: 12.4M
        CPU: 245ms
     CGroup: /system.slice/fail2ban.service
             └─12345 /usr/bin/python3 /usr/bin/fail2ban-server -xf start

Feb 05 14:23:45 ubuntu systemd[1]: Started Fail2Ban Service.
Feb 05 14:23:46 ubuntu fail2ban-server[12345]: Server ready

Protect Fail2Ban Configuration Files on Ubuntu

Fail2Ban ships with baseline configuration in /etc/fail2ban/jail.conf and /etc/fail2ban/jail.d/defaults-debian.conf. Editing those files directly invites merge conflicts during package upgrades because APT overwrites .conf files. Instead, create minimal .local override files that contain only the settings you change.

Fail2Ban reads .local files after their .conf counterparts and merges only the keys you define, so your overrides survive upgrades while upstream defaults continue to apply for everything else.

Create a blank override file for jail settings:

sudo touch /etc/fail2ban/jail.local

You will populate this file with specific overrides in the sections that follow. There is no need to copy the entire jail.conf; keeping jail.local minimal makes it easier to audit what you changed.

Customize Fail2Ban Jails and Defaults on Ubuntu

With your .local files in place, tailor Fail2Ban to match your services and threat model. The following examples highlight common tweaks you can drop into /etc/fail2ban/jail.local; adjust values to reflect the services, log locations, and ban policies in your environment.

Edit Fail2Ban Configuration File

Open the jail.local file in your preferred editor (Nano shown below) to start applying overrides:

sudo nano /etc/fail2ban/jail.local

Add only the directives you want to override. Fail2Ban merges jail.local on top of jail.conf, so any key you omit falls back to its upstream default.

Tune Ban Time for Repeat Offenders

Escalating ban durations discourages persistent attackers who rotate addresses. Enable incremental bans by setting the following values inside the [DEFAULT] section:

bantime.increment = true
bantime.factor = 2
bantime.formula = ban.Time * (1<<(ban.Count if ban.Count<20 else 20)) * banFactor

Setting bantime.factor = 2 doubles the penalty for each subsequent offense (up to 20 iterations). Inside the formula, the variable name is banFactor (camelCase), which Fail2Ban maps from the bantime.factor setting automatically.

Whitelist Trusted IP Addresses

Whitelist administration networks so legitimate maintenance sessions do not trigger bans. Edit the ignoreip directive and include single IPs or CIDR ranges separated by spaces:

ignoreip = 127.0.0.1/8 ::1 192.0.2.10

Stick to the minimal set of addresses you control; avoid whitelisting broad ISP ranges because a compromised host inside that range could bypass Fail2Ban entirely.

Define Global Ban Timings

Fail2Ban’s [DEFAULT] section governs how quickly hosts are banned and for how long. Tune the following baseline values, then override them per jail when a service needs stricter or looser limits:

[DEFAULT]
bantime = 10m
findtime = 10m
maxretry = 5

These defaults ban a host for ten minutes after five failed attempts inside a ten-minute window. Increase the bantime or lower maxretry for exposed services like SSH.

Configure Email Alerts

Email notifications keep you informed about bans without tailing logs. Define the destination, sender, and action template inside [DEFAULT]:

[DEFAULT]
destemail = admin@example.com
sender = fail2ban@example.com
action = %(action_mwl)s

The action = %(action_mwl)s shortcut emails a report with WHOIS data and the relevant log excerpt. Replace the addresses with mailboxes you monitor and ensure the host can relay mail (via Postfix, msmtp, or another MTA).

Enable or Customize Individual Jails

Each jail pairs a log filter with an action (firewall ban, Cloudflare API call, etc.). Enable only the jails that apply to the services you run so Fail2Ban watches the right log files without wasting CPU.

Set enabled = true inside the jail definition to turn it on:

[apache-badbots]
enabled = true
port     = http,https
logpath  = %(apache_access_log)s
bantime  = 48h
maxretry = 1

You can also swap in actions from /etc/fail2ban/action.d/ to call out to services like Cloudflare or custom scripts:

[apache-botsearch]
enabled = true
port     = http,https
logpath  = %(apache_error_log)s
banaction = cloudflare
bantime = 72h
maxretry = 1

Once you’ve finished editing, reload or restart Fail2Ban to apply the new rules:

sudo systemctl restart fail2ban

Configure the SSHD Jail on Ubuntu

The SSHD jail is enabled by default through /etc/fail2ban/jail.d/defaults-debian.conf. You can tighten its settings by adding an [sshd] section to /etc/fail2ban/jail.local:

[sshd]
enabled  = true
port     = ssh
maxretry = 3
findtime = 10m
bantime  = 1h

This overrides the global defaults and bans a host for one hour after three failed SSH login attempts within ten minutes. Adjust port if you run SSH on a non-standard port (e.g., port = 2222).

On Ubuntu 24.04 and 26.04, defaults-debian.conf sets the SSHD backend to systemd and uses nftables for banning. On Ubuntu 22.04, the defaults use file-based log monitoring and iptables-multiport. You do not need to change these values manually; the distro-provided defaults handle the differences.

Restart Fail2Ban after editing the jail, then verify the SSHD jail is active:

sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

Expected output:

Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- Journal matches:	_SYSTEMD_UNIT=ssh.service + _COMM=sshd
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:	

Use Fail2Ban with UFW on Ubuntu

Ubuntu systems commonly use UFW as their firewall. Fail2Ban ships a dedicated ufw ban action at /etc/fail2ban/action.d/ufw.conf, so bans appear as UFW deny rules instead of raw iptables or nftables entries.

To switch the SSHD jail to UFW, add the following to /etc/fail2ban/jail.local:

[sshd]
banaction = ufw

You can also set ufw as the default ban action for all jails by placing it under [DEFAULT]:

[DEFAULT]
banaction = ufw

Restart Fail2Ban to apply the change, then trigger a test ban to confirm UFW receives the rule:

sudo systemctl restart fail2ban
sudo ufw status numbered

Banned IPs appear as numbered UFW deny rules that Fail2Ban manages automatically.

Manage Fail2Ban Bans with fail2ban-client on Ubuntu

The fail2ban-client utility lets you ban or unban hosts, inspect jail stats, and reload configuration without touching service files directly. Run it with sudo so the command can communicate with the Fail2Ban socket.

Ban an IP Address Manually

Manually ban a host when you spot suspicious activity before Fail2Ban triggers automatically. Target the affected jail:

sudo fail2ban-client set apache-botsearch banip 203.0.113.50

The command confirms the ban:

1

Unban an IP Address

Lift a ban after troubleshooting or if a legitimate user locked themselves out:

sudo fail2ban-client set apache-botsearch unbanip 198.51.100.10

Swap 198.51.100.10 for the offending host’s address and update the jail name to match your configuration.

View fail2ban-client Help

To access the help menu and view additional settings or commands, use the following command:

sudo fail2ban-client -h

More fail2ban-client Examples

Check a jail’s status to review failure counters and active bans:

sudo fail2ban-client status apache-botsearch

The output displays jail statistics and currently banned IPs:

Status for the jail: apache-botsearch
|- Filter
|  |- Currently failed: 2
|  |- Total failed:     15
|  `- File list:        /var/log/apache2/error.log
`- Actions
   |- Currently banned: 1
   |- Total banned:     3
   `- Banned IP list:   203.0.113.42

Alternatively, reload the configuration without restarting the Fail2Ban service:

sudo fail2ban-client reload

Print the “Banned IP list” section for a specific jail to review every blocked address:

sudo fail2ban-client status apache-botsearch | grep -A1 "Banned IP list"

These commands cover the daily management tasks you’ll reach for most often; substitute your actual IP addresses and jail names whenever you issue them.

Monitor Fail2Ban Logs on Ubuntu

Review /var/log/fail2ban.log regularly so you catch misconfigured jails or unexpected brute-force patterns early.

Watch Logs in Real Time

Use the tail command to follow new entries as they occur. Prefix with sudo unless your user belongs to the adm group:

sudo tail -f /var/log/fail2ban.log

This stream lets you confirm bans in real time while testing new filters:

2026-02-05 14:25:13,456 fail2ban.filter         [12345]: INFO    [sshd] Found 203.0.113.89 - 2026-02-05 14:25:13
2026-02-05 14:25:45,234 fail2ban.filter         [12345]: INFO    [sshd] Found 203.0.113.89 - 2026-02-05 14:25:45
2026-02-05 14:26:02,567 fail2ban.actions        [12345]: NOTICE  [sshd] Ban 203.0.113.89
2026-02-05 14:26:03,123 fail2ban.filter         [12345]: INFO    [apache-badbots] Found 198.51.100.15 - 2026-02-05 14:26:03
2026-02-05 14:26:15,890 fail2ban.actions        [12345]: NOTICE  [apache-badbots] Ban 198.51.100.15

Search Logs for Specific Events

Use grep to zero in on patterns, user agents, or IP addresses of interest:

User-Agent Example:

sudo grep "Bing" /var/log/fail2ban.log

Error Example:

sudo grep "error" /var/log/fail2ban.log

IP Address Example:

sudo grep "123.123.123.1" /var/log/fail2ban.log

Combining tail and grep gives you quick insight into how each jail behaves and whether additional tuning is necessary.

Troubleshoot Fail2Ban on Ubuntu

If Fail2Ban does not behave as expected, work through these common scenarios.

Fail2Ban Service Does Not Start

A syntax error in jail.local is the most frequent cause. Check the journal for the exact error:

sudo journalctl -u fail2ban --no-pager -n 20

Fix the reported line in /etc/fail2ban/jail.local, then restart:

sudo fail2ban-client -t
sudo systemctl restart fail2ban

The -t flag tests the configuration without starting the server, letting you catch errors before restarting.

Jail Shows 0 Bans When Attacks Are Visible

Confirm the jail is enabled and watching the correct log source:

sudo fail2ban-client status sshd

If the output shows File list: as empty or points to a log file that does not exist, the filter cannot find matches. On Ubuntu 24.04 and 26.04, the SSHD jail uses the systemd journal by default. If the backend is set to auto or pyinotify while SSH logs go to the journal, Fail2Ban will never see the failures. Verify the backend in defaults-debian.conf matches your log setup.

“No file(s) found for glob” Warning

This warning appears when a jail references a log path that does not exist on the system. For example, enabling the apache-badbots jail on a server without Apache produces:

WARNING No file(s) found for glob /var/log/apache2/access.log

Only enable jails for services you have installed. Disable unneeded jails in jail.local by setting enabled = false.

Remove Fail2Ban from Ubuntu

Retire Fail2Ban cleanly if you migrate to another intrusion-prevention solution or decommission the server.

Disable the Service

Stop the service and prevent it from starting at boot:

sudo systemctl disable --now fail2ban

This immediately halts Fail2Ban and unregisters it from systemd’s boot targets.

Remove the Package

Remove the software and its system-wide configuration files:

sudo apt remove --purge fail2ban

Follow up with an autoremove to clear any remaining dependencies:

sudo apt autoremove

Verify the package is gone:

fail2ban-client --version

Expected output after successful removal:

-bash: fail2ban-client: command not found

Clean Up Residual Files (Optional)

Delete any lingering log files if you no longer need historical ban data. The --purge flag already removes /etc/fail2ban/, so this step targets only the log:

The following command permanently deletes Fail2Ban log history. Skip this step if you plan to reinstall later or need the logs for auditing.

sudo rm -f /var/log/fail2ban.log*

Conclusion

You now have Fail2Ban installed on Ubuntu with a working SSHD jail, optional UFW integration, and tools to monitor bans and troubleshoot issues. The version comparison table earlier in this guide highlights how the firewall backend and log monitoring differ between Ubuntu 22.04, 24.04, and 26.04, so keep those differences in mind when tuning jail.local. Review /var/log/fail2ban.log regularly, tighten maxretry and bantime as real-world traffic patterns emerge, and test custom filters with fail2ban-regex before deploying them. For additional security layers, consider pairing Fail2Ban with UFW, enabling unattended upgrades to keep your system patched, and following the Fail2Ban GitHub repository for release notes and community filters.