The sections that follow discuss how you can use IPSec and IPSec policy. As you’ll see, you can use IPSec with or without an Active Directory environment, but the management and distribution of IPSec policies is much easier if you have an Active Directory and Group Policy infrastructure in place.
Internet Protocol security (IPSec) is an Internet Engineering Task Force (IETF) standard (RFCs 2401-2409) for providing secure network communications over TCP/IP. IPSec provides protection against common types of attacks, such as:
Data modification, where an attacker modifies the data as it travels between the source and destination devices
Identity spoofing, where an attacker impersonates the source or destination device’s identity in order to initiate or "take over" communications
Man-in-the-middle attacks, where the attacker intercepts traffic between source and destination devices with the intent of changing the communication or otherwise interrupting traffic
Denial of Service, where an attacker tries to cause a service to fail by flooding it with network packets that are either invalid or too numerous to be handled
Data capture, where an attacker captures network traffic to obtain sensitive information
IPSec provides protection against these common types of attacks by implementing two protocols:
Authentication Header (AH) protocol, which specifies an authentication mechanism for IP traffic that prevents data modification, man in the middle attacks, and identity spoofing
Encapsulating Security Payload (ESP) protocol, which provides authentication and encryption to help with all of the above types of attacks
Because IPSec is implemented at the IP layer, upper-layer protocols are not affected by it, which makes IPSec a good solution for implementing network security without requiring applications to explicitly support it.
The Microsoft implementation of IPSec can be used with or without an Active Directory environment, but the management and distribution of IPSec policies is much easier if you have an Active Directory and Group Policy infrastructure in place. With Active Directory and Group Policy in place, you can store IPSec policies centrally and distribute them across your enterprise network. You can also take advantage of Active Directory’s built-in support for Kerberos authentication. Without Kerberos authentication in place, you would need to rely on X.509 public key certificates to provide authentication services when implementing IPSec policy.
IPSec policy is most often implemented when you need to secure network communications on an internal network. For example, if you have servers that contain very sensitive data, you might want to control which computers can talk to those servers and whether the traffic to and from those servers is authenticated, encrypted, or both. The technique used to secure network traffic in this case is port filtering. IPSec can also be used in conjunction with the Layer 2 Tunneling Protocol (L2TP) to provide secure Virtual Private Network (VPN) access across external networks.
For Active Directory–based Group Policy, IPSec policies are stored under Computer ConfigurationWindows SettingsSecurity SettingsIP Security Settings On Active Directory. If you configure one of these IPSec policies in a particular GPO, the policy is processed by computers that process that GPO.
For Local Group Policy, IPSec policies are stored under Computer ConfigurationWindows SettingsSecurity SettingsIP Security Settings On Local Computer. If you want to implement IPSec policy for computers that are not part of an Active Directory domain, define policy on the local computer.
Note
With local policy, any IPSec policies that you define are stored on that local computer but can be exported to a file for import into another machine or even to an Active Directory–based IPSec policy store. IPSec policy can be managed on the local computer using either the Local Security Policy MMC snap-in or via command line using the Netsh.exe utility built into Windows Server 2003 and Windows XP. On Windows XP, you can also use the Ipseccmd.exe tool.
IPSec can be used in a variety of scenarios where you need to protect network communications on your internal network. The most common of these are:
Server-to-server communications, where the traffic between servers needs to be private and you want to prevent unauthorized access to or interception of network packets
Server-to-client communications, where you want to control access to a server or its services or to a particular set of authorized client machines
Note
In certain scenarios, IPSec policy requires defining of a static IP address, a subnet address, or all possible addresses on machines at each end of the communication path. This requirement makes it difficult to implement IPSec policies on dynamically addressed client machines if you want the policy to affect just those machines.
Server-to-server communications across a perimeter network (also known as a demilitarized zone, or DMZ), where you need to protect and filter network traffic based on certain applications
Note
Perimeter networks are essentially subnets between your internal network and the Internet. In this environment, the security services that IPSec can provide, such as authentication and encryption of network traffic, and filtering of TCP or UDP traffic based on port numbers, can add an extra layer of protection on top of any firewall solutions you might have in place.
The scenarios in which IPSec is not well suited include:
Secure communications across your entire internal network. For large networks, using IPSec everywhere can make management of the myriad of policies you are likely to need too difficult.
Secure communications for computers using dynamic IP addressing. Using IPSec for dynamically addressed systems can present a problem if you want to use the port filtering features of the policy as these filtering rules rely on static IP addresses.
Secure communications between remote systems in which some of the remote systems are not running Windows. Using IPSec and its tunneling feature as a replacement for a VPN is recommended only when connecting to a third-party VPN server or router that does not support L2TP/IPSec.
Tip
Before the release of Windows Firewall in Windows XP Service Pack 2 and Windows Server 2003 SP1, IPSec-based port filtering was the best way to implement a centrally manageable set of firewall policies within your network. Now the port filtering capabilities in IPSec policy are less compelling and less manageable than what is available through Windows Firewall. For more information about managing Windows Firewall through Group Policy, see the "Managing Windows Firewall Policy" section in this chapter.