End-to-End Security

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

IPSec end-to-end security establishes trust and security from a unicast source IP address to a unicast destination IP address (peer-to-peer). You can use this IPSec capability for secured server scenarios in which only trusted computers are allowed access to a server. In secured server scenarios, you can use IPSec to control access to all applications and services running on the server, and then either encrypt or only simply authenticate all application network traffic. The computers (IPSec peers) are authenticated through the use of Kerberos V5, certificate-based public key authentication, or — only if necessary — preshared key authentication.

Peer-to-Peer Communication

As shown in Figure 6.4, only the sending and receiving computers need to be aware of IPSec. Each handles security at its respective end and assumes that the medium over which the communication takes place is not secure. The two computers can be located near each other, as on a single network segment, or across the Internet. Computers or network elements that route data from source to destination are not required to support IPSec. A firewall between IPSec peers must be configured to forward IPSec traffic on UDP source and destination port 500, IP protocol 50 (ESP), or IP protocol 51 (AH). If network address translation is taking place between two computers, they must both support IETF IPSec NAT-T specification draft version 2. A firewall must be configured to forward traffic on UDP source and destination port 4500.

Figure 6.4   Peer-to-Peer Security in IPSec

End-to-end security is typically used to secure data sent over connections that transmit sensitive data or that might be susceptible to eavesdropping, such as:

• Servers within a corporate network.

• Servers over the Internet. For example, end-to-end security can secure traffic used by business-to-business application systems, protect file and database content as it is distributed to your business partners, or encrypt Remote Authentication Dial-In User Service (RADIUS) traffic between RADIUS clients, proxies, and servers.

• Front-end servers in a data center or perimeter network and servers inside the corporate internal network. There are two methods for securing data in this scenario:

  • End-to-end IPSec transport protection of traffic between the servers. Use IPSec to guarantee authenticity and unmodified traffic between servers, other computers using static IP addresses, or subnets. For example, IPSec can secure traffic between domain controllers, between routers connecting remote sites or forests, or between Web servers and database servers. You can use encryption if the traffic does not require inspection by an intrusion detection system between the servers.

  • End-to-gateway IPSec protection of traffic, so that the traffic is secured with IPSec, but can be fully inspected or modified by a firewall. Depending on the gateway, you can use IPSec transport mode or IPSec tunnel mode.

For any VPN scenarios, you can use the combination of L2TP and IPSec (L2TP/IPSec). For compatibility with other routers and gateways, or end-systems that do not support L2TP/IPSec or PPTP connections, you can use IPSec in tunnel mode for site-to-site (gateway-to-gateway) tunnels.

Securing an Application Server

Figure 6.5 shows end-to-end IPSec in transport mode securing an application server.

Figure 6.5   Using IPSec to Secure an Application Server

In this scenario, an application server in an internal corporate network must communicate with clients running Windows 2000 or Windows XP Professional; a WINS server, DNS server, and DHCP server; Active Directory domain controllers; and a third-party data backup server. Typically, an administrator uses Group Policy to configure and assign an Active Directory-based IPSec policy to an application server. In this scenario, the IPSec policy specifies that traffic is secured or permitted for different data paths, as described below.

Secured traffic

The users on the client computers are company employees who access the application server to view their personal payroll information and performance review scores. Because the traffic between these clients and the application server involves highly sensitive data, and because the administrator wants the server to only communicate with other domain members, he or she uses an IPSec policy that requires ESP encryption and communication only with trusted computers in the Active Directory domain.

Additionally, in Windows Server 2003, a specific group of computers can be authorized to use IPSec when either Kerberos V5 or certificates are used for IKE authentication. This capability is known as certificate-to-account mapping. When IPSec certificate-to-account mapping is used, an administrator can control which computers are authorized to use IPSec by configuring Group Policy security settings and assigning either the Access this computer from the network or the Deny access to this computer from the network logon right to individual or multiple computers, as needed. For more information, see "Public Key Certificate" later in this chapter.

Permitted traffic

Traffic is permitted for the following data paths:

• Traffic between the WINS server, DNS server, DHCP server, and the application server is permitted because WINS servers, DNS servers, and DHCP servers must typically communicate with computers that run on a wide range of operating systems, some of which might not support IPSec.

• Traffic between Active Directory domain controllers and the application server is permitted, because using IPSec to secure communication between domain members and their domain controllers is not a recommended usage due to the complexity of the IPSec policy configuration and management required in Active Directory.

• Traffic between the third-party data backup server and the application server is permitted because the third-party backup server does not support IPSec.

Example: Contoso’s Use of End-to-End Security

The fictitious Contoso Corporation implemented a mix of IPSec solutions to meet its end-to-end security needs. Using IPSec end-to-end security makes sense for Contoso because it has branches throughout the world that need to securely exchange data; messages need to pass securely and smoothly across the Internet. Also, Contoso might need to prevent network access to its servers from attackers who might penetrate their network, either through the perimeter network or by directly using a network port in any Contoso office.

Contoso considered using IPSec end-to-end security on all communications, but quickly realized that this was unnecessary and instead chose to authenticate network access to a select set of computers, and to encrypt only its most sensitive communications. Contoso uses IPSec on traffic sent between the following computers or locations:

• Servers within their network, such as between their Distributed File System (DFS) shares and all clients. Contoso used Kerberos authentication for these connections.

• Contoso headquarters servers and partner sites at which Contoso products are manufactured. In the case of the partner connections, Contoso also restricted which partner computers can connect to their corporate network. In this case, Contoso used public key certificate authentication because they shared common root certification authorities (CAs) with their partners. Their partners obtained computer certificates from third-party PKI providers. Contoso allowed only IPSec traffic to pass through the firewall when communicating with partner networks. Contoso mapped computer certificates for partner networks to a shadow computer account in Active Directory, and specified that only computer accounts from the partner networks were allowed IPSec access to their servers. To do this, they configured the Access this computer from the network logon right on each of their servers and assigned this right to computer accounts in the partner networks.

• Web server access to the data center database on cluster servers. Contoso used certificate authentication to enable IPSec-protected connections because the Web servers did not have a security domain trust with the data center cluster servers. The IPSec policy on the data center servers allowed only inbound SQL traffic from the Web servers. To allow IPSec-protected access to Web servers that are managed by a contractor and that do not run the Windows operating system, Contoso used preshared key authentication.

By protecting these connections, Contoso protected high-value communications that were critical to their business success. If they had failed to properly protect order information, competitors might have gained valuable data, or orders might have been canceled or modified by attackers.