Hi Harri, At first you've confused me with the direction of the patch -- from a new file to old one, so I started to think that you suggest to remove -m state --state NEW :-)
This ideas seems viable indeed. But I am afraid that there might
be side effects and for that we need either just to give it a try or to
ask protocol experts and upstream author on what he thinks about it :-)
1. In a single connection session SSH via PAM allows to try multiple
passwords (by default it seems to be 3 or so). So if somebody
opportunistically decided to set maxfailures < 3, your version will have
no effect before the point when session is reestablished thus violating
user-requested behavior.
It might become even worse: Looking from ssh attack patterns: they
all follow each other very rapidly: I am not sure if they all separate
sessions or also mixed in the batches of 3 attempts... if in batches in
3, than doing simple math you can get 3*maxfailures attempts through the
fail2ban, which would be very undesired behavior.
2. I am even less sure how apache authentication is done - via separate
http connections or within one? If separate - good. If one -- then this
patch shouldn't be applied.
Please comment on and lets see what Cyril thinks about it and if
we decide to not include it in the released version, I think it is worth
mentioning in the README or smth.
Thank you Harri,
Cheers
Yarik
On Tue, Jan 31, 2006 at 04:22:11PM +0200, Harri Haataja wrote:
> Package: fail2ban
> Version: 0.6.0-3
> Severity: minor
> If two users access a host with fail2ban from the same originating ip,
> login failures from one of them will also lock the other one out.
> I've been using a small change in the rules that, I believe, will block
> only new connects instead of already established one. This way, at
> least, another users' already running ssh sessions will not be suddenly
> frozen by someone/something other tripping fail2ban. New connects will
> still be blocked from/to any source/user as the approach is based on ip
> address blocking.
> I changed the INPU rules in the config to say:
> @@ -134,13 +134,13 @@
> fwstart = iptables -N fail2ban-%(__name__)s
> iptables -A fail2ban-%(__name__)s -j RETURN
> - iptables -I INPUT -m state --state NEW -p %(protocol)s --dport
> %(port)s -j fail2ban-%(__name__)s
> + iptables -I INPUT -p %(protocol)s --dport %(port)s -j
> fail2ban-%(__name__)s
> # Option: fwend
> # Notes.: command executed once at the end of Fail2Ban
> # Values: CMD Default:
> -fwend = iptables -D INPUT -m state --state NEW -p %(protocol)s --dport
> %(port)s -j fail2ban-%(__name__)s
> +fwend = iptables -D INPUT -p %(protocol)s --dport %(port)s -j
> fail2ban-%(__name__)s
> iptables -F fail2ban-%(__name__)s
> iptables -X fail2ban-%(__name__)s
> -- System Information:
> Debian Release: testing/unstable
> APT prefers testing
> APT policy: (990, 'testing'), (900, 'stable'), (400, 'unstable'), (1,
> 'experimental')
> Architecture: i386 (i686)
> Shell: /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.10-1-686
> Locale: LANG=en_GB, [EMAIL PROTECTED] (charmap=ISO-8859-15)
> Versions of packages fail2ban depends on:
> ii iptables 1.3.3-2 Linux kernel 2.4+ iptables
> adminis
> ii python 2.3.5-5 An interactive high-level
> object-o
> fail2ban recommends no packages.
> -- no debconf information
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
pgpuSF10ytzZc.pgp
Description: PGP signature
