The Power of One fail2ban Rule

If you run any sort of server in the cloud, I can (unofficially) guarantee you there is someone out there trying to get in it. They are easy targets. Companies are still migrating to the cloud. There are tons of people that still don't know how to use the cloud. Taking even a step back, there are tons of people that don't know how to secure a computer; heck I am sure I could do a better job in a lot of cases.

So How Do I Know?

Login and review the logs; see what you can find if you don't believe me. If you don't have any sort of logging enabled (in this case access logs) you might one to start enabling those!

Run the command:

more /var/log/access.log

This will start you at the top of your log file and allow you to work your way down with the space bar. You will probably get my point real quick.

I am sure you will be something similar to this below.

The access logs, your logs will have a local IP address. (I redacted mine.)

Setup

First install fail2ban. We are using ubuntu and are just going to pull the apt package.

sudo apt-get install fail2ban

We have to make two configuration changes. We are going to have to make a filter - which is essentially a regex that triggers - as well as a jail. A jail is the rule that triggers an action. Basically, if a jail calls a filter, baddies get punished.

Insert this for the filter, the location is commented in the code block.

# /etc/fail2ban/filter.d/sshd-invaliduser.conf
[Definition]
failregex = ^.*sshd.*: Invalid user .* from  port .*$
ignoreregex =

Create the jail and add the following.

# /etc/fail2ban/jail.d/jail.local
[sshd-invaliduser]
enabled = true
filter = sshd-invaliduser
action = iptables[name=SSHD, port=ssh, protocol=tcp]
logpath = /var/log/auth.log
maxretry = 1 
bantime = 2592000

Now simply restart the service.

sudo systemctl restart fail2ban

Check the status of the jail

sudo fail2ban-client status sshd-invaliduser

There you have it, you can capture all those prisoners!

Wait, What Did We Just Do?

In short, we ban an IP address from contacting a port using a protocol based on a filter. The filter is looking for an invalid user.

Looking at the filter, it is a regular expression. Compare it to the logs you have found. The key things we are trying to filter on are the process name (sshd), the term "Invalid User" as well as the host. The host is the IP address that gets "jailed". You may have figured it out, but, yes, we are banning anyone that enters an invalid user.

OK, Question, Why?

It is common for bad actors to just try common usernames and see what sticks. This is also followed by default passwords. Therefore, think twice when you delay changing your default password. Make sure it's the first thing you do. I would also suggest you use a custom user - especially they if are an admin account - followed by disabling the default one.

The Jail

The filters are generally self explanatory, but, here is a breakdown:

[sshd-invaliduser] - The name
enabled = true - If it is enabled
filter = sshd-invaliduser - The associated filter (the other thing)
action = iptables[name=SSHD, port=ssh, protocol=tcp] - What happens when we hit the criteria (the punishment)
logpath = /var/log/auth.log - What is log is being monitored
maxretry = 1 - How many times it can triggered
bantime = 2592000 - The ban time in seconds - yes, this is a month.

What Can Go Wrong?

Yes, you can ban yourself. So don't do something silly. IE. This is a helpful practice when you have a scripted login using a private key. This might not be the best option if you are manually typing your login every time. So, two things, automate it securely and have a backup plan.

Some Interesting Findings!

There are two really interesting findings from the result of this.

The volume of unique IPs with incorrect users is interesting. I am sure there is spoofing and bots, etc., even considering within the first four days of having this configured 76 IP addresses have been punished for a month.
Some of the incorrect users banned have some logic to them. An example is, the user "seanland" has been attempted. This makes me think the bad actors are either using the domain as a blind attempt, or are adding logic to their attack; potential using generative AI in some form.

What Else Can I Do?

Well, basically anything you want. This is a simple starting point. Here are some other ideas to help lockdown your servers and services:

Look at specific application logs, filter on specific end points you don't want targeted. An example, filter a log for 404s and block popular calls (For the pages that actually don't exist. Like maybe your site doesn't have admin.php, but, people keep trying to access it.)
Go deeper into ssh attempts, limit erroneous logins on the user you use!
Get notified on specific bans! Maybe there are scenarios you want to be notified of? Login? # of failed attempts etc.
Constantly monitor your logs and look for new rules that you can create.

fail2ban is a very powerful tool, where the possibilities are nearly endless. The learning curve also is not too steep. I hope this was helpful!

Happy Jailin'!