The Journal - a proposed syslog replacement [LWN.net]

The Journal - a proposed syslog replacement

Posted Nov 18, 2011 17:48 UTC (Fri) by dlang (✭ supporter ✭, #313)
Parent article: The Journal - a proposed syslog replacement

this will not scale well to large numbers of events. It's far better to send the logs elsewhere.

and in any case, crypto signing the logs does nothing to prevent the attacker from erasing the files. If each log entry is signed individually then you don't even prevent the attacker from erasing individual log entries. you would have to sign each log entry on top of the prior one to detect gaps.

(Log in to post comments)

The Journal - a proposed syslog replacement

Posted Nov 18, 2011 18:21 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

> If each log entry is signed individually then you don't even prevent the attacker from erasing individual log entries. you would have to sign each log entry on top of the prior one to detect gaps.

Which is exactly what is being suggested. The top-level hash is based on the previous hash plus the new log entry. Yes, an attacker could still delete the logs, but the idea is to make them tamper-*evident*, not tamper-*proof*.

Still, as you stated, you can tamper-proof the logs by sending them to a dedicated, "bullet-proof" logging server, or some form of write-once local storage. Remote logging, at least, is essentially a solved problem.

The Journal - a proposed syslog replacement

Posted Nov 18, 2011 20:51 UTC (Fri) by NAR (subscriber, #1313) [Link]

but the idea is to make them tamper-*evident*, not tamper-*proof*.

Somehow I doubt this will achieve this. I bet most system administrators will use the local tools that check the signature - and the rootkits will just replace these tools to not warn the administrator...

The Journal - a proposed syslog replacement

Posted Nov 18, 2011 22:16 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Given the following scenario, how do we ensure detection?

- No network logging
- Verification binary replaced
- rpm changed so that a local rpm -V hides detection
- Files changed such that an external rpm's -V hides detection
- Scrubbing logged events of the above (so that logging in and yum.log are silent (yum detects when the rpmdb changed without yum and yum logs any changes it makes))

With local root, this is all possible.

The first step that I can see is to add expected log messages. Every X minutes a new log message is made with a specific message. The attacker can no longer just nuke the end of the log because then expected messages are missing.

Now the attacker must rewrite the logs. I don't know how to prevent this and it is probably impossible (as root can write whatever they want). It's a higher barrier to go undetected. Given that there are those who will go to varying lengths to attack your systems, how many does the higher barrier deter that weren't before? Obviously, there are those that don't care and will go to *any* lengths, so we can't win them all.