Package: fail2ban
Version: 0.8.4-3
Severity: wishlist
Tags: patch
Fail2ban currently requires root priviledges to insert iptables rules through
calls to /sbin/iptables and also to read the logfiles. Fail2ban can run as an
unpriviledged user provided that those two capabilites 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-whatever (the name of the file depends on the
iptables rules used to create it).
[/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
wrting to /proc/net/xt_recent/whatever. 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.]
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 priviledge 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. Generally 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-whatever
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 setup is simple:
- add a user fail2ban who can read /var/log/auth.log and other
necessary log files
E.g. for rsyslog (in /etc/rsyslog.conf):
$FileGroup logread
$FileCreateMode 0640
- put a rule to check the xt_recent list in the static firewall
initialization script, with a name like fail2ban-ssh
from /etc/iptables/rules:
:INPUT - [0:0]
...
-A INPUT -m recent --name fail2ban-ssh --update --second 86400 -j DROP
...
The rules to drop packets are pretty much the same as in
normal fail2ban setup... I like to add
... -m limit -j LOG --log-prefix "filtered: " --limit 3/minute
to know that packets are being dropped, but this off topic.
Action file is provided as attachment.
In summary, I think that this setup would be a useful option for fail2ban
users. It requires manual setup, differently than normal fail2ban actions,
but I think that the advantages are worth it.
-- System Information:
Debian Release: 5.0.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.20-1-486
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
# Fail2Ban configuration file
#
# Author: Cyril Jaquier
# Modified: Yaroslav O. Halchenko <[email protected]>
# made active on all ports from original iptables.conf
#
# $Revision: 658 $
#
[Definition]
# Option: actionstart
# Notes.: command executed once at the start of Fail2Ban.
# Values: CMD
#
actionstart =
# Option: actionstop
# Notes.: command executed once at the end of Fail2Ban
# Values: CMD
#
actionstop = echo / > /proc/net/xt_recent/fail2ban-<name>
# Option: actioncheck
# Notes.: command executed once before each actionban command
# Values: CMD
#
actioncheck = test -e /proc/net/xt_recent/fail2ban-<name>
# Option: actionban
# Notes.: command executed when banning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: <ip> IP address
# <failures> number of failures
# <time> unix timestamp of the ban time
# Values: CMD
#
actionban = echo +<ip> > /proc/net/xt_recent/fail2ban-<name>
# Option: actionunban
# Notes.: command executed when unbanning an IP. Take care that the
# command is executed with Fail2Ban user rights.
# Tags: <ip> IP address
# <failures> number of failures
# <time> unix timestamp of the ban time
# Values: CMD
#
actionunban = echo -<ip> > /proc/net/xt_recent/fail2ban-<name>
[Init]
# Defaut name of the chain
#
name = default
# Option: protocol
# Notes.: internally used by config reader for interpolations.
# Values: [ tcp | udp | icmp | all ] Default: tcp
#
protocol = tcp
