Recent Features
| |||||||||||||
making the logs temper evident through git like hash chainsmaking the logs temper evident through git like hash chainsPosted Nov 19, 2011 0:32 UTC (Sat) by dlang (✭ supporter ✭, #313)In reply to: making the logs temper evident through git like hash chains by scottt Parent article: The Journal - a proposed syslog replacement
this means that you have to check the hash of every single line in the file to find a problem.
that takes a significant amount of time with a large logfile.
If you don't check every single hash, then the attacker deletes one entry and then two entries later the hash will compute
there's also nothing preventing the attacker from re-writing the entire file to have consistent hashes, but with missing entries (git allows this as well,I believe it's the filter-branch option)
If you have the ability to send stuff elsewhere to a secure location then you don't need this. If you don't have this ability, then this new stuff doesn't do you any good.
tripwire, ossec and equivalent already have the ability to learn that a file is a logfile and complain if an existing part of the file is modified between scans. There is a window of vulnerability in that they don't check after each line is written, but if you run them frequently you get something that's at least 90% as good, without having to throw out all the existing logging related tools in the process.
(Log in to post comments)
making the logs temper evident through git like hash chains Posted Nov 19, 2011 5:28 UTC (Sat) by rgmoore (subscriber, #75) [Link] there's also nothing preventing the attacker from re-writing the entire file to have consistent hashes, but with missing entries (git allows this as well,I believe it's the filter-branch option)That's true. The biggest thing it does is to increase the sophistication an attacker requires to cover his tracks thoroughly. Instead of editing a log file with his favorite text editor, an attacker will need a track erasing program that rewrites all the log files with suspicious entries removed and hashes recomputed. Of course once a program like that gets out, all the script kiddies will be able to use it and we'll be hardly any better off than today- securitywise, at least.
making the logs temper evident through git like hash chains Posted Nov 20, 2011 8:16 UTC (Sun) by drag (subscriber, #31333) [Link]
Well that's the obvious first thing one should think of. I thought of it too.
Then I read in the article about a mythical 'Write-once storage'. If you can write out the hash to a write-only interface then that would solve that problem.
Unfortunately I don't know of a good write-once media. Maybe cdroms, but I don't know about that.
Maybe special flash media with the 'erase block' part of the hardware disabled and a logging FS. I don't know.
It is a solvable problem, but not one that is as easy as first glance.
making the logs temper evident through git like hash chains Posted Nov 27, 2011 2:18 UTC (Sun) by rgmoore (subscriber, #75) [Link] But the big security benefit in that case is from the existence of the WORM memory, since any data written to it is inherently tamper-proof. You could stick to an un-hashed text log and still have confidence that it hadn't been rewritten by an intruder. The benefit of the hash chain is that you can provide tamper evident recording by keeping only a fraction of the hashes, which is most important if the WORM storage is expensive or difficult to deal with. Of course keeping only a fraction of the hashes leaves open a potential window if the attacker can break in an alter the records between writes to WORM.
making the logs temper evident through git like hash chains Posted Nov 27, 2011 5:47 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
however, since systems don't actually include WORM memory, and are very unlikely to (except for very specialized systems), how does that actually help?
remember that WORM memory needs to be a replaceable thing since by default you can't erase it to make room for new data.
|
|||||||||||||