Policing the airwaves

An IDS (intrusion detection system) is usually considered the icing on the cake when it comes to monitoring a conventional network. But when it comes to monitoring an 802.11b network, the playing field changes. Conventional IDSes are great for detecting attack patterns on the wire; for wireless traffic, a device specifically designed to sniff out wireless attacks is needed. A wire-bound IDS just doesn’t cut it when a malicious attacker is trying to spoof a wireless card’s MAC address.

AirDefense Guard Version 3.0 IDS monitors the airwaves to prevent unauthorized access from taking place on your wireless and ‑ ultimately ‑ your wired LAN segments. It isn’t the cheapest solution on the block, but does have a lot going for it: a solid core based on security policy management and focused on intrusion detection, discovery/vulnerability assessment, and monitoring of the WLAN infrastructure’s health.

Three component system

The AirDefense 2200 system has three parts: the hardened Linux server appliance running RedHat; the distributed wireless AP sensors; and the AirCommand Web console, which connects to the server appliance over the Web via SSL.

The initial setup of the AirDefense 2200 server consists of connecting to the 1U rack-mountable server appliance and logging directly into the Linux console, thereby setting network parameters on a slimmed-down management interface. The setup was relatively painless, as was the setup of each wireless sensor, which required that we directly connect to each sensor with our Dell laptop and change the default network information.

The AirDefense system’s wireless AP sensors passively monitor the network for traffic; because they’re not broadcasting, their effective monitoring range is large. In fact, the range is potentially several orders of magnitude larger than a conventional wireless AP. Therefore, a sensor doesn’t have to be deployed with each AP. We found that comforting, considering that each sensor can cost as much as $795, possibly doubling wireless deployment costs depending on the density of the APs and the sensors.

We had a problem while configuring one sensor directly connected to our Dell laptop, which AirDefense attributed to documentation that described the use of a cross-over cable for configuring a sensor. That documentation has now been modified to recommend the use of a hub instead, because the cross-over cable could create a short-circuit. For us, connecting to a switch and ultimately replacing the sensor solved the problem.

To enhance security, each sensor ‑ running Cisco wireless NICs ‑ is not addressable from the airwaves, making it far less vulnerable to attack. The sensors and appliance communicate with each other via an encrypted session via port 443 (encrypting communication is optional). Each sensor can also fail over to another AirDefense server appliance if the primary appliance does not respond. There is a catch with multiple servers, though: The servers are scalable, but they don’t they don’t talk to one another, and they don’t have a centralized management platform, so each has to be managed separately. AirDefense says it is working on this management issue.

After setting it up, we connected to the AirDefense Appliance via secure Web interface. The AirCommand console relies heavily on Java applets, so we had to download and install the JVM (Java virtual machine) from Sun.com before we could connect to the AirCommand console.

The Dashboard consists of views of the entire system with sections for recent alarms, discovered APs, recent policy violations, most suspicious devices, and a section of graphs of other sensor-collected information such as mean signal strength and traffic levels by channel and by bytes transferred. We especially appreciated the additional information that popped up when we rolled the mouse over a specific AP or WLAN client icon.

Putting detection to the test

For our testing, we used a Dell Latitude C640 with an integrated WNIC (wireless network interface card) running Windows XP as our primary wireless workstation, which also served as our Web-based monitoring console, along with a Sony Vaio SR-7K with a US Robotics WNIC. For our footprinting and attack/penetration tools, we used a Dell Latitude running Redhat with Cisco and Lucent WNICs. On the AP side, we used 3Com’s AP 8000, Cisco’s Aironet 1200 Series, Proxim’sORiNOCO AP-2000 and USR’s 2249. We also used a handheld 802.11b AirMagnet and Fluke WaveRunner to augment our testing. 

Although the AirDefense box didn’t detect the AirMagnet or Fluke WaveRunner handheld wireless analyzer scans of our wireless network, NetStumbler (www.netstumbler.com) probes were correctly identified. We also conducted several intrusive tests with Air Jack tools (http://802.11ninja.net) on RedHat to see how well the IDS identified the attacks.

We first used ESSID (Extended Service Set Identifier)-jack to grab the SSID (Service Set Identifier) of our AP; the IDS identified our SSID probe as an Identity Theft attack. We then used WLAN-jack to create a DoS (Denial of Service) attack via de-authentication on our primary AP; the IDS correctly identified this as a DoS De-Auth attack and listed the details in an appropriate section. We then ran MONKEY-jack to create a man-in-the-middle attack. The IDS again correctly identified this as an Identity Theft: Out of Sequence attack.

We found that, after conducting these attacks, we were still seeing alerts on the AirCommand Dashboard hours after the attack had taken place. We rectified the situation by restarting our primary AP, which was still having intermittent trouble connecting to other wireless devices, probably due to the MONKEY-jack attack. With numerous simultaneous attacks and events, we found it very comforting that the Dashboard correlated all of the events, whether attack-, event-, or performance-related.

A major advantage of the AirDefense system is that it gave us the ability to visualize a network that uses the invisible radio spectrum as its transport medium. With a conventional network, you can always look at the CAT5 wires or the fiber to find out where a network signal originates and ends and where it might be broken or hit interference. With wireless you can lose control of the medium ‑ someone can stick out an antenna for a DoS attack, and it can seem as though someone cut your wire or fiber on a conventional network. In a mixed wireless vendor environment, the IDS provides a central monitoring environment, easing the burden and increasing the efficiency of IT monitoring.

Policy-compliance is key

The underlying foundation of the AirDefense IDS is its adherence to policies. There are three main categories for policies: configuration policy, performance policy, and vendor policy. All of the policy thresholds are configurable to suit a particular enterprise.

The vendor policy, for example, allows or disallows certain vendors’ NICs and APs from being seen on the wireless network. Knowing which cards are allowed on the WLAN helps prevent session hijacking: if an enterprise only consisted of Cisco NICs, then all other NICs could be excluded so that a non-Cisco NIC would immediately trip an alarm if seen.

Reporting functionality was also very good. We could export detailed reports on an event in either HTML or CSV (comma-separated variable) format for forensic analysis after an attack. We would have liked the option to export data in a PDF format, which would have saved graphical details displayed in the AirCommand console. The IDS can also send SNMP traps to a trap receiver for linking to an enterprise fault monitoring system such as IBM’s Tivoli, Computer Associates’ Unicenter, or Hewlett-Packard’s OpenView.

IDS systems are usually not the first components purchased for enterprise network protection, but they should be a close second when deploying a secure 802.11b network. Monitoring a WLAN can, and often does, create a whole new set of headaches when it comes to securing the enterprise, and the AirDefense IDS provides solid monitoring and alerting when an event or attack occurs. Just remember that you face a hefty price for what these boxes and sensors can do.