Re: [logs] reinventing syslog [was: Secure Central Log Host]

tepat_private

>>>>> On Thu, 05 Dec 2002 17:07:19 -0500, "Marcus J. Ranum" <mjrat_private> said:

    >>> I think I'd really like to have both timestamps in the final
    >>> destination log file.  The one the client put on, AND the one put on
    >>> by the final "write-to-file" daemone.

    MJR> What's the point? For most purposes, both timestamps would be
    MJR> inaccurate enough that you're not really storing any useful information.
    MJR> I believe that recording the messages with the originating system's idea
    MJR> of the time, and the receiving system's idea of the _sequence_ is probably
    MJR> sufficient. As long as you're keeping things in the correct sequence on
    MJR> the server, you're OK.

I think we need to make a distinction between good ol' syslog and
syslog-reliable.  There may be important differences.  Or maybe not.

First off, if you aren't running *good* NTP *everywhere, just stop
reading now and go home.  If you aren't, you don't care about "time",
nor "forensics" and this whole discussion doesn't apply to you :-)

You see, Einstein was right about "simultaneity" :-) We're trying to
see "action at a distance", and that's "hard".  We can approximate it,
but that's it.

With any syslog architecture that includes relays, you could have two
messages, issued at the same time (on the same host, under certain
really ugly circumstances), take different amounts of time to get to
the final log server.  One might pass through 3 relays, the other 9.
There might be per-link encryption/decryption delays, congestion in
the syslog relay queues, etc.

In other words, there is nothing the final destination can *ever* do
about out of order arrivals, UNLESS it a) trusts timestamps from
clients and b) is prepared to do some kind of timestamp sorting.

I'm not sure the arrival sequence at the final destination has value,
unless you don't trust the client timestamp at all, in which case you
are conceding any chance to know "when" an event actually happened?
Or you use both timestamps to increase the "assurance" that things
really happened in the order you claim.

    MJR> Huh - weird idea - you _could_ keep a differential on the server and
    MJR> keep statistics about how inaccurate all the clocks on your syslog
    MJR> sources happen to be. ;) I suppose you could even learn the skews
    MJR> and compensate/adjust the times, but then you're trashing your forensic
    MJR> value completely.

Yup, tracking skew could be fun, but that's what NTP is for.  There
shouldn't be any skew.

    MJR> In other words: syslog is bad enough that you're not going to make it
    MJR> much better - may as well leave it alone. If you care about time, run
    MJR> ntp and leave it at that. You'll have "mark"s in the server's log files that
    MJR> are presumably ntp-syncd.

OK, is syslog hopeless?  (Which one?)  Do we need to go back and do a
third-gen protocol to solve this problem?  Is it worth it?

Defense in depth against time problems: NTP, multiple timestamps
(client, relay, relay, final), arrival sequencing, and ???

--tep
_______________________________________________
LogAnalysis mailing list
LogAnalysisat_private
http://lists.shmoo.com/mailman/listinfo/loganalysis