Bug 833056 - fail2ban stops filtering after log rotation with pyInotify backend
Summary: fail2ban stops filtering after log rotation with pyInotify backend
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: fail2ban
Version: el6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Adam Miller
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-18 13:45 UTC by Leonard den Ottolander
Modified: 2013-09-16 08:13 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-16 08:13:50 UTC
Type: Bug


Attachments (Terms of Use)
Source RPM for fail2ban 0.8.8 (114.03 KB, application/x-rpm)
2012-12-16 08:57 UTC, Matthieu Pupat
no flags Details

Description Leonard den Ottolander 2012-06-18 13:45:38 UTC
Description of problem:

Fail2ban will stop adding bans after a log rotation when pyInotify is used as the backend (this is the default when backend=auto). Perhaps the pyInotify code doesn't pass all necessary events to fail2ban.

Version-Release number of selected component (if applicable):

fail2ban-0.8.4-28.el6.noarch

How reproducible:

Wait for the logs to have been rotated. (I've been told the issue will *not* become apparent when forcing log rotation, so you'll have to wait for them to rotate from cron.) See that no bans will take place afterwards. This became obvious when fail2ban stopped sending ban mails.

Actual results:
fail2ban will no longer ban offending IPs, apparently still checking the old rotated log file.

Expected results:
fail2ban should track the fresh log file and keep on banning.

Additional info:

Adding a
fail2ban-client -x reload > /dev/null
to the postrotate will at least restart fail2ban so it reads the correct log. This will however nuke existing bans.
Using backend=gamin seems to work fine.

Comment 1 Alexander Kirillov 2012-06-28 08:53:49 UTC
Same here. Still log rotation seems to be correctly detected:

/var/log/messages-20120624:Jun 23 18:46:06 vixen <28>fail2ban.actions: WARNING [apache-noscript] Ban 81.201.154.140
/var/log/messages:Jun 24 03:49:15 vixen <30>fail2ban.filter : INFO   Log rotation detected for /var/log/httpd/error_log
/var/log/messages:Jun 24 03:49:15 vixen <30>fail2ban.filter : INFO   Log rotation detected for /var/log/httpd/error_log
/var/log/messages:Jun 24 03:49:15 vixen <30>fail2ban.filter : INFO   Log rotation detected for /var/log/httpd/error_log
/var/log/messages:Jun 25 14:04:57 vixen <28>fail2ban.actions: WARNING [apache-denied] Unban 64.120.177.26

Comment 2 Yaroslav Halchenko 2012-08-14 01:13:05 UTC
not sure what patchset you have in -28'th revision of 0.8.4 but pyinotify backend support in fail2ban was introduced only in 0.8.7 (and was not correctly working in some intermediate revisions before the actual release)

Cheers

Comment 3 Matthieu Pupat 2012-12-16 08:54:50 UTC
This issue is fixed in fail2ban 0.8.8.

Comment 4 Matthieu Pupat 2012-12-16 08:57:12 UTC
Created attachment 664258 [details]
Source RPM for fail2ban 0.8.8

This is a source RPM with modified specfile and patches for fail2ban 0.8.8.

Note that the source repository for fail2ban moved to github: https://github.com/fail2ban/fail2ban

Comment 5 Maxim Egorushkin 2013-01-17 17:30:39 UTC
(In reply to comment #3)
> This issue is fixed in fail2ban 0.8.8.

I am still observing this issue with:

    # cat /etc/redhat-release 
    Red Hat Enterprise Linux Server release 6.3 (Santiago)

    # rpm -q fail2ban
    fail2ban-0.8.8-1.el6.noarch

Using the default configuration.

Comment 6 Maxim Egorushkin 2013-01-17 17:42:39 UTC
(In reply to comment #5)
> (In reply to comment #3)
> > This issue is fixed in fail2ban 0.8.8.
> 
> I am still observing this issue with:
> 
>     # cat /etc/redhat-release 
>     Red Hat Enterprise Linux Server release 6.3 (Santiago)
> 
>     # rpm -q fail2ban
>     fail2ban-0.8.8-1.el6.noarch
> 
> Using the default configuration.

I take this back, haven't restarted fail2ban after it updated. Apologies.

Comment 7 Maxim Egorushkin 2013-01-21 14:32:36 UTC
(In reply to comment #4)
> Created attachment 664258 [details]
> Source RPM for fail2ban 0.8.8
> 
> This is a source RPM with modified specfile and patches for fail2ban 0.8.8.
> 
> Note that the source repository for fail2ban moved to github:
> https://github.com/fail2ban/fail2ban

Just double checked fail2ban-0.8.8-1.el6.noarch still fails to detect that /var/log/secure has been logrotate'd.

As a workaround I modified /etc/logrotate.conf to use copytruncate method instead of create (as suggested in numerous other places), so that rsyslog keeps writing to the same /var/log/secure, rather than switching to a new file. Will see how it goes...

Also, noticed /etc/logrotate.d/fail2ban, which I could not make sense of:

/var/log/fail2ban.log {
    missingok
    notifempty
    size 30k
    create 0600 root root
    postrotate
        /usr/bin/fail2ban-client set logtarget SYSLOG 2> /dev/null || true
    endscript
}

The default /etc/fail2ban/fail2ban.conf directs logging to syslog, so I am not sure what the purpose of the above config file is.

Comment 8 Yaroslav Halchenko 2013-01-21 14:42:38 UTC
AFAIK

/usr/bin/fail2ban-client set logtarget SYSLOG 2> /dev/null || true

is indeed pointless... usually it is done when logtarget is a file, so fail2ban would close/open a new one upon rotation.  But with SYSLOG this is not necessary.

Comment 9 Maxim Egorushkin 2013-01-28 10:18:38 UTC
(In reply to comment #7)

> Just double checked fail2ban-0.8.8-1.el6.noarch still fails to detect that
> /var/log/secure has been logrotate'd.
> 
> As a workaround I modified /etc/logrotate.conf to use copytruncate method
> instead of create (as suggested in numerous other places), so that rsyslog
> keeps writing to the same /var/log/secure, rather than switching to a new
> file. Will see how it goes...

I can confirm now that the above workaround works.

Comment 10 Rolf Fokkens 2013-05-13 14:46:28 UTC
Meanwhile the original problem persists, many users could suffer from this security issue and not be aware of it. (This was the case for me anyway, I'm using fail2ban-0.8.8-2.el6). 

There is a fix: https://github.com/fail2ban/fail2ban/issues/184

Should this be applied in the RedHat repo's?

Comment 11 Yaroslav Halchenko 2013-05-13 14:57:00 UTC
FWIW -- I hope to release 0.8.9 today/tomorrow so if you could use it instead -- might avoid patching. Cheers

Comment 12 Rolf Fokkens 2013-05-14 08:38:01 UTC
Next monday my logs will rotate again, a new release before that would be ... excellent timing!

Comment 13 Rolf Fokkens 2013-06-05 12:36:00 UTC
Would be nice if the new 0.8.9 would be released soon.

Comment 14 Rolf Fokkens 2013-08-26 14:23:38 UTC
Fixed in fail2ban-0.8.10-1.el6.noarch

Comment 15 Rolf Fokkens 2013-09-16 08:13:50 UTC
I consider it closed.


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