To maintain a secure network, you must audit server and workstation activity and examine event logs frequently for signs of intrusion or unexpected events. On a network with only one or two servers, you can examine log files manually. However, when you're the network cop for more than a couple of servers, the manual process is tedious and time-consuming.
Administrators typically monitor the success and failure of logon events, changes to local accounts, and changes to local security policy. Although logon success events can help you reconstruct a specific user's activities, you look primarily for events that document a consistent pattern of failed logons or failed attempts to change the local security policy. The same is true for events you monitor in the System log—you worry about a server when you see an event documenting a service that couldn't log on or couldn't perform as expected (e.g., constant complaints from the browser that it can't retrieve a list of servers from the browse master, messages that the Windows Time Service was unable to locate a Network Time Protocol—NTP—time server).
If you support a global network, you probably have a budget for tools that automate these repetitious sifting and sorting tasks. However, in small and midsized businesses, you must often expend time rather than dollars to reduce how long scanning log files for critical events takes. The Microsoft Windows 2000 Server Resource Kit has two great utilities—AuditPol and Dumpel—that help you expedite changes to security auditing and reduce the time it takes to isolate critical events in the system event logs.
AuditPol: The Security Audit Tool
For this article, I assume that you know how to enable security auditing with either Group Policy or Local Security Policy. (If you need a quick refresher, read Randy Franklin Smith, "Auditing Windows 2000," http://www.secadministrator.com, InstantDoc ID 9633.) As you know, each time you use Group Policy or Local Security Policy to adjust security audit settings, you must force a policy refresh to update the settings on each target system. When you use the Microsoft Management Console (MMC) Local Security Authority snap-in to modify security audit settings, you must remember to manually refresh the policy by typing
secedit /refreshpolicy machine_policy
at a command prompt. If you don't refresh the policy, the system remembers but doesn't activate the new audit settings until the next scheduled Group Policy refresh or until you reboot the system (rebooting forces a refresh of the security policy). When you suspect that a system is under attack, you need to implement security audit changes immediately, without manually forcing or waiting for a scheduled refresh to occur. For more information, see "Using AuditPol to Change Security Audit Settings Immediately," http://www.secadministrator.com, InstantDoc ID 23684.
Getting started with AuditPol. The AuditPol tool lets you immediately change the audit criteria on a local or remote system. You can use AuditPol to display current security audit settings, to enable or disable security auditing, and to adjust the audit criteria for nine categories of security events. (Because AuditPol doesn't identify audit categories with the same names you see in the MMC Group Policy snap-in or the MMC Local Security Policy snap-in, I include the snap-in category name in parentheses.)
- Account events (account logon events) monitor logon attempts on a domain controller (DC).
- Directory (directory service access) is a generic category that you enable to audit access to DC objects.
- Logon events (logon events) monitor logon attempts on the local system.
- Object access (object access) is a generic category you enable before you can track access to a specific file, folder, or shared resource.
- Policy events (policy change) track changes to the local security policy.
- Privilege events (privilege use) monitor operations that grant elevated privileges to user or group accounts.
- Process (process tracking) is a generic category you enable to audit access to a specific process.
- SAM events (account management) monitor changes to individual or group accounts on the local system in the SAM database.
- System events (system events) include system and service startup and shutdown, messages from the browser, RRAS, or the Win32 Time Service.
AuditPol uses straightforward syntax:
auditpol \[\\computer\] \[/enable | /disable\] \[/category:type\] \[/category:type\] ...
You can type
at a command prompt to display command-line Help. The computer-name argument, \\computer, governs the system on which AuditPol runs. If you omit the computer-name argument, the utility runs on the local system. To run the command on a remote system, you must enter the name of the remote system. You can identify the remote system in several ways—for example, the three commands
auditpol \\machine1 auditpol \\machine1.mydomain.com
all display the security audit settings on Machine1 with IP address 10.1.1.42. As Figure 1 shows, the first line of output from any of these commands indicates whether security auditing is enabled. The remainder of the output reflects the system's current audit settings.
The /enable argument turns on security auditing. Because /enable is the default, you can safely omit it when you add or remove categories or alter the type of events you want to audit. To display the current security audit settings, use AuditPol without arguments and with or without a computer name.
The /category:type argument lets you enable security auditing by category and event type. You can use up to nine /category arguments in the command, each argument correlating to one of the nine categories of security audit events in Group Policy's computer configuration\windows settings\security settings\local policies\audit policy container and in Local Security Policy's security settings\local policies\audit policy container. Combining /category arguments lets you fine-tune the events you want the Security log to record. For each category, you can specify the type of events the system should record: success, failure, all (success and failure), or none.
Here are two equivalent commands that enable security auditing on a DC named Machine1 for all types of system, domain logon, policy, and Directory Service (DS) access events:
auditpol \\machine1 /enable /system:all /account:all /policy:all /directory:all
auditpol \\10.1.1.42 /system:all /policy:all /account:all /directory:all
auditpol \\machine1 /privilege:none
disables security audit logging for privilege events only but leaves all other settings intact. You don't enter the /disable argument to disable a specific category of event logging: You simply specify none for the type of events the system should log.
Disabling security auditing. The /disable argument sets the audit type to none for all nine categories of events. When you use the command AuditPol /disable, don't let the utility's feedback mislead you. For example, when you use the command
auditpol \\machine1 /disable
you'll see output similar to the output that the top half of Figure 2 shows. The first line of output from this command contains the text (0) Audit Disabled, followed by a list of the previously active security audit settings. Despite this seemingly misleading output, AuditPol correctly sets the audit type to none for all nine categories.
You can eliminate this misleading output by using a slightly different version of the above command:
auditpol \\machine1 /system:none /logon:none /policy:none /account:none /disable
This command updates the type of audit for four categories to none, then disables auditing. As you see in the lower half of Figure 2, the output accurately reflects the status of all security audit categories.
You can verify that AuditPol is working correctly in two ways. First, if you're auditing policy changes, look in the Security log for a record with a source of Security and event ID 612 (audit policy change) for a confirmation of the changes similar to the confirmation that Figure 3 shows. Second, you can display the active settings with the Local Security Policy snap-in. You might need to refresh the security settings; if so, right-click Security Settings in the left pane and select Reload from the drop-down menu.
Here is a sequence of commands that you can use to familiarize yourself with AuditPol.
auditpol \\machine1 auditpol \\machine1 /logon:all /sam:all /system:all /account:all /policy:failure auditpol \\machine1 /disable
(Of course, you need to substitute a valid computer name for the \\machine1 argument. If you omit the computer name, AuditPol runs on the local system.) The first command displays the current security audit settings. The second command enables auditing for five categories of events. The third command disables auditing for all categories and events.
Monitoring Critical Events with Dumpel
Dumpel is a command-line tool you can use to extract events from the System, Security, or Application log on a local or remote system. With suitable tweaking in a script and a quick entry in the Win2K Task Scheduler, you can run Dumpel at preset intervals (e.g., several times a day, once a week) based on your current perception of system stability and network vulnerability.
I like Dumpel because it's faster and cleaner than the GUI-based alternatives. You can run Dumpel more quickly than you can run the Windows NT Event Viewer on a local or remote system. Dumpel is cleaner because, although you can create a custom MMC console that incorporates the Event Viewer on multiple systems, you still must wade through thousands of entries manually. Although you can use the filter option in Event Viewer to reduce the number of events you must scan, the filter doesn't let you select multiple events by event ID, which makes the GUI version time-consuming. Dumpel's big advantage is its powerful set of command-line arguments that extract only those events that signal problems. Dumpel has two obvious uses: to generate a quick snapshot of key system or security events and to monitor the success or failure of regularly scheduled production or backup jobs.
Getting started with Dumpel. Dumpel's syntax is complicated, but the arguments give you a great deal of flexibility in controlling which events to extract and the amount of data you want to view for each event. The syntax is
dumpel -f file \[-s \\computername\] \[-b\] \[-l eventlog \[-m source\]\] \[-e EventID1, EventID2, ...\] \[-r\] \[-t\] \[-c\] \[-d x\]
The -f file argument specifies the output file in which Dumpel will store the events you monitor. As with most Win2K commands, you can use the > redirect operator to save the utility's command-line output (stdout) to the device, directory, and filename you choose. If you redirect the output, you don't need the -f file argument.
The -l eventlog argument functions in two ways. When you extract events from an active event log, -l identifies the type of log file you want Dumpel to examine: security, system, or application. This argument is required and defaults to the Application log. If you run Dumpel on a saved copy of an event log, (i.e., an event log you previously saved in .evt format), use -l to specify the name of the saved event file. I explain below how to extract records from a saved event-log file.
The -s system argument instructs Dumpel to access the event log you indicate with the -l argument on a remote system. If you omit the -s system argument, Dumpel accesses the event log you specify with -l on the local system. You can identify a remote system with a NetBIOS name, a Fully Qualified Domain Name (FQDN), or a TCP/IP address. For example, each of these three equivalent commands extracts all events in the Security log on a remote system named Machine1:
dumpel -s machine1 -l security >%temp%Machine1SecLog.txt dumpel -s \\machine1 -l security >%temp%Machine1SecLog.txt dumpel -s 10.1.1.26 -l security >%temp% Machine1SecLog.txt
(When you type Dumpel commands at a command prompt, don't include line breaks.) Dumpel writes all events to the output file machine1seclog.txt in the directory that the %temp% environment variable specifies.
Isolating key events. The output from the above commands is a text-file version of all the records in the Security log. Examining that output is neither cleaner nor faster than scrolling through the Security log with Event Viewer. To filter the log for specific events (e.g., domain or local account logon failures, changes to local security policy), you need to fine-tune Dumpel's output. Two command-line options assist in this task: the -m source argument and the -e EventID1, EventID2, ... argument.
The -m source argument selects records by the source OS component responsible for posting the event. This argument can be any of the components that appear in the Source column you see when you display the Security log in Event Viewer. So, for example, in the Security log, the source must be one of the following: DS, Local Security Authority (LSA), Network Dynamic Data Exchange (NetDDE) Object, Service Control (SC) Manager, Security, SAM, or Spooler. Dumpel would be more useful if you could specify multiple sources or, alternatively, specify a category such as Logon/Logoff on the command line. However, the version in Microsoft Windows 2000 Server Resource Kit Supplement One accepts one source only, just like the Filter tab in an Event Viewer log's Properties dialog box.
The -e EventID1, EventID2, ... argument selects records that match any of the specified event IDs. You can enter up to 10 event IDs. To effectively screen event records, you need to know exactly what you're looking for, preferably by source and event ID.
For example, the Security component of the OS writes logon failure events. You'll find at least two types of logon-failure event IDs in the Security log: event ID 529 (unknown username or bad password) and event ID 537 (the Netlogon component isn't active). The command
dumpel -s machine1 -l security -m security -e 529 537 >%temp%\Logfails.txt
extracts all events in the active Security log that match either of the logon failure event IDs. Notice that the event IDs are separated by spaces, not commas. The partial list that Figure 4 shows contains too much information on each line to let you quickly scan the file. In the section "Refining the Output," I show you how to reduce the data line. (For a list of event IDs for failed logons, see Randy Franklin Smith, "Tracking Logon and Logoff Activity in Win2K," February 2001, InstantDoc ID 16430.)
Now, suppose you want to examine logon failure records every day. Simply add the -d 1 argument, which instructs Dumpel to select records that match the source and event IDs that were written for the previous day. If you want to dump events weekly, add the argument -d 7.
This command extracts logon-failure records from four systems, Machine1 through Machine4:
for %i in (machine1, machine2, machine3, machine4) do dumpel -s %i -l security -m security -e 529 537 >>%temp%\LogFails.txt
The >> redirection operator appends the output of all four Dumpel reports to the file LogFails.txt.
To create a separate output file for each system (i.e., Machine1Logfail.txt or Machine2Logfail.txt), change the output file specification to
To run this command now, replace the names Machine1 through Machine4 with valid computer names on your network.
Reporting on a saved event log. By default, Dumpel examines and extracts records from the active event logs. Alternatively, you can save an active event log as an .evt file and direct the utility to report on the contents of the saved file. When you direct Dumpel to extract records from a saved event-log file, you need two arguments: -b (backup log) tells Dumpel to operate on a backup log file (not the active one), and -l (backup log file name) identifies the pathname of the saved file. The command
dumpel -b -l DoormanSecLog.evt -m security -e 529 537 >%temp%\LogFails.txt
extracts account and local logon failure records from a saved Security log with the name DoormanSecLog.evt.
Refining the output. Use the /format argument to include only fields of interest rather than all the text associated with events you want to isolate. The /format argument accepts a string of case-sensitive alpha-betic characters that identify output fields. Dumpel outputs the fields in whatever order you place them in the string. The format fields you can manipulate are
- d - date
- t - time
- T - event type (success or failure)
- C - event category
- I - event ID
- S - event source
- u - user
- c - computer
- s - strings (event message text)
By default, Dumpel outputs event records with the format dtTCISucs (/format dtTCISucs). This order produces one line of output per event formatted as follows:
date (d)—time (t)—event type (T)—event category (C)—event ID (I)—event source (S)—user (u)—computer (c)—strings (s)
With logon failures, you're primarily interested in the computer and the account that caused the logon failure. An alternate format places important information at the beginning of each line. You instruct Dumpel to format records this way with the argument /format dtIucTCSs.
date (d)—time (t)—event ID (I)—user (u)—computer (c)—event type (T)—event category (C)—event source (S)—strings (s)
To save additional time, you can omit the field name in the /format argument to reduce the output to only a few columns. With logon-failure records, the workstation name and account appear in the event-log message text. To generate a one-line report for each logon failure that contains only the date and time, the event ID, and the message text, use the argument /format dtIs as follows:
for %i in (machine1, machine2, machine3, machine4) do dumpel -s %i -l security -m security -e 529 537 581 /format dtIs>>%temp%\LogFails.txt
If you add /format dtIs to the command line that extracts logon-failure records on multiple systems, in moments, you have an output file that concisely documents all known logon failures (assuming the list of event ID's covers all known logon-failure events).
Figure 5 shows the output this command produces; because the data is minimal, you need only a minute or two to scan the output and decide whether you have a problem. Figure 5 shows a problem that occurred a couple of years ago.
OS components write events to the event log in different formats. Sometimes important information is in the event-log header and sometimes in the message text. To generate minimum output, use Event Viewer to review carefully the information you want to extract for each event and format Dumpel's output accordingly. In some cases, you might want to completely suppress the output of the event message text. If so, use the -ns (no strings) argument.
By default, Dumpel creates a space-delimited output file. If you prefer to load the output report into a spreadsheet, Dumpel can create either a tab-separated file (the -t argument) or a Comma Separated Value (CSV) file (the -c argument).
Let AuditPol and Dumpel Help You Monitor System Security
If you haven't looked at the Win2K resource kit recently, you might want to resurrect it from the archives and test-drive AuditPol and Dumpel. Although I've focused on extracting data from the Security log, Dumpel works equally well on the System and Application logs. Because these utilities modify security audit settings and access Security logs, I recommend that you restrict access to users who are authorized to perform these types of operations.
After you're comfortable with each tool, you can write a script that invokes the utility with arguments that reflect the names of the machines and the events you want to monitor. If you're good with batch files or VBScript, you can write a pretty sophisticated script that does exactly what you need. Then, schedule your script to run daily or weekly and email the output to you. In a few hours, you can recoup the hours spent in the manual version of this task, which frees up time for more productive, or at least more intellectually challenging, activities.