fail2ban monitors authentication events and temporarily blocks source IP addresses that repeatedly match failure patterns. On an internet-facing Ubuntu server, it is useful as an additional SSH protection layer alongside SSH keys, restricted firewall rules, timely updates, and disabled password authentication where practical. In this tutorial, you will install fail2ban on a Raff Technologies Linux VM running Ubuntu 24.04, enable the SSH jail, use the systemd journal backend, tune retry and ban windows, validate the configuration, test a ban without locking yourself out, inspect logs, and cleanly roll the setup back if needed.
Ubuntu 24.04 currently provides fail2ban 1.0.2-3ubuntu0.1 in the Noble Updates package line. The package supports systemd journal monitoring and works with modern firewall backends including nftables. This guide does not claim that every public server receives a fixed number of attacks or that fail2ban eliminates brute-force traffic; actual login noise varies by IP, exposure, SSH configuration, and time. fail2ban reduces repeated attempts from matching sources, but it should not replace SSH key authentication or firewall access controls.
You need Ubuntu 24.04, SSH access using a non-root sudo user, and preferably SSH key authentication already working before you change ban rules.
Step 1 — Confirm Ubuntu and Your SSH Access Path
Check the operating system:
cat /etc/os-release
Confirm the SSH service is active:
systemctl is-active ssh
Before changing fail2ban settings, keep your current SSH session open and confirm you can open a second SSH session from your normal workstation. This gives you a recovery path if you make a configuration mistake.
If you have not configured SSH keys yet, follow How to Set Up SSH Keys on Ubuntu 24.04 first.
Verify: Ubuntu should report 24.04, the SSH service should be active, and a second SSH session should connect successfully before you continue.
Step 2 — Install fail2ban from the Ubuntu Repository
Update package metadata and install fail2ban:
sudo apt update sudo apt install -y fail2ban
Check the installed package version:
apt-cache policy fail2ban
Ubuntu 24.04's current Noble Updates package is fail2ban 1.0.2-3ubuntu0.1, with Ubuntu security and maintenance revisions applied through package updates. You can verify the current Ubuntu package at packages.ubuntu.com.
Enable fail2ban at boot:
sudo systemctl enable fail2ban
Do not assume the SSH jail is enabled simply because the service package is installed; jails are disabled by default unless distribution or local configuration enables them.
Verify: fail2ban-client --version should report Fail2Ban 1.0.2, apt-cache policy fail2ban should show the current Ubuntu package revision, and systemctl is-enabled fail2ban should report enabled.
Step 3 — Create a Local SSH Jail Override
Do not edit /etc/fail2ban/jail.conf directly. Upstream fail2ban recommends putting local overrides in jail.local or .local files under /etc/fail2ban/jail.d/, so package upgrades can update defaults without overwriting your custom settings.
Create a dedicated SSH override:
sudo nano /etc/fail2ban/jail.d/sshd.local
Add:
[sshd] enabled = true backend = systemd port = ssh bantime = 1h findtime = 10m maxretry = 5
The systemd backend reads authentication events from the journal. When this backend is used, do not add a logpath directive; fail2ban's systemd backend uses the filter's journalmatch instead. This avoids depending on /var/log/auth.log being present on every Ubuntu installation.
If SSH listens on a custom port, replace port = ssh with the actual port number.
Verify: Run sudo cat /etc/fail2ban/jail.d/sshd.local and confirm the jail is enabled, the backend is systemd, and the SSH port matches the server's real SSH listener.
Step 4 — Decide Whether Any Administrative IP Should Be Ignored
fail2ban can exclude trusted addresses with ignoreip, but only add addresses or networks that are stable and under your control. Whitelisting a temporary hotel, mobile, ISP, or shared office address can create an unintended bypass later if that address is reassigned.
If you have a stable administrative IP or VPN subnet, add it to a [DEFAULT] override:
sudo nano /etc/fail2ban/jail.d/00-local-defaults.local
For example:
[DEFAULT] ignoreip = 127.0.0.1/8 ::1 203.0.113.10
Replace 203.0.113.10 with a stable source you actually control, or omit it entirely if you do not have one.
Check your current public source address from the workstation you use for SSH and compare it with any configured ignoreip entry before testing bans.
Verify: Run sudo fail2ban-client -d | grep -i ignoreip after the configuration test in the next step and confirm only intended trusted addresses are excluded.
Step 5 — Validate the Configuration Before Restarting
Test the full fail2ban configuration:
sudo fail2ban-client -t
A successful test should end without a configuration error. If it fails, inspect the local files you just created before restarting the service.
You can also inspect the resolved configuration for the SSH jail:
sudo fail2ban-client -d | grep -A 20 "'sshd'"
Do not restart fail2ban after a failed configuration test.
Verify: sudo fail2ban-client -t should report that the configuration is OK.
Step 6 — Start fail2ban and Confirm the SSH Jail
Restart fail2ban so the local SSH jail is loaded:
sudo systemctl restart fail2ban
Check the service:
systemctl is-active fail2ban
List active jails:
sudo fail2ban-client status
Then inspect SSH specifically:
sudo fail2ban-client status sshd
The SSH jail status shows currently failed attempts, total failures, current bans, total bans, and the banned IP list. A new server may legitimately show zero bans.
Verify: systemctl is-active fail2ban should return active, and sudo fail2ban-client status should list sshd as an active jail.
Step 7 — Confirm fail2ban Is Reading SSH Journal Events
Inspect the SSH journal directly:
sudo journalctl -u ssh --since '30 minutes ago' --no-pager
Then check fail2ban's SSH jail:
sudo fail2ban-client status sshd
Review fail2ban service logs:
sudo journalctl -u fail2ban -n 100 --no-pager
The jail may show zero failed attempts if no matching authentication failures occurred during the observation window. That is not itself an error.
If the SSH jail is active but never sees events that are visible in the SSH journal, check the backend and filter configuration before changing retry thresholds.
Verify: The SSH jail should remain active without repeated backend or journal errors in the fail2ban service log.
Step 8 — Test the Ban Action Without Locking Yourself Out
Do not intentionally enter bad SSH passwords repeatedly from your only administrative connection. First inspect the resolved SSH jail configuration so you know which ban action is active:
sudo fail2ban-client -d | grep -A 40 "sshd"
You can also inspect the loaded jail actions directly:
sudo fail2ban-client get sshd actions
Then use fail2ban's manual ban command with a documentation-only test address that is not your own source IP:
sudo fail2ban-client set sshd banip 198.51.100.25
Check the jail:
sudo fail2ban-client status sshd
The test address should appear in the banned IP list.
If the resolved action uses nftables, inspect the corresponding fail2ban rules or sets:
sudo nft list ruleset | grep -i -A 8 f2b
If your system uses a different action backend, inspect that backend instead of assuming nftables. Do not assume a fail2ban ban must appear as a permanent UFW rule; fail2ban's active action can manage firewall state independently of the baseline rules shown by ufw status.
Remove the test ban:
sudo fail2ban-client set sshd unbanip 198.51.100.25
Verify: The test IP should appear while banned, the loaded action should match the firewall mechanism you inspect, and the IP should disappear from sudo fail2ban-client status sshd after the unban command.
Step 9 — Tune Ban Time and Retry Thresholds Conservatively
The initial values in this guide are:
bantime = 1h findtime = 10m maxretry = 5
These mean that five matching failures within ten minutes trigger a one-hour ban. There is no universal ideal value. Shared administrator addresses, automation, monitoring systems, and users behind NAT can make aggressive thresholds more likely to block legitimate access.
If repeated offenders are a problem, fail2ban supports incremental ban times. Add these settings under [DEFAULT] in /etc/fail2ban/jail.d/00-local-defaults.local:
[DEFAULT] bantime.increment = true bantime.factor = 2 bantime.maxtime = 1d
After changing values, validate before restart:
sudo fail2ban-client -t sudo systemctl restart fail2ban
Verify: sudo fail2ban-client -t should pass, and sudo fail2ban-client get sshd bantime should show the effective base ban duration in seconds.
Step 10 — Manage Bans and Review Activity
List SSH jail status:
sudo fail2ban-client status sshd
Ban an address manually when there is a specific operational reason:
sudo fail2ban-client set sshd banip 203.0.113.50
Unban it:
sudo fail2ban-client set sshd unbanip 203.0.113.50
To inspect recent fail2ban activity through systemd:
sudo journalctl -u fail2ban --since today --no-pager
Do not interpret raw ban counts as a security score. Higher or lower counts can result from IP exposure, scanning activity, logging configuration, retry thresholds, and whether password authentication is enabled.
Verify: Manual ban and unban commands should change the SSH jail's banned IP list immediately.
