[email protected]
[Top] [All Lists]

Bug#515599: marked as forwarded (fail2ban inconveniences when using own

Subject: Bug#515599: marked as forwarded fail2ban inconveniences when using own iptables rules
From: Debian Bug Tracking System
Date: Thu, 10 Sep 2009 13:42:11 +0000
Your message dated Thu, 10 Sep 2009 09:29:12 -0400
with message-id <[email protected]>
has caused the   report #515599,
regarding fail2ban inconveniences when using own iptables rules
to be marked as having been forwarded to the upstream software
author(s) Cyril Jaquier <[email protected]>, Arturo 'Buanzo' Busleiman 
<[email protected]>

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]

515599: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515599
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Subject: Re: Bug#515599: fail2ban: Use custom "hook chains"
From: Yaroslav Halchenko
Date: Thu, 10 Sep 2009 09:29:12 -0400
> the approach taken by the Vuurmuur firewall. It creates a new chain
> called PRE-VRMR-INPUT, which is called unconditionally from the INPUT
> chain, before Vuurmuur's own rules.
Since you spoke to upstream already -- there is no sense to keep
conversation Debian-specific ;) I am forwarding the bugreport upstream
and will follow up on the website (apparently I was nobody for sf at
that point ;))

But besides providing such level of control over where to insert the
hooks in the tables, I don't think that much else should be done since
it gets very firewall specific -- that is why actually using just INPUT
chain was imho most generic solution (in my case I just use shorewall
firewall and shorewall action ;))

BTW, Cyril and Buanzo, what about adopting 'Debian''s jail.conf ;) and
there is a bit of other patches to absorb upstream... unfortunately git
repository is somewhat a madhouse atm... I will prep those for you later
(or should I may be just commit? ;))

> Package: fail2ban
> Version: 0.8.3-2sid1
> Followup-For: Bug #515599

> Hi,

> it seems your idea of providing hooks for fail2ban is sensible, though
> the extra magic grep involved in finding the hook is fragile.

> I would propose using a custom chain instead of a dummy rule, which is
> the approach taken by the Vuurmuur firewall. It creates a new chain
> called PRE-VRMR-INPUT, which is called unconditionally from the INPUT
> chain, before Vuurmuur's own rules. The contents of this chain are never
> touched by Vuurmuur, so if fail2ban would add its rules to that chain
> instead of INPUT, everything would be fine for Vuurmuur.

> In fact, it does not seem unreasonable for other firewalls to provide
> similar "hook chains", perhaps they even do so already. If you need even
> more control (say, for calling a whitelist before fail2ban), you could
> arrange this in vuurmuur by inserting a CHAIN rule (which just calls
> another chain, say the chain FAIL2BAN) and point fail2ban to the called
> chain.

> This does require some configuration of fail2ban to find the right
> chain, but I don't think there can be any other general solution to this
> problem (without making all firewalls aware of fail2ban, which isn't
> very pretty). To make this work, fail2ban should add a "chain"
> configuration variable, which simply defaults to "INPUT". This has the
> advantage of still working out-of-the-box when there is no other
> firewall involved, and if there is, there is only a small configuration
> change needed.

> I've submitted a feature request for this upstream [1], though halfway
> through writing it I found out that this configuration wouldn't be
> terribly convenient with upstream's default configuration. It would work
> just fine with Debian's, since that adds some indirection using action_
> to configure the action for all jails at the same time.

> Note that this still requires the firewall to start before fail2ban (to
> create the hook chains). Alternatively, we could make the iptables
> actions create the chain if it does not exist yet (and if the
> firewall scripts show the same tolerance, nothing will break). I think
> this will even solve both problems and not require fail2ban to start
> after the firewall anymore (though fail2ban will not do anything until
> the firewall is also loaded).

> I've implemented this partly (only for iptables-multiport.conf) at [2], but it
> should be trivial to extend.

> Does this make sense?

> Matthijs

> [1]: 
> https://sourceforge.net/tracker/?func=detail&aid=2855908&group_id=121032&atid=689047
> [2]: 
> http://git.stderr.nl/gitweb?p=servers.git;a=commitdiff;h=2f8315532658e5ad1acea72b357a5dc4878a4a93;hp=a31720f9f2b8f7e92d5e265bbe728e2756a7b7f6

> -- System Information:
> Debian Release: 5.0.2
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: i386 (i686)

> Kernel: Linux (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash

> Versions of packages fail2ban depends on:
> ii  lsb-base                      3.2-20     Linux Standard Base 3.2 init 
> scrip
> ii  python                        2.5.2-3    An interactive high-level 
> object-o
> ii  python-central                0.6.8      register and build utility for 
> Pyt

> Versions of packages fail2ban recommends:
> ii  iptables                      1.4.2-6    administration tools for packet 
> fi
> ii  whois                         4.7.30     an intelligent whois client

> Versions of packages fail2ban suggests:
> ii  bsd-mailx [mailx]  8.1.2-0.20071201cvs-3 A simple mail user agent
> pn  python-gamin       <none>                (no description available)

> -- no debconf information

=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     ([email protected]|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                   Linux User    ^^-^^    [175555]

--- End Message ---
<Prev in Thread] Current Thread [Next in Thread>
  • Bug#515599: marked as forwarded (fail2ban inconveniences when using own iptables rules), Debian Bug Tracking System <=