Additional System Countermeasures

Although the majority of the countermeasures discussed in this guide are applied by using Group Policy, there are some additional settings that you should consider configuring on your servers. This section describes how to implement additional countermeasures, such as securing accounts. It also provides general background, references, and configuration guidance for using Internet Protocol security (IPsec) filters as an effective countermeasure against network attacks. Review the following sections for guidance about how to implement these additional settings.

Secure built-in accounts

Windows Server® 2003 with Service Pack 1 (SP1) 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 2003 are Guest and Administrator.

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 decided to 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 will be able to 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 included with the Windows Server 2003 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 needs to 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 Microsoft Windows® 95 OEM Service Release 2 (OSR2), Windows 98, Windows Millennium Edition, Windows Server 2003, Windows XP, and Windows Vista®.

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 alternate operating system by using a bootable CD-ROM or floppy 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 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 the SysKey tool to additionally secure the system account manager (SAM) database by moving the SAM database encryption key off the Windows-based computer and configuring a startup password that must be entered to decrypt the system key so that Windows can start up and then access the SAM database. For more information about this procedure, see article 310105 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=116221).
• Use EFS to encrypt user data. Instruct users to use their domain accounts and either configure no 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 need to be accessible only to a single user.

Countermeasure

Format all partitions on every server with NTFS. If you have data on existing FAT partitions, use the Convert tool (convert.exe) to non-destructively convert FAT partitions to NTFS.

Potential impact

If you use the Convert tool to convert FAT partitions to NTFS, you should be aware that the tool configures the ACLs for the converted drive to Everyone: Full Control. 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 accidentally or deliberately fill an application log file 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 included in Windows Server 2003 mitigates this vulnerability.

Countermeasure

Whenever possible, relocate 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 will be somewhat greater because administrators will have to 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 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 is not installed by default in Windows Server 2003 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 plaintext, 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. Make sure to leave write access through SNMP disabled.

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 Security tab.

4. In the Accepted community names list, click public.

5. Click Edit, and then type the new community name in the SNMP Service Community Name dialog box when it appears.

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 security 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 plaintext can be captured and used by unauthorized personnel to gain valuable information about network resources, configure an IPsec 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. Click Start, point to Administrative Tools, and then click Local Security Policy.

3. Expand Security Settings, 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 ensure that you understand that it will be difficult to manage computers on which NetBIOS 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.

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 as many remote management tools use these protocols for connection to the server, including the Active Directory Computer Management console. However, Remote Desktop connections do not use these protocols, and you can use Remote Desktop to connect to these computers for administration purposes.

Configure Terminal Services authentication and port

Terminal Services is a useful tool for network administrators because it enables remote server and end-user computer management. The Remote Desktop client installs by default on all Windows Server 2003 and Windows Vista-based computers.

Vulnerability

Windows Vista and Windows Server 2008 include Remote Desktop 6.0, which enables support for server authentication. Server authentication verifies that you are connecting to the correct remote computer or server. This security measure helps prevent you from connecting to a different computer or server than you intend to connect to. This also prevents you from unintentionally exposing confidential information. By default, server authentication is enabled for Remote Desktop connections from Windows Vista. You can install Remote Desktop 6.0 on Windows Server 2003, but it provides only server authentication features for Windows Vista and Windows Server 2008-based computers. To download Remote Desktop 6.0 on Windows Server 2003, see https://go.microsoft.com/fwlink/?LinkId=120327.

However, servers running Windows Server 2003 or earlier operating systems cannot provide their identity for verification and thus do not perform server authentication by default with Windows Vista Terminal Services clients. Computers running earlier operating systems must be updated to be able to use Transport Layer Security (TLS) to provide server authentication. If you know that the remote computer is running one of those earlier operating systems and does not support server authentication, you can avoid authentication warnings by selecting the Always connect, even if authentication fails option on the Advanced tab of the Remote Desktop Connection properties. This results in a less secure operating mode. However, you can configure your Windows Server 2003-based terminal server to use TLS to authenticate itself to Windows Vista clients.

Another vulnerability in Terminal Services is that by default all client and server communication uses the same well-known port. Terminal Services listens on TCP port 3389 by default, and all versions of the Remote Desktop clients attempt to connect to this port. An attacker who was able to spoof a legitimate terminal server could trick users and cause them to connect to the attacker's server instead of the genuine server. To achieve this deception, the attacker could alter Domain Name System (DNS) records to redirect users to their server or use some other means.

Terminal Services in Windows Server 2003 includes four levels of encryption to help secure communications between the client and the server.

Countermeasures

The following countermeasures can be used to mitigate the previously described threats:

• Enable TLS on your Windows Server 2003 computers so that Windows Vista clients can verify that the server is legitimate when they connect to it. For more information about performing this task, see Configuring Authentication and Encryption (https://go.microsoft.com/fwlink/?LinkID=18418).
• Change the port used by Terminal Services. For more information about performing this task, see article 187623 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=120330).
• Enable IPsec protection for Terminal Services to provide for additional logging and encryption. Many organizations use standardized IPsec for network security. You can configure IPsec policies on terminal servers to make sure that IPsec protects all the Terminal Services communications. For more information about enabling IPsec protection for Terminal Services, see article 816521 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkID=25061).

Potential impact

Implementation of IPsec with authentication header (AH) will have a negligible impact on computer performance, but it will require additional management of the client and server IPsec configuration. Additional overhead is also required to manage a mutual trust method between client and server computers that are used by Internet Key Exchange (IKE) security negotiation before IPsec security associations are established. The IPsec policy should be designed either to protect all traffic to the server or to require IPsec just for connections to TCP port 3389. If you require IPsec on the server side, client computers that do not have a compatible IPsec configuration and trust will be denied access.

If you change the default ports on Terminal Services servers and clients, legitimate users who do not have their client software configured to use the new port will not be able to connect to computers whose port assignments have been changed. There may be an increase in help desk calls as users are educated in how to connect to terminal servers by using the new port assignment.

Disable Automatic System Debuggers

System debuggers facilitate the troubleshooting of computers and applications. These programs gather data and present it to the system administrator or application developer while the computer is running. The Dr. Watson tool that is included with Windows Server 2003 is an automated system debugger that records information about the system state and applications that are active at the time that a program fault occurs.

The Dr. Watson tool was removed from Windows Vista and replaced with 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.

Vulnerability

Some organizations may feel that no debuggers should be installed on critical production computers. There are no known Dr. Watson-related exploits that can be run by users who do not have administrative privileges. In other words, an attacker would need to belong to the local Administrators group to use Dr. Watson as an attack tool against other users or processes. Because an attacker who has already gained administrative privileges has complete control of the computer, an attacker could still pursue other paths if you disable Dr. Watson.

Problem Reports and Solutions in Windows Vista is enabled by default, which causes it to connect to the Microsoft error reporting service over the Internet and search for updates that could resolve the issue the computer has encountered. If your organization tightly controls Internet access or deployment of updates, you can disable this feature.

Countermeasure

For instructions about how to disable the Dr. Watson system debugger, see article 188296 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=116224)).

For more information about the information collected by Windows Error Reporting in Windows Vista and instruction for disabling the features, see Windows Error Reporting and the Problem Reports and Solutions Feature in Windows Vista (https://go.microsoft.com/fwlink/?LinkId=116225).

Potential impact

No system debugger will run, and no report will be automatically created if programs crash. Systems administrators and developers will have less information available to them to diagnose the cause of such problems, and the error reporting feature will not work.

Configure IPsec policies

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 IKE.

For most applications, the Windows Firewall component provides adequate host-level protection against malicious inbound traffic. The Security Configuration Wizard (SCW) in Windows Server 2003 with SP1 greatly simplifies the setup and management of Windows Firewall settings for large deployments. IPsec should be used to enhance the security of host-to-host and host-client traffic where appropriate, and Windows Firewall should typically be widely deployed within most organizations as an additional defensive layer.

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 simply need to locate 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 be able to 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

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.

Windows Server 2003 provides the IPsec Policy Management snap-in, which is a graphical user interface (GUI) that you can use to manage IPsec policy, the IPsec Monitor MMC snap-in, and the Netsh command-line tool to show the IPsec policy filters as they are applied on the computer. Permit and block filters appear in IKE Quick Mode configuration—IKE Quick Mode generic filters are the filters as defined in the assigned IPsec policy. IKE Quick Mode-specific filters result from the application of policy to the particular IP configuration of the computer. Note that the IKE Quick Mode-specific function Find Matching Filters cannot be used to match permit and block filters, only filters that have a negotiate action.

The following terms are discussed in the rest of this section:

• Filter list. Includes ports, protocols, and directions. Filter lists trigger a decision when traffic matches something that is specified in the list. One list can contain multiple filters.
• Filter action. The required response when traffic matches a filter list. Specific actions include blocking or permitting certain traffic.
• Rule. A rule is a correlation of a filter list with a filter action.
• IPsec policy. A collection of rules. Only one policy can be active at any particular time.

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

A network traffic map helps you understand what types of network traffic enter and exit particular servers. Before you create IPsec policies, it is essential for you to understand what traffic is required for the server to function properly. Failure to do so may cause you to create filters that are too strict, which can cause application failures.

The basic steps to create a traffic map are as follows:

1. Determine the base network services that are required for the server role.
2. Identify the protocols and ports that are required by each service. This process may involve the use of Network Monitor to capture and analyze network traffic to determine destination addresses, protocols, and ports. Also, you can use tools such as the Netstat.exe command to view open ports and active connections.
3. Document the IPsec filtering rules that are necessary to allow only the identified traffic.

If you start with the most restrictive IPsec filters and open up additional ports only as needed, the highest possible level of security can be achieved with these settings. This process is much easier if you divide the services into client and server services. The server services should be defined for any service that the computer provides to other hosts.

The following table provides a sample traffic map to use as an example of creating different rules.

Service	Protocol	Source Port	Destination Port	Source Address	Destination Address	Action	Mirror
HTTP SERVER	TCP	ANY	80	ANY	ME	PERMIT	YES
HTTPS SERVER	TCP	ANY	443	ANY	ME	PERMIT	YES
DNS CLIENT	TCP	ANY	53	ME	DNS	PERMIT	YES
BLOCK EVERYTHING	ANY	ANY	ANY	ANY	ANY	BLOCK	YES

In this sample traffic map, the Web server will provide HTTP and HTTPS services to computers from any source IP address, so appropriate traffic is permitted. The ME destination is interpreted by the IPsec service to create a filter for each of the IP addresses on the computer. Each of these filters will be mirrored to permit the traffic to return to the computer from which it originated. This approach effectively means that the HTTP Server rule will permit traffic that originates from any host on any source port to connect to port 80 on the IIS server. The mirror of this rule will permit TCP traffic from port 80 of the IIS server to go to any port on any host.

A client service can be any service that the computer performs in which the policies use another host. For example, in the sample traffic map, the server may need DNS client services to perform name lookups for one of the Web applications. In this example, a filter was created to permit traffic to and from the DNS servers. Windows Server 2003 provides policy enhancements over Windows 2000 Server for this type of configuration to permit traffic to the DNS and other infrastructure servers. In Windows 2000, the IPsec policy must contain each of the DNS server's IP addresses in the policy. In Windows Server 2003, the policy can use the logical name DNS, which will be expanded into a filter for each DNS server IP address based on the local IP configuration of the server.

The mirrored block filter from Any IP to My IP Address will block all other unicast IP traffic to or from an IP address on the computer. This filter is more general than the protocol and port-specific filters that were defined for DNS, HTTP, and HTTPS. Because the default exemptions were removed for Windows Server 2003, this filter will match and therefore block outbound multicast and broadcast packets—because the source IP is My IP Address and the destination address matches Any IP address. However, note that inbound multicast and broadcast traffic is not matched by this filter. The source address would be Any IP, but the destination address of a multicast or broadcast packet is not a specific IP address on the computer—it is a multicast or broadcast IP address. Therefore, this rule will not block inbound multicast or broadcast traffic on Windows Server 2003. This filter definition is also supported by Windows 2000 and Windows XP. However, it will only match unicast IP traffic. Those platforms were not designed to match broadcast and multicast packets against IPsec filters. Therefore, outbound and inbound multicast and broadcast packets will be permitted even though this filter is applied on computers running Windows 2000 or Windows XP.

The last rule, Block Everything, demonstrates another filter enhancement for Windows Server 2003. This rule is not supported by Windows 2000 or Windows XP. This rule blocks both inbound and outbound multicast and broadcast traffic as well as all other unicast traffic that does not match a more specific filter. If this rule is used, the previous Any IP to Me rule is not needed.

It is important to note that if such a policy were enforced, the computer could not communicate to its DHCP server to renew a lease, to domain controllers, to WINS servers, to certificate revocation list (CRL) sites, or to server monitoring stations. Also, this policy does not allow remote management by administrators who use RPC-based snap-ins or a Remote Desktop client connection. Note also that if the example IIS server had two network interface cards—one for Internet access and one for internal access—all traffic over both interfaces would be filtered in the same manner. Therefore, this policy needs to be significantly customized to accommodate production environments. Network traffic should be filtered differently for the internal IP address or subnet. Filter rules that are used to require IPsec-encrypted remote management from specific management stations also should be used whenever possible so that other compromised servers cannot gain access to servers through the internal interface or capture administrative logon network traffic for offline attacks.

If a client service is required that cannot be restricted to connections with a particular destination server or a limited number of destination servers, the level of security provided by IPsec filters may be greatly reduced.

In the sample network traffic map in the following table, one rule is added so that an administrator can use a Web browser to access any Internet site for help information and to download patches. This capability requires a mirrored outbound static permit filter for TCP destination port 80 traffic.

Service	Protocol	Source Port	Destination Port	Source Address	Destination Address	Action	Mirror
Inbound ICMP for TCP PMTU	ICMP	ANY	ANY	ANY	ME	PERMIT	NO
Inbound ICMP for TCP PMTU	ICMP	ANY	ANY	ANY	ME	PERMIT	NO
Inbound IIS Server HTTP:80	TCP	ANY	80	ANY	ME	PERMIT	YES
Inbound IIS Server FTP:21	TCP	ANY	21	ANY	ME	PERMIT	YES
Inbound Terminal Server	TCP	ANY	3389	ANY	ME	PERMIT	YES
Me to Domain DCs all traffic	ANY	ANY	ANY	ME	Domain Name	PERMIT	YES
Outbound DNS UDP/TCP	UDP	ANY	53	ME	DNS	PERMIT	YES
Outbound DNS UDP/TCP	TCP	ANY	53	ME	DNS	PERMIT	YES
Outbound WINS	UDP	137	137	ME	WINS	PERMIT	YES
Outbound DHCP	UDP	68	67	ME	DHCP	PERMIT	YES
Outbound HTTP:80	TCP	ANY	80	ME	ANY	PERMIT	YES
Block everything	ANY	ANY	ANY	ANY	ANY	BLOCK	YES

Although this sample traffic map seems like a proper configuration, the result is that the entire policy now provides no security against an attacker who initiates an inbound connection from any IP address through TCP source port 80. This attacker could access any open TCP port through the inbound permit filter, and the reply is allowed through the outbound permit filter back to TCP destination port 80.

Any of the following solutions could be used to block the inbound attack:

• Use additional IPsec filtering rules to block an attacker from using port 80 to gain inbound access to open ports.
• Use a stateful filtering firewall or router to block inbound traffic from source port 80 unless it corresponds to an outbound connection.
• In addition to this IPsec policy, configure Windows Firewall on the server's external network adapter to provide stateful filtering for all outbound traffic that is permitted by IPsec filters. Because Windows Firewall is layered above IPsec, Windows Firewall must also be configured to permit TCP ports 80 and 443 inbound (although this is the default configuration).

The sample traffic map in the following table uses additional IPsec filters to block any attempts to access open ports from port 80. First, the Netstat –ano command is used to determine what TCP ports must be open on the server that the attacker could connect to. The output of this command is similar to the following:

C:\Documents and Settings\testuser.domain.000>netstat -ano

Active Connections

Proto Local Address Foreign Address State PID

TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 740

TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4

TCP 0.0.0.0:1025 0.0.0.0:0 LISTENING 884

TCP 0.0.0.0:1046 0.0.0.0:0 LISTENING 508

TCP 192.168.0.5:139 0.0.0.0:0 LISTENING 4

UDP 0.0.0.0:445 *:* 4

UDP 0.0.0.0:500 *:* 508

UDP 0.0.0.0:1026 *:* 816

UDP 0.0.0.0:1029 *:* 508

UDP 0.0.0.0:1051 *:* 452

UDP 0.0.0.0:4500 *:* 508

UDP 127.0.0.1:123 *:* 884

UDP 192.168.0.5:123 *:* 884

UDP 192.168.0.5:137 *:* 4

UDP 192.168.0.5:138 *:* 4

The rule is then defined to block the specific attack from TCP source port 25 to each open TCP port, as shown in the following table.

Service	Protocol	Source Port	Destination Port	Source Address	Destination Address	Action	Mirror
Inbound ICMP for TCP PMTU	ICMP	ANY	ANY	ANY	ME	PERMIT	NO
Inbound IIS Server HTTP:80	TCP	ANY	80	ANY	ME	PERMIT	YES
Inbound IIS Server FTP:21	TCP	ANY	21	ANY	ME	PERMIT	YES
Inbound Terminal Server	TCP	ANY	3389	ANY	ME	PERMIT	YES
Me to Domain DCs all traffic	ANY	ANY	ANY	ME	Domain Name	PERMIT	YES
Outbound DNS UDP/TCP	UDP	ANY	53	ME	DNS	PERMIT	YES
Outbound DNS UDP/TCP	TCP	ANY	53	ME	DNS	PERMIT	YES
Outbound WINS	UDP	137	137	ME	WINS	PERMIT	YES
Outbound DHCP	UDP	68	67	ME	DHCP	PERMIT	YES
Outbound HTTP:80	TCP	ANY	80	ME	ANY	PERMIT	YES
Mitigation from inbound src 80 attack	TCP	80	135	ANY	ME	BLOCK	NO
Mitigation from inbound src 80 attack	TCP	80	139	ANY	ME	BLOCK	NO
Mitigation from inbound src 80 attack	TCP	80	445	ANY	ME	BLOCK	NO
Mitigation from inbound src 80 attack	TCP	80	1025	ANY	ME	BLOCK	NO
Mitigation from inbound src 80 attack	TCP	80	1046	ANY	ME	BLOCK	NO
Block everything	ANY	ANY	ANY	ANY	ANY	BLOCK	YES

This example demonstrates how to create one-way filters to block traffic with a source port of 80 to any active ports on the computer, which would block an inbound attack. It prevents the ability to spoof a source port of 80 to connect to the ports that are required by RPC, NetBT, and SMB (CIFS).

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. For more information about defining IPsec policies for Windows Server 2003, see Windows Server 2003 IPsec Concepts (https://go.microsoft.com/fwlink/?LinkID=47739).

Negotiate IPsec protection for traffic

The IKE protocol integration with IPsec filtering permits policy-based, automatic negotiation of IPsec cryptographic protection for unicast IP traffic that matches the IPsec filters. IPsec-protected packets can either use the authentication header (AH) format or the Encapsulating Security Payload (ESP) format with security options determined by policy configuration. The use of IPsec policies to negotiate IPsec-secured transport for upper-layer protocols and applications provides the following benefits:

• Defense in depth against network attacks. IPsec is a mature, state-of-the-art, security protocol that was designed by the Internet Engineering Task Force (IETF). It allows you to add a strong layer of defense at a layer beneath all unicast IP communications to augment application-based security. In this way, IPsec defends against vulnerabilities in the security of upper-layer protocols and can significantly strengthen communications security. For example, the SMB file-sharing protocol is used extensively for Active Directory® directory service replication, file transfer, printing, and Group Policy download. However, SMB does not provide privacy. All data that is sent inside SMB is visible to the passive network observer. SMB does provide digital signing, although in some cases it is not feasible to require it because one setting affects all SMB communication paths. IPsec can be applied to help secure a specific network path or set of paths.
• Host-based authentication and encryption for all traffic between two or more computers to ensure that the administrative owner of the data retains full control of the data as it traverses the network. The data in network traffic contains core information assets that are vital and proprietary to the owners. The theft of this information as it flows through the network could cause catastrophic damage to the business or mission of the organization. When business and legal trust relationships that manage the trust and integrity of the network path are not enforced perfectly, or are silently compromised, the IPsec-encrypted communications have more protection than non-IPsec communications.
• Simple and secure firewall traversal. The many protocols that are used in communications between domain controllers, between servers, or between clients and servers are interpreted by firewalls only as IPsec ESP (protocol 50) traffic or as AH (protocol 51) traffic. The firewalls can be configured to permit only traffic for these protocols (and IKE traffic), and these protocols are hardened against attacks.
• IPsec that uses the Triple Data Encryption Standard (3DES) encryption algorithm and the Secure Hash Algorithm 1 (SHA1) integrity algorithm is certified under the Common Criteria and FIPS 140-1. Many government, military, financial, and health care institutions require that Common Criteria or FIPS 140-1–certified algorithms be used to secure their traffic. The RC4 stream cipher algorithm is used by default to encrypt traffic over most Windows protocols, such as remote procedure call (RPC), the Kerberos authentication protocol, and Lightweight Directory Access Protocol (LDAP). RC4 is not one of the Common Criteria or FIPS 140-1-certified algorithms.
• As a software-based Windows solution, IPsec is a more cost-effective way to protect host-to-host communications than a hardware-based solution. Hardware-based security solutions, such as a virtual private network (VPN) or a private leased line, may be more expensive than the use of Windows IPsec.
• IPsec can provide lower CPU utilization than protocol-specific security measures such as SMB signing. Network adapters that offload IPsec processing accelerate the cryptographic operations that are used to protect IPsec packets, minimizing the performance costs for encryption. As a result, IPsec-encrypted TCP/IP connections can achieve the same throughput as TCP/IP connections that are not encrypted with IPsec—although these adapters may add equipment costs. If such adapters cannot be used, then IPsec encryption will increase the CPU load on a domain controller. This increased CPU load may or may not require additional CPU capacity, which depends on the available CPU and the amount of network traffic. You need to conduct performance tests to assess the impact on the domain controllers in specific scenarios.

Countermeasure

IPsec is one tool that you can use to harden a server against network attack. It should not be viewed as the only tool or a complete solution. IPsec filtering was not designed to replace the need for a full-featured perimeter firewall or router filters. It is recommended only for simple packet filtering scenarios to harden clients and servers where static filters can be effective. Also, IPsec filtering was designed for a directory-based policy to apply to many computers. Therefore, the IPsec Policy Management snap-in cannot provide detailed information during the configuration process about how a policy will be applied to a specific computer. Limitations of IPsec filtering in Windows Server 2003 include the following:

• IPsec filters cannot be applied for a particular application. They can only be defined for protocols and ports that the application uses.
• IPsec filters are static. They do not provide "stateful" outbound traffic filtering. To permit outbound network traffic typically requires a static outbound and inbound permit filter. Therefore, IPsec cannot defend against an attacker that uses the static inbound permit filter to gain access to any open port. Therefore, outbound permit filters should be specific only to the IP address or range that is required.
• IPsec filters do not differentiate between different types of Internet Control Message Protocol (ICMP) messages.
• IPsec filters do not perform inspection of the contents of IP packets for the purpose of intrusion detection.
• IPsec filters can overlap, but cannot be manually ordered. The IPsec service internally calculates a weight that provides an automatic filter order. The address part of the filter takes precedence first, then the protocol, then the source and destination ports.
• IPsec filters are not interface-specific. They can be configured to be IP address-specific, but all traffic on each interface will be matched against the filter list.
• IPsec filters cannot be explicitly configured as inbound or outbound. The inbound and outbound direction is automatically determined based on the addresses that are specified in the filter. In some cases, both inbound and outbound filters are generated automatically.
• IPsec policy does not support duplicate filters.

Although Windows Server 2003 substantially improved the performance of IPsec filtering, host-based filtering may add CPU load for very large traffic volumes. An optimized front-end router or firewall may provide faster filtering of traffic.

When IPsec (or other network device) filtering blocks network traffic, unusual application behavior and event messages may result. IPsec filtering does not provide an easy-to-read log of dropped inbound and outbound traffic. Network Monitor (Netmon) captures of network traffic cannot view outbound traffic that is blocked. Although Netmon can view inbound traffic that is blocked, there is no indication in the capture file that a particular packet is dropped. Effective diagnostics depend upon the knowledge of normal application behavior, events, and network traffic flows when IPsec policy is not assigned.

Furthermore, the proper design of IPsec filters for application traffic may depend upon detailed analysis of network traffic flows to understand how the application uses the network. For example, the SMB protocol uses TCP port 139 for file transfer, file sharing, and print sharing. If this port is blocked by IPsec, SMB can also use TCP port 445. Another example is when an application requires multiple network traffic flows to different destinations. SMB and other protocols typically authenticate the user, which can transparently cause the computer to locate and exchange Kerberos traffic with the domain controller. The Kerberos protocol uses DNS UDP 53 or TCP 53 to discover a list of domain controller IP addresses, then LDAP UDP 389 and UDP and TCP port 88 to query any of the domain controller IP addresses. Therefore, a print failure may actually be caused by a blocked packet to the domain controller. Some protocols, such as RPC, use a wide range of TCP ports that are dynamically determined when a computer starts, or at the time an application runs, which means that RPC applications cannot be effectively controlled by static filters on ports except when the RPC application provides the configuration to require the use of a static port.

Windows Server 2003 provides an initial startup policy that the IPsec driver uses when loaded by TCP/IP during computer startup. When the IPsec service starts, it immediately applies persistent policy. Then, when a local or domain policy assignment can be determined, the service applies this policy assignment in addition to the persistent policy. Therefore, a Netsh IPsec script that configures a secure default persistent policy (for example, block all traffic except management traffic) can provide protection during transition from startup to local or domain-assigned IPsec policy.

Windows Server 2003 includes the Windows Firewall service, which performs stateful filtering for outbound traffic and provides basic controls for inbound access to ports and ICMP message types. Windows Firewall also provides a readable log of inbound and outbound blocked packets. Administrators should investigate Windows Firewall capabilities to determine if it better suits their needs for filtering traffic. The stateful filtering that is provided by Windows Firewall can be used in combination with IPsec filtering to protect scenarios in which IPsec must be configured to use mirrored outbound filters to permit traffic. Front-end router or firewall filtering should be used as the first line of defense when feasible.

A host-based intrusion detection system and other antivirus systems are worth consideration to detect and potentially defend against infection and attacks within permitted network traffic and applications. A host–based or edge firewall may provide the best solution for complex filtering needs.

Windows Vista and Windows Server 2008 include an improved Windows Firewall with Advanced Security, which provides host-based, two-way network traffic filtering for a computer. Windows Firewall with Advanced Security also works with Network Awareness so that it can apply security settings based on the type of network to which the computer is connected. Windows Firewall and IPsec configuration settings are integrated into a single snap-in named Windows Firewall with Advanced Security.

Potential impact

Although IPsec end-to-end protection can greatly enhance security, if you deploy IPsec-encrypted communications on your network, you will incur additional training and administrative costs. It may also involve additional hardware costs if you need to 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.

Implementation of IPsec with AH introduces new overhead to manage a client/server IPsec configuration as well as to manage a mutual trust method between client/server computers. If the two computers are always in the same domain or mutually trusted domains, then Group Policy can deliver the necessary IPsec policy settings and Kerberos authentication can establish trust for IPsec security associations. If computers are not able to use Kerberos authentication, then either computer certificates or a preshared authentication key may be used. However, we do not recommend preshared authentication keys because the key value is stored unprotected in the IPsec policy configuration.

Although the local IPsec policy can be read only by the administrators who defined the policy, policy that is stored in Active Directory needs to 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 would be denied to client computers that did not have a compatible IPsec policy configuration and mutual trust method.

Configure Windows Firewall

An Internet firewall can help prevent outsiders from accessing your computer through the Internet. Windows Server 2003 with SP1 includes the Windows Firewall, a built-in firewall that can provide for many organizations an additional layer of protection against network-based attacks such as worms and denial of service attacks.

To activate Windows Firewall in Windows Server 2003 with SP1

1. Log on to the server computer as an account that is a member of the local Administrator group or has equivalent privileges.

2. Click Start, and then click Control Panel.

3. Click Windows Firewall.

4. Click On (recommended).

5. If necessary, click the Exceptions tab, and configure exceptions for protocols that you want to allow through the firewall.

6. Click OK to activate Windows Firewall.

Windows Firewall in Windows Server 2003 with SP1 is intended only as a basic intrusion prevention feature. Windows Firewall prohibits the gathering of data about the computer and blocks unsolicited connection attempts. However, Windows Firewall does not do extensive outbound filtering.

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 make sure 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, see Introduction to Windows Firewall with Advanced Security (https://go.microsoft.com/fwlink/?LinkId=116226).

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 Group Policy Object 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 Group Policy Object 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.