Bug 503852 - fail2ban fails to ban because of rsyslog
fail2ban fails to ban because of rsyslog
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: fail2ban (Show other bugs)
11
All Linux
low Severity urgent
: ---
: ---
Assigned To: Axel Thimm
Fedora Extras Quality Assurance
: Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-02 21:24 EDT by Jonathan Kamens
Modified: 2009-09-15 03:56 EDT (History)
3 users (show)

See Also:
Fixed In Version: 0.8.4-23.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-04 00:03:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to check inode as well a first line for log rotation (1.15 KB, patch)
2009-06-02 21:24 EDT, Jonathan Kamens
no flags Details | Diff

  None (edit)
Description Jonathan Kamens 2009-06-02 21:24:13 EDT
Fail2ban 0.8.3 detects log rotation by noticing that the first line of the log file has changed.

Unfortunately, this doesn't work reliably on systems that use rsyslog, when there is for whatever reason some process regularly sending a HUP signal to rsyslog, because the messages that rsyslog logs when it is HUP'd are not timestamped, which means that it's entirely possible for the first time of the new log file to be the same as the first line as the last one.

More generally, the assumption that all log file lines are timestamped and therefore that the first line of the new log file will always differ from the first line of the old one is invalid.

This could lead to banning not happening when it should (and, indeed, it did lead to exactly this on my system).

The attached patch fixes this by checking the inode number for rotation in addition to checking the first line of the file.
Comment 1 Jonathan Kamens 2009-06-02 21:24:46 EDT
Created attachment 346338 [details]
patch to check inode as well a first line for log rotation
Comment 3 Tomas Hoger 2009-06-03 02:56:29 EDT
Adding rsyslog maintainer to CC, as it might be worth checking if this should not be addressed in rsyslog too.  Doing a quick test, it seems that rsyslog restart message is written time-stamped to messages, but with no timestamp to secure:

# tail -n1 /var/log/messages /var/log/secure
==> /var/log/messages <==
Jun  3 08:48:47 localhost rsyslogd: [origin software="rsyslogd" swVersion="3.21.10" x-pid="1711" x-info="http://www.rsyslog.com"] restart

==> /var/log/secure <==
rsyslogd:  [origin software="rsyslogd" swVersion="3.21.10" x-pid="1711" x-info="http://www.rsyslog.com"] restart
Comment 4 Tomas Heinrich 2009-06-03 07:03:15 EDT
The message written to /var/log/secure is actually a bug in rsyslog - it shouldn't be there at all. This will be fixed in the next update.

A workaround to get rid of the message in the current version is to add this to your configuration file:
  $ErrorMessagesToStderr off

By default, all messages written to files contain a time-stamp.
This can be changed in the configuration, though.
Comment 5 Bug Zapper 2009-06-09 13:00:23 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 6 David Rees 2009-07-08 15:51:14 EDT
Any movement on this bug?  I don't see a relevant corresponding rsyslog bug.  It's affecting me on both F10 and F11.

I think it'd be nice to have the bug fixed both ways (the inode patch in fail2ban plus fix the error message in rsyslog on restart).
Comment 7 David Rees 2009-07-08 15:55:11 EDT
I apologize, it's not affecting me on F10, only on F11.
Comment 8 Tomas Heinrich 2009-07-20 08:07:42 EDT
New rsyslog release which should fix its part of the problem is available from updates-testing.
Comment 9 Jonathan Kamens 2009-07-25 23:21:31 EDT
I do not see what information you are asking me for.
Comment 10 Axel Thimm 2009-07-26 03:36:36 EDT
(In reply to comment #8)
> New rsyslog release which should fix its part of the problem is available from
> updates-testing.  

(In reply to comment #9)
> I do not see what information you are asking me for.  

Sorry, I thought the rsyslog fix is all there was needed, isn't it?

(In reply to comment #0)
> More generally, the assumption that all log file lines are timestamped and
> therefore that the first line of the new log file will always differ from the
> first line of the old one is invalid.

Other than the bug in rsyslog, could you give another example? Thanks!
Comment 11 Jonathan Kamens 2009-07-27 10:13:10 EDT
I do not know of any other log files on my system that are monitored by logrotate and affect this problem.  But I really don't see how that's particularly relevant.  I don't use all packages that have logrotated log files, so there may be one I know about.  And someone could configure logrotate to monitor an arbitrary file that isn't in an RPM maintained by Fedora, or a new Fedora logrotated file could be added that has this problem at any point in the future.

The bug in logrotate that cause this problem has been identified and is obvious from examining the code, and I've provided a patch.  Why not just fix it?
Comment 12 Jonathan Kamens 2009-07-27 10:13:36 EDT
Doh!  GOt confused.  Of course I meant fail2ban, not logrotate.
Comment 13 Jonathan Kamens 2009-07-27 10:22:51 EDT
I've reported this issue to the upstream maintainer of fail2ban, so you can CLOSED / UPSTREAM it if you wish.

  jik
Comment 14 Axel Thimm 2009-07-27 15:49:01 EDT
(In reply to comment #11)
> [...explanation on why the patch is necessary...]
> The bug in logrotate that cause this problem has been identified and is obvious
> from examining the code, and I've provided a patch.  Why not just fix it?  

OK, thanks for explaining, it needs fixing, of course.

(In reply to comment #13)
> I've reported this issue to the upstream maintainer of fail2ban, so you can
> CLOSED / UPSTREAM it if you wish.

I prefer to fix it in the package until the next upstream release does so itself, thanks for the patch and expect a fixed package soon.

For reference could you post the bug's URL you filed upstream here as well (maybe under the URL field)? Thanks!
Comment 15 Jonathan Kamens 2009-07-27 15:58:37 EDT
I don't think the author of fail2ban uses a publicly accessible bug-tracking system.  At least, I couldn't find it.  I sent him an email message.

  jik
Comment 16 Fedora Update System 2009-08-27 16:28:20 EDT
fail2ban-0.8.3-21.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/fail2ban-0.8.3-21.fc10
Comment 17 Fedora Update System 2009-08-27 16:28:33 EDT
fail2ban-0.8.3-21.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/fail2ban-0.8.3-21.fc11
Comment 18 Fedora Update System 2009-08-28 17:59:04 EDT
fail2ban-0.8.3-21.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update fail2ban'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-9094
Comment 19 Fedora Update System 2009-08-28 18:00:01 EDT
fail2ban-0.8.3-21.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update fail2ban'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9103
Comment 20 Axel Thimm 2009-08-29 01:46:57 EDT
(In reply to comment #15)
> I don't think the author of fail2ban uses a publicly accessible bug-tracking
> system.  At least, I couldn't find it.  I sent him an email message.

He uses sourceforge resources, so you can file it there, if you like.

I would recommend doing so, because currently fail2ban's development has stalled even with people looking for forking it and having the patches all in one place will make managing a new release easier.
Comment 21 Jonathan Kamens 2009-08-31 10:31:12 EDT
LOL.  Turns out I did that in June and forgot I'd done it:

https://sourceforge.net/tracker/?func=detail&aid=2800279&group_id=121032&atid=689044
Comment 22 Fedora Update System 2009-09-04 00:02:52 EDT
fail2ban-0.8.3-22.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 23 Fedora Update System 2009-09-11 06:57:17 EDT
fail2ban-0.8.4-23.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/fail2ban-0.8.4-23.fc11
Comment 24 Fedora Update System 2009-09-11 06:57:39 EDT
fail2ban-0.8.4-23.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/fail2ban-0.8.4-23.fc10
Comment 25 Fedora Update System 2009-09-15 03:49:58 EDT
fail2ban-0.8.4-23.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 26 Fedora Update System 2009-09-15 03:56:13 EDT
fail2ban-0.8.4-23.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.