>>>>> On Sat, 7 Dec 2002 01:45:22 +1100 (Australia/ACT), Darren Reed <avalonat_private> said: DR> Ok, let me wind this up (kind of)... Sure, we've all been trying to wrap-up ysstem logging for 10 years :-) DR> What I was hoping for was some sort of summary about where current DR> implementations of a syslog daemon fall short of providing adequate DR> information to be of forensic value. I think we all agress that classic syslog is useless forensically. The better-than-classic syslogs all add some good features, but each in different ways. In court, being able to claim compliance with standards, or "widespread industry practice" counts for a lot. DR> In the binary data files nsyslogd creates, it recorded, DR> per syslog msg: DR> - mac Is this the MAC address of the last hop or a message authenticity check? I'm guessing the latter. Where is this generated? On the original source machine? Is it keyed with some shared secret between the source and final destination? All of these have integrity implications, of course. DR> - time (second granularity) "received" by first nsyslogd DR> - priority DR> - hash count Is this a crypto hash of the contents or ?? DR> - syslog line # count Looks like a sequence number, which is good. DR> - file count ?? DR> Hmm, so I never did encryption (it seems) but I think I understand DR> why: 1 bit or byte of trashed encrypted data ruins the rest. Or maybe DR> it was because of export reasons or something else. The aim is not to DR> prevent change, but to detect it and be able to prove that the integrity DR> of the data is in fact intact. Oh, the problem is discovery of the hash DR> seed creates a weakness but unless you start over each time and require DR> a secret input with each startup (operationally troublesome), its just DR> a risk you have to accept. If you are worried about a 1-bit error in the stream causing encryption problems, then you have conceeded the integrity of the data is not good. But yeah, encryption is not necessary for forensic soundness, we're looking for integrity here, not secrecy. Some people use cryptography as the only hammer to get integrity as a side-effect. Pays more in overhead than necessary. OK, so the hash is seeded, that's pretty much required. And yeah, crypto is hard, but key management is harder, so getting the shared seed/secret in place... Yup its a tradeoff between being operationally feasible (store the seed on the machine) and "perfect, and operationally nearly impossible (enter seed at each startup). DR> The three counters are kept because once you start off, you need to be DR> absolutely certain of the order the data was received in. Is this for ordering (timestamp should do that) or to detect inserted and lost messages? DR> Where do you see this falling short of being suitable for forensic DR> evidence ? It looks like this design is probably pretty strong. Its main failings (if you could call them that) is that they are effectively proprietary, and not in widespread use. This is a "culture of the court" issue, not necessarily a technical issue. And of course, integrity is an end-to-end problem, and all we are discussing is the transport between the endpoints. We still need to address as separate issues, the integrity of the original data as it is generated on the source machine and integrity of storage at the final destination. But those are not syslog issues. DR> Something different it did was initialise the hashing by hashing for DR> a second and recording how many times that happened (hash count), so DR> on a P4 3GHz, if someone was to initialise it, brute forcing would DR> still force someone to spend at least 1 second per guess with a P4 3GHz. Hmmm, I think I see this. What was the algorithm? -- Tom E. Perrine <tepat_private> | San Diego Supercomputer Center http://www.sdsc.edu/~tep/ | _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Tue Dec 10 2002 - 10:27:11 PST