Configure Fail2Ban on Ubuntu VPS: Step-by-Step

Why Fail2Ban Belongs on Every Ubuntu VPS

A freshly provisioned VPS starts getting scanned within minutes of going live. That's not an exaggeration — it's a measurable reality. Bots probe port 22 constantly, looking for weak passwords or misconfigured services. Fail2Ban is one of the most practical tools you can install early, because it watches your log files and automatically bans IP addresses that show repeated failed login attempts.

Unlike a firewall rule that you set once and forget, Fail2Ban responds dynamically. You define thresholds — say, five failed SSH attempts within ten minutes — and it inserts a temporary block using iptables or nftables. When the ban expires, the block lifts automatically. No manual intervention needed.

This tutorial walks through installing Fail2Ban on Ubuntu 22.04 or 24.04, configuring it for SSH and common web services, and testing that it's actually working before you rely on it. If you're running a Hostperl VPS, this is a logical first step after locking down your firewall.

Before You Start: Prerequisites

You'll need root or sudo access to your VPS and a working UFW or iptables setup already in place. Fail2Ban integrates with both. If you haven't set up UFW yet, the UFW firewall setup guide covers that process cleanly.

Confirm your Ubuntu version before proceeding:

lsb_release -a

Both Ubuntu 22.04 LTS and 24.04 LTS are supported. The steps below apply to both unless noted otherwise.

Step 1: Install Fail2Ban

Start with a package update, then install:

sudo apt update
sudo apt install fail2ban -y

Once installed, enable and start the service:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Check that it's running without errors:

sudo systemctl status fail2ban

You should see active (running) in the output. If it shows a failed state, check /var/log/fail2ban.log for the cause — usually a syntax error in a config file you may have edited previously.

Step 2: Create a Local Configuration File

Fail2Ban ships with a default config at /etc/fail2ban/jail.conf. Don't edit that file directly — it gets overwritten on upgrades. Instead, create a local override:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Now open jail.local with your preferred editor:

sudo nano /etc/fail2ban/jail.local

Find the [DEFAULT] section near the top. These are the global settings that apply to every jail unless overridden.

Step 3: Set Your Global Defaults

The most important settings in [DEFAULT]:

• bantime — How long a ban lasts. Default is 10m (ten minutes). For production servers, 1h or 24h is more effective.
• findtime — The window Fail2Ban looks back in logs. Default is 10m.
• maxretry — Failed attempts before a ban triggers. Default is 5.
• ignoreip — IP addresses that should never be banned. Add your own IP here.

A reasonable production configuration looks like this:

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 4
ignoreip = 127.0.0.1/8 ::1 YOUR.OWN.IP.HERE

Replace YOUR.OWN.IP.HERE with your actual public IP. Locking yourself out of a VPS because your own IP got banned is a support ticket nobody wants to file.

Step 4: Enable the SSH Jail

Fail2Ban's SSH jail is usually enabled by default, but confirm it in jail.local. Scroll down to find the [sshd] section. If it's not there, add it at the bottom of the file:

[sshd]
enabled  = true
port     = ssh
logpath  = %(sshd_log)s
backend  = %(sshd_backend)s
maxretry = 4
bantime  = 2h

If you've moved SSH to a non-standard port (which is worth doing — see the VPS security checklist for the full reasoning), update the port line accordingly:

port = 2244

Save the file and reload Fail2Ban:

sudo systemctl reload fail2ban

Step 5: Add Jails for Apache or Nginx

If your VPS is running a web server, it's worth protecting it too. Fail2Ban ships with filters for both Apache and Nginx.

For Apache, add this to jail.local:

[apache-auth]
enabled  = true
port     = http,https
logpath  = %(apache_error_log)s
maxretry = 4
bantime  = 1h

[apache-badbots]
enabled  = true
port     = http,https
logpath  = %(apache_access_log)s
maxretry = 2

For Nginx:

[nginx-http-auth]
enabled  = true
port     = http,https
logpath  = /var/log/nginx/error.log
maxretry = 4
bantime  = 1h

[nginx-botsearch]
enabled  = true
port     = http,https
logpath  = /var/log/nginx/access.log
maxretry = 2

Reload after changes:

sudo systemctl reload fail2ban

If you want Fail2Ban to also send you email alerts when a ban fires, that configuration is covered in the Fail2Ban email alerts setup guide.

Step 6: Test That Bans Actually Fire

Don't assume Fail2Ban is working — test it. The safest way is to use a second machine or a throwaway IP (a mobile hotspot works fine) to simulate failed logins.

From that second machine, deliberately fail SSH authentication several times:

ssh nonexistentuser@your-vps-ip

Enter a wrong password each time. After hitting your maxretry threshold, the connection should hang or time out. Back on the VPS, check the jail status:

sudo fail2ban-client status sshd

You should see the offending IP listed under Banned IP list. The output will also show the total number of failures and current ban count.

Step 7: Manage Bans Manually

Sometimes a legitimate user gets banned — a client mistyping their FTP password four times, for example. You can unban an IP without restarting Fail2Ban:

sudo fail2ban-client set sshd unbanip 203.0.113.45

To list all active jails:

sudo fail2ban-client status

To check any specific jail:

sudo fail2ban-client status apache-auth

Bans are stored in memory by default, so they clear on a service restart. If you want bans to persist across reboots, set dbfile in jail.local:

[DEFAULT]
dbfile = /var/lib/fail2ban/fail2ban.sqlite3
dbpurgeage = 86400

This keeps a 24-hour ban history in SQLite so Fail2Ban remembers repeat offenders even after a restart.

Step 8: Monitor Fail2Ban Logs

The main log is at /var/log/fail2ban.log. You can tail it live to watch bans happen in real time:

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

A ban event looks like:

2026-03-12 14:22:07,341 fail2ban.actions [12345]: NOTICE [sshd] Ban 198.51.100.77

If you're running Logwatch for daily digest reports, it will pick up Fail2Ban activity automatically — handy for a quick daily overview without watching logs manually. The Logwatch daily digests guide explains that setup.

Common Fail2Ban Problems and Fixes

A few issues come up regularly when Fail2Ban is first configured:

• Bans aren't firing: Check that the logpath in your jail points to the actual log file. A wrong path means Fail2Ban sees no failures to count.
• Service won't start after editing jail.local: Run sudo fail2ban-client -t to check for syntax errors before reloading.
• Your own IP got banned: Add it to ignoreip and unban immediately with fail2ban-client set sshd unbanip <your-ip>.
• UFW shows no rules: Fail2Ban may be configured to use iptables directly while UFW manages its own chain. This is generally fine — they coexist without conflict on Ubuntu.

Frequently Asked Questions

Does Fail2Ban permanently ban repeat offenders?

Not by default. Bans expire after the bantime you set. You can create a recidive jail that imposes a much longer ban on IPs that get caught repeatedly — Fail2Ban ships with a filter for this. Look for the [recidive] jail in jail.conf and enable it in your jail.local.

Will Fail2Ban slow down my server?

No measurable impact on typical VPS workloads. It runs as a lightweight Python daemon and only reads log files — it doesn't inspect live traffic. Even on a 1 vCPU / 1 GB RAM VPS, CPU usage stays well under 1%.

Can I use Fail2Ban with a control panel like cPanel or Plesk?

Yes, though control panels often ship with their own brute-force protection (cPanel has cPHulk, Plesk has Fail2Ban integration built in). On bare VPS setups without a control panel, configuring Fail2Ban manually as shown here gives you the most control.

What if I'm on a server behind a load balancer or proxy?

Fail2Ban will see the proxy's IP in your logs rather than the actual client IP. You'd need to configure your web server to log the real IP via X-Forwarded-For headers first, otherwise you risk banning your own load balancer.