What you need to know about NAC

How to choose the correct setup for your company

In today's world of data theft, worm and virus threats, and the need to comply with federal mandates, incorporating network access control (NAC) technology into your network infrastructure isn't an option but rather a critical necessity.

However, NAC isn't easy to define. It encompasses a broad range of meanings and methodologies. This article aims to clarify the basic points of NAC to help answer the question of what NAC setup is correct for your particular environment.

NAC is a policy enforcer and, as such, is closely tied to a company's business processes. Many wireless hot spots at restaurants, for example, employ basic NAC systems that require users to accept the conditions of an acceptable use policy before they are allowed to access the network.

This simple form of NAC works in this case, because the restaurant is providing only one simple network service -- that is, Internet access -- as a value-added benefit of visiting the establishment. However, setup like that certainly wouldn't be acceptable for other environments, such as a hospital network.

In order to answer the question of what type of NAC approach is right for your network, two prerequisites must be satisfied. The first, rather obvious one is an understanding of the NAC offerings that are available, what they do, how they do it, and how they integrate into the network. The second requirement is the presence of a clear, enforceable corporate security and access policy. NAC systems don't create policies; they enforce them. Without such policies, general corporate access decisions become the sole responsibility of the IT department (and that's never a good practice).

Digging into NAC

Achieving network access generally involves passing one of three types of tests. The first, as in the previous example of a wireless hot spot, can be satisfied by simply requiring users to agree to an acceptable use policy before allowing them to connect to the network. User identity and machine status have no bearing on whether access is granted or not; there is but one door, and it's either open or closed.

The second type of test validates user identity, and the third validates machine posture. These two tests are rarely used to either completely deny access or allow total access, with nothing in between. When a test that validates a user's identity is used, different levels of user access may be granted based on type of user, with the extremes being complete access for administrators and use of a limited set of applications (for example, only http and https) for guest users.

Machine posture refers to the state of the computer as it relates to an established security policy. If the policy mandates that a Windows machine have up-to-date operating system patches, connectivity is restricted until the patch requirement has been met. By ensuring that the machine meets the requirements of the security policy, damage from worms and viruses can be drastically reduced.

The limited connectivity that users are granted before full network connectivity is allowed is referred to as a "quarantine state." A quarantine state doesn't mean that all access is blocked. Rather, the security policy may allow, for example, a quarantined machine to have sufficient access to download updated antivirus software definition files. When planning a NAC deployment, it's necessary to understand the basic quarantine methods, their limitations and how they relate to your network infrastructure.

Quarantine methods

Since the early days of shared networks, manual quarantine methods have been implemented using access control lists on routers and switches. Policy parameters include source and destination IP addresses, TCP and User Datagram Protocol ports, IP protocol types, and MAC addresses. From a network architecture standpoint, this requires an inline (or in-band) implementation. Inline NAC methods automate the process of managing access control lists.

Another approach involves assigning virtual LANs (VLAN) to separate quarantined machines from the corporate network. One relatively simple method is to use Dynamic Host Configuration Protocol (DHCP) to assign a client to different networks. Not only does this method place the machine in a restrictive Layer 3 VLAN, it allows for the configuration of other client information, such as DNS servers. For example, all Web page requests could resolve to one internal Web server that displays the acceptable use policy with an "Accept" button.

In more sophisticated switch infrastructures, a NAC system may be used in conjunction with the switches to dynamically configure a machine's switch port to be a member of a certain VLAN. By default, all switch ports on the NAC-protected network are assigned to the quarantine VLAN with limited access. When the NAC system detects that the machine has met the NAC requirements, it instructs the switch to change the switch port feeding the machine to a less restrictive VLAN.

Some NAC systems employ 802.1x not only for authentication but also to use the Extensible Authentication Protocol to carry machine posture information. Like the VLAN port method, access based on the established security policy is achieved at the switch port level.

Then there is the method of Address Resolution Protocol (ARP) poisoning, which emulates an inline environment by manipulating the client's ARP table. The NAC appliance is placed at a switch tap point (sometimes referred to as a SPAN port) and responds to ARP requests for the gateway. The NAC injects its MAC address into the client's ARP table as the gateway, thereby forcing the client to send all nonlocal traffic to the NAC. Once the machine passes the NAC parameters, it's allowed to communicate with the correct gateway.

Each method isn't equal in protection, however. With the DHCP method, a savvy end user could assign his machine a known valid public address statically, thereby bypassing the DHCP quarantine VLAN altogether. ARP poisoning may be bypassed by creating a manual ARP entry for the gateway if the correct MAC address for the gateway is known. Most NAC systems have some countermeasures for these tactics, however.

The granularity of access must also be considered. For example, unlike port-level NAC solutions, the inline NAC provides rigid control to the corporate backbone and the Internet, but access to machines on the same side of the NAC isn't restricted. In other words, Machine A can still have complete access to Machine B if both are on the same switch behind the NAC.

User credentials

Verifying the identity of the user is a critical component of NAC systems. In the simplest case, as in coffee shops that offer wireless hot spots, a user is granted what can be called guest access if he agrees to abide by an acceptable use policy. In other cases, other methods of restricting access may be desirable.

In a simple authentication environment, a NAC can query a RADIUS server to determine if a user is authorized for full intranet and Internet access. If the user exists, and the password is correct, full access is given, whereas the default (nonauthenticated) policy may grant guests Internet access only for common ports (such as http, https and so on, as determined by the corporate security policy).

For more complicated environments in which, say, senior managers need access to ERP systems, network administrators need access to servers, and insurance adjusters need access to databases, policies based on user credentials may be created. By interfacing with Lightweight Directory Access Protocol (LDAP) or Active Directory servers, the type of user role can dictate the level of access authorized employees are granted to systems and applications.

From the user's perspective, authentication may be accomplished via several methods. The simplest form is Web-based; however, this requires opening a browser regardless of application to achieve access. Whatever the URL requested, the browser is redirected to a NAC log-in page. Other implementations use local software to pass authentication information.

Machine posture

The introduction of a single worm may cripple a corporate network, compromise data or render critical systems useless. It's no longer an option to have vulnerable machines on corporate networks. Most NAC implementations have some method of performing a vulnerability assessment on a client to check the machine for compromises or vulnerabilities and hardening them as the company's policy dictates.

There are three basic types of security posture assessment: external, internal and transport. An external assessment involves a central server performing a scan of the client machine. Many NAC systems employ a variation of Nessus scanning for vulnerabilities and malicious software. Clients protected by firewalls can reduce the effectiveness of this scanning, however.

An internal posture assessment involves installing an agent on the machine that can, in addition to handling authentication, perform assigned checks on the client and report the results back to the NAC system. For example, in a Windows environment, an antivirus installation produces a registry key that can be checked. Of course, it's conceivable that a key may be manually inserted to circumvent the process. In other cases, an agent can check for the presence of a specified file on the local machine, regardless of operating system.

Analyzing transport data is a more reactionary method. Like intrusion-prevention tools, NAC systems that use this approach scan network traffic and look for known malicious signatures. A machine that had once been granted full access but later became infected and began malicious activity would be shut off from network access. The difference between an IPS and NAC, however, is that the user is given the opportunity for self-remediation.

Some of the more advanced NAC systems take detection to a higher level by relying on operating system identification to determine which access policy should be applied. Typically, more checks are performed against Windows machines than against those that run other operating systems, because the number of exploits targeting Windows is far greater than the number of exploits targeting other operating systems. Obviously, it isn't possible to perform a registry check on a Linux machine.

Circumvention of the operating system detection is possible, depending on the type of detection method used. For example, if detection is based on what the client browser reports, the end user can simply reconfigure the browser so it appears to be running on a different operating system. Fortunately, methodologies of determining the operating system (such as by examining the TCP fingerprint) continue to grow more sophisticated, reducing the chance of such circumvention.

Open-source options

Certainly, some of the basic roots of NAC can be traced to open-source initiatives, and there are several open-source systems available with varying features. While NAC technology is established in the mainstream commercial market, an open-source option may be ideal depending on needs and the policy that the NAC system will enforce.

As a general rule of thumb, commercial systems have more features than their open-source counterparts, and they come with a greater level of support. But that's not always the case. And it doesn't mean that open-source offerings should be neglected. Several open-source systems have sophisticated detection, authorization and quarantine abilities.

Implementing open-source NAC systems requires patience and usually at least competent Linux administrator skills. Such implementations are usually built upon other open-source packages, can be installed on many Linux distributions and often have limited documentation. For example, my first attempt at running one open-source system failed because I had incorrectly configured a dependency package, not the open-source NAC software itself.

Why go with open source, then? If there's an open-source offering that has the features you need, and the technical aspects aren't overwhelming, the costs of deployment are substantially less. Furthermore, although traditional vendor support may not be available, in some cases there are third-party companies that provide support, and often the developers themselves are available to answer questions.

Bottom line

The NAC market continues to rapidly expand to meet the goal of providing secure network access. An excellent source for further information on NAC vendors, open-source systems and trends is the Internet2 consortium's Salsa-NetAuth working group Wiki.

The question isn't whether or not you need NAC technology on your network, it's what type of system works best in your particular situation. NAC hasn't become a prominent buzzword in networking without reason. With security and privacy concerns of networked resources at an all-time high, NAC is here to stay. How you implement it, however, could pay silent dividends or cost public losses.

For more information on NAC

We've gathered the best NAC news, reviews, opinion, in-depth features and more in this NAC Cram Session site.

Greg Schaffer is a freelance writer based in Tennessee. He has over 15 years of experience in networking, primarily in higher education. He can be reached at newtnoise@comcast.net.


Copyright © 2007 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon