Fail2ban

Quoting the Fail2ban wiki:

Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs – too many password failures, seeking for exploits, etc. Generally Fail2Ban is then used to update firewall rules to reject the IP addresses for a specified amount of time, although any arbitrary other action (e.g. sending an email) could also be configured. Out of the box Fail2Ban comes with filters for various services (apache, courier, ssh, etc).

Installation with xbps

$ xbps-install -S fail2ban

The Void Linux fail2ban package provides you with the essentials to get going, but it takes a bit of configuring to start using it effectively. Before starting with fail2ban, though, you should have a basic firewall configured.

This guide also assumes that you have installed the socklog and socklog-void packages, along with enabling the socklog service.

Configuration

We will now configure fail2ban to monitor SSH on our system. Fail2ban has a lot of configuration options available. As a result, it is recommended that you do not edit the packaged configuration files, in /etc/fail2ban/ directly. Instead, fail2ban supports duplicate files that end with .local. Fail2ban first loads its .conf files and then any present .local files. Any setting in a .local file overrides what was set in the .conf file. So all of our modifications will be in .local files.

Please take the time to read any corresponding .conf files as you read the remainder of this section. Settings will not be explained in detail as that is already done within the .conf files.

/etc/fail2ban/fail2ban.local

This file is used to configure the basic settings of the fail2ban server. It defines how fail2ban will log its own messages, where it will store its operating data, and where it will listen for fail2ban client command messages. So let's define these settings as they pertain to a Void Linux system:

[Definition]
loglevel = INFO
logtarget = STDOUT

/etc/fail2ban/jail.local

Fail2ban uses filters and actions to do its work. These filters and actions are enabled through the jail configuration file. Since we want to monitor SSH, we will enable that monitoring in our jail.local file:

[DEFAULT]
# The default section defines options for all subsequent sections
# unless explicitly overridden within a section
ignoreip = 127.0.0.1
bantime = 3600
findtime = 600
maxretry = 5

[sshd]
enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/socklog/secure/current

Create Missing Bits

At the time of this writing, the fail2ban package leaves out a couple of important bits: the /var/{lib,run}/fail2ban directories. So we need to create them ourselves:

$ mkdir /var/{lib,run}/fail2ban

But it also doesn't ship with a service for loading the configuration into the server once it is started. So we need to create a new service:

$ mkdir /etc/sv/fail2ban-client
$ cat << EOF > /etc/sv/fail2ban-client/run
#!/bin/sh
exec 2&>1
[ ! -d /var/run/fail2ban] && mkdir /var/run/fail2ban
sv start fail2ban || exit 1
fail2ban-client reload
exec pause
EOF
$ chmod +x /etc/sv/fail2ban-client/run

Run It

You should now have a fully configured fail2ban that will monitor your SSH logs and insert REJECT rules into your firewall when it detects an abuse. So all that is left to do is to enable the services:

$ ln -s /etc/sv/fail2ban /var/service/
$ ln -s /etc/sv/fail2ban-client /var/service/

Finally, you can check the status of the SSH jail:

$ fail2ban-client status sshd

Different Fail Match Lines

It's possible that the above will leave you with a functioning server, but no fail rules matching. So you might need to add a new sshd.local in the filter.d directory. For example, let's assume you have disabled password authentication; then the format of log lines you'll see don't match the bundled configuration. So add the following file:

File: /etc/fail2ban/filter.d/sshd.local

[INCLUDES]
before = common.conf

[Definition]
_daemon = sshd

failregex = sshd.*Did not receive identification string from <HOST>\s*$
            sshd.*Received disconnect from <HOST>.*preauth.*\s*$
            sshd.*Disconnected from <HOST>.*preauth.*\s*$
            sshd.*Invalid user (\w+) from <HOST>\s*$

ignoreregex =

[Init]
# "maxlines" is number of log lines to buffer for multi-line regex searches
maxlines = 10

And then restart the service:

$ sv restart fail2ban-client

If these rules aren't sufficient, or you need to write rules for a different service, use the fail2ban-regex tool to develop new ones. Note that you don't need to match the timestamp. Fail2ban has pre-defined match rules for the timestamp. Your rules should start matching after the timestamp written by the service.

For example, given the log line:

2015-12-03T23:12:20.33907 authpriv.info: Dec  3 18:12:20 sshd[6538]: Invalid user echo from 10.10.10.10

You would ignore '2015-12-03T23:12:20.33907 authpriv.info: Dec 3 18:12:20 ' and start matching at 'sshd'.