Section 11.4. Network Access Quarantine Control

11.4. Network Access Quarantine Control

One of the easiest and arguably most prevalent ways for nefarious software or Internet users to creep onto your network is not through holes in your firewall, or brute-force password attacks, or anything else that might occur at your corporate headquarters or campus. It's through your mobile users, when they try to connect to your business network while on the road.

Consider why that is the case. Most remote users are authenticated only on the basis of their identity; no effort is made to verify that their hardware and software meet a certain baseline requirement. Remote users could, and do everyday, fail any or all of the following guidelines discussed next.

• The latest service pack and the latest security hotfixes are installed.

• The corporation-standard antivirus software is installed and running and the latest signature files are being used.

• Internet or network routing is disabled.

• Windows XP's ICF, or any other approved firewall, is installed, enabled, and actively protecting ports on the computer.

You would expect your business desktops to follow policy, but in the past, mobile users have traditionally been forgotten or grudgingly accepted as exceptions to the rule. However, Windows Server 2003 includes a new feature in its Resource Kit, called Network Access Quarantine Control (NAQC), which allows you to prevent remote users from connecting to your network with machines that aren't up-to-date and secure. NAQC provides a different sort of security and addresses a different, but equally important, sector of communications than VPN or IPSec.

As of this writing, NAQC is supported only on Windows-based clients. Macintosh, Unix, and Linux-based systems can't use NAQC.

This section will detail how NAQC works and how to install and configure it.

11.4.1. How It Works

NAQC prevents unhindered, free access to a network from a remote location until after the destination computer has verified the remote computer's configuration meets certain requirements and standards, as outlined in a script.

Figure 11-26 shows the pieces of this puzzle.

Figure 11-26. The IP Protocol Port screen

To use NAQC, your remote access clients must be running Windows 98 Second Edition, Windows Millennium Edition, Windows 2000, or Windows XP Home or Professional. These versions of Windows support a connectoid, which is simply a dial-up or VPN connection profile located in the Network Connections element in the user interface, containing three essential elements:

• Connection information, such as the remote server IP address, encryption requirements, and so on

• The baselining script, which is a simple batch file or program used to assess the suitability of the client computer (more on this in a bit)

• A notifier component, which talks to the destination network's backend machine and negotiates a lift of the client's quarantine

These elements are united into one profile using the Connection Manager (CM) Administration Kit (CMAK) in Windows Server 2003. Additionally, you'll need at least one Windows Server 2003 machine on the back end running an approved listening component; for the purposes of this chapter, I'll assume you're running the Remote Access Quarantine Agent service (called rqs.exe) from the Windows Server 2003 Resource Kit because that is the only agent available at press time. Finally, you'll need a NAQC-compliant RADIUS server, such as the Internet Authentication Service in Windows Server 2003, so that network access can be restricted using specific RADIUS attributes assigned during the connection process.

Under NAQC, when a client establishes a connection to a remote network's endpoint (a machine running RRAS), the destination DHCP server gives the remote, connecting computer an IP address, but an IAS server establishes a "quarantine mode."

In quarantine mode, the following restrictions are in effect:

• A set of packet filters is enabled that restricts the traffic sent to and received from a remote access client.

• A session timer is enabled that limits the duration of a remote client's connection in quarantine mode before being terminated.

Once the remote computer is in quarantine mode, the client computer automatically executes the baseline script. If Windows runs the script and is satisfied with the result, it contacts the listening service running on the Windows Server 2003 backend machine and reports this result. Then quarantine mode is removed and normal network access is restored. Otherwise, the client eventually is disconnected when the session timer reaches the configured limit, as described earlier.

11.4.2. A Step-by-Step Overview of NAQC

Here is a detailed outline of how the connection and quarantining process works, assuming you're using rqc.exe on the client end from the CMAK and rqs.exe on the back end from the Resource Kit:

1. The remote user connects his computer, using the quarantine CM connectoid to the quarantine-enabled connection point, which is a machine running RRAS.

2. The remote user authenticates.

3. RRAS sends a RADIUS Access-Request message to the RADIUS serverin this case, a Windows Server 2003 machine running IAS.

4. The IAS server verifies the remote user's credentials successfully and checks its remote access policies. The connection attempt matches the configured quarantine policy.

5. The connection is accepted, but with quarantine restrictions in place. The IAS server sends a RADIUS Access-Accept message, including the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout attributes, to RRAS.

6. The remote user completes the remote access connection with the RRAS server, which includes leasing an IP address and establishing other network settings.

7. RRAS configures the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout settings for the connection, now in quarantine mode. At this point, the remote user can only send traffic that matches the quarantine filtersall other traffic is filteredand can only remain connected for the value, in second, of the MS-Quarantine-Session-Timeout attribute before the quarantine baselining script must be run and the result reported back to RRAS.

8. The CMAK profile runs the quarantine script, currently defined as the "post-connect action."

9. The quarantine script runs and verifies that the remote access client computer's configuration meets a baseline. If so, the script runs rqc.exe with its command-line parameters, including a text string representing the version of the quarantine script being used.

10. rqc.exe sends a notification to RRAS, indicating that the script ended successfully.

11. The notification is received by rqs.exe on the back end.

12. The listener component on the RRAS server verifies the script version string in the notification message with those configured in the registry of the RRAS and returns a message indicating that the script version was either valid or invalid.

13. If the script version was acceptable, the rqs.exe calls the MprAdminConnectionRemoveQuarantine( ) API, which indicates to RRAS that it's time to remove the MS-Quarantine-IPFilter and MS-Quarantine-Session-Timeout settings from the connection and reconfigure the session for normal network access.

14. Once this is done, the remote user has normal access to the resources on the network.

15. rqs.exe creates an event describing the quarantined connection in the System event log.

11.4.3. Deploying NAQC

In this section, I'll look at the actual deployment of NQAC on your network. Deployment comprises six steps, each outlined in separate subsections.

11.4.3.1 Creating quarantined resources

The first step is to create resources that actually can be accessed while the quarantine packet filters are in place for a remote client. Examples of such resources include DNS servers and DHCP servers, so IP address and other connection information such as suffix addresses, DNS server addresses, and the like can be retrieved; fileservers to download appropriate software to update out-of-compliance machines; and web servers that can describe the quarantining process or allow a remote user to contact IT support via email if any problems occur.

You can specify and use a quarantined resource in two ways. The first is to identify certain servers, which can be spread across your network, as these quarantine resources. This allows you to use an existing machine to host the quarantined resources, but you also have to create individual packet filters for quarantined sessions for each existing machine. For performance and overhead reasons, it's best to limit the number of individual packet filters for a session.

If you decide to go this route, you'll need to enable the packet filters shown in Table 11-2.

Table 11-2. Packet filters for distributed quarantine resources

Traffic type	Source port	Destination port	Alternatives (instead of specifying port information)
Quarantine Notifier	None	TCP 7250	None
DHCP	UDP 68	UDP 67	None
DNS	None	UDP 53	You also can specify the IP address of any DNS server.
WINS	None	UDP 137	You also can specify the IP address of any WINS server.
HTTP	None	TCP 80	You also can specify the IP address of any web server.
NetBIOS	None	TCP 139	You also can specify the IP address of any file server.
Direct Hosting	None	TCP 445	You also can specify the IP address of any file server.

You also can configure any other packet filters that are particular to your organization.

The other approach is to limit your quarantined resources to a particular IP subnet. This way, you need just one packet filter to quarantine traffic to a remote user, but you might need to readdress machines and, in most cases, take them out of their existing service or buy new ones.

Using this method, the packet filter requirements are much simpler. You just need to open one for notifier traffic on destination TCP port 7250, one for DHCP traffic on source UDP port 68 and destination IDP port 67, and for all other traffic, the address range of the dedicated quarantine resource subnet. And again, you can configure any other packet filters that are particular to your organization.

Make sure the resources you make available to quarantined users are adequately hardened. Remember: you don't trust these machines, and they very well might be infected with worms, viruses, and other malware that can be detrimental to your quarantined resource machines. Ensure they are locked down tightly.

11.4.3.2 Writing the baselining script

The next step is to write a baselining script that will be run on the client. You can write this script in any scripting environment supported by your Windows clients, or even as a compiled EXE program. This script can check whatever you wantthere is no standard level of baseline, as it's only what you feel comfortable with letting onto your network. You also can use any sort of interaction with any program that your scripting environment will allow. The baseline script is very flexible and can use whatever software resources you have available.

Here is an example batch file script:

@echo off    echo Your remote connection is %1 echo Your tunnel connection %2 echo Your Windows domain is %3 echo Your username is %4    set MYSTATUS=      REM  Baselining checks begin here     REM  Verify Internet Connection Firewall is enabled.  Set CHECKFIRE  to 1-pass, 2-fail. <insert your various commands to check the ICF> REM  Verify virus checker installed and sig file up.  CHECKVIRUS is  1-pass, 2-fail. <insert your various commands to verify the presence of antivirus  software and sig file> REM  Pass results to notifier or fail out with message to user. if "%CHECKFIRE%" =  = "2" goto :NONCOMPLIANT if "%CHECKVIRUS%" =  = "2" goto :NONCOMPLIANT     rqc.exe %1 %2 7250 %3 %4 Version1-0 REM These variables correspond to arguments and switches for RQC.EXE REM %1 = %DialRasEntry% REM %2 = %TunnelRasEntry%  REM RQS on backend listens on port 7250 REM %3 = %Domain%  REM %4 = %UserName% REM The version of the baselining script is "Version1-0"     REM  Print out the status if "%ERRORLEVEL%" =  = "0" (       set ERRORMSG=Successful baseline check. ) else if "%ERRORLEVEL%" =  = "1" (       set ERRORMSG=Can't contact the RRAS server at the corporate        network. Contact a system administration. ) else if "%ERRORLEVEL%" =  = "2" (       set ERRORMSG=Access is denied. Please install the Connection        Manager profile from http://location and attempt a connection        again. ) else (       set ERRORMSG=Unknown failure. You will remain in quarantine        mode until the session timeout is reached.   ) echo %ERRORMSG% goto :EOF     :NONCOMPLIANT echo  echo Your computer has failed a baseline check for updates on echo your machine.  It is against corporate policy to allow out of echo date machines to access the network remotely.  Currently echo you must have Internet Connection Firewall enabled and echo an updated virus scanning software package with the echo latest virus signature files.  For information about how to  echo install or configure these components, surf to echo http://location. Echo You will be permitted to access only that location until Echo your computer passes the baselining check.     :EOF

Of course, this batch file is simple. I've added the necessary comments throughout the script so that you can follow the action. It's important to keep in mind that you can make the script as complex as you want; you even can compile a special program because the post-connect script option in CMAK allows a .exe file to be run.

The one requirement of every baseline script is that it must run rqc.exe if the baselining compliance check was successful and included the following parameters:

rqc ConnName TunnelConnName TCPPort Domain Username ScriptVersion

The switches and arguments are explained in the following list:

• The ConnName argument is the name of the connectoid on the remote machine, most often inherited from the dial-in profile variable %DialRasEntry%.

• The TunnelConnName argument is the name of the tunnel connectoid on the remote machine, most often inherited from the dial-in profile variable %TunnelRasEntry%.

• The TCPPort argument is, obviously, the port used by the notifier to send a success message. This default is 7250.

• The Domain argument is the Windows security domain name of the remote user, most often inherited from the dial-in profile variable %Domain%.

• The Username argument is, as you might guess, the username of the remote user, most often inherited from the dial-in profile %UserName%.

The ScriptVersion argument is a text string that contains the script version that will be matched on the RRAS server. You can use any keyboard characters except /0 in a consecutive sequence.

11.4.3.3 Installing the listening components

The Remote Access Quarantine Agent service, known otherwise as rqs.exe, must be installed on the Windows Server 2003 machines accepting incoming calls using RRAS. RQS is found in the Windows Server 2003 Resource Kit Tools download, which you can find on the Microsoft web site at http://www.microsoft.com/windowsserver. Once you've run the installer for the tools, select the Command Shell option from the program group on the Start menu, and run RQS_SETUP /INSTALL from that shell. This batch file will copy the appropriate binaries to the %SystemRoot%\System32\RAS folder on your system and modify service and registry settings so that the listener starts automatically when the server boots up.

To remove rqs.exe, type RQS_SETUP /REMOVE at a command prompt.

A bit of manual intervention is required, however, to finish the installation: you need to specify the version string for the baselining script. The listener service will match the version reported by the remote computer to the value stored on the RRAS computer to make sure the client is using the latest acceptable version of a script. This is a great way to enforce changes you make to your baseline scripts: if a user isn't using the latest version of the scripts (and therefore isn't making the latest analysis of the system based on your needs), he won't be released from the quarantine mode.

To make this change manually after you've run RQS_SETUP from the Tools download, follow these steps:

1. Open the Registry Editor.

2. Navigate to the HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/Rqs key.

3. Right-click in the right pane, and select New String.

4. Name the string AllowedValue.

5. Then, double-click the new entry, and enter the string that refers to an acceptable version of the script.

Alternatively, you can modify the RQS_SETUP batch file, so this step can be automated for future deployments. To do so, follow these steps:

1. Open the rqs_setup.bat file in Notepad.

2. Select Find from the Edit menu.

3. In Find what, enter Version1\0, and click OK. The text cursor should be on the following line: REM REG ADD %ServicePath% /v AllowedSet /t REG_MULTI_SZ /d Version1\0Version1a\0Test

4. To add just one acceptable version, delete REM from the beginning of the line.

5. Now, replace the text Version1\0Version1a\0Test with the script version string you want to be passed by rqc.exe.

6. If you want to add more than one acceptable version, you can replace the text Version1\0Version1a\0Test with the acceptable version strings, each separated by \0.

7. Save the file, and then exit Notepad.

RQS is set as a dependency of RRAS. However, when RRAS is restarted, RQS doesn't restart automatically, so you'll need to restart it manually if you ever stop RRAS manually.

By default, rqs.exe listens on TCP port 7250. To change the default TCP port, navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\rqs\ key, create a new REG_DWORD value called Port, and set it to the desired port.

11.4.3.4 Creating a quarantined connection profile

The next step is to create a quarantined Connection Manager profile, which happens to be a normal profile you might create for any standard dial-up or VPN connection, with only a few modifications. For one, you need to add a post-connect action so that your baselining script will run and return a success or failure message to the RRAS machine. You also need to add the notifier to the profile.

Let's look at using the CMAK to create a custom connectoid including the necessary NAQC components. Because the process is somewhat involved, I will only include screenshots of the steps specific to configuring a quarantined connection.

1. Open the CMAK from the Administrative Tools menu, and then click Next off the introductory screen.

2. Select Create a new service profile, and then click Next.

3. In the Service name box, type a name that you want to use for the connection. This should be something familiar to users, such as "Connect to Corpnet" or something similar.

4. In the File name box, type a name that you want to use for the service profile. This name is used for the files that CMAK creates while building the service profile. Do not use any of the following characters in the filename:

   <SPACE> ! , ; * = / \ : ? ' " < >

   
   

   Click Next.

5. I'll assume here that you do not have an existing CM profile to merge, so simply click Next to bypass the screen that appears that asks you to merge profile information.

6. If you want to add a line of support information to the logon dialog box, type it in the Support information boxfor example, For customer support, email [e-mail]. This is optional. Click Next when you've finished.

7. Specify whether the service requires a realm name, and then click Next.

8. If you want to configure custom Dial-Up Networking entries, click Add. In the Phone-book Dial-Up Networking entry dialog box, type the phonebook Dial-Up Networking entry that you want. Click Next.

9. Specify whether you want to assign specific DNS or WINS server addresses or a Dial-Up Networking script, and then click OK. Click Next.

10. If you want to add VPN support to the service profile, click to select the This service profile checkbox, and then click Next. Specify the server in the Server address box, specify whether you want to assign specific DNS or WINS server addresses and whether to use the same user credentials that are used for a dial-up connection, and then click OK. Click Next.

    (Here is where the quarantine steps begin.) The Custom Actions screen appears, and Figure 11-27 shows this.

    Figure 11-27. The Custom Actions screen of the CMAK Wizard

    
    
    

11. Select Post-Connect from the Action type drop-down box and then click the New button to add an action. The New Custom Action dialog box is displayed, as shown in Figure 11-28.

    Figure 11-28. The New Custom Action dialog box

    
    
    

12. Type a descriptive title for the post-connection action in the Description box. In Program to run, enter the name of your baselining script. You also can use the Browse button to look for it. Type the command-line switches and their arguments in the Parameters box. Finally, check the two bottom boxes, Include the custom action program with this service profile and Program interacts with the user.

13. Click OK, and you should return to the Custom Actions screen. Click Next.

14. Continue filling in the wizard screens as appropriate, until you come to the Additional Files screen, depicted in Figure 11-29.

    Figure 11-29. The CMAK Wizard Additional Files screen

    
    
    

15. Click Add, and then enter rqc.exe in the dialog presented next. You can use the Browse button to search for it graphically. Once you're finished, click OK.

16. You'll be returned to the Additional Files screen, where you'll see rqc.exe listed. Click Next.

17. Complete the remainder of the wizard as appropriate.

11.4.3.5 Distributing the profile to remote users

The profile you just created is made into an executable file that you can distribute to your remote users so that they can run it on their systems automatically, creating a profile without any intervention after that. You have several options for actually getting that executable file to your users.

You can transmit the executable file as an attachment to an email message, or better yet, as a link to the executable file hosted on a web server somewhere. In the email message, you can include instructions to run the file and use the new connectoids for all future remote access. You also can have the executable run as part of a logon or logoff script, but to do that, you need to either have your users log on through a dial-up connection, or wait until the mobile users return to the home network and are connected at the corporate campus to the network.

Regardless of which method you choose to initially transmit the profile installer to your users, you always should place the latest version of the profile installer on a quarantined resource somewhere, so client computers that don't pass your baselining script's compliancy checks can surf to a web site and download the latest version without compromising further the integrity of your network.

11.4.3.6 Configuring the quarantine policy

The final step in this process is to configure the actual quarantine policy within RRAS. In this section, I'll create a quarantine policy within RRAS that assumes you've posted the profile installer on a web server that is functioning as a quarantined resource.

If RRAS is configured to use the Windows authentication provider, RRAS uses Active Directory or an NT4 domain (remember, the RRAS machine needs only to be running Windows Server 2003; it doesn't need to belong to an Active Directory-based domain) to authenticate users and look at their account properties. If RRAS is configured to use RADIUS, the RADIUS server must be a Server 2003 machine running IAS. Incidentally, IAS also uses Active Directory as an NT domain to authenticate users and look at their account properties.

1. Open the RRAS Manager.

2. In the left-pane, right-click Remote Access Policies, and then select New Remote Access Policy from the context menu. Click Next through the introductory pages.

3. The Policy Configuration Method page appears. Enter Quarantined VPN remote access connections for the name of this policy, as shown in Figure 11-30. Click Next when you're finished.

   Figure 11-30. The Policy Configuration Method screen

   
   
   

4. The Access Method page appears next. Select VPN, and click Next.

5. On the User or Group Access page, select Group, and click Add.

6. Type in the group names that should be allowed to VPN into your network. If all domain users have this ability, enter Everyone or Authenticated Users. I'll assume this domain has a group called VPNUsers that has access to VPN capabilities. Click OK.

7. You'll be returned to the User or Group Access page, and you'll see the group name you added appear in the list box, as shown in Figure 11-31. Click Next if it looks accurate.

   Figure 11-31. The User or Group Access screen

   
   
   

8. The Authentication Methods page appears. To keep this example simple, use the MS-CHAP v2 authentication protocol, which is selected by default. Click Next.

9. On the Policy Encryption Level page, make sure the Strongest Encryption setting is the only option checked. This is shown in Figure 11-32. Then, click Next.

   Figure 11-32. The Policy Encryption Level screen

   
   
   

10. Finish out the wizard by clicking Finish.

11. Back in RRAS Manager, right-click the new Quarantined VPN remote access connections policy, and select Properties from the context menu.

12. Navigate to the Advanced tab, and click Add to include another attribute in the list.

13. The Add Attribute dialog box is displayed, as depicted in Figure 11-33.

    Figure 11-33. The Add Attribute dialog box

    
    
    

14. Click MS-Quarantine-Session-Timeout, and then click Add.

15. In the Attribute Information dialog box, type the quarantine session time in the Attribute value box. Use a sample value of 60, which will be measured in seconds, for the purposes of this demonstration. Click OK, and then OK again to return to the Advanced tab.

16. Click Add. In the Attribute list, click MS-Quarantine-IPFilter, and then click Add again. You'll see the IP Filter Attribute Information screen.

17. Click the Input Filters button, which displays the Inbound Filters dialog box.

18. Click New to add the first filter. The Add IP Filter dialog box is displayed. In the Protocol field, select TCP. In the Destination port field, enter 7250. Click OK.

19. Now, back on the Inbound Filters screen, select the Permit only the packets listed below radio button. An example of the Inbound Filters screen is presented in Figure 11-34.

    Figure 11-34. The Inbound Filters screen

    
    
    

20. Click New and add the input filter for DHCP traffic, repeating the preceding steps and including the appropriate port number and type as described in Table 11-2 earlier in this chapter. Follow the same directions to allow DNS and WINS traffic.

21. Click New and add an input filter for a quarantine resource, such as a web server, where your profile installer is located. Specify the appropriate IP address for the resource in the Destination network part of the Add IP Filter screen, as shown in Figure 11-35.

    Figure 11-35. The Add IP Filter box, adding a quarantined web resource

    
    
    

22. Finally, click OK on the Inbound Filters dialog box to save the filter list.

23. On the Edit Dial-in Profile dialog box, click OK to save the changes to the profile settings.

24. Then, to save the changes to the policy, click OK once more.

11.4.3.7 Creating exceptions to the rule

Although it is certainly advantageous to have all users connected through a quarantined session until their configurations can be verified, your organization might have logistical or political problems that mitigate this requirement. If so, the simplest way to excuse a user or group of users from participating in the quarantine is to create an exception security group with Active Directory. The members of this group should be the ones that need not participate in the quarantining procedure.

Using that group, create another policy that applies to the exceptions group that's configured with the same settings as the quarantine remote access policy you created earlier in the chapter. This time, though, don't add or configure either the MS-Quarantine-IPFilter or the MS-Quarantine-Session-Timeout attributes. Once the policy has been created, move the policy that applies to the exceptions group so that it is evaluated before the policy that quarantines everyone else.