Fedora has issued an advisory on December 19: http://lists.fedoraproject.org/pipermail/package-announce/2012-December/095127.html The issue is fixed upstream in 0.8.8. Mageia 2 is also affected. The upstream commit to fix it is linked in the RedHat bug: https://bugzilla.redhat.com/show_bug.cgi?id=887914
CC: (none) => remcoWhiteboard: (none) => MGA2TOO
Assignee: bugsquad => remco
Status: NEW => ASSIGNED
Thanks for the report David. For Mageia 2, an updated package is available in updates_testing, fail2ban-0.8.6-3.mga2 . @qa, can you please test? Unfortunately I have no real testing procedure. The only change is in the file server/action.py and the changed code is seen at https://github.com/fail2ban/fail2ban/commit/83109bc which is the upstream change addressing this issue. If you can confirm the updated package includes this change and fail2ban still runs, that would seem sufficient to me. I'll submit an updated package to Cauldron shortly.
Assignee: remco => qa-bugs
Thanks Remco! Advisory: ======================== Updated fail2ban package fixes security vulnerability: fail2ban before 0.8.8 didn't escape the content of <matches> (if used in custom action files), which could cause issues on the system running fail2ban as it scans log files, depending on what content is matched, since that content could contain arbitrary symbols. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5642 http://lists.fedoraproject.org/pipermail/package-announce/2012-December/095127.html ======================== Updated packages in core/updates_testing: ======================== fail2ban-0.8.6-3.mga2 from fail2ban-0.8.6-3.mga2.src.rpm
Version: Cauldron => 2Whiteboard: MGA2TOO => (none)
Editted /etc/fail2ban/jail.conf and commented out the ignoreip line then enabled the proftpd stanza and restarted fail2ban. I created failed ftp login attempts from another computer and could see the Ban line in syslog, with a strange process id. <U+FEFF>fail2ban.actions: WARNING [proftpd-iptables] Ban 192.168.1.16 It doesn't actually stop the connections though, the ftp client continues with failed connections/logins. Is further configuration necessary Remco or is this a problem?
Claire, You need to define an action to drop the IP in shorewall. Something like this. /etc/fail2ban/jail.conf [proftpd-shorewall] enabled = false filter = proftpd action = shorewall sendmail-whois[name=ProFTPD, dest=you@mail.com] logpath = /var/log/proftpd/proftpd.log maxretry = 6
CC: (none) => derekjenn
Correction enabled = true
It currently has this.. [proftpd-iptables] enabled = true filter = proftpd action = iptables[name=ProFTPD, port=ftp, protocol=tcp] sendmail-whois[name=ProFTPD, dest=you@example.com] logpath = /var/log/proftpd/proftpd.log maxretry = 6 and there is a iptables.conf in action.d directory but it only refers to sshd
Yes. Out of the box fail2ban assumes the firewall is iptables. In a standard Mageia configuration we use shorewall so we need to define a new 'jail' in /etc/fail2ban/jail.conf to define a proftp server with a shorewall firewall. The proftpd-iptables jail should be disabled. Each jail consists of a filter (proftpd) and one or more actions. If the action is shorewall then the action /etc/fail2ban/action.d/shorewall.conf is called to ban and unban the IP. I use fail2ban on one of my other live servers (and very good it is too) I am currently testing fail2ban-0.8.6-3.mga2 on a different server, but so far I cannot get the ban action to work either even though I am using the config files from my working server. It is too soon to say there is a problem with this release. I am still looking into it.
Remco, it seems the default config is not applicable for Mageia. Is this something you'd like to remedy now or shall we create a new bug for it?
I have spent some time trying to validate fail2ban-0.8.6-3.mga2 and cannot get it to perform any action to ban an IP. I have tried with two jails enabled [ssh] enabled = true filter = sshd action = shorewall sendmail-whois[name=SSH, dest=derek@dereks.email, sender=derek@dereks.email] logpath = /var/log/auth.log maxretry = 3 [apache-shorewall] enabled = true filter = apache-auth action = shorewall sendmail[name=Postfix, dest=derek@dereks.email, sender=derek@dereks.email] logpath = /var/log/httpd/error_log Test procedure for ssh was to perform ssh login from another computer to a non existent account. Test procedure for apache was to give the wrong password to a password protected web page. In both cases the fail2ban server would indicate that it had correctly detected the attacks and the debug log would show the IP had been banned, but no action actually takes place, and no confirmation email is sent. The status indicator shows fail2ban thinks it has banned the IP # fail2ban-client -v status apache-shorewall INFO Using socket file /var/run/fail2ban/fail2ban.sock Status for the jail: apache-shorewall |- filter | |- File list: /var/log/httpd/error_log | |- Currently failed: 1 | `- Total failed: 8 `- action |- Currently banned: 1 | `- IP list: 192.168.1.33 `- Total banned: 1 To ensure it was not an issue with shorewall I also tried with the hostsdeny action and that did not work either. I then downgraded to fail2ban-0.8.6-2.mga2.noarch and retested and was able to successfully ban IPs with shorewall for both jails.
@MrsB: This update is intended to only fix the security issue David reported. The Mageia package currently does not divert from the default fail2ban configuration. As shorewall is not installed on every Mageia installation by default (it is an option I believe at install time), and given that shorewall and I don't see eye to eye I don't feel comfortable changing that at this time, though I'm willing to consider it for the future. @MrsB/Derek: I have just tested on a virtualbox with iptables with both the old package and the updated one, and it works for me in both cases. Perhaps when either of you has time, we can walk through this on IRC and see where it goes wrong?
I have done more testing In all cases I tested the ssh jail using shorewall as the action fail2ban-0.8.6-2.mga2 on a maga2 physical server - works OK fail2ban-0.8.6-3.mga2 on a mga2 physical server - does not work fail2ban-0.8.8-1.mga3 on a mga3 virtualbox - works OK fail2ban-0.8.6-2.mga2 on a mga3 virtualbox - works OK fail2ban-0.8.6-3.mga2 on a mga3 virtualbox - does not work My conclusion is that fail2ban-0.8.6-3.mga2 has a problem with performing actions. I notice that the patch is on a file called server/action.py When failing the sendmail action does not work either, and the IP never becomes unbanned. Claire - With regard to the configuration files. fail2ban always requires manual configuration. It is not possible to have it work "out of the box" since email addresses have to be set and the services to be monitored have to be enabled. However I think we could help users get it up and running quicker if we did things like :- * Configure the provided jails with the correct log paths for mageia e.g. mail and apache logs * Provide more jail examples for a typical mageia install ready to be enabled. Shorewall is the default firewall in Mageia so it would be useful if we had some more jails using shorewall defined. In any case changing the config files ought to be the subject of another bug report.
OK I think I have found the problem. We need to implement this commit https://github.com/fail2ban/fail2ban/commit/09355663f7a3c0409e08efdebf98b1bbf47d1d9c I have tried it out by patching fail2ban-0.8.6-3.mga2 locally and it worked.
(In reply to comment #11) > Claire - With regard to the configuration files. fail2ban always requires > manual configuration. It is not possible to have it work "out of the box" since > email addresses have to be set and the services to be monitored have to be > enabled. Of course Derek, that was not what I said. If, as you said in comment 4 this should be configured to use shorewall rather than iptables then the current default iptables configuration is incorrect. Your further testing seems to suggest this has nothing to do with shorewall but rather the patch is the cause of fail2ban failing to actually ban (comment 3), in which case the current iptables configuration should then work once enabled. If it doesn't then we need to create a bug for the misconfiguration.
@Derek, thanks for the further investigation. I've amended the patch accordingly and have now built fail2ban-0.8.6-3.1.mga2 . Hoping this one works better for you all!
Confirming fail2ban-0.8.6-3.1.mga2 works great (noarch so no need to test both architectures) Validated fail2ban-0.8.6-3.1.mga2.src.rpm on mga2 Advisory: ======================== Updated fail2ban package fixes security vulnerability: fail2ban before 0.8.8 didn't escape the content of <matches> (if used in custom action files), which could cause issues on the system running fail2ban as it scans log files, depending on what content is matched, since that content could contain arbitrary symbols. References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5642 http://lists.fedoraproject.org/pipermail/package-announce/2012-December/095127.html ======================== sysadmin please push fail2ban-0.8.6-3.1.mga2.src.rpm to mga2 core/uodates
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Update pushed: https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0372
Status: ASSIGNED => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
Patch checked into Mageia 1 SVN.