Fail2ban Ubuntu: 8 Safe Steps for Ubuntu 24.04 & 26.04

This fail2ban Ubuntu guide for 24.04 LTS and 26.04 LTS shows how to ban repeat offenders without banning yourself. You install it, write one settings file, pick the ban action, point it at SSH and nginx, and test every piece before you trust it. Pick your release with the switch below. Allow about 60 minutes. You need a server with sudo, a second SSH session and, for the web part, nginx.

Every command here was run twice in disposable labs, once on Ubuntu 24.04 (fail2ban 1.0.2, nginx 1.24) and once on Ubuntu 26.04 (fail2ban 1.1.0, nginx 1.28), each with a real WordPress 7.1.3 site and a second network namespace playing the attacker. The 26.04 lab shares its host's kernel (6.8, not the 7.0 that 26.04 ships), so its firewall results come from that kernel.

We also reproduced the quiet failures: a jail that watches nothing, a ban that fails while the status screen says it worked, and a change that leaves a jail with no action. Addresses such as 198.51.100.7 are documentation placeholders, so swap in your own.

Before you start

You need an Ubuntu 24.04 or 26.04 server and a user who can run sudo. Fail2ban is only as useful as the locks behind it, so set those first: harden the server, switch SSH to keys as in our SSH hardening guide, and enable a firewall with the UFW guide. Three habits keep this guide safe to follow.

• Keep a second SSH session open while you edit, and know how to reach your provider's web console. A ban can cut off the address you are working from.
• Write down your own public address. Step 2 puts it on the never-ban list.
• Know the way back. Delete the lines you added, run sudo fail2ban-client -t, then sudo systemctl restart fail2ban, and the server behaves as before.

Why fail2ban, and not the other ways

Several tools answer the question "what do we do about people who keep guessing?" They work at different layers, and the best setups combine two or three. Here is how we weigh them for a small server.

The reasoning is a building's. Strong locks (keys, updates) come first. A clicker at the door (rate limiting) slows a crowd. A doorman who remembers faces (fail2ban) keeps repeat offenders out longer. A security company outside (a WAF or CDN) handles the mob. You rarely need all four, and you should never rely on the doorman alone.

How fail2ban Ubuntu works: a doorman, not a lock

Think of a doorman with a visitors' book. Each time someone is turned away, a line goes into the book. When the same person is turned away too often in a short time, the doorman asks the building's lock to refuse that person for a while. Fail2ban is the doorman. The lock is your firewall, and behind it your SSH settings and passwords. Four words describe the whole system.

What fail2ban cannot do matters as much. It acts after the fact, so the first few attempts always get through. It sees one address at a time, so an attacker with many addresses can stay under the limit. It trusts the log, so it is only as good as its patterns. The section on limits comes back to this.

Step 1: Install fail2ban and read what Ubuntu already switched on

Install the package, make sure the service starts at boot, then ask it what it is watching. On Ubuntu the answer is already "one jail, sshd", because the package ships a small file that turns the SSH jail on.

sudo apt update
sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

In our labs the first status command printed Jail list: sshd, and the second showed Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshdJournal matches: _SYSTEMD_UNIT=ssh.service + _COMM=sshd under the filter. Now read the file responsible (its contents follow the commands) and the three numbers that set how strict the SSH jail is.

cat /etc/fail2ban/jail.d/defaults-debian.conf
for k in bantime findtime maxretry; do echo "$k = $(sudo fail2ban-client get sshd $k)"; done

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]

[sshd]
backend = systemd
journalmatch = _SYSTEMD_UNIT=ssh.service + _COMM=sshd
enabled = true

The loop printed bantime = 600, findtime = 600 and maxretry = 5: five failures within ten minutes earn a ten-minute ban. The file above explains much of this guide.

Step 2: Create jail.local and protect yourself first

Fail2ban reads its settings from several files in a fixed order, and later files win: jail.conf, then every jail.d/*.conf, then jail.local, then every jail.d/*.local. A package upgrade may replace the shipped files, but it never touches jail.local. So every change goes into /etc/fail2ban/jail.local, and you never edit jail.conf.

The first thing to write there is the list of addresses that must never be banned. Find the address your SSH session comes from, then open the file.

echo "${SSH_CLIENT%% *}"
sudoedit /etc/fail2ban/jail.local

[DEFAULT]
# Never ban these: loopback, the office, the VPN exit (separate with spaces)
ignoreip = 127.0.0.1/8 ::1 203.0.113.0/24

Replace 203.0.113.0/24 with your own address or range, and keep the list short: an address you exempt can guess freely. Fail2ban already ignores the server's own addresses (ignoreself is true by default). Test the file, apply it, and read the list back.

sudo fail2ban-client -t
sudo fail2ban-client reload
sudo fail2ban-client get sshd ignoreip

The -t option tests the configuration, reload applies it without dropping existing bans (a test ban survived a reload in our labs), and the last command prints the ignored addresses. A harmless warning about allowipv6 appears on every run on 24.04.On 26.04 the test prints only the OK line. In the labs, failures from inside an ignored range were logged as "Ignore 203.0.113.9 by ip" and never produced a ban.

The never-ban list protects an address, not a person: on a phone hotspot or in a hotel you are not on it. An SSH agent holding many keys can also get you banned. In our labs one connection offering eight keys added two failuresone failure, so a handful of such connections reach the limit of five. IdentitiesOnly yes for that host in ~/.ssh/config limits the keys offered.

Step 3: Choose ban times that fit, and make repeat offenders pay more

Three numbers decide how strict a jail is: if an address fails maxretry times within findtime, it is banned for bantime. Ubuntu keeps upstream's values. We lengthen only the ban.

Open jail.local again and replace the [DEFAULT] section with the version below. The two bantime. lines are the interesting part: with bantime.increment on, fail2ban looks the address up in its database and lengthens the ban each time it returns.

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 203.0.113.0/24
bantime  = 1h
findtime = 10m
maxretry = 5

# Repeat offenders: 1h, then 2h, 4h, 8h ... up to five weeks
bantime.increment = true
bantime.maxtime   = 5w

[sshd]
# Also count scanners that connect and leave without logging in
mode = aggressive

The doubling is real. In the lab a 20-second test ban became 40 seconds, then 80 seconds, for the same address. With an hour as the base you get 1, 2, 4, 8 hours until the five-week cap, where, in fail2ban's words, the ban "doesn't grow further".

One catch most tutorials skip: the count lives in the ban history, which fail2ban keeps for one day by default (dbpurgeage = 1d in fail2ban.conf). On a copy of the database, an address whose last ban was three days old was forgotten at that default and remembered with 8 days. To remember offenders for about a week, add a second file.

sudoedit /etc/fail2ban/fail2ban.local

[Definition]
dbpurgeage = 8d

The [sshd] line needs a word too. The default normal mode counts wrong passwords and unknown user names. It ignores what sshd logs when a client names a real account such as root, offers no valid key and disconnects: "Connection closed by authenticating user root ... [preauth]". On a key-only server that is most of what scanners do. In the labs, eight such attempts were eight ignored lines in normal mode and eight failures in aggressive mode.

One side effect: an unknown user name logs two lines, "Invalid user" and "Connection closed by invalid user", and aggressive mode counts both. Three such attempts therefore reach the limit of five. We saw this on both releases.

Apply both files, then read the values back:

sudo fail2ban-client -t && sudo fail2ban-client reload
sudo fail2ban-client get sshd bantime
sudo fail2ban-client get sshd bantime.increment
sudo fail2ban-client get dbpurgeage

Expect 3600, True, and a purge age of 691200 seconds. A plain reload is enough for these settings and for newly enabled jails; Step 4 covers the one change that needs a restart.

Step 4: Decide how bans are enforced: nftables or UFW

A ban is only a firewall rule that fail2ban adds and removes for you. Ubuntu's default adds it with nftables. If you manage the firewall with UFW, you can make fail2ban use UFW instead. Both work, and they differ in ways we measured with a second host in the lab.

If you keep Ubuntu's default, there is nothing to change. To switch to UFW, add one line to the [DEFAULT] section of jail.local, then restart the service and check the result. A restart is required here; a plain reload is not enough.

banaction = ufw

sudo fail2ban-client -t && sudo systemctl restart fail2ban
sudo fail2ban-client get sshd actions
sudo fail2ban-client set sshd banip 198.51.100.7
sudo ufw status numbered
sudo fail2ban-client set sshd unbanip 198.51.100.7

The second command should print ufw. After the test ban, UFW listed REJECT IN 198.51.100.7 at position 1, with a comment naming the jail, and unbanip removed it. Real bans from the second host worked too: after a few failed SSH logins it was refused on every port.

Step 5: Know your backend, because the nginx jails depend on it

sudo fail2ban-client status nginx-http-auth
sudo fail2ban-client get nginx-http-auth logpath

With a journal backend inherited by mistake, the first command shows Journal matches: _SYSTEMD_UNIT=nginx.service + _COMM=nginx and the second says "No file is currently monitored". With the file backend, the first showed a File list: with the nginx error logs, the failures were counted, and a request after the ban was refused. A jail that should read files must show File list.

Step 6: Turn on the nginx jails, and add one for WordPress logins

Ubuntu ships fourfive nginx filters, with matching jail definitions in jail.conf. All are off until you enable them, and all need backend = auto here, and on 26.04 they read their log files without any backend line (the backend = auto lines below are harmless there and required on 24.04). This is what each one reads and counts.

The nginx-botsearch jail needs attention. The packaged jail reads the error log, but a WordPress site sends unknown URLs to index.php, which answers 404 without nginx logging anything. In the lab, eight probe requests all got 404, and the stock jail counted zero failures. The same filter matches those requests in the access log, so point the jail there. Add this to jail.local:

[nginx-http-auth]
enabled = true
backend = auto

[nginx-limit-req]
enabled = true
backend = auto

[nginx-botsearch]
enabled = true
backend = auto
logpath = %(nginx_access_log)s

%(nginx_access_log)s is a variable from Ubuntu's paths-common.conf for /var/log/nginx/*access.log, so per-site logs such as example.com.access.log are included. With these stanzas, six probes for phpMyAdmin, webmail and similar paths got the second host banned, and its next request was refused.

Ubuntu has no filter for WordPress logins, but the access log is enough. A wrong password makes WordPress answer 200, because it shows the form again, and a correct one answers 302 (we measured both, and our rate limiting guide shows the same 200). So a POST to wp-login.php answered 200 is a failed login. Create the filter:

sudoedit /etc/fail2ban/filter.d/wordpress-login.conf

[Definition]
# A failed WordPress login answers 200 (the form again); a good one answers 302.
failregex = ^<HOST> - \S+ \[\] "POST /wp-login\.php[^"]*" 200 \d+
datepattern = ^[^\[]*\[({DATE})

Copy datepattern exactly: it is the form Ubuntu's own botsearch filter uses for the combined access-log format. Then add the jail to jail.local, test, and reload.

[wordpress-login]
enabled = true
filter  = wordpress-login
logpath = %(nginx_access_log)s
backend = auto
port    = http,https

sudo fail2ban-client -t && sudo fail2ban-client reload
sudo fail2ban-client status

Step 7: Test every filter against real log lines before you trust it

A jail that never fires looks exactly like a quiet network. The cure is to run each filter over real log lines before relying on it, with fail2ban-regex. It takes a log (a file, a single line, or the systemd journal) and a filter, and tells you how many lines matched.

sudo fail2ban-regex /var/log/nginx/example.com.access.log nginx-botsearch
sudo fail2ban-regex /var/log/nginx/example.com.error.log nginx-botsearch
sudo fail2ban-regex /var/log/nginx/example.com.access.log wordpress-login
sudo fail2ban-regex systemd-journal sshd
sudo fail2ban-regex systemd-journal 'sshd[mode=aggressive]'

Read the summary line. Lines: 7 lines, 0 ignored, 6 matched, 1 missed means seven lines were read and six counted as failures; "ignored" lines were recognized and deliberately not counted. On our WordPress access log, botsearch matched six probe requests and missed the one legitimate page, while the same filter on the error log matched nothing: the quiet failure from step 6, made visible.

For the login filter, first type two wrong passwords and one correct one into your own login page; the two wrong ones should match. Add -v to print the address each match extracted.

Custom filters carry one more trap. Attackers control some text in your logs, such as a user name or a URL, and a loose pattern can be steered by it. We tested two patterns against a line whose user name contained a fake address.

printf '%s\n' '2026-10-09 10:00:01 app: Invalid user bob from 192.0.2.10 from 203.0.113.9 port 4242' > /tmp/app.log
sudo fail2ban-regex -v /tmp/app.log '^\s*app: Invalid user .*? from <HOST>'
sudo fail2ban-regex -v /tmp/app.log '^\s*app: Invalid user \S+ from <HOST> port \d+$'

The loose pattern blamed 192.0.2.10, the address typed into the user name, instead of the real source, 203.0.113.9. The anchored pattern, which expects one user name and then the address and port, did not match the line at all. Missing a line is safe; banning an innocent address is not. Ubuntu's packaged filters are written the careful way, so copy their style.

Step 8: Test the whole chain safely, then learn to undo a ban

Test from the least risky to the most. In your second session, run sudo tail -f /var/log/fail2ban.log so every Found, Ban and Unban appears as it happens. First prove the plumbing with an address that is not yours, a documentation address no real visitor uses.

sudo fail2ban-client set sshd banip 198.51.100.7
sudo fail2ban-client status sshd
sudo nft list table inet f2b-table
sudo grep -E "Ban|ERROR" /var/log/fail2ban.log | tail -n 5
sudo fail2ban-client set sshd unbanip 198.51.100.7

You should see the address in the jail's banned list, a set holding it in the nftables table (or the UFW rule, if you chose ufw), a Ban line with no ERROR line, and 1 from unbanip. This is also where you catch the missing nft command from step 1.

Then do one real end-to-end test from a second machine that is not on the never-ban list: a laptop on a phone hotspot, or another server. Make six SSH attempts as a user that does not exist, with no key (-n stops ssh reading your keyboard).

for i in 1 2 3 4 5 6; do ssh -n -o BatchMode=yes -o StrictHostKeyChecking=accept-new nosuchuser@203.0.113.10 true; sleep 1; done

The first answers are "Permission denied". Once the ban lands, they change to "Connection refused". With aggressive mode each unknown-user attempt scores two (step 3), so the ban can land after only three or four attempts, and the one-second pause gives fail2ban time to act. Back in your admin session, look at the ban and then lift it.

sudo fail2ban-client status sshd
sudo fail2ban-client banned
sudo fail2ban-client get sshd banip --with-time
sudo fail2ban-client set sshd unbanip 203.0.113.99
sudo fail2ban-client unban --all

status lists the jail's bans, banned lists them for every jail, and --with-time adds when each ban started and ends. unbanip frees one address in one jail, and unban 203.0.113.99 frees it in every jail; both print how many bans they removed, so 0 means the address was not banned. unban --all empties every jail. Unbanning also erases that address's ban history, so its next ban starts again at the base time.

Check your work

Run these six checks once your fail2ban Ubuntu setup is in place. Each answers a question you would otherwise ask during an incident.

• Is it running? systemctl is-active fail2ban prints active, and sudo fail2ban-client -t ends with OK.
• Is every jail reading something? sudo fail2ban-client status lists each jail you enabled, showing File list or the expected Journal matches.
• Can the filters see real lines? fail2ban-regex reports matches for a request you made on purpose.
• Is a rule created? A test ban appears in nft list table inet f2b-table (or ufw status) and disappears on unbanip.
• Are you protected from yourself? sudo fail2ban-client get sshd ignoreip lists your address or range.
• Do bans survive a restart? After sudo systemctl restart fail2ban, a live ban returns, and the log says "Restore Ban".

What fail2ban does not do: the honest limits

A fail2ban Ubuntu setup is useful and small. Treat it as one layer, and know where it stops.

• It acts after the fact. The first attempts always get through. A ban is a consequence, not a defense, so keep key-only SSH, patched software and strong passwords underneath it. Our small business cybersecurity checklist lists them.
• It sees one address at a time. Attackers who spread guesses over many addresses, or try a few times a day from each, stay under a limit of five per ten minutes. A second, slower jail on the same filter catches some of them (config below). Past that, an edge service or a WAF is the better tool.
• IPv6 gives attackers more addresses. A ban covers one address. In the lab, after we banned one IPv6 address, a neighbor in the same /64 connected immediately and got "Permission denied". Per-address bans are weak against someone who can rotate through a whole block.
• It trusts the log. A filter is only as good as its pattern (step 7), and anyone with root can edit logs or stop the service. Fail2ban is not an intrusion detector.
• It needs the real visitor address. Behind a proxy or CDN, the log may show the proxy for everyone. Fix that first with set_real_ip_from, as in our rate limiting guide and the PROXY protocol guide, or fail2ban acts on the wrong address.

Here is the slower jail from the second point. It reads the same journal with the aggressive filter, but counts over a whole day and bans for two days, so an address that tries ten times in a day is caught even if it never trips the fast jail.

[sshd-slow]
enabled  = true
filter   = sshd[mode=aggressive]
port     = ssh
findtime = 1d
maxretry = 10
bantime  = 2d

[sshd-slow]
enabled  = true
backend  = systemd
filter   = sshd[mode=aggressive]
port     = ssh
findtime = 1d
maxretry = 10
bantime  = 2d

Troubleshooting: what the symptoms mean

Common mistakes

• Editing jail.conf. A package upgrade can replace it. Use jail.local.
• Restarting without -t. One missing log file stops the service, and SSH protection goes with it.
• Enabling a file-reading jail on the journal backend. It starts, and it does nothing.
• Trusting the status screen instead of the firewall. Look for the rule, not only the list.
• Skipping ignoreip. The first tired colleague with a wrong password bans the office.
• Writing a filter and never testing it. Run fail2ban-regex on real lines, including hostile ones.

Keep it healthy

A fail2ban Ubuntu server needs a monthly look. Run sudo fail2ban-client status and each jail's status. A jail on a public server whose Total failed has not moved in weeks deserves attention. Skim recent bans with sudo grep Ban /var/log/fail2ban.log | tail -n 20 for addresses you recognize. Ubuntu rotates that log weekly and keeps four old copies, as the logrotate guide explains for nginx.

After any change to nginx log paths or formats, a new proxy, or a new site, run fail2ban-regex again. After an upgrade, confirm systemctl is-active fail2ban; unattended upgrades restart the service on their own, and unexpired bans come back from the database. Keep ignoreip current when your office address changes. Our Linux server hardening checklist lists the other recurring jobs.

Getting help

If you would rather have someone set this up and watch it, MEI's Network Architecture and Security service covers firewall and server hardening, secure remote access, monitoring and access control, and starts at $1,500, scoped after an assessment. Managed Website and IT Care starts at $149 a month, with scope-based tiers for updates, backups, monitoring and help, so routine jobs like this have an owner. We focus on the highest-impact, most likely risks, and we do not promise perfect security.