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


* 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. The naming of the group was introduced to capture possible
future generalizations of failregex to provide even more
information. At a current point, all named groups are considered as
possible locations of the host addresses, but usually you should need
just a single group (?P<host>...)

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

You might benefit from using fail2ban-regex 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, so they could be eventually
included in the fail2ban package for general use by the rest of the
community.


* Mailing:

As it was reported (bug #329722) you might need to provide a full
e-mail address in fail2ban.conf option MAIL:from to make your mail
server accept that email. I've added @localhost to both MAIL:from and
MAIL:to in the default configuration shipped with Debian. It seems to
work nicely now

See TODO.Debian for more details, as well as the Debian Bug Tracking
system.


* 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.

 -- Yaroslav O. Halchenko <debian@onerussian.com>, Fri, 10 Nov 2006 18:19:48 -0500