How to Protect Your Server from Brute-Force Attacks with Fail2ban

Every server exposed to the internet gets hammered by brute-force login attempts — bots throwing thousands of username/password combinations at SSH, WordPress, or mail services. Fail2ban is the standard defense: it watches your log files, spots repeated failures from the same IP, and bans that IP at the firewall level on its own. Here’s how to set it up properly in about ten minutes.

Step 1: Install Fail2ban

On Debian/Ubuntu:

sudo apt update && sudo apt install fail2ban -y

On CentOS/Rocky/AlmaLinux:

sudo dnf install epel-release -y
sudo dnf install fail2ban -y

Enable and start the service:

sudo systemctl enable --now fail2ban
sudo systemctl status fail2ban

Step 2: Create Your Local Configuration

Never edit jail.conf directly — it gets overwritten on updates. Create jail.local instead:

sudo nano /etc/fail2ban/jail.local

A solid starting configuration:

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
ignoreip = 127.0.0.1/8 YOUR.OFFICE.IP.HERE

[sshd]
enabled = true
port    = ssh
maxretry = 3
bantime  = 24h

This means: if an IP fails 3 SSH logins within 10 minutes, it’s banned for 24 hours. Drop your own static IP into ignoreip so you never lock yourself out. Restart to apply:

sudo systemctl restart fail2ban

Step 3: Protect WordPress and Nginx Too

Fail2ban can guard more than just SSH. For WordPress login floods, add a jail that watches your web server access log for POSTs to wp-login.php:

[wordpress-login]
enabled  = true
port     = http,https
filter   = wordpress-login
logpath  = /var/log/nginx/access.log
maxretry = 5
bantime  = 12h

Then create the filter /etc/fail2ban/filter.d/wordpress-login.conf:

[Definition]
failregex = ^<HOST> .* "POST /wp-login.php

Restart Fail2ban, and every bot hammering your login page gets cut off after 5 attempts.

Step 4: Monitor and Manage Bans

Check what’s happening day to day:

# Overall status and active jails
sudo fail2ban-client status

# Details of one jail, including banned IPs
sudo fail2ban-client status sshd

# Manually unban an IP
sudo fail2ban-client set sshd unbanip 1.2.3.4

Pair Fail2ban with two free, easy wins: move SSH to key-based authentication (PasswordAuthentication no) and keep maxretry low. Together they shut out virtually all automated brute-force traffic.

FAQ

Q1: Will Fail2ban slow down my server?
No. It only tails log files and adds firewall rules. The CPU and memory footprint are negligible even on a 1GB VPS.

Q2: What if I ban myself?
Log in through your provider’s VNC/console (not SSH), then run fail2ban-client set sshd unbanip YOUR_IP. Avoid it entirely by adding your IP to ignoreip.

Q3: Is Fail2ban enough by itself?
It’s one layer. Combine it with SSH key authentication, a UFW/firewalld ruleset that only opens needed ports, and regular updates for a solid baseline.

Got a jail that won’t ban, or a custom service you want to protect? Drop a comment below on fenij.com and I’ll help you debug the filter.