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.
Log in to post a comment.