| |||||||||||||
The Journal - a proposed syslog replacementThe Journal - a proposed syslog replacementPosted Nov 19, 2011 17:13 UTC (Sat) by Tr0n (guest, #42662)Parent article: The Journal - a proposed syslog replacement
Has Lennart gone mad!?
You secure logs by sending them to a remote host (or two) and making sure they can only be administered by a handful of people.
The first rule about security is ACCESS.. If they have access to delete the logs or destroy the system, that's all they need.
Heh, a write-only location for the initial seed of the logs is silly... How is it going to be read in order to verify the first entry? Why wouldn't root just write a new value?
This custom binary rubbish is just plain madness.
(BTW, I can see a great amount of sense and reasoning behind systemd/puleaudio - which is why I'm so surprised)
(Log in to post comments)
The Journal - a proposed syslog replacement Posted Nov 19, 2011 18:51 UTC (Sat) by alankila (subscriber, #47141) [Link]
The idea is, as far as I understand it, to periodically log the latest log entry's hash (and id) to a location which does not permit updates afterwards. I'm going to guess we are talking about logging it once per minute or something like that.
From there on, you can use this sequence of hash values to significantly improve chances of detecting any tampering, because the attacker has only in average half of the hash storage window to take over the logging facility before tampering with the logs becomes provable.
Binary log is entirely reasonable given the additional goals being sought: ability to log binary data using a format that reuses values from previous log entries and stores them in compressed form (permitting machine-readable self-describing log entries with far more information than otherwise is possible without significantly increasing entry size).
The Journal - a proposed syslog replacement Posted Nov 19, 2011 18:59 UTC (Sat) by alankila (subscriber, #47141) [Link]
I wish to add additional detail to the middle paragraph. The idea is that once attacker enters a machine, there may be a log entry in syslog that shows evidence for it happening, some characteristic error message or whatever.
If the attacker wishes to hide this entry, he must almost immediately take over the logging system before it manages to save the top hash to secure location, because afterwards you can't unnoticeably remove those log entries.
The Journal - a proposed syslog replacement Posted Nov 20, 2011 0:23 UTC (Sun) by endecotp (guest, #36428) [Link]
> periodically log the latest log entry's hash (and id) to a
> location which does not permit updates afterwards.
Such locations don't exist, apart from printers and optical drives.
> I'm going to guess we are talking about logging it once per
That's nothing like fast enough if the attacker has some sort of automatic tool (and I don't believe I've ever seen non-automated attacks). To be useful it must save every single new hash value.
The Journal - a proposed syslog replacement Posted Nov 20, 2011 4:39 UTC (Sun) by alankila (subscriber, #47141) [Link]
Such locations can be constructed. Many people here seem to think that a dedicated syslog server is secure, and that would have no other function and no other visible ports except one which accepts data in syslog protocol. Logging every hash sounds like a solution whose overhead is comparable to just doing remote logging directly. There might be value in having some kind of middle ground.
Not every attack succeeds immediately, and it may take several tries to successfully exploit some race condition in a daemon. Once attacker breaks in through some local daemon, it still takes some time to download or build the relevant exploit utility, and to launch the secondary attack which finally gives root compromise.
The Journal - a proposed syslog replacement Posted Nov 20, 2011 20:19 UTC (Sun) by jackb (subscriber, #41909) [Link] Such locations don't exist, apart from printers and optical drives.So they don't exist except when they do exist?
|
|||||||||||||