| |||||||||||||
Not very thought through proposalNot very thought through proposalPosted Nov 23, 2011 12:07 UTC (Wed) by job (guest, #670)Parent article: The Journal - a proposed syslog replacement
Each log entry authenticates the previous ones? So in order to remove a few lines from the log, you have to rewrite the log since that point in time?
Somehow I doubt this will pose a problem to an attacker who is so stealthy he/she manipulates logs. Most attackers just wipe them. That's why remote logging was invented.
After all, you will need a toolset to handle these logs for reading, searching and writing. I'm sure there will be a tool in this toolset which rewrites logs (just like there is for git).
The part where you store the root seed which authenticates the whole logs is also quite opaque. I guess you have to store a new seed every time you rotate logs, otherwise you'll be completely unable to authenticate anything when (parts of) an older log goes missing. So you'd have to have a remote logging protocol which logs these seeds continously, at which point you could just let it log everything and be done with it.
I'm all for enforcing stricter inter-application log formats to make them easier to parse, but this is just solving made up problems instead of the real ones just because it's easier.
(Log in to post comments)
Not very thought through proposal Posted Nov 25, 2011 9:57 UTC (Fri) by intgr (subscriber, #39733) [Link]
> Somehow I doubt this will pose a problem to an attacker who is so stealthy
> he/she manipulates logs. Most attackers just wipe them. That's why remote > logging was invented.
Nope. I've seen intruders simply using 'sed' to delete the lines they want to hide. I do think that Journal will defeat log manipulation by many simpler attackers, simply because there are no distro-bundled tools to manipulate them.
Not very thought through proposal Posted Nov 25, 2011 10:11 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
there will need to be distro bundled tools to manipulate the logs.
there are just too many cases where you need to deal with parts of the logs and you don't want to have to deal with all of the logs, so you need to do the equivalent of grep or grep -v
the only way it will slow the attacker down is as it is first introduced via 'security by obscurity', If it ever does become the standard, the attackers will just use the appropriate tools.
Not very thought through proposal Posted Nov 25, 2011 22:27 UTC (Fri) by job (guest, #670) [Link]
Indeed there will be such tools. It is required as the format is undocumented binary.
The reason some attackers manipulate logs with sed today is simple because it's possible. They will use another tool when it's not.
I hope some of the proponents of this proposal would answer the details about remote seed logging and what problems this would solve as opposed to simply remote logging. This part is completely left out, and I still think the misunderstanding is on my part as it is simply a much too ill thought out proposal otherwise.
Not very thought through proposal Posted Nov 25, 2011 23:31 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
one argument could be that remote seed logging is low bandwith compared to full remote logging.
I don't think it's a compelling argument (especially in light of all the complexity involved here, etc), but it's an argument.
by the way, it turns out that there is a RFC on how to properly secure logs, RFC5848 that has been through the mill of analysis, both from a crypto point of view and it's limitations (http://www.gerhards.net/download/log_hash_chaining.pdf)
|
|||||||||||||