Network Quarantine Systems

Network Quarantine Systems

Lately, network quarantine systems, or at least pre-announcements of such systems, have become common. These are systems that are designed to keep machines off the network until they've been proven to be good. This raises an important issue: If you're unwilling to prevent systems (including the CEO's) from functioning on the network, then quarantine is not for you!

Quarantine is designed to stop machines from connecting if they are infectedor at least don't match some predefined configuration policy. We've heard from many customers who are worried about getting fired because the CEO can't connect the day after his son downloads 12 worms from Kazaa. If this describes your situation, you have a few options:

1.	Don't use quarantine.
2.	Get a policy approved that specifically protects you if you do use quarantine and suspect that you might be on the receiving end of any vitriol in case the CEO's computer is quarantined.
3.	Fire up a browser and start hanging out at http://www.monster.com.

(Note that we've omitted option 4, successfully change the mind of the CEO such that he/she publicly announces agreement with quarantine consequences. After all, none of us live in Fantasy Land! Actually, this is just a joke. It takes public commitment by executives high up in the organization to succeed with a quarantine deployment. Be sure you can secure such support before you roll out any quarantine technology.)

It is simple really: network security is about stopping attacks. It is not about only stopping attacks from peons. We either do it, or we do not. Just because someone is getting an unholy number of stock options every year for a job that consists mainly of coming up with "mission statements," they shouldn't be immune to security policies. (Several recent state and federal regulations give you ammunition to enforce that no one be exempt from security policies and controls.) Actually, we hope it's apparent we're just having a little fun here. In reality, you'll probably need to enact procedures that allow you to grant temporary exceptions in case something goes wrong. Although it's nice to believe that security decisions trump everything else, in reality the business must continueand if broken security gets in the way, you can come perilously close to losing your job. The procedure must explicitly spell out risks associated with granting exceptions, so if the risk "bites," there's no blame to throw around. Enlist management as your allies and get their buy-in; it's the only way you'll make true progress.

Quarantine keeps machinesall machinesoff the network until they have managed to prove that they're compliant with security policy. The way to do that is not to ask the machines if they would like to be quarantined. You can't have effective isolation by asking systems to quarantine themselves . Enforcement is based on a very simple principle: enforcement decisions must rest with the asset that we are protecting, not with the asset we are protecting against.

Quarantine System Components

When dealing with quarantine systems, we have several components to consider.

• The protected asset. Typically a server or client that's already known to be in policy and is currently allowed to communicate on the network. (These are the assets we are trying to protect.)

• The quarantine client. This is a server or, more commonly, a workstation, that's just been connected to the network but that hasn't been evaluated yet. A client must have a software component that understands how to evaluate the policy and get the client out of quarantine. How this component is provisioned varies. Sometimes, it's done using the TAMO (Then A Miracle Occurs) principle. Better systems include a bootstrapping mechanism to get the software component provisioned to the clients .

• The enforcement server. This server resides in the quarantine network; it delivers policies and eventually access tokens to quarantined clients. Note here that all resources the client needs to get out of quarantine must be accessible in the quarantine network.

• The enforcement mechanism. There are several valid enforcement mechanisms, which we discuss below.

802.1X-Based Enforcement

The simplest type of enforcement is 802.1X-based. When a client connects to a network, it's placed into a VLAN where it has access only to the enforcement server and whatever other systems it needs to access to get itself out of quarantine. The client might have access to the Internet at this point, in which case the client could just stay on this network indefinitely if that's all the access it needs. (Consider also making available a server from which to reinstall a virus scanner in case the quarantine check fails for no good reason.) This is used in a very simple type of enforcement sometimes seen on wireless networks: domain members get on to the internal network, nondomain members only get Internet access. After a client proves that it complies with the security policy, the enforcement server causes the switch or access point to move the client to a different VLAN where it gets full access to the network. This type of enforcement carries with it the same disadvantages and advantages as 802.1X mentioned earlier.

There's one major consideration with 802.1X in a Windows environment: it wreaks havoc on roaming profiles. If the enforcement decision is based on the user profile, download gets interrupted after the client moves between VLANs because the electrical network connection is broken. The result is that the client won't receive the roaming profile. If the enforcement decision is based only on the machine, logon should be delayed until the client has passed quarantine. Keep in mind, however, that this significantly limits the corrective action and notification that can happen as part of the evaluation process.

IPsec-Based Enforcement

IPsec-based enforcement uses an IPsec policy to keep systems from talking to each other. Before the client proves its security state, it can communicate only with machines allowed by the policy, but not with any other resources on the network. After the client passes the quarantine checks, the enforcement server plumbs a short-duration certificate that's required to connect to any network resource. If the client lacks the proper IPsec rules, those are also plumbed after the client meets policy.

IPsec-based enforcement has many advantages. First, it leaves the enforcement decision where it belongs: at each individual resource. It's almost as if each server on the network has its own quarantine policy that it can enforce. Second, it's nearly impossible to circumvent because you can require Kerberos or digital certificates for authentication. The concept of IPsec-based quarantine is a more generalized version of using IPsec for domain isolation.

VPN Quarantine in Windows Server 2003

So you've done everything this book recommendshardened your infrastructure, deployed 802.1X for wireless, implemented IPsec for domain isolation, used AD group policies to apply security settings to clients and servers by role, built a comprehensive configuration and change management process that includes patches and AV/spyware signature updates, tossed out silly security settings that you read about in magazines and yet you feel a nagging ah yes, remote clients! Something about VPN access smells different. And indeed it is: although you know who the users are, VPNs give you much less certainty about the computers those users are connecting with. If in your LAN you can do so much to regulate client computer configuration and check for conformance, shouldn't there be a similar thing for remote computers, too?

One of the most popular features in Windows Server 2003 is network access quarantine control, or VPN quarantine. Rather than just letting remote clients directly on to the network (after a successful user authentication), VPN quarantine places packet filters on the client to restrict initial access to a "quarantine resources" area while a script on the client begins executing and a timer on the client starts counting. You write the script to check for whatever you'd like; common checks are service pack and patch status, whether an antivirus program is running and up-to-date, whether a firewall is installed and enabled, domain membership, and so on. The script must return a results string indicating the policy conformance before the quarantine timer expires .

If the script returns a "success" results string within the quarantine time periodmeaning that the computer conforms to your policythe VPN server deletes the packet filters from the client's connection and removes it from quarantine, granting full access to the network. If the script returns any other result or the timer runs out before the script completes, the VPN server disconnects the client. It's a good idea to keep an Internet-accessible Web server somewhere (with basic authentication enabled) so that users can bring their computers up to policy by downloading approved patches, AV updates, and so on. Understand that VPN quarantine is primarily a policy validation and enforcement mechanism, not a pure security technology. It won't protect you from malicious users who possess valid credentials on the network and try to create a forged results string.

Use the Connection Manager Administration Kit (CMAK) ^[28] to create custom VPN "connectoids" (network connection objects) that are preconfigured with DNS names of your VPN servers, telephone numbers of remote access servers, and your quarantine policy script. Be sure to prevent split tunneling by disabling the ability for clients to update their routing tables (this even applies to users running as local administrator). Because the script can be a little difficult to write, examine the sample scripts available from links at http://www.microsoft.com/vpn .

^[28] The wizard in Windows Server 2003 is greatly enhanced. http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/cmak_ops_08.asp.