Server support blog

Most of the hosting servers nowadays are plagued by brute force attacks – too many computers running some or other botnet, too many “no brainer” scan tools are available for the interested.
There are always somebody who doesn’t bother to select good password to secure his account on the server and that could potentially bring a lot of problems not only to him but to the whole hosting company as well – imagine brute-forced password used for SMTP AUTH to send massive amounts of SPAM from the compromised server?
Now there is lot of countermeasures invented for that and here I will explain which one I prefer and why.

The obvious solution is right there – fail2ban – modular, stable, proven solution used by many hosting services. But pretty bulky – uses python as scripting language and gamin as external dependency for log file change notification.
I would recommend using fail2ban if you are experiencing targeted web site protected area brute force attacks but for casual brute force scanners that are trying to hit ssh and ftp services looking for easy targets it will be too heavy.
There is another much lighter and simpler tool – Brute Force detection. Advantages in a few words – no external dependencies; – lightweight modular shell script; pre-installed rules for major SMTP/POP/IMAP/FTP/SSH servers included. You can check included README for more details from author. First line of defense in other words.
After downloading from original site and unpacking the installation procedure is simple and straightforward, handled by installation script included. By default bfd installs under /usr/local/bfd.
Note 1:
Default action is to block offenders IP using another tool from the same author – Advanced Policy Firewall (apf) – packet filtering firewall script tool. Personally, I am against using packet filtering firewalls on high traffic web servers for such trivial matter as blocking occasional brute force attack (that might easily cost you 5-15% of overall performance depending on many factors), so I decided to use ip route blocking instead. Below is my diff to the original conf.bfd file

Personally I do not enable e-mail alerts – the sheer number of “drive-by” brute force attacks can flood your mailbox real quick.
Note 2:
Initially IPs blocked by bfd will stay blocked until the next reboot. If this is not what you have in mind the command below will clear all blocked IPs from the routing table. Or alternatively keep track of offenders IPs to have them blocked forever.
You can put this command into /etc/cron.{daily,weekly,monthly}./bfd_unblock shell script to clear routing table periodically.

This solution is the part of the “first line of defense” I use on the hosting servers to keep parasite traffic and resource use at bay.