Effectively Using Fail2Ban: A Practical Guide to Security Optimization Based on Real-World Cases

1. Introduction

When operating a Linux server, you'll experience numerous login attempts just by having the SSH port open. A tool that many people use to prevent this is Fail2Ban. However, simply installing and configuring it is not enough. Over time, the ban list can accumulate into hundreds or thousands, potentially impacting server performance.

This article shares how to operate Fail2Ban more effectively and efficiently, based on real server management experience.

If you're curious about how to install Fail2Ban and its basic configuration, please refer to my previous post! Guardian of Linux Server, Fail2Ban

2. Real-World Experience: 1,113 IPs Banned in Just 3 Weeks

About 3 weeks after configuring fail2ban on my test Linux server, I executed the command below:

sudo fail2ban-client status sshd

The result was as follows:

Currently failed: 1
Total failed: 5330
Currently banned: 1110
Total banned: 1113

In just 3 weeks, 1,113 IPs were blocked, with 1,110 of them still under ban. This is because I configured it for permanent blocking with bantime = -1.

Initially, I set it with the mindset of "No mercy for anyone who tries even once!", but after thousands of banned IPs accumulated in iptables, I started worrying about resource consumption and management efficiency.

Ultimately, I began to consider a sustainable and strategic approach to operating Fail2Ban.

Tux guarding the recidive jail

3. Strategies for Improving Fail2Ban Configuration

✅ Adjust bantime Dynamically

  • Time-based bans are more practical than permanent bans.
  • Example:
  • bantime = 86400        # 1-day ban
findtime = 600         # within 10 minutes
maxretry = 3           # after 3 failures

Fail2Ban blocking flowchart

✅ Utilize Recidive Jail

🔎 What is recidive jail?

fail2ban monitors the fail2ban.log file and, if a specific IP is repeatedly banned across multiple jails, it provides the advanced feature of long-term banning of that IP. In other words, it serves as a 'repeat offender monitoring system' that imposes heavier penalties on recidivists.

Typically, individual jails like sshd, nginx, and ftp impose short-term bans, but recidive jail selects IPs with 'accumulated criminal records' for longer bans.

  • Long-term bans applied only to repeatedly banned IPs
  • Ordinary attackers disappear within a day, but reattempting attackers can be filtered
  • Example configuration:
  • [recidive]
enabled = true
logpath = /var/log/fail2ban.log
bantime = 604800        # 1 week
findtime = 86400
maxretry = 5

✅ Automate Log Management

  • Automatically clean up /var/log/fail2ban.log before it grows large with logrotate settings
  • Summarize and email the results of fail2ban-client status using cron or systemd timer

4. Example Script for Reference

#!/bin/bash
fail2ban-client status sshd > /tmp/sshd-status.log
echo "Current Ban Count: $(grep 'Currently banned' /tmp/sshd-status.log)" | mail -s "Fail2Ban SSHD Status" your@email.com

5. Conclusion: Fail2Ban is a Tool, Not a Weapon

While Fail2Ban is a very useful tool for blocking random attacks, excessive operation can lead to blocking becoming a cause of server overload rather than a goal.

By configuring realistic blocking policies and automated management tools together, Fail2Ban becomes a dependable security partner instead of a headache.

Upcoming Post Preview

I plan to discuss logrotate settings to prevent the /var/log/fail2ban.log file from growing too large. If you're interested, please subscribe!