MARS 4.3.3 (2636) pulling logs off a windows 2003 server at 1 hour intervals. The MARS events seem to get timestamped in "clumps" at about 2-hour intervals e.g. 3000 events all timestamped within about a minute of 2:00, then nothing for a couple hours, then another 3 or 4000 events all timestamped within a minute or 2 of 4:00, etc. etc.
the logs on the windows box are all spread out across these "dead intervals" as expected - so it appears MARS is pulling the log and screwing up all the timestamps on the individual events as it parses them.
I have no experience with the Windows PULL process....but as a general rule, MARS applies its own timestamp when an event is received/collected. It doesn't matter when the event actually occurred according to actual raw message. The only exception I'm aware of is Cisco IDS alarms. For this reason, I would suggest moving to the push model with snare. Even with the push model, MARS applies it own timestamp...but it's only a second or two off instead of an hour.
Besides, if you're only collecting events every hour, you can't expect MARS to do much correlation with other events that were received 45 minutes ago. There's also the problem of an attacker clearing the event log. Every one of those events between when you last collected events and when the event log was cleared is gone.
definitely Matthew's responses here have been most helpful.
just to clarify - not having the windows events correlate at this point in time is not a huge issue (although that is supposed to be the purpose of the system). Right now I'd just light to get accurate logs with reasonably correct timestamps.
It amazes me that it would be designed this way - you're pretty much guaranteed that the logs (assuming you pull them) will have the wrong timestamp info, which in effect makes them useless overall.
re: correlation. I thought about that, and I think cross device correlation is overrated anyway. You'd still have correlation of events for the same device.
I agree regarding timestamps, it's pretty near pointless to collect logs and assign timestamps like MARS does using the PULL process. You would get event correlation within that device [sort of anyway, so long as the events that should be correlated don't span a collection boundry]. But, you can't even query them normally.
Can someone else using the PULL process confirm this behavior though? I was just guessing based on other observed behavior.
reply from Cisco indicates that the log pull should be parsing the windows event timestamp info and applying to MARS events as they're generated.
i replied that this isn't the observed behavior here.
only other scenario (suggested) is that the MARS box is busy (from other work, windows pulls, etc.) and possibly has intermittent problems logging into this windows box at certain intervals, somehow screwing up the events on MARS. but I don't see any 'winpull" type errors in the backend log at all. Another suggestion is related to the time sync on the boxes - apparently if they're off then log data can get fubar'd. But none of this seems to apply here or correlate (pardon the pun) with what's going on. Still confused.
Anyway, i'm going to try to migrate to push agent asap - meanwhile any other hints or suggestions appreciated - will see if TAC comes back with anything more
I did a little testing with the pull. It DOES look like MARS attempts to parse the time out of the message. so, something does appear to be broken in your situation. However, the raw message is typical for many of the non-syslog events in MARS...they're a cobbled up mess that don't look much like the original.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...