Securing Windows 2000 Server

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

Chapter 11: Conclusion

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.

Congratulations. Now that you have finished this guide, you should have a clear understanding of how to assess risks that may impact the security of the Microsoft® Windows® 2000 servers in your organization. You have gained an understanding of how to plan for and design security into your infrastructure where possible, and how to maintain a secure environment going forward. This guide included prescriptive guidance that may be applied to any organization. Examples were provided for a security project undertaken for an enterprise by examining the security needs of Contoso, Ltd.

This guide includes material collected from consultants and systems engineers working in the field who have implemented Windows 2000 Server solutions in a variety of environments to provide you with the current set of best practices to perform this complex task. Chapters two and three in this guide introduced the concepts and terms relating to security risk management such as assets, threats, vulnerability assessment, exploits, and countermeasures. You also learned about a number of other key security terms, including confidentiality, integrity, and authentication. Chapter four introduced you to Contoso and explained what this organization determined what had to be done to improve the security of the Windows 2000 servers in the company's environment. Contoso's Windows 2000 computers were then assessed and a detailed plan was developed to address identified vulnerabilities.

Chapters five, six, and, seven then demonstrated how the concepts introduced in the earlier chapters are applied. Contoso was used in a scenario that closely mirrors the security tradeoffs that commonly exist in real world organizations today. Organization units (OUs) that rely on the Active Directory® directory service were used to group servers by their primary functional roles, and then Group Policy objects (GPOs) were created and linked to the OUs to simultaneously apply numerous settings to harden the servers against attacks and unauthorized access. A number of additional tools also were used to harden the servers, such as the IIS Lockdown Tool and URLScan, to further secure the computers at Contoso. In addition, some server hardening procedures were performed manually.

Regardless of your organization's environment, security should be taken seriously. However, many organizations still place little emphasis on security, mistakenly viewing it as something that restricts the agility and flexibility of their enterprise. When well-designed security becomes a core business requirement, and planning accounts for it at the start of every information technology (IT) project, a properly implemented security strategy can help to improve the availability and performance of your computer systems. On the other hand, when security is added to a project as an afterthought, it can have a negative effect on usability, stability, and management flexibility—all important reasons why every organization should make security a top priority.

Vulnerabilities Identified in the Contoso Environment

Chapter four identified the most critical vulnerabilities present on Contoso's servers. Contoso used a vulnerability scanning tool on its network to identify some of the major issues with its configuration. The tool returned a large list of items, which were then prioritized as High, Medium, or Low risk vulnerabilities. The following is a quick review of the list and a brief explanation of how these issues were addressed.

Buffer Overflows

A number of Contoso's servers were identified as susceptible to buffer overflows related to Microsoft Internet Information Services (IIS). A buffer overflow is a type of exploit that attackers employ to gain access to a computer. Specifically, the tool identified the ida/idq buffer overflow exploited by the Code Red worm, which had not been patched. A worm is a stand-alone, self-replicating program that usually consumes memory to the point of causing computers to crash.

Specific buffer overflow vulnerabilities were eliminated by installing service packs and hotfixes from Microsoft that provide safeguards against these types of vulnerabilities in such applications. Furthermore, the risk of an attacker exploiting buffer overflows as a class was significantly reduced. This risk reduction was accomplished through a number of countermeasures, including installing and configuring URLScan; relocating data, applications, and Web content to a storage volume separate from the location in which the operating system is installed; and by disabling unnecessary services and applications.

NetBIOS Enumeration

It was determined that all of Contoso's servers were vulnerable to NetBIOS enumeration. NetBIOS utilizes a default share for interprocess communications (IPC). By default, anyone can connect to this share—no user name or password is required. Although creating a null connection (that is, a connection with no user name or password) to the IPC$ share on a computer will not give someone rights to view files or control processes, it is possible to view a large amount of computer information. Malicious users can exploit this information disclosure vulnerability to gather data for use in later attacks.

The risk of an attacker exploiting anonymous access through NetBIOS was reduced by implementing a variety of countermeasures, including the Group Policy security option called Additional restrictions for anonymous connections. Access to null session pipes and null session shares, and IPsec filtering also was restricted.

SNMP Enumeration

Contoso uses Simple Network Management Protocol (SNMP) services on Windows 2000 servers for reporting events. The company had always used the default string "public," but their IT team was surprised to learn that in addition to generic hardware monitoring, SNMP also may be used to return information on other aspects of the company's computers. Attackers also can exploit this information disclosure vulnerability to collect information for use in later assaults.

Although SNMP is an inherently insecure protocol because of the fact that SNMP network data packets are contained in cleartext, it remains a very useful protocol for managing enterprise networks. SNMP is an industry standard supported by most modern network operating systems and enterprise management systems. The risk of sensitive information being disclosed through SNMP was mitigated by changing the SNMP string on all of the Contoso servers. A more effective way to protect SNMP network traffic is to implement IPsec encryption between the servers; however, this encryption consumes a lot processing power on busy servers. Contoso plans to eventually replace the network interface cards (NIC) on their servers with NICs that can perform IPsec encryption without placing any load on the CPUs of their computers. After these NICs are deployed Contoso will implement IPsec encryption for most server-to-server communications.

DNS Enumeration

The DNS servers for Contoso did not restrict zone transfers. Without securing this feature of DNS, an attacker can easily obtain data from an organization’s DNS servers. Contoso uses Active Directory integrated with DNS in Windows 2000. DNS holds a large amount of information about a domain, including server names and Internet Protocol (IP) addresses, services running on the network, and servers hosting specific services, such as global catalogs and domain controllers.

DNS enumeration was made much more cumbersome for attackers by configuring the DNS servers to allow zone transfers only to a list of known computers. Any requests for a zone transfer from a server not on the authorized list will now be ignored. The alternative would be to not allow zone transfers. But this countermeasure was rejected because Contoso's network is large and they have a DNS server hierarchy that includes secondary DNS servers located in remote sites.

Weak Passwords

The assessment tool chosen by Contoso has additional functionality that allows it to perform basic dictionary attacks against user accounts to identify weak passwords. In addition, the tool examines the password hashes in the Security Accounts Manager (SAM) database to determine whether there were any blank or duplicate passwords. If a large number of duplicate passwords are identified, an attacker may determine that these passwords are default passwords to potentially exploit each time a new account is set up in the organization.

The information in the SAM is encrypted, but even without trying to crack the passwords, it is easy to identify blank or duplicate passwords based on the hash. Because Contoso did not have an account lockout policy defined, an unlimited number of attempts could be made to determine passwords. The scanning tool found a number of passwords consisting purely of common words found in any dictionary that it could crack in a matter of minutes.

The risk of passwords being cracked on the Contoso network was lowered by implementing strict password and account lockout policies. It would be more effective to implement smartcards for user authentication, but Contoso does not have either a public key infrastructure (PKI) deployed yet, or the resources to design and implement an enterprise PKI. In the future Contoso plans to build a robust PKI that will be integrated with Active Directory to deploy smartcards in a staged process.

Unencrypted Server Message Block Traffic

By default, the Microsoft Windows NT® local area network (LAN) Manager (NTLM) challenge/response does not pass the LANManager (LM) authentication or NTLM hash across the network. However, tools exist that can monitor this exchange traffic and use a brute force method to derive the original LM hash value. After the hashes have been obtained, several utilities can be used to crack the hashes into a cleartext password.

Unfortunately, all four of the following SMB encryption and signing countermeasures had to be disabled: Digitally sign client communication (always); Digitally sign client communication (when possible); Digitally sign server communication (always); and Digitally sign server communication (when possible).

These countermeasures were disabled to ensure compatibility with legacy SMB applications and operating systems. Contoso plans to reduce the risk of this vulnerability by upgrading all of their computers to Windows 2000, Windows XP, and Windows Server™ 2003 in the next 18 months. When the upgrades are complete, the security team at the company can enable all four settings, however the team understands that there may still be a significant performance impact on their busiest servers.

If the performance impact is too large, the team will disable the settings for Digitally sign client communication (always) and Digitally sign server communication (always) on all the company's computers, as well as disable all four settings on any servers showing performance problems. An alternative solution would be to implement IPsec encryption between all computers including the end-user computers.

Ineffective Auditing

Many of the servers scanned did not have audit settings enabled to a sufficient level to identify potential attacks. For example, the Audit Account Logon setting was not enabled, which could help to identify brute force attacks against passwords.

Appropriate auditing settings were chosen and implemented on Contoso's servers so that significant security events are recorded in the Security event log while most unimportant ones are omitted. The size of the event logs was dramatically increased so that even the busiest servers would be able to hold several weeks' worth of entries in their logs.

Unchecked DoS Attacks

A denial of service (DoS) attack is any attack that prevents users from accessing resources. There are many variations of DoS attacks, but some of the most common affect either IIS or the TCP/IP stacks of individual computers. Several changes were made on the computers at Contoso to lower the risk of TCP/IP–based DoS attacks.

The TCP/IP network stack also was hardened by implementing a number of registry value entries. Because these registry entries can not be configured directly through Group Policy, they were added into the security templates before importing the templates into the appropriate GPOs.

IIS Directory Traversal

A review of the IIS servers revealed a common directory traversal issue. The exploit of this vulnerability would allow an attacker not only to view information such as directory layouts and the contents of files on the target computer, but in many cases, it would also allow the attacker to write files and execute commands on the servers.

Specific directory traversal vulnerabilities were eradicated by installing recommended service packs and hotfixes from Microsoft. The risk of an attacker exploiting any new directory traversal vulnerabilities also was dramatically lowered by configuring URLScan to block HTTP requests that contain strings of characters commonly used in this type of attack. Other countermeasures used to lower this risk included relocating data, applications, and Web content to a storage volume separate from the operating system; and disabling unnecessary services and applications.


Get the Securing Windows 2000 Server

Solution Accelerator Notifications

Sign up to stay informed


Send us your comments or suggestions