IPSec and Authentication Guard Administrative Ports

IPSec policies allow public access but protect your server

In "Protect Private Ports with IPSec," April 2002, Instant Doc ID 24273, I discussed IP Security's (IPSec's) components. I showed you how to use filter lists to look for certain types of traffic and assign a filter action to permit, block, or negotiate a secure connection that includes authentication, integrity-checking, and encryption. This month, I discuss the three authentication options—Kerberos, preshared-secret-key, and certificate-based authentication—and show you how to use IPSec to protect your Web server's private (i.e., administrative) ports, such as those for Windows 2000 Server Terminal Services, NetBIOS, and FTP.

If your server is part of an Active Directory (AD) domain and the computers that need to connect to a given private port on your server run Win2K or later and are within the same forest as your server's domain, you can specify Kerberos as the authentication method in your rule—and you've done all you need to do about authentication. Win2K will simply use Kerberos based on the computer accounts AD already contains. If you want to limit access to a subset of computers in your AD forest and those computers have static IP addresses, you can use specific source address ranges in your negotiated security rule. Then, only trusted computers within the allowed subnets can connect to your private ports. This technique is particularly useful in a demilitarized zone (DMZ) in which all the members are frequently members of a forest created specifically for the DMZ. By creating a forest for the DMZ, you can ensure that any computer in the DMZ receives traffic from only those systems or devices that are part of the security design.

However, if your trusted computers aren't limited to a few static IP addresses or at least subnets, source filtering won't work. Kerberos isn't an option if your Web server isn't a member of an AD domain, the other computers aren't part of the same forest, or the other computers run a pre-Win2K OS. Your alternatives are then preshared-secret-key or certificate-based authentication.

Preshared-secret-key authentication is the quickest authentication method to set up because users simply need to type in the same string of characters as the key on each computer. However, the preshared secret key is stored in the clear (i.e., in plain text) in the registry, which makes the key more vulnerable to theft than certificate-based private keys are. If a preshared secret key is compromised, you must change the key on every computer on which you've used it, whereas if a private key is compromised, you can simply revoke its associated certificate. If you administer a few computers, you can overcome this drawback to preshared secret keys by giving each client computer a different preshared secret key. However, you need to create a separate negotiate-security rule on your Web server for each client's key.

Certificate-based authentication doesn't require AD to let you use IPSec, and you get all the benefits of public key infrastructure (PKI). To use certificate-based authentication, you must specify a trusted Certificate Authority (CA) in the IPSec policy, and you must request and install a certificate from that CA on the Web server and on all the other computers that will be communicating with the Web server through administrative ports.

A Practical IPSec Policy
I'll show you how to set up a simple IPSec policy that lets port 80 and port 443 traffic into your Web server without applying IPSec but requires that computers connecting to any other port authenticate with preshared-secret-key authentication and subsequently encrypt any traffic. Such a policy wraps a layer of protection around all the ways into your server other than HTTP and HTTP over Secure Sockets Layer (HTTPS)—which IPSec can't protect because a typical public Web server must accept connections to these ports from anyone on the Internet.

To set up this policy, first open the Microsoft Management Console (MMC) IP Security Policy Management snap-in, right-click IP Security Policies on Local Machine, then select Create IP Security Policy to launch the IP Security Policy Wizard. On the wizard's opening screen, click Next. On the screen, leave the default name—New IP Security Policy—and enter

Limit and encrypt communications to authorized computers only(except ports 80, 443)

in the Description field. Click Next again. Clear the Activate the default response rule check box, click Next, then click Finish.

In the resulting New IP Security Policy Properties dialog box, which Figure 1 shows, the list of IP Security Rules is empty except for the Default Response rule, the check box for which should be clear. Now, you must create a rule that limits all IP traffic to computers on which you've configured the same preshared secret key. Then, create another rule that permits connections to TCP port 80 and port 443 so that the public can still connect to your Web server. Click Add to launch the Security Rule Wizard.

Rule 1. Click Next on the wizard's first three screens. On the Authentication Method screen, select the Use this string to protect the key exchange (preshared key) option, then enter a long key made up of random characters, such as the preshared key that Figure 2 shows. Microsoft recommends a key of at least 20 characters, but you can enter more than 1000 characters. The length of your key doesn't affect performance. (At this point, copy this key into a text file you create on a disk. You'll need the disk to configure the same key on all other computers that will be communicating with your server.) Click Next. On the IP Filter List screen, select the All IP Traffic option as the filter list. All IP Traffic is a prebuilt filter list that's applied to all traffic not filtered by more specific filters. Click Next. On the Filter Action screen, select the Require Security option as the filter action. This prebuilt filter action requires that a secure connection be negotiated with the client computer. Click Edit to view the security methods used in the negotiation, which Figure 3, page 12, shows. In Figure 3, you can see that the filter action list begins with the most secure filter action, Triple DES (3DES) encryption and Secure Hash Algorithm (SHA) for integrity-checking, and ends with the least secure filter action, single DES encryption and Message Digest (MD)—in particular, MD5.

Usually, another Win2K computer configured with the default response rule will use the strongest method, but to ensure that the computers use the strongest method, you could create a custom filter action to require the desired security method. Click OK to return to the Security Rule Wizard. Click Next, then click Finish. The New IP Security Policy Properties dialog box now shows the new All IP Traffic rule, as Web Figure 1 shows. (You can access Web Figure 1 at http://www.windowswebsolutions.com, InstantDoc ID 24481.)

Rule 2. Now you need to create the second rule, which will let the general public bypass IPSec and connect to your site by using HTTP and HTTPS. In the New IP Security Policy dialog box, click Add, then click Next four times. The authentication method you choose doesn't matter because this rule will simply permit traffic. However, if your server isn't a member of a domain, don't use Kerberos. (Kerberos would evoke an error message.)

When the wizard asks you to select a filter list, click Add to open the IP Filter List dialog box. You'll need to create a new filter list that looks for traffic on TCP port 80 and port 443.

In the IP Filter List window, enter

Incoming HTTP and HTTPS connections

in the Name field. You'll need to create two filters—one for port 80 and one for port 443. Click Add to open the IP Filter Wizard, then click Next. On the IP Traffic Source screen, select Any IP Address from the Source address drop-down list, then click Next. On the IP Traffic Destination screen, select My IP Address from the Destination address drop-down list, then click Next. On the IP Protocol Type screen, select TCP, then click Next. On the IP Protocol Port screen, select the To this port option, enter

80

in the corresponding field, then click Next. On the wizard's last screen, select the Edit properties check box, then click Finish.

When the Filter Properties dialog box appears, click the Description tab, enter

Incoming HTTP connections

in the Description field, then click OK. The new port 80 rule appears on the IP Filter List screen. Now, add another rule just like the first rule, but when you select the To this port option, enter

443

in the corresponding field and enter

Incoming HTTPS connections

in the Description field. Figure 4 shows the updated IP Filter List dialog box. Click Close to return to the Security Rule Wizard.

On the wizard's IP Filter List screen, select your new filter list, then click Next. Select the filter action Permit, click Next, then click Finish. You should now have a policy that resembles the policy that Figure 5 shows. Click OK.

Put Your Policies into Effect
You must now use the same preshared secret key that you used to create the first rule to configure any other computers or workstations that will communicate with your server through ports other than with a Web browser. (The rule for Incoming HTTP and HTTPS connections will govern Web browser traffic.) On such computers, open the Control Panel Administrative Tools applet, then double-click Local Security Settings. Create a policy that uses the same preshared secret key as the one you configured on the server. Simply use the prebuilt Dynamic Default Response rule that Web Figure 2 shows. Close the Secure Communication with Web Server Properties dialog box. Then, right-click the new policy and select Assign. Type

secedit /refreshpolicy machine_policy

at a command prompt to refresh Group Policy and thus start using this new rule.

Finally, return to your Web server and assign the policy, which will refresh Group Policy and put the new rule into effect. You should now be able to connect to Terminal Services, FTP, and other services on your Web server from computers on which you've entered the preshared key but not from computers on which you haven't yet entered the preshared key. You should still be able to access the Web server with your browser from any computer.

Administrative Doors: Closed
IPSec will now protect your Web server from attacks that occur at any of its administrative doorways. Because IPSec requires strong authentication and is immune to IP spoofing, this approach is much stronger than blocking access to certain ports by IP address. However, intruders can still attack your Web server through the front door—HTTP. In a future issue, I'll discuss how to protect your Web server against intruders who use this route.