If you operate a wireless network, you probably need to monitor the security of that network to help protect both the wireless LAN and the wired LAN that it's connected to. If your business prohibits wireless devices, you might want to monitor the airwaves to make sure that policy isn't violated. To scan and monitor wireless activity, you need a specialized security tool designed for this task. That's where wireless Intrusion Detection Systems (IDSs) come in.
Wireless IDSs are similar to IDSs designed for wired networks. Both consist of network sensors and sometimes central management consoles. Both monitor the network according to configurable security policies and can take action, including sending alerts, in situations of noncompliance. Wireless IDSs use wireless Access Point (AP) hardware for sensors. The difference between wireless APs and wireless IDS sensors is that the AP software is designed to manage client connections, and a wireless IDS sensor's software is designed to detect wireless radio traffic and interact with a central management console to report activity and take action according to defined security policies.
For example, a wireless IDS sensor shows all active APs and client stations that broadcast signals within its range regardless of whether those devices are part of your network. A sensor can determine whether APs and client stations are using encryption and if so, what kind, and it can determine what type of wireless frequencies and channels are in use. A sensor can also detect rogue devices, intrusion attempts, network probing, wireless attacks, and more.
You can use the central management console of some wireless IDS systems to instruct sensors to initiate countermeasures that will prevent APs from functioning or will prevent specific client stations from connecting to your wireless APs. To block client stations and rogue APs, a wireless IDS broadcasts data so as to initiate a Denial of Service (DoS) attack against the devices. But you should use such blocking with extreme caution because intentionally inflicting a DoS might cause someone, such as an innocent neighboring business or one of your company's own employees visiting from another office, undue harm.
In a typical wireless IDS deployment, you install the central management console in a location where your administrators can monitor it and access it quickly when they need to. You place sensors in the same general vicinity as your APs and possibly in areas where you want to detect and prevent unauthorized wireless network activity. For example, if your policies prohibit using wireless networking in some areas of your business premises, then you might deploy sensors in those areas.
Table 1 summarizes the features of three wireless IDSs: AirDefense Enterprise 4.0, AirMagnet Distributed 4.0, and Red-M's Red-Detect 3.6. Let's take a closer look at these three platforms, each of which consists of a management server and wireless network sensors that monitor the wireless radio spectrum.
AirDefense Enterprise 4.0
AirDefense Enterprise 4.0 ships as a prebuilt rack-mountable server platform along with associated network sensors. The server runs the AirDefense management software on top of a modified and hardened version of Red Hat Enterprise Linux. The sensors are built from AP hardware, but instead of acting as APs, they run a customized OS designed by AirDefense specifically to monitor wireless-radio traffic.
To get AirDefense up and running, I had to configure the basic server settings, configure the sensors to communicate with the server, then configure detailed server settings based on my test wireless network environment. The initial configuration of the server was fairly simple. I logged in by using the default username and password, started the management interface, and changed a few required settings, such as the IP address and login password.
Configuring the sensors was equally easy. I used a serial cable to connect to a sensor from my desktop system, defined its IP address, changed the password, and defined the address of the server with which I wanted the sensor to communicate. After those tasks were accomplished, the server and sensor could begin to communicate and I could use the management console to make further configuration adjustments over the IP network.
The AirDefense management software is a Java-based application that you access by using any Java-enabled Web browser. It seemed somewhat sluggish in comparison to a Windows desktop application, but the GUI design is excellent and I found it easy to use after I learned my way around the various screens. The interface includes detailed context-sensitive help that makes learning the ins and outs of the interface far easier than referencing a printed manual would be.
AirDefense let me adjust monitoring policies to suit my needs, then monitor and manage the network for policy violations. For example, I could define configuration policies that apply to APs to monitor the allowed authentication modes, data transmission rates, channel parameters (including which channel to operate on), and encryption protocol parameters. As Figure 1 shows, I could adjust the security policies used to monitor one or more APs—including their channel frequency, allowed encryption protocols, whether they should be broadcasting Service Set Identifier (SSID) beacons, and their allowed authentication modes—at one screen.
Performance policies let me control how many client-to-AP associations were allowed per minute and how much bandwidth was available for communication between APs and the local Ethernet network as well as for station-to-station communication that travels through an AP. I could use vendor policies to permit only certain client stations to connect to certain APs. For example, I could define a policy that let only Linksys-based client stations connect to Linksys APs. Channel policies allowed control over what times of day wireless connectivity could occur and whether ad hoc stations were allowed.
AirDefense uses the policy definitions to detect violations while monitoring the airwaves. When a policy violation triggers an alarm in a sensor, the sensor sends the alarm data to the central management console, which logs the alarm and makes it available for viewing in the console interface. Alarms can also be sent to syslog servers via SNMP, an email message, or another method. Alarms indicate which device violated policy and include the violation category, the specific violation, a date stamp, the priority level, and a counter that shows how many times the violation has occurred.