Fail2Ban and Intrusion Prevention

Your SSH server is under attack right now. Not maybe, not probably—right now. Automated scripts are guessing passwords against your server, trying root, admin, test, and thousands of other usernames with common passwords. This happens to every Internet-facing server, constantly.

You could watch the logs and manually block attackers. But you have better things to do, and attackers don't sleep.

Fail2Ban does this job for you. It watches your logs, spots the attack patterns, and updates your firewall to block the offenders—automatically, in real-time, without you lifting a finger.

The Bouncer with a Memory

The genius of Fail2Ban isn't the blocking—any firewall can block an IP. It's the memory. It remembers who's been knocking.

When someone fails to log into your SSH server, Fail2Ban notes the IP address and the time. When the same IP fails again, Fail2Ban remembers. And when that IP hits three failures in ten minutes? The door slams shut. A firewall rule appears, and that IP can no longer reach your SSH port.

Ten minutes later (or an hour, or a day—you configure this), the ban lifts. The attacker can try again. And if they do, Fail2Ban remembers that too.

This is intrusion prevention through pattern recognition: watch, remember, respond.

What Fail2Ban Actually Watches

Fail2Ban protects anything that writes to a log file.

SSH is the classic case. Failed password attempts appear in auth logs. Fail2Ban watches those logs, counts failures per IP, and bans IPs that fail too often. This stops brute force attacks cold—an attacker can't guess a million passwords if they get blocked after five wrong guesses.

Web servers generate logs full of suspicious activity: failed login attempts to admin panels, requests for known-vulnerable URLs, scanning for .php files on a site that doesn't use PHP. Each pattern can trigger a ban.

Email servers face constant authentication attacks. Spammers want to relay through your server. Fail2Ban watches for failed SMTP authentication and blocks the sources.

Anything with logs can be protected. If your application logs failed logins, Fail2Ban can watch those logs. The pattern matching is just regular expressions—if you can describe what an attack looks like in your logs, Fail2Ban can respond to it.

The Three Numbers That Matter

Fail2Ban's behavior comes down to three configuration values:

maxretry: How many failures before a ban? Set this too low and legitimate users who mistype their password get locked out. Set it too high and attackers get more guesses. For SSH, 3-5 is common. For web forms, 10-20 gives users more room for error.

findtime: How long is the memory window? If maxretry is 5 and findtime is 10 minutes, an IP needs 5 failures within 10 minutes to trigger a ban. Spread those failures over an hour and nothing happens. Shorter windows catch aggressive attacks; longer windows catch patient ones.

bantime: How long does the door stay shut? Ten minutes stops a casual attack. An hour makes them go elsewhere. Permanent bans accumulate forever. Some configurations escalate: first offense is an hour, second offense within a week is 24 hours, third offense is permanent.

These three numbers define the tradeoff between security and usability. Aggressive settings block attacks but also block legitimate users who make mistakes. Lenient settings let more attacks through but don't create false positives.

How the Pieces Fit Together

Fail2Ban's architecture has three core concepts:

Filters are pattern matchers. A filter is a regular expression that identifies attack signatures in log files. The SSH filter looks for "Failed password" and "Invalid user" messages. The Apache filter looks for authentication failures and suspicious requests. Fail2Ban ships with filters for common services, and you can write custom filters for anything else.

Jails are the units of protection. A jail combines a filter (what to look for), a log file (where to look), and actions (what to do). The SSH jail watches /var/log/auth.log with the SSH filter. The Apache jail watches /var/log/apache2/error.log with the Apache filter. Each jail has its own maxretry, findtime, and bantime settings.

Actions are responses to triggered jails. The default action adds a firewall rule blocking the IP. But actions can do anything: send email alerts, write to a database, notify a SIEM, or run arbitrary scripts. Blocking is just the most common response.

Where Fail2Ban Falls Short

Fail2Ban has real limitations. Understanding them matters.

Distributed attacks defeat it. If a botnet attacks from 10,000 different IP addresses, each IP only tries a few times. No single IP triggers the threshold. The attack succeeds even though Fail2Ban is watching.

Shared IPs create collateral damage. This is the genuinely absurd part: an attacker at a coffee shop can get every customer at that coffee shop banned from your server. Corporate NATs, university networks, mobile carriers—they all share IPs among many users. Ban one attacker, block thousands of innocents.

Dynamic IPs mean bans have limited memory. The IP that attacked you yesterday might belong to someone else today. Long ban times increasingly block the wrong people.

Fast attackers can outrun it. There's always latency between an attack appearing in a log and Fail2Ban processing it. A fast enough attacker can try many passwords before the ban kicks in.

High traffic means CPU cost. Parsing every log line against multiple regular expressions takes cycles. On a busy server generating thousands of log entries per second, this adds up.

None of these limitations make Fail2Ban useless. They make it one layer in a defense that needs multiple layers.

What Fail2Ban Can't Replace

Fail2Ban is a response mechanism. It reacts to attacks that have already started. It doesn't prevent attacks from beginning, and it doesn't fix the underlying vulnerabilities that make attacks possible.

Strong authentication—SSH keys instead of passwords, multi-factor authentication, rate limiting at the application level—these prevent attacks from succeeding even if Fail2Ban never triggers. Fail2Ban catches what gets through those defenses and slows down attackers who are probing for weaknesses.

Think of it as a night guard, not a lock. The lock keeps people out. The guard watches for people trying to pick the lock and escorts them off the property. You want both.

Fail2Ban in Practice

A typical Fail2Ban deployment protects SSH with a jail that bans IPs after 5 failures in 10 minutes, with a 1-hour ban time. That stops 99% of brute force attacks with essentially zero false positives—legitimate users rarely mistype their password five times in ten minutes.

More sophisticated deployments add jails for each exposed service, tune thresholds based on observed attack patterns, and escalate ban times for repeat offenders. The most paranoid configurations feed threat intelligence into Fail2Ban, pre-banning IPs that appear on known-bad lists before they even attack.

The logs Fail2Ban generates—which IPs got banned, how often, for what—become security intelligence themselves. Sudden spikes in bans indicate attacks. Repeated bans from specific IP ranges suggest targeted campaigns. The bouncer's memory becomes your memory of who's been trying to get in.