Securing Windows 2000 Server

Article
02/20/2014

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 7: Hardening Specific Server Roles

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.

The previous chapter provides you with a solid understanding of how to develop and deploy a secure baseline using Group Policy for the Microsoft® Windows® 2000 servers in the Contoso, Ltd. scenario. When a secure baseline across these servers is established, you need to consider how to secure each server according to the role that it plays in the infrastructure of your organization.

This chapter contains the recommended security settings to achieve a secure environment for the following four major server roles that are present in most organizations running Windows 2000 servers:

Active Directory® directory service domain controller
Infrastructure Server, providing DHCP and WINS services
File and Print Server
Internet Information Services (IIS)

Each server in your environment hosts a set of application services that dictate a complementary set of security settings that must be applied to ensure maximum availability and reliability of those services. These sets of security settings that you apply ensure that the data accessible from those servers is protected.

As detailed in the Member Server Baseline Policy (MSBP) discussed in Chapter 6, "Hardening the Base Windows 2000 Server," Group Policy is used to apply as many security enhancements to the Windows 2000 servers in your environment as possible.

For each server role, the policy settings are stored in individual security templates that are imported into a corresponding Group Policy object (GPO). A GPO represents a collection of policy settings used to define security settings in a Windows 2000–based environment.

For example, to secure the IIS servers in this scenario, the policy settings described are stored in the MSS IIS Role.inf security template. This template is imported into the GPO for the IIS Group Policy that is linked to the Web organizational unit (OU) in the child domain for Contoso.

The location of the GPOs within the Active Directory for Contoso is highlighted in the following figure:

Figure 7.1 OU security template GPO design by server role for Contoso

The settings contained within the security template for each server role in Figure 7.1 are defined in this chapter. However, some security hardening procedures cannot be automated through Group Policy. In these cases, specific procedures recommended for each one are described in the later sections of this chapter.

The MSS Baseline.inf security template, which is detailed in Chapter 6, "Hardening the Base Windows 2000 Server," is also used as the basis for the security template called MSS DCBaseline Role.inf. The differences between the MSS Baseline.inf and MSS DCBaseline Role.inf security templates are explained in the "Domain Controllers Group Policy" section of this chapter.

Active Directory Domain Controller Role

The domain controller server role is one of the most important roles to defend in a Windows 2000 Active Directory enterprise environment. The loss or compromise of the domain controllers would be devastating to clients, servers, and applications that consume such things as domain authentication, Group Policy, and the central lightweight directory access protocol (LDAP) directory.

Because of their importance, domain controllers should be stored in physically secure facilities, which are accessible only to qualified administrative staff. When domain controllers must be stored in unsecure locations, branch offices for example, certain security settings can be adjusted to limit the potential damage from physical threats. Where applicable, the recommended settings for domain controllers stored in unsecure locations are noted within this chapter.

Domain Controller Baseline Policy

Unlike the other server role policies detailed in this chapter, the Group Policy for the Domain Controllers role is a baseline policy, putting it in the same class as the Member Server Baseline Policy (MSBP) defined in Chapter 6, "Hardening the Base Windows 2000 Server." Therefore, the Domain Controller Group Policy requires no other security policies to be applied other than the Default Domain Policy inherited from the domain container and the Default Domain Controllers Policy configured in the Domain Controllers OU.

Because the Domain Controller Baseline Policy is based on the MSBP, you should have read Chapter 6 to understand many of the settings that are also in the Domain Controller Baseline Policy. Most of the Domain Controller Baseline Policy is a direct copy of the MSBP. Any settings in the Domain Controller Baseline Policy that differ from the MSBP are documented in this section.

Note Protection of the Directory Service (the contents of Active Directory including the objects, classes, and attributes) is addressed in Chapter 5, "Securing the Domain Infrastructure."

Audit Policy Settings

The Audit Policy settings for the Domain Controller Baseline Policy are the same as those specified in the MSBP. The baseline policy settings ensure that all the relevant security audit information is logged on the domain controllers, including Directory Services Access.

Event Log Settings

The Event Log settings for the Domain Controller Baseline Policy are the same as those specified in the MSBP.

User Rights Assignment

The Default Domain Controllers Policy specifies a number of User Rights Assignments for the domain controllers. In addition to the default settings, there are two user rights for which you should increase the security for the domain controllers:

Log on locally
Shut down the system

The recommended settings for these rights are identified in the following table.

Table 7.1 Domain Controller Baseline Policy User Rights Settings

User rights setting in UI	Groups assigned	Recommendation
Log on locally	Administrators Backup Operators Server Operators	Remove Account Operators and Print Operators because they are only used for account management. Printer shares should not be allowed from the domain controllers.
Shut down the system	Administrators Server Operators	Remove Account Operators, Backup Operators and Print Operators as they should not be allowed to shut down domain controllers.

Log on Locally

Vulnerability

Any account with the right to log on locally could be used to log on at the console of a domain controller. When someone uses Terminal Services over the network, the account also requires the Log on locally user right. If a user attempts to log on to the server using Terminal Services, that person must use an account that also has Guest Access or User Access permissions for the Terminal Services Remote Desktop Protocol (RDP).

It is a best practice to not allow unauthorized users to log on locally. In the case of the domain controllers, this best practice typically applies to the Account Operators and Printer Operators groups. Providing this privilege gives unauthorized users the ability to download, view, and potentially install new code, which can then be used to exploit any escalation of privilege vulnerability that requires local logon access.

Countermeasure

Remove the following two default groups: Account Operators and Print Operators. Neither of these default groups should require the ability to log on to the domain controllers in your environment. Perform this action through the Domain Controller Baseline Policy.

Alternatively, you can add these groups to the Deny Logon Locally privilege in the Domain Controller Baseline Policy. This privilege setting is configured in the Domain Controller Baseline Policy template.

Potential Impact

Removing these default groups could limit the delegated abilities of assigned user roles in your environment. Confirm that delegated activities will not be adversely affected.

Contoso Scenario

Only Administrators, Backup Operators and Server Operators have the Log on locally privilege on Contoso's domain controllers. Backup Operators require this privilege to support backup software, which requires service accounts. Server Operators require this privilege to be able to shut down the domain controllers, because it is also necessary to log on to the domain controller to be able to shut it down.

This setting was configured to remove these default groups in the Domain Controller Baseline Policy template.

Shut Down the System

Vulnerability

The ability to shut down domain controllers should be limited to a very small number of trusted administrators. Even though a system shutdown requires the ability to log on to the server, you should be very careful about the accounts and groups that you allow to shut down a domain controller. For detailed information, see Chapter 6 under the setting "Allow system to be shut down without having to log on."

Shutting down the domain controllers would make them no longer available to perform such functions as processing logons, serving Group Policy, and answering LDAP queries. The impact of shutting down domain controllers that possess Flexible Single-Master Operations (FSMO) roles is that these servers can disable key domain functionality, such as processing logons for new passwords (the PDC Emulator role).

Countermeasure

Remove the following three default groups from any Domain Controller Group Policy that assigns the Shut down the system privilege: Account Operators, Backup Operators, and Print Operators. These default groups should not require the ability to shut down domain controllers.

Alternatively, if you want to delegate the ability to shut down domain controllers to other groups, you can do so. However, remember that you would typically not want to shut down your central authentication databases, because then users cannot be authenticated by the domain.

Potential Impact

The impact of removing these default groups could include limiting the delegated abilities of assigned roles in your environment. Confirm that delegated activities will not be adversely affected.

Contoso Scenario

Only Administrators and Server Operators have the Shut down the system privilege on Contoso domain controllers. Backup Operators do not require this privilege to support backup software. Server Operators require this privilege because they are often delegated the ability to shut down the domain controllers without being assigned Administrators membership.

This setting to remove these default groups was configured in the Domain Controller Baseline Policy template.

Security Options

The following table outlines the security option settings that are different from those in the MSBP, or that require special considerations in the context of a domain controller. None of these settings required any changes to default client configuration to support connectivity with the domain controllers.

Table 7.2 Domain Controller Baseline Policy Security Option Settings

Security option setting in UI	Recommendation	Comment
Additional restrictions for anonymous connections	Do not allow enumeration of Security Accounts Manager (SAM) accounts and shares.	Same as MSBP recommendation in Chapter 6. This security option setting is especially important for domain controllers.
Allow server operators to schedule tasks (domain controllers only)	Disabled.	Server operators do not require this level of privilege on domain controllers.
LAN Manager Authentication Level	Send NTLM version 2 (NTLMv2) response only.	Same as MSBP in Chapter 6. Required to support Windows 98 SE clients.
Number of previous logons to cache (in case domain controller is not available)	Configure value to 0.	There is no reason to support cached domain account logons, because these servers are the domain controllers.
Secure channel: Digitally encrypt or sign secure channel data (always)	Disabled.	Same as MSBP in Chapter 6. Required to support Windows 98 SE clients and any Microsoft Windows NT® version 4.0 Service Pack 5 (SP5) or lower domain controllers in local and trusted domains.

Some of the security options documented in Table 7.2 merit additional explanation. The rest of this section details the considerations behind these settings as implemented in the domain controllers for the Contoso scenario.

Additional Restrictions for Anonymous Connections

Domain controllers are especially sensitive to the need of some clients for anonymous access. For this reason, the domain controllers must allow anonymous connections to support the following types of functionality:

Inter-forest trust relationships.
Trust relationships with Windows NT 4.0 domains.
Windows NT 4.0 Routing and Remote Access Services (RRAS) servers to look up group memberships for domain user accounts.
Windows 98 SE and Windows NT 4.0 clients with secure channel connections for domain logons.

Allow Server Operators to Schedule Tasks (Domain Controllers Only)

Vulnerability

Legitimate users who belong to the Server Operators group could schedule tasks in the Domain Controllers group. Because the Scheduler Service runs by default as System, an attacker with Server Operators membership could exploit this privilege. For example, an attacker could schedule a task that adds their account to the Domain Administrators group.

Countermeasure

Configure Allow server operators to schedule tasks (domain controllers only) to the value Disabled.

Potential Impact

Only users with domain administrator privileges will be able to schedule tasks through the Scheduler Service on the domain controllers.

Contoso Scenario

In the Contoso scenario, only administrators need the ability to schedule tasks on the domain controllers. Group Policy was used to configure Allow server operators to schedule tasks (domain controllers only) to Disabled.

LAN Manager Authentication Level

For the Windows 2000 domain controller, it is especially important that all clients are able to authenticate to a domain controller to join the domain in the first place, as well as to continue to participate in the domain. It is also very important that domain controllers authenticate to domain controllers in other domains (inter-forest or Windows NT 4.0 domains) to validate credentials outside the forest. Both of these operations require some form of local area network (LAN) Manager (that is, non-Kerberos version 5 authentication protocol) authentication.

All Windows clients (including Windows 2000 and Microsoft Windows XP) are configured by default to send LAN Manager (LM) and NTLM authentication responses (except Windows 9x clients that only send LM). They do not send NTLMv2 authentication responses by default. Therefore, enforcing NTLMv2 authentication on a Windows 2000 domain controller is not possible until all clients (and domain controllers outside the forest that participates in trust relationships) are reconfigured to send NTLMv2 responses.

Number of Previous Logons to Cache

Vulnerability

Although it is typical to allow cached logons on Windows domain clients, it is fundamentally unnecessary to cache domain logons on a domain controller—because it is impossible for the domain controller not to validate its own domain credentials.

Countermeasure

Configure the Number of previous logons to cache (in case domain controller is not available) setting to the value 0 for domain controllers.

Potential Impact

By disabling cached logons on the domain controllers, it would be impossible to authenticate previously authenticated accounts from other domains on a domain controller, if the other domain's domain controllers were all inaccessible. For example, in the Contoso child domain, it is possible that if all Contoso root domain controllers were inaccessible, accounts such as Enterprise Admins could not log on to the child domain controllers.

The impact of such a position is not permanent and is resolved as soon as access to the inaccessible domain controllers is restored.

Contoso Scenario

Group Policy was used to configure the Number of previous logons to cache (in case domain controller is not available) setting in the Domain Controller Baseline Policy to the value 0.

Secure Channel: Digitally Encrypt or Sign Secure Channel Data (Always)

Digital encryption and signing of the “secure channel” is worth investigating where it is supported. However, digital encryption and signing of the secure channel is only supported in Windows NT 4.0 SP6a or later and is not supported in Windows 9x clients. Therefore, this setting cannot be enabled on domain controllers when they have to support Windows 9x clients as members of the domain.

This setting will only enforce signing or encryption if one of the other "when possible" settings related to it has been applied to the domain controller. If neither of these settings has been applied, then this setting has no effect on the domain controller. However, when either of these other settings is enabled on the domain controller, you cannot enable this setting until the following conditions are met.

Potential impacts from this setting include disabling the ability to create or delete downstream trust relationships, disabling logons from downstream clients, and not being able to authenticate other domain users from a downstream trusted domain.

This setting should only be enabled on your domain controllers when all the following conditions are true:

All Windows 9x clients have been eliminated from the domain.
All Windows NT 4.0 clients, servers, and domain controllers (from trusted/trusting domains) have been upgraded to SP6a.
All Windows clients have been configured to enable Secure Channel: Digitally Encrypt Secure Channel Data (when possible) or Secure Channel: Digitally Sign Secure Channel Data (when possible); one or both of these settings must be enabled on the domain controllers.

System Services

The following table summarizes the prescribed system services that must be enabled on all Windows 2000 domain controllers. The system services are configured in the SCI DCBaseline Role.inf policy template, which is then imported into the Domain Controller Policy GPO.

Table 7.3 Mandatory Domain Controller Services in Baseline Policy

Service name in UI	Startup type	Comment
Distributed File System	Automatic	Required for Active Directory Sysvol share
File Replication	Automatic	Needed for file replication between domain controllers
Intersite Messaging	Automatic	Required to support Active Directory replication
Kerberos Key Distribution Center	Automatic	Allows users to log on to the network using the Kerberos V5 protocol
Remote Procedure Call (RPC) Locator	Automatic	Allows the domain controller to provide RPC name service

There are additional services that are commonly enabled on Windows 2000 domain controllers, but they are not essential in every organization. The settings recommended for these services fit the Contoso scenario, but they are frequently the subject of debate and may not be applicable in your environment.

Table 7.4 Additional Domain Controller Services Considerations

Service name in UI	Startup type	Comment
DNS Server	Automatic	Active Directory-integrated DNS is used in the Contoso environment.
IIS Admin Service	Disabled	SMTP–based Active Directory replication is not enabled in the Contoso environment, so IIS Admin Service is not needed.
NT LM Security Support Provider	Automatic	Provides security to RPC programs that use transports other than Named pipes.
Simple Mail Transport Protocol (SMTP)	Disabled	SMTP–based Active Directory replication is not enabled in the Contoso environment.

Note If you run the DCDiag.exe utility from the Windows 2000 Support Tools, it will check for all services that could run on the domain controllers in your environment. Because some services are disabled in the Domain Controller Baseline Policy—including IISADMIN, SMTPSVC, and TrkSvr—DCDiag.exe will report errors. These errors are to be expected and do not indicate a problem with your configuration.

DNS Server

Vulnerability

The DNS Server service is required to support Active Directory-integrated DNS services. The DNS Server is used to support the dynamic DNS update protocol in Windows 2000 Server.

Any running service or application is a potential point of attack—services and components that are not running cannot effectively be attacked. Therefore, to create more secure computers, a best practice is to turn off unused features to reduce the "surface area" available for attack.

Countermeasure

None. This service is required.

Alternatively, if Active Directory-integrated DNS is not required, this service may be disabled on the domain controllers and enabled in the Infrastructure server role. The Infrastructure server role could then run the DNS Server service as a primary or secondary DNS server.

Potential Impact

Disabling Active Directory-integrated DNS Services where required will make all domain operations fail, including those for replication, logon, and Group Policy. It will also cause failures in Active Directory-integrated applications such as Microsoft® Exchange 2000.

Contoso Scenario

The Contoso environment requires Active Directory-integrated DNS, so the DNS Server service Startup Type was configured to the value Automatic.

Intersite Messaging

Vulnerability

This service is required by the Active Directory Knowledge Consistency Checker (KCC). This service is also used to support SMTP–based Active Directory replication between sites. Each transport used for replication is defined in a separate add-in dynamic link library (DLL). The add-in DLLs are loaded into Intersite Messaging.

Intersite Messaging directs send and receive requests to the appropriate transport add-in DLLs, which then route the messages to Intersite Messaging on the destination computer. If you use SMTP for replication in your environment, you need to enable this service.

Any running service or application is a potential point of attack, and, conversely, services and components that are not running cannot effectively be attacked. Therefore, to create more secure computers, it is a best practice to turn off unused features to reduce the surface area available for attack.

Countermeasure

The option for the Intersite Messaging service should be configured to Automatic in the Domain Controller Baseline Policy.

Alternatively, if you want to generate manual replication topologies and thus do not need to support the KCC, you may want to disable this service.

Potential Impact

None.

Contoso Scenario

Because the Contoso environment depends on the KCC to calculate replication topologies, the Intersite Messaging service is required, and, therefore, this service was enabled in the Domain Controller Baseline Policy.

IIS Admin Service

Vulnerability

If the SMTP service is enabled, then the IIS Admin Service also needs to be enabled because the former is dependent on the IIS Admin Service.

As stated previously, any running service or application is a potential point of attack, and, therefore, to create more secure computers in your environment, it is a best practice to turn off unused features and options.

Countermeasure

Configure the option for IIS Admin Service in the Domain Controller Baseline Policy to Disable.

Alternatively, if SMTP–based replication is required, then this service should be configured to Automatic startup in the Domain Controller Baseline Policy.

Potential Impact

Because this service is required for the SMTP service to successfully run, disabling the IIS Admin Service also disables SMTP–based replication of Active Directory information. If SMTP–based replication is required to traverse slow links and high-latency links, then this setting will prevent such Active Directory replication. For this reason, you should configure this service to Automatic.

Contoso Scenario

Because the Contoso environment is composed of high-speed links between Active Directory sites, SMTP–based replication is not required, and, therefore, this service was disabled.

NTLM Security Support Provider

Vulnerability

The NTLM Security Support Provider supports the NTLM Security Support Provider Interface (SSPI) for RPC applications that call down to the SSPI for RPC message security. This service is considered essential for Windows 2000 servers to operate.

The NTLM SSPI provides the potential for RPC applications to authenticate to the domain controller using the weaker LM or NTLM authentication protocols rather than the NTLMv2 authentication protocol.

Countermeasure

None. This service, which is enabled by default, may be required for application compatibility.

This service may be disabled in some circumstances, but it is considered an essential service for supporting some older applications running under Windows 2000. If you want to disable this service, it is strongly recommended that you first test all applications running on or accessing your domain controllers to ensure that the absence of the NTLM SSPI does not cause those applications to fail.

Eliminating LM and NTLM authentication (in favor of the stronger NTLMv2 and Kerberos authentication protocols) in your environment will require some research, planning, and testing. You should first investigate the following Microsoft Knowledge Base articles:

Potential Impact

Enabling this service allows the relatively weak LM and NTLM protocols to authenticate to the domain controllers in your organization, which can be mitigated by using NTLMv2 on clients of the domain controllers.

Contoso Scenario

The NTLM Security Support Provider service is needed to support many scenarios in the Contoso environment. For this reason, this service was enabled in the Domain Controller Baseline Policy.

Simple Mail Transport Protocol (SMTP)

Vulnerability

The SMTP service on a domain controller allows other domain controllers to replicate Active Directory updates between sites by means of the SMTP protocol, as opposed to the default RPC protocol. It is useful when attempting replication across very slow or high-latency network links between sites containing domain controllers and is necessary when an organization does not allow RPC to cross internal network boundaries such as firewalls.

Intersite replication can occur using either RPC or SMTP. If you use SMTP for intersite replication in your environment, you must enable the SMTP service.

SMTP presents two potential vulnerabilities:

As an additional service that listens remotely and acts on data that is submitted to it, SMTP could potentially be subverted through buffer overflows.
The SMTP server can authenticate incoming SMTP requests by using domain user accounts. However, because the SMTP server does not apply the usual account lockout logic that is enforced by Active Directory's Password Policy, an attacker is able to retry passwords for domain accounts without the usual lockouts or delays.

Countermeasure

If SMTP–based Active Directory replication is not needed for your environment, the option for the SMTP service should be configured to Disabled in the Domain Controller Group Policy.

Alternatively, if you do not want to disable the SMTP service, you may want to investigate securing the SMTP service itself with either Access Connection filters—the SMTP Server Properties, Access tab, and Connection button—or Internet Protocol Security (IPsec) filters that block connections on TCP port 25 for all but specified Internet Protocol (IP) addresses. IPsec is a developing standard for security at the network or packet processing layer of network communication. It is useful for implementing virtual private networks (VPNs) and for authenticating or encrypting IP data between individual IP hosts.

You should also consider enabling the SMTP service only on replication partners that replicate between domains that require SMTP–based Active Directory replication.

Note If you want to enable SMTP replication, you will need to configure digital certificates on each domain controller that will participate in the SMTP replication partnership. See Appendix D, "Configuring Digital Certificates on Domain Controllers," for more details.

Potential Impact

The potential impact of disabling SMTP on domain controllers is minimal, unless you have configured SMTP–based Active Directory replication to be handled by those domain controllers—in which case the replication would fail.

Contoso Scenario

All Active Directory replication in the Contoso environment was configured to occur by means of the IP (otherwise known as RPC) transport. For this reason, the SMTP service was disabled.

File Access Control Lists

Vulnerability

File permission ACLs for all newly-created volumes other than the %SystemDrive% (usually the C partition) default to Everyone: Full Control. Therefore, any files or folders added to such volumes will generally inherit Everyone: Full Control permissions.

Any file shares created on such volumes will expose the shared files to these file permissions by default. These files would then be exposed to Information Disclosure and Tampering with Data threats as defined in the STRIDE (Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privilege) model. See Chapter 2, "Defining the Security Landscape" in the "Categorizing Threats" section for a more detailed description of these threats.

The only file permission ACLs changes that are enabled in the Domain Controller Baseline Policy are on the %SystemDrive%.

You should update the file permissions on any additional nonremovable volumes that are created along with the %SystemDrive% (for example, the D, E, and F partitions), especially the partition that contains the Active Directory database, the DNS log files, and any other sensitive data files.

Countermeasure

Configure the default permissions for all nonsystem disk partitions by enabling Full Control inheritable permissions for Administrators, Creator/Owner, and SYSTEM. Do not assign permissions to any other groups or users. Assigning such permissions to Creator/Owner allows the system to assign ownership to individual administrators rather than just to the Administrators group.

Alternatively, you may want to select different permissions for the root of each volume. However, at a minimum you should ensure that the permissions on the folders for DNS logs and for the Active Directory database and log files are locked down to allow Full Control only for Administrators and SYSTEM.

Potential Impact

Any applications already installed in these nonsystem partitions might fail to operate properly if the existing permissions are overwritten. Some Windows applications are configured to set their own explicit permissions in the directories in which they are installed. For this reason, these applications should always be tested in a lab environment with the permission setting changes applied to them as recommended here.

Contoso Scenario

The %SystemDrive% (typically the C partition) root permissions were configured in the Domain Controller Baseline Policy to allow Full Control only for Administrators, Creator/Owner, and SYSTEM and to inherit and propagate those permissions to child folders and files. For other disk partitions, those permissions were configured manually.

To change root folder permissions on nonsystem disk partitions (for example the E partition) manually

Open a command prompt.
Type the following command:
cacls e:\ /t /g administrators:F system:F "creator/owner":F
When prompted, type Y to proceed.

Additional Security Settings—Directory Services

Disabling the NoLmHash Setting on Domain Controllers

Vulnerability

The NoLmHash setting mitigates the vulnerability of the storage of LM hashes in the accounts database and prevents the use of LM Challenge/Response authentication.

However, whereas the NoLmHash setting was enabled in the MSBP, it is not possible in the Contoso scenario to enable this setting on the domain controllers because Contoso needs to support the Windows 98 clients in the scenario that are not capable of NTLM or NTLMv2 authentication. Because the Contoso Windows 98 clients can only authenticate with the LM authentication protocol, the domain controllers must preserve the ability to authenticate using LM, as well. Unfortunately, this ability requires a stored version of the LM Hash on the domain controllers, which precludes the use of the NoLmHash setting on any Contoso domain controllers.

Countermeasure

Ensure that the NoLmHash registry key does not exist on your domain controllers.

Potential Impact

The impact of not disabling the LM Hash creation is to continue to store an LM hash value representing users' passwords in Active Directory. However, the risk of attackers gaining access to these weaker hashes is generally lower on domain controllers than on servers and workstation because physical access is usually harder to obtain for domain controllers. See the Use of Syskey topic later in this chapter for more information on mitigating physical access attacks.

Not disabling the creation of the LM Hash also allows the LM Challenge-Response authentication to occur over the network, which is the weakest of the Windows challenge-response authentication methods. This method is required for support of Windows 98 SE clients, but is not necessary after all Windows 9x clients have been removed from the domain environment.

Contoso Scenario

The manual change to disable the creation of the LM hash was not performed on the domain controllers. The NoLmHash key was not added to the HKLM\SYSTEM\CurrentControlSet\Lsa registry key in the domain controllers' registry.

Data Relocation—Active Directory Database and Log Files

Vulnerability

The database and log files (ntds.dit, edb.log, and temp.edb) are always exclusively locked when the directory service is online; that is, these files cannot be directly read or written. However, it is theoretically possible that they could be subverted if an attacker somehow gained access to the files through the (lsass.exe) process that locks these files.

It is a best practice to move the Active Directory database and log files to a nonsystem disk volume to improve domain controller performance, preferably to a striped or striped/mirrored volume. General security best practices also recommend that sensitive files such as these should be moved off the system volume to minimize the risk of directory traversal attacks on these files.

Countermeasure

Ensure that during installation of the Active Directory domain controller, you select store the Database and Log directories on a nonsystem volume (usually not on the C: volume). The best choice would be a high-performance disk volume such as a striped or striped/mirrored array.

Alternatively, for pre-existing domain controllers—assuming that you have not already moved these files off the system partition—you could move the Active Directory database and log files by doing the following:

Change the ACL on these files in the nonsystem partition.

Note If you configure the ACLs in the previous "File Access Control Lists" section this change will not be necessary, because the more secure ACLs will propagate from the root folder permissions.
Change the ACL on the boot.ini file that protects the computer restart configuration to prevent an attacker from making Directory Services Restore Mode the default restart selection and then rebooting the server.

Potential Impact

Placing the database and logs on a nonsystem volume during installation has minimal or no impact, as long as a volume with sufficient size and performance is chosen.

Moving the database and logs on an existing domain controller can have significant impact, because the computer will have to be taken offline during the operation. Also, there is always the small risk that the hardware could fail during the move procedure.

Always create a backup of the System State before proceeding with such an operation. For complete instructions on the following procedure, see the Microsoft Knowledge Base article 257420, "How To Move the Ntds.dit File or Log Files," at https://support.microsoft.com/default.aspx?scid=257420.

Contoso Scenario

In the Contoso environment, the database and logs were installed on a nonsystem volume during the installation process.

To change the location of the Active Directory database and logs during installation of a domain controller

Start Dcpromo.exe, and make your chosen configurations in the Database and Log locations dialog box.
Type your chosen alternative for the database location (for example, D:\NTDS) and log location (for example E:\NTDSLogs).
Continue with the remaining DCPROMO steps.

To move the database and logs on an existing domain controller

Restart the domain controller.
Press F8 at the Startup menu, click Directory Services Restore Mode, and then log on as the administrator when prompted.
Start the ntdsutil.exe utility, and then type files at the ntdsutil prompt.
At the File Maintenance prompt, use one or both of the following procedures:
1. To move a database, type move db to %s (where %s is the drive and folder to which you want to move the database).
2. To move log files, type move logs to %s (where %s is the drive and folder to which you want move the log files).
To view the log files or database, type info and to verify the integrity of the database at its new location, type integrity
Type quit and then type quit again to return to a command prompt.
Restart the computer in Normal mode.

Note A domain controller that has been successfully promoted has the following permissions assigned by default to the Ntds folder structure: Administrators and SYSTEM = Full Control. No additional lockdown of these files is recommended.

Secure the Pre–Windows 2000 Compatible Access Group

Vulnerability

The default permissions on most objects in Active Directory assign read access to the Pre–Windows 2000 Compatible Access group. All User and Group objects have this permission, and the domain partition assigns the List Contents permission to this group.

When the Everyone special group is made a member of the Pre–Windows 2000 Compatible group in an Active Directory domain, all User and Group objects become allowed for LDAP read operations by anonymous users, including each user object's group memberships. These anonymous users can also list the contents of the domain.

Countermeasure

Remove the Everyone alias from the Pre–Windows 2000 Compatible Access group for an existing domain.

Alternatively, for new domains, choose the permissions compatible only with Windows 2000 servers setting in the Permissions dialog box during the DCPROMO process for the first domain controller.

Theoretically, you could remove the inherited permissions for the Pre–Windows 2000 Compatible Access group from the domain container. However, removing blanket permissions creates a greater risk because this alternative has not been fully tested by Microsoft. Also, this approach limits your flexibility to make the most of this permission in the future.

It should also be pointed out that changing those permissions on Active Directory objects does not strengthen security in your environment any more than emptying the Pre–Windows 2000 Compatible Access group in the first place to ensure that this group remains empty unless an attacker or worm added another account to this group.

Potential Impact

Any applications that require anonymous access to Active Directory will lose their ability to work as expected. Services and applications known to suffer when the Everyone group is removed from the Pre–Windows 2000 Compatible Access group include:

Remote Access Service (RAS) running on Windows NT 4.0 backup domain controllers (BDCs).
Routing and Remote Access Service (RRAS) running on Windows NT 4.0 servers.
Microsoft SQL Server™ 2000 for batch mode resolution of users' group membership.

Note SQL Server 2000 running on Active Directory member servers can get the access that it needs by alternatively placing the member server's computer account in the Pre-Windows 2000 Compatible Access group, rather than adding the Everyone group.
The procedure for viewing user and group lists from trusted domains—otherwise the group name has to be typed manually.

Contoso Scenario

In the Contoso scenario, the Everyone alias was removed from the Pre–Windows 2000 Compatible Access group for each domain using the following procedure.

To remove the Everyone alias from the Pre–Windows 2000 Compatible Access group

Start a command prompt on a domain controller in the domain where this group is to be removed.
Type the following command:

Note The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.
```
net localgroup "Pre-Windows 2000 Compatible 
```

Access" Everyone /DELETE

Type net localgroup "Pre-Windows 2000 Compatible Access" to confirm that the group is now empty.

You should see the following results:

Note Some of the lines in the following code have been displayed on multiple lines for better readability.
```
C:\>net localgroup "pre-windows
```

2000 compatible access" Alias name pre-windows 2000 compatible access Comment A backward compatibility group which allows read access on all users and groups in the domain Members

The command completed successfully.

Restart all domain controllers in the domain for this setting to take effect.

Remove the Add Workstations to Domain Right

Vulnerability

By default, all authenticated users have the ability to add up to 10 computer accounts to a Windows 2000 domain. These new computer accounts are created in the Computers container.

As opposed to the Windows NT 4.0 domain model, in a Windows 2000 domain each computer account is a full security principal, with the ability as the computer to authenticate and access domain resources. Some organizations want to limit the number of computers in the Active Directory environment so that they can be consistently built and managed.

Giving users the ability to add workstations to the domain can hamper this effort. It also provides avenues for users to perform activities that would be more difficult to trace by allowing them to create additional unauthorized domain computers.

Finally, if an existing computer shuts down gracefully, it will unregister its Service Principal Name (SPN) from Active Directory. During the time that the computer is down—for example, after a Denial of Service (DoS) attack—an attacker could register their own computer to that SPN and then intercept all traffic destined for the legitimate server.

Countermeasure

Remove the Authenticated Users group from the Add workstations to domain user right in the Default Domain Controllers Policy.

Alternatively, if you want to allow a different, more restricted group of users to create computer accounts, you can change the value of Add workstations to domain user right in the Default Domain Controllers Policy. For example, you could create a new domain group called Computer Account creators, populate the new group with the accounts of users who should have the Add workstations to domain right, and then add the new group name to this domain right in the Default Domain Controllers Policy.

You also can assign the Create Computer Accounts and Delete Computer Accounts permissions on any OU (or the domain container) in the Active Directory domain to specific groups of users. Users with these permissions are able to create any number of computer accounts in that container (for example, a branch office OU) to which they have these permissions.

For example, a security group called Server Management Staff could be assigned the Create Computer Accounts and Delete Computer Accounts permissions on the Member Servers OU. Any member of the Server Management Staff group would then have the ability to create any number of computers accounts in the Member Servers OU. For more information about creating computer accounts in OUs, see the Microsoft Knowledge Base article 251335, "Domain Users Cannot Join Workstation or Server to a Domain," at https://support.microsoft.com/default.aspx?scid=251335.

Finally, if you still want to allow all Authenticated Users to create computer accounts by means of the Add workstations to domain privilege, but fewer than the default setting for ten accounts, you can change the value of the ms–DS–MachineAccountQuota attribute from the default value of 10 to another decimal value greater than 0. Setting this value to 0 disables this privilege. For more information, see Microsoft Knowledge Base article 251335 (referenced in the previous paragraph).

Potential Impact

Users who previously had the ability to add their own workstations to the domain will no longer be able to perform that action. This lack of capability could have an impact on their ability to perform their jobs, especially if they frequently create computer accounts.

This step can increase the overhead for the environment by forcing the organization to provision computer accounts ahead of time for new computers. It also can increase the need to coordinate computer rollouts with a central information technology (IT) release management team, which will have to create the computer accounts on demand.

Creating computer accounts ahead of time for new computers also creates a new vulnerability. The longer new computer accounts go unclaimed, the more likely someone may "steal" one by adding an unauthorized computer to the domain, and registering it under the name of an unclaimed account. Such a scenario is possible because Windows 2000 uses a predictable default computer account password. The default password for each unused account registered in Active Directory remains the same until a new computer claims one by joining the domain.

The computer account "theft" would typically be reported when the legitimate user is unable to join their new computer to the domain. However, the attacker may use the domain computer during this interim period.

Contoso Scenario

In the Contoso scenario, all additions to the network are performed by IT staff that has Create/Delete permissions in the relevant OUs. No users are allowed to add workstations to the domain, so the privilege was revoked for all users.

The Authenticated Users group was removed from the Add Workstations to Domain right in the MSS DCBaseline Role.inf template using the following procedure.

To modify the groups that have the Add workstations to domain privilege

Start Active Directory Users and Computers as a user with permission to edit the Default Domain Controllers Policy GPO.
Right-click the Domain Controllers OU and choose Properties.
Click the Group Policy tab, click the Default Domain Controllers Policy GPO and then click the Edit button.
Double-click the Windows settings folder, Security Settings, Local Policies, and then User Rights Assignment.
Double-click the Add workstations to domain setting.
To remove a member, click that member (for example Authenticated Users), and then click the Remove button.
To add a member, click the Add button, select the user or group, and then click OK.

Protect Against Denial of Service Attacks on Kerberos/TCP

Vulnerability

There are limited conditions under which Windows 2000 domain controllers will temporarily stop accepting the Kerberos protocol requests through TCP, which is a known issue that can be resolved with a post-SP3 hotfix. A hotfix is a cumulative package composed of one or more files used to address a defect in a product. Hotfixes address specific customer situations and may not be distributed outside the customer organization without written legal consent from Microsoft.

This vulnerability is detailed more fully in Microsoft Knowledge Base article 320903, "Clients Cannot Log On by Using Kerberos over TCP" at https://support.microsoft.com/default.aspx?scid=320903.

It is extremely unlikely that even highly utilized domain controllers will experience this issue during legitimate use. However, it is possible that an attacker may exploit this DoS condition and temporarily exhaust the ability of a domain controller to service Kerberos through TCP requests.

By default and by design, the Kerberos authentication protocol traffic is sent and received on User Datagram Protocol (UDP) port 88. If the Kerberos protocol packets exceed 2,000 bytes (the default size limit) then Windows 2000 will switch to using TCP port 88.

Some organizations will choose to configure their Windows 2000 and Windows XP clients to always use TCP for the Kerberos protocol traffic. Microsoft Knowledge Base article 244474, "How to force Kerberos to use TCP instead of UDP in Windows Server 2003, in Windows XP, and in Windows 2000," at https://support.microsoft.com/default.aspx?scid=244474 explains the most common situation that warrants making this change.

Countermeasure

If your environment is such that you believe this vulnerability to be a credible threat, or if you are experiencing the conditions detailed in Microsoft Knowledge Base article 320903, obtain the hotfix prescribed in this Knowledge Base article from Microsoft and deploy it to all affected domain controllers.

Alternatively, you could monitor the calls to your help desk for indications of unusually slow logon times, which might mean that you are experiencing this issue. However, slower than usual logon times can be the result of many other issues. Determining what is causing slow logon times is notoriously difficult.

You also can limit the use of the workaround detailed in Knowledge Base article 244474 to minimize the volume of Kerberos traffic through TCP. However, 244474 describes a problem of failed logons, which are often due to dropped packet fragments. Problems related to this issue are much harder to resolve without switching over to TCP. If you have deliberately chosen to make that switch, it is unlikely you will be able to switch back to the UDP.

Also, many organizations are choosing to increase the reliability of their Kerberos protocol authentication, because this authentication protocol method is becoming key to their enterprise applications, and switching to TCP is a key means of increasing this reliability. For these reasons, limiting the use of TCP to minimize the DoS potential is not recommended.

Potential Impact

The potential impact is the same as for any hotfix. As always, you should be sure to test before rolling out the hotfix to your production environment.

Contoso Scenario

In the Contoso scenario, there is a high degree of sensitivity to logon times and the potential of internal network attacks. For this reason, the hotfix for Microsoft Knowledge Base article 320903 was deployed as a proactive measure.

To obtain and deploy the hotfix for 320903

Contact Microsoft Product Support or the Premier Help Desk and request the hotfix prescribed in Knowledge Base article 320903.
Test and deploy the hotfix according to your organization's existing hotfix testing and deployment processes.

Additional Security Settings—Active Directory Integrated DNS

Microsoft recommends using Active Directory-integrated DNS, in part because integrating the zones into Active Directory simplifies the process of securing the DNS infrastructure.

Protect DNS Servers

Vulnerability

When a DNS server is attacked, one possible goal of the attacker is to control the DNS information being returned in response to DNS client queries. This way, clients could be misdirected to unauthorized computers without their knowledge. IP spoofing and cache poisoning are examples of this type of attack.

In IP spoofing, a transmission is given the IP address of an authorized user to obtain access to a computer or network. Cache poisoning occurs when by default any names added from referral answers are cached to help expedite resolving subsequent DNS queries.

After clients start inadvertently communicating with unauthorized computers, those computers may attempt to gain access to information stored on the client computers.

Not all attacks focus on spoofing DNS servers. Some DoS attacks could alter DNS records in legitimate DNS servers to provide invalid addresses in response to client queries. By causing the server to respond with invalid addresses, clients and servers cannot locate the resources they need to function, such as domain controllers, Web servers or file shares. This issue is discussed in the "Secure the DNS Data Container" section later in this chapter.

Countermeasure

Because all DNS client configurations are based on IP addresses, configure all routers to drop spoofed IP packets to ensure that the IP addresses of the DNS servers are not being spoofed by other computers.

Alternatively, you could limit the damage to your DNS servers from such attacks by monitoring DNS server performance.

Potential Impact

None.

Contoso Scenario

Because the Contoso DNS servers (domain controllers) in the Northamerica domain have a relatively high Asset Priority, all routers in the Contoso environment were configured to prevent IP address spoofing.

Not all Contoso clients are capable of using IPsec, so IPsec encryption or signing was not enabled on the DNS servers. However, IPsec blocking filters were enabled for different reasons—for more information, see the "Blocking Ports with IPsec Filters" section later in this chapter.

Domain controller and DNS server performance was monitored using Microsoft Operations Manager (MOM).

Configure Secure Dynamic Updates

Vulnerability

The Windows 2000 DNS server and client supports DDNS updates, which allow client computers to add DNS records directly into the database on supporting DNS servers.

Unauthorized DDNS updates can be made to a Windows 2000 DNS server if:

The attacker operates a client that uses the DDNS protocol.
The DNS server is configured to accept unsecured updates.

At a minimum, an attacker could add bogus entries to the DNS database; at worst, the attacker could overwrite or delete legitimate entries in the DNS database. The result of this kind of attack could include:

Directing clients to unauthorized domain controllers.

When a client submits a DNS query looking for the address of a domain controller, a compromised DNS server can be instructed to return the address of an unauthorized server. Then, with the use of other non–DNS related attacks, the client might be tricked into passing on secure information to the bogus server.
Responding to DNS queries with invalid addresses.

This result would make clients and servers unable to locate one another. Without the ability for clients to locate servers they cannot access the directory. Without the ability of the domain controllers to locate other domain controllers, the directory will stop replicating.
Creating a DoS condition in which either of the following may occur:
- The server’s disk space may be exhausted by generating a huge zone file filled with dummy records.
- A huge number of entries, for example, more than 50,000, may be created in the zone container in the directory causing slow replication.

Countermeasure

You should use secure dynamic updates to prevent an attacker from registering bad records. Using secure DDNS updates guarantees that registration requests are only processed if they are sent from valid clients in the forest, which makes it more difficult for an attacker to launch this type of attack. An attacker must then gain access to a workstation that is a member of the forest first.

Alternatively, you could disable DDNS updates to prevent the described types of exploits. However, this configuration would significantly increase the cost of maintaining up-to-date DNS records because all updates would then have to be manually processed. In a Windows 2000 environment, the number of DNS records that have to be maintained is probably much higher than DNS administrators would be accustomed to in pre–Windows 2000 environments.

For more details on this issue, see the following Microsoft Knowledge Base articles:

Potential Impact

Some non–Windows 2000 computers may not be able to record DDNS entries in the Active Directory-integrated DNS zones after the zones are secured. This issue can be mitigated for DHCP clients by enabling Windows 2000 DHCP servers to register DNS records on behalf of DHCP clients.

However, the use of DHCP servers to register DDNS records will be of no help for non–DHCP clients. For computers that do not support secure DDNS updates or acquire their IP address information from a Windows 2000 DHCP server, but must have their DNS information registered in the secure Active Directory-integrated DNS zones, you will have to register these records manually.

Contoso Scenario

The Active Directory-integrated DNS servers in the Contoso scenario were manually configured to accept only secure DDNS updates.

To enable secure DDNS updates for each DNS zone (Forward Lookup Zone and Reverse Lookup Zone)

Open the DNS Server MMC snap-in and then the folder of interest (Forward Lookup Zone or Reverse Lookup Zone).
Right-click the zone of interest (for example northamerica.corp.contoso.com) and choose Properties.
On the General tab, in the Allow dynamic updates? dialog box, ensure Only secure updates is selected.

Note This procedure assumes that on the General tab of the zone of interest, the Type is configured as Active Directory-integrated.

Secure the DNS Data Container

Vulnerability

Permissions ACLs can be configured on the zone containers to limit access by users who might attempt to modify them with management tools such as the DNS snap-in or ADSIEdit. Administrators, Domain Administrators, Enterprise Administrators, and DNS Administrators have Full Control permission by default to all DNS components; everyone else is assigned Read access.

If the default ACLs are changed, you may encounter a nonmalicious threat from users who could unintentionally be assigned the permission to modify the DNS Data containers. This situation could allow modifications of the DNS server properties or any of the data being stored in the integrated DNS zones. Nonmalicious threats typically result from employees who are untrained in computers and unaware of security threats and vulnerabilities.

Countermeasure

Limit the ACLs on the Microsoft DNS container in any domain that uses Active Directory-integrated DNS to the default ACLs.

Alternatively, you could limit the membership of groups that, by default, have the ability to modify these settings and data (that is, Administrators, Domain Administrators, Enterprise Administrators, and DNS Administrators).

Potential Impact

Incorrect permission settings on the Microsoft DNS container or any of the integrated DNS zones could have very serious consequences for your organization. Permissions that are too loose could allow unauthorized users to harm your DNS servers or their zone data. Conversely, permissions that are too tight could theoretically create a DoS condition when trying to load DNS data from the directory, or when adding new dynamic updates.

Note In all cases, ensure that SYSTEM has Full Control.

Contoso Scenario

The default permissions on the Microsoft DNS and subordinate zones in the Contoso scenario were confirmed.

To view or edit the permissions for Active Directory-integrated DNS

Open the DNS Server MMC, right-click the DNS server and choose Properties.
Click the Security tab, then click the Advanced button.

Configure Protection Against DNS Cache Poisoning

Vulnerability

It is possible to add unauthorized entries directly into the cache on a DNS server so that clients may be misdirected to unauthorized locations, which would be an instance of cache pollution.

Countermeasure

Configure the Secure cache against pollution option on all DNS servers to the value Enable. With this feature enabled, the server can determine whether referred names are potentially polluting or unsecured, and then discard them.

The server determines whether to cache each referral based on whether each one can be identified as part of the exact related DNS domain name tree recorded in the original query. For more information, see Microsoft Knowledge Base article 316786, "Description of the DNS Server Secure Cache Against Pollution setting," at https://support.microsoft.com/default.aspx?scid=316786.

Potential Impact

Minimal.

Contoso Scenario

The Active Directory-integrated DNS servers were secured against cache pollution in the Contoso scenario.

To enable security against DNS server cache pollution

Open the DNS Server MMC, right-click the DNS server and choose Properties.
Click the Advanced tab and ensure the check box for Secure cache against pollution is selected.

Secure DNS Data and Log Directories

Vulnerability

Windows 2000 DNS servers that are configured for Active Directory-integrated DNS store their zone data in Active Directory. However, DNS servers configured as Primary or Secondary servers will store their zone data in a text file in %SystemRoot%\system32\dns by default.

In addition, if debug logs are configured on the DNS server, these logs are by default also stored in a text file %SystemRoot%\system32\dns.

The default permissions on both of these files allow Read and Execute access for Users and Modify access for Power Users.

This DNS server data could be compromised if the server is exposed to buffer overflow or directory traversal attacks, which can enable access to data within the system volume. A buffer overflow is a type of exploit employed by attackers to gain access to a computer.

Countermeasure

Reduce the permissions on the %SystemRoot%\system32\dns folder so that only Administrators and SYSTEM have permissions to these files.

Alternatively, you could move the data and log files to a separate disk volume or to another directory that is less well-known to attackers than the default location. Moving the files does not necessarily improve the permissions on those files however, which means they are still potentially vulnerable to attack by those who could find them (for example, by finding their location specified in the registry).

Potential Impact

Because only the Administrators and System require access to these files, the potential impact is minimal. You might delegate management of DNS services to a new group that does not have membership in the Administrators group on the DNS server. In this case, you must ensure that the new group also has permissions to access these files to fulfill their duties.

Contoso Scenario

In the Contoso scenario, all DNS data is derived from Active Directory so no file system permissions changes were necessary.

To li mit the permissions on the default DNS files directory

Open a command prompt.
Type the following command:

Note Some of the lines in the following code have been displayed on multiple lines for better readability.
```
cacls.exe %systemroot%\system32\dns 
```

/t /g administrators:F system:F

When prompted, type Y to proceed.

Note Remember to change the directory that you specify in the cacls.exe command if you happen to move the DNS files to a new but unsecured directory.

Move DNS Data and Log Directories

Vulnerability

Windows 2000 DNS servers that are configured for Active Directory-integrated DNS store their zone data in Active Directory. However, DNS servers configured as Primary servers will store their zone data by default in a text file in %SystemRoot%\system32\dns.

In addition, if debug logs are configured on the DNS server, those logs are by default also stored in a text file in %SystemRoot%\system32\dns.

This data could be read or compromised if the server is exposed to buffer overflow or directory traversal attacks, which can enable access to data within the system volume.

Countermeasure

Move the DNS zone data files and log files to a nonsystem disk partition.

Alternatively, you could reduce the permissions level in the default directory for DNS files located in the %SystemRoot%\system32\dns folder. However, this approach does not always limit the attack potential against these files, because some attacks can occur through compromised services that run as Administrator-level accounts or as SYSTEM.

Potential Impact

If you do not notify your Storage Management team of the new location for these files, they may inadvertently get missed during scheduled backups. You can avoid a potential availability issue by ensuring that your backup software is configured to back up these files in their new location.

Contoso Scenario

In the Contoso scenario, the DNS zone data is integrated with Active Directory and thus no data files were stored on disk. No changes were necessary.

In the Contoso scenario, debug logging for the DNS servers is not enabled. However, the debug log location was preconfigured to be stored on a separate disk in anticipation of potential future use of this logging functionality.

To move the DNS zone data files

Start Regedit.exe, and browse to HKLM\System\CurrentControlSet\Services\DNS\Parameters.
Select the Edit menu, choose New, String Value, and give it the name "DatabaseDirectory."
Double-click the new DatabaseDirectory value entry, and then in the Value data textbox, type the full path to the folder under which you want to store the zone data files.

Note DNS will not move or maintain the original database when you make this change in the Registry.
Stop the DNS server.
If you already have a DNS database in the Systemroot\System32\Dns folder, you must move it to the new location manually. Move the files and folders in the directory %systemroot%\system32\dns to the new drive folder (for example, d:\DNS).
Start the DNS server.

To move the DNS debug log files

Start Regedit.exe, and browse to HKLM\System\CurrentControlSet\Services\DNS\Parameters.
Select the Edit menu, choose New, String Value, and give it the name "LogFilePath."
Double-click the new LogFilePath value, and then in the Value data textbox, type the full path to the folder and file name under which you want to store the debug log files.
Restart the DNS server.

Limit Zone Transfers to Authorized Systems

Vulnerability

In addition to Active Directory-integrated DNS servers, there also are DNS servers that act as primary or secondary servers. Secondary servers typically transfer the entire zone file from the primary server to synchronize its contents.

A DNS server that is not configured to limit who can request zone transfers will allow the entire DNS zone to be transferred to anyone who requests it. This transfer can be easily accomplished using tools such as nslookup.exe, and would expose the entire domain's DNS dataset, including such things as which hosts are serving as domain controllers, directory-integrated Web servers, or SQL Server 2000 databases.

Countermeasure

Configure the DNS servers to allow zone transfers only to known computers (that is, only to secondary DNS servers).

Alternatively, you may want to not allow zone transfers. However, this configuration may be difficult to justify in a large, distributed network if you have or plan to set up a hierarchy of DNS servers and configure secondary DNS servers closer to large, remote populations of computing users.

Potential Impact

This configuration could limit services that require the ability to request the entire DNS zone at once. It could also slow down the response times for DNS clients that might have to query alternative DNS servers. It could also cause some DNS queries to fail, depending on your DNS infrastructure.

Contoso Scenario

In the Contoso Scenario there are secondary DNS zones configured on the child domain's domain controllers, which cache the root domain's _msdcs.corp.contoso.com zone. The root domain’s domain controllers were configured to only allow zone transfers for this zone to the child domain's domain controllers, according to the IP addresses of the authorized DNS servers. All other Active Directory-integrated zones were left with default configurations that do not allow zone transfers.

To limit zone transfers to known servers

Start the DNS administrative tool, right-click the zone for which you want to configure zone transfers, and click Properties.
Confirm that Allow zone transfers is enabled, and select either Only to the following servers or Only to servers listed on the Name Servers tab.
- If you chose Only to the following servers, fill in the IP addresses of those authorized DNS servers in the dialog box. (This setting was chosen for Contoso—the IP addresses of the child domain's domain controllers were added.)
- If you chose Only to servers listed on the Name Servers tab, click the Name Servers tab and fill in the information for the Name Servers (DNS servers) that are authorized to request secondary zone transfers from this DNS server, as well as being authoritative for this zone.

Blocking Ports with IPsec Filters

Vulnerability

Reducing the number of ports that are open and actively listening on the servers in your organization will greatly reduce the attack surface of each computer. The attack surface is the exposed area of the client/server computers in your environment that is vulnerable to attack.

Open ports can provide an attacker with a launching pad to attack another server in the organization—for example, a worm and Trojan horse may install applications that bind to unauthorized ports on the server, and listen for incoming commands.

Countermeasure

Configure IPsec blocking filters that allow only the network traffic specified in the following table. This countermeasure will reduce the number of unexpected and unauthorized applications that could successfully receive requests or that could be attacked.

Domain controllers require RPC traffic for several functions including client logon as shown in the traffic map. Therefore, a range of RPC ports will need to be opened as shown in the following table.

Each service is divided into client and server functionality, but does not necessarily refer to a client workstation and the server. Instead, it shows the corresponding IPsec filter that would need to be created to either use or provide the noted service.

For example, the DNS client policy should be applied on any computer that requires name services functionality. The DNS server rules would only be applied on a computer that provides DNS services. Other services, such as Simple Network Management Protocol (SNMP) may be a bit confusing, because ports for SNMP server are permitted, but not ports for the SNMP client. However, because of the nature of SNMP in which a remote station contacts individual computers for information, SNMP acts as a server service on the domain controller to provide this information to the remote station.

Before implementing IPsec filters, you must have a full understanding of the capabilities and limitations of this technology. IPsec filters are very powerful, but can greatly impact the manageability and usability of computers. For more information, see Chapter 11, "Additional Countermeasures" of the Threats and Countermeasures guide at https://go.microsoft.com/fwlink/?LinkId=15159.

Domain Controller IPsec Network Traffic Map

Table 7.5 Domain Controller IPsec Network Traffic Map

Service	Protocol	Source port	Destination port	Source address	Destination address	Action
Domain Member	ANY	ANY	ANY	0	ALL DOMAIN CONTROL-LERS	ALLOW
CIFS/SMB Server	TCP	ANY	445	ANY	0	ALLOW
	UDP	ANY	445	ANY	0	ALLOW
RPC Server	TCP	ANY	135	ANY	0	ALLOW
	UDP	ANY	135	ANY	0	ALLOW
NetBIOS Server	TCP	ANY	137	ANY	0	ALLOW
	UDP	ANY	137	ANY	0	ALLOW
	TCP	ANY	139	ANY	0	ALLOW
	UDP	ANY	138	ANY	0	ALLOW
Monitoring Client	ANY	ANY	ANY	0	MOM Server	ALLOW
Terminal Services	TCP	ANY	3389	ANY	0	ALLOW
Global Catalog Server	TCP	ANY	3268	ANY	0	ALLOW
	TCP	ANY	3269	ANY	0	ALLOW
DNS Server	TCP	ANY	53	ANY	0	ALLOW
	UDP	ANY	53	ANY	0	ALLOW
Kerberos Server	TCP	ANY	88	ANY	0	ALLOW
	UDP	ANY	88	ANY	0	ALLOW
LDAP Server	TCP	ANY	389	ANY	0	ALLOW
	UDP	ANY	389	ANY	0	ALLOW
	TCP	ANY	636	ANY	0	ALLOW
	UDP	ANY	636	ANY	0	ALLOW
NTP Server	TCP	ANY	123	ANY	0	ALLOW
	UDP	ANY	123	ANY	0	ALLOW
RPC Ports	TCP	ANY	RPC Range	ANY	0	ALLOW
ICMP	ICMP	ANY	ANY	0	ANY	ALLOW
All Inbound Traffic	ANY	ANY	ANY	ANY	0	BLOCK

Note It is important to note that the Kerberos filter is necessary if you have implemented the NoDefaultExempt setting that is specified in Microsoft Knowledge Base article 254728, "IPSec Does Not Secure Kerberos Traffic Between Domain Controllers" at https://support.microsoft.com/default.aspx?scid=254728.

All of the rules that are listed in the preceding table should be mirrored when they are implemented. This configuration ensures that any traffic coming in to the domain controller will also be allowed to return to the originating server.

As shown in the preceding table, there are a number of ports and services that have been opened on the domain controller. Configuring the tightest security on the domain controller would allow you to block additional ports. However, additional ports were opened because of the downstream client requirements for NetBIOS, as well as to provide additional usability for the administration of the computers.

To support the client logon process, a range of ports should be designated specifically for the use of RPC. When limiting RPC traffic in your environment to a certain number of ports, the port range chosen should include ports over 50,000. You can designate a range of ports by setting the following registry settings:

The HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet key should be created if it does not already exist.
The HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet\Ports should be created and configured as a REG_MULTI_SZ with a value that represents the range of ports to be opened.
The HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\Internet\
PortsInternetAvailable should be created and configured as REG_SZ with a value of Y.
The HKEY_LOCAL_MACHINE\Software\Microsoft\RPC\
Internet\UseInternetPorts should be created and configured as REG_SZ with a value of Y.

After making these changes to the Registry, the server should be restarted.

These changes could affect performance and should be tested prior to implementing in production. The exact number of ports that will be opened will depend on the use and functionality of the server.

Finally, note that Contoso has implemented a MOM server in their environment. Because of the large interaction between the MOM server and the OnePoint client—the client application that reports to the MOM console—all network traffic is allowed between the server and the MOM server.

Scripting Commands

IPSecPol is limited in the fact that it can only add ports one at a time. Because RPC will require a range of ports to be opened, the easiest way to address this limitation is through the use of a script to automatically generate a batch file with all commands necessary based on the number of ports that will be opened.

The following sample code will generate a file called C:\ipsec.bat that contains a separate listing for each port to be added into the IPsec policy. The PORT_START variable defines the first port in the RPC range and PORT_END, defines the end of the range. POLICY_NAME is the name of the IPsec Policy to which the port filters will be added. The IP_ADDR value should be modified to reflect the IP address of the server on which the policy will be implemented.

PORT_START = 57901
PORT_END = 57950
POLICY_NAME = "Packet Filter"
RULE_NAME = "RPC Ports"
BATCH_FILE = "c:\ipsec.bat"
Dim fso
Dim tf
Const ForWriting = 2
Set fso = CreateObject("Scripting.FileSystemObject")
Set tf = fso.OpenTextFile(BATCH_FILE, ForWriting, True)
tf.Write "ipsecpol -w REG -p " & chr(34) & POLICY_NAME & chr(34)
& " -r " & chr(34) & RULE_NAME & chr(34)
For i = PORT_START TO PORT_END
tf.Write " -f *+0:" & i & ":TCP"
Next
tf.WriteLine " -n PASS"
tf.Close

Similar code could be used to generate a batch file to run and establish the IPsec policies with little manual effort. The batch file will address the areas in the preceding tables marked "RPC Range." The remainder of the ports will need to be addressed with similar methods as discussed for the other server roles.

After a range of ports is decided upon and the IPSecPol statements to implement the filters are created, the combination of these and the remaining commands should be executed on the server.

This set of commands is also included in a batch file that accompanies this guide.

ipsecpol -w REG -p "Packet Filter" -r "Domain Member" -f 0+192.168.100.10:: -f 0+192.168.100.11:: -f 0+192.168.100.12:: -n PASS ipsecpol -w REG -p "Packet Filter" -r "CIFS Server" -f *+0:445:TCP -f *+0:445:UDP -n PASS ipsecpol -w REG -p "Packet Filter" -r "RPC Server" -f *+0:135:TCP -f *+0:135:UDP -n PASS ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server" -f *+0:137:TCP -f *+0:137:UDP -f *+0:139:TCP -f *+0:138:UDP -n PASS ipsecpol -w REG -p "Packet Filter" -r "Monitoring" -f 0+192.168.100.73 -n PASS ipsecpol -w REG -p "Packet Filter" -r "Terminal Server" -f *+0:3389:TCP -f -n PASS ipsecpol -w REG -p "Packet Filter" -r "GC Server" -f *+0:3268:TCP -f *+0:3269:TCP -n PASS ipsecpol -w REG -p "Packet Filter" -r "DNS Server" -f *+0:53:TCP -f *+0:53:UDP -n PASS ipsecpol -w REG -p "Packet Filter" -r "Kerberos Server" -f *+0:88:TCP -f *+0:88:UDP -n PASS ipsecpol -w REG -p "Packet Filter" -r "LDAP Server" -f *+0:389:TCP -f *+0:389:UDP -f *+0:636:TCP -f *+0:636:UDP -n PASS ipsecpol -w REG -p "Packet Filter" -r "NTP Server" -f *+0:123:TCP -f *+0:123:UDP -n PASS ipsecpol -w REG -p "Packet Filter" -r "RPC Ports" -f *+0:57901:TCP -f *+0:57902:TCP -f *+0:57903:TCP -f *+0:57904:TCP -f *+0:57905:TCP -f *+0:57906:TCP -f *+0:57907:TCP -f *+0:57908:TCP -f *+0:57909:TCP -f *+0:57910:TCP -f *+0:57911:TCP -f *+0:57912:TCP -f *+0:57913:TCP -f *+0:57914:TCP -f *+0:57915:TCP -f *+0:57916:TCP -f *+0:57917:TCP -f *+0:57918:TCP -f *+0:57919:TCP -f *+0:57920:TCP -f *+0:57921:TCP -f *+0:57922:TCP -f *+0:57923:TCP -f *+0:57924:TCP -f *+0:57925:TCP -f *+0:57926:TCP -f *+0:57927:TCP -f *+0:57928:TCP -f *+0:57929:TCP -f *+0:57930:TCP -f *+0:57931:TCP -f *+0:57932:TCP -f *+0:57933:TCP -f *+0:57934:TCP -f *+0:57935:TCP -f *+0:57936:TCP -f *+0:57937:TCP -f *+0:57938:TCP -f *+0:57939:TCP -f *+0:57940:TCP -f *+0:57941:TCP -f *+0:57942:TCP -f *+0:57943:TCP -f *+0:57944:TCP -f *+0:57945:TCP -f *+0:57946:TCP -f *+0:57947:TCP -f *+0:57948:TCP -f *+0:57949:TCP -f *+0:57950:TCP -n PASS ipsecpol -w REG -p "Packet Filter" -r "ICMP" -f 0+*:*:ICMP -f *+0:*:ICMP -n PASS ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic" -f *+0 -n BLOCK ipsecpol -w REG -p "Packet Filter" –x

Potential Impact

Because these settings still allow RPC traffic, this server will perform much as it would without the settings. The major benefit of these settings is that the RPC traffic is limited to a particular range. However, this limitation could cause performance problems based on the number of users connecting to the computer and the number of RPC connections that need to be established. A large amount of testing should be performed before implementing these filters in your environment. These filters could be tightened to restrict this functionality, but administration of the server may become difficult.

The implementation of this relatively small number of IPsec policies should not have a noticeable impact on the performance of the server. However, a large amount of testing should be performed before implementing these filters in your environment to verify the necessary functionality and performance. Additional rules also may need to be added to support other applications in your environment.

Contoso Scenario

In the Contoso scenario, the specified IPsec filters were implemented in the company's domain controllers. The listed IP address was substituted in the scripts and command lines as appropriate for each domain controller.

Discussion of Active Directory Security Issues

Use of Syskey

Syskey is enabled on all Windows 2000 servers in mode 1 (obfuscated key). There are many recommendations that recommend Syskey in mode 3 (floppy storage of Syskey password) or mode 2 (console password) for any domain controller that is exposed to physical security threats. You can also create a repair disk for your domain controller, and store that floppy disk in a secure location to provide an additional backup of the mode 2 Syskey password.

For example, Syskey mode 2 or mode 3 is often recommended for domain controllers in branch offices that do not offer strong physical storage security for the domain controller computer. From a security standpoint, this configuration at first appears sensible because the domain controller would be vulnerable to being restarted by an attacker with physical access to the domain controller, which in mode 1 would allow the attacker to read and alter the contents of the directory.

However, the operational requirements for ensuring that the domain controllers can be made available through restarts tend to make Syskey modes 2 or 3 difficult to support. To take advantage of the added protection provided by Syskey, you should be prepared to implement additional operational processes in your environment to meet the availability requirements for your domain controllers.

First, the logistics of Syskey password or floppy disk management can be quite complex, especially in branch offices. For example, requiring one of your branch managers or local administrative staff to come to the office at 3 A.M. to enter the passwords, or insert a floppy to enable other users to use the system is expensive and makes it very challenging to achieve high availability service line agreements (SLAs).

Alternatively, allowing your centralized IT operations personnel to provide the Syskey password remotely requires additional hardware—some hardware vendors make add-on hardware solutions available to remotely access the console of the server, which would be required.

Secondly, the loss of the Syskey password or floppy disk leaves your domain controller in a state where it cannot be restarted. There is no method for you to recover a domain controller if the Syskey password or floppy disk is lost. If loss of the Syskey password or floppy disk occurs, the domain controller must be rebuilt.

Infrastructure Server Role

The Infrastructure Server role in the Contoso scenario is either a DHCP or WINS server.

One difference between the Infrastructure Server definition in this guide and the Infrastructure Server role presented in the Microsoft Systems Architecture Enterprise Data Center (MSA EDC) guide is that the role here does not include DNS. The reason the Contoso scenario does not include DNS in the Infrastructure Server role is because all DNS server functionality is configured as Active Directory-integrated DNS and is hosted on domain controllers.

There may be companies, however, that do not want to integrate their DNS with Active Directory, or that want to host a primary or secondary zone on a server separate from their domain controllers. If your environment fits into one of these cases, take note of the advice in the preceding section of this chapter, "Additional Security Settings—Active Directory integrated DNS," and use the alternatives and notes provided for organizations implementing nonintegrated DNS.

Infrastructure Server Incremental Policy

The Incremental Infrastructure Policy includes settings for system services that are required on the Infrastructure server.

System Services

The following table provides a summary of the prescribed system services that should be disabled or enabled on a Windows 2000 Infrastructure Server. The services are configured in the MSS Infrastructure Role.inf policy template, which is then imported into the Infrastructure Policy GPO.

Table 7.6 Infrastructure Server Incremental Policy Service Settings

Service setting in UI	Startup type	Comment
DHCPServer	Automatic	To provide DHCP services to clients
NTLMSSP	Automatic	To provide security to RPC programs that use transports other than named pipes
WINS	Automatic	To provide WINS services to clients

Note The DNS Server service is disabled for the Infrastructure Server role in the Contoso Scenario because it runs on the domain controllers.

Some organizations that may not use Active Directory-integrated DNS may want to run their primary and secondary DNS server on an Infrastructure server.

In this case, the Incremental Infrastructure Group Policy template has to be altered to enable the DNS Server service Startup Type to be configured to Automatic.

If this functionality is necessary in your organization, see the section "Additional Security Settings—Active Directory Integrated DNS" in this chapter for recommendations on securing a Windows 2000 DNS server.

Additional Security Settings—WINS

Blocking Ports with IPsec Filters

Vulnerability

As mentioned previously, reducing the number of ports that are open and actively listening on the servers in your organization will greatly reduce the attack surface of each computer. Open ports can provide an attacker with a launching pad to attack another server in the organization—for example, a worm and Trojan horse may install applications that bind to unauthorized ports on the server and listen for incoming commands.

Countermeasure

Configure IPsec blocking filters that allow only the specified network traffic in the following table. This countermeasure will reduce the number of unexpected and unauthorized applications that could successfully receive requests or that could be attacked.

Before implementing IPsec filters, you must have a full understanding of the capabilities and limitations of this technology. IPsec filters are very powerful, but can greatly affect the management and usability of computers. For more information, see Chapter 11, "Additional Countermeasures" of the Threats and Countermeasures guide at https://go.microsoft.com/fwlink/?LinkId=15159.

WINS Server IPsec Network Traffic Map

Table 7.7 WINS Server IPsec Network Traffic Map

Service	Protocol	Source port	Destination port	Source address	Destination address	Action
Domain Member	ANY	ANY	ANY	0	ALL DOMAIN CONTROL-LERS	ALLOW
Monitoring Client	ANY	ANY	ANY	0	MOM Server	ALLOW
Terminal Services	TCP	ANY	3389	ANY	0	ALLOW
WINS Resolution Server	TCP	ANY	1512	ANY	0	ALLOW
	UDP	ANY	1512	ANY	0	ALLOW
WINS Replication Client	TCP	ANY	42	0	WINS Server	ALLOW
	UDP	ANY	42	0	WINS Server	ALLOW
WINS Replication Server	TCP	ANY	42	ANY	0	ALLOW
	UDP	ANY	42	ANY	0	ALLOW
ICMP	ICMP	ANY	ANY	0	ANY	ALLOW
All Inbound Traffic	ANY	ANY	ANY	ANY	0	BLOCK

Note The Host IP destination address listed in Table 7.7 should be set to the IP address configured on your server.

All rules that are listed in the preceding table should be mirrored when they are implemented. This configuration ensures that any traffic coming in to the server will also be allowed to return to the originating server.

As seen in the preceding table, there are a small number of ports and services that have been opened on the WINS server. With this additional level of security, all WINS management and management of the servers will need to be performed through the use of Terminal Services. Also note that Contoso has implemented a MOM server in their environment. Because of the large interaction between the MOM server and the OnePoint client—the client application that reports to the MOM console—all network traffic is allowed between the server and the MOM server.

Scripting Commands

Implementation of the following commands should be executed on the server. These commands will block all network traffic except what is specifically allowed. This set of commands is also included in a batch file that accompanies this guide.

ipsecpol -w REG -p "Packet Filter" -r "Domain Member" 
-f 0+<INSERT DC IP>:: -f 0+<INSERT DC IP>:: 
-f 0+<INSERT DC IP AND REPEAT AS NECESSARY>:: -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring" 
-f 0+<INSERT MOM SERVER IP> -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server" -f 
*+0:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "WINS Resolution Server" 
-f *+0:1512:TCP -f *+0:1512:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "WINS Replication Client" 
-f 0+<INSERT WINS Replication Partner>:42:TCP 
-f 0+<INSERT WINS Replication Partner>:42:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "WINS Replication Server" 
-f <INSERT WINS Replication Partner>+0:42:TCP 
-f <INSERT WINS Replication Partner>+0:42:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP" -f 0+*:*:ICMP -f 
*+0:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic" -f 
*+0 -n BLOCK
ipsecpol -w REG -p "Packet Filter" –x

Potential Impact

Because these settings do not allow network traffic through random high ports, RPC traffic will not be allowed. This configuration can make management of the server difficult. However, with the use of terminal services, a large amount of usability is regained.

The implementation of this relatively small number of IPsec policies should not have a noticeable impact on the performance of the server. However, a large amount of testing should be performed before implementing these filters in your environment to verify functionality and performance required for your organization. Additional rules may need to be added to support other applications in your environment.

Contoso Scenario

Contoso implemented the specified IPsec filters for their WINS servers.

Additional Security Settings—DHCP

Configure Logging

Vulnerability

DHCP clients are often difficult to track down in log entries because the only information that is stored in most event logs are computer names, not IP addresses. The DHCP audit logs can provide one more tool in your forensic arsenal to track down the sources of internal attacks or inadvertent activities.

However, the information in these logs is not by any means foolproof, because both hostnames and media access control (MAC) addresses can be forged or spoofed. In any case, there is greater benefit than cost to collecting this information to help fill the gap between having only an IP address and a record to track down how the IP address was used in a short time.

Because by default the DHCP audit logging function is not enabled, this information would not be collected.

Countermeasure

Configure the value for DHCP audit logging to Enable.

Potential Impact

This information could be misused or altered by those with privileged access to the log files. The permissions on these files also should be limited.

Although the DHCP audit logs could in theory fill the disk on which they are stored, the default configuration of DHCP audit log disk space checking is sufficient to prevent this from occurring. Check the settings to ensure there is sufficient free disc space for your other applications. For more information about the DhcpLogMinSpaceOnDisk setting, see DhcpLogMinSpaceOnDisk at https://technet2.microsoft.com/WindowsServer/en/Library/
f7802dce-3ff9-406a-b3e6-c0c6b3ed49411033.mspx.

Contoso Scenario

In the Contoso scenario, this information was not considered harmful and of potential use to provide an additional avenue for auditing user activity.

To enable DHCP audit logging

Start the DHCP Manager snap-in.
Right-click the name of the server, click Properties, and then click the General tab.
Select the Enable Audit Log check box to enable it.
Restart the DHCP Server.

Protect Against Denial of Service Attacks on DHCP

Vulnerability

DHCP servers are a central resource, and DoS attacks against DHCP servers can have widespread consequences. If a DHCP server is attacked and is no longer able to service DHCP requests, DHCP clients would eventually not be able to acquire leases. Those clients would lose their existing IP lease and would lose the ability to access network resources.

It would not be very difficult to write an attack tool script to request all available addresses on a DHCP server. Such a script would exhaust the pool of available IP addresses for subsequent, legitimate requests from DHCP clients. It is also possible for a malicious user to configure all DHCP IP addresses on the network adapter of a computer they administer, thus causing the DHCP server to detect IP address conflicts for all addresses in its scope and to refuse to allocate DHCP leases.

In addition, as with all other network services, a DoS attack (for example, CPU exhaustion or filling the request buffer of the DHCP listener) that exhausts the DHCP server's ability to respond to legitimate traffic, could make it impossible for clients to requests leases and renewals. For recommendations on mitigating the risk of network-based DoS attacks, see the "Security Considerations for Network Attacks" section in Chapter 6, "Hardening the Base Windows 2000 Server."

Fortunately, the DHCP client behaviors are such that periodic outages can often be tolerated, except during client startup when it does not have a valid lease. If the DHCP server does not respond when one of the early DHCP renewal messages is sent, the client will retry at a later time, and will repeat trying until it finally acquires a renewal or fresh lease.

Generally, DoS attacks against a DHCP server are only possible from internal attackers, who may be less likely to attack infrastructure servers than computers with sensitive data to be stolen.

Countermeasure

Configure DHCP servers in pairs and split allocated IP addresses across the servers according to the best practice 80/20 rule. For more information about the 80/20 rule, see the Deploying Network Services section of the Windows Server 2003 Deployment Guide at https://technet2.microsoft.com/WindowsServer/en/Library/c283b699-6124-4c3a-87ef-865443d7ea4b1033.mspx.

Alternatively, you could increase the lease time on DHCP scopes so that if an outage were to occur, more clients would be able to tolerate the outage for longer periods of time. However, this configuration would not protect against server outages if a client required an immediate DHCP lease, such as when a new computer is restarted on the LAN.

You could also monitor for performance and availability of the Windows 2000 server and the DHCP service.

You could configure DHCP clustering, which would help alleviate DoS attacks if one of the individual hosts themselves were attacked, and not the clustered DHCP resource.

Finally, you could implement multiple, separate DHCP servers that each allocate IP addresses to separate subnets in your environment. Each DHCP server would allocate all IP addresses for any one subnet. This approach fully isolates each subnet from problems another subnet's DHCP server may have, but does not provide the fault tolerance necessary in most enterprise environments.

Potential Impact

The potential impact is the added overhead of managing additional servers. In addition, if you were not careful in configuring the 80/20 allocations of IP addresses among multiple DHCP servers, incorrectly configured servers could allocate the same IP address to more than one client. The increased DHCP lease time could also lead to periods when the DHCP address space has been exhausted, which is simply another type of DoS attack.

Contoso Scenario

In the Contoso scenario, each site has two DHCP servers configured according to the 80/20 rule to allocate IP addresses. The default lease time of eight days was considered sufficient to provide for even long outages of the DHCP service.

To change the DHCP lease time

Start the DHCP Manager snap-in.
Right-click the scope whose lease duration you want to change and click Properties.
Under the Lease duration for DHCP clients dialog box on the General tab, change the Limited to values to the time span you want to implement.

You may also select the Unlimited lease duration option, but this setting is only advisable in limited circumstances, and not generally for enterprise DHCP deployments.

Blocking Ports with IPsec Filters

Vulnerability

Countermeasure

Configure IPsec blocking filters that allow only the traffic specified in the following table. This countermeasure will reduce the number of unexpected and unauthorized applications that could successfully receive requests or that could be attacked.

Before implementing IPsec filters, you should gain a full understanding of the capabilities and limitations of this technology. IPsec filters are very powerful, but can greatly affect the management and usability of computers. For more information, see Chapter 11, "Additional Countermeasures" of the Threats and Countermeasures guide at https://go.microsoft.com/fwlink/?LinkId=15159.

DHCP Server IPsec Network Traffic Map

Table 7.8 DHCP Server IPsec Network Traffic Map

Service	Protocol	Source port	Destination port	Source address	Destination address	Action
Domain Member	ANY	ANY	ANY	0	ALL DOMAIN CONTROL-LERS	ALLOW
Monitoring Client	ANY	ANY	ANY	0	MOM Server	ALLOW
Terminal Services	TCP	ANY	3389	ANY	0	ALLOW
DHCP Server	UDP	68	67	ANY	0	ALLOW
ICMP	ICMP	ANY	ANY	0	ANY	ALLOW
All Inbound Traffic	ANY	ANY	ANY	ANY	0	BLOCK

All of the rules listed in the preceding table should be mirrored when they are implemented. This configuration ensures that any traffic coming in to the server will also be allowed to return to the originating server.

As seen in the preceding table, there are a small number of ports and services that have been opened on the DHCP server. Because of the increased level of security, management of the servers will need to be performed through Terminal Services.

Also note that Contoso has implemented a MOM server in their environment. Because of the large interaction between the MOM server and the OnePoint client—the client application that reports to the MOM console—all network traffic is allowed between the server and the MOM server.

Scripting Commands

Implementation of the following commands should be executed on the server. These commands will block all network traffic except what is specifically allowed.

This set of commands is also included in a batch file that accompanies this guide.

ipsecpol -w REG -p "Packet Filter" -r "Domain Member" 
-f 0+<INSERT DC IP>:: -f 0+<INSERT DC IP>:: 
-f 0+<INSERT DC IP AND REPEAT AS NECESSARY>:: -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring" 
-f 0+<INSERT MOM SERVER IP> -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server" -f 
*+0:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "DHCP Server" -f 
*:68:UDP+0:67:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP" -f 0+*:*:ICMP -f 
*+0:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic" -f 
*+0 -n BLOCK
ipsecpol -w REG -p "Packet Filter" –x

Potential Impact

Because these settings do not allow network traffic through random high ports, RPC traffic will not be allowed. This configuration can make management of the server difficult. Administrators should be able to connect with a Terminal Services client to perform remote administration.

The implementation of this relatively small number of IPsec policies should not have a noticeable impact on the performance of the server. However, a large amount of testing should be performed before implementing these filters in your environment to verify functionality and performance required for your organization. Additional rules may need to be added to support other applications in your environment.

Contoso Scenario

Contoso implemented the specified IPsec filters for their DHCP servers.

File and Print Server Role

The servers in the file and print server role can be difficult to harden, because the most essential services on these servers are the ones that require the Windows NetBIOS-related protocols. The protocols for SMB and CIFS can provide rich information to unauthenticated users and are often recommended to be disabled in high-security Windows environments.

File and Print Incremental Group Policy

The File and Print Incremental Group Policy does the following two things:

Enables the Spooler service, which is used for printing.
Disables the security options setting Digitally sign server communication (always). If this setting is not disabled, clients will be able to print, but will not be able to view the print queue. When attempting to view the print queue they will receive the message: "Unable to connect. Access denied."

Note For print clients to support viewing print queues on a Windows 2000 file and print server, the client computers should have the configuration for Digitally sign client communication (always) set to Disabled.

System Services

Any service or application is a potential point of attack, and therefore any unneeded services or executable files should be disabled or removed. In the MSBP, these optional services as well as all other unnecessary services are disabled. However, the File and Print server role relies on one of these disabled services: the Print Spooler. Therefore, the startup mode for it is configured to Automatic in the File and Print Policy.

Note The Spooler service is also used on any client computer that sends, or initiates a print job to a print server. Because the MSBP disables the Spooler service, you will not be able to issue print jobs from any server but the File and Print servers. If you want to print from other servers, you must enable the Spooler service in its corresponding Group Policy.

There are additional Services that are often enabled on Windows 2000 File and Print servers, but they are not essential. These services are disabled in the Contoso scenario, but the use and security of these services is frequently the subject of debate. For this reason, recommendations on this server role in this guide may not be applicable to your environment. Adjust these File and Print Group Policy recommendations as needed to meet the requirements of your organization.

Distributed File System

The Distributed File System (DFS) is a service that integrates disparate file shares into a single logical namespace. DFS manages logical volumes distributed across a local or wide area network (WAN) and is required for the Active Directory SYSVOL share.

This namespace is a logical representation of the network storage resources that are available to users on the network. If the DFS service is turned off, users will be unable to access network data through the logical namespace. To access the data, users will need to know the names of all the servers and shares in the namespace, and access each of these targets independently.

DFS is not supported in the File and Print role in the Contoso scenario. For this reason, DFS service is disabled in the File and Print Group Policy. If your organization uses DFS on file servers to simplify accessing distributed resources, you will need to either modify the File and Print Server Group Policy or create a new GPO to enable this service, and then apply it to the file servers that need DFS enabled.

NT File Replication Service

The NT File Replication Service (NTFRS) maintains synchronization of file directory contents among multiple servers. NTFRS is the automatic file replication service in Windows 2000. The service maintains copies of files on multiple servers simultaneously and also replicates the Windows 2000 system volume SYSVOL on all domain controllers.

NTFRS can be configured to replicate files among alternate targets associated with the fault-tolerant DFS. If this service is disabled, file replication will not occur and server data will not be synchronized.

NTFRS is not supported in the File and Print role in the Contoso scenario. For this reason, the NTFRS service is disabled in the File and Print Policy. If your organization uses NTFRS on file servers to replicate data across multiple servers, either modify the File and Print Server Group Policy or create a new GPO to enable this service, and then apply it to the file servers that need it.

Additional Security Settings

Vulnerability

By default, members of the local Administrators, Power Users, and Server Operators groups are able to create new file shares and printer shares. New file shares have a default share permission of Full Control for the special built-in group called Everyone. This configuration creates a potential vulnerability because forgetful IT team members may accidentally create new shares allowing anyone who can connect to the folder share to gain full control access to objects within it.

Note The built-in Power Users group is not available on domain controllers, but a group with similar privileges is present on domain controllers called the Server Operators group.

Countermeasure

Train all administrators who are able to create new file shares to manually configure the share permissions so that only users who need access to the shares can use them, and then ensure that these permissions are configured as restrictively as possible.

Potential Impact

Users who create and manage shared folders will need to manually configure permissions on those shares.

Contoso Scenario

All files shares created on the File and Print Server were configured to allow Authenticated Users: Modify permissions, and the shared folders and files were appropriately secured as well using NTFS permissions.

To manually change share permissions for new shares

Start the Computer Management MMC snap-in, and browse to the Shared Folders, then the Shares node.
Right-click Shares, choose New File Share, and click the Browse button to find the Folder to Share (for example, E:\Users). Give the share a name in the Share name dialog box.
On the Create Shared Folder window, choose the Customize share and folder permission radio button, and click the Custom button.
Click the Remove button to remove the Everyone listing. Click the Add button, type Authenticated Users in the lower text area (where it says << Type names separated by semicolons or choose from list >>) and click the OK button.
Select the Change check box under the Allow column, click OK, and then the Finish button. Choose No when prompted.

Vulnerability

As described earlier, new file shares have a default share permission of Full Control for the special built-in group called Everyone. Therefore, there may be existing shared folders on your network that assign full control to the Everyone group.

Countermeasure

Audit all shared folders in your organization to verify that appropriate permissions are assigned to each one. This audit can be done manually by visiting each file server, or by using commands such as net view or third-party tools to automatically document the permissions on all file shares.

Potential Impact

The process of correcting permissions on shared folders could lead to some legitimate users losing access to those resources. These situations will have to be addressed as they arise, and could especially affect users whose access is made possible through permissions that still allow access to security IDs (SIDs) stored in their SIDHistory. A SID is a value that uniquely identifies each user, group, computer account, and logon session on a network.

When Windows user accounts are migrated from older Windows NT 4.0 domains or Windows 2000 domains that are not part of the current Active Directory forest, often the migration is performed with tools that preserve users' permissions by using the SIDHistory attribute of the new domain user account. The SIDHistory attribute records the former SIDs from the migrated account to preserve access to existing secured resources.

The most common use of SIDHistory is to preserve existing access to file and printer shares without having to update all their ACLs.

The permissions on existing file and printer shares may not have been updated yet to allow access for the current user account or groups, and users may still unknowingly rely upon the permissions that allow the SIDs in the users' SIDHistory attributes.

To administrators with no knowledge of migrated accounts and SIDHistory, the ACLs on preexisting file or printer shares may appear to have unnecessary entries, or entries that do not resolve to existing users and groups in the domain. However, if these entries are deleted, users reliant on SIDHistory to provide access will lose access, and they can potentially lose all access to these file and printer shares.

If your environment includes file and print servers that were in production before a user account migration from old Windows domains, you should carefully document the permissions that currently exist on the file and printer shares before making any changes to the ACLs. Be prepared to create new ACLs that will provide the same access, or to restore the file and print server from backup media to preserve the deleted ACL entries.

Contoso Scenario

Because the Contoso environment does not include any preexisting file servers, there was no need to update existing file share permissions. All new file shares were manually configured to provide only the minimum necessary permissions for users.

Blocking Ports with IPsec Filters

Vulnerability

Countermeasure

File and Print Server IPsec Network Traffic Map

Table 7.9 File and Print Server IPsec Network Traffic Map

Service	Protocol	Source port	Destination port	Source address	Destination address	Action
Domain Member	ANY	ANY	ANY	0	ALL DOMAIN CONTROL-LERS	ALLOW
CIFS Server	TCP	ANY	445	ANY	0	ALLOW
	UDP	ANY	445	ANY	0	ALLOW
NetBIOS Server	TCP	ANY	137	ANY	0	ALLOW
	UDP	ANY	137	ANY	0	ALLOW
	TCP	ANY	139	ANY	0	ALLOW
	UDP	ANY	138	ANY	0	ALLOW
Monitoring Client	ANY	ANY	ANY	0	MOM Server	ALLOW
Terminal Services	TCP	ANY	3389	ANY	0	ALLOW
ICMP	ICMP	ANY	ANY	0	ANY	ALLOW
All Inbound Traffic	ANY	ANY	ANY	ANY	0	BLOCK

As seen in the preceding table, there are a small number of ports and services that have been opened on the File and Print server. Because of this additional level of security, all management of the servers will be performed through the use of Terminal Services.

Scripting Commands

The following is a sample of the complete set of commands. This set of commands is also included in a batch file that accompanies this guide.

ipsecpol -w REG -p "Packet Filter" -r "Domain Member" -f 
0+<INSERT DC IP>:: -f 0+<INSERT DC IP>:: 
-f 0+<INSERT DC IP AND REPEAT AS NECESSARY>:: -n PASS
ipsecpol -w REG -p "Packet Filter" -r "CIFS Server" 
-f *+0:445:TCP -f *+0:445:UDP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "NetBIOS Server" 
-f *+0:137:TCP -f *+0:137:UDP -f *+0:139:TCP -f *+0:138:UDP -n 
PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring" 
-f 0+<INSERT MOM SERVER IP> -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server" 
-f *+0:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP" 
-f 0+*:*:ICMP -f *+0:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic" 
-f *+0 -n BLOCK
ipsecpol -w REG -p "Packet Filter" –x

Potential Impact

As mentioned before, the implementation of this relatively small number of IPsec policies should not have a noticeable impact in the performance of the server. However, thorough testing should be performed before implementing these filters in your environment to verify necessary functionality and performance. Additional rules may need to be added to support other applications in your environment.

Contoso Scenario

Contoso implemented the specified IPsec filters for their File and Print servers.

IIS Server Role

Recent reports have suggested that one out of every nine IIS servers is susceptible to some form of attack. Internet Information Services (IIS) 5.0 is installed by default on all Windows 2000 servers. IIS 5.0 enables a variety of application features out of the box, and is an example of an application service that achieved good usability at the expense of sufficient security safeguards. This vulnerability was exploited by the Nimda worm.

To increase security it is likely that some level of IIS usability could be lost. IIS 5.0 is extremely flexible, meaning it contains a large number of features enabled as part of the default installation. As with any server, every service and feature that is enabled increases the attack surface of that asset.

However, IIS can be significantly locked down and still provide the vast majority of its essential functionality. The once time-consuming task of locking down IIS servers has become much easier with the use of tools such as IISLockDown and URLScan.

The IIS Lockdown Tool is a Microsoft utility that turns off features you are not using in IIS-dependent Microsoft products, reducing the attack surface available to attackers. URLScan is an Internet Server Application Programming Interface (ISAPI) filter that analyzes incoming HTTP packets and can reject Web requests based on rules you set.

These tools can be combined with a well architected server and the use of IPsec filters on the client-facing network interface of the IIS Server to produce an extremely secure solution.

Patching the Server

As the first step in hardening IIS servers in your environment, it is imperative to apply all service packs and security hotfixes. These procedures are described in more detail in Chapter 8, "Patch Management."

By patching the server immediately, even prior to its introduction to the network, the risk of the server being infected by a worm or other exploit such as Code Red or Nimda is greatly reduced. Therefore, the server should be completely patched and hardened as much as possible before being introduced on the network.

IIS Lockdown

After applying the necessary patches, the second step in hardening an IIS server is to configure the server using recommended automated tools such as IISLockdown and URLScan.

Overview

IIS servers can provide a great deal of functionality. However, to secure IIS servers the functionality of these servers should be limited to only what is required. The easiest way to accomplish this limitation is with the IIS Lockdown Tool.

The IIS Lockdown Tool is a configurable utility that asks you to specify the application role played by your IIS server (for example, Dynamic Web Server or Exchange Server). It will then remove any functionality that is not required for the particular Web server role. You should thoroughly test any changes before implementing them in a production environment.

Note The IIS Lockdown Tool is available as part of the Security Toolkit and on the Microsoft Security Web site. Additional details can be found in the "More Information" section at the end of this chapter.

The IIS Lockdown Tool can perform many tasks to help secure Web servers, including:

Disabling services and components.
Installing URLScan.
Removing unneeded ISAPI DLL script mappings.
Removing unneeded directories.
Changing file and folder ACLs.

IIS Lockdown can be used to secure many types of IIS server roles. You should select the role that is most appropriate for the type of application being hosted on each IIS server in your environment.

IIS Lockdown Installation

In Contoso's environment, IIS is most typical used as a Dynamic Web Server to support the use of Active Server Pages (ASP). Version 2.1 of the IIS Lockdown Tool (the latest version of this tool at the time this guide was written) was used to secure the servers in the Contoso environment. Older versions may not work as well, and future versions may support new features unavailable in this guide.

To manually secure a Dynamic Web Server with the IIS Lockdown Tool

Start iislockd.exe.
Click Next.
Select I agree, and then click Next.
Select Dynamic Web server (ASP enabled), and then click Next.
Ensure Install URLScan filter on the server is selected and click Next.
Click Next.
If the Digital Signature Not Found dialog box appears, click Yes.
Click Next.
Click Finish.

Note The IIS Lockdown tool can also be run in unattended mode to automate the deployment of the settings you choose. See the RunLockdUnattended.doc help file that is included in the iislockd.exe self-extracting zip file for more details.

This procedure configures the IIS Server as a Dynamic Web Server. The configuration process results in the following changes:

The FTP Service is disabled.
The E-mail (SMTP) Service is disabled.
The Network News Transfer Protocol (NNTP) Service is disabled.
The Index Server Web Interface (.idq, .htw, .ida) script map is disabled.
The Server side includes (.shtml, .shtm, .stm) script map is disabled.
The Internet Data Connector (.idc) script map is disabled.
The .HTR scripting (.htr) script map is disabled.
The Internet printing (.printer) script map is disabled.
The printer virtual directory is removed.
The IIS Samples virtual directory is removed.
The Scripts virtual directory is removed.
The MSADC virtual directory is removed.
The IISAdmin virtual directory is removed.
The IISAdmin Web site is removed.
The IISHelp virtual directory is removed.
File permissions are configured to prevent anonymous IIS users from running system utilities.
File permissions are configured to prevent anonymous IIS users from writing to content directories.
Web Distributed Authoring and Versioning (WebDAV) is disabled.
The URLScan filter is installed on the server.

Note If a different IIS Lockdown security template is required, or if it is necessary to customize the chosen settings, additional services may need to be re-enabled that are disabled by the MSBP. These services may include SMTP, NNTP, or FTP.
However, simply running the IIS Lockdown Tool and selecting one of these services will not permanently re-enable it, because the IIS Group Policy will disable those services upon the next Group Policy refresh. The services must be manually enabled in the IIS Group Policy that you have deployed in the Web OU.

Services

Vulnerability

Any running service or application is a potential point of attack—any services and components that are not running cannot effectively be attacked. Therefore, to create more secure computers, a best practice is to turn off unused features to reduce the attack surface of the IIS servers in your environment.

Countermeasure

Use the IISLockdown Tool to disable the SMTP and FTP services that are installed by default. NNTP also should be disabled if it was installed with IIS.

Alternatively, the IISLockdown Tool can be used to uninstall these services.

Potential Impact

The UninstallServices setting in the iislockd.ini file must be carefully considered. This setting is configured to FALSE for all preconfigured templates that come with version 2.1 of the IIS Lockdown Tool. If the iislockd.ini file is modified to enable this setting to TRUE, those services will no longer be installed on the server on which IIS Lockdown has been applied. To re-enable one of those services on a server, it will have to be manually reinstalled through Add/Remove Programs or the server will need to be rebuilt according to the server deployment methodology.

Contoso Scenario

The IIS Lockdown Tool was used in the Contoso scenario to disable the NNTP, FTP, and SMTP services on the organization's IIS servers, but not to uninstall the services.

To uninstall the NNTP, FTP and SMTP services from IIS Servers using a custom IISLockd.ini file

Open the IISLockd.exe file with a decompression utility such as WinZip, and extract all the files to your hard drive.
Open the iislockd.ini in Notepad.exe.
Find the section corresponding to the role you want to configure (for example, [dynamicweb] for the Dynamic Web Server role), and change the UninstallServices setting under that section to the value TRUE.
Under the [Info] section, configure the UnattendedServerType setting by typing the name that matches the server template you want to use. For example, if you want to apply the dynamicweb template, change UnattendedServerType to equal dynamicweb.
Change the Unattended setting to the value TRUE.
Save the iislockd.ini file.
Run iislockd.exe from a command line, or from within a script.

Disabling Script Mappings

Vulnerability

The IIS-related script mappings are an excellent illustration of the principle that an increase in functionality can cause a decrease in security. Although the script mappings are very powerful and can provide a great deal of value to a Web site, nearly all of the following mappings have been exploited by security threats at some point since the release of Windows 2000:

The .ida and .idq script mappings are ISAPI extensions that provide extended functionality for the Index server. Among other vulnerabilities, an unchecked buffer in the idq.dll file introduced a vulnerability that could allow an attacker to gain complete control of the server. This vulnerability was most famously exploited by the Code Red worm. For more details, see Microsoft Security Bulletin MS01-033, "Unchecked Buffer in Index Server ISAPI Extension Could Enable Web Server Compromise," at www.microsoft.com/technet/security/bulletin/MS01-033.mspx.
The .htw ISAPI filter provides additional functionality to Microsoft Index Server. A vulnerability in the related webhits.dll file created the potential for a user to inadvertently open a hostile link through a browser or HTML-compliant e-mail client, which could cause active content such as Javascript to be executed. For more details, see Microsoft Security Bulletin MS01-025, "Index Server Search Function Contains Unchecked Buffer," at www.microsoft.com/technet/security/bulletin/MS01-025.mspx.
The .shtml mapping is the Smart HTML interpreter, which is part of the Microsoft® FrontPage® Server Extensions used to support server side includes The ssiinc.dll file contained a vulnerability that could be exploited to return attacker-specified content located on the Web server to the browser. For more details, see Microsoft Security Bulletin MS00-060, "Patch Available for 'IIS Cross-Site Scripting' Vulnerabilities," at www.microsoft.com/technet/security/Bulletin/MS00-060.mspx.
The .idc mapping can be exploited using a cross site scripting vulnerability to return the entire URL in an error page, allowing attackers to run arbitrary script code at the server. This issue was resolved in Windows 2000 SP3.
The .htr ISAPI extension was a first generation scripting technology available for ASP developers but never widely adopted. A vulnerability in the ism.dll file could be exploited to reveal the source code of ASP files. For more details, see Microsoft Security Bulletin MS00-031, "Patch Available for 'Undelimited .HTR Request' and 'File Fragment Reading via .HTR' Vulnerabilities" at www.microsoft.com/technet/security/Bulletin/MS00-031.mspx, and MS01-014, "Malformed URL can Cause Service Failure in IIS 5.0 and Exchange 2000" at www.microsoft.com/technet/security/Bulletin/MS01-014.mspx.
The .printer ISAPI extension was created for the use of printing over Internet protocols. A vulnerability in msw3prt.dll could be exploited to provide an attacker with a remote console on the target IIS computer. For more details, see Security Bulletin MS01-023, "Unchecked Buffer in ISAPI Extension Could Enable Compromise of IIS 5.0 Server," at www.microsoft.com/technet/security/Bulletin/MS01-023.mspx.

Countermeasure

All unnecessary mappings and ISAPI filters should be removed from the computer.

Unneeded script mappings should be redirected to the 404.dll file. The 404.dll file is an ISAPI filter that responds with a simple 404 error page to requests that are intercepted by one of these unused script mappings.

Note Mapping an unused extension to 404.dll is better than just deleting the mapping. With a deleted mapping, if a file is mistakenly left on the server (or put there by mistake) it will be displayed in cleartext when requested, or could be inadvertently remapped.

The related files and folders of each script mapping should also be deleted from the file system. These deletions are not done with the IISLockdown Tool, but are detailed in the "Virtual Directory and Sample Applications Removal" section later in this chapter.

Potential Impact

The potential impact of remapping these script mappings would be to disable whatever functionality those script mappings make available. If Web-based applications require the script mappings to function, then these applications could be inadvertently disabled.

Contoso Scenario

The IIS Lockdown Tool was used in the Contoso scenario to remove all unnecessary ISAPI filters from the organization's IIS servers. Only .asp files and static content remain enabled on the IIS servers. Each script mapping was automatically mapped to the 404.dll filter.

Performing script mappings to 404.dll can also be done manually for either new extensions or in case the IIS Lockdown Tool is not used.

To manually map extensions to 404.dll

Start the Internet Services Manager MMC snap-in.
Right-click your server (a.k.a. the Master site) in the left hand window and click Properties.
Ensure that the WWWService is selected in the Master Properties drop-down list box, and click the adjacent Edit button.
Click the Home Directory tab.
Click Configuration.
Select one of the extensions from the list of mappings and then click Edit.
Click Browse and navigate to c:\winnt\system32\inetsrv\404.dll.
Click Open and then OK.
Repeat steps 6, 7 and 8 for all of the remaining file extensions.

Internet Printing

Windows 2000 Server provides the ability to print from the Internet. Printers are attached to the server by means of a Web page and administration of these printers is also accessed from a Web page.

Vulnerability

The Internet printing feature increases the attack surface of an IIS server. In addition, if Internet printing is disabled from the Internet Service Manager, and an administrator restarts the server or logs out, the GPO that enables Internet printing will restart this functionality.

It is important to ensure that Internet printing is disabled through a GPO that controls the server before deploying the server. The default Group Policy neither enables nor disables Internet printing.

Countermeasure

Disable Internet printing through Group Policy using the procedure for the Contoso scenario.

Alternatively, Internet printing can also be disabled through the Internet Services Manager. If there is a conflict between the policy settings and those in the Internet Services Manager, the policy settings take precedence.

If Internet printing is removed through the Internet Services Manager, verify that it will not be re-enabled by either the local or domain Group Policies. See the Contoso scenario procedure for the details on how to verify this configuration.

Potential Impact

Any clients printing to printers shared from that IIS server through the Internet Printing Protocol (IPP) would lose the ability to use IPP to print from Web-shared printers.

Contoso Scenario

The IIS Lockdown Tool was used in Contoso's environment to disable Internet printing. No printers are shared from the IIS servers.

To disable Internet Printing using Group Policy

Start Active Directory Users and Computers as a user with permission to edit the GPO in which you will disable IPP.
Right-click the OU where the GPO is stored and choose Properties.
Click the Group Policy tab, click the GPO to be edited, and then click the Edit button.
Double-click the Computer Configuration folder, then Administrative Templates, and Printers.
Double-click the Web-based Printing setting, select the Disabled radio button and click OK.

Virtual Directory and Sample Applications Removal

Vulnerability

IIS 5.0 included a number of sample applications that are not installed by default, but that are available as part of the full installation of IIS. In addition, several virtual directories were included in IIS 5.0 that contain samples IIS applications.

The sample applications that were included in the default installation of IIS 5.0 were not developed to be hosted on high-security production IIS servers. It is possible that a hacker could exploit an inherent weakness in a sample application or in its configuration to attack a Web site. By removing the sample applications, the attack surface of the Web server can be decreased.

In addition, the virtual directories themselves are not configured for high security. For example, the default \Scripts directory provides anyone with the ability to run programs in this directory and potentially others.

Countermeasure

The virtual directories should be removed from IIS either manually or with the IIS Lockdown Tool. The underlying files and folders of the virtual directories also should be manually deleted.

To delete a sample application

Use the IIS MMC snap-in to delete the appropriate virtual directory.
Use Windows Explorer to physically delete the underlying folder.

To delete the remote IIS administration application

Use the IIS MMC snap-in to stop the administration Web site.
Use the snap-in to delete the virtual directory.
Use Windows Explorer to physically delete the underlying folder.

Potential Impact

There should be no impact, unless for some unlikely reason you have employed one of the sample applications in a production environment.

Contoso Scenario

The IIS Lockdown tool was used in the Contoso scenario to remove all sample virtual directories.

The sample applications and other unnecessary files were deleted manually, including the following directories:

C:\inetpub\scripts
C:\inetpub\iissamples
C:\Program Files\Common files\system\msadc
C:\winnt\help\iishelp
C:\Winnt\system32\inetsrv\iisadmin

File Permissions Lockdown of IIS Users

Vulnerability

After gaining unauthorized access to a computer, it may be possible for a hacker to use system commands to perform actions or view data on a remote Web server. Using these same system commands, an attacker could upload and execute additional applications on the server.

Countermeasure

Perform the following two countermeasures:

Add an Access Control Entry (ACE) to all executable files in C:\WINNT and all subfolders (that is, add the ACE to the existing ACL). The ACE should deny execute privileges to all anonymous user accounts that have been configured on the computer (including IUSR_computername), as well as all user accounts on the server that are used for running Web applications (including IWAM_computername).
Add an ACE to the existing ACL on all files and folders referenced by virtual directories, and include the files and folders that are located on remote computers. The ACE should deny write privileges to all anonymous user accounts that have been configured on the computer (including IUSR_computername), as well as all user accounts on the server that are used for running Web applications (including IWAM_computername).

Both of these actions can be performed automatically with the IIS Lockdown Tool.

Potential Impact

No Microsoft Web applications would experience any impact from the specified countermeasures, but it is possible that a custom application relies on the permissions that have been denied. All custom applications should be tested in a lab environment after these changes before making the same changes on production IIS servers.

Contoso Scenario

The IIS Lockdown Tool was used in the Contoso scenario to configure the necessary Deny ACE settings on the specified files and directories.

Disable WebDAV

Vulnerability

A vulnerability of WebDAV is that it could be exploited to run a script that would execute in the current security context of the WebDAV thread. This vulnerability means that an attacker could browse inside the intranet of your organization and potentially access restricted information that is only available to the WebDAV service account. For more details, see Microsoft Security Bulletin MS01-022, "WebDAV Service Provider Can Allow Scripts to Levy Requests as User," at www.microsoft.com/technet/security/Bulletin/MS01-022.mspx.

Countermeasure

Disable this WebDAV feature. Configure an ACE on the DLL that implements WebDAV functionality (Httpext.Dll) to prevent the DLL from being loaded into the IIS process. The IIS Lockdown Tool can perform this task automatically.

Certain applications such as Exchange 2000 and Microsoft® SharePoint™ Portal Server 2001 require WebDAV for functionality within the product. In these cases it is best to apply the latest service pack to ensure that the WebDAV functionality is fully patched.

Potential Impact

Any applications reliant on WebDAV would be disabled by this action. Test all Web applications that you believe may contain WebDAV functionality in a lab environment after making these changes and before making the same changes on the production IIS servers in your environment.

Contoso Scenario

The IIS Lockdown Tool was used in the Contoso scenario to remove the WebDAV functionality from all servers, because there were no WebDAV applications deployed.

URLScan

URLScan is an ISAPI filter that is either installed when you run the IIS Lockdown Tool or is installed separately by extracting the files from the IIS Lockdown Tool. URLScan allows Web site administrators to restrict the kind of HTTP requests that the server will process. By blocking specific HTTP requests, the URLScan filter prevents potentially harmful requests from reaching the server and causing damage.

Overview

URLScan blocks many types of unusual or potentially malicious HTTP requests, especially those that contain characters that have been used to exploit vulnerabilities in the past, such as "..", which is used for directory traversal attacks. These requests will be logged in the %systemroot%\system32\inetsrv\urlscan directory.

Even if a legitimate Web application URL includes any of these characters in the path, URLScan will reject the request and a 404 Not Found error response will be returned to the client. If these characters must be allowed to support your Web application, configure the AllowDotInPath parameter to the value 1 in the urlscan.ini configuration file (located in %systemroot%\system32\inetsrv\urlscan\ folder). It is important to realize that altering the default character set allowed by URLScan may reduce the security of the computer.

URLScan Configuration

The majority of the configuration for URLScan is performed through manipulation of the URLScan.ini file that is located in the %systemroot%\system32\inetsrv\urlscan directory. This file contains several sections of parameters that are listed in the following subsections.

Options

The "Options" section of the urlscan.ini file contains 16 settings that URLScan uses. Some of these settings refer to configurations for subsettings in the urlscan.ini file. These settings are:

UseAllowVerbs
UseAllowExtensions
NormalizeUrlBeforeScan
VerifyNormalization
AllowHighBitCharacters
AllowDotInPath
RemoveServerHeader
AlternateServerName
EnableLogging
PerProcessLogging
PerDayLogging
LogLongUrls
LoggingDirectory
AllowLateScanning
RejectResponseUrl
UseFastPathReject.

Most of these settings are either configured to 1 (true) or 0 (false). There are a few that require additional configuration, which is detailed in the following subsections. For more information, see Microsoft Knowledge Base article 326444, "How to configure the URLScan Tool," at https://support.microsoft.com/default.aspx?scid=326444.

Allow Verbs and Deny Verbs

Verbs are a critical component of HTTP requests. GET and HEAD are the most common verbs used by Web browsers for simple browsing. For example, a Web browser will use a GET command to retrieve information from the specified URL.

Browsers can use other verbs, such as PUT, POST, and REPLY to modify Web site content. For example, FrontPage Server Extensions use the POST and OPTIONS verbs to publish Web content.

The UseAllowVerbs setting in the "Options" section determines if the "AllowVerbs" section of the .ini file will be processed. If the value for UseAllowVerbs is configured to 1, URLScan will only examine the "AllowVerbs" section and ignore the "DenyVerbs" portion of the .ini file.

If the value for UseAllowVerbs is configured to 0, URLScan looks at the "DenyVerbs" section and ignores any entry in "AllowVerbs." IIS is most secure when all HTTP verbs are denied and only specific exceptions are listed, which is the default setting for URLScan (UseAllowVerbs = 1).

This feature is useful to restrict the activities you want to allow users to perform on your Web site.

Allow Extensions and Deny Extensions

The "AllowExtensions" and "DenyExtensions" portions of the URLScan.ini file work like the "AllowVerbs" and "DenyVerbs" sections. However, these areas of the urlscan.ini file control the specific file extensions that incoming requests are permitted to access.

This setting allows administrators to enable access to common Web file types but to deny users the ability to run any executable or script files.

The most secure setting is to configure UseAllowExtensions to 1 and list the permitted extensions in the "AllowExtensions" section. This configuration will block all other extensions. The default setting is UseAllowExtensions = 0, which only denies specified extensions.

Deny Headers

The "DenyHeaders" portion of the file lets you specify which client request headers URLScan will permit or deny. For example, this section could be used to deny the Translate: header, which enables a specific vulnerability to be exploited in a version of IIS 5.0 that has not been patched.

URLScan Implementation

Vulnerability

URLScan addresses a list of vulnerabilities that is too large to discuss in detail in this section. However, one of the most common vulnerabilities that it addresses is IIS file system traversal. In the Contoso scenario, this vulnerability was identified as one of the most significant risks in their environment.

File System traversal can allow an attacker to view not only the file system layout on an IIS server, but also to potentially view data within the files or gain unauthorized access to the server. This capability could even lead to an attacker gaining the ability to execute commands remotely on the computer.

Countermeasure

The primary countermeasure for this vulnerability is to move the directories that contain the virtual server roots to a drive other than the system drive. There is currently no known way for a hacker to traverse across system partitions to execute commands. By moving the Web application data files to a drive where no system command executables exist, the attacker would be restricted from performing such actions.

Alternatively, URLScan can be implemented to restrict the special characters that will be allowed in requested URLs. URLScan has the ability to specify the normalization of the URL before it is processed. This capability eliminates many of the most common file system traversal exploits.

Potential Impact

There is no known impact to Microsoft applications by installing their data files to nonsystem drives. However, custom applications may encounter unexpected problems if their files are installed in nondefault locations. Most applications require some additional reconfiguration if their files are moved after installation as well.

All applications should be thoroughly tested in a lab environment after making these changes before making the same changes on production IIS servers.

Contoso Scenario

In the Contoso scenario, the inetpub directories and all virtual directories were installed on disk partitions other than the system partition.

Contoso also implemented URLScan to limit the URLs and executables that were allowed to be executed on the computer.

Incremental IIS Group Policy

The baseline security policy discussed in Chapter 6, "Hardening the Base Windows 2000 Server," ensures that the servers are significantly more secure than after a default installation. However, as with the other server roles, additional settings are required to add some functionality to the server role while increasing the security for other aspects of the computer.

System Services

The IIS server role adds Web server functionality to the baseline Windows 2000 server policy. No matter what other services are being hosted on an IIS Server, the following two services must be enabled to support any Web server functionality. The IISAdmin service is necessary not just to administer IIS Web sites, but also because this service actually is the initial contact point for all Web-related traffic on an IIS server. Thus disabling this service would disable all Web sites, FTP, SMTP, and NNTP in your environment.

These services have been enabled in the Incremental IIS Policy.

Table 7.10 Incremental IIS Policy Service Settings

Service setting	Startup type	Policy justification
IISAdmin	Automatic	Administration of the Web Server
W3SVC	Automatic	Provides Web Server functionality

Manual Security Configuration

In addition to the Incremental IIS Policy, there are some remediation tasks that must be implemented manually. These tasks include the following:

Relocating the Web content directories.
Relocating and securing log files.
Hardening Metabase permissions.
Disabling content location in HTTP response.
Disabling detailed ASP error messages.
Removing FrontPage 2000 server extensions.
Deleting additional virtual servers.
Configuring IPsec filters.

Relocating the Web Content Directories

Vulnerability

IIS in its default installation has historically been vulnerable to directory traversals. A directory traversal occurs when an attacker escapes the Web root folder and requests or uploads files outside of the Web folders. When IIS applications are vulnerable to directory traversal, the default IIS installation allows attackers to access folders and files in the system partition, including many useful system commands and writeable folders.

There is no method using known HTTP syntax to request files across system partitions.

Countermeasure

To prevent directory traversal attacks from succeeding, relocate the \inetpub directory and all virtual directories to a drive partition other than the system partition.

This step will ensure that an attacker is not able to access even basic system commands such as cmd.exe if the attacker is exploiting an unforeseen canonicalization issue, and could not write to any writeable folders on the system partition, for example, the \inetpub\Scripts folder.

Potential Impact

Minimal. The Web server administrator must ensure that the configuration of IIS is recorded to ensure that the virtual sites are reregistered in the new location.

Contoso Scenario

The Contoso Research Web site was used to provide an example of this countermeasure. The Web site virtual root was C:\Inetpub\wwwroot\research on the Research Web server. To move its files to a nonsystem partition such as E:, the following steps were performed:

To move all content directories of the Research Web site

Start the IIS MMC snap-in.
Right-click the Web site and choose Stop. (This action will unlock any locked files.)
Start a command prompt.
Type the following command:

Note The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.
```
xcopy c:\inetpub\wwwroot\research 
```

d:\wwwroot\research /s /i /o

Go back to IIS MMC snap-in.
Right-click the Web site and choose Properties.
Click the Home Directory tab, then click the Browse button, and choose the new directory to which the files were just copied (for example, d:\wwwroot\research).
Right-click the Web site and choose Start.

Relocating and Securing the Log Files

Vulnerability

Moving and securing the IIS log files can make it much more difficult for attackers to cover their tracks by deleting these logs or individual entries in the logs.

Countermeasure

Relocate the IIS log file directory to a different disk partition from the Web site data files and the system partition. Then, configure stronger NTFS permissions to better secure the log files. Finally, ensure that the recommended logging fields are configured.

Additional log file options:

To facilitate the offline analysis of IIS log files, you could use a script to automate secure removal of log files from each IIS server. Log files should be removed at least every 24 hours and placed on a central server.
An automated script may be created to use the FTP, SMTP, HTTP, or SMB protocols to transfer log files off a computer, but such transfers must be done securely to prevent opening any additional attack opportunities. An IPsec policy can be used to secure ports and allowed hosts for these protocols.
The IIS log files could be stored on CD-R, using modern CD-RW drives with the ability to write multiple times to the same media. This configuration would enable you to log IIS entries to a storage location that cannot be deleted after it has been written. Thus, attackers would not be able to cover their tracks.
The IIS log files could also be stored on a central Universal Naming Convention (UNC) share (for example, the Log file directory could be \\server\share\iislogs rather than %Windir%\system32\logfiles). This configuration would enable you to back up these log files daily from one central repository.
Finally, the IIS log entries could be stored in a database that is compliant with Open Database Connectivity (ODBC). This configuration would allow you to store the IIS log entries in a central location, in which more granular permissions could be enabled (for example, read/write, but not delete). The log entries would already be stored in a format that is ideal for analysis.

Potential Impact

None.

Contoso Scenario

The IIS log files on the Contoso Web servers were moved to a nonsystem partition in which secured and extended logging was enabled.

To move the location of the IIS log files to a nonsystem partition

Start the IIS MMC snap-in.
Right-click the Web site and choose Properties.
Click the Properties button in the Enable Logging frame on the Web Site tab.
On the General Properties tab, click the Browse button, and select the drive and folder where you want to store the IIS log files (for example, E:\IISLogs).

Note Ensure you have already created the folder so that you can select it as part of this step.
Click OK, then click OK again.

Note If you already have IIS log files in the original location (%Windir%\System32\logfiles), you must move these files to the new location manually. IIS will not automatically move those files for you.

To set recommended permissions on the IIS log files location (for example, E:\IISLogs)

Open a command prompt.

Type the following command:

cacls e:\iislogs /t /g administrators:F system:F

When prompted, type Y to proceed.

To configure IIS W3C Extended Log File Format auditing

Start the IIS Manager MMC snap-in.
Right-click your server in the left hand window and click Properties.
Ensure that WWWService is selected in the Master Properties drop-down list box, and click the adjacent Edit button.
Select Enable Logging and ensure the Active log format drop-down list box is configured to W3C Extended Log File Format.
Click Properties.
Select the When file size reaches radio button and specify a log file size of 500 MB.
Change the default Log file directory. It is recommended to use a different nonsystem partition from your Web sites.
Click the Extended Properties tab.
In addition to the default fields selected by IIS, also select the Win32 status entry.
Click OK three times to close the properties dialog list boxes.

Note Such auditing does not prevent attacks, but it is a vital aid in identifying intruders, attacks in progress, and for diagnosing attack footprints.

Hardening Metabase Permissions

Vulnerability

Security and other IIS configuration settings are maintained in the IIS metabase file. The default file permissions could allow an attacker to directly edit the metabase file. The NTFS permissions on the IIS metabase file (and the backup metabase file) should be hardened to ensure that attackers cannot modify the IIS configuration in any way. For example, an attacker might attempt to disable authentication for a particular virtual directory by modifying appropriate metabase settings.

Countermeasure

Secure the metabase files so that Full Control permissions are assigned only to Administrators and SYSTEM.

Potential Impact

The only potential impact would be in setting permissions on the metabase files that are too restrictive, which would prevent the computer or administrators from reading and updating the file.

Contoso Scenario

The IIS Incremental Policy was applied to secure the metabase files, in which the appropriate metabase file permissions were stored.

To manually harden metabase NTFS permissions

Open a command prompt.
Type the following command:

Note The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.
```
cacls %systemroot%\system32\inetsrv\
```

metabase.bin /g administrators:F system:F.

When prompted, type Y to proceed.
Type the following command:

Note The line has been split into multiple lines for readability. However, while trying it out on a system you must enter it as one line without breaks.
```
cacls %systemroot%\system32\inetsrv\
```

metaback /g administrators:F system:F.

When prompted, type Y to proceed.

These settings are included in the MSS IIS Role.inf policy template with this guide.

Disabling Content Location in HTTP Response

Vulnerability

When a static .HTML page (that is, a non–ASP page) is retrieved, a content location header is added to the response by IIS. By default, this content header refers to the IP address, and not the fully qualified domain name (FQDN) of the current Web site. This functionality creates a vulnerability in which your internal IP address is unwittingly exposed.

Countermeasure

Hide the content location returned by default in the HTTP Response Headers. You can hide this information by modifying the UseHostName value in the IIS metabase to change the default behavior from exposing IP addresses to sending the FQDN instead.

Potential Impact

None.

Contoso Scenario

In the Contoso scenario, the UseHostName setting was reconfigured to the value True using the Adsutil.vbs script. The syntax for performing this step is:

cscript Adsutil.vbs set w3svc/UseHostName True

The ADSUtil.vbs script can be found in the IIS Adminscripts directory on the IIS server, which is by default C:\Inetpub\Adminscripts.

Note For more information about the manual process required for this step, see Microsoft Knowledge Base article 218180, "Internet Information Server returns IP address in HTTP header (Content-Location)," at https://support.microsoft.com/default.aspx?scid=218180.

Disabling Detailed ASP Error Messages

Vulnerability

By default, IIS sends detailed ASP error messages to the client browser whenever there are internal application errors. Although these error messages are very helpful for application debugging, they can expose internal details of how the application works and provide an attacker with a better understanding of how to attack the application.

Countermeasure

Disable detailed ASP error messages on the production IIS servers in your environment.

Potential Impact

Responding to issues of the Web applications can be more difficult, because the errors that IIS logs in the Application event log are not nearly as informative as the detailed ASP error messages. If you are experiencing reproducible ASP errors, there are two alternatives: set up a mirror development environment to test fixes (and configure detailed ASP error messages in that environment), or enable detailed ASP error messages in production for a temporary period while you resolve the issue.

Contoso Scenario

The production IIS servers in Research and HR were reconfigured to disable detailed ASP error messages using the following adsutil.vbs script parameters.

To disable detailed ASP error messages

Start the Internet Services Manager MMC snap-in.
Right-click your server (a.k.a. the Master site) in the left hand window and click Properties.
Ensure that the WWWService is selected in the Master Properties drop-down list box and then click the adjacent Edit button.
Click the Home Directory tab.
Click Configuration.
Select one of the extensions from the list and then click Edit.
Click Browse and navigate to c:\winnt\system32\inetsrv\404.dll.
Click Open and then OK.
Repeat steps 6, 7 and 8 for all of the remaining file extensions.

Alternatively, this process can be completed by using the Adsutil.vbs script. The syntax for performing this step is:

Note: The line has been split into multiple lines for readability. However,while trying it out on a system you must enter it as one line without breaks.

cscript Adsutil.vbs set w3svc/
AspScriptErrorSentToBrowser False

Removing FrontPage 2000 Server Extensions

Vulnerability

FrontPage 2000 server extensions provide convenient methods to collaborate among teams of Office users and to remotely manipulate Web page content. These remote management capabilities are not generally necessary for Web sites with only one administrator, and the extensions can be used as a point of attack on Web sites by skilled attackers.

Countermeasure

Disable FrontPage 2000 server extensions on all production IIS servers.

Potential Impact

If you have a need to delegate the management of certain virtual Web sites to non-administrator staff, then you may require FrontPage 2000 server extensions. In this case, make absolutely sure that you have deployed all current FrontPage 2000 server extension hotfixes to the IIS Web servers.

Contoso Scenario

In the Contoso environment, the IIS Web sites were all administered by small teams of IT staff. The teams had the ability to use the Internet Services Manager MMC snap-in either at the console, through Terminal Services, or over the network. Thus, FrontPage 2000 server extensions were disabled manually on all production IIS servers.

To manually remove FrontPage 2000 server extensions

Start the Add/Remove Programs applet, then select Add/Remove Windows Components.
Select Internet Information Services (IIS) and click the Details button.
Clear the FrontPage 2000 Server Extensions check box, click OK, and then click Next.
If the Terminal Services Setup dialog box appears, click Next.

– Or –

If the Files Needed dialog box appears, browse to the location from which you originally installed Windows 2000, and click OK.
When prompted, click Finish.
If necessary, delete the FrontPage server directories including:
- C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\40
- C:\Inetpub\wwwroot\_private
- C:\Inetpub\wwwroot\_vti_cnf
- C:\Inetpub\wwwroot\_vti_log
- C:\Inetpub\wwwroot\_vti_pvt
- C:\Inetpub\wwwroot\_vti_script

Deleting Additional Virtual Servers

Vulnerability

The default installation of IIS creates Default FTP Site, Default Web Site, and Administration Web Site. These sites often contain sample code, and are also a potential site from which to launch remote attacks that would require an unsecured instance of these services. When they are not required for your production environment, it is a best practice to remove or disable these default sites.

Countermeasure

Remove the Default FTP Site and the Administration Web Site, and stop the Default Web Site from responding to Web requests.

Potential Impact

You may have installed certain Web applications in one of the default Web sites. Before deleting these sites, ensure that you have migrated these applications to new Web sites on the IIS Web server. If you cannot delete these sites for some reason, you should at least delete the sample code from these Web sites. Use the IISLockdown Tool to delete this code.

Contoso Scenario

In the Contoso environment, the default Web sites were not necessary to support any production functionality—each of the production Web sites were installed into new virtual Web sites. Thus the default sites were deleted or stopped.

To manually remove the Default FTP Site

Start the Internet Services Manager MMC snap-in.
Right-click the Default FTP Site, choose Delete, and click Yes.

To manually remove the Administration Web Site

Start the Internet Services Manager MMC snap-in.
Right-click the Administration Web site, choose Delete, and click Yes.

To manually stop the Default Web Site

Start the Internet Services Manager MMC snap-in.
Right-click the Default Web Site and choose Stop.

Additional IIS Server Setting Considerations

Disable the IUSR Account

As part of the default IIS installation, a Windows account used to represent anonymous Internet users called IUSR_MACHINE is created. MACHINE is the NetBIOS name of your server when IIS is installed. If you do not allow anonymous access to your Web site, then you should disable this Anonymous user account.

Anonymous access can be assigned with any other account, not just this one—this account just happens to be the one created by default when IIS is installed. Conversely, disabling or removing this account does not remove Anonymous access capabilities from IIS, because IIS can be configured to use any other account to provide anonymous access to Web users.

This account is used by the majority of public Web sites where either anonymous access to content is supported, or where the application performs its own authentication by using Forms authentication for example.

Note If your Web server hosts multiple Web applications, you may want to use multiple anonymous accounts (one per application) to secure and audit the operations of each application independently.

Conduct Regular Group Membership Audits

Keep track of user group membership, particularly for privileged groups such as Administrators. The number of members of the Administrators group should be kept to a minimum, and individuals—particularly new recruits—should be fully trained prior to being added to the Administrators group.

More Recommendations for Securing Users and Groups

Create specific groups for specific administrative tasks, and:
- Catalog authorized members of privileged groups such as Server Operators.
Periodically monitor group membership.
Apply strict hiring policies and interviews before adding anyone to the Administrators group.

Disable ASP Parent Paths Setting

This IIS metabase setting prevents the use of ".." (two periods) in script and application calls to functions such as MapPath, which helps guard against potential directory traversal attacks.

To manually disable the parent paths setting

Right-click the root of the Web site that you want to secure, and click Properties.
Click the Home Directory tab.
Click Configuration.
Click the App Options tab.
Clear the Enable parent paths check box.

Note If you are using the Application Center 2002 Admin Site, refer to Microsoft Knowledge Base article 288309, "PRB: Disabling Parent Paths Breaks User Interface," at https://support.microsoft.com/default.aspx?scid=288309.

Blocking Ports with IPsec Filters

Vulnerability

Countermeasure

Incremental IIS Server IPsec Network Traffic Map

Table 7.11 Incremental IIS Server IPsec Network Traffic Map

Service	Protocol	Source port	Destination port	Source address	Destination address	Action
Domain Member	ANY	ANY	ANY	0	ALL DOMAIN CONTROL-LERS	ALLOW
Monitoring Client	ANY	ANY	ANY	0	MOM Server	ALLOW
Terminal Services	TCP	ANY	3389	ANY	0	ALLOW
HTTP Server	TCP	ANY	80	ANY	Host IP	ALLOW
HTTPS Server	TCP	ANY	443	ANY	Host IP	ALLOW
ICMP	ICMP	ANY	ANY	0	ANY	ALLOW
All Inbound Traffic	ANY	ANY	ANY	ANY	0	BLOCK

As seen in the preceding table, there are a small number of ports and services that have been opened on the IIS server. With this additional level of security, all IIS management and management of the servers will need to be performed through the use of Terminal Services.

Scripting Commands

Implementation of the following commands should be executed on the server. These commands will block all network traffic except what is specifically allowed.

This set of commands is also included in a batch file that accompanies this guide.

ipsecpol -w REG -p "Packet Filter" -r "Domain Member" 
-f 0+<INSERT DC IP>:: -f 0+<INSERT DC IP>:: 
-f 0+<INSERT DC IP AND REPEAT AS NECESSARY>:: -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Monitoring" 
-f 0+<INSERT MOM SERVER IP> -n PASS
ipsecpol -w REG -p "Packet Filter" -r "Terminal Server" 
-f *+0:3389:TCP -f -n PASS
ipsecpol -w REG -p "Packet Filter" -r "HTTP Server" 
-f *+0:80:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "HTTPS Server" 
-f *+0:443:TCP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "ICMP" -f 0+*:*:ICMP 
-f *+0:*:ICMP -n PASS
ipsecpol -w REG -p "Packet Filter" -r "All Inbound Traffic" 
-f *+0 -n BLOCK
ipsecpol -w REG -p "Packet Filter" -x

Potential Impact

Because these settings do not allow traffic through random high ports, RPC traffic will not be allowed. This restriction can make management of the server difficult. Administrators should be able to connect with a Terminal Services client to perform remote administration.

These policies still allow any necessary authentication network traffic to work on any Web sites that require basic or NTLM authentication.

The implementation of this relatively small number of IPsec policies should not have a noticeable impact in the performance of the server. However, thorough testing should be performed before implementing these filters in your environment to verify necessary functionality and performance. Additional rules may need to be added to support other applications in your environment.

Contoso Scenario

In the Contoso scenario, the specified IPsec filters were implemented for their IIS servers.

General IIS Best Practices

The following is a set of general best practices for implementing and securing IIS Server:

Do not install IIS on a domain controller.
Do not connect an IIS Server to the network until it has been fully patched and hardened as much as possible, except for Group Policy changes (that must come from the domain controllers on your network).
Use a dedicated computer as a Web server.
Physically protect the Web server computer in a secure computer room.
Do not allow anyone to locally log on to the computer apart from the administrator.
Do not allow administrators to log on to the computer over the network. Adopt a policy of local administration.

Summary

This chapter explains the server hardening procedures applied to each of the separate server roles in the Contoso scenario. Most of these procedures were accomplished by creating a variety of security templates and then importing them into a Group Policy object (GPO) linked to the appropriate organizational unit (OU) for each server role.

Some hardening procedures could not be applied through Group Policy. In these cases, details on configuring the procedures manually have been provided.

Now that you have secured your Windows 2000 servers for deployment, your next step is to determine how to continue to apply security patches in your organization's environment, how to monitor the security of your computers, and how to respond to security incidents that may involve the servers in the future.

More Information

For information about the Microsoft Systems Architecture, see the MSA: Enterprise Data Center page at
www.microsoft.com/resources/documentation/
msa/edc/all/solution/en-us/overview.mspx.

For information about enabling anonymous access to Active Directory, see the "Description of Dcpromo Permissions Choices" article at https://support.microsoft.com/default.aspx?scid=257988.

For information about Windows 2000 DNS, see the "Windows 2000 DNS" white paper at www.microsoft.com/windows2000/techinfo/
howitworks/communications/nameadrmgmt/w2kdns.asp.

For more information about the 80/20 rule, see the Deploying Network Services section of the Windows Server 2003 Deployment Kit at https://technet2.microsoft.com/WindowsServer/en/
Library/119050c9-7c4d-4cbf-8f38-97c45e4d01ef1033.mspx.

For information about the IIS Lockdown Tool, including information about URLScan, see the IIS Lockdown Tool page at www.microsoft.com/technet/security/tools/locktool.mspx.

For information about IIS 5.0, see the "From Blueprint to Fortress: A Guide to Securing IIS 5.0" white paper at www.microsoft.com/technet/prodtechnol/windows2000serv
/technologies/iis/deploy/depovg/securiis.mspx.

For information about managing security for IIS Web services, see the "Manage Security of Your Windows IIS Web Services" page at www.microsoft.com/technet/security/bestprac/mcswebbp.mspx.

For recommendations and best practices for securing a Web server running Windows 2000 and Internet Information Services (IIS) 5, see the "Secure Internet Information Services 5 Checklist" at www.microsoft.com/technet/prodtechnol/
windows2000serv/technologies/iis/tips/iis5chk.mspx.

For information about configuring a baseline level of security on IIS 5 servers, see the IIS 5.0 Baseline Security Checklist at www.microsoft.com/technet/archive/
security/chklist/iis5cl.mspx.

For information about setting appropriate file system permissions for IIS content and log files, see the "HOW TO: Set Secure NTFS Permissions on IIS 5.0 Log Files and Virtual Directories in Windows 2000" article at https://support.microsoft.com/default.aspx?scid=310361.

For information about SYN attack protections, 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 securing and maintaining IIS, see the IIS Answers Web site at www.iisanswers.com.

Securing Windows 2000 Server

Chapter 7: Hardening Specific Server Roles

On This Page

Active Directory Domain Controller Role

Domain Controller Baseline Policy

Audit Policy Settings

Event Log Settings

User Rights Assignment

Log on Locally

Vulnerability

Countermeasure

Potential Impact

Contoso Scenario

Shut Down the System

Vulnerability

Countermeasure

Potential Impact

Contoso Scenario

Security Options

Additional Restrictions for Anonymous Connections

Allow Server Operators to Schedule Tasks (Domain Controllers Only)

Vulnerability

Countermeasure

Potential Impact

Contoso Scenario

LAN Manager Authentication Level

Number of Previous Logons to Cache

Vulnerability

Countermeasure

Potential Impact

Contoso Scenario

Secure Channel: Digitally Encrypt or Sign Secure Channel Data (Always)

System Services

DNS Server

Vulnerability

Countermeasure

Potential Impact

Contoso Scenario

Intersite Messaging

Vulnerability

Countermeasure

Potential Impact

Contoso Scenario

IIS Admin Service

Vulnerability

Countermeasure

Potential Impact

Contoso Scenario

NTLM Security Support Provider

Vulnerability

Countermeasure

Potential Impact

Contoso Scenario

Simple Mail Transport Protocol (SMTP)

Vulnerability

Countermeasure

Potential Impact

Contoso Scenario

File Access Control Lists

Vulnerability

Countermeasure

Potential Impact

Contoso Scenario

Additional Security Settings—Directory Services

Disabling the NoLmHash Setting on Domain Controllers

Vulnerability

Countermeasure

Potential Impact

Contoso Scenario

Data Relocation—Active Directory Database and Log Files

Vulnerability

Countermeasure

Potential Impact

Contoso Scenario

Secure the Pre–Windows 2000 Compatible Access Group

Vulnerability

Countermeasure

Potential Impact

Contoso Scenario

2000 compatible access" Alias name pre-windows 2000 compatible access Comment A backward compatibility group which allows read access on all users and groups in the domain Members