Always-On WLAN Monitor

I tested Guard 3.0 in our Syracuse University Real-World Labs®. The setup was simple. I powered on the rack-mountable server appliance and accessed the Java Web management console after configuring a few parameters using the command-line interface. The server runs on a customized version of Red Hat Linux and uses PostgreSQL to store information fed to it over Ethernet from the wireless sensors.

I also had to install Java Runtime Environment (JRE) 1.4.1 Java HotSpot Client Virtual Machine (free from Sun Microsystems).

Guard comes with two wireless sensors that run an embedded Linux OS and include Cisco Systems' Aironet 350 and Ethernet interfaces. Determining the appropriate number of sensors required for complete coverage and their optimum location in your facility requires time and effort. AirDefense estimates that a sensor typically covers a 1,000-foot radius, but I could test it only up to 170 feet due to the lab building's physical constraints. Because the sensors are passive scanning devices, they have greater effective range than typical access points. AirDefense estimates a ratio of three to five APs per sensor to provide full overlapping coverage.

Monitor Management

I connected to the Guard server via the Web management console and found it slow to load--typical of many Java applications. The initial interface uses the dashboard metaphor and provides a summary of the wireless system based on information aggregated from the sensors (see screen at right). I created individual accounts with guest and administrative privileges and used the admin account to change policies and edit various parameters. The guest account was handy for providing view-only access to people in the lab who were intrigued by the system's capabilities. Because I hadn't entered all the lab's wireless devices into the system's database, Guard generated alarms for all unauthorized APs it discovered through passive scanning of all 802.11 channels.To test the system, I defined a vendor-based policy for my environment indicating that all deployed APs were from Cisco. Guard generated alarms as soon as I powered up APs from 3Com and Proxim. I created another policy that restricted device roaming by defining a single client MAC (Media Access Control) address to connect to one AP. As expected, the system told me of a roaming breach when the client associated to another AP. The system also provided channel activity by each sensor--suspicious or unauthorized devices and ad hoc networks sparked alerts, as did stations that exceeded the association levels I had defined.

Moving my mouse over an item on the management interface generated a pop-up with useful context-sensitive information. For APs, I received the MAC address, IP address if available and the sensor monitoring the device. The console also let me right-click on certain items for quick access to other system functions, such as sensor manager, alarm manager, access point statistics, station summaries and associations.

Working for You

Guard's Alarm Manager tool preclassifies alarms by severity--critical, major and minor--but I changed the default alarm for APs with SSID (service set ID) broadcast enabled. Additionally, Guard listed all types of alarms from the previous 24 hours and let me drill down by date, time, category of alarm, device and individual sensor. This level of granularity stands out when tracking suspicious activity.

The sensor manager places all sensors in the default group initially, but I created locations and groups within the locations (such as building one, first floor). As with the alarm manager, positioning the cursor over individual sensors displayed a pop-up with context-sensitive summary information, including the sensor's MAC and IP addresses.Sensor configuration is controlled within the policy manager. Options include channel scanning, allowed WEP (Wired Equivalent Privacy) modes, authentication modes and allowed data rates. These are accessed and changed by right-clicking on the individual sensor. You can also define performance-policy parameters--maximum associations allowed, number of different types of frames allowed and number of bytes allowed based on types of frames for stations and APs--and manage vendor-specific policies.

The vendor policy, used to detect identity thefts such as spoofed MAC addresses, is supported through AirDefense's OUI (organizational unique identifier) database for all major WLAN vendors. I tested this by specifying the use of a Cisco device at one of the locations and spoofing a MAC address. The sensor was sensitive enough to pick it up. The system also could detect the NetStumbler and AirMagnet probes I performed on our test network, listing them as possible attacks. And it generated alarms when a Windows XP device tried to scan the network to connect to any available AP.

In addition to setting policies by sensor, APs or individual station, you can apply policies based on allowable hours of operation.Lastly, the notification manager lets you select the people to notify by e-mail and the frequency of messages. It also enables SNMP integration if needed. Unfortunately there is no option to send alerts to pagers.

Reporting Skills

Overall system reporting is the key benefit of Guard, not only as an aid to security auditing but as a troubleshooting and performance-planning tool. Guard comes with some very impressive canned report formats to choose from. Much of this information can be useful for both capacity planning and security audits. There are options to view bandwidth utilization per station and average traffic statistics by access point as well--information useful for centralized performance troubleshooting. Guard can't track the precise location of rogue devices like some other monitors can, but it does provide an overall picture. Additionally, AirDefense only supports 802.11b. The company says it is committed to adding support for emerging protocols, but that will lead to higher costs. I am not aware of any other WLAN product that provides the same level of detail and flexibility for reporting.

Guard 3.0, targeted at organizations that have production WLANs and want to ensure that they aren't vulnerable to internal or external intrusions, comes with a hefty price tag--$25,000 for a complete starter pack that includes a server appliance, five sensors, licenses for 15 APs, training and support. But it adds real value to an enterprise wireless network.

Saurabh Bhasin is a research associate with the Center for Emerging Network Technologies at Syracuse, N.Y. Write to him at [email protected].Post a comment or question on this story.