IPSec Packet Filtering

Erect another layer of defense around your Web server

In "Protect Private Ports with IPSec," April 2002, InstantDoc ID 24273, I discussed using IP Security (IPSec) to lock down access to private ports on IIS servers. But locking down IPSec access is an option only if the computers that communicate with your server run Windows XP or Windows 2000 and you have the authority to configure them with complementary IPSec policies. If you can't use IPSec to secure data uploads, remote administration, and other private traffic, you can still use IPSec's packet-filtering capability. IPSec lets you block packets by port number and IP address, providing a valuable way to prevent attacks on private ports—those used for administration and data transfers such as Telnet, FTP, and Win2K Server Terminal Services—as opposed to public ports such as ports 80 and 443, which are used for HTTP and HTTP Secure (HTTPS). Let's look at how to set up IPSec packet filtering to protect your Web server and how to test it.

Set It Up
Suppose you want to make ports 80 and 443 accessible to anyone on the Internet. Your business partner needs to access your server's FTP service from its IP address 63.88.172.66. You also have an application server (10.0.12.98) that needs FTP access to your Web server, and your administrators and operator PCs (subnet 10.0.11.*) need access to port 3389 for Terminal Services.

On a Win2K system, you can create multiple IPSec policies, but you can assign (i.e., activate) only one of them. IPSec policies consist of one or more rules. Each rule has a packet filter and a specified action that Win2K will execute on any packets that meet the associated filter criteria. You can specify the actions negotiate IP security, permit, or block. Let's create one IPSec policy that consists of one block rule and one permit rule. The block rule will block all packets by default. Then, we'll add a permit rule that will allow packets for the port and source IP address combinations I described earlier.

Open Local Security Settings on your server, maneuver to IP Security Policies on Local Machine, right-click the details pane, and select Create IP Security Policy. Click Next on the wizard's first page, enter Packet Filters as the policy's name, and click Next. Clear the Activate the default response rule check box, then click Next, Finish. Now you have an empty policy, as Figure 1, page 2, shows. Next, create the block rule. To start the Create Security Rule Wizard, click Add on the Rules tab, then click Next on the first three pages. On the fourth page, the wizard asks you to select an authentication method for this rule. Although permit and block rule actions don't use any authentication, Win2K still requires that you configure an authentication method. If your server is in a domain, you can leave Kerberos selected; otherwise, select Use this string to protect the key exchange (preshared key) and enter any text you want as the key. Click Next, and the wizard asks you for an IP filter list. This is the default rule; select All IP Traffic and click Next. The wizard asks for your filter action. Out of the box, Win2K has three actions—Permit, Request Security, and Require Security—but no block action, so click Add to start the Filter Action Wizard, then click Next on the first page. Enter Block for the action's name and click Next. Select Block for the filter action behavior, then click Next, Finish. On the Create Security Rule wizard, select Block, then click Next, Finish. Your policy now contains one rule that blocks all IP traffic.

Now let's create a permit rule that lets the general public browse your Web site on ports 80 and 443. On the Rules tab, click Add, and click Next on the first three pages of the Create Security Rule Wizard. Then, configure the authentication method as you did for the block rule and click Next. Now, create a filter list. To open the IP Filter List window, click Add. A filter list consists of one or more filters, each of which specifies any combination of source and destination IP address and port number. We'll add seven filters: To permit HTTP and HTTPS traffic, add a filter for port 80 and one for port 443; add a filter for Terminal Services; and add four filters for FTP. Change the list's name to Permitted Traffic, then click Add to start the IP Filter Wizard. Click Next and select Any IP Address as the source address. Click Next and enter My IP Address as the destination address. Click Next and select TCP as the protocol type. Click Next and enter 80 in the To this port field. Click Next, then click Finish. Repeat the process for port 443.

For Terminal Services, follow the same procedure to add a filter for TCP port 3389 but specify A specific IP subnet for the source address. When the system prompts you, enter 255.255.255.0 for the subnet mask and 10.0.11.0 for the IP address. Now, anyone who connects to Terminal Services from one of your administrators' PCs in subnet 10.0.11.* will have permissions.

Finally, you need to add the filters for FTP. This process is a little trickier because FTP uses two TCP ports: port 21 for commands and port 20 for data transfers. Therefore, to use FTP to connect to your IIS server, your business partner's application needs two filters. Follow the above procedure to add the filters but specify 20 and 21 in the To this port field and 63.88.172.66 as the source IP address. Finally, to enable FTP connections from your application server, add the same two filters again but specify 10.0.12.98 as the source IP address. (This procedure won't allow passive FTP connections to an FTP server.) Figure 2 shows the completed filter list.

On the IP Filter List tab in the Edit Rule Properties window, select Permitted Traffic for the filter list, then select the Filter Action tab. Select Permit for the filter action and click Close. Figure 3 shows the results you should see in the Packet Filters Properties window.

Activate and Test It
Now you need to activate your policy. Select the Packet Filters policy, right-click your policy, and select Assign. Open a command prompt and enter

secedit /refreshpolicy machine_policy

Your IPSec policy is now in effect. Test it; you should be able to browse the Web site from any computer. You shouldn't be able to connect through FTP from your workstation because only the application servers are permitted to connect through ports 20 and 21. Go to a workstation outside subnet 10.0.11.* and try to log on using Terminal Services; the attempt should fail.

If your Web server and the workstations your administrators use are part of the same Active Directory (AD) forest, you can require Kerberos authentication to tighten security on port 3389 for Terminal Services. Delete the filter for port 3389 from the permit rule. Create a new rule in which you select Kerberos as the authentication method. (Keep in mind, however, that if you use Kerberos authentication, you can't enable NoDefaultExempt, which then lets more-experienced intruders spoof the source port to TCP 88 to bypass your blocking rules.) Give the rule the same packet filter you specified earlier for subnet 10.0.11.* and port 3389, but—for this rule—specify Require Security as the rule's action. Next, configure your administrator workstations to support IPSec when they connect to the Web server. You don't need to create a new IPSec policy for these client computers because Win2K includes a Client (Respond Only) policy that automatically negotiates security when a client requests it. To assign this policy on your administrator workstations, either edit the Microsoft Management Console (MMC) Local Security Policy snap-in on each workstation by assigning the Client (Respond Only) policy or add those workstations to an organizational unit (OU) and link a Group Policy Object (GPO) to that OU. Assign the Client (Respond Only) policy to the GPO. Now you have further protection against intruders who connect to Terminal Services on your Web server, even if they succeed in spoofing their IP addresses to make it look as if they come from the 10.0.11.* subnet.

By default, IPSec doesn't block packets that appear to be related to Kerberos or Internet Key Exchange (IKE); it views any packet with a source or destination port of TCP port 88 (Kerberos) or UDP port 500 (IKE). Therefore, an experienced intruder might succeed in reaching a supposedly blocked destination port on your server by specifying TCP port 88 or UDP port 500 as the source port. In Win2K Service Pack 1 (SP1), Microsoft added NoDefaultExempt, a REG_DWORD value under the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesIPSEC registry subkey. When you set NoDefaultExempt to 1, Win2K won't let packets with source port 88 reach destination ports on a server you blocked with an IPSec policy. However, NoDefaultExempt doesn't address IKE packets, and Microsoft documentation doesn't explain why it doesn't.

Flexible Security
Good security is a combination of layers stacked to provide in-depth defense. Using IPSec packet blocking is a good, built-in second line of defense in case your firewall fails you. If you're interested in an independently developed packet-filtering utility, check out Jean-Baptiste Marchand's PktFltr.