If you are like most administrators, you work hard to make sure that software on your workstations is kept up to date. You simply can't have a secure network unless your workstations are secure. Keeping workstations secure means keeping the operating system and applications up to date with the latest patches and loading the latest definitions for anti-virus and anti-spyware programs.
As hard as it is keeping workstations on your network up to date, it's practically impossible to ensure that remote workstations such as laptops and home computers connecting via VPN are up to date. The typical home machine has no virus protection and is infected with about 800 different types of spyware and other Trojans. Is that what you want accessing your network?
The solution to this problem is to implement Network Access Quarantine Control (NAQC). The basic idea behind NAQC is that when a user dials into your network, a script is run that examines the user's PC to make sure that it meets the same security standards as the other computers on your network. If the machine passes the test, then the user is granted access to the rest of the network. If the machine's security isn't quite up to par, then the machine is quarantined until the user installs the necessary updates. The quarantine area can even be designed so that it automatically applies the necessary updates.
Before I show you how to implement NAQC, I should warn you that setting up NAQC is not for the faint of heart. The actual setup process isn't really all that bad, but you will need an advanced knowledge of scripting. The reason why is that you will have to write a script that looks to see if the remote machine is running up to date software. It isn't enough to say that you want to remote machine to be running Windows XP Service Pack 2. You will actually have to develop a script that checks to see if Service Pack 2 is present. The script must also specify the action to take if the correct service pack level is not installed.
Making quarantined resources available
The first step in setting up NAQC is that you must make some machines and some functions available to clients that have not yet met all of the qualifications to be released from Quarantine Mode. At a minimum, you must make a DNS Server and a DHCP Server available to remote clients. Some people also set up a file server that contains software updates. That way, clients that are not up to date can be updated on the fly.
For example, if you were requiring Windows XP Service Pack 2, and a client connected with Service Pack 1, you could have a script download Service Pack 2 from your file server and apply it to the client. You have to be careful when using this approach though because of software licensing. For example, if you required clients to be running Norton AntiVirus, you probably wouldn't want to configure your script to install a copy on remote machines that weren't already running Norton AntiVirus. Otherwise, anyone with a valid set of credentials could score a free copy of Norton AntiVirus at your expense just by dialing into the server.
There are a couple of different ways that you can make machines available to quarantined users. One way is to use machines that already exist on your network. However, you will have to create a separate packet filter for each machine if you take this approach. Your other alternative is to create a subnet that is used only by quarantined machines, and place dedicated servers into this subnet. This is the most secure and easiest to configure solution, but it is also the most expensive in terms of hardware and software costs. Which ever approach you use, you will have to make sure that you allow traffic to flow across TCP port 7250 since NAQC uses this port for notifier traffic.
Creating a client script
Earlier I mentioned that you will need an advanced knowledge of scripting in order to be able to implement NAQC. This is the part of the process in which you will need to create the script that the clients will run when they connect to your network access.
Unfortunately, I can't give you a lot of specific information here because the script tests to see if the client computer matches your company's security requirements, and every company's security requirements are different. What I can tell you is that you need to design your script so that if the compliance check is successful the script will call a file named RQC.EXE. You can get the RQC.EXE file from the Windows Server 2003 Resource Kit. The syntax for the call to the RQC.EXE file is as follows:
TunnelConnName TCPPort Domain Username ScriptVersion
As you can see, there are a lot of parameters that you have to specify with the RQC command. The good news is that some of the parameters that you have to specify can be derived from environment variables that are already in effect. For example, the ConnName parameter must be replaced by the connect id from the remote machine. However, you can acquire this value by using the variable %DialRasEntry%. In fact, the only parameters that you can't replace with environment variables are the TCPPort and ScriptVersion.
The TCPPort parameter should be replaced with the number 7250. The ScriptVersion can be any text string except for /0. Just make note of the script version that you use because you will have to match it on the RAS Server. For the purposes of this article, I will set the script version to 1. With this in mind, the RQC command in your script should look something like this:
%TunnelRasEntry% 7250 %Domain% %UserName% 1
Install the listener
The next step in the deployment process is that you must deploy the NAQC listener component onto the RAS Server. The listener component is more commonly referred to as RQS. When installed, Windows sets RQS as a dependency of the RRAS service. However, a bug in Windows causes RQS not to be automatically restarted when the RRAS service is restarted. Therefore if you ever have to stop or restart the RRAS service, you will also have to manually restart RQS.
RQS is found in the Windows Server 2003 Resource Kit Tools. Although there is a standalone file named RQS.EXE, RQS needs to be installed to the Windows\System32\RAS folder and a few registry entries need to be modified before RQS will be functional. The easiest way to deploy RQS is to use a batch file that's included with the resource kit tools. To do so, enter the following command:
Running the batch file will copy the RQS files and will create the necessary registry entries. However, you will need to modify one of the registry entries. In the last section, I mentioned that the script version number in the script needed to match the script version number on the RAS server. You must modify a registry entry and enter the number that you chose as your script version. Keep in mind that modifying the registry is dangerous. If you make a mistake you could destroy Windows and / or your applications. I therefore recommend backing up your RAS server before continuing.
With that said, use the REGEDIT command to open the Registry
Editor. Now, navigate through the registry tree to
With the RQS container selected, right click in an empty portion of the column on the right and select the New | String commands from the resulting shortcut menus. Create a new string named AllowedValue and then assign it the number that you used for your script version.
Create a connection profile
At this point, you will have to use the Connection Manager Administrator Kit (CMAK) to create a Quarantine Connection Manager profile. This profile will enable the script that you wrote earlier to run when a user connects.
In case you are not familiar with CMAK, it's actually a part of Windows Server 2003, but is not installed by default. You can install CMAK by opening the Add/Remove Programs Control Panel applet and clicking the Add/Remove Windows components button. When you do, you will see a list of the available Windows components. The Connection Manager Administration Kit is found within the Management and Monitoring Tools section.
After you have installed CMAK, you can launch it from Windows Administrative Tools menu. For the most part, the CMAK is pretty self explanatory. The process of creating a CMAK connection is fairly generic until you reach the Custom Actions screen.
Once you reach the Custom Actions screen, you will have to define a post connection action. To do so, select Post Connect from the Action Type drop down list and then click the New button. When you do, you will see a screen that allows you to fill in the parameters for the custom action that you are creating. Enter a description for the new action, and then enter the filename of the script that you wrote earlier in the Program to Run field. If you have any parameters that must be entered for the script to run, you can enter them in the Parameters field. Finally, select the Include the Custom Action Program With This Service Profile and the Program Interacts With The User check boxes and click OK.
From here you can continue filling in the wizard's screens in a generic manner. The only other thing special that you will have to do is when you get to the Additional Files screen, you will have to enter the RQC.EXE file. The reason why you have to do this is because upon successful confirmation of the client's configuration, your script calls the RQC.EXE file.
After you complete the CMAK wizard, the CMAK will compile the profile into an executable file under the filename that you provided during the wizard's initial steps. Your clients will need to use this executable to establish the connection to your RAS Server. Before they can do that though, you will have to give them a copy of the file. The easiest way to do this is usually to E-mail them a copy.
Configure the RAS server
The final step in the process involves creating an RRAS policy that will allow packets to flow across the necessary ports, but prevent other ports from being used. Begin by opening the RRAS Manager. Right click on the Remote Access Policies container and select the New | Remote Access Policy commands from the resulting shortcut menus. When you do, Windows will launch the New Remote Policy Wizard.
Click Next to bypass the wizard's Welcome screen. You'll then see the wizard's Policy Configuration Method screen. Enter Quarantined Connections as the policy name and click Next to continue. You will now see the Access Method screen. Select the VPN option and click Next.
At this point the wizard will display the User Or Group Access screen. If you haven't already got one, you will need to take a time out and create a group containing the users who will be allowed to access your network remotely. If everyone will be allowed to remotely access the network then you can just use the Authenticated Users group rather than creating a special group.
Once you've got a group that you can use, go back to the User or Group Access screen. Select the Group option, click the Add button, and enter the name of the group that you have created. Click OK followed by Next.
The next screen that you will see is the Authentication Methods screen. Just click Next to accept the defaults and you will move on to the wizard's Policy Encryption Level screen. Select the Strongest Encryption check box and deselect any other check boxes. Click Next, followed by Finish and the new remote access policy is created.
You have now created a fairly generic remote access policy. It's time to customize the policy. To do so, go back to the Remote Access Manager, right click on the policy that you've created, and select the Properties command from the resulting shortcut menu. When you do, you will see the policy's properties sheet.
The first thing that you will need to do is to select the properties sheet's Advanced tab and click the Add button so that you can add another attribute to the list. When you do, you will see a list of the attributes that you can add to the policy. Select the MS-Quarantine-Session-Timeout attribute from the list and click Add. When you do, you will see the Attribute Information dialog box appear. Enter 60 as the quarantine session value. Click OK twice to return to the policy's properties sheet.
You've added one attribute to the policy, but now you must add another. Click the Add button on the Advanced tab of the policy's properties sheet to reveal the list of attributes. Select the MS-Quarantine-IPFilter attribute and then click the Add button. This time instead of returning directly to the policy's properties sheet, you will see the IP Filter Attribute Information dialog box appear. Click the Input Filters button to display the Inbound Filters dialog box.
You must now create a filter that will only permit traffic
to flow across
Click OK to return to the Inbound Filters dialog box. You must now repeat the last set of steps to create filters that allow DHCP and DNS traffic. DHCP uses UDP ports 67 and 68, DNS uses UDP port number 53. Click OK three times to close the dialog boxes and save your changes. Once you've done that, you're set and ready to go!