On 2002-03-29 12:24:16 -0800, Devin Kowatch wrote: > > The second problem is that it is not possible to determin where the > log was altered. If an attacker inserts or alters a message at time t > then all messages after time t will not be verifiable. But because > the intermediate hash values are not saved it will also be impossible > to verify messages _before_ time t. My understanding is that we save the original key, meaning that the entire chain of hash values and keys can be generated, given the log entries. Using this information you can verify all logs made before the compromise are unaltered. Save that bad-boy on a floppy or CD-R somewhere. (In the real world you probably want to save some intermediate keys as well, so you don't have to generate all hashes from the dawn of time.) > This leads to some obvious problems. > Lets say that an attacker gains access to machine A at time t. From > that point forward the logs from A cannot be trusted, however, we > still have the logs of the attack (which is good). Further, lets > assume that A is logging to a central log server L, and uses an > authenticated, integrety checked channel for communication from A to L > (i.e. the new syslog reliable protocol). In this situation it's > basically impossible for the attacker to insert a message before the > attack on A. So we should get good, verifiable logs of the attack. I'm with you up to here... > However, because it's impossible to determine where the bad messages > started, if an attacker inserts a bogus message into the channel > between A and L _after_ time t then all the log entries are > invalidated for the entire logging session. This will include the log > entries that show the source and method used to gain accesss. ...but this I don't follow. If L is compromised then sure, the logs can be wiped. But I don't see how the fact that the channel is compromised means that all log entries will be worthless. -- Shane Carpe Diem --------------------------------------------------------------------- To unsubscribe, e-mail: loganalysis-unsubscribeat_private For additional commands, e-mail: loganalysis-helpat_private
This archive was generated by hypermail 2b30 : Sun Mar 31 2002 - 08:26:27 PST