Chapter 12: Server and Domain Isolation
Quite possibly the most powerful security measure in recent memory is something Microsoft calls Server and Domain Isolation (SDI). SDI has, in fact, become a marketing rallying cry for Microsoft, although it really started as a purely technical measure for restricting avenues of attack. Perhaps the first widely published use of the technique was Microsoft's winning entry in eWeek's OpenHack IV, in 2002, which predated the marketing term by several years. The principle of the defensive method used in OpenHack IV was simple: enumerate all necessary communications patterns in the network and allow those, and only those. This is effectively what Microsoft now calls Server Isolation. In this chapter, we describe the basics of SDI, and look at how the way you deploy it has changed in Windows Vista.
Server and Domain Isolation Overview
SDI is essentially about one thing: allowing only the traffic that needs to be allowed in your network. Fortunately, there is a way to put a security mechanism right between the network and the host layer. In essence, it is a network-layer security mechanism that is implemented on each host-to protect them from the network. There are several ways to think of SDI. One is in terms of deployment phases. Another is by looking at the different isolation mechanisms. The deployment phases are really just two:
-
Analyze your network.
-
Build IPsec rules to enforce the necessary and desired communications patterns.
The network analysis phase can be quite lengthy. The sad reality today is that the vast majority of organizations do not quite know what is on their network. This is almost to be expected given how fluid and complex the average network is. In fact, an organization that knows where 80 percent of the computers they have bought are on any given day is probably ahead of the curve. This is actually one of the major reasons for SDI itself: it forces you to get a better handle on your asset management and your network architecture. Even if you never get to the deployment phase, you have made your return on the investment several times over in the improved understanding of your network. Compared to the analysis phase, the deployment phase is probably relatively straightforward, if the analysis phase was properly done.
This chapter provides only an overview of SDI. Microsoft has published lengthy tomes on SDI on its Web sites. Most SDI documentation is linked from the SDI tech-center at http://www.microsoft.com/sdisolation. In particular, Microsoft's primer on the technology is quite useful for those looking to understand the basic concepts. In the remainder of the chapter, we explore the basic concepts of SDI and some of the rationale behind it, and highlight how Windows Vista has made implementing SDI easier and faster.
Domain Isolation
Domain Isolation is quite simple in concept, albeit not so simple in practice. The idea is to restrict communications in a network such that only machines that are members of the domain can speak to each other. The ability to stop non-domain members from accessing domain resources is a common request among many customers. They want to get better control over their information assets and prevent non-domain joined machines, which by definition are unmanaged machines, from accessing any network resources. The implementation of domain isolation involves deploying an IPsec filter that allows inbound connections from other machines in the domain but blocks connections from unmanaged systems.
This is where it starts getting more complicated. First, almost every environment has unmanaged machines that cannot be domain joined. For instance, a network printer might send logging data to a domain member, and there needs to be an exception in the IPsec filter to allow this. A further complication stems from the fact that you cannot secure all domain traffic with IPsec. The rationale is quite simple. The simplest method to implement the IPsec authentication is to use Kerberos. However, in order to use Kerberos, one must be domain joined. In order to become domain joined one must be able to connect to the domain controller (DC). In order to connect to the DC one must be able to negotiate an IPsec connection. In order to negotiate an IPsec connection one must be able to get a Kerberos ticket. In order to get a Kerberos ticket one must be domain joined. In order to … Well, you get the picture.
This circular dependency is why Microsoft has never supported client-to-DC IPsec. The DC, the very most valuable resource in the domain, must be unprotected by IPsec and accessible to all; otherwise you will never join another system to the domain. There are isolated deployments that have deployed client-to-DC IPsec anyway. In at least a few environments they made a conscious decision not to join any more systems to the domain. In others, the decision was to use certificate-based authentication for IPsec and then build an out-of-band deployment and servicing mechanism for the certificates. Starting with Windows Vista, certain limited client-to-DC IPsec scenarios are actually supported. More about that later.
Server Isolation
Server Isolation is a bit more complicated than Domain Isolation both in concept and in implementation. The astute reader would have noticed the fallacy in the logic behind pure domain isolation, however. A moderate-sized domain today consists of at least 5,000 computers. Do you really wish to allow connections from every one of those to every other computer? The total number of connections in that environment can range to 5,0002*numberOfProtocols each computer implements. How can you possibly hope to maintain the integrity of an environment that allows 500,000,000 + connections? Add a single computer and the number of connections increases exponentially. By the way, do most workstations really need to request services from each other? Do most clients need to connect directly to the back-end database servers? With only Domain Isolation, while you block unmanaged computers between domain members, all those connections are allowed. You have yourself a great big kumbaya network where everyone is fat, dumb, and happy, and trusts everyone else because they managed to convince someone to add them to the domain. When the next big worm comes, or when some counter-intelligence service breaks into your network, the attackers will have access to everything that the first domain-joined system they hack has access to; transitively.
This is where Server Isolation comes in. Server Isolation is about isolating servers (systems that provide services; in other words, not just your typical server) such that only those systems that have a legitimate need for their services can access them. The simplest example of this is a back-end database server. Users should not be allowed to run ad-hoc queries against many back-end databases. They should use well-defined front-end applications, which in turn access the back-end database on the user's behalf. As a slightly more complicated example, consider Remote Procedure Call (RPC) and Distributed Component Object Model (DCOM). The vast majority of machines that provide RPC and DCOM services to remote systems actually have no legitimate need to do so to the vast majority of systems in the network. This includes every Windows XP system. This problem gets even worse if you provide these services without authentication, as Windows XP and Windows XP Service Pack 1 (SP1) did by default. Using IPsec, you can block connections from systems that should never be allowed to request RPC, or DCOM, or database services, or any service you wish, from a particular system-on the system that provides the service. In other words, this provides actual enforcement, and does not just ask the potential attacker to behave nicely. At this point you may want to pause and con sider how much damage the SQL Slammer (http://www.en.wikipedia.org/wiki/SQL_slammer_worm) and DCOM Blaster (http://www.en.wikipedia.org/wiki/Blaster_worm) worms would have caused, had you deployed server isolation throughout the entire network.
Common fears about IPsec are that it slows down your network and blocks all your network monitoring tools. The latter is not true if you use ESP NULL; in other words, you select to encrypt packets but do not provide a key to do so. This is the default in Windows Vista and provides the authenticated traffic we desire. The former concern is only marginally true. IPsec, naturally, does impose a performance penalty, but it is quite small, on the order of 5–10 percent in prior versions of Windows. Windows Vista adds performance improvements to the TCP/IP stack, including IPsec. In addition, Windows Vista has added performance monitor counters for IPsec to enable users to monitor performance of IPsec.
|
