remote unauthenticated attackers can add arbitrary hosts to the block list of systems using fail2ban. using something like $ ssh "foo from 123.123.123.123"@localhost As they point out in their faq, local users can also block arbitrary hosts.
tavis, has upstream been notified and is there a fix available?
Hi Tavis and Matthias, I'm the author of Fail2ban and a Gentoo user too ;) For 0.6.x, the Debian package contains a fix for this. The problem is that it will break user configuration. I decided not to add this patch for this reason. For 0.7.x, no releases are normally affected by this issue. If they are, then it is "only" a configuration issue. Concerning the local exploit, it is not really an issue in Fail2ban. It is not possible to know if the log came from a real daemon or a malicious user. A solution would be to change the permissions on /dev/log.
A solution would be to stabilize the 0.7.2 ebuild and then remove the 0.6.x
I'm with C
I'm with Cédric.
Arches please test and mark stable. Target keywords are: fail2ban-0.7.2.ebuild:KEYWORDS="amd64 hppa x86"
And now actually with arches CC'ed:-)
Looks like fail2ban-0.7.2 can't be succesfully restarted: root@daria /home/ticho # /etc/init.d/fail2ban restart * Starting fail2ban ... [ ok ] root@daria /home/ticho # /etc/init.d/fail2ban restart * Stopping fail2ban ... [ ok ] * Starting fail2ban ... * Failed to start fail2ban [ !! ] root@daria /home/ticho # /etc/init.d/fail2ban restart * Starting fail2ban ... [ ok ] root@daria /home/ticho # /etc/init.d/fail2ban restart * Stopping fail2ban ... [ ok ] * Starting fail2ban ... * Failed to start fail2ban [ !! ] root@daria /home/ticho #
Tried manually: root@daria /home/ticho # fail2ban-client start WARNING No 'maxtime' defined in 'postfix-tcpwrapper' WARNING No 'maxtime' defined in 'ssh-iptables-report' WARNING No 'maxtime' defined in 'ssh-tcpwrapper' WARNING No 'maxtime' defined in 'vsftpd-notification' WARNING No 'maxtime' defined in 'ssh-iptables' 2006-12-10 10:46:25,969 fail2ban.server : INFO Starting Fail2ban root@daria /home/ticho # echo $? 0 root@daria /home/ticho # fail2ban-client stop Shutdown successful root@daria /home/ticho # echo $? 0 root@daria /home/ticho # fail2ban-client start WARNING No 'maxtime' defined in 'postfix-tcpwrapper' WARNING No 'maxtime' defined in 'ssh-iptables-report' WARNING No 'maxtime' defined in 'ssh-tcpwrapper' WARNING No 'maxtime' defined in 'vsftpd-notification' WARNING No 'maxtime' defined in 'ssh-iptables' ERROR Could not start server. Try -x option root@daria /home/ticho # 2006-12-10 10:46:38,763 fail2ban.server : INFO Starting Fail2ban root@daria /home/ticho # echo $? 255 root@daria /home/ticho # The error above was printed immediately, the command returned to shell, and after a moment, the "INFO Starting Fail2ban" message appeared. The "fail2ban-client start" command returned 255, though. This might be worth looking into.
Back to ebuild status awaiting a fixed ebuild.
OK, I have tried 0.7.5, which behaves the same on restart via initscript. I removed "&> /dev/null" parts from both start() and stop(), and here's what I found out: root@daria /usr/gentoo/portage/net-analyzer/fail2ban # /etc/init.d/fail2ban restart * Starting fail2ban ... 2006-12-10 11:13:55,314 fail2ban.server : INFO Starting Fail2ban [ ok ] root@daria /usr/gentoo/portage/net-analyzer/fail2ban # /etc/init.d/fail2ban restart * Stopping fail2ban ... Shutdown successful [ ok ] * Starting fail2ban ... ERROR Server already running * Failed to start fail2ban [ !! ] root@daria /usr/gentoo/portage/net-analyzer/fail2ban # Looks like "fail2ban-client stop" is returning too soon, when the server is still running. This is confirmed by manually stopping and starting fail2ban quickly: root@daria /usr/gentoo/portage/net-analyzer/fail2ban # fail2ban-client stop && fail2ban-client start Shutdown successful ERROR Server already running root@daria /usr/gentoo/portage/net-analyzer/fail2ban #
Hi all, Sorry I should have added myself to CC :( I have just released 0.6.2 which fixes the issue. Old configuration files will still work but will generate a warning. A named group "host" is now required. This group should match the host address in the log line. Please look at the provided configuration files. The init script problem has been reported by RedHat users too. Restart need to wait a bit that server shutdowns. I will look into this as soon as possible. I consider odd version numbers (0.3, 0.5, 0.7) as development releases. Even number (0.4, 0.6, upcoming 0.8) are stable releases. Please, if possible, only stabilize these releases. I will always try to do my best to provide fixes for security issues for these "stable" releases.
0.6.2 (renamed 0.6.1-r1 ebuild) seems to work. As this is a security bug, I took the liberty of committing 0.6.2 to the tree, with x86 keyword stable. I hope netmon won't mind. :) Security, cue archteams! :)
Thx Andrej, however the 0.6.x series is only safe with the Debian patch according to comment #2.
(In reply to comment #13) > Thx Andrej, however the 0.6.x series is only safe with the Debian patch > according to comment #2. > In comment #11, Cyril says that 0.6.2 has this issue fixed, so I went from there. I can not reproduce the vulnerability with 0.6.2, which bans correct IP, instead of bogus one, as in 0.6.0.
Woops sorry Andrej. Arches please test and mark stable. Target keywords are: fail2ban-0.6.2.ebuild:KEYWORDS="amd64 hppa ~ppc ~ppc64 x86"
Stable for HPPA.
Sorry, this is not really the good place to talk about this but as this was reveal in this bug, I post it here. I (hopefully) fixed the init script for the "restart" issue. Inspired by the squid init script. https://svn.sourceforge.net/svnroot/fail2ban/trunk/files/gentoo-initd Could you test it? Is this the right way to do this? Any suggestions? Thank you
(In reply to comment #11) > Hi all, > > Sorry I should have added myself to CC :( > > I have just released 0.6.2 which fixes the issue. Old configuration files will > still work but will generate a warning. A named group "host" is now required. > This group should match the host address in the log line. Please look at the > provided configuration files. > > The init script problem has been reported by RedHat users too. Restart need to > wait a bit that server shutdowns. I will look into this as soon as possible. > > I consider odd version numbers (0.3, 0.5, 0.7) as development releases. Even > number (0.4, 0.6, upcoming 0.8) are stable releases. Please, if possible, only > stabilize these releases. I will always try to do my best to provide fixes for > security issues for these "stable" releases. > Hallo, I have emerged the latest in portage fail2ban (0.6.2) with its original configuration file. However, I cannot find the relevant information that has to do with the following error message: WARNING: No 'host' group defined. This is a security issue. Please fix your configuration file and look at CVE-2006-6302 I do not clearly understand the way that I can cure this error message. From what it is said in this thread I cannot figure out what is the "host address in the log line" that should be matched by the defined 'host' group and how this group can actually be defined. I expected to find some information in the configuration files that I did not manage to spot successfully. Kind regards, orange_juice
amd64 stable
time to glsa-vote. We issued a GLSA for denyhosts, so i would say Yes here.
i'm actually the only active member of the security team, so i can't apply the policy telling that 2 positive votes include a GLSA. Let's have one btw :)
GLSA 200702-05
I have the same problem. Also have no clue what does it mean by host group and how to cure this message.
@Fox, please open a new bug instead if the problem persists.
