DEV Community

Cover image for How to Install and Configure Fail2Ban on CentOS 8 (Stop Brute Force)
FlatlinerAtheist | CLI-NERDS
FlatlinerAtheist | CLI-NERDS

Posted on Originally published at clinerds.com

How to Install and Configure Fail2Ban on CentOS 8 (Stop Brute Force)

#security #fail2ban #centos #ssh

Open SSH to the internet and the brute-force bots arrive within hours — thousands of password guesses a day from IPs that rotate constantly. Fail2Ban is the classic answer: it watches your logs, spots repeated failures, and bans the source IP automatically.

This guide installs and configures it on CentOS/RHEL 8 (and the steps are nearly identical on Rocky, Alma, and Ubuntu).

Install Fail2Ban

On CentOS/RHEL 8 you need the EPEL repository first:

sudo dnf install -y epel-release
sudo dnf install -y fail2ban
sudo systemctl enable --now fail2ban
Enter fullscreen mode Exit fullscreen mode

On Debian/Ubuntu it's simply sudo apt install fail2ban.

Configure a jail for SSH

Never edit jail.conf directly — package updates overwrite it. Create your own override:

sudo nano /etc/fail2ban/jail.local
Enter fullscreen mode Exit fullscreen mode 
[DEFAULT]
# Ban for 1 hour after 5 failures in 10 minutes
bantime = 1h
findtime = 10m
maxretry = 5
# Never ban your own management IP
ignoreip = 127.0.0.1/8 203.0.113.10

[sshd]
enabled = true
port = ssh
logpath = /var/log/secure
backend = systemd
Enter fullscreen mode Exit fullscreen mode

On Debian/Ubuntu the SSH log is /var/log/auth.log instead of /var/log/secure. With backend = systemd, Fail2Ban reads the journal directly and the logpath matters less.

Restart to apply:

sudo systemctl restart fail2ban
Enter fullscreen mode Exit fullscreen mode

Watch it work 

sudo fail2ban-client status sshd
Enter fullscreen mode Exit fullscreen mode

You'll see the currently banned IPs and the total ban count. Useful day-to-day commands:

sudo fail2ban-client status                      # all active jails
sudo fail2ban-client unban 198.51.100.77         # unban a specific IP
sudo tail -f /var/log/fail2ban.log               # live ban/unban events
Enter fullscreen mode Exit fullscreen mode

Test it safely from a second machine: fail your SSH password five times, watch your IP appear in the ban list, then unban yourself. Better to learn the unban command now than after locking yourself out.

Extend it beyond SSH

Fail2Ban ships with filters for common services. A few worth enabling on a typical server:

[nginx-http-auth]
enabled = true

[nginx-botsearch]
enabled = true

[postfix]
enabled = true
Enter fullscreen mode Exit fullscreen mode

Each filter looks for failure patterns in that service's log — failed Nginx auth, bots probing for admin panels, mail relay abuse. Enable only what you actually run.

Fail2Ban is a seatbelt, not a fortress

Banning IPs reduces log noise and slows brute force, but the real SSH hardening is elsewhere:

  • Key-only authentication — disable password logins entirely and brute force becomes pointless (our SSH hardening guide walks through it)
  • A firewall that only opens the ports you need
  • Rate limiting at the edge for web apps

With those in place, Fail2Ban becomes the cleanup crew rather than the front line — which is exactly where it belongs.

Top comments (0)