Posts Tagged ‘NAC’

Virtualization: The Enemy of Most NAC Solutions

March 18, 2008

Tim Green is at it again targeting NAC and virtualization. I believe that he could have written about some more issues with NAC and virtualization that most NAC vendors are suffering from.

Specifically, what happens when you have a virtualized environment on a Server that might host multiple guest operating systems?

What is wrong with this scenario? Let’s take those NAC vendors that use the underlying switch infrastructure to place an element into quarantine VLAN until it’s posture is validated. Quarantine VLAN is a per port per device ‘technology’ meaning that is cannot be used for virtualization since it re-assigns the switch port’s VLAN ID to that of the quarantine VLAN. By doing this all the elements (virtual elements) using that switch port for their connectivity will also be assigned to that VLAN (meaning no communications for all).

Others may claim that the internal communications between the hosts is the problem. I disagree. I think that if the virtualization server’s administrator is installing another guest machine she is not doing that to break into the organization. It may be an unauthorized install, but not for malicious intents. The guest machine must be disallowed network access so communication with other systems on the network would not be possible (until either the guest machine is authorized and/or its posture is validated).

This brings me back mentioning that NAC solutions must first take care of rogue devices and network access (S-E-C-U-R-I-T-Y) and only then with compliance.

NAC Agents – Not The Solution To Look For

March 18, 2008

I have been speaking about this for some time now – a NAC solution that relies on agents is a solution, which would be bound to fail in deployment. The problem is more emphasized on large-scale deployments.

I can count several reasons like the problem of identifying all the elements that the agent needs to be installed on (organizations do not know what they have on the network as is. …And most of the NAC vendors do not know that to…), the NAC agent is one among many other agents that may already be installed on the element, a performance impact that may result from the agent, management overhead, and the fact that the agent is a target for a security breach.

Seems like I am not alone talking against the NAC agent approach. Tim Green of Network World published in his newsletter an article about issues with NAC agents.

NAC deployment must be complete

February 17, 2008

NAC must scale. The deployment must include all sites, and not just a certain portion of the environment. If dependent on an appliance and/or on the switching fabric, it is bound to fail (time-to-value, effort and money).

Any NAC deployment must cover the entire environment, so other venues accessing the network would not be possible.

One good example is with guest access. Enforcing guest access on specific locations, such as meeting rooms, etc. would fail once the guest will connect to those unprotected locations.

Financial institutions and NAC

August 13, 2007

As one that had worked for and consulted to a few large financial institutions I was surprised to learn that many people do not know what are the challenges that NAC solutions face at financial institutions.

Financial institutions are notoriously known for the strict roles they impose over changes to their infrastructure (external and internal). Usually, when a change is needed, a series of signatures are required to authorize the change, which could only be performed in a designated window of time (usually once a week on Sunday). If the change cannot be performed, or caused another problem, a role-back is performed, and the change is pushed back to the next week (if at all).

During some periods of time in the year a change freeze is in effect. No changes to the infrastructure are allowed. This is usually done between November – January, which represents the high season for shopping, etc.

So what are the barriers for NAC vendors? Just think about NAC solutions that use the Quarantine VLAN method to isolate devices, dynamically assigning VLAN IDs to switch ports, etc. As one can understand, a definitely no-no in a controlled environment.

Actually, any read-write access, which is required to the infrastructure switches would not be allowed.

Another interesting affect is the use of software-based agents, where most of the financial institutions would not be that happy to install (along a long list of other client-based software that they may already have on the desktop).

Testing NAC Solutions

August 9, 2007

Recently we read about some NAC product comparisons performed by various magazines. The one thing that I find the most interesting is the test criteria and the parameters, which are being used in order to perform the comparisons and tests.

For example, one magazine just checked that NAC solutions can perform user authentication against Microsoft Active Directory, and Radius servers, and that they are able to provide with host-based checks and remediation.

What was the testing environment? One new Cisco switch capable of doing 802.1x, 2x VLANs were defined, about five managed Windows XP SP2 machines were used and a patch management server.

What is wrong with this picture? Well, first of all this cannot mimic a true network setup. And in a true network setup there are a lot of parameters you must include in the equation when you enroll a NAC solution. The second issue I find is even more problematic. The parameters, which were used to test the NAC solution, are simply, in my mind, the wrong parameters to check for.

I have written about this in the past when I have discussed parameters to add to a NAC RFI/RFP. Where is the check for proper element detection? Where are the questions in regards to how Quarantine is being done? Or how enforcement is performed? Three simple questions that opens a Pandora box.

If I were you, I would do my home work and verify that a comparison NAC test I read about was done in an appropriate manner, and that the parameters and tests it went through makes sense for NAC…

About My Upcoming Defcon 15 Presentation – kNAC!

July 18, 2007

I will be speaking at Defcon 15 about NAC vulnerabilities and bypass issues.

The talk has a considerable amount of new vulnerability information, which I have collected in the past year and kept quite about. So you should stay tuned for some interesting new stuff.

Don’t be a stranger and come say hello.

8 Vulnerabilities You May Have Missed

July 18, 2007

Dark Reading had published an interesting article about the “most dangerous and least-discussed” IT security vulnerabilities they have seen in the recent weeks. This list includes NAC vulnerabilities, PHP issues, rogue Anti-Spyware stuff and other interesting issues.

You can read the article here.

Pre-connect NAC – The first building block of a controlled guarded enterprise LAN

May 19, 2007

For those of you who are confused by the different terms, pre-connect NAC is the phase in which the identity of the device and the identity of its user are to be verified.

With pre-connect NAC any device trying to access the Enterprise LAN must be authorized, and the identity of the user using this device must be authenticated.

Pre-connect NAC allows disallowing access from rogue devices (non-authorized devices), and from unauthorized users.

Proving the identities of those using our infrastructure is a major piece with the overall security and control NAC is bringing along (Just as a reminder, pre-connect NAC is followed, usually, with posture validation tests, and post-connect capabilities).

Pre-connect must also deal with devices such as printers, VoIP phones, etc, which an identity of their user cannot be verified. Instead parameters regarding the device are those who should be verified (type of device, purpose, capabilities, etc.). These devices need to be constantly monitored so they would not be abused for an attack.

As demonstrated, pre-connect NAC has an important rule with NAC, and its values cannot be dismissed.

Cisco IP Phones – The next easiest venue into your NACed network?

May 8, 2007

VoIP, IP Phones, and the gear from Cisco always fascinated me. In the past I have published several advisories and papers regarding vulnerabilities and security issues I have found with the Cisco IP Phone gear.

Looking into how Cisco handles IP Phones with their NAC solutions caused me to raise some interesting questions regarding it.

The IP phones identify/authenticate to Cisco NAC solutions using CDP packets. These packets can be easily spoofed. Usually a computer will be hooked to the IP Phone. The IP phone would assign a different VLAN tag for traffic from the IP phone, and a different VLAN tag for the computer date. What if a hub is connected to the wall, the computer is disconnected from the IP phone and now is connected to the hub and uses the VLAN tag of the Voice VLAN? What if the computer spoof an “authenticating” CDP packet?

Not even mentioning the fact the IP phone can be disconnected and the computer may completely abused its MAC address and the special authentication way of it.

You get the picture.

Suspended for hacking Cisco Clean Access NAC

April 27, 2007

Tim Green over at NetworkWorld has interviewed me for an article with an interesting story. A sophomore student over at the University of Portland was recently suspended for a year since he managed to find a way to circumvent Cisco’s Clean Access NAC. The student managed to find several vulnerabilities with Cisco’s CCA circumventing it to believe its operating system and A/V adhere to the network access policy, where in truth they were not.

Some more information can be read at The Beacon, the students paper over at the University of Portland.

This story, and others, that were published recently, demonstrates how a questionable device, that is not trusted as is, may falsify information part of a posture validation check. This proves one of the points I have raised during my summer BlackHat 2006 presentation were I have raised these same issues.

The first lesson you learn with information security is that there is no such thing as client-based security.