Protect SSH with Fail2ban in Debian 11 or newer
Fail2ban is a utility that protects various services against attacks, for example, brute-force attacks.
Fail2Ban is a tool that protects Linux‑based machines from various types of attacks and malicious behavior. The tool can safeguard several services, including SSH, HTTP, and FTP.
Fail2Ban monitors log files in real time and looks for signs of automated attacks against your server. It provides effective protection against brute‑force attacks by automatically blacklisting attackers’ IP addresses in the firewall.
In this guide, you’ll see examples of some of Fail2Ban’s most basic features, and we’ll show you how to configure the tool to protect SSH on a virtual machine running Debian 11 in Glesys Cloud.
Prerequiste
Create a Cloud virtual machine with Debian 11 or newer as the operating system. The procedure is the same for Ubuntu 22.04 or newer—except for the final step concerning restarting the firewall.
You need access to a user with root privileges. Log in as
rootor use thesudoprefix with your own user.
Install Fail2ban
Start by updating the package repository:
sudo apt updateThen, install Fail2ban:
sudo apt install fail2banOnce the installation is complete, we need to enable Fail2Ban so that it starts automatically whenever the server is rebooted:
sudo systemctl enable fail2ban.serviceConfigure Fail2ban
By default, the settings are located in /etc/fail2ban/jail.conf, but this file gets overwritten during a Fail2Ban upgrade. Therefore, we create a new file called jail.local instead. Settings placed in jail.local take precedence over those in jail.conf.
Create and open the file using the following command:
Paste the section below and replace <YOUR IP ADDRESS> with your computer’s public IP address. This prevents you from temporarily locking yourself out. Fail2Ban supports both IPv4 and IPv6 addresses.
These settings provide you with solid basic protection, but you can configure them to suit your needs.
Explanation of configuration options
Below you can see what each of the settings means:
Fail2Ban will not block the IP addresses listed in ignoreip. Replace with your own IP address to avoid being temporarily locked out.
The banaction setting determines how the attacker’s IP address will be blocked. By default, Fail2Ban uses iptables, but since Debian 11, nftables has replaced iptables. Using nftables-allports blocks all of the server’s ports for the attacker. If you prefer to block only the SSH port for the attacker, replace banaction = nftables-allports with banaction = nftables.
maxretry specifies the number of login attempts allowed before an IP address is blacklisted within the findtime period.
bantime specifies the total duration in seconds that an IP address remains blacklisted. The default value of 600 means the IP address will be blocked for 10 minutes.
findtime specifies the time window in which the allowed number of maxretry attempts must occur before the IP address is blacklisted.
Restarting Fail2ban after modifying the configuration
After you have adjusted the configuration to suit your needs, save and close the file. Then restart Fail2Ban by running:
Test Fail2ban with SSH
Login attempts via SSH are recorded in the file /var/log/auth.log. If Fail2Ban detects repeated SSH login attempts from the same IP address, it will eventually—according to the settings you configured above—blacklist that IP address in the firewall.
You can test this by repeatedly trying to SSH into your server with incorrect credentials from another computer.
Then check Fail2Ban’s log file by running:
This will produce an output similar to this:
Here, Fail2Ban has logged three login attempts from the IP address 192.0.2.56, which it then blocked in the firewall.
You can verify that Fail2Ban has added the firewall rules by running:
You should now see something similar to this:
Fail2Ban has created a firewall rule that blacklists all inbound traffic from 192.0.2.56. If you have changed banaction = nftables-allports to banaction = nftables in the configuration file /etc/fail2ban/jail.local, only port 22 will be blocked instead.
Keep in mind that Fail2Ban is meant to work alongside other security measures on your server; it should not replace firewall rules.
Restart Fail2ban together with the firewall (optional)
If you restart the firewall with systemctl restart nftables, the blacklisted IP addresses will disappear. This happens because Fail2Ban is the component that adds the rules to the firewall, and the rules are not stored permanently in the firewall itself.
To work around this, add a dependency to the systemd service for Fail2Ban. This tells systemd that the nftables firewall and Fail2Ban are linked, so a restart of the firewall should also trigger a restart of Fail2Ban. Because Fail2Ban will be restarted after the firewall starts, the rules will be reapplied.
Run the following command:
The default editor—most likely nano—will now open. The file already contains many comments. Edit the file so that the first eleven lines look like the example below (the lines that start with ### are already present in the file):
Save the file and exit the editor.
Now you need to restart the systemd daemon so that the dependencies are updated. Do this with:
Now we can restart the firewall without the rules for the blacklisted IP addresses disappearing.
Summary
Fail2Ban is a good way to protect any service that uses authentication. You should now be better prepared to configure and use Fail2Ban to protect the specific services you run.
For more information about nftables, see Set up a firewall on Debian 11 using nftables.
Last updated
Was this helpful?