RE: [logs] Windows Event Log Analysis

From: Drew, Dale (Dale.Drewat_private)
Date: Tue Jan 07 2003 - 14:48:48 PST

  • Next message: Rainer Gerhards: "RE: [logs] Syslog payload format"

    Why not spool eventlog entries to a syslog collector, so you can perform
    event correlation and do better event management and retention?
    Dale Drew
    Director, Global Security/AAA Engineering & Architecture
    Level(3) Communications, LLC
    720-888-2963 | dale.drewat_private
    -----Original Message-----
    From: Buck Buchanan [mailto:lbuchanaat_private] 
    Sent: Tuesday, January 07, 2003 1:31 PM
    To: loganalysisat_private
    Subject: RE: [logs] Windows Event Log Analysis
    This is a response to postings by H C and Frank Heyne.
    FH> > I have both systems configured so that the event logger logs
    FH> > that is sent to it.  Both systems have the logs set to overwrite.
    FH> IMHO, this is not a good idea.
    FH> You should be aware what the system has to do in overwrite mode *for
    FH> every single event* when the log is full:
    FH> - search the oldest event
    FH> - check whether the new event is larger than the oldest event
    FH> - if yes, search the second oldest event
    FH> - check again, until enough space for the new event is found
    FH> - write the new event
    FH> - write eventlog footer after new event
    FH> - write updated information into eventlog header
    Agreed.  However, on an idle system that should not be an issue.  Frank
    Heyne's FAQ and the
    documentation for his r592.exe both point out that Windows event logging
    not reliable.
    For my NT I don't think that "No Overwrite" or "Overwrite after x days"
    a good idea. I have NT Syslog forwarding all events to a central syslog
    host.  If I need to see overwritten events, I put in a request for my
    entries.  I really need to get my 2K system forwarding its event logs.
    With the exception of shutting the machine down when the event log fills
    (which is a denial of service attack waiting to happen) log entries are
    going to get lost.
    HC> Could you dump the audit config w/
    HC> auditpol.exe, and post that?  It would certainly be
    HC> more helpful and instructive.
    C:\>auditpol \\c111753
    Running ...
    (X) Audit Enabled
    System                    = Success and Failure
    Logon                     = Success and Failure
    Object Access             = Success and Failure
    Privilege Use             = Success and Failure
    Process Tracking          = Success and Failure
    Policy Change             = Success and Failure
    Account Management        = Success and Failure
    Directory Service Access  = Success and Failure
    Account Logon             = Success and Failure
    HC> Unfortunately, whatever identifier the EventLog
    HC> assigns to a process creation, it does NOT use the
    HC> same identifier when the process terminates.  Do you
    HC> get ANY process termination log entries at all?
    I have no termination events.  Before the reboot I ran arp four times in
    row and had four process creation events and no termination events.
    HC> When looking for corresponding termination events,
    HC> what exactly are you looking for?  Are you just
    HC> looking for any number of creation events to match the
    HC> same number of termination events, or are you looking
    HC> at particular fields in the EventLog entry?
    I am looking at particular fields.  For example here is a process
    A new process has been created:
          New Process ID:   1204
          Image File Name:  \cygwin\bin\ls.exe
          Creator Process ID:     960
          User Name:  lbuchana
          Domain:           C111753
          Logon ID:         (0x0,0x7D68)
    and here is the corresponding process termination description:
    A process has exited:
          Process ID: 1204
          User Name:  lbuchana
          Domain:           C111753
          Logon ID:         (0x0,0x7D68)
    The key fields are the New Process ID, Image File Name, and Process ID
    along with the Date and Time fields.  What I was looking for originally
    TDImon was reporting that a process that had supposedly terminated was
    continuing to communicate with remote systems.  The bash shell the
    had been run from, Task Manger, pslist and fport all agreed that the
    process had terminated, yet TDImon was still reporting the process
    and receiving packets.  I would consider this to be a quirk.  This lead
    to looking at the event log and not finding the process termination
    and the "whole new education".  It turns out that the system process
    had the port open and it was handling the communications.
    HC> Sometimes when I review the lists, the "quirks" that
    HC> are identified aren't really "quirks" at all, just
    HC> normal operations for the operating system
    HC> environment, and most usually something that the
    HC> poster thinks 'should' happen, rather than what really does.
    Good point.  My perspective is primarily from a UNIX view point and I
    Windows to be a large collection of quirks ;-).
    FH> This seems to be "normal behaviour",...
    OK, so this is not a quirk but normal Microsoft behavior.  My point in
    starting this thread was simply to raise peoples awareness that logging
    Microsoft Windows is not reliable.  Frank Heyne's FAQ points out that
    Vidstrom's WinZapper allows for selective deletions from the event log.
    For more information see
    B Cing U
    LogAnalysis mailing list
    LogAnalysis mailing list

    This archive was generated by hypermail 2b30 : Wed Jan 08 2003 - 08:15:51 PST