Documentation
top
Kismet Readme
Kismet 2010-07-R1
Mike Kershaw
http://www.kismetwireless.net
1. What is Kismet
2. Upgrading from earlier versions
3. Quick start
4. Suidroot & security
5. Capture sources
6. Caveats & quirks for specific drivers
7. Supported capture sources
8. Plugins
9. GPS
10. Logging
11. Filtering
12. Alerts & IDS
13. Server configuration options
14. Kismet UI
15. Kismet drones
16. Talking to Kismet
17. Troubleshooting
18. Frequently asked questions
1. What is Kismet
This release marks a MAJOR change in how Kismet works and is configured.
While many aspects are similar, many others (the client, configuring
sources and channels, etc) are very different.
Most notably:
* Sources are defined differently. See the "Capture Sources" section.
* All UI configuration is handled inside the Kismet client and stored
in the users home directory in ~/.kismet/kismet_ui.conf
* Most situations which were previously fatal conditions which caused
Kismet to exit can now be recovered from.
* New filtering options
* New alert options
* Completely new UI
* Revamped network protocol
* Significantly less CPU used for high numbers of networks
* Plugins
3. Quick start
PLEASE read the full manual, but for the impatient, here is the BARE
MINIMUM needed to get Kismet working:
* Run "kismet". If you did not install Kismet with suid-root support,
you need to start it as root in nearly all situations. This is not
recommended as it is less secure than privsep mode, where packet
processing is segregated from admin rights.
* When prompted to start the Kismet server, choose "Yes"
* When prompted to add a capture interface, add your wireless interface.
In nearly all cases, Kismet will autodetect the device type and
supported channels. If it does not, you will have to manually define
the capture type (as explained later in this README)
* Logs will be stored in the directory you started Kismet from, unless
changed via the "logprefix" config file or "--log-prefix" startup
option.
* READ THE REST OF THIS README. Kismet has a lot of features and a lot
of configuration options, to get the most out of it you should read
all of the documentation.
* Note, at the time of this writing, the updated CACE install is not yet
* available, so users wishing to take advantage of the newcore
* functionality will need to build Kismet themselves in Cygwin
Compiling it yourself:
NOTE: KISMET WILL **ONLY** WORK WITH THE CACE AIRPCAP DEVICE, SAVED PCAP
FILES, -OR- REMOTE KISMET DRONES RUNNING ON A SUPPORTED PLATFORM. NO
OTHER HARDWARE IS SUPPORTED IN WINDOWS, PERIOD. WINDOWS DRIVERS DO NOT
INCLUDE SUPPORT FOR WIFI MONITORING WHICH KISMET REQUIRES. THERE IS NO
WAY TO CHANGE THIS.
The libpcap included with OSX does not support PPI logging. Kismet
will not be able to log to PPI correctly (so it will log 802.11
packets with no per-packet headers.)
* Run "kismet". If you did not install Kismet with suid-root support,
you need to start it as root in nearly all situations. This is not
recommended as it is less secure than privsep mode, where packet
processing is segregated from admin rights.
* When prompted to start the Kismet server, choose "Yes"
* When prompted to add a capture interface, add your wireless interface.
In nearly all cases, Kismet will autodetect the device type and
supported channels. If it does not, you will have to manually define
the capture type (as explained later in this README)
For many Macs, this will be 'en1', however start a terminal and check
the output of "ifconfig -a".
Kismet currently ONLY works with the Airport wireless devices, NOT USB
WIRELESS DEVICES.
* Logs will be stored in the directory you started Kismet from, unless
changed via the "logprefix" config file or "--log-prefix" startup
option.
In order to configure the wireless card for monitor mode and start
capturing packets, Kismet needs root access. There are two ways to
accomplish this: Start Kismet as root, or install it so that the
control components are set to start as root.
Starting Kismet as root means that Kismet will continue running as root.
In theory this presents no additional risk, however if there are any
flaws in the Kismet packet dissection code then it may be possible for a
malicious packet to cause code execution as root. Additionally,
third-party plugins will run as root, and may not be secure.
Embedded systems typically have much less storage space and RAM, and
often do not enforce user/root separation as strictly due to these
limitations. On embedded systems, Kismet may be installed without the
kismet_capture binary and run in root mode only, however the above
risks still apply.
5. Capture sources
All packets in Kismet come from a capture source. Capture sources are
typically network cards on the local system, however they can also be a
previously recorded file or a remote capture system running a Kismet
drone.
Kismet will, in most cases, autodetect the driver and supported channels
for a capture source given only the network interface. For many users
this will be sufficient, however many expanded options are available for
capture sources.
Kismet captures packets at the 802.11 layer. This requires changing the
mode of the network interface, making it unavailable for normal use. In
most cases it is not possible to remain associated to a wireless network
while running Kismet on the same interface.
Capture sources may be added via the Kismet UI under the "Add Source"
option, in which case the options may be added under the "Options:"
field, comma separated. They may also be defined in the kismet.conf
configuration file as the "ncsource=" option, such as:
ncsource=wlan0:option1=foo,option2=bar
Source options:
name=foo Custom name for the source (otherwise it will be
named the same as the capture interface). This is
completely arbitrary and meaningful only to the
user.
type=foo Sources which can not autodetect the type must have
the type specified. This is rarely necessary.
Additional information on supported source types
follows.
uuid=foo Users wishing a static unique identifier on sources
may specify one here. This is not necessary for
most users. UUID is of the format:
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
hop=true|false Disable channel hopping on this source. Default
behavior is for channel sources to hop channels to
cover the entire spectrum.
velocity=# Channel hop velocity (number of channels per
second), Kismet can hop 1-10 channels per second.
dwell=# Channel dwell time, the number of seconds Kismet
will wait on each channel. If hopping is enabled
and a channel dwell time is specified, Kismet will
hop at N seconds per channel, instead of N channels
per second.
channellist=name Use an alternate channel list instead of the
autodetected list of channels supported by this
interface. The channellist must be defined.
split=true|false When multiple sources use the same channel list
(either autodetected or by the channellist= option)
Kismet will split them so that they do not cover the
same channels at the same time. Sources can be
forced to ignore this and begin hopping at the
beginning of the channel list regardless of overlap.
retry=true|false Kismet will attempt to re-open a capture source
which has encountered an error. This behavior can
be disabled if the user wants the source to remain
closed.
vap=interface Create a secondary named interface for capture
instead of trying to change the mode of the
existing interface. This is primarily only for use
by drivers using the mac80211 interface under
Linux. Users wishing to do Kismet+Managed or
Kismet+Injection should create a vap.
forcevap=t|f True/False. Force creation of a monitor-mode VAP
when possible (all Linux mac80211 based drivers
support this). Default is "true", a VAP will be
made of the name 'mon', ie 'wlan0mon',
'wlan1mon' and capture will be done with this VAP.
This behavior can be forced OFF with
'forcevap=false'.
wpa_scan=time When using a mac80211 VAP, Kismet can use
wpa_supplicant on a managed interface to trigger
hardware assisted scans, enabling some view of the
rest of the spectrum without significantly
disrupting operation of the managed VAP. Suggested
time for scan intervals is 15 seconds.
validatefcs=t|f True/False. Kismet normally will not bother trying
to validate the FCS checksum of incoming packets
because most drivers only report valid frames in
the first place. Packet sources which report
invalid frames by default will enable this option
automatically. If the drivers have been manually
configured to report invalid packets, this should
be specified to prevent Kismet from processing
broken packets.
fcs=true|false Force handling of FCS bytes on a packet source.
Default is "false", which implies "native FCS
handling". Packet sources which include per-packet
headers like radiotap or PPI will ignore this value
as the FCS is encoded in the radio header. Packet
sources such as pcapfile, reading raw 802.11 pcap
files with no headers, may need this turned on for
proper behavior.
fcsfail=true Force a mac80211 VAP to report packets with a known
bad FCS (packet checksum). This is only available
on Linux and only when using mac80211 drivers.
This MUST come after a 'vap=' option or it will be
ignored. Enabling 'fcsfail' will enable
'validatefcs' automatically. The 'fcsfail' option
should only be enabled when logging to PPI; Logging
to normal PCAP will not preserve the FCS data and
will produce unreadable output.
WARNING: With some driver versions, enabling this
seems to cause kernel OOPS warnings and the
interface will become unresponsive if capture is
stopped and resume. This option is for specific
expert use only, when in doubt, leave it alone.
plcpfail=true Force a mac80211 VAP to report packets which do not
pass the PLCP check (if possible on that
interface). The same warnings and conditions as
'fcsfail' apply. This option is for specific,
expert use only, when in doubt, leave it alone.
Example sources (these are given as config file parameters, however they
will work equally well as command-line options, ie "-c wlan0"):
Capture on wlan0, channel 6, don't channel hop
ncsource=wlan0:hop=false,channel=6
Channel lists:
channellist=name:channel,channel,channel
channellist=foo:1:3,6:3,11:3,2,3,4,5,6,7,8,9,10
channellist=name:range-[start]-[end]-[overlap]-[iteration]
Channels between start and end, at a given iteration. Kismet will not hop
directly between channels that overlap.
channellist=foo:range-1-11-3-1
channellist=foo:range-2412-2462-20-5
Ranges are NOT split between sources. Multiple sources hopping on the
same channel list which includes a range will not split the expanded
range - in other words, channel ranges are treated as a single channel
entry.
channellist=foo:range-1-11-3-1,36,52
Madwifi (Linux):
Madwifi-ng has been largely deprecated by ath5k/ath9k for normal
usage. These drivers support multi-vap more cleanly via the mac80211
layer and do not, typically, have the same problems historically
present in madwifi.
Combining managed and monitor VAPs appears to still not work well.
RT28xx (Linux)
There are 2 drivers for the RT28xx chipsets. The in-kernel driver
available as of Linux-2.6.31 works properly with Kismet. This is by
far the preferred driver to use. Be sure to enable the RT28xx driver
in the wireless drivers section, NOT the staging driver. The staging
driver is not mac80211 based and will not necessarily behave.
This driver defaults to the name 'rausbX' which exposes a bug in some
versions of libpcap and may require the device be renamed (See
'Troubleshooting' section)
rt73-k2wrlz (Linux)
This driver defaults to the name 'rausbX' which exposes a bug in some
versions of libpcap and may require the device be renamed (See
'Troubleshooting' section)
WL (Linux, Intel)
OTUS (Linux)
Atheros released a driver for the 802.11n USB devices; however, this
does not have support for monitor mode and cannot be used with Kismet.
The ar9170 driver project is providing mac80211 kernel support for
this card, and works with Kismet. ar9170 has been merged with the
wireless-git development kernel and should be present in the
compat-wireless packages.
The Nokia drivers often return FCS-invalid packets. The Nokia source
line should include 'fcs=true,validatefcs=true' to prevent these from
creating multiple false networks out of invalid packets.
Orinoco (Linux)
Due to problems in monitor mode with newer firmwares, the Orinoco kernel
drivers have disabled monitor mode for newer/"modern" firmware versions
in the Orinoco cards.
Kismet will attempt to use the device, but warn the user that it will
probably fail. Monitor support can be forced on in the module via the
module parameter "force_monitor=1" when loading orinoco.ko.
For non-hermes chipsets like prism2, use hostap (also in the kernel).
NDISWrapper (Linux)
The NDIS-Wrapper driver loads Windows drivers into the Linux network
stack. These drivers are not capable of monitor mode, and will not
work with Kismet.
Note: The rndis drivers are NOT the same as ndiswrapper. rndis
drivers are for a specific USB chipset and are not related to
ndiswrapper, rndis will work.
Cards which work under the generic BSD framework for monitor mode with
radiotap headers should work with Kismet via the source types
"radiotap_bsd_ag", "radiotap_bsd_a", "radiotap_bsd_g", and
"radiotap_bsd". Channel detection and device type autodetection are
currently not supported.
ncsource=wl0:type=radiotap_bsd_ag
Windows (Generic)
The Airpcap has monitor mode drivers with a *public* interface for
controlling them. This is the only device Kismet can capture packets
from on Windows.
AirPcap (Windows)
By default Kismet will open the first Airpcap device found. Multiple
devices can be opened by using the full named interface, which can be
found in the AirPcap tools but follows the pattern \\.\airpcapXX ; The
first device is \\.\airpcap00, the second is \\.\airpcap01, and so on.
USB Devices (OSX)
Only devices using the Airport IOKit drivers are supported on OSX.
USB devices are, in general, not supported because the drivers lack
monitor mode or a method to set the channel.
All modern drivers on Linux use the mac80211 driver framework. Kismet
will auto-detect any driver using this framework. A generic source
type 'mac80211' can be used for forcing a type, however it is not
strictly useful to do so.
Capture on BSD should work with any driver which supports monitor mode
and which uses the standard BSD IOCTLs to set the mode and channel.
Currently ONLY THE AIRPCAP DEVICE, PCAP FILE, AND DRONES RUNNING ON A
SUPPORTED PLATFORM are supported under Windows. NO OTHER DEVICES CAN
BE USED FOR PACKET CAPTURE.
Kismet plugins can do almost anything that the native Kismet process can
do. This includes extending the logging capability, adding IDS alerts,
defining new capture sources (within some limitations), and adding new
features to the Kismet UI.
Plugins bundled with Kismet (and third-party plugins extracted into the
Kismet source dir) can be built with 'make plugins' and installed with
'make plugins-install' or 'make plugins-userinstall'. These commands
will automatically configure the plugin to compile using the current
Kismet source directory, for third-party plugins compiled outside of the
tree (or for manually compiling plugins), the KIS_SRC_DIR variable must
be set or the symlinks to the Kismet source must be set up properly (see
the README for the plugin you are trying to compile for more
information).
Plugins for the Kismet server (capture and logging process) are loaded
from the system-wide plugin directory (/usr/local/lib/kismet/ by
default) or from the users Kismet settings directory
(~/.kismet/plugins).
Kismet server plugins cannot currently be manipulated via the Kismet UI,
but loaded plugins will be displayed.
9. GPS
Kismet can use the GPS network daemon 'gpsd', or can parse NMEA directly
from the GPS unit.
The GPS is controlled with the Kismet server config, kismet.conf. For
using gpsd with gpsd running on the local system:
gps=true
gpstype=gpsd
gpshost=localhost:2947
gpsmodelock=false
gpsreconnect=true
gps=true
gpstype=serial
gpsdevice=/dev/ttyS0
gpsreconnect=true
The gpsdevice parameter should be set to the proper serial device for
your GPS. For USB GPS devices this will typically be /dev/ttyUSB0, and
for bluetooth devices this will often by /dev/rfcomm0 or similar. Check
the output of "dmesg" after plugging in your device.
Kismet cannot know the location of a network, it can only know the
location where it saw a signal. By circling the suspected location,
you can provide more GPS data for processing the network center point.
10. Logging
By default Kismet will log the pcap file, gps log, alerts, and network
log in XML and plaintext.
By default, Kismet will try to log to pcapfiles using the PPI per-packet
header. The PPI header is a well-documented header supported by
Wireshark and other tools, which can contain spectrum data, radio data
such as signal and noise levels, and GPS data.
Nested directories may be used (for example, with a template of the form
"%p/%l/%D-%t"), however they must be created prior to starting Kismet,
Kismet will not create the directories itself.
Most users should never need to change the logtemplate, however the
option remains available. When changing the template, be sure to
include the "%p" prefix option in a logical location (ie, at the
beginning of the template) or else the --log-prefix argument will not
function as expected.
11. Filtering
filter_tracker=BSSID(AA:BB:CC:DD:EE:FF)
filter_tracker=BSSID(!AA:BB:CC:DD:EE:FF)
Multiple MAC addresses can be stacked on the same filter line, to filter
two all packets from AA:BB:CC:DD:EE:FF and 00:11:22:33:44:55:
filter_tracker=BSSID(!AA:BB:CC:DD:EE:FF,!00:11:22:33:44:55)
filter_tracker=BSSID(AA:BB:CC:00:00:00/FF:FF:FF:00:00:00)
filter_tracker=SOURCE(11:22:33:44:55:66)
Kismet can integrate with other tools using the tun/tap export to
provide a virtual network interface of wireless traffic; tools such as
Packet-o-Matic and Snort can use this exported data to perform
additional IDS functions.
alert=NETSTUMBLER,5/min,1/sec
Kismet supports the following alerts, where applicable the WVE (Wireless
Vulnerability and Exploits, http://www.wve.org) ID is included:
APSPOOF Fingerprint
A list of valid MAC addresses for a SSID may be given via the
'apspoof=' configuration file option. If a beacon or probe
response for that SSID is seen from a MAC address not in that
list, this alert will be raised. This can be used to detect
conflicting access points, spoofed access points, or attacks
such as Karma/Airbase which respond to all probe requests.
apspoof=Foo2:ssid="Foobar",
validmacs="00:11:22:33:44:55,AA:BB:CC:DD:EE:FF"
BSSTIMESTAMP Trend/Stateful
Invalid/Out-of-sequence BSS Timestamps can indicate AP spoofing.
APs with fluctuating BSS timestamps could be suffering an "evil
twin" spoofing attack, as many tools do not attempt to sync the
BSS timestamp at all, and the fine-grained nature of the BSS
timestamp field makes it difficult to spoof accurately. Some
APs may reset the BSS timestamp regularly, leading to a
false-positive.
References:
WVE-2005-0019
CHANCHANGE Trend/Stateful
A previously detected access point changing channels may
indicate a spoofing attack. By spoofing a legitimate AP on a
different channel, an attacker can lure clients to the spoofed
access point. An AP changing channel during normal operation
may indicate such an attack is in process, however centrally
managed networks may automatically change AP channels to
less-used areas of the spectrum.
References:
WVE-2005-0019
CRYPTODROP Trend/Stateful
Spoofing an AP with less-secure encryption options may fool
clients into connecting with compromised credentials. The only
situation in which an access point should reduce encryption
security is when the AP is reconfigured.
DEAUTHFLOOD Trend/Stateful
BCASTDISCON Trend/Stateful
By spoofing disassociate and deauthenticate packets an attacker
may disconnect clients from a network, causing a
denial-of-service which lasts only as long as the attacker is
able to send the packets.
References:
WVE-2005-0019, WVE-2005-0045, WVE-2005-0046, WVE-2005-0061
http://802.11ninja.net
http://home.jwu.edu/jwright/papers/l2-wlan-ids.pdf
DHCPCLIENTID Fingerprint
A client which sends a DHCP DISCOVER packet containing a
Client-ID tag (Tag 61) which doesn't match the source MAC of the
packet may be doing a DHCP denial-of-service to exhaust the DHCP
pool.
DHCPCONFLICT Trend/Stateful
Clients which receive a DHCP address and continue to use a
different IP address may indicate a misconfigured or spoofed
client.
DISASSOCTRAFFIC Trend/Stateful
A client which is disassociated from a network should not
immediately continue exchanging data. This can indicate a
spoofed client attempting to incorrectly inject data into a
network, or can indicate a client being the victim of a
denial-of-service attack.
DISCONCODEINVALID Fingerprint
DEAUTHCODEINVALID Fingerprint
The 802.11 specification defines valid reason codes for
disconnect and deauthenticate events. Various client and access
point drivers have been reported to improperly handle
invalid/undefined reason codes.
DHCPNAMECHANGE Trend/Stateful
DHCPOSCHANGE Trend/Stateful
The DHCP configuration protocol allows clients to optionally put
the hostname and DHCP client vendor/operating system in the DHCP
Discover packet. These values should only change if the client
has changed drastically (such as a dual-boot system). Changing
values can often indicate a client spoofing/MAC cloning attack.
LONGSSID Fingerprint
The 802.11 specification allows a maximum of 32 bytes for the
SSID. Over-sized SSIDs are indicative of an attack attempting
to exploit vulnerabilities in several drivers.
MSFBCOMSSID Fingerprint
Some versions of the Windows Broadcom wireless drivers do not
properly handle SSID fields longer than the 802.11
specification, leading to system compromise and code execution.
This vulnerability is exploited by the Metasploit framework.
References:
WVE-2006-0071
MSFDLINKRATE Fingerprint
Some versions of the Windows D-Link wireless drivers do not
properly handle extremely long 802.11 valid rate fields, leading
to system compromise and code execution. This vulnerability is
exploited by the Metasploit framework.
References:
WVE-2006-0072
MSFNETGEARBEACON Fingerprint
Some versions of the Windows netgear wireless drivers do not
properly handle over-sized beacon frames, leading to system
compromise and code execution. This vulnerability is exploited
by the Metasploit framework.
NULLPROBERESP Fingerprint
Probe-response packets with a SSID IE tag component of length 0
can cause older cards (prism2, orinoco, airport-classic) to
fail.
References:
WVE-2005-0019
PROBENOJOIN Trend/Stateful
Active scanning tools such as Netstumbler constantly send
network discovery probes but never join any of the networks
which respond. This alert can cause excessive false positives
while channel hopping, and is disabled by default.
For the most part, Kismet can run with no additional configuration by
adding capture sources runtime with the UI, however for
standalone/headless operation or advanced configuration, users will want
to edit the config file.
The Kismet config is a plain text file with option=value pairs. Lines
beginning with # are considered comments and are ignored.
Kismet can decrypt WEP networks for which the WEP key is already known:
wepkey=bssid,hexkey
Only the hex key can be given, since there is no consistent method to
turn a pass-phrase into a hex key for WEP for different vendors.
enablespeech=true|false Speak
speechbin=... Text-to-Speech player
speechtype=raw|festival If using Festival (but NOT flite) speech
type must be set to 'festival', all other
tools should be set to 'raw'
speechencoding=... NATO, Spelling, Speech. Encoding of speech
fields for clarity, spell network SSIDs as
NATO, spelled-out letters, or speak them
normally.
speech=xxx,"format" Format of spoken strings, see the Kismet UI
section for more information on formatting
of speech strings.
14. Kismet UI
Use of a mouse is supported in much of the Kismet UI, although not all
widgets fully support mouse operation. Basic use of the UI with no
keyboard should be reasonable, however.
The main Kismet window consists of the network list, GPS information,
a summary of the current server statistics and packet source status, and
the status panel where errors and announcements are printed. Additional
components of the main window may be turned on with the 'View' menu.
- Preferences
The Kismet UI handles sound and speech playing for most users. Sound
playing is straightforward (WAV files are installed, by default, to
/usr/local/share/kismet/wav) and can be played with any sound player
compatible with your install.
- Tagging networks
Kismet can add custom data to a network in the form of tags. In the
Kismet UI, networks and clients can both have tags added to them. These
tags are displayed in the UI under network details, and logged to XML
and TXT output.
- Sorting
To select a network and view details, first sort by another method (such
as channel, time, etc) via the Sort menu, then select a network.
Kismet Drones are designed to turn Kismet into a distributed IDS system.
Drones support all of the capture methods Kismet normally supports,
including multiple capture devices per drone. Drones capture wireless
data and forward to a Kismet server over a secondary connection (ie,
wired Ethernet). Drones do not do any decoding of packets and have
minimal hardware requirements.
A Kismet server connects to the drones and will provide a single Kismet
UI display, packet dump, and alert generation point. Capture sources on
remote Kismet drones are forwarded to the Kismet server and appear as
independent capture devices which can be configured for channel hopping,
locking, etc.
Using the tun/tap export function, the central Kismet server can export
the packets from all attached drones to a virtual network interface for
use with external IDS/packet capture systems (such as Snort).
This documents a simple case of the Kismet protocol and the basics of
communicating with a Kismet server, however for detailed information the
source should be consulted. A more complete documentation of the
protocol will be done at some point.
*HEADER: f1 f2 f3 f4
Where HEADER is the sentence type, and the remainder are fields
requested by the client, in the order they were requested.
!{#} SHUTDOWN
Shutdown Kismet instance
Protocol sentences:
Mandatory sentences:
*KISMET
Basic Kismet startup info
*PROTOCOLS
List of supported sentences
*ACK
Command response
*ERROR
Command failure
*TIME
Server timestamp
Example:
*ACK: 0 OK
*CHANNEL: 1 4
*CHANNEL: 3 1
*CHANNEL: 4 1
*TIME: 1245176426
17. Troubleshooting
PROBLEM: Kismet makes the mouse slow or crashes the whole system
FIX: This isn't actually Kismet. Only the kernel layer should be
able to cause the system to lockup or crash, or interfere with
interrupts so badly that the mouse becomes unresponsive.
Kismet may exacerbate this behavior by changing the card
configuration and exposing flaws in the driver; This most
often can happen while changing channels, try disabling
channel hopping (or slowing it down), and upgrade to the
latest drivers for your device.
top
Kismet-Old Readme
Kismet-Old 2009-05-R1
Mike Kershaw
http://www.kismetwireless.net
Licensed under the GPL
** NOTE **
This version of Kismet is based on the previous code base (previously known
as Kismet-Stable) and is now deprecated. It is made available for those not
willing or able to make the switch to the new release, however it is not the
recommended version.
1. What is Kismet
2. Quick Start
3. Feature Overview
4. Typical Uses
5. Upgrading From Previous Versions
6. Suidroot & Security
7. Required Libraries & Utilities
8. Compiling
9. Configuration
10. Panels Interface
11. Operating Systems
12. Capture Sources
13. Graphical Network Mapping
14. Drone Remotes
15. Intrusion Detection
16. Reporting Bugs
17. Troubleshooting
18. Frequently Asked Questions
1. What is Kismet
PLEASE read the full manual, but for the impatient, here is the BARE
MINIMUM needed to get Kismet working:
PLEASE read the full manual, but for the impatient, here is the BARE
MINIMUM method to get Kismet running:
KISMET WILL ONLY WORK WITH THE CACE AIRPCAP DEVICE OR REMOTE KISMET DRONES
IN WINDOWS. NO OTHER CARDS ARE SUPPORTED, PERIOD. DO NOT ASK IF KISMET
WILL WORK WITH THEM ON WINDOWS, IT WILL NOT. THIS LIMITATION IS CAUSED
BY THE LACK OF SNIFFER-MODE CAPABLE DRIVERS ON WINDOWS.
PLEASE read the full manual, but for the impatient, here is the BARE
MINIMUM method to get Kismet running:
3. Feature Overview
4. Typical Uses
In order to configure the wireless card for rfmon and start the packet
capture, Kismet needs root access. As soon as root access is no longer
required, Kismet drops to a designated user so that potentially hostile
remote data isn't processed as root.
When priv dropping is enabled, Kismet forks and leaves a single process
as root. This process is used for channel control and for restoring
card settings on exit. The root process performs no interaction with
user input, and only communicates with the base kismet_server via IPC
pipes.
For Kismet to have root access, it can be installed two different ways:
- Normal installation via 'make install' requires Kismet be started as
root.
- Suid-root installation via 'make suidinstall'. DO NOT INSTALL KISMET
SUID-ROOT IF YOU HAVE OTHER USERS ON YOUR SYSTEM. Suid-root installation
will allow unprivileged users to set the wireless card to rfmon (breaking
any connections using wireless) and capture data.
LibPcap provides the common capture system Kismet uses to read from most
Posix-style interfaces. Without LibPcap, Kismet will be all but useless
on most platforms.
GPSD is a daemon which listens on a serial port for GPS data, parses it,
and makes it available via a TCP socket. Kismet can use a GPSD on the
local system, or if there is a wired ethernet connection available it can
use a GPS via port 2947 on a remote host.
- Imagemagick (5.4.7+): http://www.imagemagick.org/
REQUIRED for gpsmap map generation
- GMP: http://www.swox.com/gmp/
REQUIRED for gpsmap map generation
- DBUS: http://dbus.freedesktop.org/
OPTIONAL for networkmanager control
8. Compiling
FreeBSD users should configure kismet to use the systemwide pcap, which
supports multiple DLT types, with --enable-syspcap
9. Configuration
1. Set up the target suiduser. This is the user that Kismet will drop
to after it sets the cards in monitor mode and attaches to them. See
the section 'Suidroot & Security' for more information. If this is
not set correctly, Kismet won't start.
This is controlled by the 'suiduser' directive.
2. Set up the capture sources. Most users will only need one, but it is
possible to have any number of sources defined which will be combined
into a single packet log.
Sources are defined with the 'source' directive. Source lines are
defined with 'source=type,interface,name[,channel]'. See the section
'Capture Sources' for a list of source types. The name can be anything
that is useful for you to identify what source it is. The initial
channel is optional. If an initial channel is requested on the command
line it will take precedence.
Most users will want to use channel hopping, but remember - just like
it's impossible to see all of a program while channel surfing on TV,
channel hopping means missing some of the data on the network.
5. Set the log template. By default, Kismet writes logs to the directory
it is started in. By putting a full path into the 'logtemplate'
directive you can force it to write them to another location (such as
a directory guaranteed to be writeable by the target suiduser).
Client configuration:
2. Set columns to be displayed. The default set should be fine for most
but it can be changed/expanded. Columns can be scrolled in the client
with the arrow keys.
3. Set a sound player. For most, 'play' from Sox (the default) should
be fine. If you use a sound daemon such as esd or ksd you will need
to change the play command to call esdplay or similar.
4. Configure speech (or not). Kismet can write to Festival for speaking
information about networks.
5. Customize colors. Most components of the Kismet panels UI can be
colorized.
The annoying popup window that opens every time you start the client can
be disabled by setting 'showintro' to 'false' in your kismet_ui.conf.
* To allow Kismet clients from remote hosts to connect, comment out the
bind_addr field to default to INADDR_ANY (all network interfaces).
* IDS alert rates can be controlled via the 'alert' directive, which
specifies the alert type, rate per timeframe (ie, 5/min), and the burst
rate per timeframe (ie, 1/sec). These controls are similar to the
iptables limit controls.
* Networks with known WEP keys can be decrypted in realtime with the
'wepkey' directive, which specifies a BSSID (or bssid mask) and the
WEP key.
* MAC address masking. Nearly any directive which takes a MAC address
(such as filters, WEP keys, etc) can take a masked address. MAC masking
works the same as netmask in TCP/IP, for example
'00:11:22:00:00:00/FF:FF:FF:00:00:00'
would match all addresses beginning with 00:11:22. Masks do not have
to break on whole pairs ('FF:FF:FF:F0:00:00' is a valid mask).
* Log tuning. The types of packets that make it into the logfiles can be
controlled via the 'noiselog', 'beaconlog', 'phylog, 'mangledatalog',
and other options.
* Channel delays. Currently the easiest way to get Kismet to spend more
time on part of the channel hop list is to include that channel multiple
times. A hop list of "1,3,6,6,6,9,11" would spend 3 times as long on
channel 6 as on the other channels. Channels can be repeated
throughout the list, as well, for example "6,1,6,3,6,9,6,11" would have
a similar effect while providing more frequent monitoring of other
channels.
* Fuzzy encryption detection. Not all drivers properly set the WEP flag
on encrypted packets. As of 2005-06-R1, Kismet automatically attempts to
manually determine if a packet contains encrypted data if it is part of
a network which advertises encryption. This behavior can be turned off
via the "netfuzzycrypt" option, and it can be enabled for specific
capture types via the "fuzzycrypt" config option.
Filtering syntax:
Filters are "positive-pass": anything matched by the filter is passed and
all else is excluded.
Filtering can be done on address types (ANY, SOURCE, DEST, and BSSID).
To exclude a network with the BSSID AA:BB:CC:DD:EE:FF, the filter would be:
filter_tracker=BSSID(!AA:BB:CC:DD:EE:FF)
Multiple MAC addresses can be used on the same filter line. To filter
out two known networks from being considered:
filter_tracker=BSSID(!00:11:22:33:44:55,!00:11:22:33:44:66)
Which is to say, all traffic not from 00..55 and not from 00..66 will
be considered.
Primary functions:
* Auto-fit and sorted network lists
* Client lists for each network
* Detailed network information
* Packet rate graphs
* Channel allocation graphs
* Realtime packet type display
* Compass-display of network locations
* 'Locking' channel hopping to a specific network
Other clients for Kismet are available from the links page on the Kismet
website.
The clients window has a similar selection of columns which can be enabled:
crypt Number of encrypted data packets transfered by client
data Number of data packets transfered by client
decay Displays '!', '.', or ' ' based on network activity
ip Last seen IP used by client
mac MAC address of client
manuf Manufacturer of client (if known)
maxrate Maximum rate client seen transfering
noise Last seen noise level of client
signal Last seen signal level of client
size Amount of data transfered by client
type Type of client (Established, To-DS, From-DS, etc)
weak Number of packets which appear to have weak IVs
Kismet will work (at some level) on any operating system which has POSIX
compatibility, however for it to do native packet capturing it needs
drivers which are capable of reporting packets in rfmon. Remote sources
such as WSP100 or Drones can be used on any platform you can get Kismet to
compile on.
Kismet will work with any distribution of Linux. Currently, Linux is the
recommended platform for running Kismet because it has the largest
selection of rfmon capable drivers.
- OpenBSD
Known supported cards: Prism2 (wi), Atheros (ath), Intel 2200/2225/2915
(iwi), Intel 2100 (ipw), Ralink (ral, ural and rum), Realtek RTL8180L
(rtw), ZyDAS ZD1211/ZD1211B (zyd), Prism GT Full-MAC (pgt), Cisco 35x
(an), WSP100, Drone, wtapfile, pcapfile.
OpenBSD 3.7 and newer includes a software 802.11 stack and the Radiotap
packet header format. Any cards that use the 802.11 stack and support
monitor mode should work with Kismet via the radiotap_bsd_x capture
sources.
OpenBSD 3.2 and newer report standard frames from the Prism2 drivers.
Thanks to the efforts of Pedro la Peu, Kismet works fully with prism2
cards under OpenBSD.
- FreeBSD
Known supported cards: Atheros, Prism2, WSP100, Drone, wtapfile, pcapfile
- MacOSX
Known supported cards: Viha, Darwin, WSP100, Drone, wtapfile, pcapfile
Modern cards (Broadcom and Atheros) are supported via the 'darwin' capture
source. Read the comments below in the Darwin section of the source list
for more information.
Thanks for Kevin Finisterre for help adding the modern OSX capture sources.
Other third-party drivers may support rfmon for other PCMCIA and USB
cards under OSX - let me know if your drivers support rfmon, and I'll
add support in Kismet.
- Win32 (Cygwin)
Known supported cards: WSP100, Drone, airpcap, wtapfile, pcapfile
Win32 local packet capture is possible ONLY with the CACE Airpcap device.
http://www.cacetech.com/products/airpcap.htm
Thanks to Loris Degioanni for doing the bulk of the work adding airpcap
support under cygwin.
Win32 is also usable with REMOTE captures such as the Kismet drone
running on a platform which supports native capture.
GPSMap can download maps from several online sources (MapBlast, Tiger,
Terraserver, Earthamaps, and more) as well as use user-provided graphics,
provided you know the scale and center coordinates.
Main features:
* Travel path/track
* Approximate network circular range
* Approximate network center
* Convex hull of all network sample points
* Interpolated (weathermap-style) graphing of power and range
* Labeling of network centers
* Scatterplot of all detected packets
* Legend showing total sample networks, visible networks, colors,
power ranges, network center, etc.
'gpsmap --help' lists all of the switches for enabling different map
overlays, map sources, and coloring options. The default map source
is a blank image.
All of these map sources rely on external data. By using them, you agree
to whatever terms and conditions the map provider requires. Visit the
map providers website for these conditions. It is highly probable that
re-use of maps from vendors, in noncommercial or commercial situations,
is against the terms of service.
A kismet server can be connected to all the drones in the network and will
provide a single dump file and alert system. Using wep decrpytion and a
named pipe output ('fifo' config file option), wireless traffic from around
an installation can be sent to snort (or other layer3 IDS).
If a GPS is enabled on the drone, packets recieved from the drone will use
that GPS for positioning information. If the GPS is not enabled, then the
GPS connected to the Kismet server will be used.
Bugs happen, and I'm sure some are still in the code. To make a useful
bug report:
* Start Kismet
* Use TCPDump to get a capture of the packets outside of Kismet, until
Kismet crashes. (``tcpdump -i foo0 -w crashlog.dump'')
* Run the capture through Kismet: Does it still crash? (use the
pcapfile capture type) ``kismet_server -c pcapfile,/path/to/dump,foo''
* Send me the dump file and the info
* Recompile Kismet from source and don't use ``make install''. The install
scripts strip debugging info from the binaries that we need.
* Run Kismet inside gdb (``gdb ./kismet_server'' or ``gdb ./kismet_client'')
* When it crashes, get a backtrace: ``bt'' in gdb
* Send me the info
17. Troubleshooting
PROBLEM: Fatal error enabling monitor mode, 'monitor' ioctl not available
Some capture sources use a private ioctl, 'monitor', to enable rfmon.
If Kismet is unable to find this ioctl, it means that the wrong
interface was specified, the wrong capture type is being used, or
most commonly, the drivers you are using have not been patched or the
patched drivers are not being loaded.
Be sure to download any patches needed for the drivers you are using,
and make sure that no other copies of those drivers exist in your
/lib/modules/kern-version/ directory. You may need to restart pcmcia-cs
if your wireless card was already running when you installed the patched
drivers.
FIX: Provide the correct interface and ensure that the patched drivers are
loaded.
PROBLEM: Fatal error about a Cisco card not reporting the correct
link type in Linux
FIX: Use the correct Cisco card drivers. The ones from cisco.com and
the ones in pcmcia-cs don't support rfmon, but act as if they do.
PROBLEM: Fatal error about being unable to open a file for writing
The most common cause of this problem is that the suiduser you specified
for Kismet to drop to does not have rights to write to the directory
Kismet is trying to log to.
If you did not modify the 'logtemplate' configuration file variable,
Kismet defaults to the current directory for saving logs. You can set
an explicit path in the logtemplate variable to put your logs in the same
place every time.
FIX: Start Kismet from a directory that the suiduser can write to, or set
the logtemplate variable to always put the logs in a directory the
suiduser can write to.
PROBLEM: The panels client fails with the error 'unable to open
terminal xyz'.
FIX: Set your TERM environment variable to something libcurses has support
for. 'vt100' is usually a good choice.
PROBLEM: My GPS hardware claims to have a signal lock, but Kismet shows a
fix of 0 and does not log any GPS inforation.
FIX: Some GPS units have invalid NMEA streams which gpsd doesn't understand
correctly. Set the "gpsmodelock" option to "true" in kismet.conf
PROBLEM: I can't lock Kismet onto a single channel in the panels client,
it says the server doesn't support channel hopping.
FIX: You need to start Kismet with channel hopping enabled to be able to
lock a source to a specific channel. Kismet will automatically disable
channel hopping if none of the enabled sources support setting the channel.
PROBLEM: Kismet says it couldn't take the card out of monitor mode on
exiting.
FIX: The source you're using won't come cleanly out of rfmon, or I didn't
implement it for some reason. You'll need to reconfigure (or restart)
the interfaces manually.
PROBLEM: Kismet says it took the card out of monitor mode, but it still
doesn't work.
FIX: Sometimes cards don't come out of monitor mode cleanly. If it doesn't
work, you'll need to manually restart your card, sorry. Restarting your
card depends on your drivers and distribution, Google is your friend.
PROBLEM: Kismet can't compile, there are errors about not finding libpcap
FIX: Kismet no longer includes libpcap source, and expects your system to
have a relatively modern (0.9+ preferred) libpcap install. Install
libpcap, and if your distribution provides it, libpcap-devel.
It has been reported that loading the madwifi modules with the module
parameter "autocreate=none" helps, by not automatically creating the
initial managed VAP, subsequent creation of the monitor vap doesn't
exhibit the lockup while channel hopping.
Q: Why is rfmon different from promiscuous mode, and why can't you just use
promisc?
A: In the wired world, promiscuous mode turns off the filtering mechanism
in your network card, causing it to pass all packets to the operating
system. With most drivers, it means the same thing in the wireless
world, -BUT- it only applies to the network you are currently associated
with, and it only passes the packets as 802.3/Ethernet-II. This means
no 802.11 headers, no 802.11 management frames, and nothing from
networks other than the one you're associated with.
Rfmon is a special mode that reports all packets the wireless card sees,
including management packets and packets from any network the radio can
see.
Kismet can't just use promisc mode because it won't be able to gather
information about the networks, and would only be able to get data from
the network you've already joined.
Q: My distro loads the orinoco drivers for my prism2 card, is this OK?
A: No, not really. The orinoco and prism chipsets are based off the same
reference design, but there are subtle differences, especially in the
firmware timings. Using the orinoco drivers may work for a while, but
you're likely going to have problems with lost frames, corrupt frames,
and system hangs. Plus, if you ever have problems and mention you're
using the orinoco drivers, I'll yell at you.
Q: When channel hopping, the orinoco keeps going to channel -1 and not
working.
A: Apply the latest patches available on the Kismet download page, these
fix a number of issues with the orinoco drivers and seem to alleviate
this problem for most users.
Q: How can I include all the standard known manufacturers in the manuf
identification?
A: There is a script in the extras/ directory that will convert the
standard OUI list (such as that provided with Ethereal) into the format
Kismet uses. This will make Kismet take a LOT more ram and a moderate
increase in CPU to store and search the expanded list. If your hardware
can handle it, by all means, but not recommended for lowpower systems.
top
dragorn@kismetwireless.net