Six steps for deploying Network Access Quarantine Control

In this excerpt from "Hardening Windows," you'll look at the actual deployment of NAQC on your network. There are six steps, each outlined in separate subsections.

The following excerpt, courtesy of Apress, is from Chapter 7 of the book "Hardening Windows" written by Jonathan Hassell. Click for the complete book excerpt series or purchase the book.


Six steps for deploying Network Access Quarantine Control

In this section, you'll look at the actual deployment of NAQC on your network. There are six steps, each outlined in separate subsections ahead.

To help you navigate this excerpt more quickly and easily, please use the following guide.

  TABLE OF CONTENTS
   Creating quarantined resources
   Writing the baseline script
   Installing the listening components
   Creating a quarantined connection profile
   Distributing the profile to remote users
   Distributing Configuring the quarantine policy
   Creating exceptions to the rule

 


Creating quarantined resources
Return to Table of Contents

The first step is to create resources that you can actually access while the quarantine packet filters are in place for a remote client. Examples of such resources include DNS servers and DHCP servers, so you can retrieve IP address and connection information and file servers that will download the appropriate software to update out-of-compliance machines. In addition, you can retrieve Web servers that may describe the quarantining process or allow a remote user to contact IT support via e-mail if any problems occur.

There are two ways you can specify and use a quarantined resource. The first is to identify certain servers on your network because these quarantine resources without regard to their physical or network location. This allows you to use existing machines to host the quarantined resources, but you also have to create individual packet filters for quarantined sessions for each of these existing machines. 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 7-1.

Table 7-1. Packet filters for distributed quarantine resources

 

Traffic type Source port Destination port Alternatives
Notifier n/a TCP 7250 None.
DHCP UDP 68 UDP 67 None.
DNS n/a UDP 53 You can also specify the IP address of any DNS server.
WINS n/a UDP 137 You can also specify the IP address of any WINS server.
HTTP n/a TCP 80 You can also specify the IP address of any Web server.
NetBIOS n/a TCP 139 You can also specify the IP address of any file server.
Direct hosting n/a TCP 445 You can also specify the IP address of any file server.

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

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


Writing the baseline script
Return to Table of Contents

The next step is to actually write a baseline script that will be run on the client. This is really independent to your organization, but all scripts must run RQC.EXE if the baseline compliance check was successful and they should include the following parameters:

The switches and arguments are explained in the following list:

 

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

  • The TunnelConnName argument is the name of the tunnel connectoid on the remote machine, which is 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, which is most often inherited from the dial-in profile variable %Domain%.

  • The Username argument is, as you might guess, the username of the remote user, which is 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.

Here is a sample batch file script:

@echo off

echo Your remote connection is %1
echo Your tunnel connection is %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 live.
REM Set CHECKFIRE to 1-pass, 2-fail.

REM Verify virus checker installed and sig file up.
REM CHECKVIRUS is 1-pass, 2-fail.
[insert various commands to verify the presence of AV 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 administrator.
) 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.

Of course, the batch file is simple. You can make it as complex as you like; you can even compile a special program, because the postconnect script option in CMAK allows you to run an .exe file.


Installing the listening components
Return to Table of Contents

The Remote Access Quarantine Agent service, known otherwise as RQS.EXE, must be installed on the Server 2003 machines that are 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. 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 WindowsRootSystem32RAS folder on your system and modify the service and Registry settings so that the listener starts automatically when the server boots up.

 

NOTE
To remove RQS.EXE, type RQS_SETUP/REMOVE at a command prompt.

There's a bit of manual intervention required, however. You need to specify the version string for the baseline script. The listener service will match the version reported by the remote computer to the value stored on the RRAS computer so you can make sure that the client is using the latest acceptable version of a script. To make this change manually after you've run RQS_SETUP from the Tools download, do the following:

1. Open the Registry Editor.
2. Navigate to the HKEY_LOCAL_MACHINESystemCurrentControlSetServicesRqs key.
3. Right-click in the right pane, and select New String.
4. Name the string AllowedValue.
5. 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. Do the following:

1. Open the RQS_SETUP.BAT file in Notepad.
2. Select Find from the Edit menu.
3. In Find What, enter Version10, and click OK. The text cursor should be on a line that says: REM REG ADD %ServicePath% /v AllowedSet / t REG_MULTI_SZ /d Version10Version1a0Test.
4. To add just one acceptable version, delete "REM" from the beginning of the line.
5. Now, replace the text "Version10Version1a0Test" with the script version string you want to be passed by RQC.EXE.
6. If you want to add more than one acceptable version, replace the text "Version10Version1a0Test" with the acceptable version strings, each separated by the "0" line.
7. Save the file, and then exit Notepad.

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

 

NOTE
By default, RQS.EXE listens on TCP port 7250. To change the default TCP port, navigate to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesrqs key, create a new REG_DWORD value called Port, and set it to the desired port.


Analyzing Creating a quarantined connection profile
Return to Table of Contents

The next step is to create a quarantined Connection Manager profile, which happens to be a plain-vanilla profile with a few modifications. For one, you need to add a postconnect action so that your baseline script will run and return a success or failure message to the RRAS machine. You also need to add the notifier to the profile.

In this section, I'll assume you're familiar with creating custom connectoids with the Connection Manager Administration Kit (CMAK) wizard, because the whole process is beyond the scope of this chapter and this book. The process begins to differ at the Custom Actions screen (shown in Figure 7-1), so I'll begin this procedural outline there:

1. Navigate to the Custom Actions screen, and fill in subsequent screens as appropriate.


Figure 7-1. The Custom Actions screen of the CMAK wizard

2. Select Post-Connect from the Action type drop-down list, and then click the New button to add an action.
3. The New Custom Action dialog box is displayed, as shown in Figure 7-2.
4. Type a descriptive title for the postconnection action in the Description box. In Program to Run, enter the name of your baseline script. You can also 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.
5. Click OK, and you should return to the Custom Actions screen. Click Next.
6. Continue filling in the wizard screens as appropriate, until you come to the Additional Files screen, as depicted in Figure 7-3.


Figure 7-2. The New Custom Action dialog box


Figure 7-3. The CMAK wizard Additional Files screen

7. Click Add, and then enter RQC.EXE in the dialog box. You can use the Browse button to search for it graphically. Once you're finished, click OK.
8. You'll be returned to the Additional Files screen, where you'll see RQC.EXE listed. Click Next.
9. Complete the remainder of the wizard as appropriate.


Distributing the profile to remote users
Return to Table of Contents

The profile you created earlier is made into an executable file that can be distributed to your remote users and run on their systems automatically. This creates a profile without any intervention after that. There are several options for actually getting that executable file to your users.

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

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


Configuring the quarantine policy
Return to Table of Contents

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.

 

NOTE
If RRAS is configured to use the Windows authentication provider, then RRAS uses Active Directory or an NT 4 domain (remember, the RRAS machine needs only to be running 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, then the RADIUS server must be a Server 2003 machine running Internet Authentication Service (IAS). Incidentally, IAS also uses Active Directory, which is 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 7-4. Click Next when you've finished.


Figure 7-4. The Policy Configuration Method screen

4. The Access Method screen appears. Select VPN, and then click Next.
5. On the User or Group Access screen, select Group, and then 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 there's a group called VPNUsers on this domain that should have 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 7-5. Click Next if it looks accurate.


Figure 7-5. The User or Group Access screen

8. The Authentication Methods screen 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 screen, make sure the Strongest Encryption setting is the only option checked, as shown in Figure 7-6. Then click Next.


Figure 7-6. 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 7-7.


Figure 7-7: 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 field. Use a sample value of 60, which will be measured in seconds, for 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, as shown in Figure 7-8.


Figure 7-8. The IP Filter Attribute Information dialog box

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, go back to the Inbound Filters screen, and select the Permit Only the Packets Listed Below option. Your screen should look like Figure 7-9.


Figure 7-9. The completed Inbound Filters screen

20. Click New and add the input filter for DHCP traffic, and repeat the previous steps. Make sure to include the appropriate port number and type as described earlier in this chapter.
21. Click New and add the input filter for DNS traffic, and repeat the previous steps. Make sure to include the appropriate port number and type as described earlier in this chapter.
22. Click New and add the input filter for WINS traffic, and repeat the previous steps. Make sure to include the appropriate port number and type as described earlier in this chapter.
23. 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 7-10.


Figure 7-10. The Add IP Filter box, where you add a quarantined Web resource

24. Finally, click OK on the Inbound Filters dialog box to save the filter list.
25. On the Edit Dial-in Profile dialog box, click OK to save the changes to the profile settings.
26. Then, to save the changes to the policy, click OK once more.

Creating exceptions to the rule
Return to Table of Contents

Although it's certainly advantageous to have all users connected through a quarantined session until you can verify their configurations, you may find some logistical or political problems within your organization 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, you should create another policy that applies to the exceptions group, which is 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 you've created the policy, move the policy that applies to the exceptions group so that it's evaluated before the policy that quarantines everyone else.

 


Click for the book excerpt series or visit here to obtain the complete book.


 

This was first published in November 2004

Dig deeper on Windows Server Virtualization and Microsoft Hyper-V

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchExchange

SearchSQLServer

SearchWinIT

SearchEnterpriseDesktop

SearchVirtualDesktop

Close