← Harden & defendfail2ban auto bans brute forcers, set it up right

fail2ban auto bans brute forcers, set it up right

$systemctl restart fail2ban

the hook

if you've ever tailed an ssh log on a public facing server, you know the feeling. it's not one login attempt, it's thousands, from botnets that never sleep, all trying admin, root, and password123 at 3am. fail2ban is the tool that gets tired of watching that garbage so you don't have to. it reads your logs, notices someone hammering the login prompt, and bans their ip automatically. free, lightweight, and it's been keeping servers sane for two decades. let's set it up right so it actually protects you instead of just sitting there installed and useless.

what fail2ban is actually doing

fail2ban watches log files, ssh, nginx, apache, whatever you point it at, using regex patterns called filters. when it sees a matching failure pattern too many times from the same ip within a set window, it triggers a "jail" which drops a firewall rule blocking that ip for a set amount of time. that's it. no ai, no magic, just pattern matching plus iptables or nftables doing the actual blocking. the config lives mostly in /etc/fail2ban/jail.local, which you should create instead of editing jail.conf directly, since updates overwrite that file.

the three numbers that actually matter

bantime, findtime, and maxretry are the core of your defense. get these wrong and you're either too lenient to matter or too aggressive and locking out legit users, including yourself.

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5

this means: if an ip fails to log in 5 times within a 10 minute window, it gets banned for 1 hour. that's a solid starting point. for public facing ssh servers getting hammered constantly, you can push bantime way higher, days even, since real users rarely fail login 5 times in 10 minutes anyway. bots don't care and will just keep coming back, so a longer ban saves your cpu from processing the same garbage traffic over and over.

watch more than just ssh

ssh is the obvious target but it's not the only door. if you're running a web app with a login form, wordpress, nextcloud, a custom api, brute forcers will hit that too. fail2ban ships with filters for a bunch of common services, and you enable the jails you need in jail.local:

[sshd]
enabled = true

[nginx-http-auth]
enabled = true

[nginx-botsearch]
enabled = true

if your app doesn't have a built in filter, you can write a custom one that matches your app's failed login log line. the filter just needs a regex that captures the attacking ip. check /etc/fail2ban/filter.d/ for examples before writing one from scratch.

don't lock yourself out

this is the step people skip and then panic about later. if you're managing the server remotely and you fat finger your password 5 times, fail2ban will ban you just as fast as it bans a botnet in another country. whitelist your own static ip, your vpn range, or your office network in the ignoreip line:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 203.0.113.4

if your ip changes a lot, consider whitelisting a vpn you control instead of your home ip, or set up a secondary access method, like console access through your hosting provider, so a lockout isn't a full outage. also worth noting, fail2ban bans the source ip, not the account, so if you're behind cgnat or a shared network, one person's bad login attempts can lock out everyone on that ip. plan around that if it applies to you.

turn it on and verify it's working

once your jail.local is set up, restart the service so it picks up the changes:

systemctl restart fail2ban

then confirm it's actually running and watching what you think it's watching:

fail2ban-client status
fail2ban-client status sshd

the second command shows you currently banned ips for that jail. run fail2ban-client set sshd unbanip [ip] if you ever need to manually release one, which you will, probably for yourself, at least once.

the takeaway

fail2ban doesn't stop a determined, targeted attacker with infinite patience, but it absolutely wrecks the automated noise that makes up the vast majority of brute force traffic hitting your server right now. the setup takes ten minutes: set your ban logic, watch the right jails, whitelist yourself, restart, and check status. do that today, then go check your auth log. you'll probably be shocked how much traffic was hitting you before you even noticed.

watch the reel ↗
the weekly drop

one command a week that makes you harder to hack.

a single tool, explained in plain english, every week. straight to your inbox.

no spam. one email a week. unsubscribe anytime.