Why not spool eventlog entries to a syslog collector, so you can perform event correlation and do better event management and retention? http://www.intersectalliance.com/projects/BackLogNT/index.html Dale ====================================== "SUCCESS THROUGH TEAMWORK" 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 Hi, This is a response to postings by H C and Frank Heyne. FH> > I have both systems configured so that the event logger logs everything 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 http://www.heysoft.de/nt/eventlog/faqa1.htm and the documentation for his r592.exe both point out that Windows event logging is not reliable. For my NT I don't think that "No Overwrite" or "Overwrite after x days" is 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 log 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 up (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 a 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 creation description: 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 was TDImon was reporting that a process that had supposedly terminated was continuing to communicate with remote systems. The bash shell the program had been run from, Task Manger, pslist and fport all agreed that the process had terminated, yet TDImon was still reporting the process sending and receiving packets. I would consider this to be a quirk. This lead me to looking at the event log and not finding the process termination message and the "whole new education". It turns out that the system process also 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 find 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 on Microsoft Windows is not reliable. Frank Heyne's FAQ points out that Arne Vidstrom's WinZapper allows for selective deletions from the event log. For more information see http://www.ntsecurity.nu/toolbox/winzapper/. B Cing U Buck _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis _______________________________________________ LogAnalysis mailing list LogAnalysisat_private http://lists.shmoo.com/mailman/listinfo/loganalysis
This archive was generated by hypermail 2b30 : Wed Jan 08 2003 - 08:15:51 PST