At 06:09 PM 11/2/00 -0800, Carson Gaspar wrote:
>If I want to know message sequencing, I'll log them all to the same box. I suppose
>someone might want to know message sequencing between boxen, but that forces 2
>counters, and I don't know that the incremental benefit is worth it. I'm not
>violently against it, but I see no reason to provide a solution to what is inherantly
>a "Doctor it hurts when I do this! Then don't do it!" kind of problem.
Hi Carson,
It's not entirely sequencing. Sequencing could be done well enough through
the inspection of the timestamp. As you say, the more intelligent machines
should have it while the less intelligent machines should be configured to
send everything to a single log host. Beyond sequencing, a pri-counter
-or a counter associated with a loghost or file- may indicate the loss of
messages.
I'm thinking of this case. I have 2 collectors receiving messages from
mymachine. mymachine sends auth messages to collector 1, and other event
messages to collector 2. Let's say that we only have a counter associated
with messages going to each device. I look back after a long day and
find the following.
In collector 1:
=========================================================================
mymachine time_1 authentication failed for smith on port1 seq=1
mymachine time_2 authentication failed for smith on port1 seq=2
mymachine time_3 authentication failed for smith on port1 seq=3
mymachine time_4 authentication failed for smith on port1 seq=4
mymachine time_6 authentication failed for smith on port1 seq=5
mymachine time_7 user smith logged in on port1 seq=6
===end===================================================================
and then in collector 2:
=========================================================================
mymachine time_5 interface 1 state changed down seq=1
mymachine time_8 interface 1 state changed up seq=2
===end===================================================================
So it looks like: the hacker started guessing passwords, the interface
went down, the hacker got in, and finally, the interface came back up.
All of that can be seen by comparing the timestamps.
Let's say that we had a system counter and a counter for each output
as well. The following could be received.
In collector 1:
=========================================================================
mymachine time_1 authentication failed for smith on port1 seq=1 sys#=400
mymachine time_2 authentication failed for smith on port1 seq=2 sys#=401
mymachine time_3 authentication failed for smith on port1 seq=3 sys#=402
mymachine time_4 authentication failed for smith on port1 seq=4 sys#=403
mymachine time_6 authentication failed for smith on port1 seq=5 sys#=405
mymachine time_7 user smith logged in on port1 seq=6 sys#=406
===end===================================================================
and then in collector 2:
=========================================================================
mymachine time_5 interface 1 state changed down seq=1 sys#=404
mymachine time_8 interface 1 state changed up seq=2 sys#=495
===end===================================================================
At that point, I would think it to be a good idea to find out what
happened between sys#=406 and sys#=495. They may be in other files
or they may have been deliberately suppressed. The timestamps would
not be able to indicate how many messages happened within a timeperiod.
At best, the operator would be grabbing everything within a start-stop
timeperiod with hopes that he/she got everything. With the sys# counter,
the operator would know which messages to get and would know if she/he
didn't get all of them.
Looking at it from another angle, the use of both counters could
give this example as well.
=========================================================================
mymachine time_1 authentication failed for smith on port1 seq=1 sys#=500
mymachine time_2 authentication failed for smith on port1 seq=2 sys#=519
mymachine time_3 authentication failed for smith on port1 seq=3 sys#=538
mymachine time_4 authentication failed for smith on port1 seq=4 sys#=557
mymachine time_6 authentication failed for smith on port1 seq=5 sys#=576
mymachine time_7 user jones logged in on port1 seq=8 sys#=595
===end===================================================================
I would have to be very suspicious of the missing records - seq=6 and
seq=7. I would want to find the records of sys#=577 through sys#=594
which may be on other collectors as well. ..or they may have been
deliberately suppressed.
All in all, I think that the use of multiple counters may be beneficial.
That being said, I'm very willing to back off of that and support a
single counter if any of:
- most people on this list think that multiple counters won't be used by
anyone for any effective purpose,
- we can't come to some agreement about how they will be defined or
associated with either a pri or collector-logfile,
- anyone can show that their use would be detrimental or would lead to
confusion of the operators viewing them, or
- that it would be harder-than-nails to attempt to implement this
scheme.
As always, thoughts and comments will be appreciated.
Thanks,
Chris
