Hi, Bennett Todd <betat_private> commented in a response to a posting by me: >> Hopefully this tool would have the smarts to figure out the >> differences between the clocks on the system supplying the logs, >> and to be able to determine the clock drift. > >That'd be nice, but it requires more information than I've seen >preserved in syslogs. The easiest fix to this problem is to just >eliminate the clock skew and drift, by running good time >synchronization code like ntp (which I'm not all that fond of) or >clockspeed (which I prefer). First a minor correction, I should have said systems. Second I should give attribution to Eoghan Casey for the idea behind the wish for time "smarts". For more on this see his article "Error, Uncertainty, and Loss in Digital Evidence" in the International Journal of Digital Evidence <www.ijde.org/02_summer_art1.html>. In an ideal world, all systems would have WWV(B), GPS, and other radio broadcast time signal receivers built in along with network synchronization for those systems that can not sync to a broadcast signal. Also in an ideal world, there would be sub-microsecond delay between an event and the timestamp generation of the event. Reality is most systems are not synchronized, and there can be significant delays in timestamping events. Timestamps in logs can be tampered with. I envision a time synchronization tool being given logs covering a minimum of several hours of logs from multiple systems that are supposed to cover the time period of interest. The tool would scan the logs to look for events that would be common to two or more systems. For any pair of systems, the tool would identify events that originate on each system and result in a log entry on the other. By analyzing these events the tool should be able to estimate the time difference and network delays with error bounds on those estimates. Analyzing events several hours later to compute another time difference estimate would give some idea of the clock drift between the systems. Development of this tool would also require determining the characteristics of timestamping delays for various common operating systems to further aid in computing the uncertainty bounds on an event. The logs given to the tool to analyze should be given trustworthiness ratings relative to the other logs. There is lots more on the wish list, but this will provide a basis for a start. B Cing U Buck _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Mon Jan 20 2003 - 09:59:05 PST