Security Advisor

That Isolated Feeling

Taking an isolationist approach is sometimes good -- especially for securing your domains and servers.

• By Joern Wettern
• 03/01/2006

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 network.

[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 segment.

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
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 in.

Using domain isolation instead of network-based security models has several advantages:

• 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 configuration.

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.