8.4 Using IPSec Correctly

IPSec can be used whenever you need to secure data, which you'll pretty much always want to do. The natural inclination of a security-minded administrator is to simply sign and encrypt all traffic on the network, which isn't a bad inclination. With security, erring on the side of caution is desirable. However, IPSec cannot be deployed this way within most organizations.

I've examined the way IPSec works and shown that there is a significant amount of work that the system must do to secure network traffic. If some of that traffic is already secured through another mechanism, such as SSL, what good will IPSec do? Securing data twice sounds fantastic but is simply repetitive and usually offers no more protection than doing it once. Also, some network traffic is inconsequential to security. For example, if an intruder learns that your corporate standard homepage is www.msn.com, they gain no advantage. So using IPSec becomes a balance between security, necessity, and the availability of system resources to implement it.

The best strategy is to ensure that any sensitive network traffic is encrypted and any traffic that isn't sensitive, but may be altered en route, is signed. You must also consider the impact on system performance to all computers that will use IPSec. For example, any system that will use more than occasional IPSec, such as a central server that stores sensitive data, should be sized to provide the extra resources necessary?more memory, faster processors, and so forth. If possible, network cards that perform IPSec functions on the card should be used. These cards remove most of the work from the computer's CPU and provide very efficient IPSec processing.

Some examples of good judicious use of IPSec might include:

Required encryption of all network traffic of a human resources database server. This helps provide confidentiality of the data on the network.
Requiring data signature between trusted clients in a point-of-sale scenario. Although the data of each transaction may not be considered confidential, you may need to ensure its accuracy and protect against attackers who could modify that data in transit.
Encrypting all data transported through an Internet-based router-to-router tunnel. Data transfer on either network may not require security, but the data in transit must be secured. This is often the case with branch offices.
Blocking all communication to a server except over a desired port. IPSec can be used as a very effective policy-based port filter and allow/deny network traffic based on its rules. It doesn't always have to negotiate security; it can simply disallow traffic that doesn't meet specified criteria. For example, a computer designed to allow only Telnet traffic might allow network traffic on port 23 without negotiation and block all other ports. This minimizes the exposure of the computer to attacks that come through other network ports.

8.4.1 Example: Woodgrove Bank Corporate Accounts Payable

Woodgrove Bank is headquartered at Woodgrove Tower in Charlotte, N.C. They own the entire building and use about 75% of the office space for their own business. The other 25% is leased to various companies.

Heide Haupt, a user in corporate accounts payable, has an office on the 30^th floor of Woodgrove Tower. She accesses data on the accounting server Wood-Acct-01 that is located in the data center. This data is considered confidential by the bank as it contains corporate financial information as well as personal employee data. Heide is educated in safe data management practices and ensures that the data remains stored on the file server at all times. She does not copy it or print it locally.

An intruder who wants to obtain corporate data learns that there is a network jack in a storage closet on the 30^th floor. He gains unnoticed entry and installs a network monitor device to record all data on the network. This includes the data Heide is manipulating.

Don Fink, our IT security manager, wants to ensure that all traffic in and out of Wood-Acct-01 is secured using IPSec. He wants to require data encryption and packet signing and refuse access to any client unable to comply with this requirement. Because Woodgrove Bank uses Active Directory, he wants to allow Kerberos authentication to prove the identity of all parties for IPSec.

8.4.1.1 Client IPSec configuration through Group Policy

Don must configure the IPSec Group Policy for two objects, the server and the clients. He must require the server to secure the communication and also allow the clients to communicate securely when requested. Don configures the clients first. All client computer accounts reside in the Client Computers OU in the Woodgrove Bank domain. Don implements the following configuration:

Start Active Directory Users and Computers snap-in.
Expand woodgrovebank.com, right-click the Client Computers OU, and click Properties.
Click the Group Policy tab and choose New to create a new GPO. Don names this new GPO IPSec Policy.
Click Edit to edit the new policy.
Navigate to IPSec Policy Computer Configuration Windows Settings Security Settings, then click IP Security Policies on Active Directory. This is shown in Figure 8-2.
In the right pane, right-click Client (Respond Only) and click Assign. Verify that the value under Policy Assigned changes to Yes, as shown in Figure 8-3, which indicates that this policy is active. Note that only one policy can be assigned in an IPSec policy, so trying to assign additional policies will unassign the desired one.

Figure 8-2. The default configuration for IPSec is to be disabled

Figure 8-3. The Client (Respond Only) IPSec rule is enabled

Don has now assigned an IPSec policy setting, which will be picked up by the IPSec Policy Agent and sent to the IPSec driver. This enables Don's IPSec settings on the computers.

8.4.1.2 Server IPSec configuration through Group Policy

Don must now configure the server Wood-Acct-01. I'll assume the server is in an OU called Accounting Servers and that all servers in this OU have the same security requirements as Wood-Acct-01. If that were not the case, Don could easily move the computer accounts to appropriate OUs to apply policy correctly at those OUs.

Start Active Directory Users and Computers snap-in.
Expand woodgrovebank.com, right-click the Accounting Servers OU, and click Properties.
Click the Group Policy tab and choose New to create a new GPO. Don names this new GPO IPSec Accounting Server Policy.
Click Edit to edit the new policy.
Navigate to IPSec Accounting Server Policy Computer Configuration Windows Settings Security Settings, then click IP Security Policies on Active Directory.
In the right pane, right-click Secure Server (Require Security) and click Assign. Verify that the value under Policy Assigned changes to Yes.

Note that the Secure Server (Require Security) default configuration allows communication using ESP but not AH as displayed in Figure 8-4. Three settings that may not be self-evident should be explained:

Permit: Configuring a security method for permit essentially removes IPSec from network traffic that matches the pattern we've identified in the previous dialog box. IPSec will permit this traffic to continue on the TCP/IP stack.
Block: Block is the opposite of permit. Whether security negotiation takes place or not, any traffic that matches the identified criteria will be blocked. This traffic is simply erased from memory.
Negotiate: The most complex and useful setting is negotiate. When traffic of the configured pattern is encountered and negotiate is set, IPSec attempts to negotiate a session between computers. This means it will check for an existing SA, and if none exists, IKE will attempt to make a connection and establish settings and a shared secret key.

Figure 8-4. The Secure Server IPSec rule does not apply AH because it is redundant with ESP

As discussed earlier, ESP results from negotiated shared secret keys and therefore provides encryption. However, Don wants to customize this policy to use both encryption (ESP) and signing (AH) to ensure that source and destination addresses are never spoofed.

He can customize this policy as follows (assuming he continues following steps from the point he left off earlier):

Right-click Secure Server (Require Security) and click Properties.
On the IP Security rules list, select All IP Traffic and click Edit. Click the Filter Action tab, select Require Security, and then click Edit. These options should look hauntingly familiar, as they are identical to the settings we saw in Figure 8-4.
Click Negotiate Security, and then click Add to create a new security method.
Click Custom, then click Settings to display the Custom Security Method Settings page as shown in Figure 8-5.

Figure 8-5. The Custom Security Method Settings property page

Check the "Data and address integrity without encryption (AH)" option, then choose the desired hash algorithm. You can also choose other advanced encryption options on this page, as well as choose the interval at which to generate a new shared secret key during IPSec communication. Then click OK.

You can configure an almost infinite number of options for IPSec, including the ones in this dialog box. The settings appropriate for your environment should be carefully analyzed and documented as discussed in Chapter 15 before you deploy them.

Click the security method you just created, and then click Move Up until this method appears at the top of the security method preference order.
Click OK to all open dialog boxes until the Group Policy Object Editor appears, then close it to save all changes.

At this point, the policy has been edited but not assigned. Unless you specifically right-click this policy and click Assign, this policy will not become active. This is intentional, as it allows you to make changes to many policies without having to implement them every time. Only policies that are explicitly assigned will take effect.

Remember that the policy changes used to deploy IPSec must be replicated and applied to all affected computers before they will take effect. As I discussed in Chapter 5, that can take up several hours.

Although you can force a client update of Group Policy with the gpupdate.exe command, you should do so only in a testing environment in which time is constrained. In a production deployment, allow Group Policy to update normally.

8.4.2 Verifying IPSec Operation

After the clients and server have been configured for IPSec, a prudent administrator must confirm that the desired security is in place and working correctly. This is important because assuming a security implementation worked without verification could leave the network in an insecure state indefinitely, and improper configuration may not always be apparent. For example, IPSec may negotiate to use unprotected communication, which will cause nothing to fail but will not result in the desired security level.

A number of techniques and tools can be used for this purpose. Although IP Security Monitor is the simplest and easiest to understand, I'll provide details on other tools and techniques. You should use whatever method you're most comfortable with.

8.4.2.1 Verifying IPSec operation with IP Security Monitor

You want to confirm that all communications with an IPSec-configured computer are secure. After all, verification is the last and most important step in applying security. You can use a new Windows Server 2003 tool, the IP Security Monitor MMC snap-in, to get detailed information about the activity and state of IPSec. This tool provides a great deal of useful information in a simple format.

The IP Security Monitor snap-in replaces the IPSecMon tool that is included in Windows 2000.

To use the IP Security Monitor to verify the state of IPSec on the server, you should perform the following tasks while logged in as an administrator on the desired computer:

Click Start, click Run, type mmc, and then press Enter.
Click File, click Add/Remove Snap-in, and then click Add.
Select IP Security Monitor from the list of snap-ins, and then click Add.
Click Close and then click OK.
Double-click IP Security Monitor, double-click the local computer's name, and then click Active Policy. The active IPSec policy is displayed in the details pane as shown in Figure 8-6.

Figure 8-6. IP Security Monitor showing no policy assigned
To get more details about what IPSec activities are occurring on this server, you can explore the Main Mode and Quick Mode nodes.
To see a list of the computers currently communicating with this one via IPSec, navigate to the Security Associations container as shown in Figure 8-7.

Figure 8-7. No Security Associations means this computer isn't using IPSec at all!

Because no policy is set, no security associations are listed in the details pane. As IPSec policy is implemented and secure connections are established, this list will be populated with the detailed information about each connection.

The IP Security Monitor snap-in displays a great deal of information. Detailed analysis can be accomplished with this tool to verify correct operation, both initially and over time. Within the context of an initial deployment, the tool can be used to quickly determine whether IPSec policy has been deployed correctly and whether computers are using the policy to communicate securely.

8.4.2.2 Verifying IPSec operation with other tools

Several other methods can be used to determine whether IPSec is working correctly. These methods include both specific tools and general troubleshooting techniques.

8.4.2.2.1 IPSecCmd.

This command-line tool can be used to either verify current IPSec status or configure local IPSec policy. It is not installed by default, as it's part of the Windows Server 2003 Support Tools installation. For information on installing support tools, see the Help and Support Center in Windows Server 2003.

The following command is the most appropriate and comprehensive for displaying all IPSec configuration information for the local computer:

c:\> ipseccmd.exe show all

8.4.2.2.2 Netsh.

This powerful tool is used to configure and diagnose a wide range of networking components. It can gather and display an enormous amount of data about IPSec statistics and configuration. It is similar to IPSecCmd in that it is command-line based and provides much of the same information, so you can use either tool. The following command shows all static IPSec information about the computer, including long-term configuration information and IPSec rules:

c:\> netsh IPSec static show all

The following command shows all dynamic information about the computer, including current status and statistics:

c:\> netsh IPSec dynamic show all

8.4.2.2.3 Other basic techniques.

You can indirectly examine the behavior of IPSec with the following:

Examine the Application and Security event logs for IPSec-generated events. These are often very self-describing and tell you exactly what failed and why. There are also links from most events to the Microsoft Knowledge Base, which contains detailed descriptions of common IPSec events and methods to troubleshoot those events.
Connect to the computer using a Windows 98 or Windows Me client. By default, these clients cannot communicate with IPSec and will fail to establish a connection. The error messages will vary depending on the operating system and the application that requests the connection, making it harder to specifically identify communication failures as an IPSec-based problem.
Connect to the computer from a non-Windows computer that cannot use IPSec. The results should be the same as with Windows 98 or Windows Me.
Enable detailed IKE logging in the Security Log by setting the registry value
```
 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Audit\DisableIKEAudits
```
to 1. This may quickly fill your Security Log, so when you've analyzed the data, you should disable this logging by changing the value to 0.
Use a network capture device or software package to capture network traffic flowing into and out of the desired computer. You should see the ISAKMP and Oakley exchanges and then the traffic should be encrypted (except for the header information).

You can make other configuration changes to create more detailed and extensive IPSec logs. However, these should be used only for bug identification and troubleshooting.

If you see clear communications traffic, you should verify that the IPSec group policies you configured were created properly and assigned to the correct OUs. If these are verified as correct, you should ensure that Group Policy has replicated to all domain controllers and applied to the desired computers. A common reason IPSec fails is the failure of Group Policy to apply the IPSec policy to a computer. For more information on Group Policy, see Chapter 5.

8.4.3 Example: Restricting a Server to Highly Secure IPSec Communication

You may have a computer on your network that contains only highly sensitive data. For that single computer you may want to configure IPSec in a bit more restrictive way. You decide to implement the following administrative policy and apply it to that sensitive computer:

IPSec keying material cannot be reused. This limits the success of an attacker who learns one session key by changing the key to one he cannot figure out based on the older key. It is implemented through perfect forward secrecy (PFS), which is the label for the criteria that IPSec uses to determine how to derive keys.
No communication with this computer can occur unless it is secured with IPSec.

This type of highly restrictive policy can be put in place with a minimum of effort, as I'll describe next.

8.4.3.1 Creating a policy to use perfect forward secrecy

I'll need to begin by creating a new IPSec policy in Active Directory. This new IPSec policy must enforce both session key and master key perfect forward secrecy (PFS) to ensure key material is not reused. Create this type of policy with the following steps:

Ensure the desired computer is in its own organizational unit (OU) or is in one with other computers that will share the same highly restrictive IPSec policy.
Create a new Group Policy Object and navigate to the IP Security Policy folder. For detailed instructions, follow the instructions provided in the earlier "Server IPSec configuration through Group Policy" section, up to step 5, to reach the IP Security Policies on Active Directory container for the desired OU.
Right-click in the details pane, and then click Create IP Security Policy, which will launch the IP Security Policy Wizard.

Follow the wizard to create the new policy using the settings in Table 8-1.

Table 8-1. Highly restrictive IPSec policy settings
IP Security Policy Wizard setting	Value
Name of policy	Highly Restrictive
Activate the default response rule	Selected
Default Response Rule Authentication Method	Active Directory default (Kerberos v5 protocol)
Warning (if prompted)	Yes
Edit properties	Selected

The Highly Restrictive policy detail will be shown. Click the General tab, then click Settings. The Key Exchange Settings dialog box will be displayed as shown in Figure 8-8.

Figure 8-8. The IKE Key Exchange Settings page
Select "Master key perfect forward secrecy (PFS)," and then click OK.
Click the Rules tab and then click Edit to display the Edit Rules Properties dialog box.
Remove all security methods listed except for the Encryption and Integrity methods by selecting each and clicking Remove.
Click "Use session key perfect forward secrecy (PFS)" to configure the security method as shown in Figure 8-9, and then click OK.

Figure 8-9. The security method shown has session key PFS configured and is the only available method
Right-click the Highly Restrictive policy and click Assign to activate it.
The new IPSec policy is now configured with restrictive PFS settings and will accept only secure connections with our defined parameters.

8.4.3.2 Configure IPSec to not allow any traffic to bypass its filter rules

By default, several types of network traffic can bypass IPSec filters and access the network insecurely. This has been done in the past to avoid problems when IPSec tries to secure network traffic that cannot be secured or is being relied on to authenticate for IPSec?a "chicken and the egg" scenario. In Windows Server 2003, the default behavior is not to allow any network traffic to bypass the IPSec filter. However, if you are using servers running Windows 2000 that will be impacted by this new highly secure IPSec policy, you will want to ensure that they also secure all traffic. This can be done by editing the registry on those computers, either through Group Policy or directly using Regedit. You want to ensure that the registry value specified in Table 8-2 is configured under HKLM\SYSTEM\CurrentControlSet\Services\IPSEC.

Table 8-2. Registry value to require all communication to use IPSec
Field	Value
Value Name	`NoDefaultExempt`
Data type	`DWord`
Value Data	3

This setting forces IPSec policy to override all communication and apply to all network traffic, no matter its type. However, there is always one exception to the NoDefaultExempt setting. IKE traffic, using UDP port 500, must always be exempt from the IPSec filter. Without IKE negotiating its own security, IPSec would be unable to acquire a security association and would fail to communicate with all hosts.

8.4.4 Example: Using IPSec with a Non-Microsoft Client

Not all clients that want to connect to Windows Server 2003 computers are Microsoft-based clients. Kathie Flood, another user at Woodgrove Tower, uses a Unix-based desktop computer at work. She must access files stored on a secure Woodgrove Bank server in the Red Team Servers OU. Many of the employees in Kathie's department are in the same situation, but this is a small group within the bank. Kathie's computer does not participate in domain-based security, so Don has no way to send appropriate settings to her computer. But he can configure the server in a way that will make it easy for Kathie to connect to the server securely while still providing security for all connections to the server.

8.4.4.1 Configuring IPSec for certificate-based authentication

Don chooses to obtain a public key certificate for Kathie and her coworkers and for the servers using IPSec. This is the best solution for clients that may not be able to perform implementation-specific authentication such as NTLM or Kerberos but can still use certificate-based authentication. Don configures IPSec on the Red Team Servers OU as follows:

Install the trusted root certificate in Active Directory or on the local computer. Details of this process can be found in Chapter 9.
Create a new group policy for IPSec settings and edit it in the Group Policy Object Editor. Call the new policy Red Team IPSec Policy and create it in the Red Team Servers OU.
Navigate to the IP Security Policies container, right-click the container, and choose Create IP Security Policy.
Follow the wizard to create the new policy using the settings in Table 8-3.
Right-click PKI IPSec Policy and click Assign. Verify that the value under Policy Assigned changes to Yes.

Table 8-3. IPSec settings for certificate-based authentication
IP Security Policy Wizard setting	Value
Name of policy	PKI IPSec Policy.
Activate the default response rule	Selected.
Default Response Rule Authentication Method	Use a certificate from this certification authority (CA).
Warning (if prompted)	Yes.
Select Certificate	Select the Woodgrove Bank root CA certificate or another root CA certificate that all IPSec certificates chain to.
Edit properties	Deselect.

A certificate and private key must be installed on Kathie's computer and Wood-Acct-01 to allow IPSec to authenticate each to each other. Because the installation on Kathie's computer is dependent on the exact type and version of IPSec software used, as well as the specific type of Unix, the exact steps are not provided here.

Once Kathie's computer is configured for IPSec, it can communicate securely with the server. Other clients can still communicate with the server, even without an appropriate certificate, because they authenticate via Kerberos.