• Article

Security WatchEstablish a Remote Access Quarantine

Steve Riley

In those good old easy-to-manage pre-mobility days, personal computers presented few actual threats to a network. Sure, there was the occasional virus you’d get from a borrowed floppy disk, but the rate, or at least the speed, of infection was pretty low—limited substantially by the low bandwidth and high latency of "sneakernet" technology. In those days, computers were bulky behemoths that squatted on desks and never moved. They were secure because the network was secure, if there was one at all.

Alas, those halcyon days are behind us now, relegated to the dustbin of history. And indeed they should be. Mobile computers are wonderful! We can work, well, just about anywhere, slay monsters anywhere, play solitaire anywhere. The true advance, of course, was the combination of mobility and a network connection. Got 10 minutes? Haul out the laptop and check that e-mail. Who needs an office anymore?

Of course, Murphy never gets to rest. It seems that with every technological advance (that’s a euphemism for "another way your employer squeezes more work out of you"), there’s a dark side. Connected mobility’s dark side is the ease with which unscrupulous people can wreak havoc across an entire network.

Consider an experience I had a few years ago. A very large wireless network built for a 5000-person event in Europe flat-out died within the first two hours. The Internet Security and Acceleration (ISA) Server outbound log had already ballooned into the gigabyte range. Loading the log into SQL Server™ (not exactly instant, given the log’s size) revealed that a single Media Access Control (MAC) address generated nearly all the traffic!

"Hmm," we thought, "how in the world?" So we triangulated the physical location of the offending MAC address and spoke with its owner: "Hey, your computer is generating huge amounts of traffic, rendering the network unusable for everyone else. May we take a look?" "Sure, whatever." A bit surprised at the owner’s attitude, we examined his notebook computer. Or, more accurately, his Typhoid Mary of a computer. We were flabbergasted—never had we seen so much malware on a single machine. Then came the big shocker: our offer to clean it up was met with a dismissive, "Sure, but I don’t really care." We were speechless.

Armed with a portable computer that’s routinely connected to multiple public networks, the "I don’t really care" attitude is the most dangerous thing I can envision. And when "I don’t really care" then wants to connect back to his corporate network, need I really describe the resulting carnage? Indeed, this exact scenario is arguably one of the fastest-growing infection vectors imaginable.

The Quarantine Process

  

  1. Pre-Connection A pre-tunnel script runs before the remote client initiates the VPN connection. This script checks most of the policy elements and stores the results. If the script fails, it stops the connection attempt and informs the user.
  2. Connection If the script succeeds, the remote client establishes a connection to the RAS server.
  3. User Authentication The RAS server contacts a RADIUS server to authenticate the user. If authentication fails, the script aborts the connection and informs the user.
  4. In Quarantine If authentication succeeds, the RAS server places the remote client in quarantine. Here a post-tunnel script performs additional non-mandatory checks and limits the remote client in two ways: IP filters restrict the computer’s communications capabilities to the quarantine subnet only, and a timeout ensures the computer doesn’t remain in quarantine forever.
  5. Notification The post-tunnel script returns the results of the pre-tunnel script to the RAS server. If the remote client is out of policy compliance, or if the timeout expires before the remote client replies with acceptable results, the script drops the connection.
  6. Access Granted If the post-tunnel script succeeds, the RAS server removes the IP filter restrictions and allows the remote client full regular access to the network (as specified in the remote access policy).

Remote Access Threats

Opening your network to remote access exposes it to two threats: malicious users and malicious software. Most users of your virtual private network (VPN) are connecting from networks that aren’t secure—those at trade shows, in hotels, from coffee shops, or at home. Verifying the identities of VPN users and the configurations of their mobile computers is critically important, often requiring a higher bar than for stationary computers back at the ranch. Plus, the higher speeds of broadband increases the effectiveness of many attacks. So what are these rather specialized threats, and how can you address them?

Malicious Users Home computers are frequently attacked. They’re easy targets because they’re usually poorly managed, rarely updated, and weakly configured. If your VPN is secured only by passwords, and a computer gets 0wn3d, how will you know? Detecting and preventing malicious use of valid credentials is difficult indeed.

Malicious Software Unmanaged and infected remote computers expose your corporate network to serious, severe risk. This is especially true if your network is large and complex enough that you can’t always keep everything patched immediately—it takes some time to test and deploy updates. And given always-on broadband, a lot of your remote users simply might not disconnect for a long time, thus increasing your exposure even more.

To address the threat of malicious users, consider some form of two-factor authentication. Combining "something you know"—a password or PIN—with "something you have"—a smart card or access token—increases your trust in the authentication strength and eliminates many attack vectors. Smart cards containing digital certificates eliminate logon passwords and don’t have batteries that die, but require computers with smart card readers. One-time password tokens work just about anywhere, but require more supporting infrastructure and eventually have to be replaced.

To address the threat of malicious software, consider a mechanism that allows you to verify the configuration of remote systems. Let me introduce you to Remote Access Quarantine Control, the VPN quarantine feature of Windows Server™ 2003.

Remote Access Quarantine

Security policies are wonderful things to have, but if you can’t measure conformance, the policies provide very little value. Policies become effective when you can employ a technical means to validate compliance. Then it becomes a simple matter: those who comply are granted access, while those who fail to comply are rejected.

Remote access quarantine is more of a policy enforcement mechanism than an access control technique. Two-factor authentication is the access control technique—it keeps the bad guys out of your network. VPN quarantine is the policy enforcement mechanism—it compares the configuration of an authenticated user’s computer against your policy and disconnects computers whose configurations don’t meet your requirements. It’s a whole lot easier, and far more secure, to define what you do want to permit and reject all else than it is to attempt to block that which you don’t want because you can never know all the bad stuff.

A script running on the remote client computer controls the quarantine process. When the user initiates a VPN connection, a six-step process engages, as shown in "The Quarantine Process" sidebar.

Additional VPN Quarantine Resources

Several resources will help you learn more about Remote Access Quarantine Control. Visit the main Microsoft VPN page for some excellent guidance:

  • A technical overview, including details about how it works and how to deploy it
  • A planning guide for implementing VPN quarantine, describing the benefits and challenges plus illustrating an example deployment
  • Sample scripts you can customize to enable VPN quarantine in your environment

Also be sure to read Deploying Virtual Private Networks with Microsoft Windows Server 2003, a very detailed Microsoft Press book by Joseph Davies and Elliot Lewis that completely describes everything you need to know about Routing and Remote Access Services, including VPN quarantine and more sample scripts.

Finally, have a look at the Virtual Private Networks section of the Windows Server TechCenter, which provides many additional resources, including more information on VPN concepts and best practices.

Defining Quarantine Policy

Using Connection Manager (also part of Windows Server 2003), you define a custom VPN "connectoid" (a remote access connection object) that gets installed on all remote client computers. The connectoid includes all the settings you typically define in a VPN connection plus the quarantine scripts you write.

While not strictly necessary, it’s better to conduct most of the policy evaluation during the pre-tunnel script—the script that executes before the VPN connection. If you conduct the evaluation during the post-tunnel script, the remote client could be held in quarantine for a long time, using network resources unnecessarily. Typical checks include:

  • Is the remote client running a supported operating system?
  • Are antivirus and antispyware programs installed and running?
  • Are the corresponding signature files up to date?
  • Is the Windows Automatic Update client configured appropriately?
  • Are all available high-priority software updates installed?
  • Is a personal firewall configured and enabled?
  • Is Internet Connection Sharing disabled?

Although the remote client isn’t yet connected to the VPN, it’s still connected to the Internet, which is why I like evaluating the policy with the pre-tunnel script. So the script could remediate many failures—it could download and install signature updates, enable and configure the Automatic Update client, download and install high-priority updates from the Microsoft® Update site, switch on the Windows® Firewall, and switch off Internet Connection Sharing. The script probably shouldn’t install missing antivirus or antispyware programs; instead, include that with your VPN connectoid.

After the pre-tunnel script completes, it stores a result code in the registry. Next the connectoid establishes a connection to the RAS server, which applies the quarantine restrictions. The post-tunnel script reads the pre-tunnel result code from the registry and sends it to the RAS server; the server compares this code to its list of allowed codes and either drops the quarantine restriction or disconnects the remote client.

So what might cause the RAS server to drop a remote client that passed all the pre-tunnel checks? Say you’ve made a change to your quarantine policy—you want to add one more check during the pre-tunnel process. The remote client doesn’t yet know about your modification, so its current scripts will still pass the checks (remember, all the checks occur on the client). Only after the remote client connects to the RAS server will it learn that you’ve updated the policy. Now it can download an updated connectoid, disconnect, and restart the process.

The post-tunnel script can also perform additional checks and actions:

  • Call a script to check for pending password expirations and notify users whose passwords are about to expire.
  • Update the remote client’s computer Group Policy. Unless users select the "Logon using a dial-up connection" option, computer group policies don’t get applied at logon. It’s a problem if you use Group Policy to manage security on computers. A post-tunnel script that calls GPUpdate.exe ensures that most computer group policies are updated.

When you have greater confidence in both who is connecting remotely and what they’re connecting with, you’ve mitigated the many threats that remote access exposes you to. Now you can worry less about all those far-flung connections from who-knows-where. With a standardized method for remotely accessing your network, users can enjoy a consistent experience, management can rejoice over improved business processes and reduced costs, and administrators can relax because of simplified maintenance and, of course, improved security.

Steve Riley, a senior security strategist in the Microsoft Security Technology Unit and contributing editor for TechNet Magazine, jets around the world to speak at conferences and spend time with customers to help them get and stay secure. His latest book is Protect Your Windows Network (Addison-Wesley, 2005). You can reach him at steve.riley@microsoft.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.