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.
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
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
This issue is fixed in fail2ban 0.8.8.
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
(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.
(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.
(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.
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.
(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.
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?
FWIW -- I hope to release 0.8.9 today/tomorrow so if you could use it instead -- might avoid patching. Cheers
Next monday my logs will rotate again, a new release before that would be ... excellent timing!
Would be nice if the new 0.8.9 would be released soon.
Fixed in fail2ban-0.8.10-1.el6.noarch
I consider it closed.