Performance issues capturing wireless traffic

From a hardware design perspective, the wireless capture device must be able to accommodate the theoretical maximum throughput associated to all the communication channels. By default, 802.11g networks can transmit at 54 Mbps rates, that is, an aggregated throughput of 756 Mbps (14 channels x 54 Mbps).

The device internal architecture bus, interconnecting all the wireless cards, can affect the tool performance and discard traffic, invalidating the evidence collected. To avoid that, the computing architecture must support this maximum aggregated capacity. As a reference, these are the maximum data rates for the most commonly used PC-based bus technologies available nowadays: PCI 2.2 (264 Mbps), USB 2.0 (480Mbps), CardBus (1056 Mbps), PCI-X (1064 Mbps), Express Card (2.5 Gbps) and PCI-X 2.0 (4.3 Gbps). Not only the main bus, but other components, such as the memory bus or the disk interface and hard drives must support the previously mentioned data rate. As a reference, DDR2-667 SDRAM memory modules provide high data transfer up to 42 Gbps and current SATA disks support 1.5 Gbps data rates.

Based on a specific legal case, the analyst could be required to collect data from multiple domains, such as static locations, like office buildings or company facilities, the suspect’s home, public areas such as hotels or airports, and moving locations, such as in a car prosecution. Therefore, wireless forensics solutions require large storage devices to save all the data collected.

Open-source and commercial tools

The type of tool required for professional wireless forensics activities can be built using standard equipment, such as a common PC-architecture and commercial wireless network cards. However, a high-quality device that meets all the different requirements mentioned along this article would require a considerable design and implementation investment.

Nowadays there are also a couple of commercial tools that could be used for wireless forensics:

• The Janus Project [ref 6] is a commercial tool, presented at the Defcon 2006 conference, that contains 8 wireless cards for wireless scanning, data capture and encryption cracking.
• The WLAN-14 [ref 7] Linux-based commercial device, from Aircapture, was designed as a pure wireless forensics tool for law enforcement and security officers to securely collect 802.11b/g wireless data. It offers 15 wireless cards, a GPS, one external antenna connector and support for hot-swappable disks.

The former was conceived as a wireless traffic capture and cracking tool, and the later is a pure wireless forensic device.

Tool design requirements and best practices for wireless forensics

The following list summarizes some best practices, tips and tricks, and additional technical forensic considerations that should be evaluated when building or acquiring a wireless forensic tool or device for capturing 802.11 network traffic as legal evidence.

• The device should have 15 radio components (or cards) to be able to monitor all fourteen 802.11b/g channels and, at the same time, channel hop through the spectrum to identify new wireless networks (this being the purpose of the 15th radio).
• The use of a GPS (Geographical Positioning System) device can provide accurate timestamps and outdoor location capabilities, required to corroborate when and where the evidence (wireless traffic) was collected. Open-source implementations, such as gpsd [ref 8], are commonly used for this purpose by wireless tools like Kismet for wardriving purposes. This GPS logging information is crucial during the analysis phase to match the data collected with the physical location of the capturing devices.

  From a forensic perspective, and in order to be able to consider the GPS data as evidence too, it is very relevant to measure and log the internals of when the GPS device is synchronized with the GPS satellites, that is, be able to show that the device is providing accurate information.

• The tool must capture all traffic without applying any capture filter, to not miss any real evidence. Only if regulations enforce it, filters would be applied during the capture phase to only collect traffic from specific access points or clients based on their MAC addresses (BSSID or station address). Filters can always be applied later, during the analysis phase, to focus on specific traffic flows.
• It is recommended that the wireless forensic tool be a completely passive device, not generating any traffic into the medium. This constraint can be enforced by design using a hardware attenuator that reduces or cancels the transmission power, or/and a one-way reception amplifier. This can also be enforced at the software level by placing the wireless cards in monitor mode, although it is important to denote that the latest Linux wireless cards drivers allow one to inject traffic in this “passive” mode.
• The device should provide an external antenna connector to expand the default wireless cards’ reception capabilities by using high-gain directional or omnidirectional antennas. The antennas increase the distance from where the RF signal, and therefore network traffic, can be collected. For high range reception, it is recommended to use, as a generic reference, omidirectional antennas of around 15dBi and directional parabolic grid antennas of around 24dBi.
• In some risky scenarios, it can be dangerous for the forensic examiner (and his physical integrity) to stay near or around the suspect area, so it would be desirable to have some kind of remote access capabilities to the capture device. For example, including an additional 802.11a interface to a pure 802.11b/g capture device allows accessing the system wirelessly and remotely without interferences. This remote management interface must be strongly secured so that the forensic device is not compromised, both from the wireless access perspective, and from the upper-layer protocols point of view, using SSH, SSL or IPSec to provide strong authentication and encryption.
• In order to collect additional information about the traffic, and what the estimated suspect location is, it is recommended to add specific signal strength information, in the form of the Prism monitoring header, when capturing wireless traffic.

  This additional header (see Figure 1 below) adds 144 bytes, is generated by the wireless driver, and contains received signal strength (RSSI), capture device, channel, and other signal/noise quality information [ref 9].

Figure 1. Prism monitoring header through Wireshark.

Although the signal information reported by the wireless cards cannot be accurately translated to the physical layout location due to multiple RF behaviors, such as reflection, refraction, diffraction or scattering, this information can be very useful to compare the different values collected during a capture session and map network traffic with signal properties.

The following commands show how to enable and disable the Prism monitoring header in Linux for various wireless cards/drivers. Based on the driver version the header can be available by default and the set/unset commands can vary:

- Prism 2.X cards (hostap driver):
# iwpriv wlan0 monitor 3    --> Prism header ON
# iwpriv wlan0 monitor 2    --> Prism header OFF

- Prism 2.X cards (wlan-ng driver):
# wlanctl-ng wlan0 lnxreq_wlansniff prismheader=true enable=true channel=6
# wlanctl-ng wlan0 lnxreq_wlansniff enable=true channel=6

- Atheros cards (madwifi driver):
# sysctl -w dev.ath0.rawdev=1         --> Create ath0raw
# ifconfig ath0raw up
# sysctl -w dev.ath0.rawdev_type=0    --> Normal 802.11 frames
# sysctl -w dev.ath0.rawdev_type=1    --> 802.11 + Prism headers

- PrismGT cards (prism54 driver): [*]
# iwpriv eth1 set_prismhdr 1    --> AVS WLAN header ON
# iwpriv eth1 set_prismhdr 0    --> AVS WLAN header OFF


[*]: The AVS WLAN header is an alternative Prism header format, that only adds 64 bytes to the standard 802.11 frames [ref 9], introduced by Absolute Value Systems for the wlan-ng monitor mode, which is used by Prism54 and other drivers.
• The tool should collect the traffic in the standard Pcap format (Packet CAPture, associated to the libpcap library [ref 10]), recognized by most commercial and open-source traffic capture and analysis tools.
• The wireless hardware (cards or radio components) used must have very good receive sensitivity (Rx), to increase the chance of collecting traffic even in the worst conditions. The best wireless cards in the market nowadays are capable of providing a Rx of -105 dBms at very low rates, such as the Atheros XR technology [ref 11] (-85 dBm is the reference value reflected in the IEEE 802.11 specification).

  The wireless output power is not relevant unless the tool implements some active transmission capabilities, such as when traffic is generated to increase the chance of obtaining the WEP key (covered in part two). Prior to running active actions, their legal implications must be evaluated.

• The physical characteristics of the multiple wireless hardware components limit the reception quality of the device. The internal device design should consider the usage of a high performance low noise reception amplifier to compensate the loss associated to all the cabling, the power splitter and the connectors linking all the different built-in cards.
• It is recommended to have advanced logging capabilities in the capture device itself, so that all the actions and steps executed in the device can be accurately tracked and used as evidence corroboration in the court of law. The integrity of these logging records should be assured through hashing algorithms (MD5 and SHA-1).
• Finally, all the data collected, specifically, the Pcap files and GPS information, must be cryptographically hashed once the capture session has been finalized, and apart from having a repository of hash values, they should be included in the audit log too. This hashing information will help to preserve and verify the integrity of the evidence.

Concluding part one

Wireless technologies, and especially Wi-Fi, are here to stay and are expanding to new devices used with both harmless and malicious intent. The first part of this article series has described wireless forensics as a discipline required to investigate security attacks and incidents through (and over) 802.11 wireless data networks.

The article has pointed out the challenges and the complexity associated with wireless traffic acquisition, and has provided design requirements, tool references and best practices for wireless forensics. In part two we shall introduce the challenges for wireless traffic analysis, including advanced anti-forensic techniques and some legal connotations.

References

[ref 1] “Cisco Channels and Antenna Settings”. Cisco. http://www.cisco.com/en/US/products/hw/wireless/ps4570 /products_configuration_guide_chapter09186a0080209251.html
[ref 2] “HP ProCurve Wireless Radio Country Approvals Matrix”. HP. November 2005. http://www.hp.com/rnd/pdfs/country_approvals_matrix520wl.pdf
[ref 3] IEEE 802.11 – TGn. IEEE. http://grouper.ieee.org/groups/802/11/index.html
[ref 4] IEEE 802.16 (WiMAX). IEEE. http://grouper.ieee.org/groups/802/16/index.html
[ref 5] “Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”. IEEE. June 2003. http://standards.ieee.org/getieee802/download/802.11-1999.pdf
[ref 6] The Janus Project. http://www.tgdaily.com/2006/08/30/defcon2006_janus_project/
[ref 7] WLAN-14. AirCapture. http://www.aircapture.net
[ref 8] “GPSD: GPS Daemon”. http://gpsd.berlios.de
[ref 9] “Pcap file containing two packets with Prism and AVS headers respectively”. http://www.raulsiles.com/downloads/80211_headers.pcap
[ref 10] “LibPcap: Packet capture library”. Tcpdump. http://www.tcpdump.org
[ref 11] “Atheros Extended Rate XRTM Technology”. May 2004. http://www.atheros.com/pt/whitepapers/atheros_XR_whitepaper.pdf

About the author

Raul Siles is a senior independent security consultant based in Spain and a SANS certified instructor. His current security research interests, related with this article, include wireless security, incident handling and computer forensics, and VoIP security. He is one of the few individuals who have earned the GIAC Security Expert (GSE) designation. More information can be found on his website, www.raulsiles.com.

Reprints or translations

© 2007 SecurityFocus

Comments?