Securing Windows 2000 Server

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Chapter 9: Auditing and Intrusion Detection

Published: November 17, 2004 | Updated : May 31, 2006

Note: Welcome to the TechNet Archive. We've created this Archive area so that we can continue to make available older content that is still of interest to some of our users. This allows us to streamline the content offerings on the site and keep it focused on the newest, most relevant content.

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:

• Any functional computer environment is potentially open to attack. No matter how high your level of security, there is a risk that you may be attacked.

• Successful attacks often follow a series of unsuccessful ones. If you do not monitor for attacks you will not detect others before they are successful.

• When a successful attack occurs, the earlier you find out, the easier it will be to contain the damage.

• To recover from an attack, you need to know what damage has been done.

• Auditing and intrusion detection helps you determine who was responsible for the attack.

• The combination of auditing and intrusion detection helps correlate information to identify attack patterns.

• Regular review of security logs helps identify unknown security configuration issues, such as incorrect permissions, or lax account lockout settings.

• After an attack is detected, auditing can assist in determining what network resources are compromised.

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:

• Logon events

• Account logon events

• Object access events

• Directory Service access events

• Privilege use events

• Process tracking events

• System events

• Policy change 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

Event ID	Description
528	A user successfully logged on to a computer.
529	The logon attempt was made with an unknown user name or a known user name with a bad password.
530	An attempt was made to log on with the user account outside of the allowed time.
531	A logon attempt was made using a disabled account.
532	A logon attempt was made using an expired account.
533	The user is not allowed to log on at this computer.
534	The user attempted to log on with a logon type that is not allowed, such as network, interactive, batch, service, or remote interactive.
535	The password for the specified account has expired.
536	The Net Logon service is not active.
537	The logon attempt failed for other reasons.
538	A user logged off.
539	The account was locked out at the time the logon attempt was made. This event can indicate that a password attack was launched unsuccessfully resulting in the account being locked out.
540	Successful Network Logon. This event indicates that a remote user has successfully connected from the network to a local resource on the server, generating a token for the network user.
682	A user has reconnected to a disconnected Terminal Services session. This event indicates that a previous Terminal Services session was connected to.
683	A user disconnected a Terminal Services session without logging off. This event is generated when a user is connected to a Terminal Services session over the network. It appears on the terminal server.

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

• Local logon attempt failures. Any of the following Event IDs indicates failed logon attempts: 529, 530, 531, 532, 533, 534, and 537. You will see events 529 and 534 if an attacker tries and fails to guess a username and password combination for a local account. However, these events can also occur when a user forgets their password, or starts browsing the network through My Network Places.

  In a large scale environment it can be difficult to interpret these events effectively. As a rule, you should investigate these patterns if they occur repeatedly or coincide with other unusual factors. For example, a number of 529 events followed by a 528 event in the middle of the night could indicate a successful password attack (or a very tired administrator).

• Account Misuse. Events 530, 531, 532, and 533 can all represent misuse of a user account. The events indicate that the account/password combination was correctly entered, but other restrictions are preventing a successful log on. Wherever possible, you should investigate these events to determine whether misuse occurred, or if the current restriction needs to be modified. For example, you may need to extend the logon hours of certain accounts.

• Account Lockouts. Event 539 indicates that an account was locked out. This event can indicate that a password attack has failed. You should look for earlier 529 events by the same user account to try and discern the pattern of logon attempts.

• Terminal Services attacks. Terminal Services sessions can be left in a connected state that allows processes to continue running after the session is ended. Event ID 683 indicates when a user does not log out from the Terminal Services session, and Event ID 682 indicates when a connection to a previously disconnected session has occurred.

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

Event ID	Description
672	An authentication service (AS) ticket was successfully issued and validated.
673	A ticket granting service (TGS) ticket was granted.
674	A security principal renewed an AS ticket or TGS ticket.
675	Pre-authentication failed.
676	Authentication Ticket Request failed.
677	A TGS ticket was not granted.
678	An account was successfully mapped to a domain account.
680	Identifies the account used for the successful logon attempt. This event also indicates the authentication package used to authenticate the account.
681	A domain account logon was attempted.
682	A user has reconnected to a disconnected Terminal Services session.
683	A user disconnected a Terminal Services session without logging off.

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:

• Domain logon attempt failures. Event IDs 675 and 677 indicate failed attempts to logon to the domain.

• Time Synchronization issues. If a client computer's time differs from the authenticating domain controller's by more than five minutes (by default), Event ID 675 will appear in the security log.

• Terminal Services attacks. Terminal Services sessions can be left in a connected state that allows processes to continue running after the terminal server session is ended. Event ID 683 indicates when a user does not log out from the Terminal Services session, and Event ID 682 indicates when a connection to a previously disconnected session has occurred. To prevent disconnections, or to terminate these disconnected sessions, define the time interval to end disconnected session in the Terminal Services Configuration console, in the properties of the RDP-TCP protocol.

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

Event ID	Description
624	User Account Created
625	User Account Type Change
626	User Account Enabled
627	Password Change Attempted
628	User Account Password Set
629	User Account Disabled
630	User Account Deleted
631	Security Enabled Global Group Created
632	Security Enabled Global Group Member Added
633	Security Enabled Global Group Member Removed
634	Security Enabled Global Group Deleted
635	Security Disabled Local Group Created
636	Security Enabled Local Group Member Added
637	Security Enabled Local Group Member Removed
638	Security Enabled Local Group Deleted
639	Security Enabled Local Group Changed
641	Security Enabled Global Group Changed
642	User Account Changed
643	Domain Policy Changed
644	User Account Locked Out

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

• Creation of a user account. Event IDs 624 and 626 identify when user accounts are created and enabled. If account creation is limited to specific individuals in the organization, you can use these events to identify whether unauthorized personnel have created user accounts.

• User account password changed. The modification of a password by someone other than the user can indicate that an account has been taken over by another user. Look for Event IDs 627 and 628 which indicate that a password change is attempted and is successful. Review the details to determine whether a different account performed the change, and whether the account is a member of the help desk or other service team that resets user account passwords.

• User account status changed. An attacker may attempt to cover their tracks by disabling or deleting the account used during an attack. All occurrences of Event IDs 629 and 630 should be investigated to ensure that they are authorized transactions. Also look for occurrences of Event ID 626 followed by Event ID 629 a short time later. This sequence can indicate that a disabled account was enabled, used, and then disabled again.

• Modification of Security Groups. Membership changes to Domain Adminstrators, Administrators, any of the operator groups, or to custom global, universal, or domain local groups that are delegated administrative functions should be reviewed. For global group membership modifications, look for Event IDs 632 and 633. For domain local group membership modifications, look for Event IDs 636 and 637.

• Account Lockout. When an account is locked out, two events will be logged at the primary domain controller (PDC) emulator operations master. A 644 event will indicate that the account name was locked out, and then a 642 event is recorded, indicating that the user account is changed to indicate that the account is now locked out. This event is only logged at the PDC emulator.

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:

• The security principal to be audited.

• The specific access types to be audited, called an access mask.

• A flag to indicate whether to audit failed access, successful access, or both.

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:

1. A user instructs a program to access an object (for example, File/Open).

2. The program requests a handle from the system, specifying what kind of access (read, write, and so on) is desired.

3. The security subsystem compares the Discretionary Access Control List (DACL) on the requested object to the user’s token, looking for entries in the DACL that match either the user or a group the user belongs to and that has the access rights the program requested.

4. The system compares the SACL on the requested object to the user’s token, looking for entries in the SACL that match either the effective rights being returned to the program, or the rights requested by the program. If a matching failure audit ACE matches an access that was requested but not granted, a failure audit event is generated. If a matching success audit ACE matches an access that was granted, a success audit event is generated.

5. If any access is granted, the system returns a handle to the program, which can then use the handle to access the object.

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

Event ID	Description
560	Access was granted to an already existing object.
562	A handle to an object was closed.
563	An attempt was made to open an object with the intent to delete it. (This event is used by file systems when the FILE_DELETE_ON_CLOSE flag is specified.)
564	A protected object was deleted.
565	Access was granted to an already existing object type.

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

Auditing action	How it is achieved
Find a specific file, folder or object	In the Event 560 details, search for the full path of the file or folder you want to review actions for.
Determine actions by a specific user	Define a filter that identifies the specific user in a 560 event.
Determine actions performed at a specific computer	Define a filter that identifies the specific computer account where the task was performed in a 560 event.

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:

• Bypass traverse checking

• Debug programs

• Create a token object

• Replace process level token

• Generate security audits

• Backup files and directories

• Restore files and directories

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

Event ID	Description
576	Specified privileges were added to a user's access token. (This event is generated when the user logs on.)
577	A user attempted to perform a privileged system service operation.
578	Privileges were used on an already open handle to a protected object.

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

• Act as part of the operating system. Look for Event ID 577 or 578 with the SeTcbPrivilege access privilege indicated. The user account that made use of the user right is identified in the event details. This event can indicate a user's attempt to elevate security privileges by acting as part of the operating system. For example, the GetAdmin attack, where a user attempts to add their account to the Administrators group uses this privilege. The only entries for this event should be for the System account, and any service accounts assigned this user right.

• Change the system time. Look for Event ID 577 or 578 with the SeSystemtimePrivilege access privilege indicated. The user account that used the user right is identified in the event details. This event can indicate a user's attempt to change the system time to hide the true time that an event takes place.

• Force shutdown from a remote system. Look for Event IDs 577 and 578 with user right SeRemoteShutdownPrivilege access privilege indicated. The specific security identifier (SID) the user right is assigned to and the user name of the security principal that assigned the right are included in the event details.

• Load and unload device drivers. Look for Event ID 577 or 578 with the SeLoadDriverPrivilege access privilege indicated. The user account that made use of this user right is identified in the event details. This event can indicate a user's attempt to load an unauthorized or Trojan horse (a type of malicious code) version of a device driver.

• Manage auditing and security log. Look for Event ID 577 or 578 with the SeSecurityPrivilege access privilege indicated. The user account that made use of this user right is identified in the event details. This event will occur both when the event log is cleared and when events for privilege use are written to the security log.

• Shut down the system. Look for Event ID 577 with the SeShutdownPrivilege access privilege indicated. The user account that made use of this user right is identified in the event details. This event will occur when an attempt to shut down the computer takes place.

• Take ownership of files or other objects. Look for Event ID 577 or 578 with the SeTakeOwnershipPrivilege access privilege indicated. The user account that used the user right is identified in the event details. This event can indicate that an attacker is attempting to bypass current security settings by taking ownership of an object.

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

Event ID	Description
592	A new process was created.
593	A process exited.
594	A handle to an object was duplicated.
595	Indirect access to an object was obtained.

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

Event ID	Description
512	Windows is starting up.
513	Windows is shutting down.
514	An authentication package was loaded by the Local Security Authority.
515	A trusted logon process has registered with the Local Security Authority.
516	Internal resources allocated for the queuing of security event messages have been exhausted, leading to the loss of some security event messages.
517	The security log was cleared.
518	A notification package was loaded by the Security Accounts Manager.

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

• Computer Shutdown/Restart. Event ID 513 shows each instance of when Windows was shut down. It is important to know when servers have been shut down or restarted. There are a number of legitimate reasons, such as a driver or application was installed requiring a restart, or the server was shut down or restarted for maintenance. However, an attacker may also force a restart of a server to gain access to the computer during startup. All cases where the computer is shut down should be noted for comparison with the event log.

  Many attacks involve the restart of a computer. By investigating the event logs, you can determine when a server has been restarted, and whether the restart was a planned restart, or an unplanned restart. Event ID 513 shows Windows starting up, as will a series of other events which are automatically generated in the system log. These events include Event ID 6005, which indicates that the Event Log service has started.

  In addition to this entry, look for the existence of one of two different event log entries in the system log. If the previous shutdown was clean, such as when an administrator restarts the computer, then Event ID 6006, the Event Log service was stopped, is recorded in the system log. By examining the details of the entry, you can determine which user initiated the shutdown.

  If the restart was due to an unexpected restart, an Event ID 6008, the previous system shutdown at <time> on <date> was unexpected is recorded in the system log. This event can indicate of a denial of service (DoS) that caused a shutdown of the computer. But remember, it also can be due to a power failure, or device driver failure as well.

  If the restart was made because of a stop error that resulted in a blue screen, then Event ID 1001, with a source of Save Dump, is recorded in the system log. The actual stop error message can be reviewed in the event details.

Note To include the recording of Event ID 1001 entries, the check box option Write an event to the system log must be selected to enable the recovery settings section of the System Control Panel applet.

• Modifying or Clearing of the Security Log. An attacker may try to modify the security logs, disable auditing during an attack, or clear the security log to prevent detection. If you notice large blocks of time with no entries in the security log, you should look for Event IDs 612 and 517 to determine which user modified the audit policy. All occurrences of Event ID 517 should be compared to a physical log indicating all times that the security log was cleared. An unauthorized clearing of the security log can be an attempt to hide events that existed in the previous security log. The name of the user that cleared the log is included in the event details.

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

Event ID	Description
608	A user right was assigned.
609	A user right was removed.
610	A trust relationship with another domain was created.
611	A trust relationship with another domain was removed.
612	An audit policy was changed.
768	A collision was detected between a namespace element in one forest and a namespace element in another forest. (Occurs when a namespace element in one forest overlaps a namespace element in another forest.)

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:

• Act as part of the operating system. Look for Event IDs 608 and 609 with user right seTcbPrivilege in the event details.

• Add workstations to the domain. Look for the events with user right SeMachineAccountPrivilege in the event details.

• Back up files and directories. Look for the events with user right SeBackupPrivilege in the event details.

• Bypass traverse checking. Look for events with user right SeChangeNotifyPrivilege in the event details. This right allows users to traverse a directory tree even if the user has no other permissions to access that directory.

• Change the system time. Look for events with user right SeSystemtimePrivilege in the event details. This right allows a security principal to change the system time, potentially masking when an event takes place.

• Create permanent shared objects. Look for events with the right SeCreatePermanentPrivilege in the event details. This allows a user to create file and print shares.

• Debug Programs. Look for events with user right SeDebugPrivilege in the event details. A holder of this user right can attach to any process. This right is, by default, only assigned to administrators.

• Force shutdown from a remote system. Look for events with user right SeRemoteShutdownPrivilege in the event details.

• Increase scheduling priority. Look for events with user right SeIncreaseBasePriorityPrivilege in the event details. A user with this right can modify process priorities.

• Load and unload device drivers. Look for events with user right SeLoadDriverPrivilege in the event details. A user with this user right could load a Trojan horse version of a device driver.

• Manage auditing and security log. Look for events with the SeSecurityPrivilege right in the event details. A user with this right can view and clear the security log.

• Replace a process level token. Look for events with user right SeAssignPrimaryTokenPrivilege in the event details. A user with this user right can change the default token associated with a started subprocess.

• Restore files and directories. Look for events with user right SeRestorePrivilege in the event details.

• Shut down the system. Look for events with user right SeShutdownPrivilege in the event details. A user with this user right could shut down the computer to initialize the installation of a new device driver.

• Take ownership of files or other objects. Look for events with user right SeTakeOwnershipPrivilege in the event details. A user with this right can access any object or file on an NTFS file system disk by taking ownership of the object or file.

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:

• Defining a policy for the storage, overwriting and maintenance of all event logs. The policy should define all required event log settings and be enforced by Group Policy.

• Ensuring that the policy includes how to deal with full event logs, especially the security log. It is recommended that a full security log require the shutdown of the server. This configuration may not be practical for some environments, but you should certainly consider it.

• Preventing guest access to the event logs by enabling the security policy settings to prevent local guests from accessing the system, application, and security logs.

• Ensuring that the system events are audited for both success and failure to determine whether any attempts are made to erase the contents of the security log.

• Enforcing use of complex passwords or two factor authentication methods such as smart card logon by all security principals that have the ability to view or modify audit settings to prevent attacks against these accounts to gain access to audit information.

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:

• Ensure that your security plan includes physical security of all servers to prevent an attacker from gaining physical access to the computer where auditing is performed. An attacker can remove audit entries by modifying or deleting the physical *.evt files on the local disk subsystem.

• Implement a method to remove or store the event logs in a location separate from the physical server. Such a method can include using Scheduled Tasks to write the event logs to CD-R or write once, read many media at regular intervals, or to other network locations separate from the server. If the backups are copied to external media such as backup tapes, or CD-R media, the media should be removed from the premises in the event of fire or other natural disasters.

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.

• Reviewing other application log files.

• Monitoring installed services and drivers.

• Monitoring open ports.

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:

• Faster detection of security issues. If daily review of the event logs is performed, a security event should never be older than 24 hours. Faster detection and repair of security vulnerabilities will result.

• Define responsibility. If regular review of event logs is required, the person tasked with reviewing the log files can be ultimately responsible for identifying potential attacks.

• Reduces the risk of events being overwritten or server down. After an event log is reviewed, the events in the log file can be archived for future review, and removed from the current event log. This practice reduces the risk of the event logs becoming full.

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:

• Internet Information Services (IIS). IIS creates log files that track connection attempts to Web, File Transfer Protocol (FTP), network time protocol (NTP), and Simple Mail Transfer Protocol (SMTP) services. Each service running under IIS maintains separate log files, and stores the log files in the World Wide Web Consortium (W3C) Extended Log File Format in the %WinDir%\System32\Logfiles folder. Each service maintains a separate folder for the logging information. Alternatively, you can configure IIS to store the logs into an Open Database Connectivity (ODBC)–compliant database, such as Microsoft® SQL Server™.

• Microsoft® Internet Security and Acceleration (ISA) Server. ISA Server provides logs for packet filters, the ISA Server Firewall Service, and the ISA Server Web Proxy Service. As with IIS, the logs are stored in the W3C Extended Log File Format by default but can be recorded to an ODBC-compliant database as an alternative. The ISA Server log files are stored in the C:\Program Files\Microsoft ISA Server\ISALogs folder by default.

• Internet Authentication Service (IAS). IAS provides centralized authentication and accounting for remote access authentication using the Remote Authentication Dial-In User Service (RADIUS) protocol. By default, accounting requests, authentication requests, and periodic status requests are logged to the IASlog.log file located in the %WinDir%\System32\Logfiles folder. Alternatively, the log file can be saved in a database compatible file format, rather than in IAS format.

• Third-Party Applications. Several third-party applications implement local logging functions to provide detailed information about the application. For more information, see the specific help files for your application.

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:

• The Services Console. The Services MMC console is used to monitor the services of either the local computer or a remote computer and allows an administrator to configure, pause, stop, start, and restart all installed services. Use this console to determine whether any services configured to start automatically are not currently started.

• Netsvc.exe. This command line tool, included in the Windows 2000 Server Resource Kit, allows an administrator to remotely start, stop, pause, continue, and query the status of services from the command line.

• SvcMon.exe. The Service Monitoring Tool monitors services on local and remote computers for changes in state (starting or stopping). To detect these changes, the tool implements a polling system. When a monitored service stops or starts, the tool notifies you by sending e-mail. You must configure the servers, polling intervals, and services to monitor by using the Service Monitor Configuration Tool (smconfig.exe).

• Drivers.exe. This tool displays all installed device drivers at the computer where the tool is executed. The output of the tool includes information that includes the driver's file name, the size of the driver on disk, and the date that the driver was linked. The link date can be used to identify any newly installed drivers. An updated driver that was not recently installed can indicate a replaced driver. Always correlate this information with a system restart event in the Event Viewer.

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:

• -a. Displays all connections and listening ports.

• -e. Displays Ethernet statistics. This parameter may be combined with the -s option.

• -n. Displays addresses and port numbers in numerical form.

• -p proto . Shows connections for the protocol specified by proto; proto may be TCP or UDP. If used with the -s option to display per protocol statistics, proto may be TCP, UDP, or Internet Protocol (IP).

• -r. Displays the routing table.

• -s. Displays per protocol statistics. By default, statistics are shown for TCP, UDP and IP; the -p option may be used to specify a subset of the default.

• interval. Redisplays selected statistics, pausing interval seconds between each display. Press CTRL+C to stop redisplaying statistics. If omitted, Netstat will print the current configuration information once.

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.

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

1. Select the specific event log in the console tree.

2. Select Filter from the View menu.

3. Select the parameters for filtering.

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

• Event types. The filter can be limited to information, warning, error, success audits, failure audits, or any combination of the event types.

• Event source. The specific service or driver that generated the event.

• Category. The filter can be limited to specific categories of events.

• Event ID. If you know the specific Event ID that you are searching for, the filter can limit the listing to that specific Event ID.

• User. You can limit the event display to events generated by a specific user.

• Computer. You can limit the event display to events generated by a specific computer.

• Date Intervals. You can limit the display to events that fall between specific beginning and ending dates.

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:

• -f file . Specifies the file name for the output file. There is no default for -f, so you must specify the file.

• -s server . Specifies the server for which you want to dump the event log. Leading backslashes on the server name are optional.

• -l log . Specifies which log (system, application, security) to dump. If an invalid log name is specified, the application log is dumped.

• -m source . Specifies in which source (such as redirector (rdr), serial, and so on) to dump records. Only one source can be supplied. If this switch is not used, all events are dumped. If a source is used that is not registered in the registry, the application log is searched for records of this type.

• -e n1 n2 n3 . Filters for event ID nn (up to 10 can be specified). If the -r switch is not used, only records of these types are dumped; if -r is used, all records except records of these types are dumped. If this switch is not used, all events from the specified sourcename are selected. You cannot use this switch without the -m switch.

• -r. Specifies whether to filter for specific sources or records, or to filter them out.

• -t. Specifies that individual strings are separated by tabs. If -t is not used, strings are separated by spaces.

• -d x . Dumps events for the past x days.

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:

• Define either a single Event ID , or multiple Event IDs to search for. You can include a single event ID, or multiple event IDs separated by spaces.

• Define a range of Event IDs to search for. The endpoints are inclusive. For example, if you want to search for all events between and including Event ID 528 and Event ID 540, you would define the range as 528 > ID < 540. This feature is useful because most applications that write to the event log use a sequential range of events.

• Limit the search to specific event logs. You can choose to search the system, application, and security logs. If executed locally at a domain controller, you can also choose to search FRS, DNS, and Active Directory logs.

• Limit the search to specific event message types. You can choose to limit the search to error, informational, warning, success audit, failure audit, or success events.

• Limit the search to specific event sources. You can choose to limit the search to events from a specific event source.

• Search for specific text within an event description. With each event, you can search for specific text. This capability is useful if you are trying to track specific users or groups.

Note You cannot include search logic, such as AND, OR, or NOT in the specific text. In addition, do not delimit text with quotes.

• Define specific time intervals to scan back from the current date and time. This approach allows you to limit your search to events in the past week, day, or month.

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

   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:

• System

• Application

• Security

• FRS (File Replication Service Log)

• DNS (DNS Server log)

• AD (Directory Service log)

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

• Error. This event is recorded in the application and system logs, and also appears in the FRS, DNS, and Directory Services logs.

• Informational. This event is recorded in the application and system logs, and also appears in the FRS, DNS, and Directory Services logs.

• Warning. This event is recorded in the application and system logs, and also appears in the FRS, DNS, and Directory Services logs.

• Success Audit. This event occurs in the security log or in the application log if the application registers success audits to the application log. For example, Active Directory Migration Tool (ADMT) logs success audit events to the application log.

• Failure Audit. This event occurs in the security log or in the application log if the application registers failure audits to the application log. For example, ADMT logs failure audit events to the application log.

• Success. This event is very rare and is found in the application or system logs, and also appears in the FRS, DNS, and Directory Services logs. In event viewer, success events are displayed as informational event type.

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

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

1. From the File menu, select Open Log Directory.

2. In the C:\Temp folder, double-click the output file for a domain controller to view the specific events logged by the EventCombMT tool. You should see output similar to the following:

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

   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

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.

3. Right-click the Select to Search/Right Click to Add box, and then click Select All Servers in List.

4. From the Searches menu, click Built In Searches, and then click Account Lockouts.

5. Click Search.

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

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:

• Support for all Windows 2000 logs. Support for the DNS Server, Directory Service, and FRS logs, in addition to the application, security, and system logs should be provided.

• Use of a Database Backend. The tool should allow the event logs to be stored in a database structure that allows inspection of previous event log entries for trend analysis and correlation of events between multiple servers.

• Search and Reporting Functionality. The tool should allow you to search for specific events based on provided criteria. The results should be presented in a readable manner.

Third-party products that provide event collection ability include:

• Event Log Monitor —TNT Software (www.tntsoftware.com)

• Event Archiver —Dorian Software Creations (www.doriansoft.com)

• LogCaster —RippleTech (www.rippletech.com)

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:

• Reconnaissance attacks. These attacks occur when an intruder is staking out a network, looking for vulnerabilities. Potential attacks include ping sweeps, DNS zone transfers, e-mail reconnaissance, port scans, and download of Web site content to look for vulnerable scripts and sample pages.

• Exploit attacks. These attacks occur when intruders take advantage of hidden features or bugs to gain access to the computer. Most often, the attack points were identified by a previous exploit attack.

• Denial of service (DoS) attacks. These attacks occur when an intruder attempts to crash a service running on a computer by overloading a resource, such as network links, the CPU, or the disk subsystem. The intruder is not trying to gain information, but is attempting to disable your computer from usage.

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

• Anomaly detection. This method takes a baseline of a computer on the network. Deviations from the baseline can identify an intrusion attempt. For example, an increase in logon attempts at off-peak hours can identify a compromised computer. The advantage of anomaly detection is that it can identify attacks without understanding exactly how the attack takes place.

• Signature recognition. This method identifies attacks based on well known patterns. Many Web server attacks use common patterns that are easily identifiable. By comparing incoming application traffic to signature strings in a database, an instruction detection system can identify these attacks. The disadvantage of this method of intrusion detection is that the signature database must frequently be updated to identify new attack signatures.

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

• Cisco Secure IDS (www.cisco.com/en/US/products/index.html)

• eTrust Intrusion Detection (www3.ca.com/Solutions/Product.asp?ID=163)

• Snort (www.snort.org)

• Tripwire (www.tripwiresecurity.com)

• Foundstone Attacker (www.foundstone.com)

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:

• Automated database update mechanism. The tool should provide an automated method to update the signatures for vulnerabilities so that the tool is not out of date after a short time.

• A filter to minimize false positives. The tool should filter out false positives so that an organization does not waste time investigating non-security events.

• Ability to store results in a database. The tool should allow archiving of scan results to perform trend analysis and detect changes in security over time.

• Solutions to vulnerabilities. If a vulnerability is found, the tool should provide documentation on how to fix the vulnerability or provide scripts that perform the tasks to protect against it.

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

• BindView Security Advisor (www.bindview.com)

• eEye Digital Security Retina Network Security Scanner (https://www.eeye.com/html/products/retina/index.html)

• Internet Security Systems (ISS) Internet Scanner (https://www.iss.net/products/
  Internet_Scanner/product_main_page.html)

• Symantec Enterprise Security Manager (https://www.symantec.com/Products/enterprise?c=prodinfo\&refId=855)

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.

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.

Download

Get the Securing Windows 2000 Server

Solution Accelerator Notifications

Sign up to stay informed

Feedback

Send us your comments or suggestions