Use Fail2ban to Protect SSH and Web Services

Who This Is For

Beginner. A simple security project with visible, understandable results.

Think of it like a bar bouncer who remembers faces. Get the password wrong too many times at the door, and you’re not walking back in again for a while.

What You’ll Build

SSH protected by a working Fail2ban jail that actually bans repeat offenders.

Prerequisites

• A Linux host running SSH and/or Nginx

Install Fail2ban

$ sudo apt install fail2ban

Never Edit jail.conf Directly

That file gets overwritten on updates. Create your own override instead:

$ sudo nano /etc/fail2ban/jail.local

Enable SSH Protection

$ [sshd]
$ enabled = true
$ maxretry = 5
$ findtime = 10m
$ bantime = 1h

Understand the Key Settings

• maxretry, how many failures before a ban
• findtime, the window those failures must occur within
• bantime, how long the ban lasts
• backend, systemd journal vs. traditional log file, must match how your distro actually logs

Add a Jail for Nginx

$ [nginx-http-auth]
$ enabled = true

View Active Bans

$ sudo fail2ban-client status sshd

Test Without Locking Yourself Out

Test from a second machine or a network you’re not currently connected through, not your own active session.

Security & Backup Notes

• A reverse proxy in front of a service will show Fail2ban the proxy’s IP, not the real client, unless log formats and forwarded-IP handling are configured correctly

Troubleshooting

• No matching log entries, check whether your distro logs via systemd journal or a flat file, and match the jail’s backend setting
• UFW/nftables action mismatch, Fail2ban’s ban action must match the firewall tool actually in use
• Reverse proxy logs the proxy IP, configure the upstream service to log the real client IP via forwarded headers

Lab Finish Line

SSH is protected by a working Fail2ban jail.

What to Build Next

• CrowdSec
• Centralized Logging