A best practice should be to use NTP with the security validation turned on with the time source available from within the local environment. However, this should not preclude sites which do not or cannot use NTP or similar timing system from having a meaningful logging experience. There should always be two timestamps, one from the client and one from the "trusted" logging server. The reason is that a client's time could be easily manipulated by an attacker to hide intrusion attempts even if they ran NTP. Normally, the time variation between client and server should be minimal and closely related to network delay as Chris points out. Variations in timestamps longer than X should be reported as an anomaly itself. The timestamp format in itself should be either GMT/UTC (to provide a smaller length) or should provide local time and a timezone correction. This way whatever the site administrator wishes to use as a time reference (global or local) could be created. As most machines use UTC and a timezone correction to provide local time, this should be an "easy" fix. Ron Ogle Rennes, France Chris Adams wrote: > On Monday, Aug 26, 2002, at 19:57 US/Pacific, Russell Fulton wrote: > >> 2/ Some machines are constantly sync'ed using NTP some sync'ed on boot, >> some are not sync'ed at all. Having that information included with the >> log file could be useful if at some time in the future you need to do >> correlations with other files. If you don't know how accurate the >> clocks are it is dam near impossible. > > .. > issue, I see two choices. The best one would be including something like > NTP in the spec to determine the relative offsets between the clients > and the log server at periodic intervals. This would give accuracy at > the expense of adding a non-trivial amount of additional work for > implementors. > > As a compromise what do you think about having any relay or log server > simply add a local time element to any message which differs from its > clock by more than a defined period? That'd still leave network delays > but it would help us track down consistently wrong sources or relays. _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Wed Aug 28 2002 - 11:43:46 PDT