Getting Used to Efficient Wireless Interface Configuration

To perform efficient wireless security audits, you should familiarize yourself with using UNIX wireless configuration utilities. Yes, this means a lot of command line. However, there are significant advantages to be gained from knowing it, including understanding how more complicated wireless security tools work, being able to write useful shell scripts that save time and make your life easier, and, finally, saving a lot of battery power by not using a GUI (more on that in the following chapter).

Linux Wireless Extensions

We start with Linux Wireless Extensions as the most common wireless card and interface configuration utilities used on the Linux operating system. Linux Wireless Extensions were initially developed in 1996 to work with the first Hermes chipset cards. Wireless Extensions' support of Prism cards running under wlan-ng drivers is very limited and mainly related to (often incorrect) checking the inserted card configuration parameters. However, Prism cards running under HostAP drivers are perfectly supported and configurable by Linux Wireless Extensions. Besides, 802.11a cards using vt_ark5k drivers and combo cards under Madwifi are configured using the Extensions as well. Despite the comments in the INSTALL file considering possible installation difficulties, we have never encountered any when compiling the Extensions from source, and there is nothing wrong with installing it from your favorite distribution package, unless you have some code modification ideas in mind.

The most important utility in Linux Wireless Extensions is iwconfig:

arhontus:~# iwconfig --help

Usage: iwconfig interface [essid {NN|on|off}]

 [nwid {NN|on|off}]

 [mode {managed|ad-hoc|...}

 [freq N.NNNN[k|M|G]]

 [channel N]

 [sens N]

 [nick N]

 [rate {N|auto|fixed}]

 [rts {N|auto|fixed|off}]

 [frag {N|auto|fixed|off}]

 [enc {NNNN-NNNN|off}]

 [power {period N|timeout N}]

 [txpower N {mW|dBm}]

 [commit]

As you can see, practically any parameter of your WLAN can be configured using iwconfig. Some useful tips to keep in mind are these:

• Set essid as "off" or "any" when scanning for 802.11 networks/devices:

  
  

  
  arhontus:~# iwconfig eth0 essid off
  
  

  
  

• Set the nwid as "off" to have undefined domains accepted when scanning:

  
  

  
  arhontus:~# iwconfig eth0 nwid off
  
  

  
  

• Turn off the WEP key to accept unencrypted packets when scanning:

  
  

  
  arhontus:~# iwconfig eth0 key off
  
  

  
  

• Set the sensitivity threshold to the lowest value possible for your card, for example:

  
  

  
  arhontus:~# iwconfig eth0 sens -85 (if your card sensitivity is limited by -85 dBm)
  
  

  
  

• If your card supports variable transmitting power, set it to the minimum when scanning or analyzing traffic:

  
  

  
  arhontus:~# iwconfig eth0 txpower 1            (dBm)
  
  arhontus:~# iwconfig eth0 txpower 1mW          (mW)
  
  

  
  

• Unset the nickname and chosen access point address if enabled and check that the bit rate is set on "auto."

• You can preserve battery power by setting power management; for example:

  
  

  
  arhontus:~# iwconfig eth0 power timeout 300u all
  
  

  
  

  ("All" is needed when scanning for networks.)

• The command iwconfig <interface> mode master would only work with HostAP drivers and Prism chipset cards.

• When setting a WEP key, do not forget that if the key is given in ASCII and not hex, 's:' should be appended:

  
  

  
  arhontus:~# iwconfig eth0 key s:idonttrustwep
  
  

  
  

In all these command examples, as well as many more to follow, we use the example eth0 interface for Hermes chipset, wlan0 for Prism and ath0 for Atheros (madwifi) chipsets, and eth0 and wifi0 for Cisco Aironet chipset cards. Don't forget to use appropriate interfaces in your practice. When iwconfig is executed without any given parameters, it displays the data about all available 802.11 interfaces taken from /proc/net/dev.

The latest versions of Linux Wireless Extensions support automatic scanning for access points in range and taking the ESSID/frequency of the appropriate access point found. In our observations, the scanning might not work perfectly unless the interface is first brought up with ifconfig (e.g., ifconfig eth0 up) and, until the interface is up, iwconfig might show a freakish frequency value.

If for some reason you need an easy-to-use GUI interface to iwconfig, you can use xwconfig from http://www.random-works.co.uk/xwconfig/ (Figure 4-3).

Iwpriv, or the private extension, is the important companion tool to iwconfig: Whereas iwconfig deals with setting generic standard-defined parameters, iwpriv enables driver-specific configuration changes. Iwpriv is used for setting wireless roaming with some 802.11 card drivers (e.g., wavelan_cs). The main implication of iwpriv in security testing and wireless protocol debugging is setting the card into a monitor mode. For Hermes chipset cards running under the Shmoo-patched Orinoco driver, the command to put such a card into the monitor mode is as follows:

arhontus:~# iwpriv eth0 monitor <mode> <channel>

where the mode can be 1 (append Prism II headers-specific data to the frame, ARPHRD_IEEE80211_PRISM device type), 2 (monitor mode with no Prism II-specific info, ARPHRD_IEEE80211 device type), and 0 (turn the monitor mode off). For Prism chipset cards running under HostAP drivers, this would be the corresponding command:

arhontus:~# iwpriv wlan0 monitor <mode>

where the mode value 2 is ARPHRD_IEEE80211 device type, mode value 3 is ARPHRD_IEEE80211_PRISM device type, and mode value 0 is also turning the RFMON mode off. Interestingly, the Linux Wireless Extensions version 25 and later iwconfig can be used to set Prism cards under HostAP into the monitor mode:

arhontus:~# iwconfig wlan0 mode monitor

This might make obsolete the use of iwpriv with the latest HostAP and also Madwifi versions. You can still set the device type and dumped headers data to both possible values with this:

arhontus:~# prism2_param wlan0 monitor_type <type>

where type 0 is IEEE 802.11 headers (ARPHRD_IEEE80211) and type 1 is Prism2 + IEEE 802.11 headers (ARPHRD_IEEE80211_PRISM).

HostAP drivers come with their own 802.11 frame parser called wlansniff in the sniff subdirectory:

arhontus:~# ./wlansniff -h

wlansniff [-h] [-b#] [auth] <wlan#>

 -h = help

 -b0 = do not show beacons

 -b1 = show only one line of data for each beacon

 -b2 = show full beacon data

 -auth = show only authentication frames

You need to put the card into the monitor mode (both ARPHRD_IEEE80211 and ARPHRD_IEEE80211_PRISM device types would do) before running wlansniff.

Finally, when you use iwconfig to set an Atheros chipset 802.11a card into the monitor mode the command is this:

arhontus:~# iwconfig wlan0 mode monitor

After executing this command, bring up the wireless interface (ifconfig wlan0 up). A simple vt_ar5k_monitor.sh shell script to do this can be found in the vt_ar5k/misc directory. You can also enable prism2-compatible headers appending with iwpriv wlan0 prism 1 command if necessary.

802.11 Basics: Prism Headers and RFMON Mode The Prism monitor header we referred to earlier is not a part of the 802.11 frame header as defined by the IEEE standard. It is a physical layer header generated by the firmware of the receiving Prism chipset. This header includes Received Signal Strength Indication (RSSI), Signal Quality (SQ), Signal Strength and Noise (in dBm), and Data Rate (in Mbps) parameters; watching it can be helpful. The Prism header is defined by a hex value different from the standard 802.11 header in the if_arp.h file on different Unices: /* Dummy types for non ARP hardware */ ......................................................... #define ARPHRD_IEEE80211 801 /* IEEE 802.11*/ #define ARPHRD_IEEE80211_PRISM 802 /* IEEE 802.11 + Prism2 header */ (This is an example from Linux if_arp.h.) We hope that now all references to ARPHRD_IEEE80211 and ARPHRD_IEEE80211_PRISM in the text are more understandable. As for the RF monitor (RFMON) or monitoring mode itself, it is commonly confused with the promiscuous mode on the Ethernet (as in ifconfig eth0 promisc). These are two completely different modes. Promiscuous mode on 802.3 networks is accepting all frames and it doesn't matter to whom on a LAN segment the frames are addressed by MAC. RFMON mode on 802.11 networks is passing all 802.11 frames information (usually dealt with by the client card firmware) to the end-user applications, thus allowing dumping and analysis of such frames. This is why so much attention is paid to the client card driver's ability to support RFMON and the ways of enabling the mode. Let's look at the practical example of a PCMCIA card in three possible states: arhontus:~# ifconfig wlan0 up arhontus:~# tcpdump -i wlan0 tcpdump: WARNING: wlan0: no IPv4 address assigned tcpdump: listening on wlan0 0 packets received by filter 0 packets dropped by kernel No traffic can be seen. arhontus:~# ifconfig wlan0 promisc arhontus:~# tcpdump -i wlan0 tcpdump: WARNING: wlan0: no IPv4 address assigned tcpdump: listening on wlan0 0 packets received by filter 0 packets dropped by kernel Again, no traffic can be seen, even though one of the wireless hosts is pinged from this machine. The traffic is encrypted with WEP; if it wasn't you would see the packets flying by, but you still won't see 802.11 frames. Now we put the card into the monitor mode and run tcpdump again: arhontus:~# iwconfig wlan0 mode monitor arhontus:~# tcpdump -i wlan0 17:53:59.422074 Beacon ( ) [ 11.0 Mbit] ESS CH: b , PRIVACY 17:53:59.440055 Acknowledgment RA:0:90:4b:6:15:4f 17:53:59.442675 Acknowledgment RA:0:2:2d:8e:74:5e 17:53:59.524466 Beacon ( ) [ 11.0 Mbit] ESS CH: b , PRIVACY Here they are! We hope this example is sufficiently convincing.

A few other utilities included with Linux Wireless Extensions are iwevent, iwgetid, iwlist, and iwspy. Iwevent reports changes of settings such as ESSID, channel, mode, WEP, and network ID, as well as joining new access points or ad-hoc cells, dropped transmitted packets, and the registration or unregistration of new clients if the card is run in a master mode (acts as an access point under the HostAP drivers). As such, iwevent can be useful for creating network monitoring and even intrusion detection scripts. Iwgetid is an auxiliary utility that shows current wireless network parameters such as access point (AP) MAC address, interface mode, channel, and ESSID and can be useful in scripting together with iwevent. Iwspy sets a list of host names, IPs, or MAC addresses for wireless hosts and monitors the link quality for every device on the list using /proc/net/wireless. Iwlist is another parameter-showing utility that has some very useful options including these:

arhontus:~# iwlist -h

Usage: iwlist [interface] frequency

 [interface] channel

 [interface] ap

 [interface] accesspoints

 [interface] bitrate

 [interface] rate

 [interface] encryption

 [interface] key

 [interface] power

 [interface] txpower

 [interface] retry

 [interface] scanning

The iwlist frequency or channel commands demonstrate a list of frequencies supported by the selected interface and currently used frequency; for example:

arhontus:~# iwlist eth1 freq

eth1 14 channels in total; available frequencies:

 Channel 01 : 2.412 GHz

 Channel 02 : 2.417 GHz

 Channel 03 : 2.422 GHz

 Channel 04 : 2.427 GHz

 Channel 05 : 2.432 GHz

 Channel 06 : 2.437 GHz

 Channel 07 : 2.442 GHz

 Channel 08 : 2.447 GHz

 Channel 09 : 2.452 GHz

 Channel 10 : 2.457 GHz

 Channel 11 : 2.462 GHz

 Channel 12 : 2.467 GHz

 Channel 13 : 2.472 GHz

 Channel 14 : 2.484 GHz

 Current Frequency:2.412GHz (channel 01)

Ensure that the interface you use supports all frequencies you might encounter in the country of operation.

802.11 Basics: 2.4–2.5 GHz (Medium ISM Band) Frequencies In different countries the available channels vary due to legal and licensing regulations. 802.11b channel is 22 MHz wide. The IEEE standard defines minimum space between channels as 5 MHz. Thus, the channels start from 2.412 ± 11 MHz followed by 2.417 ± 11 MHz and so forth. As you can see, the channels badly overlap (Figure 4-4). Figure 4.4. DSSS channels 2.4Ghz spectrum. [View full size image] In theory, nonoverlapping channels would be 5 x 5 MHz apart, because 25 > 22 MHz. Thus, there could only be three access points in a single network coverage area. In the United States it means channels 1, 6, and 11. In the rest of the world there is the possibility to have up to 14 channels (83.5 MHz – 11 MHz)/5 MHz = 14.5. That would mean 2, 7, 12/3, 8, 13/4, 9, 14 and many other (1, 8, 14, etc.) combinations of three access point channels are possible. Now you know where to look for APs channel-wise and how many APs would be there, unless the system administrator does not understand the concept of radio interference and deploys multiple APs on overlapping channels.

The iwlist rate command lists the supported connection speed values and the current connection speed, iwlist key/enc shows the WEP keys available and lists their sizes (ensure proper iwlist and /etc/pcmcia/wireless.opts permissions), and iwlist txpower can help you find out if your card supports regulated transmitted power output:

arhontus:~# iwlist eth1 txpower

eth1 6 available transmit-powers:

    0 dBm     (1 mW)

    7 dBm     (5 mW)

    14 dBm    (20 mW)

    15 dBm    (30 mW)

    17 dBm    (50 mW)

    20 dBm    (100 mW)

Current Tx-Power=20 dBm      (100 mW)

(This example is a Cisco Aironet 350 card.)

The most interesting iwlist command is iwlist scan (the obsolete one is iwlist ap/accesspoint), which shows all APs and ad-hoc networks in range and even gives a variety of their settings like the signal quality. If you run HostAP in a master mode, you have to use the old iwlist ap and not iwlist scan command, although by the time this book comes out this might change. Also, iwevent has an option of showing that iwlist scan request is completed (iwlist <interface> scanning), which can come in handy in your scripting adventures. The iwlist scan option gives you an opportunity for the quick discovery of access points in range while staying connected to your AP and without putting the card into the monitor mode.

We have included the fine manpages for Linux Wireless Extensions in Appendix D. Although many consider including manpages or Requests for Comments (RFCs) a waste of space, in our experience sometimes there is no substitution to printed text, and manpages make perfect bedtime reading. :)

Linux-wlan-ng Utilities

There are multiple reasons you might want to use linux-wlan-ng drivers with a Prism chipset card. The configuration options are immense, RFMON mode can be set out of the box, and the majority of network discovery and security-related tools support linux-wlan-ng by default. In fact, the development of LINUX wireless security auditing tools has started exclusively on Prism chipset cards and wlan-ng drivers. The linux-wlan-ng utilities include wlancfg and wlanctl-ng. These tools are very powerful, but their syntax is somewhat awkward and lacks documentation. Nevertheless, linux-wlan-ng utilities syntax closely reflects 802.11 standard specifications and standard-defined SNMP MIBs, which makes playing with wlancfg and wlanctl-ng very educational. If you have trouble understanding linux-wlan-ng and its utilities, you can always consult a linux-wlan maillist at http://archives.neohapsis.com/archives/dev/linux-wlan/.

Compiling linux-wlan-ng is very straightforward:

arhontus:~# ./Configure

-------------- Linux WLAN Configuration Script -------------

The default responses are correct for most users.

Build Prism2.x PCMCIA Card Services (_cs) driver? (y/n) [y]:

Build Prism2 PLX9052 based PCI (_plx) adapter driver? (y/n) [n]:

Build Prism2.5 native PCI (_pci) driver? (y/n) [n]:

Build Prism2.5 USB (_usb) driver? (y/n) [n]:

Linux source directory [/usr/src/linux]:

The kernel source tree is version 2.4.20.

The current kernel build date is Thu Mar 6 22:53:57 2003.

Alternate target install root directory on host []:

PCMCIA script directory [/etc/pcmcia]:

Module install directory [/lib/modules/2.4.20]:

It looks like you have a System V init file setup.

Prefix for build host compiler? (rarely needed) []:

Build for debugging (see doc/config.debug) (y/n) [n]: y

Configuration successful.

arhontus:~# make all && make install && make clean

You don't need to build the prism2_cs and p80211 modules if you already have the ones that come with your kernel. Interestingly, apart from placing wlan-ng and wlan-ng.conf files in /etc/pcmcia, linux-wlan-ng creates an additional /etc/wlan directory, which contains shared, wlan.conf and wlancfg-DEFAULT files (check them out). Some useful examples of employing wlanctl-ng include the following:

• Switching the card to the monitor mode:

  
  

  
  arhontus:~# wlanctl-ng wlan0 lnxreq_wlansniff channel=6 enable=true
  
  

  
  

  (You can also append prismheader=true if desired.)

• Associating with a network:

  
  

  
  arhontus:~# wlanctl-ng wlan0 lnxreq_ifstate ifstate=enable
  
  arhontus:~# wlanctl-ng wlan0 lnxreq_autojoin ssid=<yourAPsSSID> authtype=opensystem
  
  

  
  

(Note: Without executing the first command the association would not take place.)

In our experience, the best way to configure Prism cards running under wlan-ng drivers is using the wlancfg show <interface> command followed by wlancfg set <interface> and inputting:

arhontus:~# wlancfg show wlan0

dot11StationID=00:02:6f:01:4c:49

dot11PowerManagementMode=active

dot11DesiredSSID=''

dot11DesiredBSSType=infrastructure

dot11OperationalRateSet=02:04:0b:16

dot11AuthenticationAlgorithmsEnable1=true

dot11AuthenticationAlgorithmsEnable2=false

dot11PrivacyInvoked=false

dot11WEPDefaultKeyID=0

dot11ExcludeUnencrypted=false

dot11MACAddress=00:02:6f:01:4c:49

dot11RTSThreshold=2347

dot11FragmentationThreshold=2346

dot11Address1=00:00:00:00:00:00

..........................................................

dot11Address32=00:00:00:00:00:00

p2MMTx=false

p2Comment=''

p2LogEvents=false

p2CnfPortType=1

p2CnfOwnMACAddress=00:02:6f:01:4c:49

p2CnfDesiredSSID=''

p2CnfOwnChannel=3

p2CnfOwnSSID='non-spec'

p2CnfOwnATIMWindow=0

p2CnfSystemScale=1

p2CnfMaxDataLength=2312

p2CnfWDSAddress=00:00:00:00:00:00

p2CnfPMEnabled=false

p2CnfPMEPS=false

p2CnfMulticastReceive=true

p2CnfMaxSleepDuration=100

p2CnfPMHoldoverDuration=100

p2CnfOwnName=''

p2CnfWEPDefaultKeyID=0

p2CnfWEPFlags=

p2CnfAuthentication=0

p2CnfTxControl=512

p2CnfRoamingMode=1

p2CnfRcvCrcError=

p2CnfAltRetryCount=7

p2CnfSTAPCFInfo=1

p2CnfTIMCtrl=0

p2CnfThirty2Tally=false

p2CnfShortPreamble=long

p2CnfBasicRates=0,1,2,3

p2CnfSupportedRates=0,1,2,3

p2CreateIBSS=false

p2FragmentationThreshold=2346

p2RTSThreshold=2347

p2TxRateControl=0,1,2,3

p2PromiscuousMode=false

p2TickTime=10

Then do wlancfg set wlan0 and cut and paste the necessary variable and its value of choice. For example, for the monitor mode do:

arhontus:~# wlancfg set wlan0

p2CnfOwnChannel=6

p2CnfOwnName='31337'

p2PromiscuousMode=true

Ctrl-D

Congratulations, you are monitoring channel 6 (okay, we admit that the p2CnfOwnName='31337' string is not really necessary). Finally, if you do need a GUI, there is a tiny utility called WlanFE (The Linux Wireless Front End) that might come in handy (Figure 4-5) and gpe-wlancfg GUI for handhelds.

However, we encourage you to use the command line for a variety of reasons, some of which are revealed later.

Cisco Aironet Configuration

As stated before, the configuration of Cisco Aironet PCMCIA cards can be done by editing a text file created in /proc/driver/aironet/, for example:

arhontus:~# cat /proc/driver/aironet/eth1/Config

Mode: ESS

Radio: on

NodeName:

PowerMode: CAM

DataRates: 2 4 11 22 0 0 0 0

Channel: 6

XmitPower: 100

LongRetryLimit: 16

ShortRetryLimit: 16

RTSThreshold: 2312

TXMSDULifetime: 5000

RXMSDULifetime: 10000

TXDiversity: both

RXDiversity: both

FragThreshold: 2312

WEP: open

Modulation: cck

Preamble: short

Simply open your text editor of choice (shame on you if it isn't vi or emacs!) and change the needed parameters. To put the card into the RFMON mode, change the top Mode: ESS line to Mode: yna (any) bss rfmon; this will take care of the ESSID, too. Changing the transmission power to the minimal 1 mW value is also a good idea, so change XmitPower: 100 to XmitPower: 1. You can also echo to the configuration file from your console; for example:

arhontus:~# echo "Mode: rfmon" > /proc/driver/aironet/eth1/Config

or

arhontus:# echo "Mode: r" > /proc/driver/aironet/eth1/Config

arhontus:# echo "Mode: y" > /proc/driver/aironet/eth1/Config

then

arhontus:# echo "XmitPower: 1" > /proc/driver/aironet/eth1/Config

If you run iwconfig you can see that with the Cisco Aironet cards there are two wireless interfaces instead of the usual one:

eth1 IEEE 802.11-DS ESSID:"Arhont-X"

 Mode:Managed Frequency:2.412GHz Access Point: 00:02:2D:4E:EA:0D

 Bit Rate:11Mb/s Tx-Power=0 dBm Sensitivity=0/65535

 Retry limit:16 RTS thr:off Fragment thr:off

 Encryption key:off

 Power Management:off

 Link Quality:59/10 Signal level:-90 dBm Noise level:-256 dBm

 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0

 Tx excessive retries:0 Invalid misc:58 Missed beacon:6



wifi0 IEEE 802.11-DS ESSID:"Arh0not-X"

 Mode:Managed Frequency:2.412GHz Access Point: 00:02:2D:4E:EA:0D

 Bit Rate:11Mb/s Tx-Power=0 dBm Sensitivity=0/65535

 Retry limit:16 RTS thr:off Fragment thr:off

 Encryption key:off

 Power Management:off

 Link Quality:59/10 Signal level:-90 dBm Noise level:-256 dBm

 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0

 Tx excessive retries:0 Invalid misc:58 Missed beacon:6

The wifiX interface is used to direct the captured traffic in RFMON mode, not the ethX. This is important to remember when running your sniffer. When you switch from the monitoring mode to association with the network, we recommend you restart the pcmcia-cs services. Then you will have to use iwconfig or the Cisco-supplied ACU GUI to set all necessary parameters and associate. The ACU is highly intuitive (Figure 4-6) and has excellent status and statistic reporting interfaces (Figures 4-7 and 4-8). As such, it can be used as a good site surveying tool.

Figure 4.6. ACU graphical interface to Cisco cards.

[View full size image]

Configuring Wireless Client Cards on BSD Systems

The configuration utilities that remain to be covered are ifconfig, wicontrol, and ancontrol on BSD operational systems. The manual pages for these utilities are included in Appendix D and there is not a lot we can add to them. Of course, you are interested in setting your card into a monitor mode. If you have a Prism chipset card, you cannot put it into the monitor mode with ifconfig (FreeBSD) or wicontrol. Instead use the prism2ctl tool from BSD-airtools:

arhontus:~# prism2ctl wi0 -m

If the card is Cisco Aironet and you use FreeBSD 5.0 or later, an supports the monitor mode with the -M switch:

arhontus:~# ancontrol -i <interface> -M 0-15

Set monitor mode via bit mask, meaning:

• 0 to not dump 802.11 packet.

• 1 to enable 802.11 monitor.

• 2 to monitor any SSID.

• 4 to not skip beacons, monitor beacons produces a high system load.

• 8 to enable full Aironet header returned via BPF.

Note: it appears that an SSID must be set.

It is worth mentioning that with older versions of Ethereal, bit mask 8 might be necessary. This is an example of setting a Cisco Aironet card into the monitor mode:

arhontus:~# ancontrol -i wi0 -M 1 -p 1

where -p 1 sets the transmitting power to 1 mW (battery life preservation).

If you are very conservative and use older BSD versions, you'll have to apply the an.rfmon patch (see http://www.ambrisko.com/doug/an/old/) to implement the -M switch.