Securing Windows 2000 Server

In any secure environment, you should actively monitor for intrusion and attack. It would be counterproductive to put secure systems in place and then not perform any auditing, based on the assumption that you will not be attacked.

There are a number of reasons why monitoring and auditing for intrusion are very important. These reasons include the following:

This chapter shows how to audit your environment to give you the best chances of spotting and tracing an attack, and looks at monitoring for intrusion—including the use of intrusion detection systems—software specifically designed to spot behavior that indicates an attack is occurring.

On This Page

	Auditing
	Monitoring for Intrusion and Security Events
	Summary

Auditing

As part of your overall security strategy, you should determine the level of auditing appropriate for your environment. Auditing should identify attacks, either successful or not, that pose a threat to your network, or against resources that you have determined to be valuable in your risk assessment.

When deciding how much to audit, you should bear in mind that the more you audit, the more events you generate, and the more difficult it can be to spot critical events. If you are doing extensive auditing, you should strongly consider using additional tools, such as Microsoft® Operations Manager (MOM), to help you filter events that are of greater importance.

Audit events can be split into two categories: success events and failure events. A success event indicates that a user has successfully gained access to a resource, whereas a failure event shows that they tried, but failed.

Failure events are very useful in tracking attempted attacks on your environment, but success events are much more difficult to interpret. Although the vast majority of successful audit events are simply indications of normal activity, an attacker who manages to gain access to a computer will also generate a success event. Often, a pattern of events is as important as the events themselves. For example, a series of failures followed by a success may indicate an attempted attack that was eventually successful.

Wherever possible you should combine audit events with other information you have about your users. For example, if users leave on vacation, you may choose to disable their accounts while they are away, and audit for them when they are re-enabled.

How to Enable Auditing

Auditing is enabled using Group Policy, at the site, domain, organizational unit (OU), or local computer level. You will find the audit policy settings in:

Computer Configuration\Windows Settings\
Security Settings\Local Policies\
Audit Policy

Generally, you should implement auditing at a high level in the Active Directory® directory service hierarchy, which will help maintain consistency in your auditing settings. Contoso implemented auditing at both the Member Server and Domain Controller OU levels. For details about how this auditing was done, see Chapter 6, "Hardening the Base Windows 2000 Server."

You may have servers that you have chosen to keep separate from the domain. Auditing can be configured on these computers by editing Group Policy for the local computer, or by using the Auditpol.exe utility in the Windows 2000 Server Resource Kit.

Note   To access Group Policy for a local computer, start the Microsoft Management Console (MMC) and then add the Group Policy snap-in, which will make the Local Computer the focus of the snap-in.

Defining Event Log Settings

Every event generated by auditing will appear in Event Viewer. You should determine how event logs will store the events that are generated. Each of the settings can be defined directly in Event Viewer, or in Group Policy. For this guide, we have defined Event Viewer settings in Group Policy. For details of recommended settings, see Chapter 6, "Hardening the Base Windows 2000 Server."

If you remove the Event Viewer settings from Group Policy, you can instead define them directly in Event Viewer. However, it is recommended that you define your Event Viewer settings in Group Policy to ensure consistent settings across similar computers.

In Contoso's environment, Group Policy is not configured to shut down the computers in the organization if the security log reaches capacity. Rather, the computers are configured to overwrite event logs as needed.

Events to Audit

Microsoft Windows® 2000 provides several categories of auditing for security events. When designing your enterprise audit strategy, you will need to decide whether to include the following categories of security audit events:

The following sections detail some of the more common event IDs that are returned when auditing is enabled for specific categories.

Note   Tools used to search and collect event log information are discussed in the "Passive Detection Methods" section later in this chapter.

Logon Events

If you audit for logon events—every time that a user logs on or off a computer—an event is generated in the security log of the computer where the logon attempt occurs. Also, when a user connects to a remote server, a logon event is generated in the security log of the remote server. Logon events are created when the logon session and token are created or destroyed respectively.

Logon events can be useful to track attempts to logon interactively at servers or to investigate attacks launched from a particular computer. Success audits generate an audit entry when a logon attempt succeeds. Failure audits generate an audit entry when a logon attempt fails.

Note   Logon events include both computer and user logon events. You will see separate security event log entries for both the computer account and the user account if a network connection is attempted from a Microsoft® Windows NT®- or Windows 2000–based computer. Windows 9x–based computers do not have computer accounts in the directory and do not generate computer logon event entries for network logon events.

As part of the Member Server and Domain Controller Baseline Policies, auditing for success and failure logon events is enabled. You should therefore expect to see the following event IDs for interactive logons, and Terminal Services logons connecting to computers running Terminal Services in the Security Event Log.

Table 9.1  Logon Events That Appear in the Security Event Log

The following security events can be diagnosed using logon event entries:

Contoso is monitoring for large numbers of logon attempt failures and large numbers of account lockouts. It is not uncommon in their environment for users to leave terminal services sessions disconnected for legitimate reasons.

Account Logon Events

When a user logs on to a domain, the log on is processed at a domain controller. If you audit Account Logon events at domain controllers, you will see this logon attempt recorded at the domain controller that validates the account. Account Logon events are created when an authentication package validates a user's credentials. When domain credentials are used, Account Logon events are only generated in the domain controllers' event logs. If the credentials presented are local Security Accounts Manager (SAM) database credentials, then the account logon events are created in the server's security event log.

Because the Account Logon event can be recorded in any valid domain controller in the domain, you must ensure that you consolidate the security log across domain controllers to analyze all Account Logon events in the domain.

Note   As with Logon events, Account Logon events include both computer and user logon events.

As part of the Member Server and Domain Controller Baseline Policies, auditing for success and failure Account Logon events is enabled. You should therefore expect to see the following event IDs for network logons and Terminal Services authentication.

Table 9.2  Account Logon Events That Appear in the Event Log

For each of these events, the event log shows detailed information about each specific log on. The following security events can be diagnosed using account logon event entries:

Contoso is currently monitoring for uncommon numbers of domain logon attempt failures. Based on their environment, the other events are not relevant. When configuring these settings, they determined that the best approach was to start with a relatively tight setting and continue to reduce it until the number of false positive alerts was reduced. Currently, they are monitoring for any cases where 10 failed logins occur in a 10 minute period. These numbers may be different in all environments.

Account Management

Account Management auditing is used to determine when users or groups are created, changed, or deleted. This audit can be used to determine when a security principal was created, and who performed the task.

As part of the Member Server and Domain Controller Baseline Policies, auditing for success and failure in Account Management is enabled. You should therefore expect to see the following event IDs recorded in the security log.

Table 9.3  Account Management Events That Appear in the Event Log

The following Account Management events can be diagnosed using security log entries:

Because Contoso is a fairly large enterprise, they have a great deal of account maintenance that occurs on a daily basis. Monitoring for all of these events would cause too many alerts to be reasonably addressed in their environment.

Object Access

Auditing can be enabled for all objects in a Windows 2000–based network with a system access control list (SACL). A SACL contains a list of users and groups for which actions on the object are to be audited. Almost any object that a user can manipulate in Windows 2000 has a SACL, including files and folders on NTFS file system drives, printers and registry keys.

A SACL is comprised of access control entries (ACEs). Each ACE contains three pieces of information:

If you want events to appear in the security log, you must first enable Auditing for Object Access and then define the SACL for each object you want to audit.

Audits in Windows 2000 are generated when a handle to an object is opened. Windows 2000 uses a kernel-mode security subsystem that only allows programs to access objects through the kernel, which prevents programs from attempting to bypass the security system. Because the kernel memory space is isolated from user mode programs, a program refers to an object through a data structure called a handle. The following is a typical access attempt:

It is very important to note that when auditing occurs and the event is generated, nothing has happened to the object yet. This understanding is critical to interpreting audit events. Write audits are generated before a file is written to, and read audits are generated before a file is read.

As with all auditing, it is very important to take a targeted approach to auditing object access. In your auditing plan, decide on the type of objects that you must audit and then determine what type of access attempts (success, failure, or both) you want to monitor for each type of audited object. An overly broad approach to auditing will have a significant impact on your computer’s performance and will result in the collection of much more data than is necessary or useful.

Generally, you will want to audit all access to your chosen objects, including from nontrusted accounts. To audit all access, add the Everyone group to the SACL on the objects you want to audit. You should be wary of auditing for success on object access as this can create a very large number of audit entries in the security log. However, for example, if you are investigating the deletion of a critical file, you will need to examine success audit events to determine which user account deleted the file.

The Member Server and Domain Controller Baseline Policies are configured to audit for both success and failure on object access. However, no SACLs are set on the objects themselves and you will need to configure them according to the needs of your environment. The SACLs can be defined directly at the objects, or using Group Policy. If the object that requires auditing exists on multiple computers, you should define the SACLs in Group Policy.

Auditing for Object Access will cause the following events to appear in the security log.

Table 9.4  Object Access Events That Appear in the Event Log

If you are looking for specific object access events, you will primarily need to research Event ID 560 events. The useful information is within the event details and you will need to search the event details to find the specific events you are searching for. The following table shows some actions you may need to perform and how to perform them.

Table 9.5  How to Perform Key Auditing Actions for Object Access Event 560

Contoso is not specifically monitoring for any object access events, but is auditing object access for some files. This information can be extremely helpful when responding to a security incident.

Directory Service Access

Active Directory objects have SACLs associated with them and so can be audited. As previously mentioned, you audit Active Directory user and group accounts by auditing Account Management. However, if you want to audit the modification of objects in other naming contexts, such as the Configuration and Schema naming contexts, you must audit for object access, and then define the SACL for the specific containers you want to audit. Audit entries are generated when users listed on the SACL of an Active Directory object attempt to access that object.

You can modify the SACL for containers and objects in the Configuration naming context (and other naming contexts) using the ADSIEDIT MMC snap-in. This modification is accomplished by displaying the required context in the ADSIEDIT console, and then modifying the SACL for the object in the Advanced Security Settings dialog box.

It is very difficult to find specific events for directory service access because of the large volume of (generally innocuous) events that take place. For this reason, the Member Server and Domain Controller Baseline Policies only audit failed events for directory service access. This configuration will help you identify when an attacker attempts unauthorized access to Active Directory.

Attempted directory access will show as a directory service event with the ID 565 in the security log. Only by looking at the details of the security event can you determine which object the event corresponds to.

Contoso is not specifically monitoring for any directory service access events, but is auditing object access for some files. This information can be extremely helpful when responding to a security incident.

Privilege Use

As users work in an information technology (IT) environment, they exercise defined user rights. If you audit Privilege Use for success and failure, an event will be generated each time a user attempts to exercise a user right.

Even if you do audit Privilege Use not all user rights are audited. By default, the following user rights are excluded:

You can override the default behavior of not auditing Backup and Restore user rights by enabling the Audit use of Backup and Restore Privilege security option in Group Policy.

Auditing for success on Privilege Use will create a very large number of entries in the security log. For this reason, the Member Server and Domain Controller Baseline Policies only audit for failure on Privilege Use.

The following events are generated if auditing for Privilege Use is enabled.

Table 9.6  Privilege Use Events That Appear in the Event Log

Here are examples of some of the event log entries that can exist when specific user rights are used:

Contoso is specifically monitoring for any events that indicate a normal shutdown or a forced shutdown from a remote computer as well as any events indicating the auditing and security log has been modified.

Process Tracking

If you audit detailed tracking information for processes running on Windows 2000-based computers, the event log will show attempts to create processes and end processes. It will also record when a process attempts to generate a handle to an object or obtain indirect access to an object.

Because of the very large number of audit entries created, the Member Server and Domain Controller Baseline Policies do not enable auditing for process tracking. However, if you choose to audit for success and failure, the following event IDs will be recorded in the event log.

Table 9.7  Process Tracking Events That Appear in the Event Log

Contoso is not monitoring for any process tracking events and has not enabled them in any of the server policies.

System Events

System events are generated when a user or process alters aspects of the computer environment. You can audit for attempts to make changes to the computer, such as shutting down the computer or altering the system time.

If you audit system events, you also should audit when the security log is cleared. This audit is very important, because attackers will often attempt to clear their tracks after making changes in an environment.

The Member Server and Domain Controller Baseline Policies audit system events for success and failure, which will cause the following event IDs to appear in the event log.

Table 9.8  System Events That Appear in the Event Log

You can use these event IDs to capture a number of security issues:

Contoso is monitoring for both computer shutdown or restarts and the clearing of the security log.

Policy Change

Your audit policy defines which changes to your environment are audited, helping you to determine whether there have been attempts to attack your environment. However, a determined attacker will look to alter the audit policy itself, so that any changes they make are not audited.

If you audit for policy change, you will show attempts to alter the audit policy, alongside changes to other policies and user rights. The Member Server and Domain Controller Baseline Policies audit policy change for success and failure. You will see these events recorded in the event log.

Table 9.9  Policy Change Events That Appear in the Event Log

The two most important events to look for here are Event IDs 608 and 609. A number of attempted attacks may result in these events being recorded. The following examples will all generate Event ID 608 if the user right is assigned or 609 if it is removed. In each case the specific SID that the user right is assigned to, along with the user name of the security principal that assigned the right, is included in the event details:

Note   These audit events only identify that the user right was assigned to a specific security principal. It does not mean that the security principal has performed a task using the user right. The audit events do determine when the user right policy was modified.

Contoso is not currently monitoring any policy change events. These events will be utilized for any troubleshooting or incident response. Monitoring changes to Group Policies can be very difficult and provide numerous false alerts, primarily because the MMC snap-in for editing Group Policies, gpedit.msc, always opens policies with both read and write privileges. Even if no changes are made to the policy, event 578 is written to the domain controller’s security log.

The Group Policy Management Console, released as a free download shortly after Windows Server 2003 shipped, helps to overcome these issues by allowing authorized users to view policy settings without having to open them in gpedit.msc. For more information about the Group Policy Management Console, see the "Administering Group Policy with the GPMC" white paper at www.microsoft.com/windowsserver2003/gpmc/gpmcwp.mspx.

Protecting Event Logs

To ensure that the event log entries are maintained for future reference, you should take a number of steps to protect the security of the event logs. These steps should include:

Contoso implemented these settings in the Member Server and Domain Controller Group Policy Objects. For details on these settings, see Chapter 6, "Hardening the Base Windows 2000 Server," and Chapter 7, "Hardening Specific Server Roles."

In addition to these steps, you should take the following practical measures to ensure that your event log information is as safe as possible:

Note   Preventing guest access to event logs only restricts non-domain members from accessing the event logs. By default, all users in a domain can access the system and application logs. Only access to the security log is restricted. Security principals that are assigned the user right Manage auditing and security log can access the security log. By default, this user right is only assigned to Administrators and Exchange Enterprise Servers.

Other Auditing Best Practices

In addition to configuring auditing, there are other practices that should be implemented to effectively audit the security of your server environment. These practices include:

Scheduling Regular Review of the Event Logs

As mentioned previously, the security log and potentially the other event logs should be written to either removable material or consolidated to a central location for review. Reviewing the logs is often the most frequently missed auditing step.

Contoso has done a great amount of work to ensure that there is either a single person or a team responsible for reviewing the event logs as a regular task. Such a review of event logs can be scheduled as a daily or weekly event, depending on the amount of data that is collected in the security log. The amount of data collected is typically based on the level of auditing implemented on the network. If more events are included in the audit, the volume of log entries will be larger. If you schedule regular event log reviews you will help achieve the following:

Reviewing Other Application Log Files

In addition to reviewing the Windows 2000 event logs for security events, you should also review the logs created by applications. The application logs may include valuable information regarding potential attacks that can supplement the information found in the event logs. Depending on your environment, you may need to look at one or more of these log files:

Note   All computers that maintain log files should use synchronized clocks. This synchronization allows an administrator to compare events between computers and services to establish what actions were taken by an attacker. For more details on time synchronization, see the Importance of Time Synchronization section later in this chapter.

Monitoring Installed Services and Drivers

Many attacks against a computer are implemented by attacking services installed on the target computer, or by replacing valid drivers with versions of the driver that include a Trojan horse, allowing an attacker access to the target computer.

The following tools can be used to monitor the installed services and drivers on your computers:

Note   Not all services (such as the Workstation service) can be stopped directly, although you can query them. If the user has a lot of active connections, you cannot force the service to shut down remotely, although you can pause or query it. Some services have other services that are dependent on them; trying to shut down such services will fail unless the dependent services are shut down first.

Monitoring Open Ports

Attacks are often started by performing a port scan to identify any known services running on the target computer. You should make sure that you carefully monitor which ports are open on your servers, which generally means scanning the ports yourself to determine what can be accessed.

When performing port scans, you should perform them both locally at the target computer, and from a remote computer. If the computer can be accessed from a public network, the port scan should be performed from an external computer to ensure that your firewall software only allows access to desired ports.

Netstat.exe is a command line utility that can show all open ports for both TCP and User Datagram Protocol (UDP). The Netstat command uses the following syntax:

Note Some of the lines in the following code have been displayed on multiple lines for better readability.

NETSTAT [-a] [-e] [-n] [-s] 
[-p proto] [-r] [interval]

where:

When you list the open TCP and UDP ports at the local computer, port numbers are translated to names based on the entries in the services file found in the \%WinDir%\System32\Drivers\Etc\ folder. If you prefer to only see port numbers, you can use the -n switch.

If any open ports are discovered that are not recognized, you should investigate them to determine whether the corresponding service is needed on the computer. If it is not, you should disable or remove the associated service to prevent the computer from listening on that port. A number of services have been disabled in the Member Server and Domain Controller Baseline Policies included with this guide.

Because many servers are protected by firewalls, or packet filtering routers, it is also recommended to perform the port scan from a remote computer. Many third-party tools (including some freeware) are available that can do remote port scans. The remote port scan reveals which ports are available to external users when they attempt to connect to the computer.

Note   Port scanning can also be used to test your intrusion detection system to ensure that it detects the port scan as it is taking place. For more information about intrusion detection systems, see the "Active Detection Methods" section later in this chapter.

Top of page

Monitoring for Intrusion and Security Events

Monitoring for intrusion and security events includes both passive and active tasks. Many intrusions are detected after the attack has taken place through the inspection of log files. This post-attack detection is often referred to as passive intrusion detection. Only through inspection of the log files can the attack be reviewed and reconstructed based on the log information.

Other intrusion attempts can be detected as the attack takes place. This methodology, known as active intrusion detection, looks for known attack patterns or commands, and blocks the execution of those commands.

This section will look at tools that can be used to implement both forms of intrusion detection to protect your network from attacks.

Importance of Time Synchronization

When monitoring for both intrusion and security events between multiple computers, it is essential that the computers' clocks are synchronized. Synchronized time allows an administrator to reconstruct what took place during an attack against multiple computers. Without synchronized time, it is very difficult to determine exactly when specific events took place, and how events interlace. More detailed information about time synchronization can be found in Chapter 5, "Securing the Domain Infrastructure."

Passive Detection Methods

Passive intrusion detection systems involve the manual review of event logs and application logs. The inspection involves analysis and detection of attack patterns in event log data. There are several tools, utilities, and applications that can help review event logs. This section outlines how each tool can be used to coordinate information.

Event Viewer

The Windows 2000 security log can of course be viewed using the Windows 2000 Event Viewer MMC console. Event Viewer allows you to view the application, security, and system logs. You can define filters to find specific events in the Event Viewer.

To define filter in the Event Viewer

In the Filter tab of the Properties dialog box, you can define the following attributes to filter event entries:

When the filter is applied, the filtered event list can be exported to either a comma separated or tab separated listing for import into a database application.

As mentioned previously, Contoso has several individuals for each administrative role that are responsible for reviewing event logs. They review the logs on a daily basis for any security related events that were not logged by the monitoring system.

Dump Event Log Tool (Dumpel.exe)

Dump Event Log is a command-line tool, included in the Windows 2000 Server Resource Kit, Supplement One (Microsoft Press, ISBN: 0-7356-1279-X). It will dump an event log for a local or remote computer into a tab separated text file. This file could then be imported into a spreadsheet or database for additional investigation. The tool can also be used to filter for or filter out certain event types.

The following syntax is used by the dumpel.exe tool:

Note Some of the lines in the following code have been displayed on multiple lines for better readability.

dumpel -f file [-s \\server] 
[-l log [-m source]] 
[-e n1 n2 n3...] [-r] [-t] [-d x] 

where:

Note   Dumpel can only retrieve content from the system, application, and security log files. You cannot use Dumpel to query content from the File Replication Service, DNS, or Directory Service event logs.

EventCombMT

EventCombMT is a multithreaded tool that will parse event logs from many servers at the same time, spawning a separate thread of execution for each server that is included in the search criteria. EventCombMT is included with the Microsoft Windows Server 2003 Resource Kit Tools, which is available for download from the Windows Deployment and Resource Kits Web site at www.microsoft.com/windowsserver2003/
techinfo/reskit/resourcekit.mspx.

The tool allows you to:

Installing the Tool

To install the tool, extract the contents of the self-extracting SecWin2k.exe file included with this guide. This file will create a C:\SCI\scripts\EventComb folder. After the files are extracted, you can run the EventCombMT tool by double-clicking the EventCombMT.exe file.

Running the EventComb Tool

The first step in using the EventComb tool is defining which computers will be included in the event log search.

To add computers to the search

1.	In the EventCombMT utility, ensure that the correct domain is autodetected in the domain box. If you want to search event logs in a different domain, then manually type the new domain name in the Domain box.
2.	To add computers to the search list, right-click the box underneath Select To Search/Right Click to Add. The pop-up menu is shown in the following figure: Figure 9.1  Using the EventCombMT dialog box settings to add computers not autodetected to the search list See full-sized image The following options are available: • Get DCs in Domain. Adds all domain controllers for the current domain to the listing. • Add Single Server. Allows you to add a server or workstation by name to the listing. • Add all GCs in this domain. Allows you to add all domain controllers in the selected domain that are configured to be global catalog servers. • Get All Servers. Adds all servers found in the domain using the browser service. The servers exclude all domain controllers. • Get Servers from File. Allows you to import a file that lists all servers to be included in the search scope. Each server should be entered on a separate line in the text file.
3.	After the servers are added to the list, you must select which servers to perform the search against. When selected, the server will appear highlighted in the list. You can choose multiple servers, using a CTRL+click combination.

Specifying the Event Logs and Event Types to Search

After you have selected the servers to be included in your event log search, you can narrow the scope of the search by selecting which event logs and event types to include.

In the EventCombMT utility, you can select from the following event logs for the search:

You can also select the following Event types to include in the search:

Note   If you are aware of the specifics of which event log an event ID appears in, and the event type of the event ID, always include this information in your search criteria as it reduces the time for the search.

Saving Searches

EventCombMT allows you to save searches and reload them later. This capability can be useful if you frequently use EventCombMT to search your IIS servers for one set of events and your domain controllers for another.

Search criteria are saved in the registry under: HKLM\Software\Microsoft\EventCombMT and can be easily edited.

Search Result Files

The results of the search are saved to the C:\Temp folder by default. The results include a summary file named EventCombMT.txt and for each computer included in the event log search, a separate text file named ComputerName-EventLogName_LOG.txt is generated. These individual text files contain all the events extracted from the event logs that match your search criteria.

Examples of Using EventCombMT

To show how EventCombMT can be used, we will show how the tool can be configured to detect domain controller restarts and account lockouts.

To use EventCombMT to search for restarts of domain controllers

1.	In the EventCombMT tool, ensure that the domain is configured to the correct domain name.
2.	Right-click the box underneath Select to Search/Right Click to Add and then click Get DCs in Domain. Note   When searching for events such as Account Logon and Account Management events, ensure that you search all domain controllers. Because Windows 2000 uses a multimaster model for account management, an account can be added, modified, or deleted at any domain controller in the domain. Likewise, authentication can be validated by any domain controller in the domain. Because of this functionality, you cannot be sure where the specific update or authentication attempt takes place.
3.	Right-click the Select to Search/Right Click to Add box, and then click Select All Servers in List.
4.	In the "Choose Log Files to search" section of the tool, select the System log only.
5.	In the "Event Types" section of the tool, select Error and Informational.
6.	In the Event IDs box, type the following Event IDs: 1001 6005 6006 6008.
7.	Before clicking the Search button, ensure that your search criteria is defined as shown in the following figure. Then click Search. Figure 9.2  Defining search criteria in the Event Comb MT dialog box See full-sized image

When the search is completed, the results can be viewed in the log directory, which should open automatically when the search is complete.

To review the log entries

1001,INFORMATIONAL,Save Dump,Wed Nov 28 05:45:50 2001,
,The computer has rebooted from a bugcheck. 
The bugcheck was: 0x000000d1 (0x00000004, 
0x00000002, 0x00000000, 0x84c983dc).
A dump was saved in: C:\WINDOWS\MEMORY.DMP.
6005,INFORMATIONAL,EventLog,Wed Nov 28 05:45:46 2001,
,The Event log service was started.
6008,ERROR,EventLog,Wed Nov 28 05:45:46 2001,
,The previous system shutdown at 5:33:47 
AM on 11/28/2001 was unexpected.
6005,INFORMATIONAL,EventLog,Tue Nov 27 14:10:53 2001,
,The Event log service was started.
6006,INFORMATIONAL,EventLog,Tue Nov 27 14:09:26 2001,
,The Event log service was stopped.
6005,INFORMATIONAL,EventLog,Tue Nov 27 10:11:37 2001,
,The Event log service was started.

The 6006 event indicates a planned shutdown initiated by a user with the user rights to shutdown the domain controller. The 6005 event indicate that the event log service was started, which occurs at start up time.

The 6008 and 1001 events indicate that the computer was either powered off without shutting down, or restarted because it locked up, or experienced a stop error. If a 1001 event exists, a stop error did occur, and the associated debug information and reference to the debug file is included.

The events returned by the EventCombMT tool should be cross-checked with known down time, and nonmatching events should be researched to ensure that the server has not been attacked.

EventCombMT includes several preconfigured searches that can be used to search for security events. For example, there is a predefined search that searches for Account Lockout events.

To use EventCombMT to search for Account Lockouts

Note   Other predefined searches that are included with EventcombMT include File Replication Services searches, Active Directory searches for duplicate SIDs and NETLOGON DNS registration failures, Hardware disk errors, and DNS interface errors. You can also define and save your own custom searches.

Contoso uses EventCombMT in cases where they are trying to diagnose problems or determine causes of issues during an incident response. Additionally, they routinely check for account lockouts or bad password across all domain controllers. Doing so helps them manually identify any odd patterns that a monitoring system may not detect.

Event Collection

One of the main goals of auditing is to identify the actions taken by attackers on your network. An attacker may attempt to compromise multiple computers and devices on the network. Therefore, to understand the extent of any attack, you must be able to coordinate and consolidate information from many computers.

If your log utilities will import into a database, it is easier to coordinate the information from multiple logs. As long as your time is synchronized across all computers, you can sort on time fields, and ease the tracking of events based on time intervals.

The following sections outline some of the tools and utilities that you can use to collect event log information into a central location.

Scripting

Scripts can be written that collect event log information from remote computers and store it in a central location. By using scripting, you can choose when to run the scripts using Scheduled Tasks and what actions to take after the event log is successfully copied to the central location.

A simple example would be to create a batch file that uses Dumpel.exe from the Windows 2000 Server Resource Kit, and launch the batch file at regular intervals using Scheduled Tasks in Control Panel.

The Windows 2000 Resource Kit, Supplement One includes Eventquery.pl. This file is a Perl script that displays events from the Event Viewer logs on local and remote computers running Windows 2000 and offers a wide range of filters to help you find specific events.

Note   To use this script, you will need to install ActivePerl from the Windows 2000 Server Resource Kit.

Contoso currently does not use an event collection solution. However, it is expecting to use the Microsoft Audit Collection System (MACS), which will be released in the upcoming year. MACS is a security event collection tool that collects events in a secure manner utilizing compression, signing, and encryption. After gathering the events, they are loaded into a SQL database and optimized for analysis.

Microsoft Operations Manager

Microsoft Operations Manager (MOM) 2000 offers a comprehensive set of tools that allow enterprises to thoroughly analyze the built-in event reporting and performance monitoring of Windows 2000 and its applications. MOM 2000 can collect, store, and report events and performance data to a single location through the use of Intelligent Agents at remote computers, allowing an administrator to centrally review the collected information.

The MOM 2000 management pack collects events that appear in the system, application, and security event logs, and collects the results into a central event repository.

Note   MOM 2000 stores its information in a SQL Server database, and offers several methods to retrieve and analyze the archived data. Administrators can use the Operations Manager Administrator Console, Web Console, or Operations Manager Reporting to view, print, or publish the data. Each view includes predefined views for analyzing the archived data, and allows for customized views and reports to be defined.

Third-Party Solutions for Event Log Collection

Several third-party products are available that offer centralized event log collection and inspection. As you evaluate these products, include the following features in your criteria:

Third-party products that provide event collection ability include:

Active Detection Methods

Active intrusion detection systems analyze incoming network traffic at the application layer, looking for well known attack methods or suspicious application layer payloads. If a suspicious packet is received, the intrusion detection system will typically drop the packet, and log an entry into a log file. Some intrusion detection systems can also alert an administrator if a severe attack is detected.

Third-Party Solutions for Intrusion Detection

Third-party solutions exist for both network and end point intrusion detection systems. These third-party solutions provide support for protocols other than HTTP and also scan for well known attacks against networked computers.

The common types of attacks that intrusion detection systems should identify include:

A good intrusion detection system should be able to identify all three forms of attacks. Two different methods are used to identify attacks:

Some third-party products available for testing and deployment include:

Vulnerability Assessment

In addition to performing passive and active intrusion detection, you should also perform periodic vulnerability assessments. Vulnerability assessments simulate an attack on your network and detect the vulnerabilities that an attacker would find.

By performing periodic assessments you can find vulnerabilities before an attacker does and secure the weakened portion of your network to protect against the vulnerability.

When researching vulnerability assessment tools, include the following requirements in your decision-making process:

Several third-party tools exist to perform vulnerability assessments against a Windows 2000 network. These tools include:

Alternatively, it may be more appropriate to bring in a third-party consulting service to perform the vulnerability assessment. The advantage of using a third-party service is that they have no previous knowledge of the network and will be working from the same starting point as an external attacker. Many times, these external assessments will provide the most useful information, based on the neutrality of the assessment team.

Top of page

Summary

Auditing and intrusion detection is a major part of building an effective defense for your environment. As part of your risk management process, you should determine how much auditing and intrusion detection is appropriate for your environment. For intrusion detection across multiple protocols, you may want to consider third-party tools.

More Information

For more information about the use of user rights, see Writing Secure Code by Michael Howard and David LeBlanc (Microsoft Press, ISBN: 0-7356-1588-8).

For more information about independent companies that offer ISA Server–compatible and complementary third-party solutions, see the Internet Security and Acceleration (ISA) Server Partners Web site at www.microsoft.com/isaserver/partners.

For more information about ISA Server, see the ISA Server Web site at www.microsoft.com/isaserver/default.mspx.

For more information about the Group Policy Management Console, see the "Administering Group Policy with the GPMC" white paper at www.microsoft.com/windowsserver2003
/gpmc/gpmcwp.mspx.

Top of page

10 of 16