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 6: Hardening the Base Windows 2000 Server

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.

Earlier chapters mention applying server hardening procedures to all of the servers at Contoso, Ltd., the company used in the overall scenario for this guide, to illustrate the policies and procedures required to secure Microsoft® Windows® 2000 servers in your organization.

This chapter explains the base settings applied to the member servers at Contoso. Changes that are needed for specific server roles are detailed in Chapter 7, "Hardening Specific Server Roles." These roles include the File and Print, Web, and Infrastructure roles. Many of the settings that appear in the Member Server Baseline Policy (MSBP) are also applied to the domain controller server role. The differences between the MSBP and the Domain Controller Baseline Policy are explained in Chapter 7, "Hardening Specific Server Roles."

Group Policy was used to apply as many of the changes to the default Windows 2000 Server configuration as possible. For the member servers in this scenario, the policy settings described are stored in the security template baseline.inf. This template was imported into the Member Server Baseline Policy Group Policy, which is linked to the Member Server organizational unit (OU).

The MSBP is an area of a risk management strategy focused on common settings for all member servers. It includes audit policies, service configuration, policies that restrict access to the registry, file system, and other specific security settings.

The location of the objects within the Active Directory® directory service at Contoso is highlighted in the following figure.

Figure 6.1  The security template baseline.inf is imported into the MSBP , which is then linked to the Member Servers OU

The settings contained within the baseline.inf security template are described in the "Windows 2000 Server Baseline Policy" section of this chapter. This security template was also used as the starting point for the security template called dcbaseline.inf.

The differences between baseline.inf and dcbaseline.inf are explained in Chapter 7, "Hardening Specific Server Roles." This template was imported into the Domain Controllers Policy Group Policy object (GPO) and linked to the Domain Controllers OU. Step-by-step instructions for creating the OUs and Group Policies, and then importing the appropriate security template into each GPO, are provided in Chapter 5, "Securing the Domain Infrastructure."

Note   Some hardening procedures cannot be automated through Group Policy. These policies are described in the "Additional Member Server Hardening Procedures" section of this chapter.

On This Page

Windows 2000 Server Baseline Policy
Additional Member Server Hardening Procedures
Summary

Windows 2000 Server Baseline Policy

The process of configuring the settings at the domain level defines the common settings for all member servers. This configuration is done by creating a GPO linked to the Member Server OU, known as a baseline policy. The GPO automates the process of configuring specific security settings on each server.

Audit and Event Log Settings

An audit log records an entry whenever users perform certain actions that you specify. For example, the modification of a file or a policy can trigger an audit entry. The audit entry shows the action performed, the associated user account, and the date and time of the action. You can audit both successful and failed attempts at actions.

The state of the operating system and applications on a computer is dynamic. For example, security levels may need to change temporarily to enable immediate resolution of an administration or network issue. If such changes are not reversed, a computer may no longer meet the requirements for enterprise security.

Regular analysis enables an administrator to track and ensure an adequate level of security on each computer as part of an enterprise risk management program. Analysis focuses on highly specified information about all security-related aspects of the computer. This analysis enables an administrator to tune the security levels and, most importantly, detect any security flaws that may occur over time.

Security auditing is extremely important for any enterprise system, as audit logs may give the only indication that a security breach has happened. If the breach is discovered some other way, proper audit settings generate an audit log that contains important information about the breach.

Often the failure logs are much more informative than success logs, because failures more often indicate error. For example, a successful user logon would be considered normal. However, multiple unsuccessful logons may indicate someone is trying to break in by using someone else's user ID.

The event logs record events on the computer. The security log records audit events. The event log container of Group Policy is used to define attributes related to the application, security, and system event logs, such as maximum log size, access rights for each log, and retention settings and methods. The settings for the application, security, and system event logs are configured in the MSBP and applied to all member servers in the Northamerica domain.

The following table shows the settings defined in the Member Server Baseline Auditing Policy.

Table 6.1  MSBP Audit and Event Log Policy Settings for Contoso

Full policy name as it appears in the User Interface (UI)	Computer setting
Audit account logon events	Success, Failure
Audit account management	Success, Failure
Audit directory service access	Success, Failure
Audit logon events	Success, Failure
Audit object access	Success, Failure
Audit policy change	Success, Failure
Audit privilege use	Failure
Audit process tracking	No Auditing
Audit system events	Success, Failure
Maximum application log size	10240 KB
Maximum security log size	81920 KB
Maximum system log size	10240 KB
Restrict guest access to application log	Enabled
Restrict guest access to security log	Enabled
Restrict guest access to system log	Enabled
Retain application log	Not defined
Retain security log	Not defined
Retain system log	Not defined
Retention method for application log	As needed
Retention method for security log	As needed
Retention method for system log	As needed
Shut down the computer when the security audit log is full	Disabled

Within the auditing and security options of the MSBP is a set of particularly important auditing and event log settings, which are highlighted in the following sections.

Auditing Settings

Vulnerability

If no auditing is configured, it will be difficult or impossible to determine what took place during a security incident. However, if auditing is configured so that too many authorized activities generate events, the security event log will fill up with useless data.

Countermeasure

All computers in your organization should have sensible auditing policies enabled so that legitimate users can be held accountable for their actions and unauthorized activity can be detected and tracked. The options for the auditing settings are:

• Success

• Failure

• No Auditing

Potential Impact

There will be no evidence available for network forensic analysis after security incidents take place if the auditing is configured too low on the computers in your organization. On the other hand, if too much auditing is enabled, then the security log will fill up with meaningless entries.

Contoso Scenario

For the Contoso network, appropriate auditing settings were chosen and implemented so that significant security events are recorded in the security event log while most unimportant ones are omitted. In Contoso's environment, we chose the auditing settings as shown in Table 6.1.

The Audit Process Tracking option was configured for No Auditing specifically because of the large number of events that could be created if the policy is enabled. This setting can provide a large amount of benefit during an incident response from the detailed log of the processes started and the time by any user.

Note   Turning on the capability to audit an object such as a file, folder, printer, or registry key is a two-step process in Windows 2000. After enabling the audit object access policy, you must determine the objects to which you want to monitor access and then modify their security descriptors accordingly.
For example, if you want to audit any attempts by users to open a particular file, you can configure a Success or Failure attribute directly on the file that you want to monitor for that particular event using Windows Explorer or a command-line tool such as Xcacls.exe.

Maximum Size for Application, Security, and System Logs

Vulnerability

If you significantly increase the number of objects in your organization to audit, you run the risk of filling the security log to capacity and thus forcing the computer to shut down. If such a shutdown occurs, the computer will be unusable until an administrator clears the security log. To prevent this type of shutdown, you should disable the shutdown option listed in the following Table 6.2 and increase the security log size. Both of these actions were taken in the Contoso scenario.

Countermeasure

All computers in your organization should have sensible log size policies enabled so that legitimate users can be held accountable for their actions, unauthorized activity can be detected and tracked, and problems can be detected and diagnosed. Several weeks' worth of data needed to be retained in the event logs for the Contoso servers. Additionally, the servers have plenty of space available on their system volumes. After a couple of weeks of testing, the busiest servers recorded as many as 5,000 security events in a single day. By multiplying that figure by 21 days and estimating the average event to take up 500 bytes or less within the log, a log size of about 120 MB was determined to be sufficient. Another 50 percent was then added to the event log size to provide a margin of error, which expanded it to 180 MB.

Although there is no simple equation to determine the best log size for a particular server, you can find a reasonable size through a bit of trial and error. Configure the log file size for a sample of production servers that represent the enterprise. Then, wait two business days and check to see how quickly the log files are filling up. Then increase or decrease the log file size as needed to make sure that they can hold several weeks' worth of events. Wait two more business days and check the logs again, adjusting the size as needed. Check the servers twice more over the next four weeks to verify that the logs are retaining enough events.

Potential Impact

When event logs fill to capacity, entries can no longer be written to them unless the retention method for each is configured so that newer entries will overwrite the oldest entries. In the Contoso scenario, the risk of the event logs not containing recent entries is mitigated by setting the retention method so that older events are overwritten as needed.

The consequence of this configuration is that older events will be removed from the logs. Attackers can use this configuration to their advantage by generating a large number of extraneous events to overwrite any evidence of their attack.

Ideally, all specifically monitored events will be sent to a server using Microsoft Operations Manager (MOM) or some other automated monitoring tool. This last point is particularly important because an attacker who successfully compromises a server could clear the security event log. If all events are sent to a monitoring server, then you will be able to gather forensic information about the attacker's activities.

Contoso Scenario

The maximum security log size was configured to a value of 184,320 KB in a Group Policy linked to the parent OU for Contoso's servers. The maximum application log size was configured to a value of 10,240 KB and the maximum system log size to a value of 10,240 KB. These values were chosen to balance the use of disk space on the system volume with the ability to review older events.

Contoso is using MOM to monitor the server roles discussed in this guidance for security-related events.

Retention Method for Application, Security, and System Logs

Vulnerability

If you significantly increase the number of objects in your organization to audit, you run the risk of filling the security log to capacity and thus forcing the computer to shut down. If such a shutdown occurs, the computer will be unusable until an administrator clears the security log. To prevent this type of shutdown, you should disable the shutdown option listed in Table 6.2 and increase the security log size. Both of these actions were taken in the Contoso scenario.

Setting the event log retention method to Manually or Overwrite events by days could lead to important recent events not being recorded or to a Denial of Service (DoS).

Countermeasure

Configure Retention method for the system log to a value of Overwrite events as needed in the Group Policy linked to the parent OU for all servers in your organization. Some resources recommend configuring this setting to Manual; however, the administrative burden that this setting imposes is too high for most organizations.

Ideally, all significant events will be sent to a monitoring server using MOM or some other automated monitoring tool. The retention method settings are:

• Overwrite events by days

• Overwrite events as needed

• Do not overwrite events (clear log manually)

• Not defined

Potential Impact

When event logs fill to capacity, entries can no longer be written to them unless the retention method is configured so that the computer overwrites the oldest entries with the most recent ones.

Contoso Scenario

In the Contoso scenario, the risk of the event logs not containing recent entries is mitigated by setting the retention method so that older events are overwritten as needed. The consequence of this configuration is that older events will be removed from the logs. Ideally, all significant events will be sent to a monitoring server using MOM or some other automated monitoring tool. For these reasons, in Contoso's environment the Group Policy in Retention method for event logs was configured to Overwrite events as needed. Chapter 9, “Auditing and Intrusion Detection,” discusses some significant events to watch for and methods for assessing and responding to information in the logs.

Shut Down the Computer When the Security Audit Log Is Full

Vulnerability

Security event logs contain highly critical information and must be acted upon quickly because these logs record any failures or potential security issues on your servers. And these events can have a cascading effect on all computers that depend on these servers. As a part of your regular operations tasks, you should archive your security and system logs regularly to avoid losing this important event log information.

In some organizations, it may be sufficient to retain event log information for only one or two days, because most services failures will be noticed within this time period. However, some servers generate a great deal of activity in most audited environments. Therefore, it may be necessary to retain event records for longer periods, or, in some cases, permanently.

An enterprise event management system, such as MOM, is a useful tool for centralizing, managing, and archiving your event records in a central database. MOM is a Microsoft product that provides centralized event and performance management of Microsoft Windows 2000–based servers and applications.

Countermeasure

Configure Shut down the computer when the security audit log is full to a value of Enabled in the Group Policy linked to the parent OU for all servers in your organization. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

Enabling this option means that servers will shut down immediately when their event logs are full. If your organization saves all event log data to MOM or some other enterprise management system, and the event logs are configured to overwrite entries as needed, then enabling this setting is a good idea. However, for many organizations the administrative burden of enabling this setting is too high.

Contoso Scenario

The default configuration of the Shut down the computer when the security audit log is full setting is Not Defined in Windows 2000 Server. In the Contoso scenario, this setting was Disabled. Although it is a security best practice to retain every security log entry to track all attempted or successful attacks, it is impossible to prevent an attacker who has gained administrative rights on a computer from deleting some or all security log entries from the local security event log.

When you consider this information, you will understand that configuring the computer to shut down when the security audit log fills up only ensures that the computer does not overwrite existing entries. This configuration does nothing to prevent attackers from altering or deleting entries. As mentioned earlier, an enterprise event management system is necessary to mitigate against this vulnerability, by copying log entries off the computers before they can be altered or deleted.

User Rights Assignment Configuration

Debug Programs

Vulnerability

The debug privilege can be exploited to capture sensitive information from the computer's memory. Some attack tools exploit the debug program's user right to extract hashed passwords and other private security information. The risk of attackers being able to exploit this vulnerability is mitigated by the fact that the debug program's user right is by default assigned only to administrators.

Countermeasure

Revoke the Debug programs user right from all users and groups.

Potential Impact

Revoking this privilege will result in no one being able to debug programs. However, under normal circumstances debugging is rarely necessary on production computers and networks. If a problem arises that requires debugging an application on a production server temporarily, move the server to a different OU and assign the Debug programs user right to the appropriate account.

Contoso Scenario

In the Contoso scenario, it was anticipated that administrators would rarely need to debug applications; therefore, Group Policy was used to remove all groups from the Debug programs user right.

MSBP Security Options

The Security Options section of Group Policy is used to enable or disable security settings for computers, such as digital signing of data, Administrator and Guest account names, floppy disk drive and CD-ROM drive access, driver installation behavior, and logon prompts. The following security options are configured in the baseline Group Policy.

Table 6.2  MSBP Security Option Settings

Full security option name as it appears in the UI	Computer setting
Additional restrictions for anonymous connections	Do not allow enumeration of SAM accounts and shares
Allow server operators to schedule tasks (domain controllers only)	Disabled
Allow system to be shut down without having to log on	Disabled
Allowed to eject removable NTFS media	Administrators
Amount of idle time required before disconnecting session	15 minutes
Audit the access of global system objects	Disabled
Audit use of Backup and Restore privilege	Disabled
Automatically log off users when logon time expires (see the note at the end of this table)	Not Defined
Automatically log off users when logon time expires (local) (see the note at the end of this table)	Enabled
Clear virtual memory page file when system shuts down	Enabled
Digitally sign client communication (always)	Disabled
Digitally sign client communication (when possible)	Enabled
Digitally sign server communication (always)	Disabled
Digitally sign server communication (when possible)	Enabled
Disable CTRL+ALT+DEL requirement for logon	Disabled
Do not display last user name in logon screen	Enabled
LAN Manager Authentication Level	Send NTLMv2 responses only
Message text for users attempting to log on	(Organizations should specify appropriate text that has been approved by legal and human resources respresentatives.)
Message title for users attempting to log on	(Organizations should specify appropriate text that has been approved by legal and human resources respresentatives.)
Number of previous logons to cache (in case domain controller is not available)	10 logons
Prevent system maintenance of computer account password	Disabled
Prevent users from installing printer drivers	Enabled
Prompt user to change password before expiration	14 days
Recovery Console: Allow automatic administrative logon	Disabled
Recovery Console: Allow floppy copy and access to drives and folders	Enabled
Rename administrator account	Not defined
Rename guest account	Not defined
Restrict CD-ROM drive access to locally logged-on user only	Disabled
Restrict floppy access to locally logged-on user only	Disabled
Secure channel: Digitally encrypt or sign secure channel data (always)	Disabled
Secure channel: Digitally encrypt secure channel data (when possible)	Enabled
Secure channel: Digitally sign secure channel data (when possible)	Enabled
Secure channel: Require strong (Windows 2000 or later) session key	Enabled
Secure system partition (for RISC platforms only)	Not defined
Send unencrypted password to connect to third-party SMB servers	Disabled
Shut down system immediately if unable to log security audits	Disabled
Smart card removal behavior	Lock Workstation
Strengthen default permissions of global system objects (for example, Symbolic Links)	Enabled
Unsigned driver installation behavior	Warn but allow installation
Unsigned non-driver installation behavior	Silently succeed

Note   For domain accounts, there can be only one account policy. The account policy must be defined in the Default Domain Policy, which is enforced by the domain controllers that make up the domain. A domain controller always pulls the account policy from the Default Domain Policy GPO, even if there is a different account policy applied to the OU that contains the domain controller.
By default, workstations and servers joined to a domain (the member computers) also receive the same account policy for their local accounts. However, local account policies for member computers can be made different from the domain account policy by defining an account policy for the OU that contains the member computers.

The default domain policy configures Automatically log off users when logon time expires to Disabled.

Because the security options in Table 6.2 merit additional explanation, the rest of this section focuses on explaining the logic behind each setting implemented in the Contoso scenario, as well as what other options are available for each one.

Additional Restrictions for Anonymous Connections

Vulnerability

By default, Windows 2000 allows anonymous users to perform certain activities such as enumerating the names of domain accounts and network shares. This capability allows potential attackers to view information on a remote server without having to authenticate who they are with a user account.

Although this vulnerability does not allow an attacker to compromise your server, it could provide the attacker with additional information to mount an attack. To better secure anonymous access, this option can be changed through Group Policy or by means of the registry.

Countermeasure

The anonymous user functionality can be changed by modifying the registry value entry RestrictAnonymous located in the HKLM\SYSTEM\CurrentControlSet\Control\
LSA registry key to one of the following values:

• 0—Rely on default permissions.

• 1—Do not allow enumeration of Security Accounts Manager (SAM) accounts and shares.

• 2—No access without explicit anonymous permissions.

The default value for the Local Security Authority (LSA) value entry in Windows 2000 is
0—Rely on default permissions.

Additionally, the option Additional Restrictions for Anonymous Connections can also be configured through Group Policy to provide the same functionality. This value can be configured to:

• None: Rely on default permissions

  This value provides the same functionality as RestrictAnonymous = 0.

• Do not allow enumeration of SAM accounts and shares

  This value provides the same functionality as RestrictAnonymous = 1.

• No access without anonymous permissions

  This value provides the same functionality as RestrictAnonymous = 2.

Potential Impact

Setting RestrictAnonymous to 1 does not actually block anonymous connections. However, this value does prevent most of the information leaks available over the null session, primarily enumeration of user accounts and shares. Without setting this value to 2, some of this information can still be obtained.

However, setting the value to 2 can produce several undesirable results, depending on the target environment. The following applications and services are known to break when RestrictAnonymous is configured to 2:

• The RestrictAnonymous = 2 setting is recommended for Windows 2000 in various white papers and tools from Microsoft and other sources, including the MBSA tool, but the setting is supported only in environments where all computers are running Windows 2000 or later. Support from Microsoft Product Support Services (PSS) for Windows 2000 will be provided on a best-effort basis only. Also, the effect of the Windows 2000 RestrictAnonymous setting is spread across more than one policy setting in the later supported platforms. If you want to use RestrictAnonymous = 2 in your environment, proceed at your own risk and test it thoroughly in your platform testing environment for application incompatibility.

• Down-level member workstations or servers cannot set up a secure channel to the server.

• Down-level domain controllers in trusting domains cannot set up a Net logon secure channel to domain controllers with the RestrictAnonymous registry value configured to 2.

• Microsoft Windows NT® users cannot change their passwords after the passwords expire. Also, Macintosh computer users cannot change their passwords at all.

• The Browser service cannot retrieve domain lists or server lists from backup browsers, master browsers, or domain master browsers that are running on computers with the RestrictAnonymous registry value configured to 2. Therefore, any program that relies on the Browser service does not function properly.

• If you use a Microsoft Outlook® client computer that connects to a Microsoft Exchange 2000 Server, you will not be able to look through the global address list or resolve names referenced from it. The global address list appears as empty. This issue was fixed in Windows 2000 Service Pack 3.

• You may not be able to add a network printer by selecting it from the Active Directory on domain controllers with the RestrictAnonymous registry value configured to 2. However, you can still add a network printer by selecting it from the tree view.

Because of these known issues, it is not recommended to configure RestrictAnonymous to 2 in a mixed client environment. For details on the effect that this setting may have in your environment, see Microsoft Knowledge Base article 246261, "How to use the RestrictAnonymous registry value in Windows 2000," at https://support.microsoft.com/default.aspx?scid=246261.

Contoso Scenario

In the Contoso scenario, Group Policy was used to configure Additional Restrictions for Anonymous Connections to Do not allow enumeration of SAM accounts and shares because of the scenario's mixed client environment.

Allow System to Be Shut Down Without Having to Log On

Vulnerability

Users who can access the console locally or through Terminal Services could shut the computer down. An attacker or a misguided user could connect to the server through Terminal Services and shut it down or restart it without having to identify himself or herself.

An attacker could also perform this action by walking up to the local console. A server will be restarted, causing a temporary DoS condition, or a server will be shut down leaving all of its applications and services unavailable.

Countermeasure

Configure the Allow system to be shut down without having to log on to the value Disabled in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

Administrators will have to log on to servers to shut them down or restart them.

Contoso Scenario

In the Contoso scenario, there is no reason for users to be able to shut down servers from the console without needing to log on first. Therefore, Group Policy was used to configure Allow system to be shut down without having to log on to Disabled.

Allowed to Eject Removable NTFS Media

Vulnerability

Users may be able to move NTFS-formatted removable disks to a different computer where they have administrative privileges. If a removable disk is moved to a computer where the user has administrative privileges, the user could take ownership of any file, assign themselves full control, and view or modify any file. Sensitive information may be exposed, or data could be altered in an undetectable way. The value of this setting is diminished by the fact that most removable storage devices will eject media at the press of a button.

Countermeasure

Configure the Allowed to eject removable NTFS media value to Administrators in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• User-defined security accounts

• Not defined

Potential Impact

Only administrators will be able to eject NTFS-formatted removable media.

Contoso Scenario

The only people who need to be able to remove NTFS-formatted removable media are administrators. Therefore, in the Contoso scenario, Group Policy was used to configure Allowed to eject removable NTFS media to the Administrators group.

Amount of Idle Time Required Before Disconnecting Session

Vulnerability

Each server message block (SMB) session consumes server resources. If numerous null sessions are established, the server will slow down or possibly fail. An attacker could repeatedly establish SMB sessions until the server stops responding. SMB services will become slow or unresponsive

Countermeasure

Configure Amount of idle time required before disconnecting session to the value 15 minutes in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• User-defined period of time in minutes

• Not defined

Potential Impact

There will be little impact because SMB sessions will be reestablished automatically if the client resumes activity.

Contoso Scenario

To help protect the Contoso servers from SMB-based DoS attacks, Group Policy was used to configure Amount of idle time required before disconnecting session to 15 minutes.

Audit the Access of Global System Objects

Vulnerability

If this policy setting is enabled, it causes system objects, such as mutexes, events, semaphores, and DOS devices, to be created with a default system access control list (SACL). If the Audit object access audit policy is also enabled, access to these system objects is audited.

Countermeasure

Configure the Audit the access of global system objects value to Disabled in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

Enabling this policy setting could generate a large number of security events, especially on busy domain controllers and application servers. This activity could cause servers to respond slowly and force the security event log to record numerous events of little significance.

Contoso Scenario

To help prevent the security event logs on the Contoso servers from filling with unimportant events, Group Policy was used to configure Audit the access of global system objects to Disabled.

Audit Use of Backup and Restore Privilege

Vulnerability

This setting determines whether backup and restore user privileges are audited when the Audit privilege use policy is in effect. Enabling this option when the Audit privilege use policy is also enabled generates an audit event for every file that is backed up or restored. Enabling this setting could help you to track down an administrator who is accidentally or maliciously restoring data in an unauthorized manner.

Countermeasure

Configure the Audit use of Backup and Restore privilege value to Disabled in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

Enabling this policy setting could generate a large number of security events, which could cause servers to respond slowly and force the security event log to record numerous events of little significance.

Contoso Scenario

To help prevent the security event logs on the Contoso servers from filling with unimportant events, Group Policy was used to configure Audit use of Backup and Restore privilege to Disabled.

Automatically Log Off Users When Logon Time Expires (Local)

Vulnerability

This setting determines whether to disconnect users who are connected to the local computer outside of their user account's valid logon hours. This setting affects the SMB component of a Windows 2000 Server. When this policy setting is enabled, it causes client sessions with the SMB server to be forcibly disconnected when the client's logon hours expire. If this policy setting is disabled, an established client session is allowed to be maintained after the client's logon hours have expired.

Countermeasure

Configure the Automatically log off users when logon time expires (local) value to Enabled in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

This setting does not apply to administrator accounts.

Potential Impact

SMB sessions will be terminated on member servers when a user's logon time expires, and the user will be unable to log on until their next scheduled access time commences.

Contoso Scenario

To help protect servers in the Contoso scenario from members of the information technology (IT) team who forget to log off their console sessions, Group Policy configured Automatically log off users when logon time expires (local) to Enabled.

Clear Virtual Memory Page File When System Shuts Down

Vulnerability

Important information kept in real memory may be dumped periodically to the page file, which helps Windows 2000 handle multitasking functions. An attacker who has physical access to a server that has been shut down could view the contents of the page file. The attacker would move the system volume into a different computer and then analyze the contents of the page file. This process is time-consuming, but data cached from RAM to the page file could be exposed.

Note   An attacker who has physical access to the server could bypass this countermeasure by simply unplugging the server from its power source.

Countermeasure

Configure the Clear virtual memory page file when system shuts down value to Enabled in the Group Policy linked to the parent OU for servers. With this setting enabled, Windows 2000 will clear the page file when the computer is shut down, removing all information stored in this file. Depending on the size of the page file, this process could take several minutes before the computer completely shuts down. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

Shutting down and restarting the server will take longer and will be especially noticeable on servers with large page files. For a server with 2 GB of RAM and a 2-GB page file this setting may add 20 minutes, 30 minutes, or even more to the shutdown process. For some organizations, downtime of this duration violates their internal service level agreements. Therefore, use caution when implementing this countermeasure in your environment.

Contoso Scenario

Although the Contoso servers are physically secured, Contoso decided to implement this setting because it is more secure and it will have no impact on legacy applications and operating systems connecting to the server. Group Policy is used to configure Clear virtual memory page file when system shuts down to Enabled.

Digitally Sign Client and Server Communications

Vulnerability

There are four separate settings relating to digitally signing SMB communications: Digitally sign client communications (always), Digitally sign server communications (always), Digitally sign client communications (when possible), and Digitally sign server communications (when possible).

Implementing digital signing in high-security networks helps prevent the impersonation of clients and servers. This type of impersonation is known as session hijacking—a type of exploit in which session hijacking tools allow an attacker to interrupt, end, or steal a session in progress. Unsigned SMB packets could be intercepted and modified by an attacker. An attacker who had access to the same network as the client or server could intercept SMB traffic. The attacker could then modify the traffic and forward it so that the server might perform undesirable actions. Alternatively, the attacker could pose as the server or client after a legitimate authentication and gain unauthorized access to data.

SMB signing authenticates both the user and the server hosting the data. If either side fails the authentication process, data transmission will not take place. When SMB signing is implemented, there may be a noticeable performance impact from signing and verifying each packet between the servers.

Note   An alternative countermeasure that could protect all network traffic would be to implement digital signatures with Internet Protocol security (IPsec). There are hardware-based accelerators for IPsec encryption and signing that could be used to minimize the performance impact from the servers' CPU. There are no such accelerators available for SMB signing.

Countermeasure

Configure Digitally sign client communication (always) to Disabled; Digitally sign client communication (when possible) to Enabled; Digitally sign server communication (always) to Disabled; and Digitally sign server communication (when possible) to Enabled in a Group Policy linked to the parent OU for servers. Some resources recommend configuring all of these settings to Enabled, but enabling all of them may cause slower performance on client computers, and it will prevent client computers from communicating with legacy SMB applications and operating systems. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

The Windows 2000 Server, Windows 2000 Professional, and Windows XP Professional file and print sharing protocol SMB supports mutual authentication, which closes session hijacking attacks and supports message authentication, thus preventing active message attacks. SMB signing provides this authentication by placing a digital signature into each SMB, which is then verified by both the client and the server.

However, forcing all SMB traffic to be digitally signed will have a performance impact; on busy servers; this impact could be substantial. Additionally, when computers are configured to ignore all unsigned SMB communications, legacy applications and operating systems will be unable to connect. Completely disabling all SMB signing leaves the computers vulnerable to session hijacking attacks.

Contoso Scenario

In the Contoso scenario, Digitally Sign was disabled on all SMB traffic because of concerns about performance. Group Policy was used to configure Digitally sign client communication (always) to Disabled; Digitally sign client communication (when possible) to Enabled; Digitally sign server communication (always) to Disabled; and Digitally sign server communication (when possible) to Enabled.

Disable CTRL+ALT+DEL Requirement for Logon

Vulnerability

Microsoft developed this feature to make it easier for users with certain types of physical impairments to log on to computers running Windows. Not having to press the key combination CTRL+ALT+DEL leaves users susceptible to attacks that attempt to intercept their passwords. Requiring CTRL+ALT+DEL before users log on ensures that users are communicating by means of a trusted path when entering their passwords.

An attacker could install a Trojan horse program (a type of malicious code) that looks like the standard Windows logon dialog box and capture the user's password. The attacker would then be able to log on to the compromised account with whatever level of privilege that user has.

Countermeasure

Configure Disable CTRL+ALT+DEL requirement for logon to Disabled in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

Users have to simultaneously hold down three keys before the logon dialog box will appear (unless they are using a smart card to log on).

Contoso Scenario

In the Contoso scenario, there is no reason for users to be able to log on to a server without pressing the three keys. Therefore, Group Policy was used to configure the value for the Disable CTRL+ALT+DEL requirement for logon setting to Disabled.

Do Not Display Last User Name in Logon Screen

Vulnerability

An attacker with access to the console—for example, somebody with physical access or somebody who is able to connect to the server through Terminal Services—could view the name of the last user who logged on to the server. The attacker could then attempt to log on to the server by guessing the password, using an automated tool to determine the password from a dictionary, or by brute force.

Countermeasure

Configure Do not display last user name in logon screen to the value Enabled in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

Users will always have to type their user names when logging on to the servers.

Contoso Scenario

In the Contoso scenario, there was concern that an attacker could view the user name of the last user to log onto a server. Therefore, Group Policy was used to configure Do not display last user name in logon screen to Enabled.

LAN Manager Authentication Level

LAN Manager (LM) is a family of early Microsoft client/server software that allows users to link personal computers together on a single network. Networking capabilities include transparent file and print sharing, user security features, and network administration tools.

LM authentication, including the LM, NTLM, and NTLM version 2 (NTLMv2) variants, is the protocol used to authenticate all Windows clients for such operations as:

• Joining a domain

• Authenticating between Active Directory forests

• Authenticating to down-level domains

• Authenticating to down-level servers (those not running Windows 2000 or Windows XP)

• Authenticating to nondomain servers

Vulnerability

All Windows clients (including Windows 2000 and Windows XP) are configured by default to send LM and NTLM authentication responses (except Win9x clients, which only send LM). The default setting on servers allows all clients to authenticate with servers and use their resources. However, this configuration means that LM responses (the weakest form of authentication response) will be sent over the network, and will potentially be available for attackers to sniff that traffic and attempt to more easily reproduce the user's password.

The Windows 9x and Windows NT operating systems cannot use the Kerberos version 5 protocol for authentication. For this reason, by default these operating systems use both the LM and NTLM protocols for network authentication in a Windows 2000 domain. You can enforce a more secure authentication protocol for Windows 9x and Windows NT by using NTLMv2. For the logon process, NTLMv2 uses a secure channel to protect the authentication process. Even if you use NTLMv2 for legacy clients and servers, Windows 2000–based clients and servers that are members of the domain will authenticate with Windows 2000 domain controllers using the Kerberos protocol.

For information about enabling NTLMv2, see Microsoft Knowledge Base article 239869, "How to enable NTLM 2 authentication" at https://support.microsoft.com/default.aspx?scid=239869. Windows NT 4.0 requires Service Pack 4 (SP4) to support NTLMv2, and Windows 9x platforms need the directory service client installed to support NTLMv2.

Countermeasure

Configure LAN Manager Authentication Level to Send NTLMv2 responses only in the Group Policy linked to the parent OU for servers. This level of authentication is strongly recommended by Microsoft and a number of independent organizations when all clients support NTLMv2.

The possible values for this policy setting are:

• Send LM & NTLM responses

• Send LM & NTLM—use NTLMv2 session security if negotiated

• Send NTLM responses only

• Send NTLMv2 responses only

• Send NTLMv2 responses only\refuse LM

• Send NTLMv2 responses only\refuse LM & NTLM

• Not Defined

These settings correspond to the levels discussed in other documents from Microsoft as follows:

• Level 0—Send LM and NTLM response; never use NTLMv2 session security. Clients use LM and NTLM authentication, and never use NTLMv2 session security; domain controllers accept LM, NTLM, and NTLMv2 authentication.

• Level 1—Use NTLMv2 session security if negotiated. Clients use LM and NTLM authentication, and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication.

• Level 2—Send NTLM response only. Clients use only NTLM authentication, and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication.

• Level 3—Send NTLMv2 response only. Clients use NTLMv2 authentication, and use NTLMv2 session security if the server supports it; domain controllers accept LM, NTLM, and NTLMv2 authentication.

• Level 4—Domain controllers refuse LM responses. Clients use NTLM authentication, and use NTLMv2 session security if the server supports it; domain controllers refuse LM authentication (that is, they accept NTLM and NTLMv2).

• Level 5—Domain controllers refuse LM and NTLM responses (accept only NTLMv2). Clients use NTLMv2 authentication, and use NTLMv2 session security if the server supports it; domain controllers refuse NTLM and LM authentication (they accept only NTLMv2).

Potential Impact

Clients that do not support NTLMv2 authentication will not be able to authenticate in the domain and access domain resources using LM and NTLM.

Contoso Scenario

In the Contoso scenario, Group Policy was used to configure the LAN Manager Authentication Level to Send NTLMv2 responses only. This setting was chosen so that legacy Windows clients that are not configured to use NTLMv2 security can still use the domain resources. This configuration means that the less secure authentication traffic will pass over the network. An attacker who is able to sniff traffic on the network may be able to collect NTLM authentication traffic to determine user names and passwords of domain members. Network sniffing is the inspection of network traffic.

The Windows 98 clients will continue to use LM or NTLM authentication, and will continue to be authenticated by the domain controllers because of the setting configuration. These computers could be configured to use only NTLMv2 if the DSClient was installed on the computers. Because of the large amount of work required to install the DSClient on all Windows 98 computers, Contoso has accepted the fact that this vulnerability will exist until these workstations are updated.

Note   For information about a hotfix to ensure that this setting works in networks with a mix of Windows 2000 and Windows NT 4.0 computers, see Microsoft Knowledge Base article 305379, "Authentication Problems in Windows 2000 with NTLM 2 Levels Above 2 in a Windows NT 4.0 Domain," at https://support.microsoft.com/default.aspx?scid=305379.

Message Title and Text for Users Attempting to Log On

Vulnerability

Displaying a warning message before logon may help prevent an attack by warning the attacker of their misconduct before it happens. It may also help to reinforce organizational policy by notifying employees of the appropriate policy during the logon process.

Countermeasure

Configure the Message text for users attempting to log on and Message title for users attempting to log on to an appropriate value for your organization.

Apply both of these settings in the Group Policy linked to the parent OU for servers. The possible values for these policy settings are:

• User-defined text

• Not defined

Potential Impact

Users will see a dialog box before they will be able to log on to the console of the server.

Note   Any warning that displays should be approved by your organization's legal and human resources representatives.

Contoso Scenario

Contoso used Group Policy to configure the Message text for users attempting to log on and Message title for users attempting to log on settings.

Number of Previous Logons to Cache (in Case Domain Controller is Not Available)

Vulnerability

The number assigned to this setting indicates the number of users whose logon information will be cached locally. If the number is configured to 10, then the logon information for 10 users will be cached. When an eleventh user logs on to the computer, the oldest cached logon session will be overwritten.

Users who access the console of the server will have their logon credentials cached on that server. An attacker who is able to access the file system of the server could locate this cached information and use a brute-force attack to determine passwords for the users.

This type of attack is mitigated by the way in which Windows 2000 secures this sensitive information. The cached credentials are kept in the registry, which is encrypted and spread across numerous physical locations.

Countermeasure

Configure Number of previous logons to cache (in case domain controller is not available) to a value of 10 in the Group Policy linked to the parent OU for servers. Some resources suggest setting this value to 0.

This setting was configured so that in the event of failure to communicate with a domain controller, users will still be able to log on to computers. The possible values for this policy setting are:

• User-defined number

• Not defined

Potential Impact

Logon information will be cached locally on the servers.

Contoso Scenario

To ensure that authorized users could log on to the Contoso servers even when the domain controllers were unavailable, Group Policy is used to configure Number of previous logons to cache (in case domain controller is not available) to 10.

Prevent System Maintenance of Computer Account Password

Vulnerability

The default configuration for computers running Windows 2000 that belong to a domain is that they are automatically required to change the passwords for their accounts every seven days. Disabling this feature causes computers running Windows 2000 to retain the same passwords as their computer accounts. Computers that are no longer able to automatically change their account passwords are under risk of an attacker determining the password for the computer's domain account.

Countermeasure

Verify that the Prevent system maintenance of computer account password option is configured to Disabled. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

None.

Contoso Scenario

In the Contoso scenario, we want to minimize the risk of an attacker determining a computer's password for its domain account. Therefore, Group Policy is used to configure Prevent system maintenance of computer account password to Disabled.

Prevent Users from Installing Printer Drivers

Vulnerability

It may be appropriate to enable users to allow printer access on their own workstations, but this capability is not suitable for servers. Installing a printer driver on a server may unintentionally cause it to become less stable. Only administrators should have this privilege on servers.

A malicious user may deliberately try to damage your organization's network by installing inappropriate printer drivers. A malicious user is anyone who has access to a computer system and poses a security threat to it. An example would be people who try to elevate their privileges to gain access to unauthorized data.

Countermeasure

Configure Prevent users from installing printer drivers to the value Enabled in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

Only users with Administrative, Power User, or Server Operator privileges will be able to install printers on the servers.

Contoso Scenario

In the Contoso scenario, only administrators should ever need to install printer drivers. Therefore, Group Policy was used to configure Prevent users from installing printer drivers to the value Enabled.

Prompt User to Change Password Before Expiration

Vulnerability

In the Contoso scenario, user passwords expire periodically. If users are not notified when their passwords are about to expire, they may not realize it until the passwords have already expired. Users who access the network locally could become confused, and remote users who access your organization's network through dial-up or virtual private network (VPN) connections may not be able to log on to the network.

Countermeasure

Configure Prompt user to change password before expiration to a value of 14 days in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• User defined number of days

• Not defined

Potential Impact

Users will see a dialog box each time that they log on to the domain when the expiration date for their password is 14 days or less in the future.

Contoso Scenario

In the Contoso scenario, the security team wanted to be sure that users changed their passwords before they expired. Therefore, Group Policy was used to configure Prompt user to change password before expiration to 14 days.

Recovery Console: Allow Automatic Administrative Logon

Vulnerability

The Recovery Console can be very useful when troubleshooting and repairing computers that cannot be restarted. However, configuring this setting to enable automatic logon to the console is dangerous. Anyone could walk up to the server, shut it down by disconnecting the power, reboot it, select Recover Console from the restart menu, and then assume full control of the server.

Countermeasure

Configure Recovery Console: Allow automatic administrative logon to Disabled in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

When the Recovery Console is used, the user will have to enter a user name and password to access the Recovery Console account.

Contoso Scenario

In the Contoso scenario, whenever the Recovery Console must be used, an authorized member of the IT team will be present to troubleshoot and repair the computer. Therefore, Group Policy was used to configure Recovery Console: Allow automatic administrative logon to Disabled.

Recovery Console: Allow Floppy Copy and Access to Drives and Folders

Vulnerability

An authorized administrator could forget to remove a CD-ROM or floppy disk with sensitive data or applications that a malicious user could then steal. An authorized administrator could accidentally leave a startup disk in the computer after having used the Recovery Console. If the computer restarted for any reason and the BIOS was configured to boot from the CD-ROM or floppy disk drive before the hard disk, the server would start from the removable disk and cause the server's network services to be unavailable.

Countermeasure

Configure Recovery Console: Allow floppy copy and access to drives and folders to the value Enabled in the Group Policy linked to the parent OU for servers. Some resources suggest disabling this setting. However, enabling it gives the administrator more flexibility when working with a failed server through the Recovery Console. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

Users who have started a server by means of the Recovery Console and logged in with the built-in Administrator account will not be able to copy files and folders to a floppy disk.

Contoso Scenario

In the Contoso scenario, it was decided to retain the option to be able to copy files from a CD-ROM or floppy disk while using the Recovery Console to repair an unusable server. Therefore, Group Policy was used to configure Recovery Console: Allow floppy copy and access to drives and folders to Enabled.

Restrict Removable Media Access to Locally Logged-On User Only

Vulnerability

This policy setting determines whether a CD-ROM is accessible to both local and remote users simultaneously. If this policy setting is enabled, it allows only the interactively logged-on user to access removable CD-ROM media. If this policy setting is enabled and no one is logged on interactively, the CD-ROM can be accessed over the network.

Countermeasure

Configure both Restrict CD-ROM drive access to locally logged-on user only and Restrict floppy access to locally logged-on user only to Disabled in the Group Policy linked to the parent OU for servers. The possible values for these policy settings are:

• Enabled

• Disabled

• Not defined

Potential Impact

If this setting is enabled, users connecting to the server over the network will not be able to use any CD -ROM or floppy disk drives installed on the server. Additionally, this setting causes problems for management tools that make the most of WMI. For example, when this setting is enabled, the Disk Management console will take as long as 30 seconds to open and, after it opens, no CD-ROM drives will appear in the tool. This setting would not be suitable for a computer that serves as a CD jukebox for network users.

Contoso Scenario

Because Contoso relies on the Disk Management tool for managing storage volumes, these settings were disabled. Group Policy was used to configure Restrict CD-ROM drive access to locally logged-on user only to Disabled and to configure Restrict floppy access to locally logged-on user only to Disabled.

Secure Channel: Digitally Encrypt or Sign Secure Channel Data

Vulnerability

When a Windows 2000 system joins a domain, a computer account is created. After joining the domain, it uses the password for that account to create a secure channel with the domain controller for its domain every time it restarts. Requests sent on the secure channel are authenticated, and sensitive information (such as passwords) is encrypted. But the channel is not integrity-checked, and not all information is encrypted. There are several settings relating to this countermeasure: Secure channel: Digitally encrypt or sign secure channel data (always); Secure channel: Digitally encrypt secure channel data (when possible); and Secure channel: Digitally sign secure channel data (when possible). If a system is configured to always encrypt or sign secure channel data, then a secure channel cannot be established with a domain controller that is not capable of signing or encrypting all secure channel traffic, because all secure channel data is signed and encrypted. If the computer is configured to encrypt or sign secure channel data when possible, a secure channel can be established, but the level of encryption and signing is negotiated.

Countermeasure

Configure Secure channel: Digitally encrypt or sign secure channel data (always) to the value Disabled; configure Secure channel: Digitally encrypt secure channel data (when possible) to the value Enabled; and configure Secure channel: Digitally sign secure channel data (when possible) to the value Enabled in the Group Policy linked to the parent OU for servers.

The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

Digital encryption and signing of the “secure channel” is a good idea where it is supported. The secure channel is the Netlogon communication channel for protecting domain credentials as they are sent to the domain controller. However, digital encryption and signing of the secure channel is supported only in Windows NT 4.0 SP6a or later, and is not supported in Windows 98SE clients. Therefore, this setting cannot be enabled on domain controllers when they have to support Windows 98 clients as members of the domain. The potential impact may include disabling the ability to create or delete down-level trust relationships, disabling logons from down-level clients, and not being able to authenticate other domains' users from a down-level trusted domain.

After all Windows 9x clients have been eliminated from the domain, and all Windows NT 4.0 servers and domain controllers (from trusted/trusting domains) have been upgraded to SP6a, this setting could be enabled.

Secure channel data transmitted between down-level clients and the servers in your organization may not be encrypted or protected with digital signatures.

Contoso Scenario

Some guidance exists that suggests configuring all of these settings to Enabled, but to ensure backward compatibility the Contoso servers were configured to digitally sign and encrypt their secure channel data when communicating with computers that support the feature. In the Contoso scenario, Group Policy was used to configure Secure channel: Digitally encrypt or sign secure channel data (always) to Disabled; configure Secure channel: Digitally encrypt secure channel data (when possible) to Enabled; and configure Secure channel: Digitally sign secure channel data (when possible) to Enabled.

Secure Channel: Require Strong (Windows 2000 or Later) Session Key

Vulnerability

Session keys in older versions of the Windows operating system are not as secure as those in Windows 2000 Server. Session keys used to establish secure channel communications between domain controllers and member computers are much stronger in Windows 2000 than they were in previous operating systems from Microsoft.

Whenever possible, you should take advantage of these stronger session keys to help protect secure channel communications from eavesdropping and session hijacking network attacks. Eavesdropping is a form of hacking in which network data is read or altered in transit. The data can be modified to hide or change the sender, or to redirect it.

Countermeasure

Configure Secure channel: Require strong (Windows 2000 or later) session key to Enabled in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Enabling this setting ensures that all outgoing secure channel traffic will require a strong (Windows 2000 or later) encryption key. If this policy setting is disabled, the key strength is negotiated with the remote server. This option should be enabled only if the domain controllers in all trusted domains support strong keys. By default, this value is disabled.

Potential Impact

With this setting enabled you will be unable to join computers running Windows 2000 to Windows NT 4.0 domains.

Contoso Scenario

In the Contoso scenario, there are no remaining NT 4.0 domains, so Group Policy was used to configure Secure channel: Require strong (Windows 2000 or later) session key to Enabled.

Send Unencrypted Password to Connect to Third-Party SMB Servers

Vulnerability

If this setting is enabled, the server could transmit passwords in cleartext across the network to other systems offering SMB services. These other systems may not use any of the SMB security mechanisms included with Windows 2000. Cleartext is used in a message that is not encrypted. Cleartext messages are also referred to as plaintext messages.

Countermeasure

Configure Send unencrypted password to connect to third-party SMB servers to Disabled in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

Some very old applications and operating systems may not be able to communicate with the servers in your organization through the SMB protocol.

Contoso Scenario

There are no third-party SMB servers in the Contoso scenario; therefore, Group Policy is used to configure Send unencrypted password to connect to third-party SMB servers to Disabled.

Shut Down System Immediately if Unable to Log Security Audits

Vulnerability

This setting is removed to prevent a DoS attack aimed at filling the security log to capacity with audit entries. Configuring computers to shut down when the security log is full could lead to a DoS condition.

Some resources recommend configuring this setting to Manual; however, the administrative burden is too high for most organizations. Ideally, all significant events will be sent to a monitoring server using MOM or some other automated monitoring tool.

Countermeasure

Configure Shut down system immediately if unable to log security audits to Disabled in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

If the security log fills to capacity, the computer will continue to operate without recording additional events. The risk of unrecorded security events is mitigated by setting the Retention method for the security log to As needed.

Contoso Scenario

The administrative burden of enabling this setting in the Contoso scenario was determined to be too high; therefore, Group Policy is used to configure Shut down system immediately if unable to log security audits to Disabled.

Smart Card Removal Behavior

Vulnerability

If smart cards are used for authentication, then the computer should automatically lock itself when the card is removed. If this setting is not used, users may forget to manually lock their workstations when they are away from them. If workstations are left unlocked, a malicious user may be able to access another user's computer to obtain sensitive information or make unauthorized changes to the computer or the network.

Countermeasure

Configure Smart card removal behavior to Lock Workstation in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• No Action

• Lock Workstation

• Force Logoff

• Not defined

Potential Impact

Users will have to reinsert their smart cards and re-enter their personal identification numbers (PINs) when they return to their workstations.

Contoso Scenario

We wanted to ensure that the console for servers in the Contoso scenario would not be accessible when administrators removed their smart cards; therefore, Group Policy was used to configure Smart card removal behavior to Lock Workstation.

Strengthen Default Permissions of Global System Objects (for Example, Symbolic Links)

Vulnerability

This setting determines the strength of the default discretionary access control list (DACL) for objects. Windows 2000 maintains a global list of shared system resources such as DOS device names, mutexes, and semaphores.

In this way, objects can be located and shared among processes. Each type of object is created with a default DACL that specifies who can access the objects with what permissions. If this policy setting is enabled, the default DACL is strengthened, allowing non-administrator users to read shared objects, but not to modify shared objects that they did not create.

Countermeasure

Configure Strengthen default permissions of global system objects (for example, Symbolic Links) to Enabled in the Group Policy linked to the parent OU for servers. The possible values for this policy setting are:

• Enabled

• Disabled

• Not defined

Potential Impact

None.

Contoso Scenario

To additionally secure the Contoso servers, Group Policy was used to configure Strengthen default permissions of global system objects (for example, Symbolic Links) to Enabled.

Unsigned Driver Installation Behavior

Vulnerability

This option prevents the installation of unsigned drivers, or warns the administrator that an unsigned driver software is about to be installed. This option can help prevent the installation of drivers that have not been certified to run on Windows 2000.

Countermeasure

Configure Unsigned driver installation behavior to the value Warn but allow installation in the Group Policy linked to the parent OU for servers. This configuration differs from the default setting in Windows 2000, which is Not defined. The possible values for this policy setting are:

• Warn but allow installation

• Do not allow installation

• Not defined

Potential Impact

A less restrictive setting was used in the Contoso scenario to give more flexibility to administrators for using unsigned drivers. Users with sufficient privileges to install device drivers will be able to install unsigned device drivers. However, this configuration could result in stability problems for system servers. Another potential problem with setting this to Warn but allow installation is that unattended installation scripts will fail if they attempt to install unsigned drivers.

Contoso Scenario

In the Contoso scenario, it was decided the administrators should have the flexibility to install unsigned drivers when it is determined to be the best course of action. Therefore, Group Policy was used to configure Unsigned driver installation behavior to Warn but allow installation.

Unsigned Non-Driver Installation Behavior

Vulnerability

This option prevents the installation of unsigned applications, or warns the administrator that an unsigned non-driver software application is about to be installed. This option can help prevent the installation of non-driver software that has not been certified to run on Windows 2000.

Countermeasure

Configure Unsigned non-driver installation behavior to the value the Silently succeed in the Group Policy linked to the parent OU for servers. Other guidance exists that suggests setting this to Warn but allow installation. This setting was chosen so that Exchange 2000 Server and other applications can be installed in an unattended manner and to prevent installation warnings from being generated by other unsigned applications. The possible values for this policy setting are:

• Silently succeed

• Warn but allow installation

• Do not allow installation

• Not defined

Potential Impact

Code signing has not been implemented in most software applications and services. Not only does this policy setting have no real benefit because there is little or no signed application software to distinguish from the masses of unsigned application software, but it could prevent or make difficult the installation of software that has been tested in your own certification environment—especially for unattended installations, which can be stalled even by the Warn but allow installation setting.

Users with sufficient privileges to install applications will be able to install applications that have not been digitally signed. This configuration could result in stability problems for the server.

Contoso Scenario

In the Contoso scenario, the default setting was chosen so that unsigned application software such as Exchange 2000 Server can be installed in an unattended manner, and so that other unsigned applications can be installed without generating hundreds of error messages. Group Policy was used to configure Unsigned non-driver installation behavior to Silently succeed.

Services Configuration

When Windows 2000 Server is first installed, default services are created and are configured to run when the system starts. Many of these services do not need to run in the Contoso network of the Contoso scenario.

Any service or application is a potential point of attack. Therefore, any unneeded services or executable files should be disabled or removed in your system environment. There are additional optional services available with Windows 2000, such as Certificate Services, that are not installed during a default installation of Windows 2000 Server.

These optional services can be added to an existing system by using Add/Remove Programs or the Windows 2000 Configure Your Server Wizard, or by creating a customized automated installation of Windows 2000. In the MSBP, these optional services, as well as all unnecessary services, are disabled.

The MSBP only enables the services required for a Windows 2000 member server to participate in a Windows 2000 domain and provide basic management services. Specific services required for each server role are enabled through role-specific Group Policies as described in Chapter 7, "Hardening Specific Server Roles."

If additional server types were needed on the Contoso network, it would then have been necessary to enable additional services. For example, if a certificate server was going to be used for distributing Secure Socket Layer (SSL), secure e-mail and other types of certificates to end users, then Certificate Services would need to be installed. A Group Policy that applies to that new server role would also need to be created that sets the Certificate Services service to Automatic. For descriptions of the purposes for all of the services included with Windows 2000 Server, see Appendix A, "Purpose of Microsoft Windows 2000 Services."

Note If additional services are enabled, they may in turn have dependencies that require more services. All of the services needed for a specific server role should be added in the policy for the server role that it performs in your organization.

The following table illustrates which services are configured to start automatically in the MSBP.

Table 6.3  MSBP Services Enabled

Full service name as it appears in the UI	Service name	Default setting	Startup type
Automatic Updates	WUAUServ	Automatic	Automatic
Computer Browser	Browser	Automatic	Automatic
DHCP Client	DHCP	Automatic	Automatic
Distributed Link Tracking Client	TrkWks	Automatic	Automatic
DNS Client	DNSCache	Automatic	Automatic
Event Log	EventLog	Automatic	Automatic
IPSEC Policy Agent(IPSEC Service)	PolicyAgent	Automatic	Automatic
Logical Disk Manager	Dmserver	Automatic	Automatic
Netlogon	Netlogon	Automatic	Automatic
NTLM Security Support Provider	NtLmSsps	Manual	Automatic
Plug and Play	PlugPlay	Automatic	Automatic
Protected Storage	ProtectedStorage	Automatic	Automatic
Remote Procedure Call (RPC)	RpcSs	Automatic	Automatic
Remote Registry Service	RemoteRegistry	Automatic	Automatic
Security Accounts Manager	SaContoso	Automatic	Automatic
Server	Lanmanserver	Automatic	Automatic
SNMP Service	SNMP	Not Installed	Automatic
System Event Notification	SENS	Automatic	Automatic
TCP/IP NetBIOS Helper Service	LmHosts	Automatic	Automatic
Terminal Services	TermService	Disabled	Automatic
Windows Installer	MSIServer	Manual	Automatic
Windows Management Instrumentation	WinMgmt	Manual	Automatic
Windows Time	W32Time	Automatic (see the following note)	Automatic
Workstation	LanmanWorkstation	Automatic	Automatic

Note Default settings are automatic for a server in the domain and manual if the server belongs to a workgroup.

The following table illustrates which services are disabled in the MSBP.

Table 6.4  MSBP Services Disabled

Full service name as it appears in the UI	Service name	Default setting	Startup type
Alerter	Alerter	Automatic	Disabled
Application Management	AppMgmt	Manual	Disabled
ClipBook	ClipSrv	Manual	Disabled
Distributed Transaction Coordinator	MSDTC	Automatic	Disabled
Fax Service	Fax	Manual	Disabled
Indexing Service	Cisvc	Manual	Disabled
Internet Connection Sharing	SharedAccess	Manual	Disabled
License Logging Service	LicenseService	Automatic	Disabled
Messenger	Messenger	Automatic	Disabled
NetMeeting Remote Desktop Sharing	Mnmsrvc	Manual	Disabled
Network DDE	NetDDE	Manual	Disabled
Network DDE DSDM	NetDDEdsdm	Manual	Disabled
QoS Admission Control (RSVP)	RSVP	Manual	Disabled
Remote Access Auto Connection Manager	RasAuto	Manual	Disabled
Remote Access Connection Manager	RasMan	Manual	Disabled
Removable Storage	NtmsSvc	Automatic	Disabled
Routing and Remote Access	RemoteAccess	Disabled	Disabled
RunAs Service	Seclogon	Automatic	Disabled
Smart Card	ScardSvr	Manual	Disabled
Smart Card Helper	ScardDrv	Manual	Disabled
Task Scheduler	Schedule	Automatic	Disabled
Telephony	TapiSrv	Manual	Disabled
Telnet	TlntSvr	Manual	Disabled
Uninterruptible Power Supply	UPS	Manual	Disabled
Utility Manager	UtilMan	Manual	Disabled

The following table illustrates which services that are not installed by default are disabled in the MSBP.

Table 6.5  MSBP Non-Default Services Disabled

Full service name as it appears in the UI	Service name	Default setting	Startup type
Boot Information Negotiation Layer	BINLSVC	Not installed	Disabled
Certificate Services	CertSvc	Not installed	Disabled
Cluster Service	ClusSvc	Not installed	Disabled
File Server for Macintosh	MacFile	Not installed	Disabled
FTP Publishing Service	MSFTPSVC	Not installed	Disabled
Gateway Service for Netware (see the note at the end of this table)	NWCWorkstation	Not installed	Disabled
Internet Authentication Service	IAS	Not installed	Disabled
Message Queuing	MSMQ	Not installed	Disabled
Network News Transfer Protocol (NNTP)	NntpSvc	Not installed	Disabled
On-Line Presentation Broadcast	NSLService	Not installed	Disabled
Print Server for Macintosh	MacPrint	Not installed	Disabled
QoS RSVP	RSVP	Not installed	Disabled
Remote Storage Engine	Remote_Storage_Engine	Not installed	Disabled
Remote Storage File	Remote_Storage_File_System_Agent	Not installed	Disabled
Remote Storage Media	Remote_Storage_Subsystem	Not installed	Disabled
Remote Storage Notification	Remote_Storage_User_Link	Not installed	Disabled
SAP Agent	NwSapAgent	Not installed	Disabled
Simple TCP/IP Services	SimpTcp	Not installed	Disabled
Single Instance Storage Groveler	Groveler	Not installed	Disabled
Site Server ILS Service	LDAPSVCX	Not installed	Disabled
Simple Mail Transport Protocol (SMTP)	SMTPSVC	Automatic	Disabled
SNMP Trap Service	SNMPTRAP	Not installed	Disabled
TCP/IP Print Server	LPDSVC	Not installed	Disabled
Terminal Services Licensing	TermServLicensing	Not installed	Disabled
Trivial FTP Daemon	TFTPD	Not installed	Disabled
Windows Media Monitor Service	nsmonitor	Not installed	Disabled
Windows Media Program Service	nsprogram	Not installed	Disabled
Windows Media Station Service	nsstation	Not installed	Disabled
Windows Media Unicast Service	nsunicast	Not installed	Disabled

Note NetWare is a Novell network management product that offers access to core network resources including files, printers, directories, e-mail, and databases across all types of networks, storage platforms, and client desktops.

The following table illustrates which services are configured to start manually in the MSBP.

Table 6.6  MSBP Services Configured to Start Manually

Full service name as it appears in the UI	Service name	Default setting	Startup type
Background Intelligent Transfer Service	BITS	Manual	Manual
COM+ Event Services	EventSystem	Manual	Manual
Logical Disk Manager Administrative Service	Dmadmin	Manual	Manual
Network Connections	Netman	Manual	Manual
Performance Logs and Alerts	SysmonLog	Manual	Manual
Windows Management Instrumentation Driver Extensions	WMI	Manual	Manual

The following table illustrates which services are configured to start automatically for specific server roles in the Contoso scenario. For the other server roles these services are disabled by setting their startup mode to Disabled in the MSBP. These services and why they are required for specific server roles are discussed in Chapter 7, "Hardening Specific Server Roles."

Table 6.7  MSBP Services Enabled for Specific Server Roles

Full service name as it appears in the UI	Service name	Default setting	Startup type
DHCP Server	DHCPServer	Not installed	Enabled only in the Infrastructure role.
Distributed File System	Dfs	Automatic	Enabled only in the domain controller role.
Distributed Link Tracking Server	TrkSrv	Automatic	Enabled only in the Domain Controller role.
DNS Server	DNS	Not Installed	Enabled only in the Domain Controller role.
File Replication	NtFrs	Manual	Enabled only in the Domain Controller role.
IIS Admin Service	IISADMIN	Automatic	Enabled in the IIS role.
Intersite Messaging	IsmServ	Disabled	Enabled in the Domain Controller role.
Kerberos Key Distribution Center	Kdc	Disabled	Enabled only in the Domain Controller role.
Print Spooler	Spooler	Automatic	Enabled only in the File and Print role.
Remote Procedure Call (RPC) Locator	Rpclocator	Manual	Enabled only in the Domain Controller role.
Windows Internet Name Service (WINS)	WINS	Not installed	Enabled only in the Infrastructure role.
World Wide Web Publishing Service	W3svc	Automatic	Enabled only in the IIS role.

The following Windows 2000 Server services discussed in the preceding tables merit additional attention.

Computer Browser

Vulnerability

The Computer Browser service maintains the list of computers on the network and supplies the list to programs that request it. The Computer Browser service is used by Windows–based computers that need to view network domains and resources.

Countermeasure

Enable the Computer Browser service by setting its startup mode to Automatic. The possible values for this policy setting are:

• Automatic

• Manual

• Disabled

• Not defined

Potential Impact

Computers that connect to the same physical network segment as the Contoso servers will be able to remotely access the Computer Browser service to see the browse list of domains and resources.

Contoso Scenario

The network in the Contoso scenario utilizes the Computer Browser service to enumerate services within the forest. Therefore, Group Policy is used to configure the Computer Browser service startup mode to Automatic.

NTLM Security Support Provider

Vulnerability

The NTLM Security Support Provider service provides security to RPC programs that use transports other than named pipes and enables users to log on using the NTLM authentication protocol.

Countermeasure

Enable the NTLM Security Support Provider service by setting its startup mode to Automatic. The possible values for this policy setting are:

• Automatic

• Manual

• Disabled

• Not defined

Potential Impact

This service is included with Windows 2000 Server purely for backward compatibility with applications that specifically look for this service to be running. This functionality is now included in the core operating system.

Contoso Scenario

The servers in the Contoso scenario run a third-party agent that requires this service; therefore Group Policy was used to configure the NTLM Security Support Provider service startup mode to Automatic.

SNMP Service

Vulnerability

In many cases, management applications require an agent to be installed on each server. Typically, these agents will use Simple Network Management Protocol (SNMP) to forward alerts back to a centralized management server.

Countermeasure

Enable the SNMP Service by setting its startup mode to Automatic. The possible values for this policy setting are:

• Automatic

• Manual

• Disabled

• Not defined

Potential Impact

Enabling SNMP Service creates a risk of its own because the default community string for read access used for Microsoft products is the word Public. By default, write access through SNMP is disabled in Windows 2000. SNMP can provide not only the functionality to read values from a server but modify information as well. The community string is similar to a password and should be treated with the same level of security. This risk is mitigated by manually changing the community string as described later in this chapter.

Another risk created by enabling the SNMP Service is that traffic is all sent in cleartext. An attacker who is able to sniff traffic on the network in the Contoso scenario would be able to view the SNMP packets.

Contoso Scenario

The MOM agents installed on the servers in the Contoso scenario are dependent on this service. Therefore, Group Policy was used to configure the SNMP Service startup mode to Automatic.

Terminal Services

Vulnerability

Remote administration of servers saves time and money. Support staff can connect to servers and perform administrative tasks without having to physically walk up to the console of the server to manage it. This capability is particularly important in large, distributed networks.

Countermeasure

Enable Terminal Services by setting its startup mode to Automatic. The possible values for this policy setting are:

• Automatic

• Manual

• Disabled

• Not defined

Potential Impact

An attacker who is able to connect to TCP port 3389 will be able to establish a Remote Desktop Protocol (RDP) connection. The attacker would still need to know the user name and password of an account that has sufficient privileges to log on to the server. Because of other security settings implemented in the Contoso servers, in the Contoso scenario it would be extremely difficult and time consuming for the attacker to use a brute force attack through a RDP connection and Terminal Services.

Contoso Scenario

For the reasons stated earlier, servers in the Contoso scenario have the Terminal Services service installed and enabled. Group Policy was used to configure the Terminal Services startup mode to Automatic.

Windows Management Instrumentation

Vulnerability

The Windows Management Instrumentation (WMI) service is needed for managing logical disks that use computer management. The service also facilitates performance alerts. Many other applications and tools also use WMI.

Countermeasure

Enable the Windows Management Instrumentation service by setting its startup mode to Automatic. The possible values for this policy setting are:

• Automatic

• Manual

• Disabled

• Not defined

Potential Impact

If the WIM interfaces are be enabled, an attacker who gains access to a system may be able to take advantage of them to gather more information about the hardware and software installed on the server.

Contoso Scenario

Servers in the Contoso scenario need to be managed by means of WMI. Therefore Group Policy was used to configure the Windows Management Instrumentation service startup mode to Automatic.

Messenger Service and Alert Service

Vulnerability

Although not explicitly dependent on one another, these services work together to send administrative alerts. The Messenger Service sends alerts triggered by the Alert Service. If you are using performance logs and alerts to trigger alerts, you will need to enable these services on the servers in your organization.

Countermeasure

Disable the Messenger Service and Alert Service by setting startup mode for these services to Disabled. The possible values for this policy setting are:

• Automatic

• Manual

• Disabled

• Not defined

Potential Impact

Automatic administrative alerts will not be sent, and messenger notifications can not be sent to or received by the computer or by users currently logged on to it. For example, the NET SEND and NET NAME commands will no longer function.

Contoso Scenario

These services are not required in the Contoso scenario. Therefore, Group Policy was used to configure the Messenger Service and Alert Service startup mode for these services to Disabled.

Additional Registry Settings

For the servers in the Contoso scenario, additional registry value entries are added to the baseline security template file that are not defined within the Administrative Template (.adm) file. The .adm file defines the system policies and restrictions for the desktop, shell, and security for Windows 2000 Server.

Because these registry value entries are not defined in the .adm file, the entries in the following tables are not represented when you load the Microsoft Management Console (MMC) Security Templates snap-in and view the baseline.inf template. Instead, these settings have been added to the .inf file using the text editor called Notepad included with Windows and will be applied to the server when the policy is downloaded.

These settings are embedded within the baseline.inf security template to automate the changes. If the policy is removed, these settings are not automatically removed with it and must be manually changed using a registry editing tool such as Regedt32.exe.

Security Considerations for Network Attacks

Vulnerability

DoS attacks directed at the TCP/IP stack tend to be of two classes: attacks that use an excessive number of system resources, for example, by opening numerous TCP connections; or attacks that send specially crafted packets that cause the network stack or the entire operating system to fail. These registry settings help to protect against the attacks directed at the TCP/IP stack.

Countermeasure

Configure values as indicated in Tables 6.8 and 6.9 in the Group Policy linked to the parent OU for servers. DoS attacks include those that flood a Web server with communication to keep it busy, and others that flood a remote network with an enormous amount of protocol packets. Routers and servers become overloaded by attempting to route or handle each packet.

DoS attacks can be difficult to defend against. To help prevent them, the TCP/IP protocol stack is hardened. This registry value was added to the baseline security template file, but it is not defined within the Administrative Template (.adm) file. Because it is not defined in the .adm file, the registry value is not visible when you load the MMC Security Templates snap-in and view the baseline.inf template. Instead, these settings can be added to the .inf file using a text editor. The settings will then be applied to the server when the policy is downloaded.

Potential Impact

The potential impacts of this countermeasure are detailed in Table 6.10.

Contoso Scenario

In the Contoso scenario, Group Policy was used to configure these registry settings to increase the resistance of the Windows 2000 TCP/IP stack to standard types of DoS network attacks.

The following registry value entries have been added to the template file in the HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\ registry key:

Table 6.8  MSBP TCP/IP Parameters Added to Registry

Registry value entry	Format	Value (Decimal)
EnableICMPRedirect	DWORD	0
SynAttackProtect	DWORD	2
EnableDeadGWDetect	DWORD	0
EnablePMTUDiscovery	DWORD	0
KeepAliveTime	DWORD	300,000
DisableIPSourceRouting	DWORD	2
TcpMaxConnectResponseRetransmissions	DWORD	2
TcpMaxDataRetransmissions	DWORD	3
PerformRouterDiscovery	DWORD	0
TCPMaxPortsExhausted	DWORD	5

Windows Sockets applications such as File Transfer Protocol (FTP) servers and Web servers have their connection attempts handled by Afd.sys. Afd.sys has been modified to support large numbers of connections in the half-open state without denying access to legitimate clients.

This capability is accomplished by allowing the administrator to configure a dynamic backlog. The new version of Afd.sys supports four new registry parameters that can be used to control the dynamic backlog behavior.

The following registry value entries have been added to the template file in the HKLM\System\CurrentControlSet\Services\AFD\Parameters\ registry key:

Table 6.9  MSBP Afd.sys Settings Added to Registry

Registry value entry	Format	Value (Decimal)
DynamicBacklogGrowthDelta	DWORD	10
EnableDynamicBacklog	DWORD	1
MinimumDynamicBacklog	DWORD	20
MaximumDynamicBacklog	DWORD	20000

Potential Impact

Table 6.10  Impact of Countermeasures and Potential Exploits

Registry value entry	Countermeasure potential impact	Potential exploit
EnableICMPRedirect	When Routing and Remote Access Services (RRAS) is configured as an autonomous system boundary router (ASBR), it does not correctly import connected interface subnet routes. Instead, this router injects host routes into the Open Shortest Path First (OSPF) routes. Because the OSPF router can not be used as an ASBR router, importing connected interface subnet routes into OSPF results in confusing routing tables with strange routing paths.	Internet Control Message Protocol (ICMP) redirects the stack to plumb host routes. These routes override the OSPF-generated routes, which is expected. The problem is that the 10 minute time-out period for the ICMP redirect-plumbed routes creates a black hole for the network concerned.
SynAttackProtect	This registry value causes TCP to adjust retransmission of SYN-ACKs. When you configure this value, the connection responses time out more quickly in the event of a SYN attack. This value adds additional delays to connection indications, and TCP connection requests quickly time out when a SYN attack is in progress. When you configure this setting, the scalable windows and TCP parameters that are configured on each adapter (including Initial Round Trip Time (RTT) and window size) socket options no longer work.	In a SYN flood attack, the attacker sends a continuous stream of SYN packets to a server, and the server leaves the half-open connections open until it is overwhelmed and is no longer able to respond to legitimate requests.
EnableDeadGWDetect	When dead-gateway detection is enabled, TCP may ask the IP to change to a backup gateway if a number of connections are experiencing difficulty. When this setting is configured to 0, Windows will no longer detect dead gateways and automatically switch to an alternate.	An attacker could force the server to switch gateways, potentially to an unintended one.
EnablePMTUDiscovery	When you configure EnablePMTUDiscovery to 1, TCP attempts to discover either the maximum transmission unit (MTU) or the largest packet size over the path to a remote host. TCP can eliminate fragmentation at routers along the path that connect networks with different MTUs by discovering the path MTU and limiting TCP segments to this size. Fragmentation adversely affects TCP throughput. When this value is configured to 0, an MTU of 576 bytes is used for all connections that are not hosts on the local subnet.	If you do not configure this value to 0, an attacker could force the MTU to a very small value and overwork the stack by forcing the server to fragment a large number of packets.
KeepAliveTime	This value controls how often TCP attempts to verify that an idle connection is still intact by sending a keep-alive packet. If the remote computer is still reachable, it acknowledges the keep-alive packet. Keep-alive packets are not sent by default. You can use a program to configure this value on a connection. Lowering this value from the default of 2 hours to 5 minutes means that inactive sessions will be disconnected more quickly.	An attacker who was able to connect to network applications could cause a DoS condition by establishing numerous connections.
DisableIPSourceRouting	IP source routing is a mechanism allowing the sender to determine the IP route that a datagram should take through the network. Setting this value to 2 will cause all incoming source routed packets to be dropped.	An attacker uses source routed packets to obscure their identity and location. Source routing allows a computer sending a packet to specify the route it takes.
TCPMaxConnectResponseRetransmissions	This parameter controls the number of times that a SYN-ACK is retransmitted in response to a connection request if the SYN is not acknowledged. If this value is greater than or equal to 2, the stack employs SYN-ATTACK protection internally. If this value is less than 2, the stack does not read the registry values at all for SYN-ATTACK protection. This parameter shortens the default time that it takes to clean up a half-open TCP connection. A site that is under heavy attack might configure the value as low as 1. A value of 0 is also valid. However, if this parameter is configured to 0, SYN-ACKs will not be retransmitted at all and will time out in 3 seconds. With the value this low, legitimate connection attempts from distant clients may fail.	In a SYN flood attack, the attacker sends a continuous stream of SYN packets to a server, and the server leaves the half-open connections open until it is overwhelmed and no longer is able to respond to legitimate requests.
TCPMaxData Retransmissions	TCP starts a retransmission timer when each outbound segment is handed down to the IP. If no acknowledgment has been received for the data in a given segment before the timer expires, then the segment is retransmitted up to three times.	In a SYN flood attack, the attacker sends a continuous stream of SYN packets to a server, and the server leaves the half-open connections open until it is overwhelmed and no longer is able to respond to legitimate requests.
PerformRouterDiscovery	This entry is configured to prevent Windows 2000, which supports the Internet Router Discovery Protocol (IRDP), from automatically detecting and configuring Default Gateway addresses on the computer.	An attacker who gained control of a computer on the same network segment could configure a computer on the network to impersonate a router. Other computers with IRDP enabled would then attempt to route their traffic through the compromised computer.
TCPMaxPortsExhausted	This parameter controls the point at which SYN-ATTACK protection starts to operate. SYN-ATTACK protection begins to operate when TCPMaxPortsExhausted connect requests have been refused by the computer because the available backlog for connections is set at 0. This configuration should have little impact on the server or computers attempting to use it in a legitimate manner.	In a SYN flood attack, the attacker sends a continuous stream of SYN packets to a server, and the server leaves the half-open connections open until it is overwhelmed and no longer is able to respond to legitimate requests.
AFD settings: DynamicBacklogGrowthDelta EnableDynamicBacklog MinimumDynamic Backlog MaximumDynamic Backlog	Windows Sockets applications such as FTP servers and Web servers have their connection attempts handled by Afd.sys. Afd.sys has been modified to support large numbers of connections in the half-open state without denying access to legitimate clients. This capability is accomplished by allowing the administrator to configure a dynamic backlog. DynamicBacklogGrowthDelta controls the number of free connections to create when additional connections are necessary. Be careful with this value, as a large value could lead to explosive free connection allocations.	In a SYN flood attack, the attacker sends a continuous stream of SYN packets to a server, and the server leaves the half-open connections open until it is overwhelmed and no longer is able to respond to legitimate requests.

Configure NetBIOS Name Release Security

NetBIOS over TCP/IP is a networking protocol that among other things provides a means of easily resolving NetBIOS names registered on Windows–based computers to the IP addresses configured on those computers.

Vulnerability

The NetBIOS over TCP/IP (NetBT) protocol is designed not to use authentication, and is therefore vulnerable to spoofing. A malicious user could exploit the unauthenticated nature of the protocol to send a name-conflict datagram to a target computer, causing it to relinquish its name and stop responding to queries.

The result of such an attack could be to cause intermittent connectivity issues on the target computer, or even to prevent the use of Network Neighborhood, domain logons, the net send command, or additional NetBIOS name resolution.

For more details, see Microsoft Knowledge Base article 269239 "MS00-047: NetBIOS Vulnerability May Cause Duplicate Name on the Network Conflicts" at https://support.microsoft.com/default.aspx?scid=269239.

Countermeasure

Test and deploy the registry changes recommended in Knowledge Base article 269239. Applying the registry value NoNameReleaseOnDemand and setting it to 1 ensures that the servers will no longer comply with name release requests from computers other than the WINS servers configured on in the network settings of the server.

Alternatively, you could disable the use of WINS in your environment and further ensure that all applications rely upon DNS for name resolution services. Although this approach is a recommended long-term strategy, it is generally impractical for most organizations to attempt as a short-term solution. Organizations still running WINS generally have application dependencies that can not be quickly resolved without upgrades and software rollouts, which require careful planning and significant time commitments.

If you can not deploy this countermeasure, and you want to guarantee NetBIOS name resolution, then take the additional step of "pre-loading" NetBIOS names in the LMHOSTS file on certain computers. Knowledge Base article 269239 details the procedure for preloading the LMHOSTS file.

Note   There is a high maintenance factor required to update the LMHOSTS files in most environments. Microsoft encourages the use of WINS over LMHOSTS.

Potential Impact

An attacker could send a request over the network asking a computer to release its NetBIOS name. As with any changes that could affect applications, Microsoft recommends testing this change in a non-production environment before making the change in production.

Contoso Scenario

In the Contoso scenario, NetBIOS naming services are still required to be supported. This hotfix is deployed to all servers, and the registry is updated through the Incremental Infrastructure server policy.

The following registry value entry was added to the template file to the HKLM\System\CurrentControlSet\Services\Netbt\Parameters\ registry key:

Table 6.11  MSBP Setting Added to Registry to Configure the NetBIOS Name Release protection

Registry key	Format	Value (Decimal)
NoNameReleaseOnDemand	DWORD	1

Disable Auto Generation of 8.3 Filenames

Vulnerability

Windows 2000 supports 8.3 file name formats for backward compatibility with16-bit applications. The 8.3 file name convention is a naming format that allows file names up to eight characters long.

If 8.3 filenames are automatically generated, an attacker would only need eight characters to refer to a file that may be 20 characters long. For example, a file named Thisisalongfilename.doc, could be referenced by its 8.3 filename Thisis~1.doc. If you avoid using 16-bit applications, you can turn this feature off. Disabling short name generation on an NTFS partition also increases directory enumeration performance.

Attackers could use short file names to access data files and applications with long file names that would otherwise be difficult to locate. An attacker who has gained access to the file system could access data or execute applications.

Countermeasure

Configure NtfsDisable8dot3NameCreation to the value 1 in the Group Policy linked to the parent OU for servers. This registry value was added to the baseline security template file, but it is not defined within the .adm file. Therefore, the registry value is not visible when you load the MMC Security Templates snap-in and view the baseline.inf template. Instead, these settings can be added to the .inf file using a text editor. The settings will then be applied to the server when the policy is downloaded.

Potential Impact

The 16-bit applications in your organization will not be able to access files with names longer than the 8.3 format allows.

Contoso Scenario

In the Contoso scenario, Group Policy is used to configure NtfsDisable8dot3NameCreation to the value 1.

The following registry value entry has been added to the template in the HKLM\System\CurrentControlSet\Control\FileSystem\ registry key:

Table 6.12  MSBP Setting to Remove 8.3 Filename Creation Added to Registry

Registry value entry	Format	Value (Decimal)
NtfsDisable8dot3NameCreation	DWORD	1

Note   If you apply this setting to an existing server that already has files with auto generated 8.3 file names, it does not remove them. To remove existing 8.3 file names, you will need to copy those files off the server, delete the files from the original location, and then copy the files back to their original locations.

Disable Autorun

Vulnerability

Autorun begins reading from a drive on your computer as soon as media is inserted in it. As a result, the setup file of programs and the sound on audio media starts immediately. To prevent a possible malicious program from starting when media is inserted, the Group Policy disables Autorun on all drives.

An attacker with physical access to the computer could insert an Autorun enabled DVD or CD into the computer that will then automatically launch malicious code. This malicious program could contain whatever code the attacker desires.

Countermeasure

Configure NoDriveTypeAutoRun to the hexadecimal value 0xFF in the Group Policy linked to the parent OU for servers. This registry value was added to the baseline security template file, but it is not defined within the .adm file. Therefore, this registry value is not visible when you load the MMC Security Templates snap-in and view the baseline.inf template. Instead, these settings can be added to the .inf file using a text editor, and they will then be applied to the server when the policy is downloaded.

Potential Impact

Autorun will no longer work when Autorun enabled discs are inserted into the computer.

Contoso Scenario

In the Contoso scenario, Group Policy was used to add the following registry value entry to the template in the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\ key:

Table 6.13  MSBP Setting to Disable Autorun on All Drives Added to Registry

Registry value entry	Format	Value (Hex)
NoDriveTypeAutoRun	DWORD	0xFF

Removing OS/2 and POSIX Subsystems

Vulnerability

The OS/2 Subsystem is required if the server needs to significantly interact with OS/2 clients. OS/2 is a family of Microsoft protected-mode, virtual-memory, multitasking operating systems for computers based on the Intel 80286 and 80386 processors. The Portable Operating System Interface for UNIX (POSIX) is an Institute of Electrical and Electronic Engineers (IEEE) standard that defines a set of operating system services.

The subsystem introduces a security risk relating to processes that can potentially persist across logins. That is, if a user starts a process and then logs out, there is a potential that the process will be accessed by the next user who logs in to the computer. The process started by the first user may retain the user's system privileges.

Countermeasure

To disable the OS/2 Subsystem, the Optional, OS/2, and POSIX registry keys were deleted in the Group Policy linked to the parent OU for servers. The commands to delete these registry subkeys were added to the baseline security template file, but they are not defined within the .adm file.

Therefore, the registry change is not visible when you load the MMC Security Templates snap-in and view the baseline.inf template. Use a text editor to add these settings to the .inf file, and then apply them to the server when the policy is downloaded.

Potential Impact

Applications that rely on the OS/2 or POSIX subsystems will no longer operate. For example, Microsoft Services for UNIX (SFU) 3.0 installs an updated version of the POSIX subsystem that requires both the Optional and POSIX subkeys, so you would need to remove these subkeys from the security template for any servers that use SFU 3.0.

Contoso Scenario

In the Contoso scenario, Group Policy is used to delete the following subkeys of the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems registry key by adding entries to the security template:

• Optional

• OS/2

• POSIX

Make Screensaver Password Protection Immediate

Vulnerability

The default grace period allowed for user movement before the screen saver lock takes effect is five seconds. Leaving the grace period in the default setting makes your computer vulnerable to a potential attack from someone walking up to the console to attempt to log on to the computer before the lock takes effect. An entry to the registry can be made to adjust the length of the delay.

Countermeasure

To make password protection effective immediately, configure ScreenSaverGracePeriod to the value 0. The value is the time in seconds before the screen saver grace period expires.

Potential Impact

Users will have to enter their passwords to resume their console sessions as soon as the screen saver activates.

Contoso Scenario

In the Contoso scenario, the following registry value entry was added to the template in the HKLM\Software\Microsoft\Windows NT\CurrentVersion\
Winlogon\ScreenSaverGracePeriod\ key:

Table 6.14  MSBP Setting to Make Screensaver Password Protection Immediate Added to Registry

Registry value entry	Format	Value (Decimal)
ScreenSaverGracePeriod	String	0

Restrict Null Session Access

Vulnerability

Null sessions are a weakness that can be exploited through the various shares that are on the computers in your environment.

Countermeasure

Modify null session access to shares on your computers by adding RestrictNullSessAccess with the value 1, a registry value that toggles null session shares on or off to determine whether the Server service restricts access to clients logged on to the System account without user name and password authentication.

Potential Impact

Setting the value to 1 restricts null session access to unauthenticated users to all server pipes and shares except those listed in the NullSessionPipes and NullSessionShares entries.

Contoso Scenario

In the Contoso scenario, Group Policy was used to add the following registry key to the template in the HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters\ key:

Table 6.15  MSBP Setting to Restrict Null Session Access Added to Registry

Registry value entry	Format	Value (Decimal)
RestrictNullSessAccess	DWORD	1

Restrict Null Session Access over Named Pipes

Vulnerability

Restricting access over named pipes helps prevent unauthorized access to the network.

Countermeasure

Delete the registry subkeys NullSessionPipes and NullSessionShares located at HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters.

Potential Impact

Null session access over named pipes will be disabled; applications that rely on this feature will no longer function. Null session access to shares will be disabled, and applications that rely on unauthenticated access to network shares will not work. For example, with Microsoft® Commercial Internet System 1.0, the Internet Mail Service runs under the Inetinfo process. Inetinfo starts in the context of the System account. When Internet Mail Service needs to query the Microsoft® SQL Server™ database, it uses the System account, which uses null credentials to access a SQL pipe on the computer running SQL Server computer.

There are two ways that you could resolve this problem: configure the World Wide Web Publishing Service to run with an account other than System that can connect to the SQL Server database, or enable null session pipes. For more information, see the "How to Access Network Files from IIS Applications" article at https://support.microsoft.com/default.aspx?scid=KB;en-us;207671.

Contoso Scenario

In the Contoso scenario, Group Policy was used to delete the following subkeys of the HKLM\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters registry key by adding entries to the security template:

• NullSessionPipes

• NullSessionShares

Security Log Approaching Capacity Warning

Vulnerability

SP3 for Windows 2000 includes a new feature for generating a security audit in the security event log when the security log reaches a user-defined threshold. When the security log reaches 90 percent of capacity, it will show one event entry for eventID 523 with the following text: “The security event log is 90 percent full.”

Countermeasure

To enable this feature, add a new registry DWORD value called WarningLevel and configure the value for it to 90 in the following key: HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Security.

Potential Impact

This setting will generate an audit event when the audit log reaches the 90 percent full threshold.

Contoso Scenario

In the Contoso scenario, Group Policy was used to add the following registry value entry to the template in the HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Security\ key:

Table 6.16  MSBP Setting to Enable Security Log Approaching Capacity Warning Added to Registry

Registry value entry	Format	Value (Decimal)
WarningLevel	DWORD	90

Requiring Domain Controller Authentication to Unlock the Console

Vulnerability

The computer caches in memory the credentials of any users who were authenticated locally. To unlock the console, the computer uses the cached credentials, from memory, to authenticate anyone who attempts to unlock the console.

When cached credentials are used, any changes that have recently been made to the account, such as user rights assignments, account lockout, or the account being disabled, are not considered or applied after this authentication process. If cached credentials are used, user privileges are not updated and (more importantly) disabled accounts are still able to unlock the console of the computer.

Countermeasure

To ensure that any changes to the account are enforced immediately, require the computer to authenticate the account each time that an attempt is made to unlock the console. Do not allowing the computer to rely on cached credentials.

To enable this feature, add a new registry DWORD value called ForceUnlockLogon and configure the value for it to 1 in the following key: HKLM\Software\Microsoft\
Windows NT\CurrentVersion\Winlogon\.

Potential Impact

When the console on a domain controller is locked, either by a user or automatically by a screen saver time-out, the console must be unlocked to gain access to the computer.

Contoso Scenario

In the Contoso scenario, Group Policy is used to add the following registry value entry to the template in the HKLM\Software\Microsoft\Windows NT\
CurrentVersion\Winlogon\ key:

Table 6.17  MSBP Setting to Require Domain Controller Authentication to Unlock Console Added to Registry

Registry value entry	Format	Value (Decimal)
ForceUnlockLogon	DWORD	1

Additional Member Server Hardening Procedures

Although most of the countermeasures used to harden the Contoso servers were applied through Group Policy, there are additional settings that are difficult or impossible to apply with Group Policy. This section describes how some of these additional countermeasures were implemented manually, such as securing accounts; and how others were put in place using shell scripts, such as the IPsec filters.

Manual Hardening Procedures

The following subsections illustrate the manual procedures used to apply countermeasures to the Contoso servers.

Securing the Accounts

Vulnerability

Windows 2000 has a number of built-in user accounts that can not be deleted but can be renamed. Two of the most well known built-in accounts in Windows 2000 are Guest and Administrator. By default, the Guest account is disabled on member servers and domain controllers. This setting should not be changed. The built-in Administrator account should be renamed and the description altered to prevent attackers from compromising a remote server using a well known name.

Many variations of malicious code use the built-in administrator account in an initial attempt to compromise a server. The value of this configuration change has diminished over the past few years since the release of attack tools that attempt to break into the server by specifying the security identifier (SID) of the built-in Administrator account. A SID is the value that uniquely identifies each user, group, computer account, and logon session on a network. It is not possible to change the SID of this built-in account.

Note   The built-in administrator account can be renamed using Group Policy. We have not implemented this setting in the baseline policies because you should choose a name that is not well known. We were concerned that some organizations that deploy our security templates would not change the setting and that they would have the same name for their renamed administrator accounts as in the Contoso scenario. We encourage you to use the policy setting called Rename administrator account located in Computer Configuration\
Windows Settings\Security Settings\Event Log\ in your environment.

Countermeasure

Manually rename the administrator account and change the password to a long and complex value on every server. Also, use different names and passwords on each server.

Record these changes in a secure place. If the same account names and passwords are used on all of the servers, an attacker who gains access to one member server will be able to gain access to all others with the same account name and password.

Potential Impact

The users responsible for managing the servers will have to keep track of which account name is used for each server. If it is necessary to log in to a particular server with the local administrator account, then the user will have to refer to this secured documentation to find out what the user name and password for it is.

Contoso Scenario

In the Contoso scenario, the Computer Management console was used to change the local administrator account and password on each member server.

Securing Service Accounts

Windows 2000 services typically run under the Local System account, but they can also be run under a domain user or local account. Use local accounts whenever possible over domain user accounts.

A service runs under the security context of its service account, so if an attacker compromises a service on a member server, the service account can potentially be used to attack a domain controller. When determining which account to use as a service account, ensure that the assigned privileges are limited to what is required for the successful operation of the service. The following table explains the privileges inherent to each type of service account.

Table 6.18  Windows 2000 Account Privileges in Different Environments

Authentication service on Windows 2000 Servers	Intraforest only on Windows 2000 Servers	Multiforest with NTLM trusts between domains
Local user service account	No network resources, local access only under account's assigned privileges.	No network resources, local access only under account's assigned privileges.
Domain user service account	Network access as domain user, local access under user's privileges.	Network access as domain user, local access under user's privileges.
LocalSystem	Network access as computer account authenticated user, local access under LocalSystem.	No network resources spanning forests, local access under LocalSystem.

Important   All Windows 2000 default services run under LocalSystem, a setting that should not be changed. Any additional services added to the computer that require the use of domain accounts should be evaluated carefully before they are deployed.

Disable LM Hash Creation

Vulnerability

Windows 2000–based servers can authenticate computers running all previous versions of Windows. However, previous versions of Windows do not use the Kerberos protocol for authentication, so Windows 2000 supports LAN Manager (LM), Windows NT (NTLM,) and NTLM version 2 (NTLMv2).The LM hash is relatively weak compared to the NTLM hash and therefore prone to rapid brute force attack.

Tools such as L0phtcrack have been available for several years that can determine a password based on its LM hash using dictionary and brute force attacks. If you do not have clients that require LM authentication, you should disable the storage of LM hashes.

Countermeasure

To disable the creation of the LM hash, you must manually add a NoLMHash key to the following registry key: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\

Note   If you want to disable the creation of the LM hash, this key must be manually added to the registry. There is no way to use Group Policy to add a key to the registry; only values can be added.

Adding this key will disable the creation of the LM hash for newly stored passwords. Any existing hashes stored in the SAM database or NTDS.dit file will not be removed. Therefore, you should force all users to change their password after this setting is applied.

Potential Impact

Local administrator accounts and clients running legacy operating systems or applications that require LM hashes for authentication will not be able to connect to servers in your organization.

Contoso Scenario

In the Contoso scenario, we disabled the creation of the LM hash, by manually adding a NoLMHash key to the following registry key: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\

Note   To disable the storage of LM hashes with this registry setting you must be running Windows 2000 SP2 or later.

NTFS

Vulnerability

NTFS partitions support ACLs at the file and folder levels. This support is not available with the file allocation table (FAT), FAT32, or FAT32x file systems. FAT32 is a version of the FAT file system that has been updated to permit significantly smaller default cluster sizes and support hard disks up to two terabytes in size. FAT32 is included in Windows 95 OSR2, Windows 98, Microsoft® Windows® Me, Windows 2000, and Windows XP.

Countermeasure

Format all partitions on every server using NTFS. Use the convert utility to non-destructively convert FAT partitions to NTFS, but keep in mind that the convert utility will configure the ACLs for the converted drive to Everyone: Full Control.

For Windows 2000 Server–based computers, apply the following security templates locally to configure the default file system ACLs for workstations, servers, and domain controllers, respectively:

• %windir%\inf\defltwk.inf

• %windir%\inf\defltsv.inf

• %windir%\inf\defltdc.inf

Note   The default domain controller security settings are applied during the promotion of a server to a domain controller.

Potential Impact

No negative impact.

Contoso Scenario

All partitions on the Contoso servers were formatted with NTFS partitions.

Data and Application Segmentation

Vulnerability

There are two classes of vulnerabilities exposed by locating applications, data, and log files on the same storage volume as the operating system. One potential threat is a user or users accidentally or deliberately filling the storage volume with data by causing an application log file to fill up the drive or by uploading files to the server.

The second potential threat is through directory traversal exploits in which an attacker takes advantage of a bug in a network service to navigate up the directory tree to the root of the system volume. The attacker may then back down through the operating system file folders to remotely execute a utility.

There are thousands of variations on directory traversal attacks that exploit scores of vulnerable applications and operating systems. IIS has been vulnerable to several over the past few years. For example, the NIMDA and Code Red worms used a buffer overflow exploit to traverse Web site directory trees and then remotely execute cmd.exe to gain access to a remote shell and execute additional commands.

Therefore, whenever possible it is necessary to locate Web content, applications, user data, application logs, and any other files not required by the operating system on the system volume in a separate storage partition.

Countermeasure

Relocate Web content, applications, data, and application log files to a partition separate from the system volume.

Potential Impact

No significant negative impact.

Contoso Scenario

The details of how these issues are addressed in the Contoso scenario are discussed in Chapter 7, "Hardening Specific Server Roles."

Configure SNMP Community Name

Vulnerability

The SNMP protocol is inherently weak when it comes to security. The single biggest vulnerability with SNMP is that nearly all vendors set a default community string name. These default community names are well known; for example, Microsoft uses the word Public.

A second vulnerability is more difficult to overcome: Because SNMP traffic is all sent in cleartext, when an SNMP management device connects to an SNMP client, the community string is transmitted across the network without being encrypted or hashed. This second vulnerability can be addressed by encrypting all traffic between servers. However, this countermeasure is beyond the scope of this guide.

Countermeasure

Configure the SNMP community string for read access on all computers to a random alphanumeric value. This configuration can be done from the Services console by double-clicking SNMP Service and then clicking the Security tab from the SNMP Service Properties dialog box. Select public from the list of Accepted community names, click the Edit button, and type the new community name in the SNMP Service Community Name dialog box when it appears. Click the OK button to close each of the dialog boxes. Leave write access through SNMP disabled.

Note   The community name is stored in the Registry as a registry value with a DWORD value of 4, so you could automate this change by creating a script or adding a line to the baseline.inf security template before importing it into the Member Server Baseline Policy. The value is stored in: HKLM\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities

Potential Impact

The community string on all management tools that use the SNMP protocol also must be reconfigured.

Contoso Scenario

In the Contoso scenario, the SNMP community string is reconfigured to mouse3pad.

Configuring IPsec Policies

Internet Protocol security (IPsec) was initially designed to encrypt data as it travels between two computers, protecting the data from modification and interpretation if anyone were to see it on the network. IPsec is a key line of defense against internal, private network, and external attacks.

Although most network security strategies have focused on preventing attacks from outside an organization's network, a great deal of sensitive information can be lost by internal attacks that interpret data on the network. Most data is not protected when it travels across the network, so employees, supporting staff members, or visitors may be able to plug into your network and copy data for later analysis.

Although IPsec can be used to encrypt data on the network, it is also an excellent way to secure the network layer of the defense-in-depth model. The network layer can be secured by using IPsec policies to lock down a network interface. Internal attackers can potentially mount network-level attacks against other computers. Firewalls located between the internal network and the Internet offer no protection against such internal threats, so using IPsec to block unnecessary ports offers a significantly greater level of security for an organization's assets.

Windows 2000 Server IPsec filtering was not designed to replace a full-featured firewall. IPsec filtering should be considered as a tool to harden servers. The use of IPsec can provide defense in depth against attacks that can be blocked with static. In addition, IPsec filtering can help contain and control malicious code traffic from worms and viruses. There are a few critical characteristics concerning security about IPsec filtering that should be understood before using the tool:

• A security compromise that results in an attacker obtaining either Local Administrator or Local System access could allow them to disable or change the IPsec policy.

• To ensure that the target computer is locked down adequately, the NoDefaultExempt registry setting must be configured to a value of 1. This setting is required for all IPsec filtering scenarios used in this security guidance. Instructions for configuring the NoDefaultExempt setting are described in Microsoft Knowledge Base article 254728, "IPSec Does Not Secure Kerberos Traffic Between Domain Controllers," at https://support.microsoft.com/kb/254728.

• IPsec does not provide stateful filtering for outbound connections. Therefore, static inbound filters have been created as part of this security guidance to ensure that responses to outgoing communication can be received. This approach effectively blocks the majority of attempts by an attacker to scan or connect to open ports on the servers in your network. However, it is still possible for an attacker to use special tools to create a connection through the IPsec inbound permit filter. If outbound permit filters to any destination Internet Protocol (IP) address are required (for example, an outbound filter to allow an Simple Mail Transfer Protocol (SMTP) server to send mail to any other destination STMP server connected to the Internet), then a firewall or other stateful filtering device must be placed between the host computer and the Internet. When possible, outbound permit filters should be specific to the IP address required to receive the traffic.

Important   IPsec does not provide complete security filtering during computer startup. There is a small window of time in which the TCP/IP stack is responsive, and that an automated attack could potentially access applications ports that the IPsec policy would otherwise block. In most cases, the application has not been able to start processing connections before IPsec filtering is in place. Setting service dependencies on the IPsec Policy Agent service startup will not effectively guarantee the filters are in place.

To achieve the highest level of security using IPsec filters, the computer should be disconnected from the network during restart. The exact time that IPsec filters are in place depends on many factors specific to the server configuration and the size of the IPsec policy. Local testing should be performed to determine a safe time interval before reconnecting your servers to your network. If testing cannot be performed, a firewall or filtering router should be used to restrict incoming traffic to only the permitted ports.

There are several terms that will be used throughout the remainder of the document.

• Filter List. Includes ports, protocols, and directions. Filter lists trigger a decision when traffic matches something specified in this list. One list can contain multiple filters.

• Filter Action. The required response when traffic matches a filter list. Specific actions will include blocking or permitting certain traffic.

• Rule. A rule is a correlation of a filter list with a filter action.

• Policy. A collection of rules. Only one policy can be active at any particular time.

Planning IPsec Policies Using Network Traffic Maps

An easy way to record this information is in a table called a network traffic map. A network traffic map contains basic information about the server role, direction of network traffic, destination of traffic, IP address of the interface, IP protocol, the TCP port, and the User Datagram Protocol (UDP) port involved. A sample network traffic map is shown in the following table.

A network traffic map helps you understand what network traffic is coming in and out of particular servers. Before creating IPsec policies, it is critical to have a good understanding of the traffic that will be required for the server to function properly. Failure to do so may result in the creation of filters that are too strict, causing application failures.

In the Contoso scenario, network services were determined that would be needed by each server role. Next, ports were identified that are required by each service. Then IPsec filters were created that allowed only the ports that had been identified. This process resulted in very restrictive IPsec filters. After implementing the filters, some troubleshooting was performed to verify that all of the network services functioned properly. A few more ports had to be enabled, which are documented for each server role in Chapter 7, "Hardening Specific Server Roles." By starting with the most restrictive IPsec filters and opening up additional ports as needed, the highest possible security was achieved for these settings.

Table 6.19  IPsec Network Traffic Map

Service	Protocol	Source port	Destination port	Source address	Destination address	Action
HTTP Server	TCP	ANY	80	ANY	Host IP	ALLOW
HTTPS Server	TCP	ANY	443	ANY	Host IP	ALLOW
DNS Client	TCP	ANY	53	Host IP	ANY	ALLOW
	UDP	ANY	53	Host IP	ANY	ALLOW

It makes the process much easier if you divide the services into client and server services. The client services can be any service that the computer uses from another host. For example, in the preceding table the server may need DNS client services to perform name lookups for one of the Web applications.

The server services are any service that the computer provides to other hosts. For example, in the preceding table the Web server will be providing HTTP and HTTPS services to other computers, so appropriate traffic must be allowed. Sample scripts which implement the settings documented in Chapter 7, "Hardening Specific Server Roles" can be downloaded with this guide.

The data in the network traffic map will vary based on the role of the server. When this chart is completed, the IPsec policies can be built based on this information. It is possible to distribute the IPsec policies based on Group Policy, but because many of the IPsec policies will be tailored to specific computers, it may be better to use local policies to implement these changes.

Implementing IPsec Policies

IPsec policies can be implemented through the "IP Security Policies" section of the Local Security Settings MMC snap-in. This process is easy to implement on one server, but may be difficult to achieve on many servers. For this reason, in this section, the scripted method of deploying IPsec policies is discussed.

Scripted Implementation

Included in the Windows 2000 Resource Kit is IPSecPol.exe, a command-line utility that you can use to create, assign, and delete IPsec policies. IPSecPol.exe is very flexible; it can create dynamic and static policies in Active Directory and in local and remote registries. See the documentation in the Windows 2000 Resource Kit for complete information. This guide provides guidance on creating static policies in the local computer's registry. You can download the IPSecPol.exe tool from www.microsoft.com/downloads/details.aspx?displaylang=en\&FamilyID=7D40460C-A069-412E-A015-A2AB904B7361.

IPSecPol.exe has quite a number of parameters, and its syntax can be confusing to understand at first. However, if you use the following examples, you can duplicate the entire configuration shown previously in the graphical user interface (GUI) examples with three commands. You might want to open the MMC and refresh its display after each command to verify that the command performed in the way that you were expecting. Let's get started.

The first command creates a new policy, adds a rule to the policy, and adds two filter lists and one filter action to the rule:

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

ipsecpol -w REG -p "Packet Filter"
-r "Inbound web protocols"
   -f *+192.168.0.201:80:TCP -f
   *+192.168.0.201:443:TCP -n PASS

The command is shown on two lines for printing; enter it as a single line. The parameters are:

• -w REG -Write a static policy to the registry, which is exactly the same as using the MMC.

• -p "Packet Filter" -Create a policy called "Packet Filter."

• -r "Inbound web protocols" -Create a rule called "Inbound Web protocols."

• -f *+192.168.0.201:80:TCP -Add a filter, where * specifies any source address and any port, 131.107.1.1:80 specifies the destination address (the server's own address) and specific port, :TCP specifies the protocol, and + indicates that the filter is mirrored.

• -f *+192.168.0.201:443:TCP -Same as the previous, except that the destination port is 443.

• -n PASS -Pass the traffic through without negotiating security.

Note The values of the -w, -f, and -n parameters are case-sensitive—use lower case only.

As many filters as necessary may be created. If the server runs multiple services, a separate IPSecPol.exe command should be used for each class of filters. For example, in addition to the listed Web services, the following command would allow inbound connections to port 25 and would allow outbound connections to anywhere on port 25:

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

ipsecpol -w REG -p "Packet Filter"
-r "SMTP Protocol" 
   -f *+192.168.0.201:25:TCP -f 
   192.168.0.201+*:25:TCP -n PASS

The last filter, -f 192.168.0.201+*:25:TCP, looks a little different. It allows outbound traffic to originate from the server's own address on any port to any server on port 25. This filter allows the server to initiate outbound SMTP connections to the Internet.

However, this filter is mirrored, which also allows any remote computer to connect to any local port on the computer if the traffic originates from port 25. There are several tools available to modify the source port of traffic, otherwise known as "source port spoofing." To protect your computer against such an attack, multiple one way "BLOCK" filters can be created to prevent any unwanted traffic from coming in on port 25 and reaching other open ports on the server. For more information on preventing this type of attack, see Chapter 11, "Additional Countermeasures" of the Threats and Countermeasures Guide at https://go.microsoft.com/fwlink/?LinkId=15159.

The next command creates the generic rule that matches all traffic and blocks it:

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

ipsecpol -w REG -p 
"Packet Filter" -r "All inbound traffic" 
   -f *+192.168.0.201 -n BLOCK

The parameters are:

• -w REG -Write a static policy to the registry, which is exactly the same as using the MMC.

• -p "Packet Filter" -Add to the existing policy called "Packet Filter."

• -r "All inbound traffic" -Create a rule called "All inbound traffic."

• -f *+192.168.0.201 -Add a filter, where * specifies any source address and any port, 192.168.0.201 specifies the destination address and any port, the absence of a protocol means any protocol, and + indicates that the filter is mirrored.

• -n BLOCK -Block the traffic.

The last command assigns the policy:

ipsecpol -w REG -p "Packet Filter" –x

The parameters are:

• -w REG -Write a static policy to the registry, which is exactly the same as using the MMC.

• -p "Packet Filter" -Add to the existing policy called "Packet Filter."

• -x -Assign the policy.

When adding IPSecPol.exe support to your server build scripts, it is recommended to not actually assign the policy until after the server is completely built. The script should include only the -n PASS and -n BLOCK commands; after all the servers are installed, the policies can be remotely assigned using this form of the command:

ipsecpol \\machinename -w REG -p "policyname" –x

Administrative rights are required on the computer specified in the command. To temporarily unassign a policy, replace the -x with -y.

An entire policy can be deleted in the same fashion, including all associated filter lists and filter actions. The command to delete the policy is:

ipsecpol -w REG -p "policyname" –o

Server Roles

Because of the specific nature of each server role, specific policies will have to be created for each role. These server specific steps are included in Chapter 7, "Hardening Specific Server Roles."

Summary

This chapter explains the server hardening procedures initially applied to all of the servers in the scenario for Contoso, Ltd. Most of these procedures were accomplished by creating a security template and importing it into a GPO linked to the parent OU for the member server.

However, some hardening procedures can not be applied through Group Policy. For this reason, these were configured manually. Additional steps were taken for specific server roles to enable them to function within their roles in as secure a manner as possible.

The role-specific steps include both additional hardening procedures, as well as procedures to reduce the security settings in the baseline security policy. These changes are discussed in detail in Chapter 7, "Hardening Specific Server Roles."

More Information

For more information on disabling NetBIOS, see Appendix C, "Disabling NetBIOS on Servers in Untrusted Networks."

For information about the STRIDE (Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privilege) threat model, see the STRIDE Threat Model page on MSDN® at https://msdn2.microsoft.com/en-us/library/ms954176.

For information on security and privacy at Microsoft, see the Trustworthy Computing: Security Web site at https://www.microsoft.com/mscorp/twc/security/default.mspx.

For information on using Active Directory to delegate administration, see the "Design Considerations for Delegation of Administration in Active Directory" article at www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/addeladm.mspx.

For information on security threats, see the Security Threats page on Microsoft TechNet at www.microsoft.com/technet/security/bestprac/bpent/sec1/secthret.mspx.

For more information about the relationship between .inf and .adm files, see the "Location of ADM (Administrative Template) Files in Windows" article at https://support.microsoft.com/default.aspx?scid=228460.

For more information about applying the 299687 Security Hotfix in an environment that has Exchange 2000 Server, see the "XADM: Clients Cannot Browse the Global Address List
After You Apply the Q299687 Windows 2000 Security Hotfix" article at https://support.microsoft.com/default.aspx?scid=309622.

For more information about hardening the Windows 2000 TCP/IP stack, see the "How to harden the TCP/IP stack against denial of service attacks in Windows 2000" article at https://support.microsoft.com/default.aspx?scid=315669.

For more information about hardening the settings for Windows Sockets applications, see the "Internet Server Unavailable Because of Malicious SYN Attacks" article at https://support.microsoft.com/default.aspx?scid=142641.

For more information on ensuring that more secure LAN Manager Authentication Level settings work in mixed networks, see the "Authentication Problems in Windows 2000 with NTLM 2
Levels Above 2 in a Windows NT 4.0 Domain" article at https://support.microsoft.com/default.aspx?scid=305379.

For more information about LM hash authentication, see the "How to Disable LM Authentication on Windows NT" article at https://support.microsoft.com/default.aspx?scid=147706.

For more information about disabling the creation of LM hashes, see the "How to prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases" article at https://support.microsoft.com/default.aspx?scid=299656.

For more information about resolving authentication issues created by disabling null sessions, see the "How to access network files from IIS applications" article at https://support.microsoft.com/kb/207671.

To download the Windows 2000 Resource Kit, see www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx.

For more information about Windows documentation and resource kits, see the Windows Deployment and Resource Kits Web site at www.microsoft.com/windowsserver2003/techinfo/reskit/resourcekit.mspx.

Download

Get the Securing Windows 2000 Server

Solution Accelerator Notifications

Sign up to stay informed

Feedback

Send us your comments or suggestions