RE: [logs] Windows Event Log Analysis

From: Buck Buchanan (lbuchanaat_private)
Date: Wed Jan 08 2003 - 08:17:52 PST

  • Next message: Rainer Gerhards: "[logs] syslog/tcp (selp)"

    "Eric Fitzgerald" <ericfat_private>01/07/2003 07:46 PM writes:
    >Are you using event viewer or your central syslog collection tool to
    >determine whether the process tracking events are being generated?
    No, I am using Microsoft's Event viewer.  I do not have access to the
    central log server except by submitting requests for log contents.
    >I'm not claiming that a bug does not exist, but I have never seen it.
    I have been poking around event logs for a couple of years and had never
    noticed it, but until the other day, I did not have a need to look for it.
    >1) Windows event logging is "reliable"- the RPC call to the eventlog
    >service doesn't return until the data is committed to disk.  However,
    >disk  write caches could affect this.
    Parts of it may be reliable, but event logging is far from being a single
    monolithic entity.  The event logger can only log what it is sent, or it
    generates internally.  If other parts of Windows fails to make that RPC
    call, that event will not be logged.
    >2) Windows auditing- that is, security event logging- does have internal
    >queues.  It is possible to lose events during a power down (even a
    >graceful one) if the event log service stops before LSASS finishes
    >flushing these queues.
    During this whole exercise, only the NT has been rebooted.  The 2K system
    is configured to go into standby after 2 hours of being idle.  The behavior
    I have been commenting on is not caused by power failures.
    >3) Due to queuing there might be a time lag between audit generation and
    >audit appearing in the log.
    I have noticed this, but I have never noticed that events are recorded out
    of order.
    >4) Event Viewer does not auto-refresh- press F5.
    I have been using the "Refresh" menu item.
    >5) An "everything on" audit policy is not unreasonable, but will affect
    >performance.  I personally recommend turning off "privilege use" do to a
    >low signal/noise ratio, but it's up to you.  Do NOT turn on the options
    >in security policy "audit base system objects" and "crashonauditfail".
    The NT has had this configuration for more than two years, and the 2K since
    I reinstalled the OS last May.  This has never been a problem on either
    system.  So far this year, I have logged 8 "privilege use" events on the 2K
    system and about 40 on the NT (mostly due to Event Log refreshes while
    researching this issue).  I have "audit base system objects" and
    "crashonauditfail" disabled on the 2K system and these registry keys do not
    exist on the NT.
    >Please verify for me the configured maximum size of your security log.
    >If it is above 128MB then please reduce it until we determine the source
    >of your problem.
    10MB on the 2K and 4MB on the NT.
    >How are you determining whether or not the process termination audit is
    >missing?  In other words, what method are you using to correlate the
    >events?  I would suggest, on Windows 2000, you use the DUMPEL utility
    >from the Windows 2000 Resource Kit to dump all event 592 and 593 to a
    >CSV text file, and then use findstr or grep to find the events of
    >dumpel -l security -m security -e 592 593 -c > process.csv
    >findstr "myprocess.exe" process.csv > event592.txt
    >Then to find the process termination events, match the Process ID field
    >between the 592 event and the 593 event that occurs next in the log
    >chronologically (the PID can be re-used after a process is terminated).
    I had been using the event viewer.  Using dumpel and Excel, I see the same
    missing process termination messages.
    As mentioned in earlier postings, this is not something new.  Frank Heyne
    has this problem mentioned at least twice on his web site.
    B Cing U
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Wed Jan 08 2003 - 11:29:11 PST