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 => 2
Whiteboard: 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_update
CC: (none) => sysadmin-bugs

Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0372

Status: ASSIGNED => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED

Patch checked into Mageia 1 SVN.