This guide has moved. It overlapped almost entirely with a second Fail2Ban article on this site, so the two have been combined. The current, maintained version is Setting up Fail2Ban on Ubuntu, which covers everything below plus Apache and nginx jails, custom filters for your own application, ban actions, and the Ubuntu 24.04 changes that break older configurations. This page stays here for anyone following an old link.
What this page used to cover, and where it lives now
The original article walked through protecting SSH and HTTP with Fail2Ban on a Linux server. All of that material is now in the combined guide, updated for Ubuntu 24.04 LTS. The short version is below, with pointers to the section that goes into detail.
The three parts of a Fail2Ban configuration
A filter holds the regular expressions that recognise an abusive log line. An action is what happens on a match, normally a firewall rule blocking the source address. A jail connects a filter to a log source, a threshold and an action.
An address that produces more matches than maxretry inside the findtime window is blocked for bantime, and the rule is withdrawn automatically when that expires.
SSH protection in short
Configuration belongs in /etc/fail2ban/jail.local, never in jail.conf, which apt replaces on upgrade.
[sshd]
enabled = true
port = 2222
mode = aggressive
backend = systemd
maxretry = 3
bantime = 1hTwo details matter more than they used to. The port value has to match the port SSH actually listens on, which on a hardened server is often not 22. And backend = systemd is now the safer choice, because minimal Ubuntu images do not install rsyslog, so a jail pointed at /var/log/auth.log watches a file that does not exist while reporting itself as healthy.
Key-only authentication does the heavy lifting here. Fail2Ban removes the noise and the connection load; it is not what keeps an attacker out. The settings that matter on the SSH side are in the guide to securing SSH on Ubuntu.
HTTP protection in short
Web server jails watch the access and error logs for repeated authentication failures or for scanner traffic hunting paths that do not exist.
[nginx-http-auth]
enabled = true
port = http,https
logpath = %(nginx_error_log)s
maxretry = 3Scanner jails such as nginx-botsearch and apache-noscript are more useful and more dangerous, because the paths they treat as suspicious include ones a real site may serve. The combined guide covers how to tune them, how to write a filter for your own application's log format, and what happens when the site sits behind a CDN and every log line carries the proxy's address rather than the visitor's.
Progressive bans instead of harsh first bans
The approach that has replaced aggressive thresholds is incremental banning. Each repeat offence multiplies the ban length, so persistent scanners disappear for progressively longer while an ordinary user who mistypes a passphrase is inconvenienced for an hour rather than a week.
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 5w
ignoreip = 127.0.0.1/8 ::1 203.0.113.50Keep ignoreip narrow. Exempting a whole private range because it seemed convenient exempts millions of addresses, and on shared cloud networking it can exempt other people's machines too.
Checking that any of it works
A jail that matches nothing looks exactly like a jail that is protecting you.
sudo fail2ban-client status sshd
sudo fail2ban-regex systemd-journal /etc/fail2ban/filter.d/sshd.conf
sudo fail2ban-client set sshd unbanip 198.51.100.42Read the matched-line count rather than the service status. A week of zero matches means the filter or the log path is wrong.
What Fail2Ban cannot do
It reads logs on one machine and reacts afterwards, so it cannot absorb volumetric denial of service traffic, and it does little against an attack spread thinly across thousands of addresses. Those cases need filtering in front of the server, and the options are compared in the notes on web application firewalls. Fail2Ban belongs alongside the rest of the work in the Ubuntu server hardening checklist.
Read the current guide instead
Everything above is covered in more depth, with the Ubuntu 24.04 specifics, in Setting up Fail2Ban on Ubuntu. That is the page that gets maintained.
If you would rather have an existing configuration reviewed than work through it yourself, N. Cristea can check whether the jails are matching real traffic and how the setup fits with the firewall around it. Get in touch with the Ubuntu version and what the server runs.