@ -36,8 +36,47 @@ enabled = true
NOTE: -e command line parameter is non existant in 0.7.x
* Multiport banning:
Comment for the wishlist #373592.
* 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.
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
@ -69,16 +108,14 @@ Troubleshooting:
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>...)
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 to construct and debug
your failregex statements.
You might benefit from using fail2ban-regex command shipped along to
construct and debug your failregex statements.
* "Interpolations" in the config file:
@ -89,21 +126,17 @@ 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.
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:
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.
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:
@ -145,4 +178,25 @@ 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
* 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
Yaroslav Halchenko
18 years ago