ConfigServer Community Forum

Running latest csf, RHEL 4.4, latest kernel, generic linux

We have an application that ssh's into a server every hour. We'll see this being logged in lfd.log and ignored as it should, then suddenly the logging stops in lfd.log, even though the logins continue. During these times, actual brute force attacks go unblocked as well. A "service lfd restart" seems to jumpstart things again.

After examining the times, it seems to coincide with log rotations each night. If we /dev/null a logfile does this cause lfd a problem? We use a simple devnull copy for our system logs after being zipped. Our workaround for now is a nightly restart of lfd.

Rob

Did some more testing. A "cp /dev/null /var/log/secure" even with a HUP to syslogd still makes lfd stop logging to it's logfile and stop analyzing this file. lfd has to be restarted to resume tracking. Hope this helps.

Rob

That's to be expected. lfd was developed to cope with the standard logrotate procedure that generates a new file and archives the old, thuse changing the inode which prompts lfd to reopen the relevant log file it is monitoring. If you simply empty the file, the inode doesn't change and the file pointer remains where it was. So it won't pick up any new entries until the file pointer reaches the same value.

I'll see if there's a way around this, but it would really be best to:

1. Rename /var/log/secure to /var/log/secure1

2. HUP syslogd

Which is basically what logrotate does.

3. Remove /var/log/secure1 if you have no use for it, otherwise compress it

Thanks. Makes sense. Our custom log rotate script will just restart lfd for now untill we rewrite things.

Rob

I've released a new version of csf (v2.64) that should now cater for emptied log files as well as rotated ones. Once upgraded you should no longer need to restart lfd after your rotation job.

Thanks, works great!

Rob