Installing and Tuning fail2ban on a Linux VPS

fail2ban is not a firewall; it is a log scanner with a firewall trigger. It watches the log files your services already write, extracts the source IPs from failed attempts, and hands them to iptables, nftables, or ufw to be dropped. Out of the box it protects SSH, but the same engine guards web, mail, and anything else that logs failures. This guide covers installing fail2ban on a Debian-based VPS, enabling the jails that matter, and tuning it so real users are never collateral damage.

Install and First Run

On Debian and Ubuntu, fail2ban is a single package. The base install enables an sshd jail out of the box, which is a reasonable starting point, but the real value is in a jail.local that expresses your intent instead of the package defaults.

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

The status command lists every active jail. Notice sshd appears even though you did nothing — the package ships a default enabled jail. Before tuning anything, confirm your auth log path is what the jail expects, because a jail pointed at the wrong file silently does nothing while looking healthy.

Write a jail.local You Understand

The correct way to configure fail2ban is /etc/fail2ban/jail.local, which overrides the shipped jail.conf without touching it. Define your ban policy here once: a bantime that outlasts a scan, a maxretry that tolerates a human typo, and a findtime that counts attempts within a realistic burst.

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 192.168.0.0/16 10.0.0.0/8

[sshd]
enabled = true
port = ssh
logpath = /var/log/auth.log

[nginx-http-auth]
enabled = true
logpath = /var/log/nginx/error.log

ignoreip never ban your own monitoring and management ranges — home broadband, jump hosts, and your private subnet. A botnet behind a NAT can masquerade many attempts as one IP, so if you control a large office range, add it here rather than risking a real user being banned mid-demo.

Tune for Real Traffic

The default settings are conservative because false bans are worse than slow bans. A 10-minute findtime with maxretry 5 lets an attacker try five times every ten minutes forever. For internet-facing SSH with key-only auth, tighten it: attackers who cannot guess anyway get banned far harder.

[sshd]
enabled = true
maxretry = 3
bantime = 6h
findtime = 6m

For web services, watch out: a single reverse proxy or load balancer presents every visitor as one IP, so banning that IP takes down your whole site. If you sit behind a proxy, set the nginx jail to track the real client IP from the X-Forwarded-For header, or skip banning on that service entirely and rely on rate limiting at the application layer instead.

Get Notified When Something Happens

A ban you never hear about is a ban that might as well not exist. Configure jail.local to send an email so you learn what is actually hammering your box. On Debian this uses the sendmail package, which is lightweight and fine for alerting.

[DEFAULT]
action = %(action_mwl)s
mta = sendmail
dest = you@example.com
sender = fail2ban@your-server.example.com

action_mwl sends a ban email that includes who was banned, the matched log lines, and a whois summary of the source — exactly the signal you want when triaging whether a ban range belongs to a known attacker or an accidental victim.

Read the Status and Unban on Demand

Managing a ban by hand is inevitable: a colleague on a blocked IP, a test box whose IP drifted into a blacklist, or a rule you tightened too fast. Know the inspection and unban commands cold so you are never stuck waiting for a timer.

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 203.0.113.44
sudo fail2ban-client set sshd bantime 7d

The status output lists banned IPs and their remaining time, and set sshd unbanip lets you clear an individual address immediately. When you change rules in jail.local, run systemctl reload fail2ban rather than a hard restart so existing bans and state survive.

Takeaway

fail2ban converts the noisy reality of a public internet connection into a clean, defendable posture: every service that logs failures gets a jail, repeat sources get banned, and legitimate traffic is untouched by design. Start from the defaults, tune the timing to your threat model, and add notifications before you need them. A fresh Ubuntu 24.04 VPS on Netbay boots in under 60 seconds, so you can install and tune fail2ban immediately — netbayhosts.in.