Get started Bring yourself up to speed with our introductory content.

Managing Windows network access security tutorial

Learn to control network access and get a comparison between NAQC and NAC in our network access control learning guide.

This guide is designed to help network admins control network access. There are many areas you need to be cognizant of when securing a Windows network, like VPNs, remote access and telecommuters, securing network endpoints and network firewalls. If you overlook any of these access points, you run the risk of losing critical data to any degree of hacker, from the relatively benign hacker to the most advanced cyber criminals. This learning guide on controlling network access will provide several tips and tools to teach you how to manage network access and keep your network as secure as possible.

Table of contents

Microsoft network access protection with NAP and NAQC
Microsoft network endpoint security tips and tactics
Remote access security measures
VPN security testing and maintenance
Microsoft Windows Firewall security

  NAP and NAQC

There are several ways to beef up security and prevent malicious hackers from entering your network. In the opening section of our network access control learning guide, well discuss two ways you can do that; by using Network Access Quarantine Control and Network Access Protection. These two services help you as a Windows security admin to manage who can and cannot enter your network and how you can beef up the security of your perimeter, endpoints and mobile users.

How does NAQC work?

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

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.

Create quarantined resources

You need 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 e-mail 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.

Write 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 want -- there 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.

Install 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. 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%System32RAS 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.

Create 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.

Distribute the profile to remote users

The profile you just created is made into an executable file. You can distribute this profile 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 e-mail message, or better yet, as a link to the executable file hosted on a web server somewhere. In the e-mail 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.

Configure 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.

Network Access Quarantine Control vs. Network Access Protection

With the number of mobile devices and remote workers growing, network quarantining has been a popular topic lately. Contributor and Network Access Quarantine Control expert Jonathan Hassell compares the features of NAQC with Network Access Protection (NAP) and advises on if and when to deploy a network quarantining solution.

The difference between NAQC and NAP

The biggest difference between NAQC and NAP is scope: NAQC protects just against machines outside your perimeter that attempt to connect to your network. NAP does that, too, but it takes protection a step further by enforcing policies on computers directly connected to the LAN, including mobile computers that come back to the home office and that connect occasionally. This closes a serious loophole in NAQC coverage.

Should you deploy NAQC now?

A lot of administrators are wondering whether to go ahead and deploy Microsoft's existing quarantining solution, NAQC, when there's clearly a superior release on the horizon. You might also be considering an investment in Cisco's quarantining solution, Network Access Control -- the primary selling point being hardware-based control of policies that isn't dependent on the operating system software.

In either case, my recommendation is not to wait. In terms of NAQC, for one, the probability that a remote user will infect your premises grows with each passing day, particularly as more locations where mobile users frequent offer unfettered, unfirewalled, completely insecure Internet access. Second, the protection offered to your mobile users can still continue with NAP in its current form, so you don't exactly lose by making the effort to deploy NAQC now. Finally, some security is better than none at all. The only cost of NAQC now is time; you have the tools you need that are freely available. Why not take advantage of them and introduce the concept of quarantining in your organization? In terms of deploying Cisco's solution, consider your investment well protected. NAP and NAC are fully interoperable and compatible.

Active Directory Security School

No matter how secure all the layers of your network might be, poor Active Directory (AD) security can render the rest of your security measures useless. Find the answers to all of your AD questions in the Active Directory security school.

Hunting down a hacker

If you've ever discovered that your network has been hacked, you've probably wondered how to track down the hacker. Learning who has accessed your network is a function of the auditing capabilities of the file server and can be enabled using the native tools. This is done by enabling the Auditing functionality in the Auditing Tab of the Advanced Security settings for the given folders/file system. You also have to enable the appropriate Audit Policy for your environment using Group Policy/the Local Security Policy of the system in question. Unfortunately, if you weren't auditing to begin with, there won't be a historical record.

If you are going to enable this degree of auditing, I would strongly recommend the use of third-party log management/security monitoring tools such as NetIQ Security Manager, LogLogic or ArcSight ESM. These tools can both manage the quantity of logs as well as the volume of events. Doing otherwise, in my experience, results in auditing policies that are effectively worthless because data is near impossible to find. It is also difficult to manage the volume of data (which can exceed gigabytes of data per day).

Dig Deeper on Windows Server troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.