SANS Intrusion Detection FAQ: Intrusion detection on wireless network?

Introduction

The IEEE 802.11b wireless LAN standard has become the de-facto for wireless network communications medium. The availability of inexpensive equipment coupled with wire-like network bandwidth and ease of use has driven rapid adoption by corporate and SOHO users. Unfortunately, the rapid implementation of this wireless technology is having other, unintended consequences.

Historical Context

Brought into the public eye 20 years ago by the movie War Games, war dialing, or systematically dialing ranges of phone numbers to discover computer systems, continues to plague corporate America. War dialing will often discover modems attached to corporate desktops, which are in turn connected to the corporate LAN. These computers are often loaded with remote control software, such as PCAnywhere or Carbon Copy, allowing the individual dialing the modem to control the remote computer as if they were sitting at the keyboard.

A similar situation is beginning to develop with wireless technology. Business units or individuals install wireless access points (AP), acting as bridges to the corporate LAN, broadcasting to anyone with a $50 wireless network card and a laptop, up to three football fields distant. “War driving,” like its cousin described above, allows those with the tools described here to find, catalog, and access vulnerable wireless APs, and possibly gain access to any physically connected network, from the relative anonymity of a rental car in the parking lot.

Objective

The scenario described above is but one of the threats which an intrusion detection analyst must consider. First, however, we must ask a more fundamental question: what is intrusion detection when applied to wireless networks? Intrusion detection systems collect information about observable or auditable events, which are then analyzed and correlated to determine things like cause or motive. Therefore, in order to provide a basis for wireless intrusion detection, we must first determine what can be observed and collected for analysis. This paper will discuss several rudimentary events which could be captured by a wireless intrusion detection system and present a survey of tools to accomplish those tasks.

This is not your father’s network

Current intrusion detection solutions rely on the relatively static and contained nature of wired networks. Potential intruders would need to gain physical access to a network jack or logically enter the network through well-defined pathways. Placing intrusion detection sensors was a matter of finding (or creating) places where all or most network traffic transited. These assumptions are no longer valid for wireless networks.

The IEEE 802.11 standard [1] defines two types of wireless network topologies: Independent Basic Service Set (IBSS, or “ad hoc”), and Basic Service Set (BSS, or “infrastructure”). The IBSS topology involves two or more wireless stations communicating peer-to-peer (Figure 1).

Figure 1


Figure 2

The BSS topology (Figure 2) adds an AP attached to a “distribution system” (usually a network, like Ethernet); all communications route through the AP.

An ad hoc network has some obvious disadvantages for intrusion detection. Yongguang Zhang and Wenke Lee have written an excellent paper [2] addressing this particular problem. They outline several fundamental issues with wireless ad hoc networks:

• Wireless stations are all independent nodes. Each must be responsible for it’s own protection from attack and compromise. Compromising only one node or introducing a malicious node may affect the viability of the entire network.
• No central point exists from which to monitor all network traffic.
• Differences between normal and anomalous traffic patterns may be indistinguishable. The mobile nature of the wireless stations can make legitimate network traffic appear suspect.

• data collection: the types of raw data the detection engines will utilize includes system and user activities, local communication activities, and “observable” (nodes within range) communications activities
• local detection – since it will be difficult to maintain and distribute an anomalous signature database, Zhang and Lee propose defining statistically “normal” activities specific to each node, which will therefore reside locally on each node.
• cooperative detection. If the local detection engine does not have enough evidence to alert on a suspected problem, it can ask other nodes for assistance. Information describing the detect gets propagated to neighboring nodes. Evidence returned from neighboring nodes can be used to create a new evaluation of the detect.

Infrastructure mode is where current intrusion detection methodologies and collection techniques become useful. Since all traffic transits through the AP, close proximity to the AP becomes a logical choice to place a sensor. Since 802.11b is essentially just another physical medium, the AP acts as a bridge – translating 802.11b frames to 802.3 (or some other network medium) frames, and vice versa. Data encapsulated at higher layers is unchanged. To collect events of interest at Layer 3 and above, one can rely on current tools, such as tcpdump. To look at frame information, however, each tool must be able to interpret the medium frame type.

Events of Interest

Several events of interest would be of obvious interest to an analyst monitoring an access point (it is assumed the reader has sufficient knowledge of the 802.11 standard; please see [1] and [3] for details).

General MAC Frames

Like IP packets, 802.11 frames [1] carry enough useful information to warrant monitoring.

Beacon Frames (Type 00, Subtype 1000)

“Beacon” frames are regularly transmitted by the AP, and contain information needed by a wireless station to begin the association/authentication process. An analyst may wish to analyze these frames to monitor for rogue access points or other potentially malicious traffic.

Capturing beacon frames is similar to sniffing network traffic on an Ethernet segment. The network card must be in promiscuous mode, but does not necessarily need to have a network address assigned to it. It can capture data, but is virtually invisible to everyone else on the network. The following tools are specifically built for this task (your mileage may vary):

Association and Authentication (Type 00)

Once an attacker collects an SSID, they may wish to return and actually use the wired network your AP is attached to. In order to do that, the attacker must begin the association and authentication process.

The first frame to be sent by the wireless station is an Association Request Management frame (subtype 0000), to which the AP responds with an Association Response Management frame (subtype 0001). The association response frame contains a 2-byte status code – “0” means success, while all others indicate a problem. Also, the attacker’s MAC address has been transmitted over the wireless medium. Analyzing association/authentication response codes and capturing MAC addresses would also be a good basis for intrusion detection events. 802.11b packet analysis tools are now required to capture and display this information. Tools which perform this function include:

Here is Mognet in action:

ARP

The address resolution protocol (ARP) is used to map an IP address to a corresponding hardware address [4]. Arpwatch (http://www-nrg.ee.lbl.gov/) is a tool which monitors changes to this information and can be used as a source of detection data. When applied to a wireless access point [5], arpwatch could be used to obtain information about wireless stations already authenticated and associated with the AP. Once a packet enters the wired side of the AP from the wireless side, interesting traffic may begin to appear. For example, Richard Johnson (http://www.monkey.org/openbsd/archive/ports/0012/msg00098.html) noted:

You'll see a lot of the following if you're watching ARPs from across an 802.11b wireless bridge to a 10baseT LAN or the like: ethernet mismatch

The source mac ethernet address didn't match the address inside the arp packet.

Analysis

Due to the large amount of raw data that will be collected by these tools, the analyst will be forced to develop procedures to reduce it. Statistical methods must be employed to bring order to the data. The anomaly detection routines described by Zhang and Lee [2] and XXX could be applied here. For example, given a fixed time period, tally the number of Association/Authentication requests and Association/Authentication response status codes and corresponding MAC address for typical network situations. This is called a “normal profile” in [2]. Other profiles not fitting this typical profile can be alerted to the analyst. In this case, a large number of Authentication response codes of 15 (Authentication rejected because of challenge failure), over a short period of time (both “large” and “short” will be defined by the normal profile), with the same source MAC address, should generate an event.

Conclusion

The process, methodology, and tools described above simply scratch the surface of wireless intrusion detection. This paper has described the most rudimentary form of wireless intrusion detection for the most basic network architecture– detecting wireless stations associating with an access point attached to a wired network. Much more work needs to be done develop the state of wireless intrusion detection. With the increasing popularity of “war driving”, this capability will certainly be required to help protect our wireless infrastructure.

References

1. ANSI/IEEE. “IEEE Standard for Information technology. Telecommunications and information exchange between systems. Local and metropolitan area networks. Specific requirements. Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.” 1999.
2. Zhang, Yongguang, Wenke, Lee. “Intrusion Detection in Wireless Ad-Hoc Networks.” Proceedings of the Sixth Annual International Conference on Mobile Computing and Networking. 2000.
3. Arbaugh, William A., Shankar, Narendar, Wan, Y.C. Justin. “Your 802.11 Wireless Network has No Clothes.” Department of Computer Science, University of Maryland. 31 March 2001.
4. Stevens, W. Richard. TCP/IP Illustrated, Volume 1. Massachusetts: Addison-Wesley. 1994.
5. Shipley, Peter. Interview. http://www.starkrealities.com/shipley.html. 31 July 2001.

< Previous Question | Back to Intrusion Detection FAQ Home | Next Question >