Logfile integrity monitoring

[thogard]

Many compliance specifications require logfile integrity monitoring. I'm at a loss of how to do this properly with FreeBSD without writing my own code. I'm looking at checking log files that grow for a while, get rotated to a different name and then later compressed and I want to do this with text files as well as binary files from OpenBSM. Tools like OSSEC seem to have some smarts when it comes to expanding log files or renamed logs but they don't seem to detect when the early parts of an expanding log have have been tampered with. Is there a simple tool that checksums a log up to its previously checked size to detect that or knows its been compressed? I expect the 1st answer is "move your logs to a more secure log server" but I have the same problem on that server too. What are the common solutions for doing this?

 

[bds]

This might not directly address your question, but running with kern.securelevel > 0 and setting the system append-only flag on a log file is probably the best way of avoiding tampering in a sensitive environment. However, if you're rotating and/or compressing you'll need to think carefully about how these can proceed without hitting the same wall as an attacker.
The trouble with secure hashes is that you only get a yes/no that they have been altered, but if they have you really will want to know what was changed to evaluate the nature/intent of an intrusion. So replicate them to a secured location, and to compare them you can create a truncated copy of the new one with head -c given the size in bytes of the old.

 

[thogard]

I've decided that I'm going to build a compressed zfs file system for /var/log/2019/ and put most things there with chflags sappnd,sunlnk * with a kern.securelevel=2. It would be great id syslog and newsyslog happened to use strftime on their log file names so I could use /var/log/%Y-%W/syslog in syslog.conf. One of the problems I've seen is that I can do a zfs destroy zroot/var/log/2019 even if /var/log or /var/log/2019 has schg set. So a hacker looking to edit logs would be to copy the files someplace, then remove the file system, recreate it and move the edited files back. I expect it would be very difficult to recreate a zfs system with what appears to be the historic snapshots but I expect a fix for that could be scripted. I've looked at fixing things via symbolic links but that could open up race condition issues.