2006-11-11 00:10:10 +00:00
|
|
|
fail2ban (>=0.7.0) for Debian
|
|
|
|
-----------------------------
|
2005-07-06 23:10:26 +00:00
|
|
|
|
2006-11-11 00:10:10 +00:00
|
|
|
This package is ~99% identical to the upstream version. Few features
|
2006-03-19 05:27:42 +00:00
|
|
|
could have been added but not yet propagated into upstream version and
|
2006-11-11 00:10:10 +00:00
|
|
|
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
|
2005-07-06 23:10:26 +00:00
|
|
|
|
2006-02-10 18:08:01 +00:00
|
|
|
Currently, the major difference with upstream: python libraries are
|
2005-11-21 02:50:08 +00:00
|
|
|
placed under /usr/share/fail2ban instead of /usr/lib/fail2ban to
|
2005-07-23 19:15:22 +00:00
|
|
|
comply with policy regarding architecture independent resources.
|
|
|
|
|
2006-11-11 00:10:10 +00:00
|
|
|
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
|
2006-03-19 05:27:42 +00:00
|
|
|
|
2005-09-27 15:45:26 +00:00
|
|
|
|
2006-06-14 16:22:43 +00:00
|
|
|
* Enabled Sections:
|
|
|
|
|
2005-08-19 07:14:17 +00:00
|
|
|
Only handling of ssh files is enabled by default. If you want to use
|
|
|
|
fail2ban with apache, please enable apache section manually in
|
2006-11-11 00:10:10 +00:00
|
|
|
/etc/fail2ban/jail.local by including next lines:
|
|
|
|
|
|
|
|
[apache]
|
|
|
|
enabled = true
|
|
|
|
|
|
|
|
NOTE: -e command line parameter is non existant in 0.7.x
|
2005-08-19 07:14:17 +00:00
|
|
|
|
2006-02-10 18:08:01 +00:00
|
|
|
|
2006-12-07 04:07:59 +00:00
|
|
|
* Interpolations vs actions/filters parameters:
|
|
|
|
For details see #398739.
|
|
|
|
|
|
|
|
Summary: every pair of .conf and then .local (if exists) files read
|
|
|
|
separately from the others, so interpolations cannot penetrate from
|
|
|
|
(for instance) jail.* into actions.d/iptables.conf. To overcome this,
|
|
|
|
you are welcome to create/use any parameter which can be substituted
|
|
|
|
in actions/filters [Definition] section, whenever it is also defined
|
|
|
|
in the [Init] section of that file and used in place of necessary
|
|
|
|
placement as <parameter>. Parameters can be specified in the
|
|
|
|
definitions within jail.{conf,local}. For instance 1 lengthy example,
|
|
|
|
where fwchain is both used as interpolation (in jail.local) and
|
|
|
|
parameter (in iptables-flex.local).
|
|
|
|
|
|
|
|
==> /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.
|
2006-06-14 16:22:43 +00:00
|
|
|
|
|
|
|
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
|
2006-11-11 00:10:10 +00:00
|
|
|
don't have --dport %(port)s statement at all (can be redefined on per-section
|
2006-06-14 16:22:43 +00:00
|
|
|
basis as well)
|
2006-11-11 00:10:10 +00:00
|
|
|
Such option is not enabled by default since multiport module might not be
|
2006-06-14 16:22:43 +00:00
|
|
|
compiled for some hand compiled kernels.
|
2006-11-11 00:10:10 +00:00
|
|
|
|
|
|
|
|
|
|
|
* 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
|
|
|
|
|
|
|
|
|
2005-09-27 15:45:26 +00:00
|
|
|
Troubleshooting:
|
|
|
|
---------------
|
|
|
|
|
2006-02-10 18:08:01 +00:00
|
|
|
* Updated failregex:
|
2005-10-01 06:53:51 +00:00
|
|
|
|
|
|
|
To resolve the security bug #330827 [1] failregex expressions must
|
|
|
|
provide a named group (?P<host>...) as a placeholder of the abuser's
|
2006-12-07 04:07:59 +00:00
|
|
|
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.
|
2005-10-01 06:53:51 +00:00
|
|
|
|
|
|
|
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330827
|
|
|
|
|
2006-12-07 04:07:59 +00:00
|
|
|
You might benefit from using fail2ban-regex command shipped along to
|
|
|
|
construct and debug your failregex statements.
|
2006-02-10 18:08:01 +00:00
|
|
|
|
|
|
|
* "Interpolations" in the config file:
|
2006-01-15 20:18:39 +00:00
|
|
|
|
|
|
|
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
|
2006-12-07 04:07:59 +00:00
|
|
|
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.
|
2006-01-15 20:18:39 +00:00
|
|
|
|
2006-02-10 18:08:01 +00:00
|
|
|
|
|
|
|
* Mailing:
|
2005-09-27 15:45:26 +00:00
|
|
|
|
2006-12-07 04:07:59 +00:00
|
|
|
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}.
|
2005-07-06 23:10:26 +00:00
|
|
|
|
2006-02-10 18:08:01 +00:00
|
|
|
|
|
|
|
* Dirty exit:
|
2005-10-20 17:33:53 +00:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2006-02-10 18:08:01 +00:00
|
|
|
|
2006-03-03 21:14:34 +00:00
|
|
|
** SSHD Configuration Specific Problems
|
|
|
|
|
2006-02-10 18:08:01 +00:00
|
|
|
* 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
|
|
|
|
|
|
|
|
|
2006-03-03 21:14:34 +00:00
|
|
|
* 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.
|
|
|
|
|
|
|
|
|
2006-02-10 18:08:01 +00:00
|
|
|
* Bantime:
|
2005-11-21 02:50:08 +00:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2006-12-07 04:07:59 +00:00
|
|
|
|
|
|
|
* 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>, Wed, 6 Dec 2006 22:56:20 -0500
|