Bruce force attacks are attempts to guess common passwords by repeatedly trying to login to your server.  SSH is the most common target but FTP, IMAP, POP3, and other password-based systems can be targeted. While you, as perhaps a more sophisticated user, may choose strong passwords, your users may not.  Shared hosting servers with thousands of accounts are particularly vulnerable.  Many “script kiddies” will robotically probe, scan, and attack servers one after another, trying dozens of common passwords to move on.  All they need is a single user who’s chosen “monkey1” or “abc123” and they’re in.

You can defeat these attacks by using fail2ban.  This software watches your log files and if it sees a pattern of login failures, it inserts a firewall rule that blocks all connections from that IP.  Even if the block is temporary, this slows the attacker down from doing hundreds of attempt per minute to perhaps only 3 every 10 minutes.  This is all done automatically, so even when you’re sleeping, fail2ban is guarding your server.

In this tutorial, we’ll show you how to setup and configure fail2ban.

Prerequisite: Postfix (optional)

I’m going to install Postfix, a mail server, so that fail2ban can send me an email whenever an IP is blocked.  If you already have a functioning mail server (specifically, an MTA – Mail  Transfer Agent) on your system, you can skip this step.

On Debian, installing Postfix is as simple as:

apt-get install postfix

You’ll be asked how to configure it and you should probably answer Internet site.  There are tons of configuration possibilities with Postfix but this will get you going.  In this example, I’m using a server named secure.lowend.party:

Installing fail2ban

Once again, Debian makes it easy:

apt-get install fail2ban

Configuring fail2ban

fail2ban’s configuration lives in /etc/fail2ban.  Let’s set up fail2ban to handle simple sshd protection.

In /etc/fail2ban/jaild., create a file called local.conf and populate it as follows:

[DEFAULT]
destemail = "someone@example.com"
sender = "root@secure.lowend.party"
ignoreip = 127.0.0.1/8 1.2.3.4/32
action=%(action_mwl)s

[sshd]
enabled = true
filter = sshd
# port = 2222
logpath = /var/log/auth.log
findtime = 600
maxretry = 3
bantime = 600

Let’s walk through those.

First, you have a DEFAULT section that applies to all fail2ban sections.

• destemail: Who receives fail2ban alerts
• sender: Who alerts come from.
• ignoreip: I’ve listed two IPs here.  The first is the entire /8 block of localhost.  The second is my home IP.  These IPs will never be blocked by fail2ban.  Note that many people’s home IPs change due to DHCP, so keep that in mind.
• action: in this case I’ve selectd the “mwl” action, which means “mail with log”.  You can define your own actions – take a look at /etc/fail2ban/jail.conf to see other options, or Read The Fine Manual.

Next I’ve defined a section for sshd:

• enabled: to toggle it on
• filter: corresponds to a configuration in filter.d.  The config files (over 80 different services are shipped with fail2ban to easily enable) include things like regular expressions to match in logs and other info fail2ban needs to work.
• I’ve commented out port but if you run with a custom port, define it here
• logpath: the…you guessed it, it’s the path to the log
• findtime and maxretry: fail2ban takes action if the number of failed logins exceeds maxretry times in findtime seconds.
• bantime: how long the ban persists before it’s auto-removed

Once you’ve created the config file, you can check it with the command-line fail2ban client:

fail2ban-client -t
root@secure:/etc/fail2ban/jail.d# fail2ban-client -t
OK: configuration test is successful

fail2ban in Action

I went to another VPS and tried repeatedly to login to this server via ssh, entering the wrong password each time.  On my four attempt, this appeared in secure.lowend.party’s log file (/var/log/auth.log).  The IP has been anonymized:

2020-07-26 13:21:57,623 fail2ban.actions [10814]: NOTICE [sshd] Ban 1.2.3.4

For the next 10 minutes, I was unable to connect to anything on secure.lowend.party.  I couldn’t connect to the SSH port to retry.

On secure.lowend.party, I saw this in the iptables:

Chain f2b-sshd (1 references)
target prot opt source destination
REJECT all -- server.example.com anywhere reject-with icmp-port-unreachable
RETURN all -- anywhere anywhere

And I received this email:

The ban expired after ten minutes, but if I wanted to unban a client before that, I could use this command:

fail2ban-client unban 1.2.3.4

raindog308

Raindog308 is a longtime LowEndTalk community administrator, technical writer, and self-described techno polymath. With deep roots in the *nix world, he has a passion for systems both modern and vintage, ranging from Unix, Perl, Python, and Golang to shell scripting and mainframe-era operating systems like MVS. He’s equally comfortable with relational database systems, having spent years working with Oracle, PostgreSQL, and MySQL.

As an avid user of LowEndBox providers, Raindog runs an empire of LEBs, from tiny boxes for VPNs, to mid-sized instances for application hosting, and heavyweight servers for data storage and complex databases. He brings both technical rigor and real-world experience to every piece he writes.

Beyond the command line, Raindog is a lover of German Shepherds, high-quality knives, target shooting, theology, tabletop RPGs, and hiking in deep, quiet forests.

His goal with every article is to help users, from beginners to seasoned sysadmins, get more value, performance, and enjoyment out of their infrastructure.

You can find him daily in the forums at LowEndTalk under the handle @raindog308.