Additional System Countermeasures

Applies To: Windows Server 2008

Although the majority of the countermeasures discussed in this guide are security settings applied by using Group Policy, there are some additional settings that you should consider configuring on your servers. Review the following sections for guidance about how to implement these additional settings.

• Secure built-in accounts

• Convert file systems to NTFS

• Segregate data, applications, and operating systems

• Configure SNMP community name

• Disable NetBIOS and SMB on public-facing interfaces

• Disable Problem Reports and Solutions

• Configure Windows Firewall with Advanced Security

• Use simplified IPsec policies included with Windows Firewall with Advanced Security

• Enable BitLocker Drive Encryption

• Configure FIPS policy for a mixed environment

Secure built-in accounts

The Windows Server® 2008 operating system has a number of built-in user accounts that cannot be deleted but can be renamed. Two of the most well-known built-in accounts in Windows Server 2008 are Guest and Administrator. Both of these accounts have been disabled by default in the Windows Vista® operating system.

Vulnerability

By default, the Guest account is disabled on member servers and domain controllers. This configuration should not be changed. The built-in Administrator account is used by many variations of malicious code in an initial attempt to compromise a server. You should rename the built-in Administrator account and alter its description to prevent compromise of remote servers by attackers who try to use this well-known account.

The value of this configuration change has diminished over the past few years since the release of attack tools that specify the security identifier (SID) of the built-in Administrator account to determine its true name and then break into the server. A SID is the value that uniquely identifies each user, group, computer account, and logon session on a network. It is not possible to change the SID of this built-in account.

Ideally, organizations should employ different passwords on each server. If you use the same account names and passwords on all of the servers, you accept the risk that an attacker who gains access to one member server can gain access to all others.

Countermeasure

Rename the Administrator account and change the password to a long and complex value on every server.

You can rename the built-in Administrator account through Group Policy. The baseline policies that are described by the Windows Server 2008 Security Guide do not implement this setting because every organization should choose a unique name for this account. To rename the account, configure the Rename administrator account setting in Group Policy at the following location:

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security\Options

Potential impact

If this countermeasure is adopted, your business practice must encompass a form of securely recording the names of the Administrator account configured for each server and its corresponding password so that the account name and password can be retrieved when necessary.

Convert file systems to NTFS

The NTFS file system partitions support access control lists (ACLs) and, optionally, encryption—by means of the Encrypting File System (EFS)—at the file and folder levels. This support is not available with the FAT, FAT32, or FAT32x file systems. FAT32 is a version of the FAT file system that has been updated to permit significantly smaller default cluster sizes and support hard disks of up to 2 terabytes in size. FAT32 is included in the Microsoft Windows® 95 OEM Service Release 2 (OSR2), Windows® 98, Windows® Millennium Edition, Windows Server® 2003, Windows® XP, Windows Server 2008, and Windows Vista operating systems.

Proper configuration of NTFS permissions can help protect your organization's data from exposure or unauthorized modifications, but it is critical that you do not forget about physical security. An attacker who has gained physical control of a computer can start it with an alternative operating system by using a bootable disk. An attacker who has removed a hard disk from one of your organization's computers can move it to a different, unmanaged computer. After the attacker has complete physical control of the storage media, it is very difficult to keep that data secure.

This fundamental problem of computer security also exists for the file systems of other operating systems. After an attacker has physical access to the disk, the NTFS permissions—and most other safeguards—can be easily bypassed. Obvious physical security measures that your organization can implement include restricted access to buildings, installation of magnetic locks on server rooms, use of locks in server racks, and use of docking station locks for portable computers. In addition to these security measures, we recommend the following additional technologies that can help lessen the impact of these types of attacks:

• Use BitLocker Drive Encryption to encrypt the drives of servers and client computers that contain sensitive information, user accounts, or computers that are not in a secured location, such as branch office servers and mobile computers. This helps prevent data loss if the drive is removed or tampered with, as well as providing a start-up authentication method.

• Deploy Windows Server 2008 read-only domain controller (RODCs) in branch offices instead of standard domain controllers. This mitigates the vulnerability that an attacker could modify the Active Directory Domain Services (AD DS) database on a running domain controller to grant access to malicious users or computers.

• Use EFS to encrypt user data. Instruct users to use their domain accounts and either configure it without a recovery agent or configure it for domain administrator accounts rather than the local Administrator account.

• Use BIOS passwords to deny unauthorized users the ability to easily start computers within your organization.

• Configure the system BIOS to disable the ability of computers to start from CD drives and floppy disk drives. This configuration can help prevent unauthorized users from starting computers by using their own operating system.

Vulnerability

Files that you cannot protect with ACLs can be easily viewed, changed, or deleted by unauthorized users who can access them locally or over the network. Other files can be protected with ACLs, but encryption provides much more protection and is a viable option for files that must be accessible only to a single user.

Countermeasure

Format all partitions on every server with NTFS.

Potential impact

Newly converted partitions may not be compliant with your organization security policy. After the partitions are converted, apply the security settings that you have selected as part of your organizational security policy to ensure that the data access rights are configured correctly.

Segregate data, applications, and operating systems

It has long been considered a best practice to locate data, applications, and operating system files on separate storage devices to improve computer performance. If you segregate these types of files on servers, you also help protect the applications, data, and operating systems from directory traversal attacks.

Vulnerability

Two types of vulnerabilities are exposed if you locate applications, data, and log files on the same storage volume as the operating system.

• Denial of service vector. Locating data, applications, and the operating system on a single storage volume provides the potential for a user to fill an application log file accidentally or deliberately, or upload files to the server and fill the storage volume with data.

• Directory traversal vector. In a directory traversal exploit, an attacker impersonates a known account and uses it to navigate the directory tree to the root of the system volume. The attacker can then search through the operating system file folders to run a tool remotely.

There are thousands of variations on directory traversal attacks that exploit vulnerable applications and operating systems. Internet Information Services (IIS) has been vulnerable to several such attacks, although the IIS Lockdown feature that is included in Windows Server 2003 and the secure-by-default installation of the Web server role in Windows Server 2008 mitigate this vulnerability.

If you are deploying a Web server on Windows Server 2008, be sure to review the new information about IIS 7.0 security on TechNet IIS 7.0: Configure Web Server Security.

Countermeasure

Whenever possible, place Web content, applications, data, and application log files to a partition that is separate from the system volume.

Potential impact

For organizations that build and maintain servers in a consistent manner, the impact should be minimal. For organizations that do not maintain this information, the impact is somewhat greater because administrators must investigate how each computer is set up.

Configure SNMP community name

The Simple Network Management Protocol (SNMP) is a network management standard that is widely used in TCP/IP networks. SNMP provides a way to manage network nodes—servers, workstations, routers, bridges, and hubs—from a centrally located host. SNMP performs its management services through a distributed architecture of management systems and agents. Computers that run network management software are referred to as SNMP management systems or SNMP managers. Managed network nodes are referred to as SNMP agents. The SNMP service for Windows Server 2008, Windows Vista, and Windows Server 2003 operating systems does not have a configured SNMP community name.

The SNMP service provides a rudimentary form of security by means of community names and authentication traps. You can restrict SNMP communications for agents and allow them to communicate with only a specific list of SNMP management systems, and community names can be used to authenticate SNMP messages. Although a host can belong to several communities at the same time, an SNMP agent does not accept requests from a management system in a community that is not on its list of acceptable community names. There is no relationship between community names and domain or workgroup names. A community name can be thought of as a password that is shared by SNMP management consoles and managed computers. It is your responsibility as a system administrator to create hard-to-guess community names when you install the SNMP service. The SNMP service is not installed by default in Windows Server 2008 or Windows Vista.

Vulnerability

The single biggest vulnerability with SNMP is that almost all vendors set a default community string name (such as "Public"), and these default community names are well known.

A second vulnerability is more difficult to overcome. Because SNMP version 1 and version 2 send traffic in plain text, the community string is transmitted across the network without being encrypted or hashed when an SNMP management device connects to an SNMP client. To address this second vulnerability, you can use IPsec to encrypt all traffic between servers.

Countermeasure

Configure the SNMP community string for read access on all computers to a random alphanumeric value. Ensure that you leave write access through SNMP disabled. Unlike many services in Windows, the SNMP service does not have a corresponding snap-in. Instead, you configure the SNMP service through additional tabs on the properties of the SNMP service in the Services snap-in.

To configure the SNMP community string

1. Log on to the computer with an account that is a member of the local Administrators group or has been delegated permission to install and configure system services.

2. Click Start, click Run, and then type services.msc to open the Services snap-in console.

3. At the Services console, double-click SNMP Service, and then click the Traps tab.

4. In the Community names field, type the community name that you want to use.

5. Click Add to list and the name that you typed displays in the Community names drop down list.

6. Click OK to close the dialog boxes.

The community name is stored in the registry as a registry value with a DWORD value of 4, so you could automate this change by creating a script or adding a line to a Group Policy template and importing the template into a domain-based Group Policy. The value is stored in:

HKLM\SYSTEM\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities

You must also reconfigure the community string on all management tools that use the SNMP protocol.

To address the vulnerability in which community names transmitted in plain text can be captured and used by unauthorized personnel to gain valuable information about network resources, configure an IPsec policy and filter list to help protect SNMP communications.

To create an IPsec filter list

1. Log on to the computer with an account that is a member of the local Administrators group or has been delegated permission to install and configure system services.

2. Open the IP Security Policy Management snap-in in the Microsoft Management Console.

3. Right-click IP Security Policies on Local Computer, and then click Manage IP filter lists and filter actions.

4. Click the Manage IP Filter Lists tab, and then click Add. The IP Filter List dialog box opens.

5. In the Name box, type SNMP Messages (161/162). In the Description box, type Filter for TCP and UDP ports 161.

6. Clear the Use Add Wizard check box, and then click Add. The IP Filter Properties property sheet opens.

7. Click the Addresses tab. In Source address, click Any IP address. In Destination address, click My IP Address. Verify that the Mirrored. Match packets with the exact opposite source and destination addresses check box is selected.

8. Click the Protocol tab. In Select a protocol type, click UDP.

9. In Set the IP protocol port, click From this port, and then type 161 in the corresponding text box. Click To this port, and then type 161 in the corresponding text box. Click OK to close IP Filter Properties and apply your settings.

10. Repeat steps 6 through 9 to add another filter list. In the second filter list, specify TCP in Select a protocol type for step 8, and specify port 161 as the IP protocol port for step 9.

11. Repeat steps 6 through 9 to add another filter list. In the third filter list, specify UDP in Select a protocol type for step 8, and specify port 162 as the IP protocol port for step 9.

12. Repeat steps 6 through 9 to add another filter list. In the fourth filter list, specify TCP in Select a protocol type for step 8, and specify port 162 as the IP protocol port for step 9.

13. Click OK to close Manage IP filters lists and filter actions and apply these settings.

You can also create IPsec policies to help secure communications on TCP and UDP ports 161 and 162 to secure SNMP transactions.

To create an IPsec policy to require IPsec for SNMP communications

1. Log on to the computer with an account that is a member of the local Administrators group or has been delegated permission to install and configure system services.

2. Click Start, point to Administrative Tools, and then click Local Security Policy to open the Local Security Policy snap-in.

3. Expand Security Settings, right-click IP Security Policies on Local Computer, and then click Create IP Security Policy to start the IP Security Policy Wizard.

4. On the IP Security Policy Name page, in Name, type Secure SNMP. In Description, type Force IPsec for SNMP Communications, and then click Next.

5. Clear the Activate the default response rule check box, and then click Next.

6. On the Completing the IP Security Policy Wizard page, verify that the Edit properties check box is selected, and then click Finish. The Secure SNMP Properties dialog box opens automatically when the wizard closes.

7. Clear the Use Add Wizard check box, and then click Add.

8. Click the IP Filter List tab, and then click SNMP Messages (161/162).

9. Click the Filter Action tab, and then click Require Security.

10. Click the Authentication Methods tab. Kerberos is the default authentication method. If you require alternate authentication methods, click Add, and then specify the authentication method properties.

11. In the Secure SNMP Properties property sheet, verify that the SNMP Messages (161/162) check box is selected, and then click OK.

12. In the Local Security Policy snap-in, right-click the Secure SNMP rule, and then click Assign.

Complete this procedure on all Windows-based computers that are running the SNMP service. This IPsec policy must also be configured on the SNMP management station.

Potential impact

If you are running SNMP services on your network, implementing these countermeasures may require some system downtime while the management station and the client computers are updated with the new policies.

Disable NetBIOS and SMB on public-facing interfaces

Some servers are located in networks that cannot be fully controlled, such as publicly accessible Web servers and e-mail gateways. These types of servers are also referred to as "bastion hosts." If you have any such servers, you should consider the recommended procedures in this countermeasure. However, you should test each change thoroughly and make sure you can still manage computers on which NetBIOS and SMB has been disabled.

Vulnerability

Because bastion hosts are on the front line of your public-facing network, they have the greatest attack-surface vulnerability.

NetBIOS and Server Message Block (SMB) support File and Printer Sharing for Microsoft Networks and Client for Microsoft Networks and some remote management tools. Windows Vista and Windows Server 2008 support SMB 2.0 but use SMB 1.0 when communicating with a client that does not support SMB 2.0.

NetBIOS uses the following ports:

• UDP/137 (NetBIOS name service)

• UDP/138 (NetBIOS datagram service)

• TCP/139 (NetBIOS session service)

SMB uses the following ports:

• TCP/139

• TCP/445

The most common attacks are denial-of-service and man-in-the-middle attacks against open NetBIOS and SMB ports. SMB signing mitigates the risk of man-in-the-middle attacks for the SMB protocol, but increases the processing load on the server, so it may not be the best option for servers with high traffic, such as Internet-facing servers. When these attacks are successful, they can cause disclosure of data, loss of data, and inability to use computing resources.

Countermeasure

You can reduce a server's attack surface and effectively protect the server from compromise through the SMB and NetBIOS protocols by disabling SMB and NetBIOS over TCP/IP on servers that are accessible from the Internet.

Use the following procedures to remove File and Printer Sharing for Microsoft Networks and Client for Microsoft Networks from an Internet-facing server.

To disable SMB

1. Log on to the server by using an account with Administrator privileges.

2. In Control Panel, double-click Network Connections.

3. Right-click any Internet-facing connection, and then click Properties.

4. In the Properties dialog box, clear the Client for Microsoft Networks check box and the File and Printer Sharing for Microsoft Networks check box.

5. Click OK.

Performing this procedure unbinds the services from the selected network interface but still allows them to be used for other network interfaces. If you do not want these services to be used at all on the system, you can uninstall them.

To disable NetBIOS over TCP/IP

1. Log on to the computer with an account that is a member of the local Administrators group or has been delegated permission to install and configure system services.

2. In Control Panel, double-click System, click the Hardware tab, and then click Device Manager.

3. On the View menu, click Show hidden devices.

4. Expand Non-Plug and Play Drivers.

5. Right-click NetBios over Tcpip, and then click Disable.

These steps disable the SMB direct host listener on TCP/445 and UDP 445 and the Nbt.sys driver, which disables the NetBIOS Session Service (which listens on TCP port 139).

Potential impact

When these settings are disabled, computers cannot connect to the server through SMB. The servers are unable to access folders shared on the network. Management tools that depend on NetBIOS or SMB for connectivity are unable to connect to the servers. This makes it difficult to manage servers that operate under this configuration because many remote management tools use these protocols for connection to the server. However, Remote Desktop connections do not use these protocols, and you can use Remote Desktop to connect to these computers for administration purposes.

Disable Problem Reports and Solutions

Problem Reports and Solutions helps you check for solutions to hardware and software problems that can occur on your computer. You can choose to report problems and check for solutions automatically, or you can choose to check for solutions whenever a problem occurs. Problem descriptions and solutions are saved so that you can view them at any time.

Problem Reports and Solutions in Windows Vista and Windows Server 2008 is enabled by default. When Windows Server 2008 is installed and the computer is started for the first time, the Initial Configuration Tasks interface appears, displaying a variety of tasks including Enable automatic updating and feedback. In this task, you can choose to enable a default level of automatic updating and feedback (which includes error reporting), or you can manually configure settings. If you enable automatic updating and feedback, the consent level of Windows Error Reporting is Yes, automatically send summary reports and Notify me if there are possible solutions to the problem. If you manually configure settings, you can choose among the consent levels. If you do not perform the task at all, the consent level is Ask me about sending reports every time an error occurs. If your organization tightly controls Internet access or deployment of updates, you can disable this feature.

Vulnerability

Trapping failing software and reporting it can cause system instability. Therefore, some organizations may feel that error reporting on critical production computers should be done as part of system maintenance rather than automatically to mitigate this risk. Additionally, because Problem Reports and Solutions transmits data across the Internet, the system must be connected to the Internet to make use of the feature.

Countermeasure

In a managed environment, you can choose to disable Windows Error Reporting or control it in several ways:

• You can use Group Policy or an answer file for unattended installation to control the consent level (described previously) to determine the amount of prompting that users or administrators encounter before information about a software problem is sent to Microsoft. For example, you can set the consent level so the person using the computer is always prompted before information is sent.

• You can use Group Policy to disable Windows Error Reporting by enabling the Turn off Windows Error Reporting policy setting located in Computer Configuration\Administrative Templates\System\Internet Communication Management\Internet Communication settings.

• You can use Group Policy to redirect error reports to a server on your intranet by using the Group Policy setting, Configure Corporate Windows Error Reporting. To fully manage error reporting on a local server, you must purchase software and software services for analyzing the errors that you capture on your servers. Based on your policies and the data in the error reports, you can filter the reports before they are sent to Microsoft. Such software is also useful for determining the types of problems users and administrators are experiencing most often. For more information about Microsoft software designed for use with the Group Policy setting, Configure Corporate Windows Error Reporting, see the System Center Operations Manager 2007 Web site (https://go.microsoft.com/fwlink/?LinkId=106414)

For more information about the information collected by Windows Error Reporting in Windows Server 2008, see Windows Error Reporting and the Problem Reports and Solutions Feature in Windows Server 2008 (https://technet.microsoft.com/en-us/library/cc732067.aspx)

Potential impact

Problem reports are not automatically created if programs crash. Systems administrators and developers have less information available to them to diagnose the cause of such problems, and the error reporting feature does not work.

Configure Windows Firewall with Advanced Security

An Internet firewall can help prevent outsiders from accessing your computer through the Internet. Windows Firewall with Advanced Security is provided with Windows Vista and Windows Server 2008. The new Windows Firewall in Windows Vista and Windows Server 2008 has the following enhancements over the Windows Firewall in Windows Server 2003 with SP1:

• Supports both incoming and outgoing traffic.

• Includes a new snap-in for graphical user interface (GUI) configuration.

• Integrates firewall filtering and IPsec protection settings.

• Allows exceptions for Active Directory accounts and groups, source and destination IP addresses, IP protocol number, source and destination TCP and UDP ports, all or multiple TCP or UDP ports, specific types of interfaces, ICMP and ICMP for IPv6 (ICMPv6) traffic by type and code, and for services.

Windows Firewall has been turned on by default on Windows client operating systems starting with Windows XP with Service Pack 2 (SP2), but Windows Server 2008 is the first Windows server operating system to have Windows Firewall turned on by default. This has implications whenever an application or service is installed that must be allowed to receive unsolicited incoming traffic over the network. Many older applications are not designed to work with a host-based firewall, and might not operate correctly unless you define rules to allow that application to accept unsolicited incoming network traffic. When you install a server role or feature that is included with Windows Server 2008, the installer automatically enables or creates firewall rules to ensure that the server role or feature operates correctly. To determine what firewall settings must be configured for an application, contact the application vendor. Firewall settings are often posted on the vendor's support Web site.

For more information about managing Windows Firewall with Advanced Security on Windows Vista and Windows Server 2008, see "Windows Firewall with Advanced Security and IPsec" (https://go.microsoft.com/fwlink/?LinkID=108689).

Use simplified IPsec policies included with Windows Firewall with Advanced Security

IPsec is a tool that allows network security administrators to permit, block, or negotiate security for TCP/IP traffic. IPsec is independent of and transparent to applications. IPsec policy provides static TCP/IP traffic filters (also called selectors) that are necessary to negotiate security through Internet Key Exchange (IKE).

In Windows Vista, IPsec policies are tightly integrated with Windows Firewall with Advanced Security and support IPv6. Windows Vista and Windows Server 2008 support the following two types of IPsec rules:

• IPsec rules

  Earlier IPsec rules that are currently deployed in Windows 2000 and in Windows Server 2003 can be applied to a Windows Vista-based computer. The earlier IPsec rules are managed by the Policyagent service. These IPsec rules are IKE rules that support only computer-based Kerberos authentication, X.509 certificates, or preshared key authentication. These IPsec rules are configured in the IPsec Policy Management snap-in. IKE-based Policyagent rules are applied in the same manner as in Windows 2000 and in Windows Server 2003. Although multiple policies can be applied to a given computer, only the last policy that is applied is successful. This is according to the "last writer wins" method. Additionally, IKE policy settings cannot be merged.

• Connection security rules

  Connection security rules are supported only in Windows Vista and in Windows Server 2008. Connection security rules are supported by an extension to IKE that is called Authenticated IP (AuthIP). AuthIP adds support for the following authentication methods:

  • Interactive user Kerberos credentials or interactive user NTLMv2 credentials

  • User x.509 certificates

  • Computer Secure Sockets Layer (SSL) certificates

  • NAP health certificates

  • Anonymous authentication (optional authentication)

  Connection security policies can be configured to create IPsec-based policies that are compatible with IKE version 1-based clients, such as Microsoft Windows 2000, Windows XP, and Windows Server 2003. Connection security policies can also be configured to create policies that support communications only between Windows Vista-based computers and Windows Server 2008-based computers. The improvements made to IPsec in Windows Vista and Windows Server 2008 were focused on improving security and manageability. The underlying architecture of IPsec did not change. For more information about Windows Firewall with Advanced Security and IPsec in Windows Server 2008 and Windows Vista, see Windows Firewall with Advanced Security and IPsec (https://go.microsoft.com/fwlink/?LinkID=108689).

Vulnerability

Although most network security strategies focus on how to prevent attacks from outside an organization's network, a great deal of sensitive information can be lost by internal attacks that interpret data on the network or that exploit design or implementation weaknesses in upper-layer protocols to gain access to a computer. Attackers may use NetBT null sessions to gain information that could be used to compromise administrator passwords (if other security settings are not used or accidentally turned off).

Attackers must locate only one vulnerability in one application port to gain access and potentially full control of a computer. As noted, because many types of data are not protected when they travel across the network, employees, support staff members, or visitors may copy data for later analysis. Firewalls that are located between the internal network and the Internet offer no protection against such internal threats. Internal firewalls often cannot provide authenticated access controls that are necessary to protect clients and servers, nor can they provide end-to-end security of network traffic between computers.

Countermeasure

Use IPsec to protect network traffic on your internal network. IPsec filters recognize TCP/IP traffic by source and destination IP address, by IP protocol type, and by TCP and UDP ports. IPsec filters help contain and control the spread of malicious software because they block worm and virus traffic. Also, IPsec can make it very difficult for an attacker to use remote shells or other attack tools to gain access to the computer from within a compromised application.

In Windows Server 2008 and Windows Vista the new Windows Firewall with Advanced Security snap-in now controls both traditional firewall responsibilities (blocking and allowing both inbound and outbound traffic) and protecting traffic with IPsec. Combining both firewalling and protection configuration helps to prevent contradictory rules. Additionally, commands within the netsh advfirewall context can be used for command-line configuration of both firewall and IPsec behavior. The integration of Windows Firewall with IPsec provides computers running Windows Server 2008 or Windows Vista with an authenticating firewall that helps protect again both internal and external threats.

IPsec in Windows Server 2008 and Windows Vista provides an optional behavior when negotiating IPsec protection. If enabled, when initiating communication with another network node, an IPsec node running Windows Server 2008 or Windows Vista attempts to communicate in the clear and negotiate protected communication in parallel. If the initiating IPsec peer does not receive a response to the initial negotiation attempt, the communication continues in the clear. If the initiating IPsec peer receives a response to the initial negotiation attempt, the communication in the clear continues until the negotiation can complete, at which point subsequent communications are protected.

With this optional behavior and the recommended configuration to require protection for incoming initiated communications and request protection for outgoing initiated communications, the initiating node discovers whether the node it is communicating with is capable of IPsec and behaves accordingly. This new behavior greatly simplifies IPsec policy configuration. For example, the initiating node does not need a set of predefined IPsec filters for exemptions for the set of hosts that either should not or cannot protect network traffic with IPsec. The initiating node tries both protected and unprotected traffic in parallel, and if protected communication is not possible, the initiating node uses unprotected communication.

This new negotiation behavior also improves the performance of unprotected connections to hosts. An IPsec node running Windows Server 2003 or Windows XP that is configured to request protected communications but allow unprotected communications—a behavior known as "fallback to clear"—sends the negotiation messages and then waits for a response. The initiating node waits up to three seconds before falling back to clear and attempting unprotected communications. With Windows Server 2008 and Windows Vista, there is no longer a three-second delay when falling back to clear because communications in the clear is already in progress while the initiating node is waiting for a response.

For more information about simplified IPsec policies in Windows Vista and Windows Server 2008 see the article "New Networking Features in Windows Server 2008 and Windows Vista" (https://technet.microsoft.com/en-us/library/bb726965.aspx).

You can apply IPsec policies in several ways:

• Apply them on an individual computer.

• Attach them to an organizational unit (OU) or domain by using Group Policy.

• Write a script for the netsh ipsec command, and then run the script on selected computers.

It is possible to distribute the IPsec policies based on Group Policy. However, when IPsec policies must be tailored to specific computers, it may be better to use local policies. Alternatively, a mix of local or domain-based policy and Netsh IPsec-scripted persistent policy may be the most manageable. In particular, Netsh must be used to set persistent policy that provides security during computer startup.

Windows Vista and Windows Server® 2008 use a new filtering subsystem, the Windows Filtering Platform, that allows for packet filtering to be enabled per application, per user, and per connection in addition to per network interface or per port and for stateful packet filtering. For more information about the Windows Filtering Platform, see About Windows Filtering Platform (https://go.microsoft.com/fwlink/?LinkId=116227).

Potential impact

Although IPsec end-to-end protection can greatly enhance security, if you deploy IPsec-encrypted communications on your network, you incur additional training and administrative costs. It may also involve additional hardware costs if you must purchase IPsec hardware, offload network adapters, or increase CPU capacity. Therefore, before you deploy IPsec for any specific scenario, you should carefully consider and document the potential security threats that IPsec is intended to address, your security requirements, the costs of IPsec deployment, and the expected business benefits.

Although the local IPsec policy can be read-only by the administrators who defined the policy, policy that is stored in Active Directory must be accessible by all domain computers. Therefore, it is difficult to maintain privacy of the preshared key value. We recommend the use of digital certificates when the Kerberos protocol cannot be used for IKE authentication. IPsec policy should be designed to either protect all traffic, or to negotiate IPsec just for specific TCP or UDP ports. IPsec policy on the client side typically must be configured with the server's static IP address. If you require IPsec on the server side, access is denied to client computers that do not have a compatible IPsec policy configuration and mutual trust method.

Enable BitLocker Drive Encryption

BitLocker Drive Encryption (BitLocker) is a data protection feature available in Windows Vista Enterprise and Windows Vista Ultimate operating systems for client computers, and in Windows Server 2008. BitLocker addresses the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned personal computers by providing a closely integrated solution in Windows Vista.

Data on a lost or stolen computer is vulnerable to unauthorized access, either by running a software attack tool against it or by transferring the computer’s hard disk to a different computer. BitLocker helps mitigate unauthorized data access by enhancing Windows Vista file and system protections. BitLocker also helps render data inaccessible when BitLocker-protected computers are decommissioned or recycled.

For Windows Server 2008 servers in a shared or potentially nonsecure environment, such as a branch office location, BitLocker can offer the same level of data protection that it offers on client computers. This additional feature, which is available for Windows Server 2008, enables an IT administrator to encrypt both the operating system volume and additional data volumes on the same server.

By default, BitLocker is not installed with Windows Server 2008. Add BitLocker from the Windows Server 2008 Server Manager page. After BitLocker is installed, setup and maintenance are performed as described later in this document. You must restart after installing BitLocker on a server. Using Windows Management Instrumentation (WMI), you can enable BitLocker remotely on servers and client computers.

One of the authentication methods that BitLocker can use to validate access to a drive is the entry of a personal identification number (PIN) at startup. Requiring a PIN entry is a good security measure on client computers because it requires that the user starting the computer have knowledge of a secret in addition to have a start-up key on a USB device or the validation that the drive have not been tampered with by the trusted platform module. However, you may not want to enable the PIN feature on a server where startup speed is a factor or where human intervention in case of a restart is not possible. In many server environments, uptime and remote management are critical. One feasible deployment scenario is to enable BitLocker with PIN authentication in branch offices where an employee must turn on the server at the start of every work shift. In this scenario, the individual responsible would know and enter the PIN at startup.

Using a USB startup key with BitLocker is the method by which you can enable BitLocker protection on computers that do not have a Trusted Platform Module (TPM). They also provide a securable key that can be controlled to limit access to BitLocker protected computer. USB keys can be used with both client computers and servers. However, USB key startup only increases data protection if the USB keys are not left in the computer after startup. Therefore, to maximize data protection, someone must manually insert the startup key at each computer restart and then remove the key until needed again. This may not be feasible for some servers.

For more information about using BitLocker on mobile computers, see the see "Data Encryption Toolkit for Mobile PCs" (https://go.microsoft.com/fwlink/?LinkId=85982).

For more information about using BitLocker on Windows Server 2008, download the "Windows BitLocker Drive Encryption Design and Deployment Guides" (https://go.microsoft.com/fwlink/?LinkId=106052).

Configure FIPS policy for a mixed environment

The Federal Information Processing Standard (FIPS) 140-1 is a security implementation designed for certifying cryptographic software. FIPS 140-1–validated software is required by the U.S. government and requested by other organizations. The Group Policy Management Console (GPMC) provided for Windows Vista and Windows Server 2008 does not allow you to administer the FIPS setting for Windows Server 2003 or Windows XP. If you are supporting computers running those operating systems in your environment and require adherence to FIPS policy, you must configure the FIPS policy separately for the computers running Windows Server 2003 and Windows XP and the computers running Windows Vista and Windows Server 2008 because the registry location was changed with the release of Windows Vista. If your computers are running Windows XP, Windows Server 2003, or Windows 2000, the FIPS setting is applied to the following registry key: HKLM\SYSTEM\CurrentControlSet\Control\Lsa [fipsalgorithmpolicy]. If your computers are running Windows Vista or Windows Server 2008, the FIPS setting is applied to the following registry key: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy [Enabled]. If the value of the registry setting is 0, FIPS policy is turned off and not defined. If the value of the registry setting is 1, FIPS policy is turned on. The policy can be configured from the Local Group Policy Editor or the GPMC on the corresponding operating system or by running scripts to set the appropriate registry keys. The following procedure describes how to apply the FIPS policy settings through the user interface.

To configure FIPS policy settings

1. Log on to a domain-joined Windows XP or Windows Server 2003-based client computer with an account that is a member of the Domain Admins group or has equivalent permissions, and then open the Local Group Policy Editor.

2. Open the domain policy for editing.

3. Expand the policy tree as follows: Computer Configuration\ Windows Settings \Security Settings \Local Policies\ Security Options.

4. Select the System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing setting.

5. Right-click the setting, click Properties, and then click either Enable or Disable.

6. Log on to a domain-joined Windows Vista or Windows Server 2008 client computer with an account that is a member of the Domain Admins group or has equivalent permissions, open the GPMC, and then repeat the steps to configure the appropriate setting for these client computers.