Using IPSec to Lock Down a Server

Article
10/27/2009

By Steve Riley Consultant, Microsoft Telecommunications Practice

The Windows 2000 IPSec policy engine provides a very effective means to secure a network interface. If you have a server that isn't protected by a firewall or router with good access control lists, the procedure described here is a must for ensuring that the server remains secure. And even if one or more layers of defense protect your server, this procedure adds an effective additional layer—increasing your network's "defense in depth."

Note that you aren't actually creating any IPSec security associations1 between the server and any other node; rather, you're using the IPSec interface and policy engine to specify which protocols are allowed into the server's network interface (and blocking all others). This is much more flexible than the TCP/IP filtering available in the advanced configuration options. Compare the two approaches:

Feature	IPSec policies	TCP/IP filtering
Scope	Specific addresses/interfaces	All interfaces in the server
Source addresses	Can be part of a policy	No ability to indicate
Reboot required	No	Yes
Response to blocked traffic	None—incoming packets are dropped, server appears invisible	Reset returned to client

Using IPSec policies to lock down a server provides greater flexibility by allowing you to specify which interface should be filtered as well as which source addresses are allowed (if you need this level of granularity). IPSec policies also provide greater security by silently discarding blocked traffic.

For large-scale deployments of IPSec policies, and to include creating policies as part of an automated server build process, the Windows 2000 Resource Kit includes IPSECPOL.EXE. This command-line utility allows you to script the creation of IPSec policies. Although you should refer to the Resource Kit for full information, this document will discuss using IPSECPOL.EXE in the context of locking down a server.

The Defense in Depth Strategy

Adopted from the military, this strategy also makes very good sense for information security. Relying on a single mechanism for network and host security is inadequate when faced with contemporary information attacks for several reasons:

A single configuration error allows an intruder complete access to the network.
One layer of defense provides little resistance to attack and insufficient time for an incident handling team to respond.
Attempting to accommodate all security policies in one device may result in unwieldy rulesets that become difficult to maintain.

Spreading responsibility for protection among several devices addresses each of these concerns:

A configuration error at one layer most likely will be mitigated in another.
Multiple layers of defense create more work for an attacker—this alone will discourage casual attacks; layers of defense also provide that most valuable of resources for your incident handling team: time.
Multiple layers of security allow you to create policies that are appropriate for each layer, simplifying the configuration.

Defense in depth also provides good flexibility to accommodate changes. For example, suppose you have a demilitarized zone (DMZ) network with some web servers, a mail server, a news server, and a DNS server. Suppose also that you have an automated process with which you can easily change the role of a server—quickly converting a web server into a mail server, if necessary. If your firewall specifies rules that control which hosts receive traffic, you'll need to adjust those rules when a server's role changes. In large-scale deployments, such maintenance could become cumbersome. Instead, configure the firewall with regard only to which protocols—but not source or destination addresses—are allowed in the network. Now add an IPSec policy to each server, limiting that server's inbound traffic to what's appropriate for its role. IPSECPOL.EXE makes this very easy—you can include the policy creation and assignment as part of your automated build process. Each time you need to change a server's role, it'll automatically receive an IPSec policy appropriate for that new role. Routine role changes no longer require security modifications.

Planning Your Policies

Before you can begin creating IPSec policies, you need to consider the particular kinds of traffic that each server will experience. It's best to make an actual list, as opposed to a mental one, because this list will help guide you when you create your policy's filters. Filters that are too strict will cause application failures; filters that are too loose will expose your servers unnecessarily. A document describing the required ports, protocols, and flow directions for each server role (or application) will help ensure that your policies are appropriate.

Make a chart similar to the one below. The example illustrates some rules for publicly available web servers and mail servers. Your actual data will vary, particularly if you decide to implement rules limiting the source addresses of inbound traffic or the destination addresses of outbound traffic.

Role	Direction	From/to	Interface IP address	IP Protocol	TCP/UDP port
Web—regular	in	all	131.107.1.1	TCP	80
Web—SSL	in	all	131.107.1.1	TCP	443
SMTP	in, out	all, all	131.107.1.2	TCP	25
POP3—regular	in	all	131.107.1.2	TCP	110
POP3—SSL	in	all	131.107.1.2	TCP	995
IMAP4—regular	in	all	131.107.1.2	TCP	143
IMAP4—SSL	in	all	131.107.1.2	TCP	993

Once you've completed your chart, you can begin creating IPSec policies. While it's possible to store IPSec policies in the Active Directory and have them assigned to machines via group policy, it's better to use local policies for storing the lockdown filters you're creating, since the policies are tailored to specific machines.

Terminology

Knowing these terms will help you understand IPSec policies in Windows 2000.

Filter list. Ports, protocols, and directions; triggers a decision when traffic matches something specified here. One list can contain multiple filters. Derived from the chart made earlier.
Filter action. The required response when traffic matches a filter list. Here, you're concerned only with the "permit" and "block" actions.
Rule. A correlation of a filter list with a filter action. Generally used to specify IPSec security negotiation parameters, which you aren't using here.
Policy. A collection of rules. Only one policy can be active ("assigned") at any particular time.

Now you're ready to begin creating the IPSec policy for a server. We'll first use the GUI. Later we'll examine the command line utility in the Resource Kit.

Creating the IPSec Filter Lists and Filter Actions

Begin by opening the computer's local security settings:

Start | Programs | Administrative Tools | Local Security Settings

This management console allows you to configure several security options. Click IP Security Policies on Local Machine in the left-hand pane. The right-hand pane shows Windows 2000's default policies, which you won't be using here.

Figure 1: Local Security Settings console.

Now right-click in the right-hand pane. There are two choices at the top of the menu: Create IP Security Policy and Manage IP filter lists and filter actions. Since you need lists and actions before you can create a policy, that's what you'll do first. Click the second item—Manage IP filter lists and filter actions.

The dialog has two tabs—one for filter lists and one for filter actions. The Manage IP Filter Lists tab shows Windows 2000's default filter lists, which you won't be using here.

Figure 2: Manage IP filter lists and filter actions dialog, filter lists tab, with default lists.

You'll create at least two filter lists:

A list containing at least one filter that matches the traffic you want to allow into the server. You may have multiple filters and multiple lists, depending on what your server is running.
A list matching all inbound protocols and ports. The reason for this will become clear.

Click the Add button to create a new filter list. Give the filter list a name; the example here shows the filter list for a web server performing both regular and SSL web functions.

In the IP Filter List dialog, click the Add button. The IP filter wizard starts. Answer each of the wizard's questions based on the policy plan you created earlier. Continuing with the web server example (each bullet item here is a page in the wizard):

The source address is Any IP address.
The destination address is A specific IP address. Enter the IP address of the interface that's connected to the Internet. Alternately, if the server has only a single interface, you may choose My IP address instead.
Choose the appropriate IP protocol. In this example, it's TCP.
The IP Protocol Port page (which appears only if you choose TCP or UDP for the protocol) allows you to set both source and destination ports. The default settings are From any port and To any port. To change the destination port, click To this port and enter the application's port number. In this example, it's 80.
Finally, finish the wizard.

Moving on with the example, you'd add another filter, following the same steps in the wizard, except the destination port would be 443 (for HTTP over SSL). The image below shows the completed filter list.

Figure 3: Completed IP filter list for the web server example.

Now it's time to make a decision. If you're working on a single-purpose server—such as the web server in our example—you're done creating filters for that server. If your server has multiple roles, then you can either add more filters to the existing filter list or you can create additional role-specific filter lists. Role-specific lists are more flexible because you can easily include or exclude roles from the policy without having to edit particular lists.

If you plan to add more filters to the existing list:

Click the Add button and repeat the process.

If you're done creating the list, or wish to create more lists:

Close the IP Filter List dialog. You'll return to the Manage IP filter lists and filter actions dialog. If you've decided to add additional lists (which you'd do only for multi-purpose servers, remember), repeat the entire process.

A "match all inbound" filter list. You need to create one additional filter list, one that matches all traffic into the interface. The existing All IP Traffic list is defined as "match all outbound traffic from my IP address," which won't work here. Follow these steps to create the correct filter list:

Name the filter list All inbound traffic.
Begin adding a filter.
The source address is Any IP address.
The destination address is A specific IP address. Enter the IP address of the interface that's connected to the Internet. Alternately, if the server has only a single interface, you may choose My IP address instead.
The IP protocol is Any.
Finally, finish the wizard.

You'll match this list with a "block" action soon; more on that later.

Once you've finished your filter list(s), click the Mange Filter Actions tab. You'll see Windows 2000's default filter actions.

Figure 4: Manage IP filter lists and filter actions dialog, filter actions tab, with default actions.

Note one of the actions is Permit. When you build the rules in your IPSec policy, you'll assign the Permit action to each of the filter lists you created. There is one other filter action you need: a block action, which you should create now by following these steps:

Click the Add button.
Name the filter action Block.
Select Block for the general options.
Finish the wizard.

You've completed all lists and actions. Close the Manage IP filter lists and filter actions dialog.

Creating the IPSec Policy

Now that you've created appropriate filter lists and added a block action, you can create the IPSec policy. This is where you define the rules linking the lists to actions.

Back in the Local Security Settings MMC, right-click in the right-hand pane and choose Create IP Security Policy. A wizard starts. Follow these steps:

Name the policy Packet Filter.
Uncheck Activate the default response rule. Actually, it doesn't matter whether this enabled or not, since incoming connections are always either allowed or blocked. Deactivating the rule just keeps things neat.
Leave the check next to Edit properties and finish the wizard.

Your policy is created, but it has no rules, as you can see:

Figure 5: Policy properties dialog, with default rules.

Click the Add button to begin the wizard for adding a rule to the policy. The steps are:

For the tunnel endpoint, choose The rule does not specify a tunnel.
The network type is All network connections.
The authentication method is Windows 2000 default (Kerberos V5 protocol). It's important to understand the following: since your rule actually won't be negotiating security, it doesn't matter which authentication method you choose. No authentication happens when rules simply block or allow traffic. Leaving the setting at its default (Kerberos) simplifies the rule creation process, however.
Choose the filter list you created earlier. Following the example, you'd pick Inbound web protocols.
Choose the Permit filter action. (See the figures below for an illustration of this step and the previous one.)
Finish the wizard.

Figure 6: Choosing the filter list corresponding to the traffic allowed into the server.

Figure 7: Associating the permit action with the previously selected list.

If you've created additional filter lists, repeat the process, each time associating that filter list with the Permit action.

Finally—and this is an important step—repeat the process once more, this time associating the All inbound traffic filter list with the Block filter action. Since there is no "default deny" notion in the IPSec policy engine, you need to create an explicit default deny rule.

After you finish creating the rules, your policy properties will look similar to this:

Figure 8: Policy properties dialog, with completed rules.

Close the properties dialog.

Rule processing in IPSec policies. Unlike typical firewall or packet filtering rules, there is no way to order the list of rules in an IPSec policy. The rule engine matches traffic with rules according to specificity. If a packet matches more than one rule, the engine will apply the most specific rule to the packet. In the case here, packets that match the Inbound web protocols filter list also (of course) match the All inbound traffic list, but since the former list is more specific, the rule engine uses that list to make its decision. Therefore, traffic as defined in Inbound web protocols will be passed to the server, while everything else (as defined in All inbound traffic) is blocked. Without the All inbound traffic filter list and its corresponding Block filter action, the policy really wouldn't do anything useful at all!

Turning on the IPSec Policy

You've created filter lists and filter actions, and you've associated them accordingly with rules in an IPSec policy. The only remaining task is to turn on—that is, assign—the policy to the server. Only one policy can be assigned at any time, so be sure that your filter lists and policy rules accommodate all the traffic you expect the server to process.

To assign the policy:

Right-click the policy you created (Packet Filter in the example) and choose Assign from the menu.

Figure 9: Local Security Settings console, with the Packet Filter policy assigned.

The policy is applied immediately, and the IPSec engine starts processing packets according to the rules in the policy. You don't need to reboot the server.

Scripting policies with IPSECPOL.EXE

Included in the Windows 2000 Resource Kit is IPSECPOL.EXE, a command-line utility you can use to create, assign, and delete IPSec policies. IPSECPOL.EXE is very flexible—it can create dynamic and static policies in the Active Directory and in local and remote registries. Please see the documentation in the Resource Kit for complete information. Here, you'll create static policies in the local machine's registry.

IPSECPOL.EXE has quite a number of parameters, and its syntax can be confusing to understand at first. But if you follow the examples shown here, you can—with three commands—duplicate the entire configuration shown in the GUI examples previously. You might want to open the MMC and refresh its display after each command to verify that the command performed how you were expecting. Let's get started.

The first command, shown below, creates a new policy, adds a rule to the policy, and adds two filter lists and one filter action to the rule:

ipsecpol –w REG –p "Packet Filter" –r "Inbound web protocols"
-f *+131.107.1.1:80:TCP –f *+131.107.1.1:443:TCP –n PASS

The command is shown on two lines for printing; enter it as a single line. The parameters are:

**–w REG —**Write a static policy to the registry. This is exactly the same as using the MMC.
**–p "Packet Filter" —**Create a policy called "Packet Filter."
**–r "Inbound web protocols" —**Create a rule called "Inbound web protocols."
**-f *+131.107.1.1:80:TCP —**Add a filter, where * specifies any source address and any port, 131.107.1.1:80 specifies the destination address (the server's own address) and specific port, :TCP specifies the protocol, and + indicates that the filter is mirrored.
**–f *+131.107.1.1:443:TCP —**Same as the previous, except that the destination port is 443.
**–n PASS —**Pass the traffic through without negotiating security.

Please note that the values of the –w, -f, and –n parameters are case-sensitive—use upper case only!

You may include as many filters as you wish. Remembering the earlier discussion about role-based filter lists, if your server runs multiple services, you should use a separate IPSECPOL.EXE command for each class of filters. For example, the following command would allow inbound connections to ports 110, 995, 143, 993, and 25 and would allow outbound connections to anywhere on port 25:

ipsecpol –w REG –p "Packet Filter" –r "Inbound/outbound mail"
-f *+131.107.1.1:110:TCP –f *+131.107.1.1:995:TCP
-f *+131.107.1.1:143:TCP –f *+131.107.1.1:993:TCP
-f *+131.107.1.1:25:TCP –f 131.107.1.1+*:25:TCP
–n PASS

(The last filter, –f 131.107.1.1+*:25:TCP, looks a little different. It allows outbound traffic to originate from the server's own address on any port to any server on port 25. This filter allows the server to initiate outbound SMTP connections to the Internet.)

The next command creates the generic rule that matches all traffic and blocks it:

ipsecpol –w REG –p "Packet Filter" –r "All inbound traffic"
-f *+131.107.1.1 –n BLOCK

The parameters are:

–w REG — Write a static policy to the registry. This is exactly the same as using the MMC.
–**p "Packet Filter" —**Add to the existing policy called "Packet Filter."
–**r "All inbound traffic" —**Create a rule called "All inbound traffic."
-**f *+131.107.1.1 —**Add a filter, where * specifies any source address and any port, 131.107.1.1 specifies the destination address and any port, the absence of a protocol means any protocol, and + indicates that the filter is mirrored
–**n BLOCK —**Block the traffic.

The last command assigns the policy:

ipsecpol –w REG –p "Packet Filter" –x

The parameters are:

–w REG — Write a static policy to the registry. This is exactly the same as using the MMC.
–**p "Packet Filter" —**Add to the existing policy called "Packet Filter."
–**x —**Assign the policy.

That's all there is. So with three commands, you've accomplished the same thing as with the GUI. When adding IPSECPOL.EXE support to your server build scripts, remember that you probably don't want to actually assign the policy until after you've completely built the server. So the script should include only the –n PASS and –n BLOCK commands; after all the servers are installed, you can remotely assign the policies using this form of the command:

ipsecpol \\machinename –w REG –p "policyname" –x

You will need administrative rights on the machine you specify in the command. If you need to temporarily unassign a policy, replace –x with –y.

You can delete an entire policy—including all associated filter lists and filter actions—with this command:

ipsecpol –w REG –p "policyname" –o

This would be useful if your server build process allows you to dynamically change the role of a server without rebooting. Delete the existing policy, then create and assign the new policy. You can add \\ machinename to all forms of the command if you wish to remotely script the creation of the policies on all your servers.

Differences between the GUI and IPSECPOL.EXE. Yes, there are a few differences, related only to the way certain things are displayed in the GUI.

You can't disable the default response rule, but this really doesn't matter in the packet filter case since incoming connections are always either allowed or blocked.
The rule name is used as the name of the filter list.
The –n PASS and –n BLOCK commands won't use the existing Permit and Block (if you created that in the GUI) actions; instead, a new permit or block action is created for each rule and is named "rule-list-name negpol."
In the properties of each filter action, there will be the default list of security methods, but since there is no actual security negotiation, this list is ignored.
Deleting a policy with the –o command will also delete the associated filter lists and filter actions. Deleting a policy in the GUI doesn't delete the associated filter lists and filter actions.

So Does This Really Work?

In a word, yes. Shortly after Windows 2000 was released, a popular industry magazine tested the security of a number of web servers. Microsoft was invited to attend. We built a Windows 2000 Server with Internet Information Services 5.0 enabled. All we did to secure the server was to add a password to the administrator account and create an IPSec policy just like the one in the examples here. The server was connected directly to the Internet and survived several weeks of attempted attacks.

Of course, this test was performed before the current IIS 5.0 vulnerabilities were found. Please understand that the procedure described here won't protect you from attacks delivered over permitted protocols and ports. Be sure to visit https://www.microsoft.com/technet/security/current.aspx and install the relevant hotfixes for your environment.

We welcome any comments or questions you have about this article. Please send us your feedback to https://go.microsoft.com/?linkid=2544905.

1 A security association describes the negotiated secure communications between two nodes. It specifies the type of authentication, the encryption algorithm, the IPSec protocol, and the destination address.