On the surface, the ConSentry CS4024 loosely resembles most edge switches on the market today. The CS4024 comes in two flavors, either Power over Ethernet or non-PoE, with both models sporting 24 ports of 10/100/1000 copper, two of which are shared copper/fiber ports for uplinks to core or distribution switches. Of course, if all ConSentry had to offer was an Ethernet switch, we wouldn't be wasting your time with a review of commodity hardware. It's what's under the hood of the CS4024 that's worth a closer look.
Using a combination of custom ASICs and intelligent switching code, the ConSentry line of switches provides network access control, deep packet inspection, and threat and user access control all in one package. ConSentry and other smart switch vendors are attempting to do something that firewalls, virus engines, malware-prevention tools, and URL filters can't do: enforce policy at the switch port. It's a strategy that more and more IT managers are adopting -- because after all, wouldn't you prefer to subdue a would-be robber before he breaks into your home?
ConSentry's intelligent switch last made its way through the InformationWeek labs in October 2007. At the time, our very own Mike Fratto took a miter saw to the prior generation of the CS4024 and exposed some serious security flaws that he humorously described as a hole "big enough to drive a truck through."
Our analysis of ConSentry's security flaws did not go unnoticed, because 18 months and two code revisions later, we see a much improved smart switch that addresses or works around almost every security hole that we reported in late 2007.
As a switching and security product that's meant to be deployed at the edge, we found a nice spot in one of our enterprise network wiring closets for the CS4024 and quickly proceeded to unleash its full capabilities on unsuspecting users. Deployment of the CS4024 is relatively painless, although it's not nearly as plug-and-play as Napera's N24 NAC switch. ConSentry's feature set is also much more complex and robust. Before putting the CS4024 into production, it's necessary to install the ConSentry InSight centralized policy management and distribution component on a server-class machine.
If a client fails a health check, there's no need for virtual LAN switching, because the CS4024 can dynamically enforce access policy, negating the need to maintain quarantined VLANs or access lists for unhealthy systems. All NAC features worked well in the lab environment; the only knock we had was that we didn't have the ability to enforce policy on specific Windows updates, although the ability to check for certain registry keys, files, and processes provided an acceptable workaround.
ConSentry's full Layer 7 awareness, coupled with the ability to snoop in on the Kerberos authentication process, gives administrators the ability to define custom application usage polices and roles based on Active Directory user ID, group membership, or other parameters contained within an Active Directory object. With code release 3.4, ConSentry has greatly improved on its user access control since we saw revision 3.2 back in late 2007, and it now only seems to fall short in one area.
Fratto discovered during his lab work with 3.2 that full network access could be obtained by plugging into a switch port with cached credentials on a port previously enabled with full network access by a legitimate user. Thankfully, ConSentry has closed that hole somewhat with some additional safeguards, including the ability to timeout an active session or terminate it entirely if Layer 1 connectivity is broken. This is certainly a great start for preventing intruders from, for example, walking up to a network printer, or an IP phone, and pulling its network cord in an attempt to gain full system access. Unfortunately, we were still able to crack ConSentry's logoff mechanism by logging off a user with full network access on the domain, and logging back in with a local user account, without physically unplugging the network connection. While the switch was able to detect and reapply policy when logging in with another domain account, it was unable to detect a domain logoff and a local login.