I wish I had seen that link earlier

. Thanks for pointing me in the right direction, Till.
The cited tutorial contains the correct information regarding the log location (
/var/log/syslog), which is good to see.
However, when I change my fail2ban configuration to match that in the tutorial, I'm never banned in my tests.
I have not changed the pure-ftpd configuration or logging options, for what that's worth.
I tried passing the sample log line and regex from the tutorial to fail2ban-regex, and a match is found, so I'm not sure why I'm never banned. I have made sure that my IP address is not white-listed in the fail2ban configuration.
With fail2ban's loglevel = 3, nothing is logged when I repeatedly fail authentication. The maxretry threshold is set to 3, and I've tried dozens of times -- still nothing.
If I set fail2ban's loglevel = 4, there is simply too much output for me to sort-out the log entries.
Is this a question for the fail2ban mailing list?
Unfortunately, I've introduced another issue while attempting to troubleshoot this one.
I forced a log rotation for all logs when I meant to force a rotation only for
/var/log/auth.log. (I wanted to force a rotation because this file was some 400MB in size, and parsing it with fail2ban-regex was taking too long.) Now, nothing is being written to
/var/log/auth.log. If I
tail the file, and for example, log-in via SSH, nothing is written to the log. After a day or so, the log is still empty. Why might rotating the log cause this behavior?
The files look like this:
Code:
-rw-r----- 1 syslog adm 0 Jan 4 09:49 auth.log
-rw-r----- 1 syslog adm 376M Jan 5 08:32 auth.log.1
EDIT: Now that I look at these dates, I realize that the auth.log.1 file is the one being modified, not auth.log.
I should add that auth.log was never being rotated (which is why it was 376MB in size), so I created the file
/etc/logrotate.d/auth and populated it with the following contents:
Code:
/var/log/auth.log {
weekly
rotate 12
}
I forced the log rotation
after creating this file, if I recall correctly.
The relevant entry in
/etc/syslog.conf looks correct:
Code:
auth,authpriv.* -/var/log/auth.log
Any idea why this would cause the .1 log file to become the primary log? Is there a simple way to fix this?
Recent comments
6 hours 35 min ago
16 hours 3 min ago
16 hours 53 min ago
20 hours 26 min ago
1 day 50 min ago
1 day 1 hour ago
1 day 3 hours ago
1 day 13 hours ago
1 day 18 hours ago
1 day 19 hours ago