KISMET 3.0.1
Mike Kershaw <dragorn@kismetwireless.net>
http://www.kismetwireless.net
Licensed under the GPL
- What is Kismet
- Features
- Quick Start
- Upgrading
- Supported Operating Systems
- Linux
- Linux-ARM
- BSD
- Win32 (Cygwin)
- MacOS X
- Supported Card Types
- cisco
- prism2
- orinoco
- wsp100
- wtapfile
- pcapfile
- ar5k
- drone
- airport (viha)
- acx100
- GPS Support
- Compiling
- Configuration
- Panels Interface
- Mapping
- Drone Remotes
- Intrusion Detection
- WHAT IS KISMET
Kismet is a 802.11 wireless network sniffer - this is different from a normal network
sniffer (such as Ethereal or tcpdump) because it separates and identifies different
wireless networks in the area. Kismet works with any 802.11b wireless card which is capable of
reporting raw packets (rfmon support), which include any prism2 based card (Linksys,
D-Link, Rangelan, etc), Cisco Aironet cards, and Orinoco based cards. Kismet also
supports the WSP100 remote sensor by Network Chemistry, and is able to sniff 802.11a
networks using ar5k cards.
- FEATURES
- Configurable channel hopping
- IP range detection
- Cisco product detection via CDP
- Ethereal/tcpdump compatable file logging
- Airsnort-compatable "interesting" (cryptographically weak) logging
- Hidden SSID decloaking
- Grouping and custom naming of networks
- Multiple clients viewing a single capture stream
- Graphical mapping of data (gpsmap)
- Cross-platform support (handheld linux and BSD)
- Manufacturer and model identification
- Detection of default access point configurations
- Detection of Netstumbler and Wellenreiter clients
- Runtime decoding of WEP packets
- Multiplexing of multiple capture sources
- 802.11b and 802.11a sniffing abilities
- Data export for external layer3 IDS (such as Snort)
- Distributed 'Drone' sniffing
- QUICK START
Detailed information about each of these steps can be found in the appropriate section
of the documentation.
- Compile Kismet (./configure, make dep, make)
- Install Kismet (make install). By default, Kismet installs without suid-root ability. This requires
you to start Kismet as root so that it can enable monitor mode and control channels. Kismet CAN be
installed as suid-root (make suidinstall) which allows you to start it as a normal user, HOWEVER this
will allow any user on your system to stop the wireless connection. Do NOT install Kismet suid-root
if you have untrusted users on your system.
- Configure kismet.conf and kismet_ui.conf for your card and setup. Make sure to put a valid, non-root
user as the 'suiduser' option. This user is the account kismet will run as once it has attached to the capture
source. Most users will want to also edit the "logtemplate" field and put an absolute path to a directory
that the suiduser has write permission to.
- Run 'kismet' as root (if installed normally) or simply run 'kismet' as any user if you installed it suid-root.
Kismet will place the specified cards into rfmonitor mode and begin.
- UPGRADING
Upgrading to 2.9-devel and beyond
Kismet-devel revamps major parts of Kismet. There is a new alert system, and the hopper and monitor scripts
have been absorbed into Kismet itself and no longer need to be started seperately. All users will need to
read the documentation for how to install Kismet as a normal or a suid binary, and all users will need to
upgrade to the new config files for alerts, hopping, etc to work correctly.
Upgrading to 2.8
Kismet 2.8 adds support for several features, which necessitate changing the configure file.
All users should install Kismet with 'make forceinstall' and reconfigure it accordingly.
New options include runtime WEP decoding, multiple sources, multiple servers under one client,
and many more new features.
- SUPPORTED OPERATING SYSTEMS
- Linux
Kismet was developed primarily on Linux, and should work on any distribution.
Kismet should compile with gcc 2.95.x and gcc 3.2.
Kismet is endian-clean and should compile on little (intel) and big (powerpc)
endian systems. It also works on ARM-based systems (Ipaq and Zaurus) and
SH3 (Jornada) handhelds.
- Linux-ARM
Zaurus Installation
Nearly all CF form-factor wireless cards are Prism/2 based. As of this writing,
the version of wlan-ng shipped with the Zaurus only supports the 'prism2' card
type. A seperate package is provided with pcap support for OpenZaurus installs,
which use HostAP and the prism_hostap card type.
Ipaq Installation
Depending on the version of the Familiar distribution installed on your Ipaq,
the version of the wlan-ng drivers may not support sniffing. If you get errors
that enabling monitor mode is not supported, you'll need to update your
Familiar install or compile them yourself in a cross-build environment.
As of Familiar 0.5.3, Lucent/Orinoco cards do not support RFMON (PF_PACKET) and
as such, cannot be used with Kismet without patching. As of 8/28/02, Jamey
Hicks who maintains the Familiar distribution promises future releases of
Familiar will include Snax's patch for the orinoco_cs drivers.
Familiar users with Cisco cards will need to set their kismet.conf file to use
a cardtype of "cisco_cvs", with a capinterface of "ethX:wifiX".
Some Familiar installs also do not include the latest ncurses and panels
libraries - these can be obtained from the Skif cluster (telnet to
ipaq3.handhelds.org and copy the /lib/libpanel.so.5 and /lib/libncurses.so.5.0
files to your ipaq). You may also need to install the GNU stdc++ libraries
by running "ipkg install libstdc++2.01-glibc2.2".
Configure your card just as you would on an intel system - with the PCMCIA
sleeve, all the standard cards function and must be configured as they
would be on any other system.
Compiling it yourself
Pass the appropriate cross-build to configure, I use
'./configure --host=arm-linux --disable-pcap --enable-zaurus --disable-setuid'
to build for the Zaurus, and
'ac_cv_linux_vers=2.4.16 ./configure --host=arm-linux --with-pcap=linux
--disable-setuid'
to build for the iPaq. Set ac_cv_linux_vers accordingly to match your system.
Some versions of GCC appear to generate incorrect alignments when optimization
is turned on. If you experience bus errors under arm, try removing the -O2
from the CXXFLAGS in the Makefile and recompiling.
I used the Zaurus cross-build environment from
http://www.lart.tudelft.nl/lartware/compile-tools/
and the Skif cluster environment for Ipaq.
- BSD
Kismet should configure and compile cleanly on *BSD.
Due to problems with the wireless drivers in FreeBSD and NetBSD, Kismet may not perform
well or at all. Thanks to the efforts of Pedro la Peu, Kismet WILL function
without problems on OpenBSD 3.2 with prism/2 cards.
The lions share of drivers supporting rfmon are available only for Linux, so
for general use, using Linux to run Kismet is highly reccomended. Some driver maintainers
for the BSD variants have expressed no interest in providing support for monitoring tools,
so it is unknown when useful drivers for rfmon will be available.
The standard './configure' script should detect your OS and configure itself
accordingly. It is vital that you use 'gmake' instead of 'make' to
compile however -- most *BSD make's do NOT like the GNU makefile format very
much.
I'm definitely NOT a BSD expert. If you experience problems, probably the best
course to take is to report them to the mailing list
(wireless@kismetwireless.net).
- Win32 (Cygwin)
The Kismet panels frontend will compile and run under Cygwin on win32.
The Kismet server will work under cygwin with the wsp100 source or the drone remote
source. No other sources can currently be used because no publicly available
drivers for win32 can support rfmon.
To compile Kismet under win32, use:
./configure --disable-pcap --without-ethereal --disable-gps --disable-wireless
--disable-netlink --disable-suid-root --enable-wsp100
- MacOS X
Kismet will work with Airport (but not Airport Extreme due to a lack of drivers) under MacOS X.
To compile Kismet under OSX, download the Viha drivers (http://www.dopesquad.net/security/) and
install them, then run configure and compile as normal.
Kismet should operate normally inside OSX.
- SUPPORTED CARD TYPES
- CISCO
Cards: Aironet 340, Aironet 350
Notes: Cisco cards use an internal firmware channel hopper. kismet_hopper is not
needed, and with all current drivers, user-controlled channel hopping is not possible.
- 'cisco': Linux kernel 2.4.10 through 2.4.19
Capture interface: ethX
Notes: Built-in Linux kernel drivers for the aironet cards (airo and airo_cs). These
are, currently, the most reliable drivers to use.
- 'cisco_cvs': Linux kernel 2.4.20, sourceforge.net CVS driver release
Capture interface: ethX:wifiX
Notes: The new drivers use the interface ethX for normal operation and wifiX for
raw packet capturing. The interface for Kismet should be set to wifiX. These drivers
have a history of locking up under high loads and when entering/leaving rfmon mode.
- 'cisco_bsd': BSD 'an' drivers
Capture interface: anX
Notes: The 'an' drivers do not report the linktype or packets reliably under most
BSD versions. Performance may be varied.
- PRISM/2
Cards: Prism/2 based PCMCIA, PCI, PLX, Compact Flash, and USB cards by a variety of
manufacturers, including Linksys, D-Link, Zoom, Demarctech, Microsoft, and many others.
Notes: Prism/2 users should use kismet_hopper to channel hop. WARNING: The 22mbit
cards made by manufacturers such as D-Link (labeled as 650+ among others) are NOT
Prism/2 based. They use a proprietary TI chipset, which is currently NOT supported by
any drivers in Linux or BSD, and cannot be used. Additionally, recent PCI cards by
Linksys and others use a Broadcom chipset instead of Prism/2, which is not supported.
- 'prism2': Wlan-ng 0.1.14 and higher.
Capture interface: wlanX
Notes: Recent wlan-ng development drivers report PHY (physical layer) packets
such as data-ack and request-to-send. Logging of these can be controlled with
the 'phylog' option.
- 'prism2_avs': Wlan-ng 0.2.0 and higher.
Capture interface: wlanX
Notes: Wlan-ng 0.2.0 introduces a new capture header with MUCH more information
from the radio. Kismet doesn't entirely take advantage of these new headers
yet, but wherever possible, use the prism2_avs capture source. As Wlan-ng 0.2.0+
becomes more widely adopted, prism2_avs will become the default prism2 behavior.
- 'prism2_legacy': Legacy wlan-ng drivers (0.1.13 and earlier)
Capture interface: wlanX
Notes: All users able to do so should upgrade their wlan-ng drivers to a newer
version. For those forced to use the older drivers, prism2_legacy uses the
linux-netlink-socket capture interface.
- 'prism2_hostap': hostap
Capture interface: wlanX
Notes: The hostap drivers appear to frequently change the commands used to
place them into monitor mode. When in doubt, consult the hostap documentation.
- 'prism2_bsd': BSD Prism/2 drivers
Notes: OpenBSD 3.2 has Prism/2 drivers which correctly report the link type and
packets. Other BSD versions have, at best, mixed results.
- ORINOCO
Cards: Lucent orinoco based cards such as the WaveLAN series and by some reports Airport.
Notes: Apple Airport cards are reported to also work with these drivers with some
effort. kismet_hopper handles channel hopping. Currently, no BSD drivers exist which
are capable of doing rfmon mode.
- 'orinoco': Patched Linux orinoco drivers
Capture interface: ethX
Notes: Drivers must be patched with the rfmon patches at http://airsnort.shmoo.com.
Unpatched drivers will not work in rfmon mode.
- WSP100
Device: WSP100 Remote Sniffer from Network Chemistry
Notes: The WSP100 remote sensor is a SNMP-controlled embedded device that
reports packets via a UDP stream. This should work on ANY platform including Win32 (cygwin),
Max OS X, Linux, BSD, and anywhere else you can get Kismet to compile. kismet_hopper will
configure the wsp100 firmware for internal channel hopping.
- 'wsp100': Kismet UDP handler
Capture interface: host:port
Notes: The capture interface specifies the address of the wsp100 unit and the port
to send the UDP packet stream to.
- WTAPFILE
Notes: The wtapfile replay ability is primarily useful for debugging, however it can also
be used to recreate csv/xml/etc files from a saved dump. Libwiretap has support for more
esoteric dumps (which is faily irrelevant) and transparent support for compressed dumpfiles,
but requires a compiled source tree of ethereal.
- 'wtapfile': Kismet wtapfile handler
Capture interface: file
Notes: The capture interface specifies the path to the dump file. Dumps can be
in any format wtaplib understands, which includes files created by Kismet, Ethereal,
TCPdump, and others. Files can be gzip compressed.
- PCAPFILE
Notes: The pcapfile replay is similar to wtapfile but uses libpcap instead of libwiretap.
- 'pcapfile': Kismet pcapfile handler
Capture interface: file
Notes: The capture interface specifies the path to the dump file. Dumps can be any
format libpcap understands, and should have a rfmon wireless encoding.
- AR5K
Notes: 802.11a doesn't put the channel in the beacon headers.
- 'ar5k': vt_ar5k Linux 802.11a drivers
Capture interface: wlanX
Notes: The vt_ar5k drivers require the Linux wireless-tools version 25 or
higher. Older versions will not be able to put the cards into monitor mode.
- DRONE REMOTE
Notes: The packets sent by Kismet drones may be filtered by the drone itself for
content (physical, beacon, etc.).
- 'drone': Kismet Drone remote
Capture interface: host:port
Notes: The capture interface specifies the address of the Kismet drone server and
the port on that server which provides packets.
- AIRPORT (VIHA)
Cards: Airport cards under OSX using the Viha drivers
Notes: Viha only works with the Airport cards, not the Airport Extreme cards. Lowlevel
PHY reporting is available.
- 'viha': OSX Viha drivers
Capture interface: enX
Notes: Drivers available from http://www.dopesquad.net/security/. Current Kismet support
is for Viha 0.0.1a, but it MAY work with newer versions. Normal OSX drivers will not work in
RFMon mode.
- ACX100 (TI 22MBIT)
Cards: 22mbit 802.11b+ cards such as the Dlink 650+
- 'acx100': ACX100 OSS drivers
Capture interface: wlanX
Notes: Drivers available from http://acx100.sourceforge.net.
- GPS SUPPORT
GPS support is provided via the GPSD daemon, available at http://russnelson.com/gpsd/.
GPSD is also included with the navigation software GPSDrive. Current versions of GPSDrive
distribute a GPSD which will work with Kismet, however earlier versions (1.17 and earlier)
did not.
GPSD provides network accessable GPS data from a wide variety of GPS recievers, including
Garmin, Magellan, and more. Kismet can use a GPSD running on the local server or on a
remote host (assuming that there is a wired connection to that host).
Kismet will write an XML logfile of the travel path taken and the packets seen. The
gpsmap program that comes with Kismet will plot these files to a graphical map.
Some systems have trouble compiling GPSD. The easiest fix is to edit
em.c and change "#include <sys/time.h>" to "#include <time.h>".
- COMPILING & INSTALLATION
Before configuration and compilation, you should get the following packages:
-
ethereal (www.ethereal.com). This is a GREAT sniffer and capture reader,
and will be invaluable to you for processing dump files. Kismet will also
use Ethereal's wiretap packet library for dumping and reading dumpfiles
if it is available.
-
gpsdrive (http://www.kraftvoll.at/software/). This program does
real-time street mapping and other useful GPS things, and includes gpsd,
the daemon Kismet interfaces to for GPS support. Alternatively, you can get
just the daemon from http://russnelson.com/gpsd/. This is NOT required for
compilation but you need the gpsd daemon running for GPS logging when you
go to run Kismet. New versions of GPSdrive will interface directly with Kismet
and plot access points realtime. See the GPSDrive documentation for more details.
-
Run the ./configure script. This will find as much as possible about
your system. Most configuration options are autodetected, you should only
need to override them for custom compilations if you are attempting to save
space (such as for a handheld). Useful configuration options include:
--disable-curses disable curses UI
--disable-panel disable ncurses panel extentions
--disable-gps disable GPS support
--disable-netlink disable linux netlink socket capture (prism2/orinoco
patched)
--disable-wireless disable linux kernel wireless extentions
--disable-pcap disable libpcap capture support
--enable-syspcap use system libpcap (not reccomended)
--disable-setuid disable suid capabilities (not reccomended)
--enable-wsp100 enable WSP100 remote sensor capture device
--enable-zaurus enable some extra stuff (like piezzo buzzer) for
Zaurus
--enable-local-dumper force use of local dumper code even if ethereal is
present
--with-ethereal=DIR support ethereal wiretap for logs
--without-ethereal disable support for ethereal wiretap
--enable-acpi Enable linux-kernel ACPI support
- Run 'make dep' and 'make install'
- Edit kismet.conf (default install path, /usr/local/etc/kismet.conf) to set your
logging type and preferences.
- Edit kismet_ui.conf (default install path, /usr/local/etc/kismet_ui.conf) to set
your interface preferences.
Unless you specify --disable-setuid, Kismet will be installed as suid-root.
Immediately after binding to the capture source, it will drop root privileges
and run as the user specified in the config file. This suid behavior will
occur when kismet is run as root or as the user specified in the config file.
It is reccomended that you do NOT disable this capability, as Kismet is
handling potentially hostile foreign data and should not have elevated rights
to the system.
- CONFIGURATION
Kismet is controlled by 2 system-wide config files (by default, in /usr/local/etc/). These
files use a simple option=value format.
- kismet.conf
kismet.conf controls the behavior of the server itself, including capture sources,
logging, GPS support, etc. All of the options are documented inside the file, as well
as in the man page kismet.conf(5).
- Configuring capture sources
Kismet capture sources define the type of device and the interface that Kismet will
listen for packets on. Most systems will only have one capture source, but Kismet can
support any number of simultaneous captures. The data captured from multiple interfaces
will be multiplexed to a single dump file. Sources can be passed on the command line,
but are primarily controlled by 'source' lines in kismet.conf.
Each source line consists of the type, interface, and name, separated by commas.
source=cisco,eth0,Cisco
defines a cisco card on interface eth0 named 'Cisco',
source=prism2,wlan0,Prism
defines a prism2 card using the wlan-ng drivers on interface wlan0 named 'Prism'.
If multiple sources are defined, all will be enabled by default, unless an "enablesources"
option is given.
- Configuring fuzzy encryption
Not all capture sources report the WEP flags on incoming packets correctly. Fuzzy
encryption detection attempts to classify packets by matching known LLC types and treating
unknown packets as encrypted.
Don't use fuzzy encryption unless your drivers report encrpyted packets as unencrypted.
- Filtering packet logs
What packets are logged to the dump file can be filtered using the 'noiselog', 'beaconlog',
and 'phylog' options in kismet.conf.
Disabling noise logging discards any packets classified as noise - spurious packets from
some drivers, packets which are too short to contain the data they claim, etc.
Disabling beacon logging discards all but one beacon packet per network seen. Additional
beacon packets may be logged if the advertised SSID changes.
Disabling phy logging discards physical layer packets such as data acks which some drivers
report.
- Decrypting wep on-the-fly
Kismet supports decrypting WEP as packets are captured. This enables Kismet to extract
clients, IP ranges, and alert conditions out of WEP-enabled traffic. WEP keys are set
via the "wepkey" option. Multiple wepkey options can be set to decrypt different networks.
Each wepkey line should be the bssid and the hex key, for example:
wepkey=00:FE:ED:BE:EF:00,00:11:22:33:44
WEP keys can be 5 hex pairs (40-bit) or 13 hex pairs (128-bit)
- Using an external IDS
By configuring a FIFO named pipe (fifo="..." in kismet.conf), Kismet will create the
specified pipe and write the data packets to it. If a packet can be decrypted with a
known key, it will be modified and written as an unencrypted packet to the FIFO.
External IDS programs (such as Snort) should be instructed to read packets from a file
or pipe.
When writing packets to a FIFO pipe, Kismet will pause during the startup procedure until
an external utility opens the pipe for reading.
- kismet_ui.conf
kismet_ui.conf controls the behavior of the user interface - colors, columns, default
server, etc. All of the options are documented inside the file, as well as in
kismet_ui.conf(5).
- Changing columns
The informational columns the Kismet panels interface (default) uses can be changed by the
'columns' option for the main network display and the 'clientcolumns' option for the client
display in kismet_ui.conf. A complete list of columns is in the man page.
- Changing colors
Nearly all the elements of the Kismet interface can be changed via the kismet_ui.conf file
any the 'xxxcolor' options. The config file and the man page list all the possible colors
and configurable elements.
- PANELS INTERFACE
Kismet's primary user interface uses the curses extention library, panels. Other interfaces
i can be connected at will.
- Basics of the panels interface
The panels interface is divided into three primary panels:
- Network display view
The network display panel shows all the networks which have been discovered. This
list can be sorted and manipulated.
- Information view
The information panel shows the total number of packets, current packet rate,
amount of time the capture has been running, etc.
- Status view
The status panel scrolls information and status events. Alerts appear in this
panel, as well as in the alert popup.
In addition to these three primary panels, additional popup windows can be requested to
display detailed information about a network, overall statistics, rename a network group,
and a number of other operations.
- Interacting with Kismet
- 'e' - Open popup window of Kismet servers. This lets you simultaneously monitor
two or more Kismet servers on different hosts.
- 'z' - Zoom network display panel to full screen (or return it to normal size if
it is already zoomed)
- 'm' - Mute sound and speech if they are enabled (or unmute them if they were
previously silenced). You must have sound or speech enabled in your config to be
able to mute or unmute them.
- 't' - Tag (or untag) the current network
- 'g' - Group currently tagged networks
- 'u' - Ungroup current group
- 'c' - Open client popup window to display clients in the selected network
- 'n' - Rename selected network or group
- 'i' - Display detailed information about the current network or group
- 's' - Sort the network list differently
- 'l' - Show signal/power/noise levels if the card reports them
- 'd' - Instruct the server to start extracting printable strings from the packet
stream and display them.
- 'r' - Display bar graph of the packet rate.
- 'a' - Show statistics about packet counts and channel allocation.
- 'p' - Display packet types as they are recieved.
- 'f' - Follow the estimated center of a network and display a compass
- 'w' - Display all previous alerts and warnings.
A description of the current window and a list of what options are available can always
be requested by pressing 'h' (Help).
- Selecting a network
The default sort order for the display is designed to automatically reorder the networks
to display as many active networks as possible on the screen. When in autofit mode,
selecting an indifidual network is disabled. Use the sort function to sort networks
in a stable order.
If more columns of information are requested than can fit on the current screen, the
left and right arrow keys can be used to shift the columns.
- Network types
Tracked networks may be one of several types:
- P - Probe request - A client card searching for a network with no association
- A - Access point - standard wireless network
- H - Ad-hoc - point-to-point wireless network
- T - Turbocell - Turbocell (aka Karlnet and Lucent Outdoor Router)
- G - Group - Group of wireless networks
- D - Data - Data only network with no control packets.
- Network details
The details panel lists more information than can be displayed in the limited space
available for the list of all networks.
Group information:
- Name - Custom name (or ssid) of the network or group
- Networks - Number of networks in the group
- Min Loc - Minimum geographic location
- Max Loc - Maximum geographic location
- Range - Range of group
Network information:
- SSID - SSID of the network
- Server - Which Kismet server reported this network
- BSSID - BSSID
- Manuf - Manufacturer based on BSSID MAC
- Model - Hardware model, if a match was found
- Matched - Portion of the BSSID MAC used to match to manuf/model
- Max rate - Maximum data rate supported by this network
- First - Time of first packet seen for this network
- Latest - Time of latest packet seen for this network
- Clients - Number of client systems seen in this network
- Type - Network type
- Info - Optional informational field in some manufacturers beacon packets
- Channel - Channel network is operating on
- WEP - WEP encryption enabled on this network
- Beacon - Beacon rate
- Packets - Number of packets and types of packets seen.
- Data - Amount of data transfered through this network
- Signal - Current and best signal levels
- IP - Aggregate IP range detected for this network
- Min Loc - Minimum geographic location
- Max Loc - Maximum geographic location
- Range - Range of network
- Client types
Tracked clients may be one of several types:
- F - From DS - client broadcast from wireless distribution system
- T - To DS - client transmitted over the wireless to the distribution system
- I - Intra DS - client is a node of the distribution system talking to another node
in the distribution system
- E - Established - client has been seen entering and leaving the DS
- Client details
The client details panel lists more information than can be displayed in the limited space
available for the list of all networks.
- Type - Network type
- Server - Which Kismet server reported this client
- MAC - MAC address of the client
- Manuf - Manufacturer based on MAC
- Model - Hardware model, if a match was found
- Matched - Portion of the MAC used to match to manuf/model
- First - Time of first packet seen for this client
- Latest - Time of latest packet seen for this client
- Max rate - Maximum data rate supported by this client
- Channel - Channel client is operating on
- WEP - WEP encryption enabled on this client
- IP - Aggregate IP range detected for this client
- Min Loc - Minimum geographic location
- Max Loc - Maximum geographic location
- Range - Range of client
- Packets - Number of packets and types of packets seen.
- Data - Amount of data transfered through this network
- Signal - Current and best signal levels
- MAPPING
Gpsmap (which comes with Kismet) takes GPS and network data (.gps and .xml files, respectively)
and plots them graphically on vector, satellite, or user supplied maps.
Gpsmap supports several drawing methods:
- Track drawing
Draws a track along the traveled path, based on the saved track data.
- Bounding rectangle
Draws the bounding rectangle around the extreme points of each network.
- Range circle
Draws the estimated range of a network as a circle around the center point.
- Convex hull
Draws the convex hull of the network (smallest polygon which covers all network points)
- Scatter plot
Draws a point for every logged packet
- Center dot
Draws a point in the estimated center of each network
- Interpolated power
By far the most CPU intensive, power interpolation forms a grid over the image
and attempts to interpolate the power for points that aren't directly sampled.
For this graph to be a reasonable representation of reality, samples around
the entire area, preferably forming a grid or mesh, should be taken.
More information about gpsmap is available from the man page gpsmap(1).
- DRONE REMOTES
Kismet is also able to do distributed sniffing of a larger physical area by using
Drone remote sniffers. A Kismet drone is essentially a stripped down Kismet sniffer
engine which is able to capture data from all the same sources as Kismet itself (as well
supporting multiple simultaneous capture sources, mixture of 802.11a and 802.11b
sources, etc) and provide those packets over a TCP stream on a wired network.
Any number of drones with any number of sources can be distributed across the target
area, with all captured packets being processed by a single Kismet server, stored in a
common dump file and passed to a single Snort IDS instance, if desired.
- INTRUSION DETECTION
Kismet will examine the headers and payload information of 802.11 traffic,
and will generate alerts when it encounters traffic that matches defined
attack signatures. Kismet is unlike other traditional IDS's since it will
analyze traffic at the data-link level, instead of just examining properties
specific to the IP family of protocols. Kismet is also capable of anomaly
analysis over a defined period of time to detect attacks that cannot be
detected with simple per-packet matching patterns.
In addition to Kismets link-layer IDS, Kismet can interface with traditional
IDS implementations like Snort (www.snort.org) via a named pipe (See the
section about configuring Kismet to write to FIFO/Named pipes) to form a
complete IDS solution. Distributed sniffing via Drone Remotes and WEP
decoding of known networks lets you monitor your entire wireless coverage
area.
- NETSTUMBLER
Alert on: Netstumbler Probe
Alert message: "NetStumbler ($version) probe detected from $source"
References: www.netstumbler.com
Tool specific: Yes
Implemented in: NetStumber 3.22, 3.23, 3.30
Details: NetStumbler is a Windows program to perform active discovery of
WLAN networks through probe request scanning. After NetStumbler
locates a WLAN, it will probe the AP for "nickname" information.
This probe contains a specific payload that will cause Kismet to
generate an alert.
- DEAUTHFLOOD
Alert on: Deauthenticate/Disassociate Flood
Alert message: "Deauthenticate/Disassociate flood on $targetbssid"
References: 802.11ninja.net, http://home.jwu.edu/jwright/papers/l2-wlan-ids.pdf
Tool specific: No
Implemented in: AirJack, fata-jack, void11, others
Details: By sending deauthenticate or disassociate message to clients or
a layer 2 broadcast address with a spoofed source address of the
legitimate AP, an attacker can launch a DoS attack against a
target network. This type of attack only lasts as long as the
attacker sustains the deauthenticate flood.
- LUCENTTEST
Alert on: Lucent link test
Alert message: "Lucent Link Test detected from $clientmac"
References: http://www.agere.com/wlan/customercare/ (requires login)
Tool specific: Yes
Implemented in: Lucent/Orinoco WaveManager site survey software
Details: Lucent/Orinoco/Agere/Proxim provides site survey software with
their AP's. This rule will generate an alert when this
software is in use.
- WELLENREITER
Alert on: Wellenreiter SSID brute force
Alert message: "Wellenreiter probe detected from $clientmac"
References: http://home.jwu.edu/jwright/papers/l2-wlan-ids.pdf
http://home.jwu.edu/jwright/papers/wlan-mac-spoof.pdf
Tool specific: Yes
Implemented in: Wellenreiter 1.6, Wellenreiter 1.5
Details: Wellenreiter has an option to brute-force the ESSID of a
discovered access point by attempting multiple associations
from a list of potential SSID's. Between each association
attempt, Wellenreiter will reset the card ESSID to
"this_is_used_for_wellenreiter". Kismet will raise this alert
when the SSID "this_is_used_for_wellenreiter" is detected.
- CHANCHANGE
Alert on: Known BSSID changing channel
Alert message: "Beacon on $bssid ($ssid) for channel $newchannel, previously detected on channel $oldchannel"
Tool specific: No
Implemented in: AirJack, others
Details: Many attacks attempt to divert clients from a legitimate network to another
channel. This alert is raised when a beacon is seen for a different channel
than the one the network was previously communicating on.
- BCASTDISCON
Alert on: Broadcast disassociation or deauthentication packets
Alert message: "Broadcast [disassociation|deauthentication] on $bssid"
Tool specific: No
Implemented in: AirJack, fata-jack, void11, others
Details: Many attacks use a broadcast disassociate or deauthenticate packet to
knock all of the users off a network. This can be a prolonged into a sustained
DOS attack, used to decloak a hidden SSID, or be the precursor of a man in the
middle attacks. Broadcast disassociations are rarely, if ever, legitimate.
This alert is raised whenever a broadcast disassociation is seen.
- AIRJACKSSID
Alert on: Beacon for SSID "airjack"
Alert message: "Beacon for SSID 'airjack' from $sourcemac"
Tool specific: Yes
Implemented in: AirJack
Details: The defcon/blackhat AirJack test code sets the card to beacon as the SSID "airjack" while performing
other attacks. This alert is raised whenever a beacon packet for the SSID "airjack" is seen.
- PROBENOJOIN
Alert on: Clients seen probing and receiving acknowledgements but not participating in a network.
Alert message: "Suspicious client $sourcemac - probing networks but never joining."
Tool specific: No
Implemented in: NetStumbler, other active-probe scanners.
Details: Clients which probe continually for networks, are accepted, and never participate are likely to be
stumbler clients looking for networks. There is a chance of false positives with this detection method, but
it can be effective when watching for stumblers.
- DISASSOCTRAFFIC
Alert on: Traffic from a given source within 10 seconds of a disassociate or deauthenticate.
Alert message: "Suspicious traffic on $sourcemac: Data traffic within 10 seconds of disassociate."
Tool specific: No
Implemented in: "802.11 Denial-of-Service Attacks: Real Vulnerabilities and Practical Solutions" research paper.
Details: As discussed in the above research paper by Bellardo, J. and Savage, S., a host which legitimately
disassociates or deauthenticates from a network should not be exchanging data immediately thereafter. Any
client which DOES exchange data within 10 seconds of disassociating from the network should be considered a likely
victim of a disassociate attack.
- NOPROBERESP
Alert on: Probe response packet with no ssid or ssid field length 0.
Alert message: "Probe response with 0-length SSID detected from $sourcemac"
Tool specific: No
Implemented in: PoC code, Georgia Institute of Tech reseach paper
Details: Many firmwares (prism2, prism2.5, orinoco, airport) will crash when expecting and receiving a probe
response packet with the SSID tagged parameter length set to 0.