mirror of https://github.com/fail2ban/fail2ban
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
86 lines
3.8 KiB
86 lines
3.8 KiB
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 |
|
|
|
|