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.