LANShield is a Network Access Control platform that allows you to apply security policies to your LAN. We looked at the two key products in the range: the LANShield Controller (in our case a CS2400) and the LANShield Switch (ours was a CS4048X without the PoE option).
Both devices run on the same firmware but with very slight operational differences (which we’ll come to later). Although there’s loads of stuff you can configure, the underlying principle is very straightforward. First, it watches users authenticate to the network. Once authenticated (or not, as the case may be) a user is attached to a role. Each role has one or more policies attached to it, and each policy uses rules (“filters”) to decide what traffic can pass and what can’t. Devices can work in three modes: Passthrough (where they’re invisible to everything on the network and simply pass packets); Protect mode (where they enforce the policies you’ve defined and report everything that goes on to wherever you’ve told it to) and Monitor mode (which does everything that Protect mode does except that it doesn’t actually block any connections). So you’ll generally connect it up in Passthrough mode, sit it in Monitor mode while you watch the network and devise your policies, then flick to Protect mode when you’re ready to start enforcing those policies.
Step one, then, is authentication, and the system has a number of alternatives. First, it can transparently watch Kerberos/AD or RADIUS logins and deduce whether the login was successful (and can then delve into the directory service to get the user’s profile). It can also work with a whitelist of MAC/IP addresses, or by watching DHCP conversations (the DHCP protocol does more than allocate addresses – there’s a load of extra fields you can use for other stuff). Finally you have the option of a "captive portal" login – where your users are presented with a web page and they enter a user ID and password that the ConSentry kit looks up in an LDAP, RADIUS or internal user database.
When a user or device first connects, it’s attached to a default role called "unauthenticated". There’s a second default role called, unsurprisingly, "authenticated", into which it’ll drop things that have passed whatever login checks you’ve stipulated. Of course, you can then define your own roles to fit the particular permissions you want to grant to each type of user on the network. The collection of roles is a hierarchy, which each item inheriting its parent’s policies, parts of which can then be overridden as required.
It’s probably obvious by now that a role is really just a collection of policies, and it’s the policies that provide the actual control over what happens on the network. Policies can be defined based on a pretty sizeable set of criteria – so you could use the Country attribute in the user’s directory services entry, for instance, or the ID of the VLAN their workstation is on, or the way they authenticated. Most importantly policies can also include “application filters”. The latter are implemented by digging into the application specifics of the packets flying around the network, which means that you can do the usual stuff like preventing access to specific URLs along with some more clever, cool stuff like matching the filenames being copied in fileshare or FTP connections, or permitting only certain browsers to be used by watching the User-Agent entry of an HTTP connection, or allowing only certain screen names in IM conversations. Application filters can be grouped together or used individually in policies. When you define a policy you set all the usual parameters such as the source and destination entities the rule should apply to, what to do in the event that the rule triggers (allow, reset connection or drop), whether to log the event, what category and severity to present when reporting back to the central monitoring service (more about that later).
The type of policy I’ve just described is a “user policy”, and this is where you’ll spend most of your time fiddling with the settings. It’s also worth noting, though, that there are a couple of other policy types. One is Malware – which it won’t surprise you to hear is for spotting dodgy software flying around the network. The other is EPV, or EndPoint Verification – ensuring that devices connecting to the network satisfy constraints such as having AV services installed and being virus-free. ConSentry has made the very sensible decision not to bother writing its own EPV implementation, and has instead done an OEM deal with Check Point for the latter’s Integrity product. Thus when you fire up the EPV part of the user interface, it’s plastered with the Check Point logo.