Fail2ban
Fail2ban scans various textual log files and bans IP that makes too many password failures by updating firewall rules to reject the IP address, similar to Sshguard.
Contents
Installation
If you want Fail2ban to send an email when someone has been banned, you have to configure SSMTP (for example).
systemd
Enable the fail2ban.service
unit.
Hardening
Currently, fail2ban must be run as root. Therefore, you may wish to consider hardening the process with systemd. Ref:systemd for Administrators, Part XII
Capabilities
For added security, consider limiting fail2ban capabilities by specifying CapabilityBoundingSet
in the drop-in configuration file for the provided fail2ban.service
:
/etc/systemd/system/fail2ban.service.d/capabilities.conf
[Service] CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_ADMIN CAP_NET_RAW
In the example above, CAP_DAC_READ_SEARCH
will allow fail2ban full read access, and CAP_NET_ADMIN
and CAP_NET_RAW
allow setting of firewall rules with iptables. Additional capabilities may be required, depending on your fail2ban configuration. See man capabilities
for more info.
Filesystem Access
Consider limiting file system read and write access by using ReadOnlyDirectories and ReadWriteDirectories, under the [Service]
section. For example:
ReadOnlyDirectories=/ ReadWriteDirectories=/var/run/fail2ban /var/lib/fail2ban /var/spool/postfix/maildrop /tmp /var/log/fail2ban
In the example above, this limits the file system to read-only, except for /var/run/fail2ban
for pid and socket files, and /var/spool/postfix/maildrop
for postfix sendmail. Again, this will be dependent on you system configuration and fail2ban configuration. The /tmp
directory is needed for some fail2ban actions. Note that adding /var/log/fail2ban
is necessary if you want fail2ban to log its activity. Make sure all the directories exist, or you will get error code 226 on starting the service.
Configuration
Default jails
Jails for many different services are already present in /etc/fail2ban/jail.conf
but not enabled by default. You can copy the section headers into a .local file of your choice, enable them (and optionally override settings).
Paths
There currently is no out-of-the-box support for archlinux, but the fedora defaults can make a decent starting point:
# cp /etc/fail2ban/paths-fedora.conf /etc/fail2ban/paths-archlinux.conf
To activate that configuration, add or alter the following section in the jail.local
file:
[INCLUDES] before = paths-archlinux.conf
Restart fail2ban.service
to test your configuration. Watch out for "file not found errors" from fail2ban-client if the fail2ban service fails to start. Adjust the paths paths-archlinux.conf
or jail.local
as needed. Many of the default jails might not work out of the box.
Custom SSH jail
Edit /etc/fail2ban/jail.d/jail.conf
, add this section and update the list of trusted IP addresses.
If your firewall is iptables:
[DEFAULT] bantime = 864000 ignoreip = 127.0.0.1/8 [sshd] enabled = true filter = sshd action = iptables[name=SSH, port=ssh, protocol=tcp] sendmail-whois[name=SSH, dest=your@mail.org, sender=fail2ban@mail.com] backend = systemd maxretry = 5
If your firewall is shorewall:
[DEFAULT] bantime = 864000 ignoreip = 127.0.0.1/8 [ssh-shorewall] enabled = true filter = sshd action = shorewall sendmail-whois[name=SSH, dest=your@mail.org, sender=fail2ban@mail.com] backend = systemd maxretry = 5
Also do not forget to add/change:
LogLevel VERBOSE
in your /etc/ssh/sshd_config
. Else, password failures are not logged correctly.