That Isolated Feeling
Taking an isolationist approach is sometimes good -- especially for securing your domains and servers.
- By Joern Wettern
Traditional IT security relies on assigning different levels of trust to different
network zones. A more effective solution is to rely on trust between computers,
instead of trusting the networks they're connected to. Domain isolation and
server isolation leverage Windows capabilities to reach this goal.
A Matter of Trust
Chances are that your current network consists of the main internal
network, and one or more demilitarized zone (DMZ) networks. Maybe there are
a few tightly controlled networks with limited access, such as one that connects
the research department's computers. In addition, you might have branch office
networks connected over WAN links, but computers on them have full access to
your internal network, so they really belong to the internal network from a
security point of view.
When we analyze the security functions of a network, physical infrastructure becomes secondary. Instead, we often think about security zones and agonize over which zone network should contain a network resource, or how to best control traffic between these zones. We know that the Internet is entirely untrustworthy; even in our wildest dreams, we wouldn't connect a server directly to that malware playground.
If we need to allow someone to access a server from the Internet, we routinely
place the server into a DMZ and use a firewall to tightly control and monitor
access to it. We trust the DMZ more than the Internet, but not enough to allow
unrestricted communications between it and our internal network. If such connections
are required, we use another firewall to further restrict and monitor them,
because we only want to allow network packets that we trust on our internal
[Click on image for larger view.]
|Figure 1. On a typical network,
computers on the internal network all trust each other. This can be a problem
when an outside, possibly compromised computer is introduced to this network
This trust seems to be justified because, in addition to using firewalls, we
make sure that only legitimate users get access to this internal network. We
try to keep intruders out by authenticating users, using selective permission
assignments on file servers, and requiring an employee badge for entering a
building with network taps. Figure 1 illustrates this type of network design,
which allows any computer considered part of the internal network to communicate
with any other computer -- because the internal network is trusted.
This philosophy of network segmentation has been the de facto security standard for a long time, and most corporate networks rely on it. Looking at the network as a set of security zones can be useful, but relies on the often-unrealistic assumption that access to the network is tightly controlled. Instead, many internal networks include a variety of computers: managed clients at corporate headquarters; home computers connected over a VPN; the laptops of outside consultants or visiting customers; a kiosk computer in the lobby; wireless users inside the building and in the coffee shop across the street; and so on. Because all computers on a typical network like this shouldn't be trusted equally, it's a dangerous a practice to trust based on zones.
Divide and Conquer
One way to restore the trust in your network is to further divide it.
For example, you could create a separate network for the accounting department
and disallow access to it for VPN and wireless clients. Readily available tools
for such segmentation include firewalls, routers and VLANs (virtual LANs), but
each of these tools has its own shortcomings:
- Large-scale, effective VLAN deployment requires all switches to support
this type of segmentation.
- Routers make decisions based on IP addresses and ports.
- Firewalls can be expensive and difficult to manage.
And none of these solutions can protect you against an employee who plugs a virus-infected personal laptop computer into the corporate network.
802.1x: Not Just for Wireless
A better method for ensuring trust in your network is to require computer
authentication when connecting to your network infrastructure, then restricting
which authenticated computers are allowed to connect. This is commonly done
for wireless clients by using 802.1x-based access control.
The wireless clients need to be configured with a certificate or some type of shared secret before the wireless access point (WAP) allows any network packets to be transmitted across the network (note that 802.1x can also be used for regular wired connections.) Windows supports this out of the box, and many recent switches have 802.1x support built-in. 802.1x can be an effective method for ensuring that only authenticated computers and devices can send and receive packets on your network -- if an employee plugs a personal laptop into a hub, or a visiting sales representative plugs a computer into the conference room's network tap, they'll be stopped at the switch. 802.1x can be an effective solution, but the resulting administration work, the need for an existing PKI (Public Key Infrastructure), an the scarcity of devices that support it often put and end to any plans to implement 802.1x company-wide.
Domain isolation tries to accomplish a goal similar to 802.1x, but with
a different method. Instead of preventing untrusted computers from sending and
receiving network packets, it relies on your trusted computers to ignore such
traffic. You're essentially treating your entire network as if it's untrustworthy,
and letting your trusted computers make decisions about whether to trust computers
with which they're communicating, independent of the network. This creates a
security domain of trusted computers which can securely communicate across a
network that may not be entirely trusted. Figure 2 shows how only computers
in this trusted domain can talk to each other.
[Click on image for larger view.]
|Figure 2. Using domain isolation,
trusted computers ignore communications from untrusted computers, no matter
which network segment they’re on, or which security zone they’re
Using domain isolation instead of network-based security models has several
- It's much more flexible.
- It can be rolled out incrementally, at a pace that works for you.
- It will probably require no additional hardware.
If you have an existing Active Directory infrastructure and most of your computers are running Windows 2000 or higher, you already have the two tools you need for domain isolation: IPsec and Group Policy. IPsec, which takes care of the authentication, is built into all versions of Windows since Win2K. Group Policy, which allows you to implement domain isolation across a large number of computers, is a core component of AD.
IPsec to the Rescue
IPsec is a versatile network security protocol (for a refresher on IPsec,
see the "The Many Uses of IPsec" below). IPsec authentication occurs
much earlier than resource access authentication. When a computer authenticates
a user who wants to access a shared folder, a network connection has already
been established. But IPsec authentication occurs even before the first network
packets, excluding the authentication traffic itself, can be sent or received.
IPsec authenticates computers and not users. When used as part of domain isolation, an IPsec policy on each computer determines how it will communicate with other computers. For example, you can require that two computers authenticate each other before exchanging any network packets. The policy can also include exceptions based on ports or IP addresses.
The most basic form of domain isolation uses an IPsec policy that instructs
client computers and servers in your AD domains to process network packets only
from computers within the same AD. IPsec can use shared secrets, certificates
or Kerberos. Of these options, Kerberos is the clear choice if your infrastructure
is Windows-based. Shared secrets aren't secure, and certificates can be difficult
to deploy and administer. Kerberos, on the other hand, can be used by domain
members to authenticate each other without any additional administration or
Many Uses of IPsec
IPsec (IP Security) is a standard for securing
IP communications at the network layer. Unlike Secure Sockets
Layer (SSL), which secures application data, IPsec was designed
to be completely independent of the application and handle
all IP packets at the network layer. IPsec has many security
- Virtual Private Network (VPN) tunnels: This is
the most common use for IPsec. It can provide encryption
and packet integrity checking for a VPN tunnel, either for
client connections or site-to-site tunnels. Many vendors
have implemented IPsec in their VPN solutions.
- Authentication: Microsoft is one of the few vendors
that has fully supported the use of IPsec for any type of
network connection, and not just VPN tunnels. The Windows
IPsec driver, part of the network stack, can perform authentication
of a remote computer before IP packets are further processed
by the stack. Microsoft supports shared secrets, certificates
and Kerberos for authentication.
- Encryption: IPsec can be used to encrypt network
traffic (but this isn’t required -- you can require authentication
without encryption). Encrypting packets provides confidentiality
for all network traffic, and you get this even if the application
you use doesn’t provide encryption itself. IPsec has a built-in
mechanism for negotiating encryption algorithms and exchanging
- Integrity: Packet integrity ensures that a network
packet hasn’t been altered since it was sent. IPsec can
detect such alterations and automatically drop packets that
have been changed in transit. -- J.W.
Configuring IPsec separately on each computer is a waste of manpower. Instead,
configure a Group Policy for all your clients that includes the IPsec policy
designed to accomplish your authentication goals. You can apply this policy
to all computers in a domain or Organizational Unit (OU), but you can also easily
configure exemptions for computers that should accept unauthenticated connections,
such as connections from non-domain members. Designing such exemptions will
probably require the most work during the planning phase; but unless all your
computers are running Windows and are AD members, there will likely be times
you'll have to allow non-authenticated connections, like allowing a consultant
to connect to a server from a laptop, or enabling users to access corporate
resources over a VPN from home.
Next Time: Isolating Servers
Keeping unauthenticated computers off your network is only the first
step. Malicious actions can originate from authenticated computers, and I often
find that I want to tightly restrict which computers can connect to critical
resources, such as servers that contain payroll data. Also, when the access
involves confidential data, and the application I'm using has no built-in encryption,
I often want to encrypt the data at the network layer instead. Server isolation
is an IPsec-based scheme to accomplish these goals by building on the principles
of domain isolation and going several steps beyond it. Next month I'll show
you how to use server isolation by itself or in conjunction with domain isolation
to increase security. I'll also provide more details on using IPsec and group
policy to achieve your security goals.
- The best place to learn more about domain isolation and server isolation
is the Microsoft
TechNet site on this topic.
a detailed description of how Microsoft implemented domain isolation in its