fail2ban/debian

fail2ban (>=0.7.0) for Debian
-----------------------------

This package is ~99% identical to the upstream version. Few features
could have been added but not yet propagated into upstream version and
some modifications might be Debian-specific. Debian specific jail.conf
file is shipped. Original upstream file is available from
/usr/share/doc/fail2ban/examples/jail.conf

Currently, the major difference with upstream: python libraries are
placed under /usr/share/fail2ban instead of /usr/lib/fail2ban to
comply with policy regarding architecture independent resources.

Upgrade from 0.6 versions:
-------------------------

* New Config Files Format:

If you had introduced your own sections in /etc/fail2ban.conf, you
would need manually to convert them into a new format. At minimum you
need to create /etc/fail2ban/filter.d/NAME.local (leave .conf files
for me and upstream please to avoid any conflicts -- introduce your
changes in .local) with failregex in [Definition] section. And provide
appropriate jail definition in /etc/fail2ban/jail.local


* Enabled Sections:

Only handling of ssh files is enabled by default. If you want to use
fail2ban with apache, please enable apache section manually in
/etc/fail2ban/jail.local by including next lines:

[apache]
enabled = true

NOTE: -e command line parameter is non existant in 0.7.x


* Interpolations vs actions/filters parameters:

For details see #398739 or wait for a closure of #400416

Every pair of .conf and then .local (if exists) files is read
separately from any other configuration file, so interpolations cannot
penetrate from jail.* into actions.d/*. To overcome this, it is
necessary to create a PARAMETER which can be substituted in actions
[Definition] section, if it is also defined in the [Init] section of
that file and is used in place of necessary allocation as <PARAMETER>
tag. Parameters can be specified in the definitions within
jail.{conf,local}. For instance, 1 lengthy example, where the same
name "fwchain" is used both as interpolation (in jail.local) and as a
parameter (in iptables-flex.local) (from #398739)

==> /etc/fail2ban/jail.local <==
[DEFAULT]
action = iptables-flex[name=%(__name__)s, port=%(port)s, fwchain=%(fwchain)s, post_start_commands=%(post_start_commands)s, pre_end_commands=%(pre_end_commands)s]
fwchain = INPUT
[ssh]
fwchain = ssh-tarpit
==> /etc/fail2ban/action.d/iptables-flex.local <==
[Definition]
actionstart = iptables -N fail2ban-<name>
               iptables -I <fwchain> -m state --state NEW -p <protocol> --dport <port> -j fail2ban-<name>
               iptables -I <fwchain> -j <whitelist>
actionstop  = iptables -D <fwchain> -j <whitelist>
               iptables -D <fwchain> -m state --state NEW -p <protocol> --dport <port> -j fail2ban-<name>
               iptables -F fail2ban-<name>
               iptables -X fail2ban-<name>
actioncheck = iptables -L <fwchain> | grep -q fail2ban-<name>
actionban   = iptables -I fail2ban-<name> 1 -s <ip> -j DROP
actionunban = iptables -D fail2ban-<name> -s <ip> -j DROP
[Init]
whitelist = ssh-whitelist
fwchain = INPUT
name = default
port = ssh
protocol = tcp


* Multiport banning: Comment for the wishlist #373592.

Default iptables rules for banning use --dport statement which allows to
ban just a single port. For multiport banning you would need to adjust iptables
rules to use multiport module ( -m multiport --dports %(port)s ). If you would
like to ban all ports for that host, just redefine fwban/fwunban commands to
don't have --dport %(port)s statement at all (can be redefined on per-section
basis as well)
Such option is not enabled by default since multiport module might not be
compiled for some hand compiled kernels.


* Blocking of NEW connections only
Comment for the wishlist #350746.

It might be benefitial in some cases to ban only new connections. For
that just use iptables-new action instead of default iptables:
/etc/fail2ban/jail.local:

[DEFAULT]
action = iptables-new[name=%(__name__)s, port=%(port)s]

or override action within interesting for you section


Troubleshooting:
---------------

* Updated failregex:

To resolve the security bug #330827 [1] failregex expressions must
provide a named group (?P<host>...) as a placeholder of the abuser's
host. Alternative tag (since 0.7.5) can be "<HOST>". The naming of the
group was introduced to capture possible future generalizations of
failregex to provide even more information.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330827

You might benefit from using fail2ban-regex command shipped along to
construct and debug your failregex statements.

* "Interpolations" in the config file:

Since version 0.6.0-3 to reduce duplication, thus to improve
readability of the config file, interpolations provided by the module
ConfigParser are used. If you had custom sections defined before, you
might benefit from updating config file and adding appropriate
information for the new sections.

N.B. If you have some nice additional sections defined, I would really
appreciate if you share them with me or upstream author, so they could
be eventually included in the fail2ban package for general use by the
rest of the community.


* Mailing:

Since actions.d/mail*.conf commands rely on presence of "mail"
command, mailx package (or another package providing mailx
functionality such as mailutils) is required if those actions are
activated in jail.{conf,local}.


* Dirty exit:

If firewall rules gets cleaned out before fail2ban exits (like was
happening with firestarter), errors get reported during the exit of
fail2ban, but they are "safe" and can be ignored.


** SSHD Configuration Specific Problems

* Ban "Not allowed" attempts:

Make sure that you have
ChallengeResponseAuthentication no
PasswordAuthentication yes

Details from the bug report #350980 [2]

[2]  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=350980


* Not caught attempts to login as root

On the boxes running older versions of openssh (e.g. sarge
distribution) in the case when PermitRootLogin is set to something
else than "yes" and iff AllowUsers is active, failed root logins do
not confirm to the standard logging message -- they omit the source
IP, thus allowing attack to persist since such messages are not caught
by fail2ban.


* Bantime:

An IP is banned for "bantime" not since the last failed login attempt
from the IP, but rather since the moment when failed login was
detected by fail2ban. Thus, if fail2ban gets [re]started, any IP which
had enough of failed logins within "findtime" will be banned for
"bantime" since [re]start moment, not since the last failed login
time.


* Syslog entries can be 'forged' by a regular user

From
http://fail2ban.sourceforge.net/wiki/index.php/FAQ_english#What_do_I_have_to_consider_when_using_Fail2ban

Especially on systems wich provide ssh/CGI/PHP services to unknown
users it is possible to block other users from ssh and probably other
access as a unprivileged user may issue:

logger -p auth.warning -t 'sshd[123]' 'Illegal user user1 from 1.2.3.4'

N.B. chmod o-x /usr/bin/logger should provide at least obfuscation
solution

Or the malicious user may write via PHP's openlog()/syslog() to syslog.

P.S. Anyone is welcome to recommend proper security solution to this
issue, such as an alternative to sysklogd which allows better control
over users logging to specific facilities (such as AUTH)

 -- Yaroslav O. Halchenko <debian@onerussian.com>, Thu,  7 Dec 2006 18:09:36 -0500