Ubuntu Server 18.04 – Installing and configuring Fail2ban

Installing Apache On CentOS 8

Fail2ban, how I love thee! Fail2ban is one of those tools that once I learned how valuable it is, I wondered how I ever lived so long without it. In the past, I used a utility known as DenyHosts to secure OpenSSH. DenyHosts protects SSH (no more, no less). It watches the server’s log files, looking for authentication attempts. If it sees too many failures from a single IP address, it will create a firewall rule to block that IP. The problem was that it only protected OpenSSH. Another problem is that DenyHosts just kind of went away quietly. For some reason, it stopped being maintained and some distributions removed it outright. Fail2ban does what DenyHosts used to do (protect SSH) and more, as it is able to protect other services as well.

Installing and configuring Fail2ban is relatively straightforward. First, install its package:

sudo apt install fail2ban

After installation, the fail2ban daemon will start up and be configured to automatically start at boot-time. Configuring fail2ban is simply a matter of creating a configuration file. But, this is one of the more interesting aspects of Fail2ban, you shouldn’t use its default config file. The default file is /etc/fail2ban/jail.conf. The problem with this file is that it can be overwritten when you install security updates, if those security updates ever include Fail2ban itself. To remedy this, Fail2ban also reads the /etc/fail2ban/jail.local file, if it exists. It will never replace that file, and the presence of a jail.local file will supersede the jail.conf file. The simplest way to get started is to make a copy of jail.conf and save it as jail.local:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Next, I’ll go over some of the very important settings you should configure, so open up the /etc/fail2ban/jail.local file you just copied in a text editor. The first configuration item to change is located on or around line 54 and is commented out:

#ignoreip = ::1

First of all, uncomment it. Then, you should add additional networks that you don’t want to be blocked by Fail2ban. Basically, this will help prevent you from getting locked out in a situation where you accidentally trigger Fail2ban. Fail2ban is relentless; it will block any service that meets its block criteria, and it won’t think twice about it. This includes blocking you. To rectify this, add your company’s network here, as well as any other IP address you never want to be blocked. Make sure to leave the localhost IP intact:

Ignoreip = ::1

In that example, I added the network, as well as a single IP address of Add your networks to this line to ensure you don’t lock yourself out.

Next, line 63 includes the bantime option. This option pertains to how many seconds a host is banned when Fail2ban blocks it. This option defaults to 10m:

bantime  = 10m

Change this number to whatever you find reasonable, or just leave it as its default, which will also be fine. If a host gets banned, it will be banned for this specific number of minutes, until it will eventually be allowed again.

Continuing, we have the maxretry setting:

maxretry = 5

This is specifically the number of failures that need to occur before Fail2ban takes action. If a service it’s watching reaches the number set here, game over! The IP will be blocked for the number of minutes included in the bantime option. You can change this if you want to, if you don’t find 5 failures to be reasonable. The highest I would set it to is 7, for those users on your network who insist they’re typing the correct password and they type the same (wrong) thing over and over. Hopefully, they’ll realize their error before their seventh attempt and won’t need to call the helpdesk.

Skipping ahead all the way down to line 231 or thereabouts, we have the Jails section. From here, the config file will list several Jails you can configure, which is basically another word for something Fail2ban will pay attention to. The first is [sshd], which configures its protection of the OpenSSH daemon. Look for this option underneath [sshd]:

port    = ssh

port being equal to ssh basically means that it’s defaulting to port 22. If you’ve changed your SSH port, change this to reflect whatever that port is. There are two such occurrences, one under [sshd] and another underneath [sshd-ddos]:

port    = 65332

Before we go too much further, I want to underscore the fact that we should test whether Fail2ban is working after each configuration change we make. To do this, restart Fail2ban and then check its status:

sudo systemctl restart fail2ban
sudo systemctl status -l fail2ban  

The status should always be active (running). If it’s anything else, that means that Fail2ban doesn’t like something in your configuration. Usually, that means that Fail2ban’s status will reflect that it exited. So, as we go, make sure to restart Fail2ban after each change and make sure it’s not complaining about something. The status command will show lines from the log file for your convenience.

Another useful command to run after restarting Fail2ban is the following:

sudo fail2ban-client status

The output from that command will show all the Jails that you have enabled. If you enable a new Jail in the config file, you should see it listed within the output of that command.

So, how do you enable a Jail? By default, all Jails are disabled, except for the one for OpenSSH. To enable a Jail, place the following within its config block in /etc/fail2ban/jail.local file:

enabled = true 
Earlier versions of Ubuntu included the enabled = false line for each Jail in the sample jail.conf file. In that case, you’d only need to change the line to enabled = true to enable a Jail if you’re using an older version of Ubuntu.

If you want to enable the apache-auth Jail, find its section, and place enabled = true right underneath its stanza. For example, apache-auth will look like the following after you add the enabled line:

enabled = true 
port     = http,https 
logpath  = %(apache_error_log) 

In that example, the enabled = true portion wasn’t present in the default file. I added it. Now that I’ve enabled a new Jail, we should restart fail2ban:

sudo systemctl restart fail2ban

Next, check its status to make sure it didn’t explode on startup:

sudo systemctl status -l fail2ban

Assuming all went well, we should see the new Jail listed in the output of the following command:

sudo fail2ban-client status

On my test server, the output became the following once I enabled apache-auth:

|- Number of jail: 2

  `- Jail list:    apache-auth, sshd

If you enable a Jail for a service you don’t have installed, Fail2ban may fail to start up. In my example, I actually did have apache2 installed on that server before I enabled its Jail. If I hadn’t, Fail2ban would likely exit, complaining that it wasn’t able to find log files for Apache. This is the reason why I recommend that you test Fail2ban after enabling any Jail. If Fail2ban decides it doesn’t like something, or something it’s looking for isn’t present, it may stop. Then, it won’t be protecting you at all, which is not good.

The basic order of operations for Fail2ban is to peruse the Jail config file, looking for any Jails you may benefit from. If you have a daemon running on your server, there’s a chance that there’s a Jail for that. If there is, enable it and see whether Fail2ban breaks. If not, you’re in good shape. If it does fail to restart properly, inspect the status output and check what it’s complaining about.

One thing you may want to do is add the enabled = true line to [sshd] and [sshd-ddos]. Sure, the [sshd] Jail is already enabled by default, but since it wasn’t specifically called out in the config file, I don’t trust it. So you might as well add an enabled line to be safe. There are several Jails you may benefit from. If you are using SSL with Apache, enable [apache-modsecurity]. Also, enable [apache-shellshock] while you’re at it. If you’re running your own mail server and have Roundcube running, enable [roundcube-auth] and [postfix]. There are a lot of default Jails at your disposal!

Like all security applications, Fail2ban isn’t going to automatically make your server impervious to all attacks, but it is a helpful additional layer you can add to your security regimen. When it comes to the Jails for OpenSSH, Fail2ban is worth its weight in gold, and that’s really the least you should enable. Go ahead and give Fail2ban a go on your servers—just make sure you also whitelist your own networks, in case you accidentally type your own SSH password incorrectly too many times. Fail2ban doesn’t discriminate; it’ll block anyone. Once you get it fully configured, I think you’ll agree that Fail2ban is a worthy ally for your servers.

Comments are closed.