Once a sufficient number of network behavior statistics are gathered, a proper wireless IDS can start looking for the suspicious events indicating the possibility of malicious attack. These events might be manifested as the presence of certain frame types, frequency of frame transmission, frame structure and sequence number abnormalities, traffic flow deviations, and unexpected frequency use. Let's categorize the events a quality wireless IDS should be able to detect and issue a warning for.

1 RF/Physical Layer Events

• Additional transmitters in the area.

• Channels not used by the protected WLAN in use.

• Overlapping channels.

• Sudden operating channel change by one or more monitored wireless devices.

• Loss of signal quality, high level of noise, or low SNR.

These events can indicate connectivity or networking problems, severe network misconfiguration, rogue device placement, intentional jamming, and Layer 1 and Layer 2 man-in-the-middle attacks.

2 Management/Control Frames Events

• Increased frequency of normally present network frames.

• Frames of unusual size.

• Unknown frame types.

• Incomplete, corrupted, or malformed frames.

• Floods of deassociate/deauthenticate frames.

• Frequent reassociation frames on networks without enabled roaming.

• Frames out of sequence.

• Frequent probe requests.

• Frames with ESSIDs different from the WLAN ESSID.

• Frames with the broadcast ESSID ("Any").

• Frames with frequently or randomly changing ESSIDs.

• Frames with ESSIDs or other fields typical for certain intrusion tools.

• Frames with MAC addresses not included in the ACL.

• Frames with duplicated MAC addresses.

• Frames with frequently or randomly changing MAC addresses.

These events can indicate network misconfigurations and connectivity problems, strong RF interference, wardrivers using active scanning tools in the area, MAC address spoofing on the WLAN, unsolicited clients connected to the WLAN, attempts to guess or brute-force a closed ESSID, or more advanced attackers mangling control and management frames to launch Layer 2 man-in-the-middle or DoS attacks.

3 802.1x/EAP Frames Events

• Incomplete, corrupted, or malformed 802.1x frames.

• Frames with EAP types not implemented by the WLAN.

• Multiple EAP authentication Request and Response frames.

• Multiple EAP failure frames.

• EAP start and EAP logoff frame floods.

• EAP frames of abnormal size ("EAP-of-Death").

• Fragmented EAP frames of small size.

• EAP frames with bad authentication length.

• EAP frames with bad authentication credentials.

• EAP frames with multiple MD5 challenge requests.

• EAP frames originating from illicit authenticators (rogue access points).

• Unfinished 802.1x/EAP authentication processes.

These events can indicate attempts to bypass the 802.1x authentication scheme, including clever rogue 802.1x device placement and access brute-forcing or advanced DoS attacks to disable the authentication mechanisms. Of course, the malformed 802.1x frames can result from strong RF interference and other Layer 1 problems.

4 WEP-Related Events

• Unencrypted wireless traffic present.

• Traffic encrypted with unknown WEP keys.

• Traffic encrypted with WEP keys of different lengths.

• Weak IV frames.

• Frames with repeated IVs in a row.

• No IV change.

• Fallback to the original WEP from more secure solutions such as TKIP.

• Failed WEP key rotation.

These events can indicate severe network security misconfigurations, insecure legacy equipment in use, users violating the security policy, rogue wireless device placement, or use of traffic injecting tools (WEPwedgie, reinj) by advanced crackers.

5 General Connectivity/Traffic Flow Events

• Connectivity loss.

• Sudden surge in bandwidth consumption.

• Sudden decrease in network throughput.

• Sudden delay increase on a point-to-point link.

• Increased packet fragmentation level.

• Frequent retransmits.

These events should prompt a future investigation to find the exact causes of the problem detected. An intelligent IDS inference engine should be able to link these problems to the different categories of events, thus partially automating the investigation problems.

6 Miscellaneous Events

• Associated, but not authenticated, hosts.

• Attacks on higher network layers triggering the "traditional" IDS.

• Unsolicited access point management traffic.

• Constantly duplicated or repeated data packets.

• Data packets with corrupt data link layer checksums/MIC.

• Flood of multiple concurrent network association attempts.

These events can indicate successful or unsuccessful cracker attacks, a host with misconfigured security settings, attempts to access and reconfigure the deployed access points, the use of traffic injecting tools, advanced DoS attacks against 802.11i-enabled hosts, or attempts to overwhelm the AP buffers with large numbers of connections from the wired or wireless side. Again, any cases of frame or packet corruption can be attributed to physical layer problems, such as interference and low signal strength.

Now you can easily recognize many of the telltale attack signs from the preceding event list. For example, frames with frequently changed MAC addresses and ESSIDs are a good indication of someone using a FakeAP. Alternatively, there is a way to brute-force closed ESSIDs using two client PCMCIA cards and Wellenreiter. We did not describe it in the Attack section because we have never tried it, and using essid_jack or dinject is far more efficient and saves resources. Such a brute-forcing attack generates frames with changing ESSIDs and MAC addresses (Wellenreiter's way to obscure the attacker's card vendor and identity). Frequent probe requests might indicate someone using Netstumbler or Ministumbler, and hosts suddenly changing their operation channel can flag out a possible man-in-the-middle attack.

Many of the events outlined can be a result of user misbehavior rather than a planned malicious attack. Users can plug in unsolicited wireless devices or use interference-creating appliances (Bluetooth, wireless cameras, cordless phones). They can connect to the AP without enabling WEP/TKIP if the AP permits it (a big mistake on the administrator's side) or miss/avoid firmware upgrades it ("if it works, don't fix it"), thus making your 802.11i-based security deployment efforts useless. Any system or network administrator knows how unruly and obnoxious some users can be.