Windows Server 2003 : Configuring a Windows IPSec Policy (part 1) - Using the IPSec Policy Wizard to Create a Policy

Configuring a Windows IPSec policy is not difficult—if you understand how IPSec works and take the time to learn where to enter the information the Policy Agent needs. The preceding sections provide information on how the protocol works. In this section, you'll learn how to use the Windows interface, write a policy, assign it, test it, and monitor it. Do not implement your first policy on production computers. Your first test policies should be deployed in a test environment. Start by using a local policy.

Following is an overview of the steps to configure IPSec:

1. Review configuration requirements such as the protocols to be blocked permitted or secured, and other parameters before beginning.

2. Run the IPSec Policy Wizard or create a script using netsh.

3. Assign the policy.

4. Monitor and/or test the policy.

5. If required, add additional filters and rules to the policy to complete its requirements. Test after the addition of each new item until the policy is working the way you want it.

6. If secure communications are part of the policy requirements, monitor communications during the test to ensure that communications are secured in the manner required.

7. If the policy will be used on multiple computers in a domain, use the IPSec Policy Wizard within a Group Policy Object (GPO) linked to a test OU to create a policy and assign it. Move at least two test computers to the test OU.

8. Monitor and test the policy.

9. When the policy is working the way it should, then implement it in the production network.

After successfully completing these steps, you should feel comfortable about having learned how to create and implement IPSec policies. By using this knowledge and your understanding of IPSec, you will be able to determine how you might use IPSec to protect communications on your network.

It is possible to configure an IPSec policy in a GPO and destroy communications between all of the computers affected by the GPO. If the GPO is linked to the domain controller's OU, it is entirely possible to impact domain controller communications to such an extent that you cannot correct the situation. So, be very careful with this.

1. Reviewing Configuration Requirements

When developing a policy using the wizard or by creating a script, you will need to enter information to configure a number of elements. Table 1 lists these policy elements, along with a description. Several of the elements are optional (that is, they may not be necessary for blocking and permitting policies). The type of policy within which the element must be configured is included in the "Required" column.

Table 1. IPSec policy elements

Element	Description	Required for
Rule	Rules are composed of a filter list that may have one or more filters. Each policy includes one or more rules.	Securing, blocking, permitting
Filter List	A collection of filters.	Securing, blocking, permitting
Filter Action	Determines what action is taken when an inbound or outbound packet matches a filter.	Securing, blocking, permitting
Authentication type	Selects peer authentication mode. Choices are Kerberos, shared secret, or certificates.	Securing
Integrity algorithm	Selects MD5 or SHA1	Securing
Encryption algorithms	Selects DES or 3DES	Securing
Diffie-Hellman Group	The Diffie-Hellman group is used to determine the length of the base prime numbers used in key material. Group 1 uses 768 bits, group 2 uses 1,024 bits, and group 3 uses 2,048 bits. Group 3 is only available between Windows Server 2003 peers.	Securing
Perfect Forward Security (PFS)	Ensures that keying material and keys used to protect communications are not used to generate new keys. Master Key PFS requires reauthentication as well. Session PFS does not require reauthentication, but does require a new Diffie-Hellman (DH) exchange to generate new keying material.	Securing
Key lifetime	Determines when a new key is generated. Set key lifetime to force key regeneration after a specified interval. The SA will also be renegotiated.	Securing
Session key refresh limit	Session keys are generated using the Diffie-Hellman shared secret. A session key refresh limit can be imposed (that is, you can decide how many sessions can use the same session key). Setting this limit to 1 is the same as selecting Master key PFS.	Securing
Tunnel or not	Determines if tunnel or transport mode is used. If tunnel mode is used, a tunnel endpoint must be designated.	Securing
Network application	Determines which type of network communication is affected by the policy. Choices are LAN, remote, or both.	Securing

This table demonstrates that blocking and permitting policies require few settings and, therefore, might be a good place to start your tests. You can use the instructions in the following section to create and test a blocking policy and then a permitting policy before you attempt a securing policy.

In the example, instructions for following these steps are given assuming the use of a policy. In another section, a script writing example will be provided.

2. Using the IPSec Policy Wizard to Create a Policy

Before you can create a policy, you must define what you want it to do. In this example, the end result is that a single computer can be used to remotely administer a computer using Terminal Services. All other computers will be denied access via Terminal Services. We'll step you through a simple blocking policy (block all access to the computer via Terminal Services). We'll show you how to assign and test that policy, and then we'll show you how to add a rule that allows one specific computer to access the computer using Terminal Services.

The simplest way to learn to use IPSec to protect communications is to create a simple blocking policy. You might, for example, create a policy that blocks port 3389 from any IP address and, therefore, blocks remote access using Terminal Services (including the Remote Desktop connectivity).

Start the IPSec Monitor and observe its recordings. When you have tested the policy and found it to be working, add a rule that permits the use of remote access using Terminal Services from one specific IP address. When you test the policy again, you should find it only possible to use Terminal Services to get into the machine from that specific IP address. Finally, change the filter action on the permit rule to require security. You must create a similar policy on the computer whose IP address is indicated in the policy. Be sure to inspect the IP Security Monitor to prove that encryption is taking place. Create these policies locally at each computer, not locally through Group Policy.

For these exercises the computer names ComputerA and ComputerB will be used.

2.1. Creating an MMC console

Domain-based IPSec policies can be created in Group Policy, but you should always start tests using a local policy. The first step is to load the IP Security Policy Management snap-in in a Microsoft Management Console (MMC).

Open an MMC on ComputerA by clicking Start → Run, and then entering mmc. Click the OK button. Select the File menu and select Add/Remove Snap-in. Then click Add. Under the Add Standalone Snap-ins option, select IP Security Policy Management, and then click Add. From the Select Computer or Domain dialog, accept the default "Local computer" selection and click Finish, then Close, and then click OK, as shown in Figure 1.

Figure 1. Use the Local Computer IPSec policy

Select the File menu, click Save As, and enter the name IPSecurityPolicy1. Click Save. Leave the console open for the next exercise.

2.2. Create a blocking rule

The simplest type of policy is a blocking rule, which blocks some unwanted communication. Configuration is straightforward.

On ComputerA, in the IPSecurityPolicy1 console created earlier, right-click on the IP Security Policies on the Local Computer container and select Create an IP Security Policy. Click Next on the wizard welcome page. Name the policy Block TS, enter a brief description, and then click Next. Click to deselect the default response rule.

The default response rule allows negotiation of unencrypted communication and should not be used in most cases in which IPSec negotiation is required. If it is left checked, and your rules are not properly implemented, you may inadvertently allow unsecured communications. The policy you are configuring first is a blocking policy, and unchecking the default policy will have no affect. However, you will be building on the policy and it's better to take this step now so it will not be forgotten later.

Click Next, and then click Finish. In the Block TS Properties Rules page shown in Figure 2, uncheck the Use Add Wizard box and click Add.

Figure 2. Forgo the use of the Wizard here for simple blocking policies

Select the IP Filter List tab on the New Rule Properties page, as shown in Figure 3. Click Add to create the filter list.

Name the filter list Block TS Filter. Uncheck the Use Add Wizard box and click Add to add a filter. Select Any IP Address in the "Source address" drop-down list. (This will apply the filter to traffic from any host.) Select My IP Address in the "Destination address" drop-down list, as shown in Figure 4, and then click the Protocol tab.

Figure 3. You'll need to add a filter list to build the rule

Figure 4. Select source and destination IP address

Select TCP in the Select a Protocol Type box. In the "Set the IP protocol port" area shown in Figure 5, select To This Port and enter 3389. Click OK.

Click OK to close the IP Filter Properties page. In the IP Filter Lists box, select the Block TS Filter and then click the Filter Action tab. Click to deselect the Use Add Wizard button and click Add to add a Filter Action. On the Security Methods page shown in Figure 6, click Block.

Select the General tab and enter Block TS Action as the Filter Action Name, and then click OK. On the Filter Action page, click the Block TS Action button, and then click Close. On the Block TS Properties page, click OK.

Figure 5. Set the IP protocol port

Figure 6. Select the filter action