private/var/log/mail.log changed size expected 25917 found 742 cksum expected 3652242742 found 1276740875
Log files are altered and rotated on a daily basis, and as such, any change to a log file is not necessarily a red flag. We need not be too worried about this one. But the next one is more of a problem:
private/var/log/system.log changed permissions expected 0640 found 0662 size expected 49066 found 18671 cksum expected 3572187358 found 1678708264
Here the system log file, which is usually only writable by root, has been made writable by everyone. There's no good reason for this, and no normal program would have done this. If you didn't do this, then you should be suspicious of the change. Change the permissions back and examine the file; let us assume that someone has set write permission on the file so that they could alter its contents to cover up their break-in. Look for gaps in the timestamps. My system runs
crons every five minutes, so I would be looking for any missing
cron entries that would give me a clue as to when the event took place. Alas, it does not tell me what took place, only that something did and maybe when. Here's another:
usr/bin/passwd changed cksum expected 426431686 found 2543813206
The only change reported is the
cksum. From this, we know that the contents of the file have been changed (although we do not know what the actual change was). This is a basic system utility, and you don't just recompile it on the fly; indeed, you won't find the source for this on your Macintosh unless you went to the Apple site and got it specifically. Now would a good time to start panicking, especially if you found several files had changed. Fortunately for me, this was just the result of installing an updated version of Mac OS X, and the panic was short-lived.
This is a problem with the report--lots of files get changed in the normal usage of a system. I left mine alone for 24 hours, and 38 files turned up in the report. All logs get added to and moved as part of the daily
periodic tasks, and applications such as SoftwareUpdate update their plist files. When you actually use your computer for even the most mundane tasks, such as email and browsing, the list gets large very quickly. There are three things you can do:
- Diligently check each line of the report.
- Write a program to filter the report and highlight exceptional activity.
- Exclude irrelevant files from the specification.
I go with a combination of 2 and 3. Changes to executable files worry me more than those to other files, and changes to permissions and ownership more than size changes. So I have a program rank the changes according to severity, and I can then investigate the most severe changes. I will leave the writing of such a program as an exercise.
Excluding Files from the Specification
To exclude files or directories from the specification,
mtree takes an
-X parameter, followed by the name of the file that lists the files and directories to exclude. Whatever you do, make sure that you do not exclude your exclude list from the specification. Mine looks like this:
./Users ./Library/Fonts ./Library/Logs
Being a developer, my home directory has frequent changes that put too many false positives into the report. So I have chosen to ignore the home directories. The Fonts directory has a cache that keeps changing, and the Logs directory always changes. The lines in the exclude file are supposed to be
regex patterns, and should allow a great deal of control over what files are to be excluded, except that it doesn't seem to work. Note also that as we created our specification with the
-P option, to make it treat symbolic links as files, we are not able to add /tmp to our exclude file. We would need to add /private/tmp, as this is the actual directory that /tmp is a link to.