Bug 833056

Summary:

fail2ban stops filtering after log rotation with pyInotify backend

Product:

[Fedora] Fedora EPEL

Reporter:

Leonard den Ottolander <leonard-rh-bugzilla>

Component:

fail2ban

Assignee:

Adam Miller <maxamillion>

Status:

CLOSED WORKSFORME

QA Contact:

Fedora Extras Quality Assurance <extras-qa>

Severity:

unspecified

Docs Contact:

Priority:

unspecified

Version:

el6

CC:

maxamillion, maxim.yegorushkin, nevis2us, redhat.bugzilla, redhat_bugzilla, rolf, site-redhat, winckler

Target Milestone:

---

Target Release:

---

Hardware:

Unspecified

OS:

Unspecified

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2013-09-16 08:13:50 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
Source RPM for fail2ban 0.8.8	none

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.