SpectraGuard is a security product for protecting networks against all manner of threats from wireless networking equipment. The main component is SpectraGuard Enterprise, which connects into the corporate network and protects against nefarious wireless activity; also part of the package is SpectraGuard SAFE, a software component that runs on portable computers and allows the policies that are defined in Enterprise to be reflected on these devices when they’re disconnected from the office. I’ll look predominantly at the Enterprise component, since there’s more than enough to say about it in the space I’m allowed.
The core of the Enterprise system is the main appliance, which in our case was a 1U server with a 3GHz CPU, a Red Hat Linux base and the SpectraGuard software installed thereon. The appliance (which can partner with others like it for resilience if you wish) controls the policies you define and also provides you, via a Java console application, with the configuration GUI. Once you’ve defined the policies, the appliance communicates with “sensors” across the network. These look rather like wireless access points, and are themselves Linux-based devices with WLAN radios, PoE-capable LAN interfaces, and external antennae.
The first thing you do to get up and running is configure the appliance via a short wizard over an RS-232 connection. It’s all the usual stuff like letting it know how to connect to the LAN, so that you can do the rest of the work via the GUI. Once you’ve done the initial setup the sensors can seek and detect the appliance; if you have DHCP on the network they’ll magically wake up, but if not then you can use their RS-232 interfaces to configure addresses in by hand. The sensors have four LEDs on the top panel; although their primary functions are to show whether the power is on, the network is connected, and each of the two (b/g and a) radios are running, they have a selection of different ways of flashing to let you know other stuff too, such as whether they’ve acquired an IP address. All being well, the four lights will all light up after a few seconds, which tells you the sensors are talking to the appliance.
When the lights are on, you point a browser at the device and you’re given a link to download the console applet. The system says you need version 1.4.2 of the Java runtime (and you can click to download and install it), but in reality it worked fine on our 1.5 installation. When you log in for the first time a wizard fires up and walks you through a startup routine in which you do things like changing the admin password (which is, sensibly, a mandatory task) and defining a default policy.
SpectraGuard works with two types of wireless entity: clients (portable PCs, handhelds, etc) and access points (“APs”). The thing to configure first is the rulesets relating to the APs that exist on and around your network, and so it goes out and finds the APs that it can. Each unit it finds is classified into one of four categories: authorized (sic), mis-configured, rogue and external. The way the system probes for APs is very sneaky. It probes over both the wired network and the wireless network, and if an AP is visible wirelessly but not via the wired network, it’s treated as an external device. Anything that’s accessible over the LAN and the WLAN must by definition be connected to the network, and by default new APs will be treated as rogues until the system manager flags them as “authorised”. For an AP to be treated as “mis-configured” generally means that it’s authorised but doesn’t conform to the policy that’s been set for it – perhaps because the authentication protocol it’s using isn’t as strong as the policy requires.
What is your policy?
This brings us neatly onto the subject of policies. A policy is simply a set of rules that dictates whether any wireless device is permitted access to the network. There’s a configurable default policy that you can use for general access rules, and if you wish you can then define additional custom policies for individual subnets or VLANs. A policy can prohibit wireless connections entirely, or it can permit them with strings attached – e.g. to insist that only certain 802.11 variations are permitted, that particular authentication schemes are used (e.g. insist that no unsecured sessions take place), that only a given set of SSIDs are permitted, and even that only hardware from particular vendors is allowed. You can also define the default treatment for APs that can’t be categorised definitively (e.g. one that looks external but is actually connected to an inaccessible part of the organisation’s LAN) and clients that appear for the first time (e.g. you can say that if a client authenticates successfully to an authorised AP, the client should be classed as authorised too). It’s worth noting that although you can allow clients to be auto-authorised in this way, the only way an AP can become authorised is for the system manager to do so manually. Once you’ve defined these access control type rules, there are some extra intrusion prevention rules you can apply, such as blocking authorised clients that start to use ad-hoc WLAN connections, or which it sees making connections to external APs.
All well and good so far, but just how do you go about intrusion prevention in a wireless environment? In a wired world you simply put the firewall in-line in the network, so that packets have to go through it to get from outside to inside, but you can’t do the same with radio photons flying through the air. Well, as long ago as 1998, Abirnet broke new ground by introducing SessionWall-3, a passive firewall – that is, one that taps into the LAN and watches the packets as they fly past (Abirnet was bought by Memco, which was then gobbled up by Platinum and finally by CA, lest you should wonder). To kill a connection, it would simply send tear-down packets to each of the involved machines, and the connection would be dropped (or, more frequently, not even allowed to complete its initiation negotiation).
In a wireless world, SpectraGuard does the same – when it decides an activity shouldn’t be allowed, it sends appropriate WLAN messages to both the source and the destination (it may, after all, have a sensor within range of only one of the two parties in the conversation, so it makes sense to attack both ends just in case) to block the connection setup, or to terminate a connection that is already established. In fact, given that wireless signals commonly extend outside one’s building, it is in fact conceivable that you could use SpectraGuard to kill your neighbour’s wireless LAN! The upshot of the way the system works is that it protects your systems in two directions; as well as the traditional task of preventing unwanted APs and clients from being added to the network, it also prevents things on your network from becoming vulnerable by connecting to external entities – “honeypot” APs set up with the same SSID as your own WLAN, for instance, or the office next door’s AP which still has the default SSID and no security.
Back to the configuration console, then. Once you’ve finished with the initial setup wizard and the necessary configuration screens, the thing you’ll look at most often is the Dashboard. As you’d expect, this is an overview of what’s going on on the network, and the most prominent bit is the top left-hand box which contains either a big green tick (if all is well) or a big red cross (if a policy rule has been broken). When policy events happen you simply click on the cross to be taken to a list of events; double-clicking on an event gives a detailed description of what went wrong. Apart from the basic status indicator the dashboard also shows stats about devices that have been detected and how they’ve been classified, along with a summary of the APs, clients and sensors on the network. The drill-down features are excellent – it’s generally the case that clicking on something takes you to the detail screen for that entity – and the help buttons (big, impossible-to-miss yellow squares with an “I” in) pop up help screens that are tremendously detailed, with plenty of illustrations and text that makes a good fist of jargon avoidance.
Events and Locations
We’ve already hinted that policy breaches result in “events” being generated. As you’d expect, as well as displaying information in the GUI, it can also send emails to key people based on the type and severity of the event; this is all configured in the Events section of the console application. Also unsurprising is the presence of the Reports section, which has a set of pre-defined reports and the facility to allow you to generate your own; reports can be run on demand or on a schedule, and sent via email to nominated recipients if you so wish.
Last but not least is the Locations section, which allows you to tell the system what your organisation looks like. You can draw the basic layout with a built-in design tool, or you can upload a pre-prepared GIF/JPEG graphic instead. If you’re feeling very adventurous you can alternatively upload a map generated by SpectraGuard’s Planner tool, which is an “intelligent” diagram of your world that includes information about the make-up of walls, doors, windows, etc and allows the location facilities to work more accurately. The purpose of all this is not to look pretty, but to allow SpectraGuard to triangulate the position of any device and show you on the map where it is – a neat tool that eases the task of dealing with suspect clients and APs. You don’t need the intelligent mapping capability to triangulate the location of suspect devices, but it does let you check that the placing of your sensors is sufficient to detect signals from everywhere in the building.
SpectraGuard is very, very clever. I can’t help thinking that the designers have covered all the potential security issues with wireless intrusion prevention, and the way the package intercepts and deals with illicit connections is clever and effective. The GUI is superb, the online help brilliant, and the price is good too.
If your company is concerned about wireless security and your budget can reach, buy this product.