Security Methods. On the Security Methods tab, which Figure 2, page 76, shows, you can select the IPSec protocols (and associated cryptographic and hash algorithms) that the policy agent can employ when it negotiates the SA connection. The most secure protocol (i.e., 3DES) appears at the top of the list, followed by DES, then the hash algorithms (i.e., SHA-1 and MD5). Double-click any entry in this list to view or modify the cryptographic algorithm or key lifetimes.
When the IPSec policy agent negotiates an SA, the agent offers each security method in the order that appears in this list; the endpoints select the first algorithm that they agree upon. If you include all the options in both endpoints' IPSec policies, the endpoints will always find a common algorithm. But if you restrict one endpoint to one option (e.g., ESP-3DES) and the other endpoint to a different option (e.g., AH-SHA-1), the two systems will have no algorithm in common and will never successfully negotiate an SA.
Win2K's default ordering of algorithms from most to least secure produces a steady stream of event ID 542 messages in the Application log. These messages inform you that 3DES encryption is invalid if you're exporting this system to other countries. You can eliminate these annoying events by using the Security tab's Move up and Move down buttons or the up and down arrow keys to move the 3DES entries to the bottom of the list. However, remember the dangers of altering the <Default Response> rule.
Authentication Methods. On the Authentication Methods tab, which Figure 3, page 78, shows, you can define the method that you want IPSec to use to authenticate the endpoints. If you click Add, you'll see a screen that lets you add or change authentication methods: (i.e., Kerberos, certificate, and preshared key). You can include one, two, or all three authentication options in your policy; the endpoints will negotiate until they find a common option.
You should never change the authentication settings for the <Default Response> rule because Win2K automatically includes this rule in every built-in and custom policy. If you make an error, the built-in policies won't work and you might need to reinstall the OS to restore IPSec functionality.
Connection Type. On the Connection Type tab, which Figure 4, page 78, shows, you can specify the type of connection to which the rule applies. Select All network connections for a policy that applies to local and remote connections. Select Local area network (LAN) to activate a policy specifically for LAN access. Select Remote access to apply a policy to only dial-up and VPN clients.
Built-in or Custom?
To help you implement common security scenarios, Win2K includes three built-in IPSec policies: Client (Respond Only), Server (Request Security), and Secure Server (Require Security). When you assign one of these built-in policies to a Win2K system, you define the security role for that machine.
The Client policy tells a machine to communicate without IPSec but to respond with IPSec when a machine with a more secure IPSec policy requests that it do so. In other words, when you
activate the Client policy, the client responds—with Kerberos authentication and encryption—only when another Win2K system requests a secure connection. Because the policy never initiates a secure connection request, a system with an active Client policy can also communicate with NT 4.0 systems that don't support IPSec.
The Server policy always requests IPSec but permits unsecured communication if a client doesn't respond with IPSec. This process is referred to as the fallback because the policy lets the server communicate in clear text (i.e., without authentication or encryption) when the client doesn't respond securely. When you assign this policy, the local computer always tries to establish a secure connection with the endpoint. Because the policy lets the server accept incoming clear text packets, you should enable this policy only for internal servers. If you enable the policy on an Internet-connected server, you expose the server to a myriad of Denial of Service (DoS) attacks.
The Secure Server policy requires IPSec (Kerberos authentication and encryption) for all communication. When you assign this policy, every incoming connection must first establish its identity with Kerberos, then negotiate encryption. If the endpoint doesn't communicate with IPSec, the local machine will refuse the connection. When you activate this policy, local services that can't communicate securely with other systems on the network will issue frequent warnings or errors in the event log. You shouldn't assign this policy on a DNS or DHCP server because clients might not be able to authenticate until after they resolve a DNS name query or receive a DHCP address. Likewise, if the machine needs to communicate with a nonsecure DNS, DHCP, proxy, or other resource server, services on the secure system will issue failure messages in the event log because they can't connect to nonsecure servers.
So how can you effectively use these built-in policies? Suppose you have a server that publishes active-lawsuit information, and you want to ensure that only known users and computers can access the data. To ensure that other users on the network can't read the data in transit, you need to encrypt all packets that flow to and from the legal server. To secure the server, you can activate the Secure Server policy. However, if you activate the Client policy on your Win2K workstations, the workstations will never be able to access the legal server because the Secure Server policy accepts only secure connections, and the Client policy never initiates secure connections. If you instead activate the Server policy on the workstations, they will request security from the legal server and the server will respond in kind. The Server fallback option also permits workstations to communicate with systems that aren't IPSec-enabled.
Assigning an IPSec Policy
When you assign an IPSec policy, you establish communication rules for TCP/IP traffic to and from one machine. Although you can define multiple IPSec policies on the same machine, only one policy at a time can be active. To enable an IPSec policy, start the IP Security Policies MMC snap-in. In the right pane, right-click the desired policy and select Assign; to disable a policy, select Un-assign. You'll see the status of the policy change in the Policy Assigned column. When you assign a policy on a machine that already has an active policy, the policy utility automatically unassigns the previous policy. To implement the changes when you enable or disable a policy or modify a policy's properties, you must stop and restart the IPSec Policy Agent. You can restart the IPSec Policy Agent from the Control Panel Services applet. To restart the agent from the command line, type
net stop policyagent
and
net start policyagent
If you change an IPSec policy that controls remote connections on a RRAS server, restart RRAS after you restart the IPSec Policy Agent. Otherwise, RRAS won't load the new or modified policy. You can restart RRAS from the Control Panel Routing and Remote Access applet, or from the command line, type
net stop remoteaccess
and
net start remoteaccess
Creating a Custom IPSec Policy
Although the built-in IPSec policies are a good starting point, they don't cover many site-specific security scenarios. The built-in policies are good templates but provide secure-connection solutions only for Win2K domain members. All three policies include the <Default Response> rule, which requires Kerberos authentication, but sometimes Kerberos authentication isn't an option.
Three common scenarios call for a custom policy. First, you might need a high-security policy that mandates ESP protocol and 3DES encryption to protect a server that contains confidential information (e.g., legal briefs and depositions, proprietary scientific information, human resources data). You can't use the built-in Secure Server policy because it lets endpoints negotiate DES or 3DES, and you need a custom policy that specifies 3DES only. Second, you might need a custom policy to support remote Win2K clients that connect to a Win2K RRAS server. You can't activate the built-in policies because they all specify Kerberos authentication, and Kerberos isn't available to remote clients until after they negotiate an SA. Instead, you need a custom policy that permits remote clients to authenticate with a certificate or a preshared key. Third, you might need a custom policy to establish secure communication between two Win2K servers that are members of an NT 4.0 domain. You can't use the built-in policies because you don't have a Win2K domain controller to perform Kerberos authentication. In this situation, you need a custom policy that permits the two standalone servers to authenticate with a certificate or a preshared key. For step-by-step instructions for creating and testing a custom policy for this scenario, see the sidebar "Creating and Testing a Custom Policy."
Go for the Gold
With a careful look at where sensitive and mission-critical data resides on your network, you can implement IPSec policies that protect these resources like a coat of armor. Although IPSec can't prevent stolen passwords or an unlocked CD-ROM drive, it can ensure that only known computers and verifiable users have access to LAN servers and data and that data travels safely on your network. Perhaps next year you'll be celebrating because you've reduced network abuse by 50 percent. What a goal!
Corrections to this Article:
- "Use IPSec to Protect Your LAN Resources" includes an error in the byline of the print version. Paula Sharick is the author of the article. We apologize for any inconvenience this error might have caused.