Your message dated Tue, 31 Jan 2006 10:38:06 -0500
with message-id <[EMAIL PROTECTED]>
has caused the Debian Bug report #350746,
regarding fail2ban: Only block new connects
to be marked as having been forwarded to the upstream software
author(s) Harri Haataja <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL
PROTECTED]
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
---------------------------------------
Received: (at 350746-forwarded) by bugs.debian.org; 31 Jan 2006 15:38:48 +0000
>From [EMAIL PROTECTED] Tue Jan 31 07:38:48 2006
Return-path: <[EMAIL PROTECTED]>
Received: from washoe.rutgers.edu ([165.230.95.67])
by spohr.debian.org with esmtp (Exim 4.50)
id 1F3xai-00012a-Cv; Tue, 31 Jan 2006 07:38:48 -0800
Received: from yoh by washoe.rutgers.edu with local (Exim 4.54)
id 1F3xa2-00039c-Bm; Tue, 31 Jan 2006 10:38:06 -0500
Date: Tue, 31 Jan 2006 10:38:06 -0500
From: Yaroslav Halchenko <[EMAIL PROTECTED]>
To: Harri Haataja <[EMAIL PROTECTED]>, [EMAIL PROTECTED],
[EMAIL PROTECTED]
Cc: Cyril Jaquier <[EMAIL PROTECTED]>
Subject: Re: Bug#350746: fail2ban: Only block new connects
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j"
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
X-URL: http://www.onerussian.com
X-Image-Url: http://www.onerussian.com/img/yoh.png
X-PGP-Key: http://www.onerussian.com/gpg-yoh.asc
X-fingerprint: 3BB6 E124 0643 A615 6F00 6854 8D11 4563 75C0 24C8
User-Agent: mutt-ng/devel-r556 (Debian)
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER
autolearn=no version=2.60-bugs.debian.org_2005_01_02
--nFreZHaLTZJo0R7j
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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 :-)=20
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.=20
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 =3D 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 =3D iptables -D INPUT -m state --state NEW -p %(protocol)s --dport=
%(port)s -j fail2ban-%(__name__)s
> +fwend =3D 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=3Den_GB, [EMAIL PROTECTED] (charmap=3DISO-8859-15)
> Versions of packages fail2ban depends on:
> ii iptables 1.3.3-2 Linux kernel 2.4+ iptables a=
dminis
> ii python 2.3.5-5 An interactive high-level ob=
ject-o
> fail2ban recommends no packages.
> -- no debconf information
--=20
.-.
=3D------------------------------ /v\ ----------------------------=3D
Keep in touch // \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
--nFreZHaLTZJo0R7j
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFD34RdjRFFY3XAJMgRAnIQAJ0eSbF488H8zEJKwLY9pPof7bec4wCfZeub
7E4IU7GSwVr1YHc6rP+qDlc=
=DP9D
-----END PGP SIGNATURE-----
--nFreZHaLTZJo0R7j--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
