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).
Contents
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'.