It seems that everyone is more concerned with network security now than ever before. One big concern is that it’s possible for anyone with a protocol analyzer to steal copies of packets as they flow across the wire, a practice sometimes referred to as electronic eavesdropping. For example, it’s possible for someone to use a protocol analyzer to intercept e-mail messages without the sender or the recipient ever knowing that prying eyes have seen the message. Fortunately, you can protect your network against this practice by creating IP security policies and using the policies to encrypt data as it flows across the wire. In this Daily Drill Down, I’ll explain how to create, implement, and test IP security policies.

IP Security Policy Management snap-in
You’ll use the IP Security Policy Management snap-in for Microsoft Management Console to configure an IPSec policy. To load this snap-in, enter the MMC command at the Run prompt to load an empty Microsoft Management Console session. Select Add/Remove Snap-In from the Console menu. On the Add/Remove Snap-In properties sheet, click Add on the Standalone tab; you’ll see a list of all of the available snap-ins. Select IP Security Policy Management and click Add. A dialog box will ask whether you want to manage the IP security policy for the local computer, the local domain, a remote computer, or for another domain. Since we’re implementing IP security on a domain basis, select the Manage Domain Policy For This Computer’s Domain radio button and click Finish, Close, and then OK. You now have the necessary means to begin working with IP security policies.

Figure A
Windows 2000 includes three predefined IP security policies.

At this point, navigate through the console tree and select the IP Security Policies On Active Directory container. Three predefined IP security policies will appear to the right: Client (Respond Only), Secure Server (Require Security), and Server (Request Security), as shown in Figure A.

Default policies
Although you can create custom IP security policies that are more strict or more lenient, the three existing policies will be sufficient for many people.

The first policy on the list is Client (Respond Only). If you implement this policy, all communications between clients will be insecure. The only time a client will carry on secured communications will be when a server requests a secure link.

The next policy on the list is Secure Server (Require Security), the most restrictive of the three predefined policies. Any communications that servers using this policy send out will be secured. Likewise, servers using this policy won’t accept inbound communications unless they are secure. This means that if you use this policy on your servers, you won’t be able to use the Client (Respond Only) policy on your workstations; you’ll have to use the Server (Request Security) policy on workstations.

The Server (Request Security) policy can be used for both servers and workstations. With this policy, the computer will attempt to secure all outbound transmissions, assuming that the machine it’s communicating with offers IP security. The basic premise of this policy is that it always requests a secure channel, but security isn’t an absolute requirement.

Anatomy of an IP security policy
Now that you know something about the three predefined IP security policies, let’s take a look at the anatomy of an IP security policy. Right-click on a policy you’d like to examine and select the Properties command from the resulting context menu. You’ll see the policy’s properties sheet. By default, the Rules tab is selected. The main portion of the Rules tab displays various types of IP traffic and the filter action associated with them. For example, the Server (Request Security) policy is set to request security for all IP traffic but to permit all ICMP traffic. Each item on the list is considered to be a rule. Each rule contains an IP filter, a filter action, and an authentication type. You can add or remove rules with the Add and Remove buttons. You can also modify an existing rule by selecting the rule and clicking Edit.

When you click the Edit button, you’ll see the Edit Rule properties sheet. By default, the IP Filter List tab is selected. This tab allows you to choose between IP traffic and ICMP traffic.

The Filter Action tab allows you to choose between Permit, Request Security, and Require Security. You can also create custom filter actions.

The next tab is Authentication Method. By default, the rules are set to use Kerberos for authentication. However, if you have a certificate authority in your organization, you can tell the rule to use a digital certificate instead of relying strictly on Kerberos. You can see an example of this in Figure B.

Figure B
You can set up a rule to use a digital certificate for authentication.

Unless you’re using a VPN, you won’t have to worry about using the next tab, Tunnel Settings. If you are using a VPN, simply specify the tunnel’s endpoint.

The final tab is Connection Type, which allows you to specify whether the rule should apply to only LAN-based connections or to all network connections.

The policy’s properties sheet also has a General tab, which contains the policy’s name and description and a field that tells Windows how often it should check for policy changes. You can also click the Advanced button to access the Key Exchange settings dialog box, which lets you control how often a new encryption key is generated. You can control the generation of new keys by minutes, sessions, or both. The more frequently new keys are generated, the more secure the session; however, more frequent key exchanges place more overhead on the server. The Key Exchange dialog box’s Methods button lets you control which encryption methods are used.

Creating a new IP security policy
Creating a new rule is almost identical to modifying an existing rule. Right-click on the IP Security Policies On Active Directory container and select the Create IP Security Policy command from the resulting context menu. Windows will launch a wizard that asks you to fill in the same basic information required for the default policies.

Applying IP security policies
It’s important to remember that IPSec policies that have been applied to a domain will override local IPSec policies for computers that are members of that domain, and that IPSec policies are hierarchical. For example, IPSec policies that have been applied to an organizational unit will override policies that were applied to a domain for members of that organizational unit. Likewise, IPSec policies applied to lower-level organizational units will override IPSec policies applied to higher-level organizational units. One IPSec policy will always override another policy; the two policies will never merge. Given the way IPSec policies function within the context of Active Directory, you can see that the easiest way to apply IPSec policies is to apply them to the highest possible level of Active Directory and to not attempt to overlap multiple IPSec policies.

When you activate an IPSec policy, you’re actually assigning the policy to a group policy object. There are some strange side effects associated with doing so, though. One is that if you delete a group policy object that references an IPSec policy, the IPSec policy will remain in effect. To keep the IPSec policy from remaining in effect, you must unassign the policy before deleting the group policy object. If you neglect to unassign the IPSec policy, the IPSec policy agent will simply assume that it’s having trouble finding the group policy object that’s associated with it and will use a cached copy. As you can see, group policy objects and IPSec policies are two separate entities that work closely with each other. To avoid problems, I recommend backing up the IPSec policies any time you back up the group policy objects.

Figure C
You can assign IP security policies through the Domain Security Policy console.

For the purposes of this example, I’ll apply the Server (Request Security) on a domain basis. To apply an IP Security policy to a domain, select Administrative Tools | Domain Security Policy. Navigate through the console tree to Windows Settings | Security Settings | IP Security Policies On Active Directory. You’ll see the available IPSec policies appear in the list to the right. Right-click on the policy you’d like to enable and select the Assign command from the resulting context menu. You’ll see the Policy Assigned column change to Yes, as shown in Figure C.

Testing your IP security policies
It doesn’t do any good to implement an IP security policy if you don’t know whether your transmissions are actually being encrypted. Fortunately, there’s a little-known utility, IP Security Monitor, included with Windows 2000 that allows you to verify that your IPSec policies are indeed working.

To access this utility, enter the IPSECMON command at the Run prompt. You can verify at a glance that the IP security policies you’ve assigned are working (see Figure D).

Figure D
You can use the IP Security Monitor program to verify that your IP security policies are working.

With the amount of sniffing and cracking going on these days, it’s critical that your data be transmitted as securely as possible. Although IPSec, in and of itself, is not enough to ensure 100 percent data security, it is certainly a solid starting block. With that starting block in place, share out your public keys between server and clients and you’ll be ready, with your well-designed IPSec policies, to do some encrypted file sharing.