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 2.6.22.19-vs2.2.0.7-grsec2.1.11-vs2.2.0.7 (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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
