Tips, Tricks, and Best Practices for Hardening Windows Server 2003

Tips, Tricks, and Best Practices for Hardening Windows Server 2003

Exchange Server 2003 is only as secure as Windows Server 2003. Therefore, it is imperative to secure Windows Server 2003 to ensure it conforms to the security standards for the organization.

Layered Approach to Server Security

Security works best when it is applied in layers . It is much more difficult to rob a house, for example, if a thief not only has to break through the front door, but also has to fend off an attack dog and disable a home security system. The same concept applies to server security: multiple layers of security should be applied so that the difficulty in hacking into a system becomes that much greater.

Windows Server 2003 seamlessly handles many of the security layers that are required, using Kerberos authentication, NTFS file security, and built-in security tools to provide for a great deal of security out of the box. Once Windows Server 2003 is secured according to the organization's requirements, Exchange Server 2003 security can be integrated to conform to the security requirements of the organization.

Physical Security Considerations

An Exchange Server 2003 server can be very restrictive in what resources are accessible but if the server is not physically secured, an unauthorized user or hacker can more easily gain unauthorized access. For example, simply unplugging the server can have serious repercussions even if the unauthorized user was not able to access messaging data.

Physical security should be a requirement for any organization because it is the most common cause of security breaches. Despite this fact, many organizations have loose levels, or no levels, of physical security for their mission-critical servers.

Servers should be physically secured behind locked doors, preferably in an environmentally controlled room. Other methods of physically securing servers includes hardware locking devices, video surveillance, and more.

Restricting Logon Access

All servers should be configured to allow only administrators to physically log in to the console. By default, Exchange Server 2003 does not allow any members of the domain users group local logon privileges. This prevents non-administrators from logging on to the server even if they can gain physical access to the server.

Auditing Security Events

Auditing is a way to gather and keep track of activity on the network, devices, and entire systems. By default, Windows Server 2003 enables some auditing, whereas many other auditing functions must be manually turned on. This allows for easy customization of the features the system should have monitored .

Auditing is typically used for identifying security breaches or suspicious activity. However, auditing is also important to gain insight into how the servers are accessed. Windows Server 2003's auditing policies must first be enabled before activity can be monitored.

Auditing Policies

Audit policies are the basis for auditing events on a Windows Server 2003 system. Depending on the policies set, auditing may require a substantial amount of server resources in addition to those resources supporting the server's functionality. Otherwise, it could potentially slow server performance. Also, collecting lots of information is only as good as the evaluation of the audit logs. In other words, if a lot of information is captured and a significant amount of effort is required to evaluate those audit logs, the whole purpose of auditing is not as effective. As a result, it's important to take the time to properly plan how the system will be audited. This enables the administrator to determine what needs to be audited and why without creating an abundance of overhead.

Audit policies can track successful or unsuccessful event activity in a Windows Server 2003 environment. These policies can audit the success and failure of events. The types of events that can be monitored include:

• Account Logon Events Each time a user attempts to log on, the successful or unsuccessful event can be recorded. Failed logon attempts can include logon failures for unknown user accounts, time restriction violations, expired user accounts, insufficient rights for the user to log on locally, expired account passwords, and locked-out accounts.

• Account Management When an account is changed, an event can be logged and later examined. Although this pertains more to Windows Server 2003 than Exchange Server 2003, it is still very relevant because the Exchange directory is stored in Active Directory.

• Directory Service Access Any time a user attempts to access an Active Directory object that has its own System Access Control List (SACL), the event is logged.

• Logon Events Logons over the network or by services are logged.

• Object Access The object access policy logs an event when a user attempts to access a resource (for example, a printer or shared folder).

• Policy Change Each time an attempt to change a policy (user rights, account audit policies, trust policies) is made, the event is recorded.

• Privilege Use Privileged use is a security setting and can include a user employing a user right, changing the system time, and more. Successful or unsuccessful attempts can be logged.

• Process Tracking An event can be logged for each program or process that a user launches while accessing a system. This information can be very detailed and take a significant amount of resources.

• System Events The system events policy logs specific system events, such as a computer restart or shutdown.

The audit policies can be enabled or disabled through either the local system policy or Group Policy objects. Audit policies are located within the Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy folder, as shown in Figure 12.2.

Figure 12.2. Windows Server 2003 audit policies.

Securing Groups

An important way to secure your messaging environment is by securing distribution and mail-enabled security groups. For instance, CompanyABC is a medium- sized company with 1,000 users. To facilitate company-wide notifications, the HR Department created a distribution group called "All Employees". All employees are members of the "All Employees " group. By default there are no message restrictions for new groups, meaning that anyone can send to this list. If CompanyABC has an Internet Mail SMTP Connector, this group will also have an SMTP address.

Consider what would happen if a new user sent an email to "All Employees" advertising a car for sale. Now imagine that the user sent it with a read receipt and delivery notification requested . This can have disastrous results if the server is unable to process this many requests at once.

In a similar scenario, intentions are not as innocent as the new user trying to sell a car. In fact, it can be an attempted denial of service (DOS) attack. An attacker sends an SMTP message to the "All Employees" group with a delivery notification receipt requested and spoofs the Return to address field as the same SMTP address as the distribution group. The effect is (1 + 1000 + 1000 * 1000) = 1,001,001 messages! Since a delivery notification receipt was requested, this single email results in over 1 million messages processed by the system.

Exchange Server 2003 now offers an easy solution for this problem by configuring message restrictions for the distribution group. To secure distribution groups so that only authenticated users can use it, do the following:

1. Open Active Directory Users and Computers from the Start, All Programs, Microsoft Exchange menu.

2. Right-click the distribution group and select Properties.

3. Select the Exchange General tab and under the Message restrictions section, check the check box to Accept messages: From authenticated users only.

4. Click OK when done.

An administrator could further restrict the usage of this group by allowing only a specific security group to use it. To restrict access to the distribution group to a specific user or group, do the following:

1. In the Active Directory Users and Computers snap-in, right-click the distribution group and select Properties.

2. Select the Exchange General tab and under the Message restrictions section, select the Only from radio button.

3. Click Add and enter the security group that has permissions to send to the distribution group.

4. Click OK when finished.

Keep Services to a Minimum

Depending on the role that an Exchange Server 2003 server will fulfill, not all services that are installed by default are necessary for the server to function. It is considered good practice to limit the number of entry points (services) into a server. Any services that are not required for the system to function should be disabled. Note that this can be performed using a customized security template.

Locking Down the File System

Files secured on Windows Server 2003 are only as secure as the permissions that are set on them. Subsequently, it is good to know that Windows Server 2003, for the first time in a Microsoft operating system, does not grant the Everyone group full control over share-level and NTFS-level permissions. In addition, critical operating system files and directories are secured, to disallow their unauthorized use.

Despite the overall improvements made, a complete understanding of file-level security is recommended to ensure that the file-level security of a server is not neglected.

NOTE

The Exchange Server 2003 installation process requires that partitions on the server are formatted as NTFS.

Using the Microsoft Baseline Security Analyzer

The Microsoft Baseline Security Analyzer (MBSA) is a tool that identifies common security misconfigurations and missing hotfixes via local or remote scans of Windows systems. MBSA provides users with the ability to scan a single Windows system and obtain a security assessment as well as a list of recommended corrective actions. Furthermore, administrators may use the MBSA tool to scan multiple functional roles of a Windows-based server on the network for vulnerabilities to help ensure systems are up-to-date with the latest security- related patches.

To run MBSA, do the following:

1. Download the latest security XML file to use with MBSA. (This is downloaded automatically if the server is connected to the Internet.) This file contains a list of current service packs and hotfixes that should be applied to a system.

2. Keep the default settings and scan the server(s).

Consulting Standards and Guidelines

As mentioned in Chapter 11, "Client-Level Security," Microsoft has gone to great lengths to provide secure and reliable products. Moreover, it has worked closely with companies, government agencies, security consultants , and others to address security issues in the computer industry.

In addition to Microsoft security standards and guidelines, it is advisable that organizations use recommended best practices compiled by the National Institute of Standards and Technologies (NIST) and the National Security Agency (NSA). Both NIST and NSA provide security lockdown configuration standards and guidelines that can be downloaded from their Web site (http://www.nist.gov and http://www.nsa.gov respectively).

Securing Servers with Security Templates

Security templates are a practical and effective means to apply security policies and configurations to Exchange Server 2003 servers. Although security templates are provided with Windows Server 2003, it is recommended to customize them prior to applying them using the Security Configuration and Analysis Microsoft Management Console (MMC) snap-in.

This not only ensures that computers are identically configured with the same security configurations but it also is an easy way to configure appropriate security measures for those computers that are not managed using GPOs.

NOTE

For more information on customizing and using security templates, refer to Chapter 11.

Keeping Up with Security Patches and Updates

Service packs (SPs) and hotfixes for both the operating system and applications, such as Exchange Server 2003, are vital parts to maintaining availability, reliability, performance, and security. There are several ways an administrator can update a system with the latest SP: CD-ROM, manually entered commands, Systems Management Server (SMS) Windows Update, or Microsoft Software Update Server (SUS).

NOTE

Thoroughly test and evaluate SPs and hotfixes in a lab environment before installing them on production servers. Also, install the appropriate SPs and hotfixes on each production server to keep all systems consistent.

Windows Update

Windows Update is a Web site that scans a local system and determines whether there are updates to apply to that system. Windows Update is a great way to update individual systems, but this method is sufficient for only a small number of systems. If administrators choose this method to update an entire organization, there would be an unnecessary amount of administration.

Software Update Services

Software Update Services (SUS) minimizes administration, management, and maintenance of mid- to large-sized organizations communicating directly and securely with Microsoft to gather the latest security updates and SPs (for Windows XP SP1 and Windows 2000 SP4 or higher).

The security updates downloaded onto SUS can then be distributed to either a lab server for testing (recommended) or to a production server for distribution. After these updates are tested , SUS can automatically update systems inside the network.

NOTE

You can find more information on SUS and download the product from

http://www.microsoft.com/windows2000/windowsupdate/sus/

Hardening IIS

IIS is an integral part of Windows Server 2003 and it has come a long way from its predecessors especially in terms of security. Several key enhancements such as a reduced attack surface and enhanced application isolation deliver a robust and secure Web platform.

IIS installs only the features needed to fill its defined role or function. It works by turning off unnecessary features, much like the IISLockdown utility performed, thus reducing the attack surface available to attackers . For previous versions of Windows, the IISLockdown tool was available as a separate download. It is now, however, built into IIS. IIS maintains a UrlScan.ini file with a specific section for DenyUrlSequences and can limit the length of specific fields and requests. This functionality replaces some of the features of URLScan, a complementary component of using IISLockdown.

IIS Hardening Checklist

Although IIS does a good job at installing and enabling only what is needed, it is important to review IIS security configurations on the organization's Exchange Server 2003 servers. Table 12.1 summarizes key hardening aspects of IIS as well as presents other key recommendations for securing the Web components on the messaging server.

Table 12.1. IIS Hardening Checklist

Recommendation	Description
Enable logging using W3C. Use the extended properties sheet to add more info to the logs.	IIS logging can identify many different parameters and record them for later analysis. Add client IP address, username, method, URI Stem, HTTP status, Win32 status, User Agent, server IP address, and server port.
Set log file ACLs (adminFull Control, systemFull Control, everyonewrite, create).	This prevents someone from covering his tracks. Any log file that IIS generates will be stored in the %SystemRoot%\system32\LogFiles folder on the system partition. If the access control settings for these files are not secured, an attacker might cover up his actions on the server by deleting associated log entries.
Remove unused script mappings.	Unused script mappings such as .htr , .ida , .htw , .idc , .printer , .shtm , .stm , and .shtml could be used to gain access to the system. If any script mappings within IIS are not being used, they should be removed.
Set appropriate directory permissions.	Set appropriate ACLs on virtual directories.

Other Hardening Techniques for Windows Server 2003

Although not all inclusive, Table 12.2 provides a quick checklist of recommended security precautions to take on an Exchange Server 2003 server.

Table 12.2. Windows Server 2003 Hardening Checklist

Recommendation	Description
Secure default Windows Repair Directory ( \%SystemRoot%\Repair ).	Set an appropriate level of access to this directory to prevent unauthorized access to system files.
Protect against data remnants.	The Recycle Bin saves a copy of a file when it is deleted through Windows Explorer. On critical servers this could pose a security risk. A sensitive file might be deleted; yet a copy of that file would remain in the Recycle Bin. To configure the Recycle Bin to prevent deleted files from being saved, use the following procedure: Right-click the Recycle Bin icon on the desktop, and select Properties. Check the box labeled Do not move files to the Recycle Bin. Remove files immediately on delete. Click OK. Empty the Recycle Bin of any preexisting files.
Automatically clear the pagefile before the system shuts down.	Virtual Memory support in Windows Server 2003 uses a system pagefile to swap pages from memory when they are not being actively used. On a running system, this pagefile is opened exclusively by the operating system and hence is well protected. However, to implement a secure Windows Server 2003 environment, the system pagefile should be wiped clean when the system shuts down. To do so, change the data value of the ClearPageFileAtShutdown value in the following Registry key to a value of 1 : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management . If the value does not exist, add the following value: Value Name : ClearPageFileAtShutdown Value Type : REG_DWORD Value : 1
Rename the administrator account.	Renaming the administrator account helps prevent unauthorized access by using the default administrator account. In addition, consider establishing a decoy account named "Administrator" with no privileges. Scan the event log regularly to identify attempts to use this account.
Remove all unnecessary file shares.	Scrutinize all shares to determine whether they should be removed or shares should be locked down.