Cram Session: Network Access Control

NAC authentication with XP clients is a snap

continued from page 1



Diversifying agentless access

Cisco brought in partners Qualys and Great Bay Software each with its own strategy for handling guests and unauthenticated devices.

Qualys provides a small appliance, part of its QualysGuard service, which is normally used for vulnerability scanning across a corporate network. In the CNAC scenario, our Qualys appliance talked directly to the Cisco ACS server. When a new system requested access, the ACS server sent a message using a Cisco-defined protocol to the QualysGuard appliance detailing the IP address of the requester. The QualysGuard appliance would run a quick scan, and return a status report with a pass/fail result on the new system.

The integration was quick and elegant, but the actual deployment was very limiting. In this initial incarnation of the QualysGuard NAC integration, we didn’t have a lot of options for configuring the difference between good systems and bad systems because the report didn’t seem to give us a lot of information on what was going on. As more guest users come with firewalls running on their laptops, it’s likely that this approach will offer less useful information. Because QualysGuard has to have an IP address of a system to scan it, this approach also didn’t work for 802.1X users or MAC-authenticated devices such as printers — neither of which has an IP address when the scan has to occur.

To complement the auditing capabilities of QualysGuard, Great Bay Software brought in its Beacon appliance to integrate with Cisco ACS and help with the problem of devices such as VoIP phones and printers. Beacon is a multi-purpose device, but one of its primary tasks is a network device discovery tool. Using a variety of techniques, such as packet sniffing and SNMP discovery, Beacon tries to associate a profile with each device on the network. With Beacon, we wouldn’t have to catalog the MAC address for every agentless device on our network and we would have some “checking” to help reduce the risk of MAC address spoofing by an intruder who wanted to pose as a printer. We used Beacon to identify our VoIP phones and printers based on how they behaved on the network.

The link between Beacon and Cisco ACS is made using an LDAP connection. When an agentless device tries to connect, the MAC address of the device is sent to Cisco ACS for authentication, which then looks it up using LDAP in the Beacon server. If Beacon has built a profile for that device, the profile is sent back to ACS, which can use it to decide what access control settings are appropriate. In the case of our VoIP phones and printers, we were able to put them on the correct VLANs without having to know ahead of time what their MAC addresses were.

Of course, because Beacon talked to Cisco ACS using a standardized protocol (LDAP) rather than a proprietary protocol (as QualysGuard needs to), we were able to sneak the Beacon Appliance onto our TCG/TNC network as well, with the same functionality. We did have to cope with the clumsiness of having two RADIUS servers on the TCG/TNC side, but were able to authenticate printers and VoIP phones using this technique.

One important development we learned about from vendors passing through our lab is that a new TCG/TNC protocol is currently under development. The specification, called IF-MAP, is specifically designed to allow tools such as intrusion-detection systems and Security Information Managers (SIM) to feed information back into the NAC deployment. This kind of linkage would be perfect for tackling the problems of MAC authentication. Currently there is no public information available on IF-MAP.

While waiting for IF-MAP to be released, we brought in QRadar, a SIM from Q1 Labs, to solve the guest and agentless device problem. We set up a QRadar appliance and linked it to the Juniper UAC policy decision point using the TCG/TNC protocols. The idea behind QRadar’s link to TCG/TNC is outstanding: as you discover that something is wrong with a device, you should act to block or quarantine that device as soon as possible. As a SIM, QRadar is in a unique position to know when a system starts to go “bad” by the alerts and logs that it sets off throughout the network. Unfortunately, while the QRadar link to the Juniper UAC was a direct one using TCG/TNC protocols, the actual act of marking a system as “bad” was a manual operation, requiring the operator to select a device and set its status.

We also ran into conceptual problems related to network layers. When a system is detected as bad using QRadar, the common identifying information is the IP address on that system, and possibly the user credentials. However, during the 802.1X authentication, when QRadar would be queried for pertinent information about the system, the IP address is not known because it hasn’t been assigned yet. Hoping the user is sitting in front of the same system that was misbehaving could lead to false positives.

Lessons learned form NAC authentication

From a framework point of view, CNAC and TCG/TNC are in great shape when it comes to the mainstream case of authenticating users on Windows laptops. Everything works great at this juncture, and except for a huge pile of uncertainty when it comes to Vista (see story, What about Vista), it’s all shipping and ready to implement today.

Adding users who have 802.1X but don’t have the Cisco CSSC or Juniper UAC client revealed a crack in Juniper’s shipping product that we had to patch by adding in a second RADIUS server. The CNAC realm covered that scenario more gracefully with its ability to handle different types of RADIUS queries at the same time.

When we added complexity with additional scenarios, we quickly discovered that NAC calls for more hardware and software than just a RADIUS server and some client tools. Many of the capabilities of the NAC network are just as dependent on configuration flexibility within the switches and wireless devices we selected.

Bringing in outside sources of information, as we did with QualysGuard, QRadar and Beacon, looks like a great way to help add security to a NAC deployment and to reduce the amount of custom configuration required in networks with many embedded devices. However, the level of integration and quality of information is basic at this stage. While there seems to be strong interest in integrating these products with both CNAC and TCG/TNC frameworks, what we saw needs more functionality to truly smooth deployment woes.

What can NAC do for you now? Part 1 of 5

NAC enforcement tools fall short Part 3 of 5

Cisco, TCG deliver on basic end point security Part 4 of 5

NAC management can be a headache Part 5 of 5

Back to top

Submit A StoryClick here to submit a story for consideration by Cram Session Editor, stories@cramsessionnac.com