Fail2Ban: SSH Bruteforce Protection for VPS Owners

The problem:

If you own a VPS that is exposed to the internet then it is probably being scanned by botnets to determine if SSH is exposed and could be bruteforced. It doesn’t really matter what you do.

You’re probably thinking that absolutely no one will attempt to gain access to your server if you’re not using it for anything valuable. Well… you’re wrong. Even if the server is idling and doing nothing it is probably already discovered and having its ports scanned.

I found this out by chance while testing NixStats for an upcoming review. I installed their Logging agent and to my surprise, I see random IPs (predominantly from China) attempting to login through SSH with different usernames and incorrect passwords. The IPs were even attempting to use different ports instead of the typical port 22 to see if you changed it for added security.

At first, I was obviously concerned, but a quick Google search shows that this is incredibly typical and nothing out of the ordinary. Millions of machines that are compromised will be doing this to any public server. The rate at which these bruteforcing attacks happen is mind boggling. I was seeing at least 20 requests every single minute being dumped to my logs as they guess the incorrect password.

If you are using a non-dictionary attack vulnerable password, then you’re probably fine for a very long time. It would be very unlikely for any of these attempts to guess your password. However, if you’re using a weak password, or even a strong one that has been leaked before, you’re in trouble. Compromised VPSs are using for all sorts of nefarious behavior. You will probably end up sending large amounts of spam through your mailserver (compromised postfix) and end up getting your server IP blacklisted in a matter of hours. Delisting after such a compromise is a manual and time consuming process that you probably want to avoid.

You may also end up being part of DDOS attacks through a botnet, and could potentially land in hot water with your service provider if complains start coming in.

Let’s not let that happen…

Protecting yourself is actually a trivial process. Instead of having to worry about all the problems we already discussed, we can simply do the following:

• Change your root password to something strong. Capital letters, numbers, symbols, and a length of about 16 characters is very strong. Here is an example of a good password: ^o&TVz$9$kU!67pm (don’t use this one!)
• Install fail2ban, a module that will allow you to rate-limit and control these attacks.

The first step is straightforward, but fail2ban is probably your best line of defense here. Fail2ban allows you to block IPs performing these bruteforcing attacks for a set amount of time before unbanning them. The process is entirely automated and requires no additional input beyond the initial setup. You will be able to set failed attempts before bans, ban durations, etc…

I’m going to assume that you’re running Ubuntu on your VPS, which is most likely the case. So let’s get it done!

Step 1: Install Fail2Ban:

$ sudo apt-get update
$ sudo apt-get install fail2ban

You will be prompted to enter Y (or click enter) to approve the installation. You can review the required dependencies, size, and other details before you do so.

Step 2: Initial Setup:

We can perform the initial setup by navigating to /etc/fail2ban. Here, you will need to create a jail.local file. This is where we now define attempts, ban durations and so on. Input the following:

[DEFAULT]
bantime = ban duration in seconds (ex: 3600)
findtime = time period to count max attempts (ex: 360)
maxretry = maximum failed attempts before ban (ex: 5)
ignoreip = protect your own ip from getting locked out.

The default variables above will now apply to all of Fail2Ban’s jails. You can exclude the ignoreip setting, but you might get locked out accidentally for the duration of the ban time.

Now we get to enable the SSH jail and stop worrying about any bruteforce attacks! Add the following right after the previous code:

[ssh]
enabled = true

We’re done! Let us just restart fail2ban to apply our settings then we can sleep in peace:

$ sudo service fail2ban restart

The resulting logs show a much slower pace of failed logins as IPs get banned. This makes any bruteforcing basically impossible – notice the span of time before failed attempts:

Feel free to ask any question in the comment section below if you encounter any issues!