We're an ISO27001:2013 Certified Supplier


Although attacks on the modern Internet are increasingly sophisticated, for bad actors sometimes the simplest compromises are the easiest. One of those is known as a user enumeration attack, and it works when the bad actor has unlimited access to try to log in to your service. It’s often followed by a dictionary attack on passwords of discovered users.

Take, for example, the Secure Shell (SSH) service which will be running on almost any remote server. If you check log files regularly, you might find lines like these in there:

sshd[17273]: Invalid user ellen from
sshd[17277]: Invalid user emil from
sshd[17280]: Invalid user enzo from
sshd[17285]: Invalid user felix from
sshd[17289]: Invalid user fred from

These entries reveal that someone at the remote address has been attempting to log in with a dictionary of common names. Given enough time, they may well stumble upon a user with a weak password and be able to log in.

Ideally, access to the SSH port would be restricted by IP address to only to those people who need access. However, that’s not always possible or practical; genuine users may need to travel, or have dynamic addresses.

Selective Blocking

If the server has a local firewall – for example, using the iptables framework – one option is to detect an enumeration in progress and block it. The fail2ban utility, available in most distribution package repositories, can automate this task by following the server’s log file and taking the action you configure.

On a Debian system, fail2ban  places its configuration in /etc/fail2ban . The main file, jail.conf by default includes the following block to enable SSH protection:

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

Once the fail2ban service is started, this configuration will cause it to follow the /var/log/auth.log log file and watch for failed logins. On the sixth consecutive failure from the same IP address, the iptables ruleset will be updated to block connections from that address for a short time – by default, around ten minutes.

fail2ban logs its actions to /var/log/fail2ban.log – here it is in action:

11:02:11,540 fail2ban.actions[1869]: WARNING [ssh] Ban
11:12:12,210 fail2ban.actions[1869]: WARNING [ssh] Unban

Of course, not all servers use iptables  rulesets directly. fail2ban can also manipulate them through the Shorewall abstraction tool, which allows complex configurations and fail2ban to live happily together.

Additional Services

SSH is not the only service which can be attacked in this way. fail2ban is usually shipped with a variety of other filters, which it uses to parse the log files being watched. A suitable filter for the Dovecot IMAP service may be included and its jail may look like this:

enabled = false
port    = smtp,ssmtp,submission,imap2,imap3,imaps,pop3,pop3s
filter  = dovecot
logpath = /var/log/mail.log

The additional ports in this configuration are all restricted when a ban is activated, so attackers concentrating on one protocol actually get blocked from all them. The filter directive tells fail2ban how to match lines in /var/log/mail.log, which are very different to those in /var/log/auth.log. This configuration can be activated simply by setting enabled = true, so enabling additional services is trivial.

Photo by Kaur Kristjan on Unsplash

Leave a Reply

Your email address will not be published. Required fields are marked *

Get free Linux business strategies

Fill in this form and we'll send you updated Linux business strategies and ideas each week
  • This field is for validation purposes and should be left unchanged.