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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
