#648021 fail2ban: Logfile in UTC, localtime UTC+1 -> no entrioes found

#648021#5
Date:
2011-11-08 12:01:23 UTC
From:
To:
Package: fail2ban
Version: 0.8.4-3
Severity: normal

Hi.

On this (hopefully quite generic) system a log line looks:
Nov  8 11:19:38 bar sshd[25427]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=fnord

The time given is in UTC, localtime is UTC+1. Fail2ban seems to interpret the
time stamp as localtime and given the value of 'findtime' of 600 will never
find any logentry.

My workaround is 'fail2ban-client set ssh findtime 4600', which is a bit ugly.
A nicer approach would be to make a time offset settable.

cu

AW

#648021#10
Date:
2011-11-08 12:58:49 UTC
From:
To:
hm... i.e. custom time offset per each jail?
#648021#15
Date:
2011-11-08 12:58:49 UTC
From:
To:
hm... i.e. custom time offset per each jail?
#648021#20
Date:
2011-11-09 09:16:20 UTC
From:
To:
begin  quotation  from Yaroslav Halchenko (in <20111108125849.GZ8592@onerussian.com>):

Yep. Or for the whole package. But I have not thought that through.

cu

AW

#648021#25
Date:
2013-12-23 12:36:38 UTC
From:
To:
I also ran into this issue. A different work around is

echo "export TZ=UTC" >> /etc/default/fail2ban

Since it took me quite some time to notice this issue, let me propose
the following extension:

In processLineAndAdd you already (debug) log when a line gets ignored
due to the findtime setting. I propose adding a flag to
processLineAndAdd that indicates whether it was called due to a poll or
during program startup. Since all polling modes either immediately
notice changes or take at most 1 second, this ignoring can (in theory)
never happen during polling. So I suggest to emit a warning in this
case. I believe that a warning is warranted when a poller takes more
than findtime seconds to report new messages.

The advantage is that now fail2ban spams my log when I have
misconfigured it and chances are, that I'll notice.

Helmut