Not very thought through proposal [LWN.net]

Not very thought through proposal

Posted Nov 25, 2011 9:57 UTC (Fri) by intgr (subscriber, #39733)
In reply to: Not very thought through proposal by job
Parent article: The Journal - a proposed syslog replacement

> 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.

(Log in to post comments)

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)