Kismet

Many people complain that configuring Kismet in Linux is difficult. Actually, configuring Kismet is easy. The problem is that configuring your wireless card in Linux used to be very difficult. Nowadays driver support has gotten much better, and if you are using a reasonable card, then enabling monitor mode is a simple iwconfig command away.

This section assumes you already have your wireless card working and that it supports monitor mode. The easiest way to verify this is to type the following:

[root@phoenix:~]$ iwconfig
eth0       no wireless extensions.
lo         no wireless extensions.
ath0      IEEE 802.11  ESSID:""
          Mode:Managed  Frequency:2.412 GHz  Access Point:
00:00:00:00:00:00
              . . .

If you see something similar to ath0, you have a working wireless card. If you don't, you might need to load a driver (modprobe ath-pci, for example) or compile support for your card into the kernel. Assuming you have a working wireless interface, you can verify the driver supports monitor mode by issuing the following command:

[root@phoenix:/home/johnycsh]$ iwconfig ath0 mode monitor

No error messages means it worked.

A Better Way to Enable Monitor Mode? (airmon.sh)

Though the simple iwconfig command will work on most drivers, some do not support the Linux wireless extensions' API. Others only support them partially. The most prominent driver in this boat is the wlan-ng driver. Also, some drivers that support prism headers require you to enable them explicitly. All this boils down to the fact that different cards might need different commands to get them into the best state for war driving (monitor mode plus prism headers). Fortunately, there is a script called airmon.sh included with aircrack that keeps track of all the idiosyncrasies of specific drivers and lets you forget about the details. An example of using it to set an Atheros card to monitor channel 11 is shown here:

[root@phoenix:/home/johnycsh]$ /usr/local/bin/airmon.sh start ath0 11
usage: /usr/local/bin/airmon.sh <start|stop> <interface> [channel]
Interface       Chipset         Driver
ath0            Atheros         madwifi (monitor mode enabled)

By using this script bundled with aircrack, you can avoid having to remember quirky commands for each driver.

Configuring Kismet

Assuming you have a working wireless card, configuring Kismet is easy. You need to change only two lines of the config file to get it running. The config file is /usr/local/ etc/kismet.conf by default. The first line you need to change is the suiduser; set this to your usual non-root user. You'll also need to change the source line. This line tells Kismet what type of card to use and what interface it's on. A common example is shown here:

[root@phoenix:/home/johnycsh]$ vi /usr/local/etc/kismet.conf
# User to setid to (should be your normal user)
suiduser=johnycsh


# Sources are defined as:
# source=sourcetype,interface,name[,initialchannel]
# Source types and required drivers are listed in the README under the
# CAPTURE SOURCES section.
# The initial channel is optional, if hopping is not enabled it can be used
# to set the channel the interface listens on.
# YOU MUST CHANGE THIS TO BE THE SOURCE YOU WANT TO USE
source=madwifi_g,ath0,MyAtheros

In this example, Kismet has been configured to switch users down to johnycsh (my normal user account) once it has started. I told it to use the interface ath0 with a madwifi_g source type because I have an Atheros-based b/g card plugged in using the MadWifi driver.

Once you have made these changes, you should be able to launch Kismet. You might think you should do this as the suiduser listed in the config file. However, Kismet needs to start out with root privileges to configure your wireless card correctly. Therefore, you need to start Kismet as root, in a directory that your suiduser can write files to.

[johnycsh@phoenix:~]$ mkdir Kismetdumps
[johnycsh@phoenix:~]$ cd Kismetdumps/
[johnycsh@phoenix:~/Kismetdumps]$ su
Password:
[root@phoenix:/home/johnycsh/Kismetdumps]$ kismet

At this point, Kismet will start up as root, initialize your wireless card, drop privileges to your suid user, and start creating files in the directory Kismetdumps, which is owned by your suiduser.

Configuring GPS for Kismet

Kismet relies on another program named GPSD to talk to your GPS hardware. GPSD connects to your GPS device across a serial port and makes the data available to any program that wants it via a TCP connection (port 2947 by default). GPSD comes with many distributions, and it is easy to install. Once installed, you just need to pass it the correct arguments to talk to your hardware. The two most common scenarios are a USB-to-serial converter or a serial-based device speaking NMEA.

To use a USB-to-serial converter, you should start GPSD with a command similar to this one:

[root@phoenix:/home/johnycsh]$ gpsd  /dev/ttyUSB0

To use a plain-old serial port, you should help out GPSD by specifying the speed on the command line:

[root@phoenix:/home/johnycsh]$ gpsd -s 4800  /dev/ttyS0

If you have any trouble getting GPSD to work, it supports useful debugging flags -D (debug) and -N (no background). For example, typing gpsd -D 1 -N /dev/ttyUSB0 will allow you to see what's going on in real-time. You can connect to the GPSD TCP port by using telnet or netcat. The following command connects to GPSD and verifies a working connection:

[root@phoenix:/home/johnycsh]$ nc localhost 2947
r
GPSD,R=1

$GPRMC,194328,A,3636.0066,N,12152.1101,W,0.0,0.0,200406,14.8,E,A*35
$GPRMB,A,,,,,,,,,,,,A,A*0B
$GPGGA,194328,3636.0066,N,12152.1101,W,1,06,1.8,-0.2,M,-29.6,M,,*51

The r command tells GPSD to forward you the raw NMEA output.

Once you have GPSD running, you may need to make a small change to kismet .conf. Make sure the GPS key/value pair is set to true. The default gpshost should be fine.

[root@phoenix:/home/johnycsh]$ vim /usr/local/etc/kismet.conf
# Do we have a GPS?
gps=true
# Host:port that GPSD is running on.  This can be localhost OR remote!
gpshost=localhost:2947

Running Kismet

Now that you've configured Kismet for your laptop, it is time to begin. Remember, start Kismet as root inside a directory your suiduser can write to. Assuming all goes well, you will be greeted with a screen that looks like the one shown in Figure 5-9.

Figure 5-9: Kismet in action

Kismet has a surprisingly rich and well-documented interface. For example, pressing C will give you the client list for the currently selected network, R will show the current packet rate, and L will give you the current SNR for the wireless card. This is only a small sample of the integrated features in Kismet. The best way to find them is to read the documentation, or just press keys until something interesting happens.

Kismet-Generated Files

By default, Kismet will generate the following six files in the directory you started it from:

• .csv Comma-separated values. Contains a useful summary of the networks you saw on your war drive. Information includes the name, BSSID, location, and encryption type. This file is fairly analogous to the NetStumbler summary format. StumbVerter can use this information to generate a map.

• .xml Contains a similar set of data as the .csv file, except in Kismet's XML format.

• .network Contains the same set of data as the .csv file, but formatted for easy human perusal.

• .gps Contains all the GPS info from the war drive.

• .cisco Contains information pertaining to Cisco's discovery protocol (CDP). This file is only left if Kismet actually sees some CDP traffic.

• .weak Contains all of the weak IVs that Kismet saw. This file can be used as input to airsnort.

• .dump Contains all the packets Kismet sees in the typical pcap file format.

Mapping with Kismet

Kismet comes with a utility named gpsmap that can be used to convert the .gps files it creates into maps. Unfortunately, it takes a dizzying number of flags on the command line to get the map to look good, and it's also somewhat prone to crashing. The easiest way to generate a map from Kismet data is to use NetStumbler and import a Kismet .csv file.

One interesting feature that Kismet supports is GpsDrive integration. GpsDrive is a stand-alone application that can draw your location on top of images downloaded from map servers in real-time. GpsDrive supports Kismet integration in recent releases and makes it easy to see your position as well as the APs you discover in real-time. Starting with version 2.04, GpsDrive will actually connect to the Kismet server automatically, and you no longer need GpsDrive to generate a text file with waypoints in it just for GpsDrive to read.

To get GpsDrive working with Kismet requires MySQL. Compiling, installing, and configuring MySQL is outside the scope of this book. Assuming you have a typical MySQL install, however, the following should get Kismet and GpsDrive working together:

[root@phoenix:~]# /etc/init.d/mysql start
 * Starting mysqld (/etc/mysql/my.cnf) ...      [ ok ]
 [root@phoenix:~]# mysql -u root < /usr/share/GpsDrive/create.sql

The first command starts MySQL and the second command creates the required tables and MySQL user named gast. Note that you create the tables only once. You will need to run MySQL every time you want GpsDrive and Kismet to interoperate.

Once that's done, you simply launch GPSD, then Kismet, and then launch GpsDrive:

[root@phoenix:/home/johnycsh/Dumps]# gpsd /dev/ttyUSB0
[root@phoenix:/home/johnycsh/Dumps]# kismet
[johnycsh@phoenix:/home/johnycsh/Dumps]$ gpsdrive

If everything went correctly, you will be greeted with a screen that looks similar to the one in Figure 5-10. If you don't see any APs, be sure to check the Use SQL box in the left column.

Figure 5-10: GpsDrive is successfully communicating with Kismet.

Other Kismet Features

Kismet supports quite a few advanced features. Part of this is due to Kismet's client-server architecture, which allows it to be very extensible. For example, if you don't like the text-based interface you see by default, check out gkismet-a gtk-based client that talks to the Kismet server. One very useful feature built in to Kismet is the ability to use more than one card intelligently (e.g., get the most channel coverage possible). Kismet can also be used as a cheap wireless IDS. A good place to start looking to see what other things Kismet can do is in the included README or the kismet.conf file.