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 147.135.192.203 sshd[17277]: Invalid user emil from 147.135.192.203 sshd[17280]: Invalid user enzo from 147.135.192.203 sshd[17285]: Invalid user felix from 147.135.192.203 sshd[17289]: Invalid user fred from 147.135.192.203
These entries reveal that someone at the remote address 147.135.192.203 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:
[ssh] 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 36.84.225.220 11:12:12,210 fail2ban.actions[1869]: WARNING [ssh] Unban 36.84.225.220
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:
[dovecot] 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