#32 Scan for deleted/empty logs

Rkhunter (37)

Attackers will try to remove their tracks by removing logs like /var/log/messages and /var/log/secure.
It would be pretty easy to check if certain logs exists and contain data.

I created a check for this myself like this (with $LOGFILES being a space separated list of important logs):
# Check all logfiles
for file in $LOGFILES; do
if [ ! -f $file ]; then
echo "CRITICAL: $file does NOT exists! Please check!"
[ -s $file ] || eval 'echo "WARNING: $file seems to be empty! Please check!"; ((pwarn++))' && echo "OK: $file exists and contains data."

It would be great if Rkhunter could do this check.


  • unSpawn

    unSpawn - 2012-06-24

    I agree a log file existence check is a good one. Apart from that some systems may log way less, some operating systems and Linux distributions may use different file names, log files may have odd names ("segment/YYYY/mm-dd-machine-syslog"), files may be subject to log rotation, logs may be stored with a different method altogether (database), I could echo "AAA" > /some/log" and it wouldn't mean much, some distributions advocate storing logs in a tmpfs and rsync on shutdown (right, guess what goes wrong on crash) and besides that the interval with which one would run RKH with (and the overhead it would cause) would be no match for a cron job, a system monitor like Monit or a file integrity checker like Samhain. There is more to it than meets the eye, wouldn't you say?

    Most of all please remember RKH runs -=post-incident=- checks. If log files were deleted somebody may have gained root. Meaning -=everything including RKH=- may be subject to alteration. An ounce of prevention being worth a pound of cure I would suggest using a cron job, Monit or Samhain or equivalent.

  • unSpawn

    unSpawn - 2012-06-24
    • assigned_to: nobody --> unspawn
    • status: open --> pending
  • John Horne

    John Horne - 2012-08-09

    I would agree with unspawn. Log rotation will empty a file, so this sort of check would cause numerous false-positives at that time (assuming the file is still empty at the time RKH runs).

    However, a check that a file exists may be possible. We can;t do this with the file properties checks because a log file will generally be changing and so continuously giving false-positives (changing size, md5, date/time etc). But a simple check that a file exists should be relatively trivial. A config option would be required to allow the user to specify what file(s) to check.

    (Hmm, actually we could check for empty files too. Simply provide a default empty option, and let the user provide the relevant file names. Any false-positives will be for them to deal with.)

  • John Horne

    John Horne - 2012-12-22
    • status: pending --> closed-fixed
  • John Horne

    John Horne - 2012-12-22

    Fixed in CVS.

    Two new tests, part of the 'filesystem' checks, have been created. The first checks for missing log files, the second for empty log files. The second test will also check to see if the file is missing (since a missing file can be considered 'empty'). Two new config file options have been added to support this - MISSING_LOGFILES and EMPTY_LOGFILES.
    Note that using these options may cause false-positives when log files are rotated.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks