How to Use Fail2Ban to Blunt Brute-force Attacks

By: Steven J. Vaughan-Nichols

With Fail2Ban you can automatically help your firewall protect your server.

WordFence, the WordPress security plugin company, tells me that unsophisticated brute-force attacks have doubled in the past three weeks. While WordFence can help keep your WordPress instances up and running, your server is still getting mauled. What can you do about it? You can use Fail2Ban to patch your firewall against blunt attackers in real time.

It’s a shame that many of you haven’t heard of, never mind use, Fail2Ban. I’ve found it to be a very useful and easy way to protect servers that is just as easy to install and deploy.

Fail2Ban is an intrusion-prevention framework written in Python. It works by reading your SSH, Apache and other outward-facing internet service logs for signs of an attack. For example, if someone is constantly trying — and failing — to log in to SSH, Fail2Ban notes this and creates an iptables firewall rule to lock out the attacking IP address.

It’s no miracle worker. You shouldn’t use Fail2ban in place of a good set of iptables rules. If you allow your users to use weak passwords, Fail2Ban will only slow down hackers; it won’t stop them.

Better still, if you really want to protect your services from unauthorized users, you should use two-factor authentication (2FA). On Linode, you can deploy two-factor authentication from the Linode Manager. On other servers, you can implement 2FA using authenticator application such as Google Authenticator or Authy.

Of course, that won’t prevent bots from trying to pound on your system until the cows come home. That’s where Fail2Ban proves it usefulness.

Here’s how Fail2Ban works.

First, it reads in its core conf files. “.conf and .local” for its marching orders. If there are any IP addresses you want it to ignore — say, the one your lame cousin in accounting who can never remember his password uses — you place them in the jail.local under the ignoreip setting.

In the jail.local file you need to set the following parameters: bantime, findtime, and maxretry. These are the values that define the circumstances and duration of a ban.

Specifically these values are:

  • bantime: This is the length of time in seconds for which an IP is banned. If you set this to a negative number, the ban will be permanent. The default value of 600 bans an IP for a 10 minutes. I prefer to set this longer, 3,600, an hour.
  • findtime: This is length of time between unsuccessful login attempts before a ban is set. For example, if Fail2ban is set to ban an IP after 5 failed login attempts, those 5 attempts must occur within the set 10-minute findtime limit. That default works for me. Findtime, like bantime, is set in seconds. So if you wanted to block an IP address after 5 failures in five minutes, you’d set Findtime to 300.
  • maxretry: This sets the maximum number of failed attempts that can be made to access the server from a single IP before a ban is imposed. The default is set to 3. I think that’s a reasonable number.

By default, Fail2Ban only prevents SSH attacks. But it can be set to monitor assaults against any service that writes login attempts to a log file. Fail2ban uses regular expressions (regex) to search for bogus login attempts. I like to use it to protect such popular attack targets as ftp, POP, and IMAP.

Once Fail2Ban finds an attack recorded in the log files, it writes a new iptable rule to block the would-be intruder.

The best thing about all this? Once you’ve set up Fail2Ban to your liking, you don’t have to worry about it. It — and iptables — handles the would-be attacker for you.

Now, Fail2Ban isn’t going to stop a full-out Distributed Denial of Service (DDoS) attack. For that, you’ll still need a DDoS mitigation service such as those offered by Akamai, CloudFlare, and Incapsula.

If you want to know how Fail2Ban is protecting you, you can set it up to use your local mail transfer agent (MTA) to send you an email letting you know what IP addresses it’s blocking and that they’re being blocked.

From the Linode shell, you can also use

fail2ban-client status JAIL

to see what’s IP addresses are currently banned.

It’s all pretty simple and it takes away a lot of the worry about someone trying to bludgeon his way into your server. I highly recommend using Fail2Ban on your servers. It’s remarkably helpful.


Please feel free to share below any comments or insights about your experience using Fail2Ban to supplement your firewall and harden your server. And if you found this blog useful, consider sharing it through social media.


About the blogger: Steven J. Vaughan-Nichols is a veteran IT journalist whose estimable work can be found on a host of channels, including ZDNet.com, PC Magazine, InfoWorld, ComputerWorld, Linux Today and eWEEK. Steven’s IT expertise comes without parallel — he has even been a Jeopardy! clue. And while his views and cloud situations are solely his and don’t necessarily reflect those of Linode, we are grateful for his contributions. He can be followed on Twitter (@sjvn).