You might consider disabling the Audit logon events category on member servers because it generates events both for local SAM and domain-account logons without distinguishing between them and is largely redundant to Audit account logon events. The only value of enabling Audit logon events on member servers is that it lets you distinguish between interactive logons and connections from users elsewhere on the network.
If you want to track all logons from the server console, check for event ID 528 (Successful Logon) with logon type 2 and failed Audit logon events attempts with logon type 2. To track connections to a computer by a user elsewhere on the network, look for event ID 540 (Successful Network Logon), which signifies a network logon. Audit logon events also lets you determine how long the user was logged on. Note the logon ID, which you can find in the description of event ID 540 or event ID 528. Then look for event ID 538 (User Logoff) with the same logon ID. By using the same logon ID to tie the logon event (event ID 540 or event ID 528) to the logoff event (event ID 538), you can determine how long the session lasted.
If your account-lockout policy is set to automatically unlock accounts after a specified time period, you won't be able to detect lockouts as a result of users calling in to reset their passwords unless you check your logs for event ID 644 (User Account Locked Out). On DCs, event ID 644 signifies that a domain account was locked out; on member servers, it signifies that a local SAM account was locked out. This event is part of the Audit account management category, not the logon categories. You might want to monitor logons to servers and domains during unusual hours, which might identify suspicious activity (or just that someone is working long hours).
Important System Events
The Win2K Security log identifies several major system events that help you identify physical-access attacks and recognize abuse of administrator authority (for a list of important security events, see Table 2). Whenever someone clears the Security log, Win2K logs event ID 517 (The audit log was cleared) regardless of how the computer's audit policy is configured. This process can help you identify the person who cleared the Security log. If Audit system events is enabled, Win2K logs event ID 512 (Windows NT is starting up) when the system reboots. Reboots are important to security because Win2K systems are highly vulnerable to physical-access attacks while the OS is down. You might be able to compare event ID 512 with other information you might have, such as server-room entry and exit logs, to determine who was present when the server rebooted. If you enable Audit policy changes, Win2K will log event ID 612 (Audit Policy Change) when the computer's audit policy is changed. Event ID 612 records exactly which categories were enabled and disabled.
Incorrect changes to a system's time can wreak havoc on applications. To change the system's time, users must have the Change system time user right, which you can track by enabling Audit privilege use. Then, monitor for any occurrence of event ID 577 (Privileged Service Called) that specifies SeSystemTimePrivilege in its description.
Account Management
The Audit account management category lets you audit how administrators use their authority and monitor when they grant new access. On DCs, watch for event ID 642 (User Account Changed), which lets you monitor user-account-status changes or password changes. Because this event ID covers almost all types of user account changes, read the description to determine which changes were made on the user account. As Figure 3 shows, event ID 642's description clearly states the type of change, such as password reset or account enabled.
Event ID 624 (User Account Created) lets you keep track of new domain user accounts on DCs, but I recommend that you also monitor member servers for this event. Local SAM accounts are usually undesirable for security reasons because local SAM accounts aren't subject to the centralized controls and monitoring of domain accounts, and event ID 624 will help you keep a handle on local SAM accounts as well as detect intruder-created backdoor accounts.
Monitoring for new-member additions to a group is also important. On DCs, watch for event ID 632 (Security Enabled Global Group Member Added), event ID 636 (Security Enabled Local Group Member Added), and event ID 660 (Security Enabled Universal Group Member Added) to identify when new members are added to groups. Because SAMs allow only local groups, you can monitor just for event ID 636 on member servers. All three event IDs specify the group, new member, and user who made the change. As Figure 4 shows, event ID 632 reveals that user rsmith added Guest to the global group Domain Admins. If you want to detect unauthorized computers, use event ID 645 (Computer Account Created) to monitor when new computers are added to the domain.
File Access
The Audit object access category lets you track all types of access to files, folders, and other objects, such as printers and registry subkeys. Enabling this category will initially generate limited security events that are related to SAM maintenance. As soon as you enable this audit category, you'll see some object-access events in the Security log, even though you haven't specifically enabled auditing on any objects. To audit a file or folder, locate the file or folder in Windows Explorer and open its Properties page. Select the Security tab and click Advanced. In the Access Control Settings window, select the Auditing tab, as Figure 5 shows. Initially, the auditing entries list will be empty. Click Add, select a user or group whose access you want to audit, then click OK to open the Auditing Entry window. You can add any combination of users or groups, but I recommend simply using Everyone. Select the types of access you want to audit, then click OK.
Be careful not to turn on auditing for all types of access, especially successful read access. Too wide an audit policy can generate a crippling number of security events that will slow your system to a crawl and fill your log with useless noise. For the same reason, limit the number of folders for which you enable auditing. For example, enabling auditing on the system drive root for all types of access is a recipe for disaster.
Depending on the type of information you're trying to protect, you might want to detect unauthorized attempts to read a file or track anyone who might have changed a file. To detect unauthorized read attempts, enable auditing for failed Read data attempts. To detect file changes, enable auditing for successful Write data and Append data attempts. Be aware, however, that Win2K audits only potential changes. For example, if Bob opens a Microsoft Word document for write access but immediately closes the file without making any changes, Win2K will log only the fact that Bob successfully opened the file for write access. Windows 2003 solves this problem by recording a specific event the first time a user actually writes to an open file. You can also detect when an administrator changes file permissions by monitoring successful Change permission attempts. When a user accesses a file by using a type of access that you've enabled for auditing, Win2K generates event ID 560 (Object Open), which identifies the user, file, and type of access granted or denied. For example, the error code that Figure 6 shows signifies that Bob tried to open a file for read access when he didn't have access to that file. You can deduce that he didn't have access because the event is a failed object-access event. You know he tried to open the file for read access because ReadData is listed under Accesses.
Scanning Logs
The events described in this article constitute the most important and easily recognized security events in Win2K security logs. Win2K uses the Microsoft Management Console (MMC) Event Viewer snap-in to provide minimal functionality for scanning logs for the specific events you enter. You can use the Event Viewer snap-in to filter by event ID and other types of information. Select the Security log in Event Viewer, right-click, and select View, Filter.
Event Viewer doesn't let you filter events based on values in the event descriptions (e.g., logon ID or other codes), which is unfortunate because the description contains much of the information that you need to identify important events. However, Event Viewer does provide a way to scan filtered events for values in the description. After you set up the filter, right-click the Security log again and select View, Find. You can find events based on several fields, including the description. The Find Next button lets you find one event at a time. Another quick and dirty way to scan a log is to save it to a tab-delimited text file, then open the file with Microsoft Excel. However, both these methods let you scan only one log at a time, which isn't helpful if you have to monitor multiple systems.
Third-Party Tools
Some third-party tools, such as GFI LANguard Security Event Log Monitor, Symantec Intruder Alert, and Adiscon's EventReporter, can merge logs from multiple computers into one database and provide aggregated reports and alerts. Alternatively, you might try using SystemTools.com's free DumpEvt utility to build your own solution. DumpEvt comes with a Microsoft Access database template that can import events from many different computers. You can then use the database to design your own reports to monitor your network.
End of Article
Prev. page
1
[2]
next page -->
