How to Protect Your Server With Fail2Ban in Linux

Securing a server is a top priority for any business or organization. One of the most important tools in a sysadmin’s toolkit is Fail2Ban. This guide explains what Fail2Ban is and how you can use it to protect your Linux server from attacks.

Tip: in addition to Fail2Ban, check out these open-source tools to secure your server.

What Is Fail2Ban?

Fail2Ban is an intrusion prevention tool that monitors log files and bans IP addresses that show signs of malicious activity. It does this by creating “filters” that match certain patterns in the log files and executing actions, such as banning the offending IP address.

Why Use Fail2Ban? 

There are a few reasons to use fail2ban. It can:

• save you time by automatically banning malicious IP addresses.

• help to secure your server by reducing the chances of a successful attack.

• give you peace of mind knowing that your server is being monitored and protected.

Installing Fail2Ban

By default, Fail2Ban is available in the Ubuntu repositories. Install it using apt.

sudo add-apt-repository universe
sudo apt update && sudo apt install fail2ban -y

Fail2Ban will set its service in the background, but systemd will disable it by default. You can start and enable it with the following commands:

sudo systemctl start fail2ban
sudo systemctl enable fail2ban

Verify that Fail2Ban is running with the following command:

sudo systemctl status fail2ban

You will see an output similar to the image below.

Configuring Fail2Ban

The “/etc/fail2ban” directory contains the configuration files for Fail2Ban. By default, Fail2Ban comes with a “jail.conf” file that contains settings that will apply to all services.

However, it is good practice to create a local “jail.local” file and override the settings in “jail.conf,” as you will lose any changes you make to “jail.conf” whenever the program updates.

You can create your “jail.local” file with the following commands:

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

Open the jail.local file to edit it:

sudo nano /etc/fail2ban/jail.local

Good to know: learn how to create a SSH honeypot to catch hackers in your server.

Exploring the jail.local File

You will see a similar output as below and may be overwhelmed by the number of options available. But don’t worry, as we are walking you through the most important options.

You will see the “#” symbol at the beginning of a line, indicating that it is a comment. Fail2Ban uses these to explain what a particular setting does. You can enable some of the settings here by removing this symbol.

The “[DEFAULT]” section contains the options applied to all jails. This is the global configuration for Fail2Ban. The following screenshot shows an example of this.

There are also other sections that start with the name of a service. This jail applies to a specific service over the top of the global jails.

For example, there is a section for “sshd” jail. This section contains the options that are specific to the sshd service.

Tip: you can also learn more about server hardening by securing your SSH server.

Enabling the Autoban Feature

Navigate to the “bantime = 1h” setting and remove the “#” symbol at the beginning of the line to enable it. This line sets the duration for how long Fail2Ban will disable an IP address. The default unit is one hour. You can also use other units, such as minutes(m), days (d), or even weeks (w).

You can increase or decrease this value as you see fit. For example, you can change this value to 30m to reduce the length of the ban to 30 minutes.

Changing the Default Login Window Length

The next settings are “maxretry” and “findtime.” They determine how many login attempts an attacker can do before Fail2Ban bans his IP.

The default values for “maxretry” and “findtime” are 5 and 10m. If an IP fails to authenticate five times in ten minutes, Fail2Ban will ban it for the duration specified by the bantime setting.

You can change these values to whatever you want. For example, you can set “maxretry” to 3 and “findtime” to 5m: Fail2Ban will disable an IP if it fails to authenticate three times in five minutes.

Enabling Fail2Ban’s Notification Feature

The next settings are destemail, sendername and mta. These settings are what Fail2Ban will use to configure email notifications.

• The destemail setting is the email address where the program will send its notifications.

• The sendername is the name that will show up in the “From” field of the notification email.
• The mta is the mail transfer agent that Fail2Ban will use to send emails. The default mta is sendmail, but you can change it to something else like mail.

If you want to receive email notifications, you need to uncomment these lines and enter the appropriate values as shown.

When a ban occurs, you will receive an email notification with details about the ban as shown.

Creating Custom Ban Commands

The next setting is “action_ =.” This determines the action that Fail2ban takes when it bans an IP address. The default action is to use iptables to block the IP until the “bantime” has passed.

You can also use other actions, as shown below. This tutorial sticks with the default for the sake of simplicity.

• action_mw: sends an email notification when an IP is banned, attached with relevant WHOIS information.

• action_mwl: sends an email notification when an IP is banned, attached with relevant WHOIS information and the log file entries that triggered the ban.

• action_xarf: sends an email notification in the X-ARF format when an IP is banned with the log file entries that triggered the ban.

Many other actions are available, but it’s impossible to cover them all in this tutorial. You can read about all of the available actions in the Fail2ban documentation.

Enabling Service-Specific Configuration

Aside from configuring Fail2ban’s default behavior, it is also possible to use pre-made “filter files” for some of the common Internet services. These are small files that the developers wrote to look for specific log output of a particular server daemon.

For example, the “apache-shellshock.conf” file contains all of the necessary settings to allow Fail2ban to check for any malicious attempts to create the shellshock bug.

You can find all the available filter files for your system by listing the “/etc/fail2ban/filter.d” directory:

ls /etc/fail2ban/filter.d

Once you know the filters that you want to use, tell Fail2ban to load them during startup by opening your “jail.local” file:

sudo nano /etc/fail2ban/jail.local

Create a space in “jail.local” where you can activate your new filters. I am creating mine between the comment header and the [INCLUDES] block.

Add the filters that you want to activate. For example, the following is an excerpt that I use in my configuration:

# Comments: use '#' for comment lines and ';' (following a space) for inline comments
 
[sshd]
enabled = true
 
[nginx-bad-request]
enabled = true
 
[bitwarden]
enabled = true
 
[INCLUDES]

Once done, save and close the file. Restart fail2ban to apply the changes.

sudo systemctl restart fail2ban

Testing Your Configuration

Now that you have configured fail2ban, it’s time to test it.

The simplest way to test your configuration is to try to log in with an incorrect password multiple times in quick succession. You can use an SSH connection to do this.

On a disposal machine, try to SSH into your Fail2ban server using an “admin” username. Replace “your_server_ip_address” with the actual IP address of your Fail2ban server.

ssh admin@your_server_ip_address

Enter a random password when prompted and repeat it a few times. After a few attempts, you will see a message that the server refused your connection attempt.

Aside from using ssh, you can also test the other filter files in Fail2ban by triggering their “fail state.” In my case, I am using the “nginx-bad-request” filter that detects whether there is a host that’s flooding the server with invalid requests.

Knowing that, you can test this feature by deliberately sending empty requests to your web server using curl:

curl -H "User-Agent:" -H "Host:" https://yourwebsite.com -v

Good to know: while Fail2ban works brilliantly with Nginx, you can also use this program to protect your Apache server.

Verifying Fail2ban’s Actions

Finally, run the below command on your Fail2ban server to verify that fail2ban has added the necessary rules to iptables.

The grep command filters the output of the iptables command. The -S option tells iptables to print the rules in a format that can be easily parsed.

sudo iptables -S | grep f2b

You will see an output similar to the one pictured below. The  “–reject-with icmp-port-unreachable” argument tells iptables to send an ICMP port unreachable message back to the client when it tries to connect. You can also see the IP addresses of the machines that server has banned.

Tip: you should also make use of SELinux to secure your Linux server.

Frequently Asked Questions

Image credit: Unsplash. All alterations and screenshots by Ramces Red.

Ramces Red - Staff Writer

Ramces is a technology writer that lived with computers all his life. A prolific reader and a student of Anthropology, he is an eccentric character that writes articles about Linux and anything *nix.