Anyone who has ever spent any amount of time setting up and maintaining servers will understand how difficult it can be to stay on top of identifying and blocking malicious traffic. For example, it doesn’t take long for a server with SSH exposed to the Internet to start receiving attempted logins. If you have a complex password, then it’s unlikely someone will get in, but why allow them to try in the first place?
Using a tool like Fail2ban, you don’t have to worry as much about SSH password compromises or other types of brute-force break-ins. Fail2ban won’t stop malicious traffic from coming in, but it will help harden your defenses against it.
In this article, I explain why it’s useful to have Fail2ban deployed in your environment, and how we can go about using it to protect common web app services on a Linux-based server.
This article covers the following points:
What is Fail2ban, and how can it help you?
- Installing Fail2ban on a Debian-based OS
- Configuring Fail2ban to block malicious attempts on your server
- How does Fail2ban block malicious traffic?
What is Fail2ban and how can it help you?
Fail2ban is a type of intrusion prevention tool that can help protect servers from certain types of brute-force attacks. It does this by scanning log files of applications like the OpenSSH daemon, Apache, MySQL, mail logs (e.g., Dovecot, Postfix), etc. It looks at these log files and analyses where connection attempts are coming from, and looks at things like how many times a user attempts to log in, where they try to log in from, and how frequently they try. This tool is very helpful in stopping brute-force attacks on your server, as in the case where users repeatedly try to SSH into your server with different user and password combinations.
Installing Fail2ban on a Debian-based OS
For the purposes of this article, we’re going to assume that you’re using a Debian-based operating system such as Ubuntu or Debian itself. Installing Fail2ban is incredibly easy. You can do so by simply running apt-get install -y fail2ban—There are some defaults in place that offer immediate protection for services like SSH, but you’ll probably want to add protection for other services or change certain thresholds that are set, such as how many attempts will be allowed before a blocking event occurs, and whether or not you want to send out email alerts for such events.
Configuring Fail2ban to block malicious attempts on your server
Now that we’ve got Fail2ban set up, we’ll want to configure it to monitor the services that are important to us. We’ll also explain in this section how the thresholds work and how we can adjust the amount of time an IP address is banned.
First, we’ll want to find where all the configuration is stored. In this case it can be found under /etc/fail2ban where you’ll find various files and directories. The ones we’re most interested in are as follows:
filter.d (directory) jail.d (directory) jail.conf (Default jail file. Use only for reference and do not edit!)
You are able to add your own configuration (conf) files under jail.d which will be parsed by Fail2ban. You can see the default jails within the ‘jail.conf’ file, of which a few (including SSH) are enabled. So let’s have a look at the SSH jail as an example of how it works:
[ssh] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 6
In the above snippet, the options are pretty self-explanatory. We’re enabling the jail, specifying the port it will take action on (default SSH port = 22), the filter to use for searching and matching, the path to the log file it will monitor, and finally, the maximum number of login retries before action is taken.
If you wish to go a step further, you can take a look in /etc/fail2ban/filter.d/sshd.conf to see the filter used to identify malicious login attempts. This can be useful if you need to write a filter of your own—although, in my version of Fail2ban on this version of Debian, there are currently 57 filters ready to be used, which cover lots of common applications so hopefully you won’t need to write anything yourself!
If you couldn’t already tell, the SSH jail is enabled by default, so if this is the only service you want to monitor, then you don’t have to worry about doing anything else!
Finally, if you wish to change the amount of time an IP address is banned, then this is another setting you can set in jail.conf. Simply set (in seconds) the amount of time an IP should be blocked by adding bantime =
How does Fail2ban block malicious traffic?
So at this point, you might be asking how Fail2ban goes about blocking IP addresses after identifying malicious attempts in your log files. Well, this is where the action files come in. If you look in /etc/fail2ban/action.d you’ll see a number of files. One of the files used frequently within jails is the iptables action. In the iptables.conf file, you’ll see how it achieves a ban of an IP or unban, for example. A ban as a result of something picked up by the SSH jail will look like the following when running an iptables -nL.
Chain fail2ban-ssh (1 references) Target prot opt source destination REJECT all -- 172.20.5.2. 0.0.0.0/0 reject-with icmp-p Ort-unreachable RETURN all -- 0.0.0.0/0 0.0.0.0/0
Resources
So there you have it! I’m including some resources below which you may find useful!
- Fail2ban website: https://www.fail2ban.org/wiki/index.php/Main_Page
- Switching from denyhosts to Fail2ban: https://www.chrissearle.org/2015/06/16/replacing-denyhosts-with-fail2ban-for-debian/
