Recent Features
| |||||||||||||
The Journal - a proposed syslog replacementThe Journal - a proposed syslog replacementPosted Nov 18, 2011 19:56 UTC (Fri) by slashdot (guest, #22014)Parent article: The Journal - a proposed syslog replacement
Binary formats are a non-issue, since you can just use a tool that writes it out in text format, and pipe that to whatever.
However, overall, their hash chain idea is cute, but just sending everything to another machine seems far more effective, since instead of just detecting that someone erased the logs, you can prevent them from doing so (as long as they don't compromise the other machine too, that is).
Most of the points they raises are very valid.
Instead of using UUIDs, however, I would suggest using (an hash of?) the format string; if it needs to be changed, a special API can be used which takes both the original format string for ID purposes and the new one for formatting.
(Log in to post comments)
The Journal - a proposed syslog replacement Posted Nov 18, 2011 20:58 UTC (Fri) by zander76 (guest, #6889) [Link]
Hey
Won't it be possible to sha1 the textfile plus some extra infomation like the time and previous key. That should make it fairly easy to check to see if its been modified without using some binary file or am I missing something?
Ben
The Journal - a proposed syslog replacement Posted Nov 18, 2011 21:35 UTC (Fri) by elanthis (guest, #6227) [Link]
The hash chain works really well, actually, even for local storage.
Attackers aren't going to just wipe out logs because that can make it painfully obvious that there's been a breakin. Removing or changing individual log entries is much more subtle, but with the hash chain this becomes very difficult; the attacker would have to rewrite the entire chain from the first message he wanted to modify.
This can clearly be combined with remote logging facilities. Better yet, it removes the need for infrastructure explicitly targetted at remote logging and instead just lets you use an existing backup service, and some tools to see if the "branches" of the logs match up between previous backups or not.
This is _exactly_ what git does.
In the end, while never losing data is important, knowing that you have modified data is significantly more important. People who can do so should have remote logging and very strict security rules, but the rest of us who have a single Linux box and an SFTP backup service (if we're lucky) shouldn't be screwed out of _all_ security features.
The Journal - a proposed syslog replacement Posted Nov 18, 2011 22:18 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Additionally, on btrfs (or other COW systems) such manipulation can be nigh impossible to hide as it would require to rewrite quite a lot of stuff.
The Journal - a proposed syslog replacement Posted Nov 21, 2011 14:31 UTC (Mon) by nix (subscriber, #2304) [Link] the attacker would have to rewrite the entire chain from the first message he wanted to modify.Well, yes. The attacker has to read() and write() the whole thing from that point on anyway, since POSIX provides no write_and_shift_up() nor delete_and_shift_down() functions. Do you really think that rehashing will be hard on top of that? You could only detect that if you mirrored the logs onto some other system... in which case you might as well only mirror the hashes. Actually you might as well simply store the hashes on their own on a different machine, and use a conventional syslog, without the myriad instantly obvious downsides of this hairbrained scheme.
|
|||||||||||||