1.3. Understanding Clientless and Client-Based NAC

While NAC solutions may be different, they do basically fall into two categories:

• Clientless — No software is installed on the device to assist with the NAC process.

• Client-based — A software component is preinstalled on the device to assist in the NAC process.

There are a number of factors that determine which type of solution makes the most sense for a particular organization. As you'll see, client-based NAC provides the most detail about a device, although installing software on every machine trying to gain access to a network may not always be possible.

1.3.1. Clientless NAC

A good example I've seen of clientless NAC came from my dealing with a university. They were a fairly good-sized university that was known around the country as being extremely strong academically. It had a network throughout its campus that both students and faculty would access. This network provided access to campus resources, as well as access to the Internet. Because of the mix of users and the fact that campus resources and the Internet were both accessed, the university felt the need to perform a level of analysis on devices trying to gain access to the network.

The major issues the university ran into with trying to put together this type of solution was the sheer number and diversity of devices that needed access and the fact that it couldn't possibly support putting software onto all of them. It wasn't just a question of physically getting the software onto the devices. Once an organization puts software onto a machine, it is responsible for supporting that software and dealing with any problems that may arise from that software being on the device. That would simply not be possible to manage for the tens of thousands of devices that would be accessing the network over the course of year. Not to mention it would be a licensing nightmare to try to manage who had the software, to uninstall the software when a student left, and so on.

For this type of scenario, the answer was simply not to put software onto the devices. Instead of using software, the university would simply use a technology to scan the devices when they came onto the network. If they met the minimum requirements, then devices were allowed access. If they didn't, then they weren't allowed access. This sounds easy, so why doesn't everyone go clientless?

The big reason is that clientless solutions do not offer a very granular level of detail about the devices. If properly configured and secure, a device should give very little detail about its security posture to an external technology that is attempting to get further information. For example (and under normal circumstances), it's not possible to tell if a device that is attempting to gain access to the network has antivirus software installed and running with the antivirus definition files up to date. There isn't a mechanism that computer systems use to communicate this to an unknown technology that is requesting this information. In fact, there is good reason not to give out this type of information. Why on Earth would a computer system want to advertise the fact that its antivirus software is outdated?

The same is true for patches, such as Microsoft security updates. If the university wanted to ensure that devices coming onto the network had particular critical Microsoft patches, that isn't necessarily an easy thing to do. It's not as though anyone would want a laptop to actively communicate that it is missing a critical patch that would make it vulnerable to exploitation.

That notwithstanding, there are clientless methods to see if devices are vulnerable to particular exploits. For example, it's possible to scan to see if Microsoft patches MS03-026 and MS03-039 are missing. These particular patches help fix a rather large, gaping, and well-known vulnerability. Some quick information about these particular patches is:

• MS03-026: A buffer overrun in RPC interface may allow code execution.

• MS03-039: A buffer overrun in RPCSS could allow an attacker to run malicious programs.

Clearly, anything that allows code execution and that allows an attacker to run malicious programs is bad. That is why Microsoft developed an easy-to-use tool to help administrators know if these patches were missing. This didn't require any knowledge about the devices to be scanned, and didn't require that any particular software be installed on the devices. The name of this particular tool is KB824146scan.exe. To run the tool, someone would simply go to a command line, type in the name of the tool, and put in the IP address range and subnet information for the network to be scanned. The following is example of this being done, with the results also being shown:

C:>kb824146scan 10.1.1.1/24

Microsoft (R) KB824146 Scanner Version 1.00.0257 for 80×86
  Copyright (c) Microsoft Corporation 2003. All rights reserved.

<+> Starting scan (timeout = 5000 ms)

Checking 10.1.1.0 - 10.1.1.255
10.1.1.1: unpatched
10.1.1.2: patched with both KB824146 (MS03-039) and KB823980 (MS03-026)
 10.1.1.3: Patched with only KB823980 (MS03-026)
10.1.1.4: host unreachable
10.1.1.5: DCOM is disabled on this host
10.1.1.6: address not valid in this context
10.1.1.7: connection failure: error 51 (0x00000033)
10.1.1.8: connection refused
10.1.1.9: this host needs further investigation

<-> Scan completed

Statistics:

Patched with both KB824146 (MS03-039) and KB823980 (MS03-026) .... 1
Patched with only KB823980 (MS03-026) ............................ 1
Unpatched ............................. 1
TOTAL HOSTS SCANNED ................... 3

DCOM Disabled ......................... 1

Needs Investigation ................... 1
Connection refused .................... 1
Host unreachable ...................... 248
Other Errors .......................... 2
TOTAL HOSTS SKIPPED ................... 253

TOTAL ADDRESSES SCANNED ............... 256

This is some rather valuable information. Something to keep in mind is that this can be used for good intentions and for bad. Imagine a hacker at a busy Wi-Fi hotspot running this tool in hopes of finding a victim.

There are also other tools available that can do clientless scanning. Among these are the following:

• Nessus

• Core Impact

• Sara

• GFI LANGuard

• Retina

• SAINT

• ISS Internet Scanner

• X-Scan

The following is the bottom line about clientless NAC:

• It doesn't require software on the devices attempting to gain access, so deployment and management of client-side software is not necessary.

• The level of technical detail about the devices gaining access is dramatically less than using client-based NAC (unless the device is configured quite poorly and lacks security software).

1.3.2. Client-Based NAC

Client-based NAC is what most companies think about with today's NAC solutions. Not only will the software give more detail about the security posture of the device, the software can be used to perform other NAC functions, as well. (See Chapter 2 for more on this.)

NAC solutions that use a client can install the client via a number of different methods. It's not always as straightforward as an administrator installing NAC software on every device; it depends on the type of NAC solution being used. NAC software can be installed as:

• An executable with the sole purpose of performing NAC functions

• A component of other security software, such as personal firewalls

• A component of the VPN client

• An ActiveX component that is automatically downloaded

• A Java component that is automatically downloaded

Take, for example, the Cisco Security Agent. This agent includes the Cisco Trust Agent functionality that, in the past, may have been installed separately.

The ActiveX and Java components are pretty interesting. These can be seen with SSL VPN devices that are performing NAC-type functionality. Juniper's SSL device (formally NetScreen and Neoteris) has the ability to perform Host Checker functionality. This allows the SSL device to assess at a granular level the device attempting to gain access. Of course, the big thing with SSL VPNs is that they are considered to be clientless. So, how does a clientless VPN solution provide client-based NAC assessment?

The answer is pretty simple. When an end user logs into the SSL device by accessing a web page, the browser downloads an ActiveX, or similar component. This component is the software and allows the detailed, client-based assessment to take place. In essence, the ActiveX component becomes the NAC client software.