Fail2Ban – A Secured Site’s Best Friend
If you run a linux site that is exposed to the internet, check the /var/log/auth.log or /var/log/secure log files. Chances are you’ll see a bunch of ‘ Failed password for user ‘ attacks on your site.
The ‘user’ most likely will either be ‘root’ or a ton of random names. The latter are most likely a form of a dictionary attack that someone is trying to run on your server, to gain access.
A majority of our ‘attacks’ seem to come from Indian and Chinese based sites, but you’ll most likely see them coming from everywhere across the globe.
Question now is what to do. You could try and block all of the IP’s using iptables and/or entire subnets, but you will eventually end up playing a good game of ‘wack o mole’. You will never block every attacker on the globe by hand, but by automatically blocking the computers that attack you, you can significantly reduce your risk.
I would highly recommend you take a look at Fail2Ban. Its a great tool, written in Python, that has the ability to automatically look for bad-people in any log file, and block them within the server’s firewall, for a certain amount of time. Out of the box, the solution supports a ton of services to check and enable. It is also flexible enough to monitor your custom web applications. Installation and configuration is outside the scope of this article, but we would be more than happy to help you set it up for you.
My Tips For Configuration
1.) The more the threat on a service: the longer timeout and the shorter the “maxretry” number should be. So for instance, on SSHD, I have it set with 3 for the “maxretry” and 86400 seconds for the bantime (24 hours). So basically, if a bad person tries to login 3 times unsuccessfully, they are banned for 24 hours till they can access the site again.
2.) Always, always, always set the “ignoreip” variable to be your known IP addresses. So if you are configuring the site remotely, make sure you add your public address to jail.local file immediately, before configuring Fail2ban (you’ll regret it if you dont!).
3.) Always test EVERY rule that you install. The “fail2ban-regex” tool is a great addition to the package so that you can double check that your rule is matching correctly and consistently
fail2ban-regex /var/log/secure /etc/fail2ban/filter.d/sshd-stech.conf
4.) I created my own custom filter for SSHD. I’ve added the line below to ensure matching on SSHD connection attempts that are most likely coming from telnet. The attacker is trying to see what version of SSH you are using to see if they can exploit it. They are instantly blocked.
^%(__prefix_line)sDid not receive identification .* from
5.) Always use network security common sense: strong passwords, regularly changes, enable only the services that you need, running regular user account audits, run external network penetration tests, etc. If you are unsure or need help, be sure to contact a professional to help you assess your overall risk.