A Wall Around Your Servers
Using IPsec policies for server isolation is easier than you think.
Server isolation builds on the concept of domain isolation, which I described
. 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.
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.
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
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
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.
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
- 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
- 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
- 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.