Rolling Review: Consentry Networks LANShield Controller CS2400 and Consentry InSight

ConSentry's CS2400 LANShield Controller, the first entry in our in-line NAC Rolling Review, is a passive in-line NAC device that applies access controls based on a variety of user-defined criteria. The Controller is a good port-based firewall and has the potential to be a powerful user-based access control system, as evidenced by its robust definition engine. However, because it cannot detect log-offs, the device fails to live up to ConSentry's claim of enabling NAC based on making ACL decisions by user. We also found its logging capabilities lacking.

The CS2400 model that we tested ships with 10 paired SFP GBIC ports supporting 10/100/1000 copper and single- and multi-mode fiber. An out-of-band Gigabit Ethernet port provides for management. Appliances can be deployed in an active/active configuration, sharing user authentication state. In addition, the devices can be set to either pass or block traffic in the event of hardware failure. We used ConSentry's InSight Command Center to manage the Controller.

Paired ports pass bridge traffic through the CS2400; each port is defined as either host-oriented or network-oriented. The distinction is important because the LANShield Controller looks for authentication traffic on host ports. Reversing the ports, as we accidentally did, causes access-control issues. Unlike with out-of-band NAC products, we didn't have to reconfigure our switch or router. The Controller detected our 802.1Q trunks.

Roles and HolesConSentry's role definition is very flexible. We could combine a variety of criteria, including authentication type, RADIUS attributes, network information and time of day, to assign a user to a role. Role assignment could be as simple as tying your Active Directory group membership to InSight's roles, or you could take into account network address or host condition. Roles are assigned access-control policies that determine what a user or host can do within the network. The flexibility lies with the product's role hierarchy, where each child role inherits access controls from its parent. Rules are then processed from the lowest matching child rule to the All Users role. Access-control rules are essentially firewall rules allowing or denying network traffic.

NETWORK ACCESS CONTROL
Immersion Center

NEWS | REVIEWS | BLOGS | FORUMS TUTORIALS | STRATEGY | MORE

For example, we created a rule called "Unauthenticated," which denied all access except for those services needed to log on to our Active Directory domain. In the "Authenticated" role, we created ACLs that should be applied to all authenticated users, for example, access to DNS and the Internet. We didn't define additional access rules for the "Guest" role, which was a child of Authenticated, but for the "Sales" role, which is derived from an Active Directory Sales group, we defined access to an additional set of servers. When a host comes onto the network for the first time, it falls into the Unauthenticated role. Once a user authenticates, either through Kerberos, which is detected passively, or through the captive portal, he is placed into a new role, and the ACLs are applied to that host. If a new user authenticates over the network from that same host, the new authentication is detected and the new role is assigned accordingly.

Specific roles can be also be assigned using multiple, more complex criteria, like IP address or VLAN assignment, and this is an area where ConSentry shines. For example, you can have a policy that states if an HR person logs in from a workstation on the HR network, she can access the ERP system. But if she's logging in from any host not on the HR VLAN, she is denied access.

Unfortunately, however, there's a hole in ConSentry's user-based access control big enough to drive a truck through.

The LANShield Controller doesn't detect log-offs on the host, so a malicious user could easily gain elevated network access privileges. Say a person in a Domain Administrator role logs on to a workstation using an Active Directory account. He will be granted access based on that role. If the Domain Administrator then logs off the computer and someone else logs on using an account local to the computer, that user now has the access that was applied to the Domain Administrator role. Alternatively, a malicious user could disconnect the network cable, log in using cached credentials and gain the same access.

This article is the second of a series and is part of NWC's Rolling Review of In-Band NAC. Click on that link to go to the Rolling Reviews home page to read all the features and reviews now.

Because the LANShield Controller tracks hosts by MAC address and IP pairs, an alternative way to gain the access privileges of an existing host is to discover the IP and MAC address of the host you want to impersonate, disconnect that host from the network, and configure your computer with the new MAC address. If the network is using DHCP, you will get the IP address of the host you're impersonating, or you can manually set it.In both of these bypasses, the attacker does need physical access to the hosts and the network to be successful, but once they have that, it's game over. These simple bypass techniques may apply to NAC products yet to be tested as well.

To plug this hole ConSentry needs to do two things. First, detect a domain user log-off, a capability the company says is coming in the next release. That should trigger a change in policy. Second, detect when a host's network port goes down and force a re-authentication. Hosts, Applications and Anomalies

ConSentry makes no bones about its feelings on host scanning—namely, that it's overrated, and that what's important is the activity a host exhibits once on the network. Rather then build its own host assessment capability, ConSentry licenses Check Point's Integrity Clientless Security, or ICS. Positioned as an assessment scanner for guest computers, ICS uses a dissolvable agent that runs on the user's machine and returns an appraisal. If the host passes, ICS notifies the LANShield Controller and the host is allowed to move on to the next step in authentication. Otherwise, the host is restricted until it meets policy.

Assessment policies are global under LANShield Controller and apply to all hosts, so we had to create exclusion rules for user groups and hosts to bypass the ICS assessment phase. That is a step down from ConSentry's otherwise robust policy definition.

ConSentry talks a big game about application enforcement and network anomaly detection, but the reality doesn't measure up to the hype. The LANShield can detect 30 applications at Layer 7, but it can control access to a smaller number.For example, applications with configurable actions are restricted to HTTP, CIFS and FTP; access-control rules are generally limited to file and user names. Not terribly useful. During testing we set out to configure CIFS to control access to a file share based on host name and found the name had to be in capital letters. It's little things like this, combined with a dearth of configurable options, that diminishes the efficacy of application control.

Detected applications are equally limited. IM protocols are AIM, Yahoo Messenger and MSN, while P2P protocols are limited the obscure WINNY. With no way to add applications, we see very little use for this feature and suggest that ConSentry partner with a vendor like SourceFire or Tenable for application detection and control.

Anomaly detection looked promising, and when we had it working, it spotted common anomalies like port scanning. However, we were unable to keep the function running long enough to thoroughly evaluate it. Tests are limited to high connection rates and high failure rates—both indicative of scanning and DoS attacks.

Wherefore Logging

InSight has some nice overview graphs that give an indication about the status of hosts on the network, but digging into details is daunting at best, useless at worst. While lots of pretty pictures are nice, we were unable to troubleshoot problems, like connections failing to complete or users not seeming to be authenticated, and we had no logs to troubleshoot.It wasn't until we were working with ConSentry to troubleshoot various issues that we picked up on the "CLI show" commands. While not as in-depth as Cisco's CLI, which the ConSentry interface is modeled on, we were able to pull out a bit more information. Still, it was a difficult slog, and when we configured debug output via syslog, we found relevant events weren't available.

If you're a vendor reading this article, pay attention to this sentence: Give administrators access to logs for troubleshooting. There is nothing worse than a function not working and the device in question not giving any indication as to why. Nowhere did we see a single event that would point to a problem. If this were a remote device, it would have been difficult, if not impossible, to diagnose.