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: Invalid user ellen from 220.127.116.11
sshd: Invalid user emil from 18.104.22.168
sshd: Invalid user enzo from 22.214.171.124
sshd: Invalid user felix from 126.96.36.199
sshd: Invalid user fred from 188.8.131.52
These entries reveal that someone at the remote address
184.108.40.206 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.
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
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: WARNING [ssh] Ban 220.127.116.11
11:12:12,210 fail2ban.actions: WARNING [ssh] Unban 18.104.22.168
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.
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.