Fail2ban normally requires root privileges to insert iptables rules
through calls to /sbin/iptables and also to read the logfiles.
Fail2ban can run as an unprivileged user provided that those two
capabilities are preserved. The idea is to run fail2ban as a normal
user (e.g. fail2ban) who belongs to a group which is allowed to read
logfiles. The user should also be allowed to write to
/proc/net/xt_recent/fail2ban-<name> (name is specified in the iptables
rule).
/proc/net/xt_recent/* is created by the xt_recent kernel module when
an iptables rule with '-m limit' is inserted. This file contains a
dynamic list of IP addresses which can than be used in iptables rules.
Addresses can be matched against this list, with an optional timeout.
One way to use xt_recent is to insert IPs into this list from an
iptables rule, e.g. after connecting to the SSH port three times in a
minute. This is the standard usage described in iptables(3).
Another way to use xt_recent is by inserting the rules by writing to
/proc/net/xt_recent/fail2ban-<name>. This can be performed by a fail2ban
action. Files in /proc/net/xt_recent/ are protected by normal
filesystem rules, so can be chown'ed and chmod'ed to be writable by a
certain user. After the necessary iptables rules are inserted (which
requires root privileges), blacklisting can be performed by an
unprivileged user.
Using fail2ban with xt_recent allows smarter filtering than normal
iptables rules with the xt_recent module can provide.
The disadvantage is that fail2ban cannot perform the setup by itself,
which would require the privilege to call /sbin/iptables, and it must
be done through other means.
The primary advantage is obvious: it's generally better to run
services not as root. This setup is more robust, because xt_recent has
it's own memory management and should behave smartly in case a very
large amount of IPs is blocked. Also in case the fail2ban process dies
the rules expire automatically. In case of a large amount of blocked
IPs, traversing rules linearly for each SYN packet as fail2ban
normally inserts them will be slow, but xt_recent with the same number
of IPs would be much faster. (Didn't test this, so this is pure
handwaving, but it should really be this way ;)) From the
administrators point of view, a setup with xt_recent might also be
easier, because it's very simple to modify the permissions on
/proc/net/xt_recent/fail2ban-<name> to be readable or writable by
some user and thus allow delisting IPs by helper administrators
without the ability to mess up other iptables rules.
The xt_recent-echo jail can be used under the root user without
further configuration. To run not as root, further setup is necessary:
- Create user:
- set FAIL2BAN_USER in /etc/default/fail2ban.
This probably should be fail2ban.
- add user fail2ban who can read /var/log/auth.log and other
necessary log files. Log files are owned by group 'adm', so
it is enough if this user belongs to this group.
The user can be created e.g. with
useradd --system --no-create-home --home-dir / --groups adm fail2ban
- Statically initialize chains firewall:
- put a rule to check the xt_recent list in the static firewall initialization
script, with names like fail2ban-ssh (action uses separate chains per each
jail, so define here the ones you need 1-per-jail)
Sample invocation might be
iptables -I INPUT -m recent --update --seconds 3600 --name fail2ban-<name> -j DROP
with <name> suitably replaced.
- Permissions:
make sure that configuration files under /etc/fail2ban are readable by
fail2ban user. Make sure that logfiles of fail2ban itself are writable
by the fail2ban user. /etc/init.d/fail2ban will change the ownership at
startup, but it is also necessary to modify /etc/logrotate.d/fail2ban.
The simplest way is to replace '# create ...' with the following
# create 640 fail2ban adm
Generated by dwww version 1.15 on Thu Jun 27 22:48:04 CEST 2024.