Archiving and Analyzing the NT Security Log

Windows NT thoroughly captures security events, but the OS doesn't provide many tools to track those events. Given the difficulty and time-consuming nature of manual event-log analysis, you might neglect Security-log analysis activities. But if you ignore these important tasks, you might lose security-event data or miss the signs of an attempted (and possibly successful) attack. In this final article of the NT Security log series, I describe several free or inexpensive tools that can help you archive, merge, and analyze your systems' event logs. (For information about the previous articles, see "Other Articles in This Series," page 82.) I also show how to import your logs into one Microsoft Access database so that you can write custom reports.

Archiving Event Logs
As I explain in "Introducing the NT Security Log," March 2000, you can keep only a limited history of events in the Security log. Regardless of the maximum log size and event-wrapping options that you use, you eventually need to clear the log or overwrite older events. I recommend that you use your job scheduler (e.g., the NT Scheduler service) and a batch-file utility to archive the Security log before each nightly tape backup. If you choose a log size that accommodates the average amount of recorded activity that occurs between backups, you'll have a contiguous Security log archive that dates back as far as your tape rotation permits.

To automate event-log archival, you need a batch-file utility that can import your Security logs into an output file. The following four tools have certain strengths and peculiarities; one of the four will likely suit your environment. (For information about other available tools, see Mark Joseph Edwards, "The Handy Security Toolkit Revisited," October 1999.)

Dumpel. The Microsoft Windows NT Resource Kit's Dumpel is a well-known utility that can dump NT's three event logs (i.e., Security, System, and Application) to an output file. Dumpel lets you specify the log to dump, an output file, and filtering criteria. The utility dumps the log only in text format, delimiting each record with a carriage return or line feed. To copy the local system's Security log to a file called sec_archive.txt, type

dumpel ­f sec_archive.txt 
­l security

Unfortunately, the utility doesn't let you dump an event log in the log's native .evt file format, which NT Event Viewer uses. Dumpel's inability to save .evt output files is this tool's primary flaw. However, you can use the utility's c parameter or t parameter to specify comma-delimited or tab-delimited columns, respectively. So ostensibly, you can easily import the files into a database such as an Access database, from which you can view and write reports. However, Dumpel's format for each event record's free-form description field doesn't match the Access parsing algorithm and causes conversion problems.

The description field is a series of text strings; each event ID has a different set of strings. Some strings are dynamic (i.e., different for each occurrence of the event ID). Others are static (i.e., identical for each occurrence). Figure 1 shows an example description of event ID 528. The only information that NT stores in the event log is the dynamic string—for example, Administrator, DOMAIN, (0x0,0x3779C), 7, User32, Negotiate, and TECRA. NT stores the static string (i.e., Successful Logon:, User Name:, Domain:, Logon ID:, Logon Type:, Logon Process:, Authentication Package:, and Workstation Name:) in a separate standard message file. The Event Viewer and other programs that dump event logs in text file format must merge the dynamic and static strings. This requirement presents no problem for events that native NT components generate because NT's standard message files are present on every NT system. However, when you use third-party drivers and applications to generate an event from a particular system, that event might display correctly only on that system because the application's static message is unavailable on other systems. In this situation, the event description notes that the message text is unavailable and displays only the event's dynamic data string. (For example, you might see only the dynamic data string when you view a Microsoft SQL Server event from a workstation that doesn't have SQL Enterprise Manager installed.)

A key aspect of event-log archiving is the need to collect logs from multiple systems. Many systems administrators prefer to keep all the systems' event logs in a central directory. Dumpel lets you use the ­s parameter followed by a computer's name to retrieve and dump a remote system's event logs.

EventSave. Frank Heyne Software's EventSave (which you can download free at http://www.heysoft.de/) copies all three event logs in .evt file format and thus addresses Dumpel's primary flaw. EventSave collects the event logs from each of your crucial systems and maintains the logs in a central archive. The program checks the recorded time of each event in each log, then sorts the events into one file per log per computer per month. The program uses the format year_month_computername_eventlogname for these files. For example, on a system with event logs that contain events only from April 2000, EventSave will produce three files: 2000_04_oraclesvr_security.evt, 2000_04_oraclesvr_system.evt, and 2000_04_oraclesvr_application.evt. When a destination file already exists (e.g., because you previously ran EventSave that month), the tool appends new events to the existing file so that regardless of how often you run EventSave, you end up with only one file per month.

You can use the tool's /A switch to automatically save the event logs of each system in a domain, or you can use the /C switch to specify one computer. (If you want a subset of the domain's systems, you must write a batch file that executes EventSave for each computer.) For example, to save server2's event logs to the eventlogs shared directory on server1, type

eventsave \\server1\eventlogs /Cserver2

If you don't specify an archive path, EventSave puts the archive files in the directory that is active; if you don't add a computer name after the /C switch, the program saves the archive files in the local system's event logs.

One warning about EventSave: The tool unconditionally clears the logs after saving them, so you can't keep a constant amount of activity in each system's logs. If this restriction is a problem for you, consider Frank Heyne Software's EventCopy, which functions like EventSave but doesn't clear the logs. To archive the logs and still keep a month of activity on each system, you can set your event logs to overwrite events older than 30 days, then run EventCopy daily to add new events to the central archive directory. Frank Heyne Software also offers EventSave+, which lets you specify an event log to save for each system. The vendor negotiates pricing for these two utilities on a case-by-case basis.

EventSave and its siblings use Win32 event-log-dumping APIs that save event logs only to the local computer's hard disk. To support remote saves across a network, EventSave instructs the remote computer to dump the log to its local \%systemroot%\system32\config directory, then the tool uses file sharing to copy that information to the specified output directory. The remote systems must run the NT Server service, and if you've disabled administrative shares, you need to share the boot drive's root and use eventsave's /S switch to specify the share to EventSave. The user account that you use to run EventSave also requires change access to \%systemroot%\system32\config, read access to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog Registry key, and rights to Manage Auditing and Security Log on each system for which the utility accesses event logs.

NTOLog. NT OBJECTives' NTOLog (which you can download as part of NTO Tools at http://www.ntobjectives.com/) also makes an .evt backup of your local and remote systems' event logs. The free product uses a date and time filename format (i.e., DD-MM-YY-HH-MM-SS) and an extension (i.e., .secbak, .sysbak, or .appbak) that depends on the type of saved event log. NTOLog lets you use the /sec, /sys, or /app switches to save only the Security, System, or Application log, respectively. For example, if you type

ntolog \\oraclesvr /sec

at 10:02:32 on April 3, 2000, NTOLog will create a file called 03-04-00-10-02-32.secbak in OracleSvr's C:\winnt\system32\config directory. You can also use the tool's /c switch to clear a log after saving it.

NTOLog doesn't let you choose where to put the output files; the tool puts the files in the C:\winnt\system32\config directory of the archived logs' system. This restriction can be a problem if that path is invalid on your system. NT OBJECTives plans to remove this hard-coded path, but until then you can use a binary file editor to modify the NTOLog executable. And although NTOLog can help archive and back up your event logs, the product doesn't offer a way to automatically distinguish and collect output files from remote systems. If you want to maintain a central event-log archive, you need to append a computer name to each output filename, then copy the output files to a central directory. I recommend that you use NTOLog if you want to dump event logs only in .evt format for inclusion in your backups; use EventSave, which produces a clean set of appropriately named monthly files for each system, if you want to maintain a central online archive.

ELDump. You might consider Jesper Lauritsen's ELDump (which you can download free at http://www.ibt.ku.dk/
jesper/eldump/) if you need to dump your event logs in text format but require more functionality than Dumpel offers. The product is especially useful for importing the logs into an Access or SQL Server database. ELDump dumps a system's current event logs or lets you read .evt files that you previously dumped using other utilities. The tool provides excellent flexibility for specifying which events to output (e.g., events for a particular time period or specific event ID). ELDump also provides control over the output data format, including the output file's date and time format.

Another notable feature is ELDump's method of handling each event record's free-form description field. To prevent the display problem that I described earlier, ELDump uses the remote system's message files when dumping a remote event log.

Merging Event Logs
In "Introducing the NT Security Log," I explain how NT's fragmented logging nature isolates each system's Security log and provides no way to assess security events for your entire network (e.g., scan for all failed logon attempts throughout the network). If you're responsible for multiple systems, you need a way to merge the saved event logs from all systems into one file from which you can track events for the network. If you want one .evt file that contains all your systems' Security logs, try Frank Heyne Software's Merge Eventlog Records (MER), which is available with the registered version of Report Event for Windows NT/2000. This utility imports the .evt files that EventSave creates and uses them to produce one output file. You can then use Event Viewer to view your entire network's security activity. You can specify a wildcard filename (which tells MER which log files to read) and a destination filename. You can use the /E switch followed by comma-delimited event IDs to specify the event IDs that you want the program to merge. For example, to scan all your computers' Security logs that EventSave archived in C:\events\ for May 2000 and write logon failure event ID 529 and event ID 539 to a new file (e.g., 2000_05_failedlogon_security.evt) in the default (i.e., active) directory, type

mer C:\events\2000_05*security
.evt 2000_05_failedlogon_security
.evt /E529,539

Or to create one file (e.g., securitymerged.evt) that comprises all the Security logs from EventSave's archived directory, type

mer C:\events\*security.evt securitymerged.evt

   Previous  [1]  2  Next