Networking

Use Fail2ban to blacklist IP addresses and alert you to attacks

Vincent Danen takes you through some basic configuration of the Fail2ban network monitoring utility, which can help protect your systems and servers from brute-force attacks.

One indication of whether anyone is taking undue interest in a system is to keep an eye on failed login attempts. Of course, depending on what services you're running, and how much time you can devote to the task, this is easier said than done.

The problem is not only what files to watch, but how often you can watch them. Certain log analysis programs can give you a report of the previous day, such as logwatch, but by this time it could be too late. Reactive reports don't help stop attempts, they just alert you of historical data.

One program that can help is Fail2ban, which monitors log files every second. If there are too many authentication failures, it can alert you via email so you have instant notification of what is going on, as it happens. But that isn't all that Fail2ban can do -- it can also modify firewall rules to block any subsequent access to the system from the attacking IP address. This makes Fail2ban a very interesting utility as, while it makes a good reporting system, it makes a much better proactive protection system. Fail2ban accomplishes this by adding iptables rules, shorewall rules, or tcp_wrappers rules, and these can differ per service.

Unlike some tools, Fail2ban works for more than just SSH: it can monitor logs for failed login attempts in Apache, Postfix, vsftpd, and more. In fact, Fail2ban allows you to write custom regular expressions so you can create filters for any other service you may be writing. Filters have been written to block attackers of WordPress blogs and other web applications as well.

Most Linux distributions provide Fail2ban, so it is usually an apt-get or yum command away. Once it is installed, the various configuration files are typically located in /etc/fail2ban/.

The primary configuration file is the jail.conf file. This is where you define the configurations for different services. There are different contexts here; the "[DEFAULT]" context applies to all services:

[DEFAULT]
ignoreip = 127.0.0.1
bantime  = 600
findtime  = 600
maxretry = 3
backend = auto

The ignoreip entry tells Fail2ban which IP addresses to ignore for failed login attempts. The default is for the localhost, and other IPs can be added here, each one separated by a space. The maxretry entry tells Fail2ban how many failures must be made by a host before it gets banned, and the bantime entry tells Fail2ban for how long to ban the host, in seconds (so 600 would be ten minutes).

After this, you can define per-service jails. The following is the SSH entry, which manipulates iptables rules to ban a host:

[ssh-iptables]
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
           sendmail-whois[name=SSH, dest=root, sender=fail2ban@mail.com]
logpath  = /var/log/secure
maxretry = 5

Here, this jail specification tells Fail2ban to use the sshd filter (more on that below). The iptables action is used, specifying the name ("SSH"), the port to deny access to ("ssh", or port 22), and what protocol to block on ("TCP"). It also specifies a second action, which tells Fail2ban to send an email to root noting that the IP has been blocked. Finally, this tells Fail2ban to watch the /var/log/secure file for authentication failures, and overrides the default of three failed attempts with five.

The filter is specified in /etc/fail2ban/filter.d/sshd.conf (which is what the "filter" keyword is pointing to). This file contains the regular expressions used to determine if a login has failed. Typically, you will not need to change anything here, but if you wish to add other regular expressions to this filter, you can do so by creating a file named /etc/fail2ban/filter.d/sshd.local and including them there.

Every .conf file that Fail2ban has can have a .local counterpart; the .local counterpart will override anything specified in the .conf file. This is to allow you to customize the configuration files and not worry about your changes being replaced when new versions of Fail2ban are installed. This guarantees that any custom configuration you specify will persist across upgrades.

Finally, the actions noted in the jail configurations are handled by configuration files in /etc/fail2ban/action.d/, so in our example above, the two action files being referenced would be /etc/fail2ban/action.d/iptables.conf and /etc/fail2ban/action.d/sendmail-whois.conf. This is where you can tweak the emails that get sent (by creating a sendmail-whois.local file, perhaps) and examine what iptables commands are being called. Here you can also see different action types; for instance the ipfw action would be used for operating systems such as OS X and FreeBSD, or the shorewall action if you use Shorewall to manage your firewall. Here is also where you would create any other custom actions, such as perhaps logging to an additional text file or database.

Fail2ban is a highly versatile tool to help prevent brute-force attacks as they occur. Rather than alerting an administrator after the damage may already be done, Fail2ban can alert immediately and take proactive steps in denying access to the host by the attacking IP address. It is quite straightforward to configure and very easy to install. If you are looking for a solution to help protect your systems and servers from unwanted attacks, Fail2ban is definitely worth looking into.

Get the PDF version of this tip here.

About

Vincent Danen works on the Red Hat Security Response Team and lives in Canada. He has been writing about and developing on Linux for over 10 years and is a veteran Mac user.

7 comments
Gis Bun
Gis Bun

You can ban all the IP addresses you want because hackers will never use just one IP address to try and get in.

jwright
jwright

We've been using fail2ban for about 3 years, it has been great at reducing unwanted traffic. One thing we did see early on was that some bots would only try to log in the default fail2ban error count -1, then wait awhile and try again. When we saw this in the logs, we made changes. Also changed bantime to forever. If you ban yourself, you have to log in from another address to fix it, (small price to pay to keep the morons out).

gracedman
gracedman

Thank you, Vincent. This looks like a helpful product and I was not very familiar with anything more than the name before this article. We've been using OSSEC as a tool which offers many other features and seems to include this feature. Would you care to comment on how the two compare and where one would use one over the other? Thanks - John

K12Linux
K12Linux

It stops a ton of script-kiddie attacks. At the very least it would slow down a targeted attack by someone with lots of compromised PCs under their control. Say someone had 10,000 IPs at their disposal for a targeted brute-force attack. With the default fail2ban settings they could attempt about 40 million logins per week without triggering a ban/notice. Yeah, that sounds really bad. While you don't really want that going on, we're still talking about an attack rate that would take (on average) 49 years to break an 8 character password made up of only upper-case letters. Honestly though, if you are being attacked in a coordinated way by someone with tens of thousands of IPs at their disposal, you'd better already be taking many other precautions in addition to fail2ban.

vdanen
vdanen

I'd love to comment, but I can't, unfortunately. I've never looked at OSSEC before, so I'm not sure what it does. Perhaps I can take a look at it here in the next little while and write something up about it, including a brief comparison to fail2ban.

Gis Bun
Gis Bun

If you have 10,000 IPs aimed at you, you have to ban 10,000 IPs. Not everyone "keeps" their IP [static]. So banning a non-static IP could cause problems as well.