IPSec Packet Filtering

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.