Nearly three years ago I described the fundamentals of Network Access Control ("The Tech of NAC," October 2006, Article ID 20690), explaining how NAC works and its promise as a useful tool for securing Ethernet LANs. A year after that ("Be a NAC Ninja," November 2007, Article ID 21065) I showed you step-by-step how to implement basic NAC. Armed with that knowledge and a burgeoning market of nascent NAC products, I fully expected all of us to be immersed in NAC by 2009.
Alas, something happened to NAC on the way to ubiquity. Despite its promise as a needed access control layer for otherwise alarmingly exploitable Ethernet ports, NAC has failed to catch fire as some predicted. The problem isn't a lack of products—NAC software, high-speed switches, and control appliances abound, and it's built into Windows Server 2009. But the problem may well be the unfortunate tendency of vendors to push the envelope on standards, creating their own proprietary extensions in an effort to differentiate themselves from the crowd.
As a result of that proprietary competitiveness, the NAC product ecosystem is full of unique, cleverly designed, but largely incompatible critters. Developers saw the elegant, well-designed 802.1x framework with its client-side supplicant, network-based authenticator, and centralized RADIUS authorization server as an invitation to get inside end-user computers and control the dickens out of them. The end result is a product space so complex that potential customers give up, unable to make apple-to-apple comparisons and unable to implement NAC without a forklift.
Yet NAC, at its most basic level, is still a valuable service, greatly enhancing network security with virtually no inconvenience to users, at least when properly implemented. NAC is worth deploying, but to get there cost effectively you have to separate architecture from marketecture to discover the minimum feature set worth pursuing. You also need to be aware of some new Ethernet use cases that vendors trumpet as requiring their "secret sauce" to handle. You'll then be prepared to get moving with NAC now.
NAC the Knife
For a detailed look at NAC internals and implementation, I recommend you review the aforementioned articles. The essential idea of NAC, however, is easy to summarize: NAC ensures that every user or device plugging into an enterprise Ethernet port is either authenticated by qualified credentials or authorized in advance by MAC address. NAC can also perform device integrity checks such as antivirus and firewall status, operating system patch level, and past history. If necessary, NAC can repair a device (e.g., install the latest OS patches) before connecting. And once connected, NAC can enforce access policies that limit where users can travel on your LAN.
The point many potential NAC users often miss, however, is that you don't have to roll out all of those capabilities at once, or even roll out most of them ever. Ninety percent of the value of NAC is just making sure Ethernet users are authenticated. This single, simple control heads off a slew of common network disasters, such as virus invasions via conference room ports, unauthorized snooping in the warehouse, and hackers invading through rogue WiFi access points.
This basic level of NAC protection requires no vendor-proprietary software or expensive hardware upgrades. If you eschew the flashy post-authentication processes of NAC, you can immediately enjoy the benefit of a secure Ethernet. Then take your time investigating products, selecting those that have modular components that interoperate well with basic NAC, letting you add features one at a time. You'll also give your users time to adapt to the idea of NAC—although it's very transparent, it's not totally invisible—and give your enterprise time to absorb policy changes that NAC requires. Living with NAC is not difficult, and the security payback is immense. You may encounter some rough spots along the way, both in the form of user resistance and with new uses for Ethernet that basic NAC may not seem to support. Before explaining solutions to those potential problems, it's worth reviewing a sane strategy for NAC deployment.
When and if you do decide to move to more rigorous NAC protections such as health checking and remediation, be aware that you'll likely have to install a special vendor-specific NAC "agent" on each protected computer. This agent is what interacts with the NAC controller to carry out various health assessment and repair tasks. The agent can also be problematic for mobile users who have to connect to other networks. The whole process of distributing and maintaining agent code more than doubles the complexity of NAC, a fact that you should weigh carefully in deciding on future NAC objectives.
Avoiding NAC Attack
Successfully deploying basic NAC requires careful assessment of your user population and their needs. Simply plopping NAC onto your network without this prep work will cause many existing, legitimate Ethernet connections—both users and peripheral devices such as printers and scanners—to stop working, leading to end-user frustration. Users want the network to help them, not attack them, so maintaining transparency is the aim of the assessment process. The first step of that assessment is ensuring that your LAN is free of NAC-incompatible switching devices.
All an Ethernet switch needs to work with NAC is support for the 802.1x authentication protocol. 802.1x support is already built into standard desktop operating systems, be they Windows, Mac, or Unix. Once an 802.1x switch is configured to authenticate users, it invokes the 802.1x authentication process on the end-user device, prompting the user for their credentials (or automatically reading them from the hard drive, in the case of certificate-based authentication. Virtually all managed Ethernet switches manufactured since 2001 support 802.1x, so your LAN likely is largely NAC-enabled already. But non-managed switches have a way of creeping into the enterprise LAN—that $10 hub in the corporate boardroom, for example—and you will have to ferret those out and replace them with NAC-compliant devices.
Fortunately the cost of managed switches has plummeted in recent years—you'll have no problem finding compatible products for under $10/port. But in order to exploit the 802.1x feature, you'll have to get all your switches into your network management infrastructure, which means assigning them IP addresses and secure passwords and SNMP community strings. Until this basic footwork is done, don't even think of trying out NAC. By design, 802.1x assumes that all of your Ethernet ports connect to one and only one device (although there is one exception discussed a bit later).
The second preparatory step toward NAC is assessing user requirements. You'll need an accurate inventory of every Ethernet device and its role—is it a laptop, workstation, peripheral, or infrastructure component. That's easy to accomplish using off-the-shelf network discovery software, which scans your LAN and enumerates devices. You can look up a device's MAC address in the IEEE Organizationally Unique Identifier list (standards.ieee.org/regauth/oui/oui.txt), or your discovery tool might do that for you automatically. Devices that can't run an 802.1x client, such as printers, routers, and other peripherals, must either be locked down by MAC address to the port they're currently using or simply physically secured to protect against tampering. End-user workstations will all need some form of authentication credentials stored in a central database. In most cases that can be your existing Windows or LDAP enterprise authentication store. You may encounter some general-purpose workstations that don't "belong" to anyone; you can assign these default credentials or provide a physical token, such as a USB key or digital certificate, to automatically authenticate them.
As a final step in the assessment, you must categorize devices as fixed or mobile. Fixed devices should be locked to a specific Ethernet port when possible, to prevent their credentials from being used to authenticate an interloper on some other port. Mobile devices such as laptops should ideally be locked into a separate VLAN. They can plug in anywhere and automatically gain access to that VLAN, but you can apply controls to limit their access to internal resources where appropriate.
Trial Run
After the assessment you can configure a small set of switches and NAC authentication servers to turn on NAC in report-only mode to test the authentication process without actually blocking any user access. You'll have briefed users already on the password or token login process for your NAC implementation. At worst this means a user will be prompted for login credentials when they first attach to the network, but you can make that even less intrusive through the use of pre-installed digital certificates. In many cases you can push out those certificated without visiting the end-user computer, using, for example, Windows Group Policies. Each certificate is unique for every user, and should be stored with administrator-only permissions to prevent tampering.
This first trial run lets you validate your NAC configuration without affecting your entire LAN, and with no danger of blocking user access. Carefully review the NAC authentication logs to find failures and investigate them. You may need to adjust your end-user training before the big rollout, or possibly add additional hard-coded MAC authentication.
You can follow up the initial trial with a larger-scale test—keeping NAC in report-only mode—to introduce more users to the authentication concept. It's probably worth running this way for several weeks to ensure you've ironed out all the bugs and that users are adapting to the new login requirements. It's critical to keep reviewing logs to find problem cases and address them. When you're satisfied you've covered all the exceptions, you can begin the go-live process.
You've been very careful to this point, making small changes that you can easily reverse should problems arise. Taking NAC fully operational requires the same care: bring up one switch at a time and verify that users on that switch are successfully operating before moving on to the next switch. A gradual turn-up will let you catch any last-minute oversights and insulate you from a flood of tech support calls should something major go wrong.
Special Cases
During the assessment process you're likely to run into one or more special cases. NAC is flexible, and many NAC devices have 802.1x-compatible workarounds for these cases. Some have proprietary workarounds that, while not ideal, may be worth exploiting in the short term to get around a problem.
The most common special case is a mobile device that you can't lock down by MAC address but that also doesn't support 802.1x. This is a case that purely standard NAC truly doesn't cover, but one where a common workaround has been developed by several vendors: http authentication. In this scenario, you can configure a NAC-protected port to fall back to "web capture" mode, which captures any attempted HTTP request by the user and displays in response an HTML log-in screen. If the user can enter their credentials on this panel, NAC will authenticate them like any 802.1x-compliant user, nicely circumventing the failure. This is often a useful mode with which to configure conference room ports that may be used by guests. You can provide them with guest credentials that authorize the guests to a special, isolated VLAN limited to web surfing.
Another special case is piggybacked Ethernet devices that share a single physical port but use separate VLANs. The most common example is a VoIP phone that has a pass-through port for the end user's computer. VoIP traffic flows on one VLAN, while user traffic flows on another, simulating two physical ports and saving the cost of installing an entirely separate Ethernet physical plant for VoIP. Handling this requires an 802.1x workaround called multi-auth that not all switches support. You'll have to check your existing switch specs to see if you already have this option or upgrade switches for ports that need it. Multi-auth can sometimes be used to accommodate multiple users connecting through an unmanaged, non-802.1x Ethernet switch, but each user will require a unique VLAN to be fully secured. It's far wiser, though, to simply replace the unmanaged device with a managed one.
Note that this is an 802.1x "workaround." Recall that 802.1x assumes one device per switch port. Multi-auth is not a part of 802.1x; it's a vendor extension that has been implemented somewhat consistently across vendor products, making it reasonably reliable. However, you should test your vendor's implementation to make sure a switch doesn't simply admit all users once one is authenticated.
The last special case we'll consider here is the use of personal wireless "hotspots"—small access points that users often bring into work areas or conference rooms to enable convenient multi-user collaboration. Users like these devices because they simplify peer-to-peer file sharing and are more convenient than dealing with multiple sets of access credentials. There is danger here, however, in letting users usurp security for convenience. Although you want NAC protection to be as unobtrusive as possible, users will always face some inconveniences, and a policy against personal hotspots may be one of them.
The problem with these hotspots is that they are really routers, and thus appear to the switch as a single device masking potentially dozens of individual users. When a user plugs a personal WiFi device into the LAN and tries to gain access through an associated laptop, NAC will properly authenticate the user and let her in. But traffic from any new users that associate with the wireless device looks to the switch as if it's coming from the original now-authenticated user.
Currently standard NAC has no workaround for this, and proprietary workarounds are limited at best. Some let you lock out devices with MAC addresses known to be used by WiFi routers, but the WiFi devices support MAC cloning to circumvent that block. The best you can do is to prohibit these devices by policy. Exploiting personal WiFi requires at least one user with credentials, and that user is subject to your policy. You should make the policy highly visible and remind users of it often. And penalties for violation should be serious enough to be a deterrent.
NAC Now
It's true that NAC hasn't gained the traction it promised at its inception, but that's largely due to vendor dilution of NAC's primary mission, controlling Ethernet access. The 802.1x standard is a good one, with a proven track record for its intended functionality, which extends to client health checks and even remediation. The secret to successful NAT deployment, as you've seen, is adequate prep work and gradual introduction to users, with thoughtful user education and implementation testing. New use cases that challenge the current 802.1x protocol are addressed in a revision called 802.1x-Rev, slated for ratification this year. Moving to that will be a simple firmware upgrade and promises to make NAC even easier to use in the future.
Mel Beckman is a senior technical editor for System iNEWS.