|
|
11.5. Network Access Quarantine ControlOne 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:
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.
This section will detail how NAQC works and how to install and configure it. 11.5.1. How It WorksNAQC prevents unhindered, free access to a network from a remote location until the destination computer has verified the remote computer's configuration meets certain requirements and standards, as outlined in a script. Figure 11-39 shows the pieces of this puzzle. Figure 11-39. How NACQC works
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:
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:
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.5.2. A Step-by-Step Overview of NAQCHere 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:
11.5.3. Deploying NAQCIn this section, I'll look at the actual deployment of NQAC on your network. Deployment comprises six steps, each outlined in separate subsections. 11.5.3.1. Creating quarantined resourcesThe 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 that 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.
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.
11.5.3.2. Writing the baselining scriptThe 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:
11.5.3.3. Installing the listening componentsThe 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.
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:
Alternatively, you can modify the RQS_SETUP batch file, so this step can be automated for future deployments. To do so, follow these steps:
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.
11.5.3.4. Creating a quarantined connection profileThe 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.
11.5.3.5. Distributing the profile to remote usersThe 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. Figure 11-42. The CMAK Wizard Additional Files screen
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.5.3.6. Configuring the quarantine policyThe 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.
11.5.3.7. Creating exceptions to the ruleAlthough 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 force you to create exceptions to 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.  |
|
|
