Fail2Ban to the brute-force rescue

If you have any service accessable on the internet someone will try to bruteforce it. It's just that simple. While you cannot completle stop someone from trying a few username/password you can stop them from trying millions of times with Fail2Ban.


Most services you have will accept as many wrong username/password as you give it and probably log it to somewhere but continue to wait for the next attempt as nothing has happened. This simple property gives brute-force scripts an opportunity. You may not even think that a brute-force script has run on your service, but if it's accessible from the internet and it's on the default port there is a good chance that some automatically running internet scanner has already discovered it and run an attack on it. One of the most attractive target an automatic script can have is the SSH. It's quite common to forward it, by default it has no defense against brute-force and if a valid username password pair is obtained a hacker can pretty much have a complete control over the computer.

To see if an attempt has been already made on a Linux/Unix system you should check your /var/log/auth.log files (because of log rolling you may have files like auth.log.1, auth.log.2..., some might even be gzipped with .gz extension). If an attempt was made to access it you should see a lot of logs like:
Failed password for {User} from {IP} port 34047 ssh2
Where {User} is usually root (though they can try many different usernames, for example in my RPI there was attempts to log in with 5891 different usernames) and {IP} is the IP address where the attacker tried to log in.

Here are some defense to make sure these automatic scripts don't succeed.

  • Strong password, usually these scripts will try some dictionary attacks
  • If you don't need remote login hide services behind firewall, or only allow login from certain IP (ranges)
  • Port knocking
  • Non default ports (some are against the idea, but it's still effective against automatic scripts)
  • Limit login attempts (This is what this article is about)

Meet Fail2Ban

Fail2Ban is a little service utility program for Unix-like OS-es (Linux, FreeBSD, MacOSX) which can stop brute-force attacks (among other things). It works by scanning log files and matching a pattern against the text in the log. It will count how many instances of that log happened the past (you can give the time it should scan backward) and if a limit is exceeded it will do the action you want it to do (probably adding it to your firewall).
First thing first let's install it. You can use the Linux repositories to do this:
sudo apt-get install fail2ban
or you could go to the Fail2Ban website download the package and install it manually.
After installation a fail2ban service will be created under /etc/init.d. You can start it up by
sudo /etc/init.d/fail2ban start
And you can check if it indeed started by
sudo /etc/init.d/fail2ban status
if you don't see any errors it's ready to go. By default it should check only for SSH brute-force and ban any IP for 10 minutes that failed to log into SSH 3 times in the last 10 minutes.
Sometimes the log formats are different than the one coming with your Fail2Ban, so let's try it out to make sure it work: Fail 2 log into SSH 6 times fast and your 4th try will yield timeout, because you have been banned. If you check your log file at /var/log/fail2ban.log your should see something like that:
WARNING [ssh] Ban {your ip}

Some time later you will also see the Unban message appear.
If you get to here, awesome, your SSH is protected agains brute force.

Let's configure

Tonight's the night. And it's going to happen, again and again, we have to configure. Don't worry it's not that hard, first lets review the base concepts of Fail2Ban:

  • Filter: What should we consider a match (aka the fail message in a log file)
  • Action: What should happen (when someone do too many failed requests)
  • Jail: Put the filter and action together. Defines what is "too many" where are the log files to scan, etc...

Now here is your homework, check all 3 types of configuration files under /etc/fail2ban/ folder.

Go through an already existing configuration, the SSH. Start with the jail.conf file. At the top you will find a [DEFAULT] section, these are the globals, most is pretty well commented and self-explanotary, so I won't go into details about these, just read the comments in the config file. All of these can also be changed for each individual jails. Go down a bit to until you see

enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 6

First line is the name of the jail, I don't think there is any uses for these, so it can be pretty much anything. SSH seems to be the only filter enabled by default, the port can be numeric or the name of it, in this case the name of ssh (port 22) is used. The filter is the name (and filename) of the filter, in this case filter.d/sshd.conf.The file to monitor will be the auth.log file. The maxretry overrides the one defined in [DEFAULT] section. The action was defined in the [DEFAULT] section, and it's "iptables-multiport" with some parameters, which just means, add it to IPTables and block ports given in the jail setup file.
Now take a look at the filter.d/sshd.conf file. It will have really scary regular expressions. There are good tutorials about regexps on the interwebs, so I won't provide that, but there are few interesting things to note.

  1. <HOST> in the regexp is a mandatory parameter, and it should be the ip or the hostname of the request. This will be the one who gets banned.
  2. The timestamp is also mandatory in the log, but as far as I know currently there is no way to indicate where is the time in the log file or what format it is. It will automatically match to the datetime, you have to act like it's not in the log you are creating the regexp for.
  3. Multiple regexp can be written, one per line, if any matches the filter matches.
  4. "%(__prefix_line)s" comes from the common.conf, on my system it doesn't contain anything. You can add it, but if it works without it, it's more readable to leave it if you're creating a custom filter.

The final file is under the action. There are many actions by default, probably it has all the actions which you will ever need. I will leave it to you to explore these.

Article was created by helospark (2015-12-12 17:48:46)
Rate article: 0
Ask questions or share your opinion.
You need to login to comment.