How to Install Fail2ban and Stop Brute-Force Attacks 2026

Spin up a fresh VPS, leave port 22 open, and the failed logins start inside the hour. Not from a person. From botnets that sweep the entire IPv4 range looking for root and admin with a lazy password. Learning how to install fail2ban is the cheapest twenty minutes of security work you will ever spend on a server: one package, one config file, and the noise stops.

Quick Answer (as of September 2026): On Ubuntu or Debian, run sudo apt update && sudo apt install fail2ban -y, create /etc/fail2ban/jail.local containing an [sshd] block with enabled = true, maxretry = 3, findtime = 10m and bantime = 1h, then restart the service. Confirm bans with sudo fail2ban-client status sshd. On Ubuntu 24.04 and Debian 12 you also need backend = systemd, or the jail watches an empty log file and bans nobody.

Our engineers resolve 20 to 30 client server issues every day, across the 10,000+ clients served since 2016 at Hostaccent, and brute-force noise sits behind a large share of them. So this guide is written the way we actually configure a box under pressure, not the way the manual reads. Every command below has been run on Ubuntu 24.04, Debian 12 and AlmaLinux 9.

What Fail2ban Actually Does (And What It Will Not Stop)

Fail2ban is a log parser with a firewall attached. It reads a log source, matches failed-authentication lines against a regex filter, counts the hits from each address inside a rolling window, and when an IP crosses your threshold it writes a firewall rule that drops it for a set period. That is the whole product: three moving parts, one job, and it is the standard way to block brute-force SSH attacks on Linux.

Those three parts have names you will see in every config file:

• Filter: the regex that recognises a failure line, stored in /etc/fail2ban/filter.d/sshd.conf
• Jail: the filter plus thresholds plus the log source being watched
• Action: what happens on a ban, usually an nftables or iptables rule

A default install ships dozens of filters for services you may never run: Postfix, Dovecot, Nginx, ProFTPD, Asterisk. Only the sshd jail is enabled out of the box on Debian-family systems, and even that one has a catch we cover further down.

Do I actually need fail2ban if my VPS already has a firewall?

Yes, because the two solve different problems. A firewall decides which ports the world can reach. Port 22 has to stay open for you to work, which means it stays open for every scanner on the planet. Fail2ban is the piece that watches who keeps knocking and shuts the door on the addresses failing password after password. UFW on its own will happily pass 40,000 login attempts a night without complaint.

Be honest about the limits, though. Fail2ban counts failures per IP, so an attacker spread across 5,000 residential proxies at one attempt each will never trip a threshold. It does nothing against volumetric floods either, which need upstream filtering rather than a local rule; if that is your real problem, start with how to stop a DDoS attack in the first 10 minutes instead. And it cannot help against stolen-credential reuse, the pattern OWASP calls credential stuffing, because those logins succeed on the first try.

Pro Tip: Fail2ban is a rate limiter, not a lock. Setting PasswordAuthentication no in sshd_config and moving to keys removes SSH brute force entirely. Fail2ban then exists to cut log noise, save CPU cycles, and catch the attempts aimed at your other services.

How to Install Fail2ban on Ubuntu, Debian, and AlmaLinux

The install itself takes one command on every mainstream distribution, and the package is in the standard repositories, so you never need a third-party source. Debian 13 ships version 1.1.0, Debian 12 and Ubuntu 24.04 ship 1.0.x, and both behave identically for the config in this guide. Budget five minutes for the install and verification, then another ten for tuning.

Before you start, confirm three things: you have root or sudo access, SSH is working right now (never harden a server you cannot currently log into), and a firewall backend exists. Fail2ban writes rules through nftables, iptables, UFW or firewalld, so at least one must be installed.

Ubuntu and Debian:

bashCopy
sudo apt update
sudo apt install fail2ban -y

The service starts automatically on Debian-family systems. On some minimal cloud images it does not, so enable it explicitly:

bashCopy
sudo systemctl enable --now fail2ban

AlmaLinux, Rocky and RHEL 8/9: fail2ban lives in EPEL, not the base repositories, and you want the firewalld integration package too:

bashCopy
sudo dnf install epel-release -y
sudo dnf install fail2ban fail2ban-firewalld -y
sudo systemctl enable --now fail2ban

Now verify. These two commands tell you whether the daemon is alive and which jails it loaded:

bashCopy
sudo fail2ban-client ping
sudo fail2ban-client status

A healthy response is Server replied: pong followed by a jail list. If the jail list is empty on a fresh Debian or Ubuntu box, that is normal: the packaged defaults enable sshd only once a local config exists. The official Fail2ban wiki documents the packaged versions per distribution, and the Ubuntu Server documentation covers the firewall side.

One warning before you edit anything: do not touch /etc/fail2ban/jail.conf. Package upgrades overwrite it, and every custom threshold you wrote disappears with it. The rest of this Fail2ban Ubuntu setup happens in a separate file that upgrades leave alone.

Your First jail.local: The SSH Jail Config That Actually Bans

Your Fail2ban SSH jail config lives in one file: /etc/fail2ban/jail.local. Create it new and small. Most tutorials tell you to copy the 900-line jail.conf across, which buries your five real settings inside a wall of defaults you will never read again. A Fail2ban jail.local file of fifteen lines is easier to audit at 3am.

bashCopy
sudo nano /etc/fail2ban/jail.local

Paste this, changing the IP on the ignoreip line to your own address first:

iniCopy
[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 203.0.113.45
bantime  = 1h
findtime = 10m
maxretry = 3
bantime.increment = true
bantime.factor = 2
bantime.maxtime = 7d

[sshd]
enabled = true
backend = systemd
port    = ssh

Here is what each setting is doing, because the defaults are worth understanding rather than copying:

• maxretry = 3 means three failures triggers a ban. Setting this to 1 looks tough and mostly bans your own colleagues who fat-finger a passphrase.
• findtime = 10m is the window those three failures must land inside. Two failures today and one tomorrow will not trigger anything.
• bantime = 1h is the initial block. With bantime.increment enabled, a repeat offender's next ban doubles, then doubles again, up to the seven-day ceiling. Persistent bots eventually get long sentences without you touching a thing.
• ignoreip is your safety net. Put your office or home IP here before you restart anything.

From the Ticket Queue: According to Hostaccent's support-queue data, brute-force and malware cleanups account for roughly 25% of the tickets we open in a typical month, and Linux server issues another 25%. A jail this simple removes most of the first category before it becomes a cleanup job.

Reload and check:

bashCopy
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd

You want to see Currently failed, Total failed, Currently banned and a banned IP list. If every counter reads zero on a public server after an hour, something is wrong, and the next section explains exactly what. For the wider picture on locking down the rest of the box, work through our complete 2026 VPS hardening checklist once your jails are confirmed live.

◆ Professional help available

Still working through this server issue?

Send the symptoms, error output, and what you have already tried. We can work with Hostaccent services or infrastructure hosted with another provider.

Request server help→How server support works↗Hosted elsewhere? One-time paid support is available after scope and price confirmation.

Why Your sshd Jail Bans Nobody on Ubuntu 24.04 and Debian 12

This is the failure that catches the largest number of people, and almost no install guide mentions it. On Debian 12 and later, and on journald-only Ubuntu 24.04 cloud images, SSH failures go to the systemd journal instead of /var/log/auth.log. Fail2ban's default file backend then watches a file that is empty or missing, reports its jail as running, and bans exactly nobody. It has been an open complaint in the project tracker since Debian bug #770171.

Check it in two commands. First, look for recent SSH failures in the journal:

bashCopy
sudo journalctl -u ssh --since "1 hour ago" | grep -i "failed password"

Then look at the traditional file:

bashCopy
ls -l /var/log/auth.log

If the journal is full of failures and auth.log is missing or zero bytes, that is your answer. The fix is the backend = systemd line already included in the config above. Set it inside the [sshd] block rather than globally, because a global systemd backend is always technically available, which means fail2ban can no longer detect a genuinely missing log source and will fail quietly instead of loudly.

Prove the filter matches your log lines before you trust it:

bashCopy
sudo fail2ban-regex systemd-journal /etc/fail2ban/filter.d/sshd.conf

Any result above zero matched lines means the regex and your log format agree.

Insider Insight: After 10 years managing everything from bare root servers to cPanel and Plesk fleets, the pattern we notice is that "installed" and "working" are separated by exactly one restart nobody performed. The 60-Second Ban Test is the check Hostaccent engineers run before calling a server hardened: from a phone on mobile data, SSH in with a deliberately wrong password four times, then run fail2ban-client status sshd from your whitelisted session. If your mobile IP is not on the banned list, the jail is decorative. It takes a minute and it has caught more silent failures than any config review.

Once the sshd jail is confirmed live, the same verification habit applies to everything else you enable. A jail you never tested is a jail you cannot count on, and our Linux VPS security baseline for Ubuntu 24.04 covers the order to bring the rest of the stack up in.

Beyond SSH: WordPress, Mail and Recidive Jails

SSH is the loudest target, not the only one. On a typical hosting box the second wave lands on wp-login.php, the third on SMTP and IMAP authentication, and both are worth their own jails. Add them one at a time, and test each with the ban test above before adding the next.

WordPress has a catch nobody warns you about: it writes no authentication-failure line to any system log by default. A jail pointed at auth.log for WordPress will never match anything, because there is nothing to match. You have two honest options. Install the WP fail2ban plugin, which logs login attempts (including XML-RPC) to syslog and ships ready-made wordpress-hard and wordpress-soft filters. Or write a filter against your web server's access log instead:

iniCopy
# /etc/fail2ban/filter.d/wp-login.conf
[Definition]
failregex = ^<HOST> .* "POST .*wp-login\.php.* 200
ignoreregex =

iniCopy
# in jail.local
[wp-login]
enabled  = true
filter   = wp-login
port     = http,https
logpath  = /var/log/nginx/access.log
maxretry = 8
bantime  = 24h

Keep maxretry generous here. Legitimate users mistype passwords on a login form far more often than they do on SSH, and a hair-trigger web jail creates support tickets rather than security.

The other jail worth enabling on day one is recidive. It watches fail2ban's own log and applies long bans to addresses that keep coming back after shorter ones expire:

iniCopy
[recidive]
enabled  = true
bantime  = 12w
findtime = 1d
maxretry = 5

For database and mail, the same principle applies with different log paths: the mysqld-auth jail needs a file backend because MySQL logs to a file rather than the journal, which matters if you are already dealing with credential problems like a forgotten MySQL root password. Postfix, Dovecot and Exim jails are enabled by name with the filters already on disk.

Pro Tip: Jails are per-IP counters, so they complement rather than replace request-rate controls at the web layer. Pairing a WordPress jail with Nginx rate limiting for basic bot and DDoS protection catches both the slow guesser and the fast flooder.

Checking Bans, Unbanning Your IP, and the Mistakes That Lock You Out

Three commands cover daily operation. sudo fail2ban-client status lists active jails, sudo fail2ban-client status sshd shows the banned IP list for one jail, and sudo tail -f /var/log/fail2ban.log streams bans as they happen. On a public server with SSH exposed, expect that log to fill up within minutes.

What happens if I ban myself?

It happens to everyone eventually, usually while testing. The Fail2ban unban IP command removes your address from a single jail:

bashCopy
sudo fail2ban-client set sshd unbanip 203.0.113.45

To clear an address from every jail at once:

bashCopy
sudo fail2ban-client unban 203.0.113.45

If SSH itself is the jail holding you out, you need console access through your provider's control panel to run either command. That is the practical argument for putting your own address in ignoreip before you start, and for keeping your provider's web console credentials somewhere you can reach on a phone. In the lockout tickets we handle, the person is almost never an attacker. They are the owner, testing, from the only IP they had.

Four more mistakes account for most of the rest:

1. Editing jail.conf instead of jail.local. Your settings survive until the next apt upgrade, then silently revert.
2. Running behind a reverse proxy without real-IP restoration. If your site sits behind a CDN, every request arrives from the proxy's edge address, so a web jail will happily ban the CDN and take your whole site offline. Configure ngx_http_realip_module or mod_remoteip first; the Cloudflare Learning Center explains how the proxied request path works.
3. Jailing ACME validation traffic. Overly aggressive HTTP jails can block the validation request that renews your certificate, which shows up weeks later as a Certbot renewal failure rather than as a fail2ban problem.
4. Never checking again. Log formats change between distribution releases. A filter that matched perfectly on Debian 11 can quietly stop matching after an upgrade, and we have watched a hardened box sit silent for weeks while the jail counted zero.

None of this costs performance worth measuring. Fail2ban reads logs and writes occasional firewall rules; on an NVMe SSD server with a normal traffic profile, the overhead is invisible next to PHP, your database and cache layer.

Your Next Step: A Server Where the Bans Are Already Running

You now know how to install fail2ban, why the sshd jail goes quiet on Ubuntu 24.04, and how to get yourself back in after an accidental self-ban. You can work through that on every box you own this weekend, or start on one where the hardening, free 30 Gbps DDoS filtering and engineers who genuinely read fail2ban.log come with the plan. The Basic Linux VPS at $7.99/mo renews at $7.99/mo, not at a quiet increase in month 13: start on the Basic VPS plan, with a 30-day money-back guarantee and a 99.99% uptime guarantee behind it. One honest caveat: Basic is sized for a single project, so if you are running a dozen client sites, take Standard instead. That is the part Hostaccent's own engineers would tell you before you paid.

Frequently Asked Questions About Installing Fail2ban

Does fail2ban work on Ubuntu 24.04?

Yes, and the package installs cleanly from the standard repositories. The catch is logging: on Ubuntu 24.04 images that ship without rsyslog, SSH failures go only to the systemd journal, so a jail pointed at /var/log/auth.log finds nothing and bans nobody. Add backend = systemd inside your [sshd] block in jail.local, restart the service, then confirm with sudo fail2ban-client status sshd that the counters are actually moving.

How do I unban an IP address in fail2ban?

Run sudo fail2ban-client set sshd unbanip 203.0.113.45 to release an address from one jail, or sudo fail2ban-client unban 203.0.113.45 to clear it from every jail at once. If the ban is blocking your own SSH session, you will need console access through your hosting control panel to run the command. Prevent the whole situation by listing your own address on the ignoreip line before you enable any jail.

What is a good bantime and maxretry setting?

For SSH, maxretry = 3, findtime = 10m and bantime = 1h is the sensible starting point, with bantime.increment = true so repeat offenders climb toward a seven-day ban automatically. For web login forms, loosen it: maxretry = 8 and a 24-hour ban, because real users mistype passwords constantly. A one-attempt threshold looks strict but mostly generates lockout tickets from your own team rather than blocking determined attackers.

Will fail2ban stop a DDoS attack?

No, and treating it as DDoS protection is a costly mistake. Fail2ban reacts to authentication failures from individual addresses after they appear in a log, which is useless against a volumetric flood arriving from thousands of hosts at once, and it cannot help once your uplink is saturated. Volumetric attacks need filtering upstream of your server, at the network edge or through a CDN, before traffic ever reaches your firewall rules.

Is knowing how to install fail2ban enough to secure a server?

No. It handles one category of attack well and leaves several others untouched: unpatched software, weak database credentials, outdated PHP, missing backups and expired SSL. Treat it as one layer beside key-only SSH, automatic security updates, DNS hygiene and offsite backups. On Hostaccent VPS plans you get full root access to install any control panel you prefer (the cPanel or Plesk licence is bought separately, since no honest host bundles a $30+/month licence under $10), plus 24/7 support from our own in-house engineers.

Can fail2ban ban legitimate users by mistake?

Yes, and it is the most common real-world complaint. Shared office IPs, mobile networks that rotate addresses, monitoring probes and CDN edge servers all generate patterns that look like attacks. Whitelist known-good addresses with ignoreip, restore real client IPs before any web jail sees traffic behind a proxy, and keep web thresholds well above SSH ones. Reviewing /var/log/fail2ban.log weekly for the first month catches false positives before your users report them.