fail2ban doesn't handle leap years

[Robin Sheat]

Binary package hint: fail2ban

Today is the 29th of February. restartd tells me fail2ban is failing to start. The log says:

2008-02-29 16:10:00,988 ERROR: Fail2Ban got an unhandled exception and died.
2008-02-29 16:10:00,989 ERROR: Type: 'ValueError'
Value: ('day is out of range for month',)
TB: [('/usr/bin/fail2ban', 47, '?', 'fail2ban.main()'), ('/usr/share/fail2ban/fail2ban.py', 519, 'main', 'e = element[1].getFailures()'), ('/usr/share/fail2ban/logreader/logreader.py', 143, 'getFailures', 'for element in self.findFailure(line):'), ('/usr/share/fail2ban/logreader/logreader.py', 174, 'findFailure', 'date = self.getUnixTime(timeMatch.group())'), ('/usr/share/fail2ban/logreader/logreader.py', 213, 'getUnixTime', 'date = list(time.strptime(value, self.timepattern))'), ('/usr/lib/python2.4/_strptime.py', 425, 'strptime', 'julian = datetime_date(year, month, day).toordinal() - \\')]

and isn't actually starting the process.

This is in dapper, and not something I think will come up a whole lot, but perhaps should be fixed upstream if it isn't already as it does have some security implications.

[Yaroslav Halchenko (yarikoptic)]

see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468382
apply patch provided and please verify that it works after...

On Fri, 29 Feb 2008, Eythian wrote:

> Public bug reported:

> Binary package hint: fail2ban

> Today is the 29th of February. restartd tells me fail2ban is failing to
> start. The log says:

> 2008-02-29 16:10:00,988 ERROR: Fail2Ban got an unhandled exception and died.
> 2008-02-29 16:10:00,989 ERROR: Type: 'ValueError'
> Value: ('day is out of range for month',)
> TB: [('/usr/bin/fail2ban', 47, '?', 'fail2ban.main()'), ('/usr/share/fail2ban/fail2ban.py', 519, 'main', 'e = element[1].getFailures()'), ('/usr/share/fail2ban/logreader/logreader.py', 143, 'getFailures', 'for element in self.findFailure(line):'), ('/usr/share/fail2ban/logreader/logreader.py', 174, 'findFailure', 'date = self.getUnixTime(timeMatch.group())'), ('/usr/share/fail2ban/logreader/logreader.py', 213, 'getUnixTime', 'date = list(time.strptime(value, self.timepattern))'), ('/usr/lib/python2.4/_strptime.py', 425, 'strptime', 'julian = datetime_date(year, month, day).toordinal() - \\')]

> and isn't actually starting the process.

> This is in dapper, and not something I think will come up a whole lot,
> but perhaps should be fixed upstream if it isn't already as it does have
> some security implications.

> ** Affects: fail2ban (Ubuntu)
> Importance: Undecided
> Status: New
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: [phone]x263 | FWD: 82823 | Fax: [phone]
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik

[Robin Sheat (eythian)]

On Friday 29 February 2008 16:29:05 Yaroslav Halchenko wrote:
> see
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468382
> apply patch provided and please verify that it works after...
That patch won't apply because it's for a significantly different version of
fail2ban than the one in dapper, and the file it's patching doesn't exist. On
the flip side, the one in dapper doesn't take 100% CPU, it just doesn't work.

[Yaroslav Halchenko (yarikoptic)]

o boy... for that one:
dapper (net): bans IPs that cause multiple authentication errors
[universe]
0.6.0-3: all

you better install some backport from sid/lenny. 0.6 is heavily insecure and
imho no sense to have this issue fixed there

On Fri, 29 Feb 2008, Eythian wrote:

> On Friday 29 February 2008 16:29:05 Yaroslav Halchenko wrote:
> > see
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468382
> > apply patch provided and please verify that it works after...
> That patch won't apply because it's for a significantly different version of
> fail2ban than the one in dapper, and the file it's patching doesn't exist. On
> the flip side, the one in dapper doesn't take 100% CPU, it just doesn't work.
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: [phone]x263 | FWD: 82823 | Fax: [phone]
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik

[Robin Sheat (eythian)]

On Friday 29 February 2008 17:40:44 Yaroslav Halchenko wrote:
> you better install some backport from sid/lenny. 0.6 is heavily insecure
> and imho no sense to have this issue fixed there
Fair enough, although I might wait for tomorrow given the debian one has worse
issues. However, if the dapper one has real security issues shouldn't it be
updated there at some stage, given it's still supported for servers, where
this kind of thing matters?

[Yaroslav Halchenko (yarikoptic)]

> Fair enough, although I might wait for tomorrow given the debian one has worse
> issues.
what worse issues? let me know -- I will have it fixed ;-)

> However, if the dapper one has real security issues shouldn't it be
> updated there at some stage, given it's still supported for servers, where
> this kind of thing matters?
gy gy -- ask Canonical about that... just teasing ;-) or may be MOTUs?

--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: [phone]x263 | FWD: 82823 | Fax: [phone]
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik

[Robin Sheat (eythian)]

On Fri, 29 Feb 2008, Yaroslav Halchenko wrote:
> what worse issues? let me know -- I will have it fixed ;-)
The debian one uses 100% CPU, the Dapper one simply doesn't start.

> gy gy -- ask Canonical about that... just teasing ;-) or may be MOTUs?
True, although if it's a security issue, surely it should be pushed through?

[Launchpad Janitor (janitor)]

This bug was fixed in the package fail2ban - 0.8.1-3ubuntu1

---------------
fail2ban (0.8.1-3ubuntu1) hardy; urgency=low

  * Added 11_fix_leap_year.dpatch to fix leap year issues. (LP: #196854)

 -- Chuck Short <email address hidden> Fri, 29 Feb 2008 16:46:26 -0500

[smicha (smicha)]

Hi,
I have the same problem as Eythian.
I use the version "Fail2Ban v0.6.0"

I have solved that problem with following trick.
(Quick and dirty ;-)

###########
cat /dev/null > /var/log/auth.log
cat /dev/null > /var/log/fail2ban.log

/etc/init.d/fail2ban restart
###########

Before you "flush" the auth.log and fail2ban.log, make a copy !!!! ;-)

After that, fail2ban is running wel.

Best regards
Michael Schleicher

[Yaroslav Halchenko (yarikoptic)]

it is running well since it is already 1st of March ;-)

On Sat, 01 Mar 2008, smicha wrote:

> Hi,
> I have the same problem as Eythian.
> I use the version "Fail2Ban v0.6.0"

> I have solved that problem with following trick.
> (Quick and dirty ;-)

> cat /dev/null > /var/log/auth.log
> cat /dev/null > /var/log/fail2ban.log

> /etc/init.d/fail2ban restart

> Before you "flush" the auth.log and fail2ban.log, make a copy !!!! ;-)

> After that, fail2ban is running wel.

> Best regards
> Michael Schleicher
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: [phone]x263 | FWD: 82823 | Fax: [phone]
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik

[Even Nedberg (nedberg)]

I faund out today that fail2ban did not start. Today is 2nd of March. I use Dapper server. smichas solution fixed it though! If fail2ban has security issues it should be fixed since this is a LTS!

[Robin Sheat (eythian)]

I have the same problem (I hadn't thought to look). Unless the logs are manually flushed, fail2ban will be unusable until the appropriate logs containing Feb 29 dates are rotated. This is a bit more damaging than I initially thought. I'm also of the opinion that it should be fixed in the distro.

[x (dvice-null)]

Authors of fail2ban have provided following patches (mayby the patch 'fix-leap-year-detection-0.6.2.patch' could be used for Ubuntu 6.06?):
http://sourceforge.net/tracker/index.php?func=detail&aid=1904430&group_id=121032&atid=689044

IMHO this is a security bug and should be fixed. I didn't dare to wait so I cleared my log files to get it working again.