In: Root » Electronics and communication » Protocols » Detecting Unauthorized 802.11 Cards and Access Points
learn more...The first goal is detection. Can we tell when someone powers on a card within range of the local network? This can be done with off-the-shelf components and free software. The Cisco Aironet driver included with the more recent Linux kernels supports "RF Monitor" mode, which permits promiscuous monitoring of 802.11 packets - specifically, monitoring raw 802.11 frames to detect if there are any telltale frames broadcast by a rogue access point or card. As outlined in the original 802.11 specification, there are three classes of 802.11 frames. With the goal of detecting rogue access points and unauthorized wireless ethernet cards, we are primarily interested in class 1 and 2 frames. Class 1 frames are the only frames allowed in state 1, the unauthenticated state, and are largely management frames used for authentication, beacons, and probe requests. Class 2 frames are allowed in both states 1 and 2, and are used for association and reassociation. From access points, we would expect to see a large number of beacon frames (Class 1). From unassociated Ad-hoc clients scanning in active mode, we would expect to see a large number of probe requests (also Class 1). To test this hypothesis, a method of monitoring all 802.11 management frames is needed, which the Cisco card and Linux driver are capable of in "RF Monitor mode." Setup To put the card into RF Monitor mode, any BSS (use "Mode: r" for plain RF monitor mode): # echo "Mode: y" > /proc/driver/aironet/eth0/Config # Then, start logging packets with tcpdump, saving them to a file for later analysis with ethereal: # tcpdump -i eth0 -s 0 -w capturefile # Unauthorized Ad-hoc network The first test was to confirm the ability to detect a WLAN card being powered on. A Lucent Orinoco card was configured in Ad-hoc mode on a Win2k laptop, and turned on to find out if there were any characteristic frames sent out by the Orinoco card when it was put into Ad-hoc mode. After the card initialized, tcpdump was stopped, ethereal started, and the capture file opened. A large number of probe requests from the Orinoco card were found, confirming that it was indeed possible to detect when someone within close range had powered up a wireless ethernet card in ad-hoc mode. The dissected frame was as follows:
Indeed, it is possible to tell if someone starts an actively scanning card in ad-hoc mode, and quite a bit of useful information can be gleaned from a single frame. Most relevant are the SSID and the MAC address, since they can be used to track down a particular card and/or person. Unauthorized Access Point The next test was to confirm the possibility of detecting a rogue access point. A tcpdump session was started, and then a Cisco Aironet 340 access point was turned on. After the access point had finished booting, the dump was examined with ethereal, and a large number of beacon frames sent out by the access point were found. Following is one such frame, again dissected by ethereal:
Unauthorized Client The final tested condition was unauthorized clients. The first scenario considered (the more likely scenario), is that someone brings a foreign card and powers it up with the wrong SSID. If the card was actively scanning, probe requests would be seen from this card as it attempted to find an access point. The second scenario is that someone brings a foreign card and powers it up with the correct SSID. This one turns out to be a little more problematic to detect, in that there will be only a few 802.11 management frames to trigger an alert, and then more "normal" traffic. This is problematic primarily because of the way RFMON_ANYBSS mode on the Cisco card works - despite its name, the card cannot receive packets simultaneously from all BSS's in range, especially if those BSS's use different frequencies. The consequence is that it takes some manual intervention to sniff traffic from a particular BSS - see the section below on "Problems and Complications" for more details on this problem and how to work around it. This problem was ignored and instead the focus was on the few 802.11 management frames that do show up readily in the sniffer - both scenarios turned out to produce similar probe requests, so both scenarios are treated as identical. The dissected probe request sent out by this card:
Problems and Complications A few problems came to light with the Cisco card and driver that need to be mentioned. The first problem is that the Cisco card, by default, even in RFMON and RFMON_ANYBSS modes, does not actively scan for traffic on all channels at all times. The following are the conditions under which it will rescan for BSS's:
All of these conditions will "kick" the card into rescanning. To build a practical detection device, the card should be kicked at regular intervals, perhaps every minute. A simple script to touch the BSSList file every minute will do the trick. Second problem: Not all the BSS's in range showed up reliably in the file /proc/driver/aironet/eth0/BSSList. When the card is put into RFMON mode, transmitting is disabled, so the card cannot scan actively for BSS's by sending out probe requests. Therefore, the card must use passive scanning. Instead of sending out probe requests, the card listens for beacons. Passive scans use a timer—the card will listen for beacon frames until the timer expires and then move to another channel. The problem with the Cisco card is that this timer is set too low. The default value is 40ms, which was insufficient on our test network to notice all BSS's, regardless of the range or relative signal strength of the access points. The solution was to add this line to the card initialization routine, setup_card, in airo.c: cfg.beaconListenTimeout = 120; Tripling this timeout made BSS detection work reliably. Consequently, all of our access points showed up in BSSList, all the time. Third problem: Despite its name, even putting the card in RFMON_ANYBSS mode did not cause the card to receive traffic from all of our access points, which were all using different frequencies and were probably synchronized differently. The card itself chose a BSS to synchronize to base on its own algorithm (probably on its assessment of the relative signal strength). The problem with this is that we want to see traffic from all BSSs in range, not just those that happen to have the strongest signals. A way could not be found to disable this feature on the Cisco card, but there is a workaround - the Linux driver provides a /proc interface to set a preferred AP. Once the list of BSSs in range of the scanner is found (/proc/driver/aironet/eth0/BSSList), choose the one to monitor and enter the MAC address in the file /proc/driver/aironet/eth0/APList. This will force the card to synchronize with that BSS and switch to that channel, after which traffic from that BSS can be received and used for signal strength assessments or monitoring for suspicious activity. Conclusions These simple tests confirm that there are 802.11 frames that are characteristic of typical rogue access points and unauthorized ad-hoc networks, and that these frames can be detected and analyzed using off-the-shelf components and free software. Using these concepts along with a database of trusted access points and cards and the fingerprints of suspicious frames, ethereal could be used as a fundamental building block in a full-blown 802.11 intrusion detection system. |
||||||
Disclaimer
1) E-articles is not responsible for the information contained by this article as well for any and all copyright infringements by authors and writers. E-articles is a free information resource. If you suspect this article for any copyright infringement, please read the terms of service and contact us to investigate the problem.
2) E-articles is not responsible for inaccuracies, falsehoods, or any other types of misinformation this article may contain and will not be liable for any loss or damage suffered by a user through the user's reliance on the information gained here. link to this article |
