Security Advisor

A Wall Around Your Servers

Using IPsec policies for server isolation is easier than you think.

• By Joern Wettern
• 04/01/2006

Server isolation builds on the concept of domain isolation, which I described in last month's column. While domain isolation ensures that computers in your Active Directory domains can only communicate with each other, server isolation protects specific servers by tightly controlling which client computers can communicate with them. One nice feature of server isolation is that you can start small and learn how to leverage the IP Security (IPsec) capabilities of Windows to protect your most important servers. During this process you can then build the base for planning towards more comprehensive domain isolation.

Why Isolation?
Last month I discussed the perils of letting computers in your network freely exchange IP packets. In a typical network you don't have control over which computers can connect to each other -- clients and servers gladly accept and process packets from other corporate computers, as they should. However, they just as gladly talk to an unknown laptop plugged into one of your switch ports. The consequences can be dire, if for instance a worm gets introduced and spreads quickly from the rogue computer to the rest of your network.

[Click on image for larger view.]

Figure 1. A rule for TCP port 1433 allows SQL Server connections. Making the rule mirrored ensures that return packets are also processed correctly.

Domain isolation is designed to ensure that computers that are part of your managed environment only exchange IP packets with other computers that are part of the same environment. This goes beyond the protection of individual resources with access control lists (ACLs), the mainstay of traditional Windows networking. Domain isolation forces managed computers to drop unauthenticated network packets even before someone can make an attempt to access a specific resource.

Starting Small
Implementing domain isolation company-wide can be a daunting task, requiring a lot of planning. Server isolation, on the other hand, can start with a single server as a testing ground. You can then extend it to all your critical servers, paving the road to full-fledged domain isolation, which uses the same techniques and tools as server isolation. In addition, servers are ideal candidates for such an initial implementation. They contain the resources you want to protect the most, and you generally have a clear idea which clients need access to them. For example, assume you have a database server in the accounting department that should only be accessible from clients also in the accounting department. Such a server makes a great candidate for the initial deployment because you can easily determine which network traffic from and to this server is required.

The Essential Tool: IPsec
IPsec is widely viewed as a traffic encryption technology, but don't forget its other capability -- authenticating IP packets. All versions of Windows since Windows 2000 can use IPsec, so it's likely that most servers and clients can use it. Creating IPsec policies isn't difficult, but the Windows tool for editing these IPsec policies has a tendency to intimidate administrators. It does this by taking you through a series of wizards that are strung together and muddle the concepts involved. Because of this, few administrators get further than looking at some pre-defined sample policies, which are of limited use. For our small server isolation project we'll ignore the samples and create our own policy. But first, it's necessary to review the elements that make up an IPsec policy:

• IPsec Policy. This is a collection of rules that determine how a computer communicates when it sends or receives packets. Each computer can have a single policy assigned to it at any given time, but that policy can consist of multiple rules that cover various types of network communications.
• IPsec Rule. Each rule defines a method for how the Windows IPsec driver handles the type of traffic that the rule applies to. This includes whether security is required for this traffic and which type of authentication is used. Each rule contains one or more filters that specify which traffic that rule applies to.
• IP Filter. The filter defines the network traffic by protocol, port and direction.

Creating an IPsec policy opens a wizard, which first prompts you to create rules, then allows you to create filters. I find it more helpful to think about the process like this: You create filters to define types of network traffic; you then apply a rule that determines how the traffic is handled; finally, you combine multiple rules into a policy. Once your policy is finalized, the last step is to apply it to the computer. Since there can be only one active policy at any time, you must make sure that the assigned policy contains all required rules. The procedure I'm describe below still follows the steps you take in the wizard, but as you go through it, try to remember at each step how the different elements connect to each other.

Creating A Simple Policy
For our example, let's keep it simple: Our SQL server should only accept connections on port 1433 from computers in the same subnet. But because it's a domain member, it also has to communicate with domain controllers, located in a different subnet.

The first step is to open a Microsoft Management Console window and add the IP Security Policy Management snap-in for the local computer to it. Three pre-defined policies already exist, but we'll start the IP Security Policy Wizard to create a new policy.

First, right-click on IP Security Policies on Local Computer, then left-click on Create IP Security Policy.

In addition to the name and description of the policy (call it “SQL Server Policy”), you'll be asked if you want to use the default response rule. This rule is used for undefined incoming connections. Since you don't want to allow any network traffic you don't define, don't activate the default rule.

[Click on image for larger view.]

Figure 2. Choosing the Require Security setting ensures that only authenticated connections are possible, but encryption is not required.

Once you've created the policy, it's time to create the first filter. Upon clicking Add, A wizard for doing this should start automatically. When answering the questions in the wizard, make sure to specify that this rule does not specify a tunnel and that it should apply to all types of network connections. Once you've entered this information, you're prompted to create IP filters. After naming your filter list you will create a filter that applies to SQL traffic.

Click Add again to start the wizard that actually creates the filter definition. A filter that applies to SQL traffic needs to allow connections for TCP port 1433 from one subnet to the SQL server. In the IP Filter Wizard, first specify the rule to be mirrored, which means that return packets to the client computers are also allowed. As the source address, select A specific IP subnet, and then enter the address of the subnet where the client computers are located. As the destination address, select My IP Address (which is the SQL server's address). When prompted for the protocol and port, select TCP, and specify traffic from any port to port 1433. Figure 1 shows the results of creating this rule.

Continuing the Security Rule Wizard, first select the filter list you just created. Next you have to choose an authentication method. IPsec contains a pre-defined filter action for requiring authentication. By choosing Require Security, as shown in Figure 2, you enforce authentication for all packets that match the filter, but encryption is required. Make sure you keep the default authentication method of Kerberos to complete the wizard.

Once you've created this rule, SQL traffic is covered. But you also need a rule to permit connections to domain controllers. For simplicity's sake, this rule will apply to all traffic from the SQL server to the subnet containing the DCs.

In the Properties dialog box of the security policy, click Add, then complete the Security Rule Wizard. The steps are almost identical to those for the SQL traffic rule, with one exception -- the filter you add will need to specify My IP Address as the source and the subnet with the DCs as the destination. Also, this time you should allow all protocol types. Once you've created this definition, you'll be back in the Security Rule Wizard. Assign the filter action Request Security (Optional), which means that the computer will try to establish an authenticated connection to the DCs, but that it will fall back to an unauthenticated connection if the DCs aren't configured with a compatible policy. Select Kerberos as the authentication protocol. Once you have completed the wizard you should see results that look similar to those in Figure 3.

[Click on image for larger view.]

Figure 3. The pre-defined filter actions "Request Security" can be used instead of "Require Security" when you're not sure whether all computers support secure communications.

Once you've configured IPsec policies for your DCs and are sure that they can communicate securely with the server, you can change the setting to Require Security. Before you continue, make sure that the check boxes for the IP filter list you have created are selected, but that the check box for the default response is not selected.

Now that you've created the policy, one crucial step remains: You need to assign the policy to the computer by right-clicking on the policy, and clicking Assign. It's easy to forget this step, but without it, nothing will happen. Now that the policy is assigned, you've completed our simple isolation of the SQL server.

What's Next?
Obviously, setting up server isolation for a single server won't increase your overall network security by much, and the simple policy implemented here only covers a very limited scope of network traffic. However, even this simple policy has the elements any server or domain isolation policy will include. Here are the steps you will need to take to expand the concept to make your network more secure:

• Document requirements. Identifying the network traffic that each type of computer performs and documenting the associated protocols and ports is required to configure your IPsec filters.
• Create subnets. Grouping computers with similar requirements into their own subnets will make creating IPsec policies much easier.
• Configure Group Policy. The biggest limitation of the example here is that it applies to a single server. Configuring each of your servers separately would be a cruel task. Instead, export your tested policies and then import them into a Group Policy Object (GPO) that you apply to multiple computers via AD. Alternatively, you can define your IPsec policies directly in the GPO.
• Think about exceptions. Your network most likely contains computers and devices that don't support IPsec. Your IPsec policies will need to incorporate exceptions for legitimate network traffic between them and protected servers and clients.
• Prepare for domain isolation. Domain isolation extends the principle of controlling network traffic with IPsec network-wide, but the principles and tools are the same. You'll find that implementing server isolation will give you a good idea of what's required to apply IPsec-based protection for your whole network.

Using IPsec to secure your entire network can be a very involved process, but getting started can be easy. And starting out with server isolation for some of your most critical servers will give you the most impact from the very beginning. You can get immediate results from the start and learn more about the process and requirements as you move along in the project.