HTTP WWW - Kismetwireless.net Documentation

Kismet
Page 1 of 46
Download
Documentation
Forum
Links
Documentation Kismet Readme Current Kismet Readme Kismet-Old Readme Readme from Kismet-Old code (Pre 2009-05-RC1) top
Kismet Readme
Kismet 2011-01-R1 Mike Kershaw http://www.kismetwireless.net 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 1. What is Kismet Upgrading from earlier versions Quick start Suidroot & security Capture sources Caveats & quirks for specific drivers Supported capture sources Plugins GPS Logging Filtering Alerts & IDS Server configuration options Kismet UI Kismet drones Talking to Kismet Troubleshooting Frequently asked questions What is Kismet Kismet is an 802.11 wireless network detector, sniffer, and intrusion detection system. Kismet will work with any wireless card which supports raw monitoring mode, and can sniff 802.11b, 802.11a, 802.11g, and 802.11n traffic (devices and drivers permitting). Kismet also sports a plugin architecture allowing for additional non-802.11 protocols to be decoded. Kismet identifies networks by passively collecting packets and detecting networks, which allows it to detect (and given time, expose the names of) hidden networks and the presence of non-beaconing networks via data traffic. 2a. Upgrading from recent versions 2009-06-R1 has changed some basic behavior when using multi-vap capable devices (ie, modern in-kernel Linux drivers). Whenever possible, it will create a new VAP and reconfigure it, instead of modifying the existing interface. To preserve the old behavior, specify 'forcevap=false' on the source line. 2b. Upgrading from Kismet-old versions
http://www.kismetwireless.net/documentation.shtml
8/1/2011
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. To take advantage of the new features, replace your existing configuration files with the latest configuration data. 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 While this release breaks almost everything from previous releases, it opens the door for smoother upgrades and major feature enhancements. 3. Quick start PLEASE read the full manual, but for the impatient, here is the BARE MINIMUM needed to get Kismet working: * Download Kismet from http://www.kismetwireless.net/download.shtml * Run "./configure". Pay attention to the output! If Kismet cannot find all the headers and libraries it needs, major functionality may be missing. Most notably, compiling Kismet yourself will require the development packages and headers, usually called foo-dev or foo-devel. * Make sure that all the functionality you need was enabled properly in configure. Almost all users will need pcap and libnl support for proper operation. * Compile Kismet with "make". * Install Kismet with either "make install" or "make suidinstall". YOU MUST READ THE "SUID INSTALLATION & SECURITY" SECTION OF THE README OR YOUR SYSTEM MAY BE INSECURE. * If you have installed Kismet as suid-root, add your user to the "kismet" group * 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. 3b. Windows quick start * 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 Using the CACE Package: * Download the Win32/Cygwin installer created by CACE and linked from the download page (http://www.kismetwireless.net/download.shtml * Run the installer * Start Kismet
Page 2 of 46
8/1/2011
Kismet
* Pick your AirPcap or Kismet Drone sources * READ THE READ OF THIS README. Compiling it yourself: * * * * * Download the Cygwin setup tool (http://www.cygwin.org) Install Cygwin with make, GCC, libncurses, libncurses-dev Download the Airpcap_Devpack from CACE Support Put Airpcap_Devpack and Libpcap_Devpack in the kismet source directory Run "./configure", adding the options: --with-airpcap-devpack=... --with-winpcap-devpack=... --enable-airpcap The airpcap/winpcap devpack is available from the CACE website. Due to bugs in Cygwin, it appears that the airpcap and winpcap directories must be inside the kismet source directory. If they are not, the Kismet binary will immediately exit with no output. * Compile Kismet with "make". * Install Kismet with "make install" 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. 3c. OSX/Darwin quick start * Please note: Many have complained that iTerm does not send correct key events. However, Terminal.app appears to work fine, and is recommended for using Kismet. * Download Kismet from http://www.kismetwireless.net/download.shtml * Run "./configure". Pay attention to the output! If Kismet cannot find all the headers and libraries it needs, major functionality may be missing. Notably, you may need to install libpcap manually. 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.) Configure will automatically detect OSX and default to the group "staff" for OSX suidinstall. This may be overridden with the '--with-suidgroup' configure option. * Compile Kismet with "make". * Install Kismet with either "make install" or "make suidinstall". YOU MUST READ THE "SUID INSTALLATION & SECURITY" SECTION OF THE README OR YOUR SYSTEM MAY BE VULNERABLE. * If you have installed Kismet as suid-root, add your user to the "staff" group if it is not already. * 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". The wireless interface must be enabled in the wireless control panel for Kismet to work, otherwise it will not find any networks. 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.
Page 3 of 46
8/1/2011
Kismet
Page 4 of 46
* READ THE REST OF THIS README 4. Suidroot & Security 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. Installing Kismet as suid-root creates a limited-functionality binary (kismet_capture) which is only launchable by members of the "kismet" group. Kismet uses this to configure cards and control the channels, while packet decoding happens only in the user component, significantly limiting the attack surface. Distributions are strongly encouraged to use this method as it allows standard group controls for what users can use Kismet to change card states. 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. Under no situation should the kismet_server binary itself be set suidroot as this will bypass any security checks. 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
type=foo
uuid=foo
hop=true|false
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. Sources which can not autodetect the type must have the type specified. This is rarely necessary. Additional information on supported source types follows. 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 Disable channel hopping on this source. Default behavior is for channel sources to hop channels to
8/1/2011
Kismet
cover the entire spectrum. Channel hop velocity (number of channels per second), Kismet can hop 1-10 channels per second. 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. Use an alternate channel list instead of the autodetected list of channels supported by this interface. The channellist must be defined. 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. 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. 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. 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'. 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. 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. 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. 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. Force a mac80211 VAP to report packets which do not pass the PLCP check (if possible on that
Page 5 of 46
velocity=# dwell=#
channellist=name
split=true|false
retry=true|false
vap=interface
forcevap=t|f
wpa_scan=time
validatefcs=t|f
fcs=true|false
fcsfail=true
plcpfail=true
8/1/2011
Kismet
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 Capture on wlan0, 802.11b channels only even if it supports 5GHz ncsource=wlan0:channellist=IEEE80211b Create a VAP on wlan0 named wlan0mon and use wpa_supplicant to give us some view of other channels, while remaining associated to a network: ncsource=wlan0:vap=wlan0mon,hop=false,wpa_scan=15 Read from a pre-recorded pcap file: ncsource=/home/foo/old.pcap Capture using the first Airpcap device on Windows ncsource=airpcap Capture using a remote capture drone ncsource=drone:host=10.10.100.2,port=2502 Channel lists: Channel lists control the channels and patterns hopped to by capture sources in Kismet, when the channels can not be autodetected (or when the user wishes to override them for some reason). The default channel lists (IEEE80211b, IEEE80211a, and IEEE80211ab) are used only when a channel list is not provided by the driver, so should not be changed in most cases. When the channel list is automatically created from the channels supported by the driver, the preferredchannels= option will control which channels are weighted for extra time. By setting this to channels known to be defaults (such as 1, 6, 11) or channels with known networks of interest (such as in a stationary install), Kismet will devote more time to those channels to gather more information. For more complex channel timing, keep reading about how channel lists work. Channels can typically be specified as IEEE channels (11, 36, etc) or as frequencies (2401, 5200) however some platforms and drivers may not support specifying channels or frequencies out of the IEEE standard range. channellist=name:channel,channel,channel Additionally, individual channels in the list can be weighted so that more time is spent on them; for a weighting value of 3, 3x more time is spent on that channel. channellist=foo:1:3,6:3,11:3,2,3,4,5,6,7,8,9,10 Up to 256 channels may be specified in a channel list. numbers of channels, a range must be specified. Ranges may consist of channels or of frequencies. channellist=name:range-[start]-[end]-[overlap]-[iteration] Channels between start and end, at a given iteration. directly between channels that overlap. channellist=foo:range-1-11-3-1 A similar range using frequencies (802.11 2.4GHz channels are ~20MHz wide; technically 22 but 20 suffices, and 5 MHz apart). channellist=foo:range-2412-2462-20-5 Kismet will not hop For greater
Page 6 of 46
8/1/2011
Kismet
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. Multiple ranges can be specified in a single channel list, separated by commas. They may also be mixed with channels: channellist=foo:range-1-11-3-1,36,52 6. Caveats and quirks for specific drivers: Mac80211 General (Linux): At the time of this release, the mac80211 drivers in Linux are undergoing significant development, which means at any given time they can exhibit extremely odd behavior or be outright broken. Users are encouraged to upgrade to the latest kernel, and to consider installing the compat-wireless backport package, if problems are experienced. 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. Madwifi-ng sources can be specified as either the VAP (ath0, mon0, etc) or as the control interface (wifi0, wifi1). However, IF THE CONTROL INTERFACE IS SPECIFIED, Kismet cannot extract the list of supported channels, and will default to IEEE80211b channels. Madwifi-ng continues to have problems with multi-vap and initial vap creation. It is recommended that the initial VAP creation be turned off by the module parameter "autocreate=none" when loading ath_pci. If the madwifi monitor vap stops reporting packets soon after being created, this is often the cause. 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. The out-of-kernel driver does not conform to mac80211 controls. This driver also cannot be auto-detected (they don't provide a valid identifier in /sys) so the driver type mus be manually specified with 'type=rt2870sta' on the source line. 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) An out-of-tree rt73 driver similar to rt2870sta. It may be necessary to specify a type of 'rt73' manually when using this driver. 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) Broadcom has released a binary version of their drivers called WL. These drivers are incapable of monitor mode, and cannot be used with Kismet. Kismet will attempt to autodetect them and report this to the user. Users of Broadcom cards should use the b43 or b43xx in-kernel drivers.
Page 7 of 46
8/1/2011
Kismet
Page 8 of 46
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. Nokia ITT (Linux) For any chance of Kismet working on the Nokia ITT, the scan interval must be set to zero in the Nokia system control panel, connectivity section. It should be disconnected from any network, but wireless must be turned on. 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. The Nokia device does not autodetect properly, a driver type of 'nokia770', 'nokia800', 'nokia810', or 'nokiaitt' must be set. 'nokiaitt' is a generic source which should work on any Nokia ITT tablet. 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. BSD (BSD Generic) 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) ONLY THE AIRPCAP DEVICE IS SUPPORTED UNDER WINDOWS. THIS IS A SPECIFIC HARDWARE DEVICE MADE BY CACE TECHNOLOGIES. IF YOU DID NOT GO AND BUY AN AIRPCAP SPECIFICALLY FOR CAPTURING DATA, YOU DO NOT HAVE ONE, AND THIS WILL NOT WORK. 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
8/1/2011
Kismet
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. 7. Supported capture source types Capture source types are only required in specific situations where Kismet cannot detect the capture source type automatically. Linux Capture Sources: 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. adm8211 acx100 hostap ipw2100 ipw2200 ipw2915 ipw3945 mac80211 madwifi madwifi_a madwifi_b madwifi_g madwifi_ag nokia770 nokia800 nokia810 nokiaitt pcapfile rt2870sta wl12xx Kernel adm8211 driver Kernel acx100 driver Kernel prism2 driver Kernel Intel 2100 driver Kernel Intel 2200 driver Kernel Intel 2915 driver Kernel intel 3945 driver Generic mac80211 catch-all source for any mac80211 drivers. Madwifi/Madwifi-ng Alias for madwifi, default 802.11a channels Alias for madwifi, default 802.11b/g channels Alias for madwifi, default 802.11b/g channels Alias for madwifi, default 802.11abg channels Conexant-based driver in Nokia Maemo tablets Alias for nokia770 Alias for nokia770 Alias for nokia770 Pcap-formatted previously recorded file Out-of-kernel/Staging rt2870 11n driver (use in-kernel instead) Patched wl12xx drivers for the N900, must use patched drivers from http://david.gnedt.eu/blog/, otherwise autodetected. Remote Kismet packet capture, source options "host=..." and "port=..." are required. ncsource=drone:host=localhost,port=2502
Page 9 of 46
drone
BSD Capture Sources: Currently, the BSD packet capture sources do not support autodetection or channel detection. 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. Patches/Additional BSD support welcome. radiotap_bsd radiotap_bsd_g radiotap_bsd_a radiotap_bsd_ag pcapfile drone Generic Default Default Default BSD capture source, default 802.11b/g channels 802.11b/g channels 802.11a channels 802.11abg channels
Pcap-formatted previously recorded file Remote Kismet packet capture, source options "host=..." and "port=..." are required.
Windows Capture Sources: Currently ONLY THE AIRPCAP DEVICE, PCAP FILE, AND DRONES RUNNING ON A SUPPORTED PLATFORM are supported under Windows. NO OTHER DEVICES CAN
8/1/2011
Kismet
BE USED FOR PACKET CAPTURE. airpcap Airpcap generic source. Will autodetect the channel ranges. Interface 'airpcap' will detect the first airpcap device (ncsource=airpcap), interface paths may be used to specify specific devices (ncsource=\\.\airpcap01) List available sources and ask which one to use. Should NOT be used when launched by the Kismet UI. Pcap-formatted previously recorded file Remote Kismet packet capture, source options "host=..." and "port=..." are required.
Page 10 of 46
airpcap_ask
pcapfile drone
OSX/Macintosh Capture Sources: darwin Any device controlled by the Airport IOKit drivers under OSX. Default 802.11b/g channels. pcapfile drone 8. Plugins 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 need access to the Kismet source (and configuration information) to compile, and should ALWAYS be recompiled when the Kismet version changes (for those using Kismet-SVN development code, this may require rebuilding plugins every time a checkout is done). 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). When running Kismet with privilege separation enabled (installed kismet_capture as root), plugins are only loaded by the Kismet server process and not the root-level Kismet capture process, and plugins cannot perform tasks that require root privileges. When running Kismet without privilege separation (launching as root), plugins run with root privileges. This is not recommended. Server plugins are only loaded when kismet.conf contains: allowplugins=true Client plugins are loaded from the system-wide plugin directory (/usr/local/lib/kismet_client by default) or from the users Kismet settings directory (~/.kismet/client_plugins). The Kismet UI provides mechanisms for loading plugins (and specifying plugins to be loaded automatically on startup) via the Plugins menu item. Once a Kismet UI plugin is loaded, it cannot be unloaded. To unload a Kismet plugin, go to the Plugins window, configure the plugin to not load on start, and restart Kismet. To configure plugin loading in the UI, select the plugin (the list is automatically generated from plugins installed in the system and user plugin directories) and press enter. Plugins will be loaded when the plugin window is closed. Pcap-formatted previously recorded file Remote Kismet packet capture, source options "host=..." and "port=..." are required.
8/1/2011
Kismet
Kismet server plugins cannot currently be manipulated via the Kismet UI, but loaded plugins will be displayed. If a plugin causes startup problems (most likely because it was compiled for a different Kismet binary), Kismet will exit and explain which plugin caused the crash during startup. Plugins may also cause instability during runtime; if runtime crashes occur while plugins are loaded, remove them and re-test. Often, recompiling the plugins against the running Kismet source will help resolve these issues. 9. GPS Kismet can integrate with a GPS device to provide coordinates for networks it has detected. These can be logged to the pcap file when PPI logging is enabled, and to an XML file for processing with Kismap, included with the Kismet source, as well as other third-party tools. 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. using gpsd with gpsd running on the local system: gps=true gpstype=gpsd gpshost=localhost:2947 gpsmodelock=false gpsreconnect=true By specifying gpsreconnect, if gpsd crashes its connection, it will be re-established. certain broken GPS/GPSd combinations, where valid lock. By forcing a gpsmodelock=true, always has a 2d lock. For using a GPS device without gpsd: 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. Kismet keeps running averages of the network location, however this is not incredibly accurate, due to averaging and imprecision in floating point math. For plotting network locations, the GPSXML file should be used. 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. PPI is only available with recent libpcap versions. When it is not available, Kismet will fall back to standard 802.11 format with no extra headers. The pcap logging format is controlled by: pcapdumpformat=ppi or or Kismet otherwises looses Gpsmodelock compensates for the GPS never reports a Kismet assumes the GPS For
Page 11 of 46
8/1/2011
Kismet
pcapdumpformat=80211 The naming of logfiles is controlled by the "logtemplate" configuration option. By default, Kismet logs in the directory it is started in (unless modified with the "--log-prefix" option). The following variables can be used in the logtemplate: %p Prefix (as given by --log-prefix) %n Logging name (as given by --log-title) %d Starting date, Mmm-DD-YYYY %D Starting date, YYYYMMDD %t Starting time, HH-MM-SS %i Incremental, in the case of multiple logs of the same name %l Log type (pcapdump, netxml, etc) %h Home directory of the user Kismet was started as The default log template with a --log-prefix of /tmp and a --log-title of Kismet would expand from: logtemplate=%p%n-%D-%t-%i.%l to (for example): /tmp/Kismet-20090428-12-45-33-1.pcapdump 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 Kismet supports basic filtering; networks can be excluded from tracking, pcap logging, or general logging, based on BSSID, source, or destination MAC addresses. Filters, when enabled, are "positive-pass"; anything matched by the filter will be allowed, and all other matches are excluded. To process ONLY packets to or from the network with the BSSID AA:BB:CC:DD:EE:FF: filter_tracker=BSSID(AA:BB:CC:DD:EE:FF) This behavior can be inverted by using the '!' operator. packets to or from the 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) MAC addresses may also be masked in a fashion similar to IP netmasks; to process only networks of a single manufacturer: filter_tracker=BSSID(AA:BB:CC:00:00:00/FF:FF:FF:00:00:00) Similarly, SOURCE(...), DEST(...), and ANY(...) may be used to filter packets. To process only packets FROM the MAC address 11:22:33:44:55:66: filter_tracker=SOURCE(11:22:33:44:55:66) 12. Alerts & IDS Kismet includes IDS functionality, providing a stateless and stateful IDS for layer 2 and layer 3 wireless attacks. Kismet can alert on fingerprints (specific single-packet attacks) and trends (unusual probes, disassociation floods, etc). Kismet can integrate with other tools using the tun/tap export to To exclude
Page 12 of 46
8/1/2011
Kismet
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. Kismet as an IDS is most effective in a stationary (ie, non-wardriving) setup, and for best results, a non-hopping source should be available on the channels the primary networks are on. Kismet IDS functions CAN be used in mobile or channel-hopping installations (and are turned on by default) but accuracy may suffer. Alerts are configured with the "alert=" configuration option in kismet.conf, and have two time parameters: Throttle, and Burst. The throttle option controls how many alerts are allowed total per time unit, while the burst option controls how many alerts are allowed in a row. For example: alert=NETSTUMBLER,5/min,1/sec Will allow 1 alert per second, at a maximum of 5 per minute. Kismet supports the following alerts, where applicable the WVE (Wireless Vulnerability and Exploits, http://www.wve.org) ID is included: AIRJACKSSID Fingerprint Deprecated The original 802.11 hacking tools, Airjack, set the initial SSID to 'airjack' when starting up. This alert is no longer relevant as the Airjack tools have long since been discontinued. 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. The 'apspoof=' configuration option can specific exact SSID matches, regular expressions (if Kismet is compiled with PCRE support), and single, multiple, or masked MAC addresses: apspoof=Foo1:ssidregex="(?i:foobar)",validmacs=00:11:22:33:44:55 apspoof=Foo2:ssid="Foobar", validmacs="00:11:22:33:44:55,AA:BB:CC:DD:EE:FF" When multiple MAC addresses are specified, they should be enclosed in quotes (as above). For more information about forming PCRE-compatible regular expressions, see the PCRE docs (man pcrepattern). 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
Page 13 of 46
8/1/2011
Kismet
Page 14 of 46
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. LUCENTTEST Fingerprint Deprecated Old Lucent Orinoco cards in certain scanning test modes generate identifiable packets. 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
8/1/2011
Kismet
to system compromise and code execution. 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. NETSTUMBLER Fingerprint Deprecated Older versions of Netstumbler (3.22, 3.23, 3.30) generate, in certain conditions, specific packets. 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. 13. Other Configuration Kismet is divided into two main processes: kismet_server and kismet_client. The server portion (responsible for capture, logging, and decoding) is controlled by kismet.conf (by default in /usr/local/etc) and the client is configured via preferences options. 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. beginning with # are considered comments and are ignored. Lines This vulnerability is
Page 15 of 46
Most configuration options are self-explanatory or documented in the config file itself. By default Kismet only listens to the loopback interface on port 2501. This may be changed: listen=tcp://ip:port Define the IP and port Kismet listens on. By default, for security reasons, Kismet will listen only on 127.0.0.1, the loopback interface. To listen on any interface, use the IP 0.0.0.0. Comma-separated list of IP addresses allowed to connect to the Kismet server. IP ranges may be specified with netmasks (ie 10.10.10.0/24) Maximum number of clients allowed to simultaneously connect to the Kismet server. Maximum number of backlogged "lines" the server keeps for clients which are not keeping up with the network protocol. This also affects the amount of RAM potentially used by the Kismet server process, and may need to be lowered on extremely RAM-limited systems.
allowedhosts=...
maxclients=N maxbacklog=5000
Kismet servers may also be configured to act as Kismet drones, exporting a TCP stream of live packets: dronelisten=.. droneallowedhosts=.. dronemaxclients=.. Same as above, for drone capabilities ... ...
8/1/2011
Kismet
droneringlen=65535 Equivalent of maxbacklog for Kismet clients, maximum amount of space used for backlogged packets as a drone. May be reduced on extremely RAM-limited systems.
Page 16 of 46
Kismet can export packets directly to other tools by creating a virtual network interface (supported on Linux, minimal support on OSX and BSD due to limited tuntap driver implementations on these platforms): tuntap_export=true tuntap_device=kistap0 Enable tuntap export Virtual network interface created
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. Sound and speech can be generated by the Kismet server, however typically this would be done by the Kismet UI instead. Sound is disabled by default in the Kismet server: enablesound=true|false soundbin=... sound=xxx,true|false Play sound Path and options for sound player binary Enable playing sound trigger xxx
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. The OUI file (used by Kismet to determine the manufacturer of a device) can be shared with other tools (such as Wireshark), so long as they use a compatible format. By default, Kismet searches: /etc/manuf /usr/share/wireshark/wireshark/manuf /usr/share/wireshark/manuf Additional search paths can be added with the 'ouifile=' configuration option. 14. Kismet UI The default Kismet UI uses the text-based ncurses library. Additional UIs may be available from the Links page on the Kismet website (http://www.kismetwireless.net/links.shtml) The Kismet UI functions much as any other curses application (such as Midnight Commander or Links) does. The menu is activated with 'escape', '`' or '~'. Navigation between elements of the UI is done with 'tab'. 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 Configuration of the Kismet UI is done entirely inside the UI via the 'Kismet->Preferences->...' menus. Preference changes are (for the most part) immediate and do not require restarting.
8/1/2011
Kismet
Page 17 of 46
By default, the Kismet UI will prompt on startup to launch the Kismet server, this behavior (as well as auto-connection and server setup) can be changed via the Startup and Shutdown preferences (Kismet->Preferences->Startup and Shutdown): Open Kismet server launch window automatically - Kismet will open the server startup window when the UI is loaded, if the default server is not running. Ask about launching server on startup - Ask to start a server (instead of just opening the server window) Show Kismet server console by default - Automatically open the Kismet server console window after starting the server Shut down Kismet server on exit automatically - Kill locally started servers and issue a shutdown command to remote servers when the UI exits Prompt before shutting down Kismet server - Don't kill servers without confirming Kismet menus support shortcuts, for example '~Wl' is the same as navigating to the 'Windows->Client List' menu option. - Sound and Speech 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. Speech is supported on Festival and Flite. Any other text-to-speech program should work as long as it accepts plain text on standard in. Speech text is encoded depending on the type of speech event, where %1, %2, etc are replaced with data by Kismet. The supported events and replacements are: New network: 1. Network SSID encoded to speech encoding setting (spell, nato, plain) 2. Network channel 3. Network BSSID Alert: 1. Alert type GPS Lost, GPS Lock: No replacement options - 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. Tags can be set as permanent; By checking the "Remember note when restarting Kismet" checkbox in the Network and Client Note windows, the note is saved and will be re-applied to networks every time Kismet loads. Client tags are applied to a specific client in a specific network; Currently there is no mechanism for adding a note to every instance of the client. - Sorting Kismet defaults to "autofit" mode, where it tries to put as many of the currently active networks on the screen as possible. Because autofit mode is so variable, it doesn't make sense to try to allow selecting networks in autofit. 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. 15. Kismet Drones
8/1/2011
Kismet
Page 18 of 46
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). To start using Drones, launch the kismet_drone process on a remote system (editing the kismet_drone.conf file to control what hosts are allowed to connect) or turn on drone capabilities in the Kismet server (by enabling the drone config options in kismet_server.conf). When running a kismet_server instance as a drone, local logging will act as usual and Kismet clients can be connected to the server as normal; When running kismet_drone, Kismet clients cannot connect directly to it, and it will not log, a Kismet server instance must be started to provide packet decoding, logging, and Kismet UI connectivity. 16. Talking to Kismet The Kismet client/server protocol is basic text. Communicating with Kismet can be as simple as using telnet or netcat, however writing a full protocol dissector is suggested for serious applications. 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. The Kismet protocol consists of commands and response sentences. command is of the form: !ID COMMAND OPT1 OPT2 OPT3 Where ID is a number (which for proper error detection should be unique) and the remainder of the arguments are the command and any options it may take. Options which contain spaces but should be treated as a single argument should wrap those options in "\001...\001" And a response sentence is of the form: *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. Fields are expected to be plain ASCII text, however a client should take precautions to be sure that the value is sane for the terminal before printing it. Fields which may contain a space (used as the separator character) are buffered with \001...\001. As this could be any field, any protocol parser should be able to handle fields so buffered. Basic Kismet commands include: !{#} SHUTDOWN Shutdown Kismet instance !{#} CAPABILITY {Sentence} Query the accept fields for a protocol. A
Returns the *CAPABILITY
8/1/2011
Kismet
sentence !{#} ENABLE {Sentence} {Fields}|{*} Enable a sentence, with either the provided fields and order, or all fields in the default order if * is specified. !{#} REMOVE {Sentence} Remove a sentence.
Page 19 of 46
Stop sending a sentence.
!{#} ADDNETTAG {BSSID} {Permanent} {Tag name} {Tag content} Add an arbitrary tag to a network. If permanent, it will be cached in ~/.kismet/tags.conf !{#} DELNETTAG {BSSID} {Tag name} Remove a tag !{#} ADDCLITAG {BSSID} {MAC} {Permanent} {Tag} {Content} Add tag to specified client in network !{#} DELCLITAG {BSSID} {MAC} {Tag} Remove a tag !{#} ADDSOURCE {source line} Add a source dynamically. Source line should be of the same format as a 'ncsource=' config line Protocol sentences: When a sentence is enabled, any existing sentence data is sent (at the discretion of the protocol handlers). Additional data is sent in the form of deltas; To conserve bandwidth and processing time, only instances where the data has changed are sent. For example, when the *BSSID sentence is sent, a block of *BSSID records are sent, for all networks previously detected by Kismet. Until the sentence is disabled, a record is sent once per second for each network which has changed in some fashion (new packets). Mandatory sentences: Kismet expects a client to support AT LEAST the following mandatory protocols, which are enabled by default. At the very least, any client should ignore these if it does not process them. They may be disabled with the REMOVE command. In general, any client should ignore protocols it does not understand. *KISMET Basic Kismet startup info *PROTOCOLS List of supported sentences *ACK Command response *ERROR Command failure *TIME Server timestamp Example: echo -e '\n!0 enable channel channel,networks' | nc localhost 2501 Enable the *CHANNEL sentence with the fields 'channel' and 'networks'. The output could look something like: *ACK: 0 OK *CHANNEL: 1 4 *CHANNEL: 3 1 *CHANNEL: 4 1 *TIME: 1245176426 17. Troubleshooting Congratulations! You're actually reading the troubleshooting section of the README! Many don't.
8/1/2011
Kismet
Page 20 of 46
If you are having trouble getting Kismet to capture packets at all, launch kismet_server independently of the client and watch the output, it may be easier to spot problems then. Some common problems with Kismet have easy solutions: PROBLEM: Fatal errors about old configuration files/missing config values Kismet has evolved over time, and has recently had a significant rewrite of the entire application, rendering many of the old configuration values obsolete, and changing many others. Update your config files. If you are moving to the latest release of Kismet, it may be best to just remove your old config files, copy the new ones, and reconfigure. Kismet crashes immediately while starting up If you are building Kismet from SVN routinely, it's possible that the build system has gotten screwed up with a recent change. Run 'make distclean' then './configure' and 'make' again. If the kismet_capture binary is out-of-sync with the kismet_server or kismet_drone binaries, things will behave oddly. Kismet shows FATAL errors about permission denied Are you trying to capture from a network interface without root privileges? Kismet must either be installed as suid-root (and the user starting it must be in the kismet group) or it must be started as root, see the "Suid Root & Security" section of the README. Kismet can not autodetect my card type or doesn't understand the "type=..." source option. Some drivers do not register with the /sys filesystem and can not be properly autodetected. Check the list of capture sources known to be problematic in this README. Secondly, check the output of './configure' when building Kismet and make sure that support for your capture type is present, most commonly support for pcap or wext is missing. Kismet warns about interfering processes while starting up. Many network services can interfere with Kismet (DHCP, networkmanager, etc) by reconfiguring or shutting down the network interface while Kismet is running. Only necessary if Kismet is not behaving as expected, or encountering errors. Shutdown or kill the offending processes. This can often be most quickly accomplished by stopping the networking services for your interface ('ifdown wlan0' for example). In some specific configurations, these alerts may be spurious (dhcp and wpa_supplicant alerts on a multi-vap mac80211 interface doing sta+rfmon with a wpa_supplicant scanning option, for example). Kismet complains about multiple VAPs under madwifi-ng Destroy the other VAPs, or ignore this warning if there are no run-time failures. Madwifi-ng has historically had significant problems with multi-vap and rfmon (for example, a STA VAP and a RFMON VAP). Shortly after starting on madwifi-ng, Kismet stops reporting packets. There appears to be a race condition in madwifi-ng startup where an autocreated VAP causes errors in future VAPs. A temporary fix is to reload the madwifi-ng driver before starting Kismet, with the 'autocreate=none' modparm ('rmmod ath_pci; modprobe ath_pci autocreate=none'), a more permanent fix is to put this in the default module parameters for ath_pci and make the necessary changes to your startup scripts to create a managed VAP on startup. './configure' is unable to find libpcap, wext, ncurses, pcre, or some other library when building from source.
FIX:
PROBLEM: FIX:
PROBLEM: FIX:
PROBLEM: FIX:
PROBLEM:
FIX:
PROBLEM: FIX:
PROBLEM: FIX:
PROBLEM:
8/1/2011
Kismet
FIX: Many distributions separate the runtime data from the data necessary to compile programs against a library. Install the '-dev' or '-devel' or 'devel-' packages for each of the libraries ('apt-get install libpcap-dev' for example) Kismet exits immediately on Cygwin with no output. Cygwin appears to have problems linking static libraries when they are not in a sub-directory of the build. By default, './configure' will look in "Airpcap_Devpack" and "Winpcap_Devpack", you should probably just expand the devpack zips there. I can't capture on (some device that isn't an AirPCAP that I bought from CACE) on Windows! Buy an AirPCAP and read the docs. I can't see some parts of the Kismet UI Some terminals have bad default color assignments and render dark grey as black. Go into the Kismet color preferences and change the items. A plugin crashes Kismet (server or UI) Recompile the plugin and make sure it's build with the same code as the Kismet server/client. This is especially problematic if you are following Kismet development in SVN. Kismet makes the mouse slow or crashes the whole system 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. Kismet cannot open a source, with the error: "can't get usb bus index" Some versions of LibPcap interpret any interface with "USB" in the name as a USB device on Linux, and attempt to do USB bus capture instead of packet capture. Rename the interface (with ifrename or udev rules) to something that doesn't include 'usb'. A newer version of libpcap may also resolve this problem. configure cannot find libnl on Ubuntu, but libnl-dev is installed Some distributions (apparently, Ubuntu) require libnfnetlink-dev to be installed as well. Currently there is no good way to autodetect this.
Page 21 of 46
PROBLEM: FIX:
PROBLEM: FIX: PROBLEM: FIX:
PROBLEM: FIX:
PROBLEM: FIX:
PROBLEM: FIX:
PROBLEM: FIX:
18. Frequently Asked Questions Q: Where did the name Kismet come from? A: 'Kismet' means 'Fate' or 'Destiny'; While I wish I could take credit for some plan about picking it for Kismets ability to uncover any network in the area, I really just needed a name and clicked through a thesaurus until I found a word that wasn't used in any other OSS projects. Q: Is there anything illegal about Kismet? A: In and of itself, there should be nothing illegal about Kismet (it's fundamentally no different than any other capture tool) but you should check your local laws first. Note, however: - Recording data from networks that you do not have permission to may be considered an illegal wiretap. - Using networks you do not have permission to use may be considered 'Theft of Service' and is illegal. - Don't be stupid. - If you are stupid, I'm not responsible. Q: Can Kismet crack WEP? A: Yes, but also, no. The base Kismet code does not do any WEP
8/1/2011
Kismet
cracking, however due to constant requests, there IS an Aircrack-PTW plugin which will do PASSIVE WEP cracking only. It will NOT do arp-replay, fragmentation, or other active attacks, however if enough packets are gathered it will attempt to crack the WEP key and insert it into Kismet to decrypt that network. The PTW-WEP cracking plugin is in the Kismet source tree in the plugin-ptw/ directory. Q: What's the deal with Newcore, and where did it go? A: Newcore was a total rewrite of Kismet, which lasted years longer in a development state than planned. If you're reading this, you've got the release that Newcore became already. Q: What happened to the version numbers? A: They stopped making sense. 3.0 to 3.1 was a 30,000 line change, but calling it 4.0 didn't make any sense either. I hate project perpetually in 0.1, 0.9 status, but I also hate artificially expanding the version numbers. So, now, it's versioned by the release date, YYYY-MM-RR. Q: Can I use the old Kismet UI still? A: No, sorry, too much has changed in the protocols, and the new UI is much more flexible anyhow Q: Can I use the old drones still? A: No, again, too much has changed (however from now on it should be possible to mix versions since the drone protocol has been expanded to be expandable) Q: What is RFMON/Monitor mode? A: In the wired world, promiscuous mode turns off the filtering mechanism in the device and reports all packets on the Ethernet (or whatever) layer. With wireless drivers, this doesn't necessarily mean anything (sometimes it causes different results, sometimes it doesn't). Wireless drivers present a fake Ethernet device to the operating systems, which reports only 802.11 data frames. When looking at WPA encrypted networks, this is even more limited, because packets are encrypted for each client and only multicast/broadcast packets or packets destined to the capture device could be reported as valid data frames anyhow. Monitor/RFMON mode is a special mode for wireless devices which reports all packets the card sees, with the 802.11 headers intact, including 802.11 management and control frames. Q: Does Kismet work differently than NetStumbler? A: Absolutely. Netstumbler (and Ministumbler, InSSIDer, etc) work by instructing the card to probe for networks and report the networks the card sees responses from. This method is obviously competent at detecting networks in the area, however it can't record data, find hidden networks, detect clients using networks, etc. Q: Why are some probe SSIDs full of strange nonsense characters? A: It appears with Windows Zero Config in many versions of Windows XP has an off-by-one error which leaks a little bit of memory into a probe request. Q: Why is the range of a network sometimes totally bogus when using a GPS with Kismet? A: Doing real-time GPS averaging leads to increasingly bad data due to floating-point accuracy and averaging. For more exact GPS data, process the gpsxml file. Q: What happened to gpsmap? A: gpsmap was the old mapper code for Kismet. It stopped being useful a long time ago when the map sources it used went away. It's being replaced with a tile-based mapper, the beginnings of which are in the kismap/ directory in the source code. Kismap isn't quite finished for the RC1 release, but development continues on it and it will be available hopefully soon. Q: How can I merge multiple capture files? A: Use the 'mergecap' tool that comes with Wireshark.
Page 22 of 46
8/1/2011
Kismet
Page 23 of 46
Q: How can I support device X with Kismet on operating system Y? A: Kismet is designed to be fairly modular (especially the newest versions based on Newcore). So long as your environment is something like Posix and your device supports raw capture modes, it should be possible. Swing by IRC (#kismet on freenode) and chat. Q: Why does Kismet make a new interface named foo-mon? A: When mac80211 is available, Kismet will use to create a new virtual interface, named after the existing interface (wlan0 for instance will cause a wlan0mon to be created). Kismet will use this virtual interface for capture, so that it causes less disruption to the configuration of the existing interface. Q: What happens when I ask a question already here? A: I'll probably be rude to you (or someone else will). But that would never happen, because everyone reads the docs all the way to the end, right? Right!?
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. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 1. What is Kismet Quick Start Feature Overview Typical Uses Upgrading From Previous Versions Suidroot & Security Required Libraries & Utilities Compiling Configuration Panels Interface Operating Systems Capture Sources Graphical Network Mapping Drone Remotes Intrusion Detection Reporting Bugs Troubleshooting Frequently Asked Questions What is Kismet Kismet is an 802.11 layer2 wireless network detector, sniffer, and intrusion detection system. Kismet will work with any wireless card which supports raw monitoring (rfmon) mode, and can sniff 802.11b, 802.11a, 802.11n, and 802.11g traffic (devices and drivers permitting). Kismet identifies networks by passively collecting packets and detecting standard named networks, detecting (and given time, decloaking) hidden networks, and inferring the presence of non-beaconing networks via data traffic.
8/1/2011
Kismet
Page 24 of 46
2a. Quick Start PLEASE read the full manual, but for the impatient, here is the BARE MINIMUM needed to get Kismet working: * Download Kismet from http://www.kismetwireless.net/download.shtml * Run ``./configure''. Pay attention to the output! If Kismet cannot find all the headers and libraries it needs, it won't be able to do many things. * Compile Kismet with ``make'' * Install Kismet with either ``make install'' or ``make suidinstall''. YOU MUST READ THE SECTION OF THIS README NAMED "SUID INSTALLATION & SECURITY" OR YOUR SYSTEM MAY BE MADE VULNERABLE!! * Edit the config file (standardly in "/usr/local/etc/kismet.conf") * Set the user Kismet will drop privileges to by changing the "suiduser" configuration option. * Set the capture source by changing the "source" configuration option. FOR A LIST OF VALID CAPTURE SOURCES, SEE THE SECTION OF THIS README CALLED "CAPTURE SOURCES". The capture source you should use depends on the operating system and driver that your wireless card uses. USE THE PROPER CAPTURE SOURCE. No permanent harm will come from using the wrong one, but you won't get the optimal behavior. * Add an absolute path to the "logtemplate" configuration option if you want Kismet to always log to the same directory instead of the directory you start it in. * Run ``kismet''. You may need to start Kismet as root. * READ THE REST OF THIS README 2b. Windows Quick Start PLEASE read the full manual, but for the impatient, here is the BARE MINIMUM method to get Kismet running: * * * * Download the Win32/Cygwin Installer created by CACE Run the installer Start Kismet Pick your AirPcap or Kismet Drone sources
* READ THE REST OF THIS README 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. 2c. OSX / Darwin Quick Start PLEASE read the full manual, but for the impatient, here is the BARE MINIMUM method to get Kismet running: * Download Kismet from http://www.kismetwireless.net/download.shtml * Run ``./configure''. Pay attention to the output! If Kismet cannot find all the headers and libraries it needs, it won't be able to do many things. * Compile Kismet with ``gmake'' (NOT 'make'. gnumake is required.) * Install Kismet with either ``gmake install'' or ``gmake suidinstall''. YOU MUST READ THE SECTION OF THIS README NAMED "SUID INSTALLATION & SECURITY" OR YOUR SYSTEM MAY BE MADE VULNERABLE!! * Edit the config file (standardly in "/usr/local/etc/kismet.conf") * Set the user Kismet will drop privileges to by changing the "suiduser" configuration option. * Set the capture source by changing the "source" configuration option. For OSX/Darwin, this should almost always be a source of type 'darwin'. FOR A LIST OF VALID CAPTURE SOURCES, SEE THE SECTION OF THIS README CALLED "CAPTURE SOURCES". The capture source you should use depends USE THE PROPER CAPTURE SOURCE. No permanent harm will come from using the wrong one, but you won't get the optimal behavior. * Add an absolute path to the "logtemplate" configuration option if you want Kismet to always log to the same directory instead of the directory you start it in.
8/1/2011
Kismet
* Run ``kismet''. You may need to start Kismet as root. * READ THE REST OF THIS README 3. Feature Overview Kismet has many features useful in different situations for monitoring wireless networks: 4. Ethereal/Tcpdump compatible data logging Airsnort compatible weak-iv packet logging Network IP range detection Built-in channel hopping and multicard split channel hopping Hidden network SSID decloaking Graphical mapping of networks Client/Server architecture allows multiple clients to view a single Kismet server simultaneously Manufacturer and model identification of access points and clients Detection of known default access point configurations Runtime decoding of WEP packets for known networks Named pipe output for integration with other tools, such as a layer3 IDS like Snort Multiplexing of multiple simultaneous capture sources on a single Kismet instance Distributed remote drone sniffing XML output
Page 25 of 46
Typical Uses Common applications Kismet is useful for: - Wardriving: Mobile detection of wireless networks, logging and mapping of network location, WEP, etc. - Site survey: Monitoring and graphing signal strength and location. - Distributed IDS: Multiple Remote Drone sniffers distributed throughout an installation monitored by a single server, possibly combined with a layer3 IDS like Snort. - Rogue AP Detection: Stationary or mobile sniffers to enforce site policy against rogue access points.
5.
Upgrading from Previous Versions Upgrading to Kismet 2008-05-R1: "probenojoin" has been disabled by default in the config file, as it's not terribly useful and generates a lot of noise. No other specific actions needed. Upgrading to Kismet 2007-10-R1: For Linux users, the config option 'vapdestroy' has been added. If you are using an Atheros card with Madwifi-NG, this controls if non-rfmon VAPs are destroyed automatically. Not including this new config option will default to 'false'. Wrt54 devices now have channel hopping enabled. probably turn this off by default. Packagers should
IV duplication tracking is now off by default to save memory, and is controlled by the 'trackivs' parameter. DBUS integration to try to quiesce Network Manager while Kismet is running, controlled by the 'networkmanagersleep' config parameter. Upgrading to Kismet 2007-01-R1: Make sure to either update your kismet.conf file from the one included in the distribution, or to copy the new ALERT enable lines. If you do not copy the ALERT setup from the new config, new IDS alerts will not be enabled. 6. Suidroot & Security 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
8/1/2011
Kismet
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. REMEMBER: Installing Kismet suid-root is NOT SECURE ON MULTIUSER SYSTEMS. Most users of Kismet are likely using single-user laptops or handhelds, where suidroot is very convenient. If you have ANY OTHER USERS ON YOUR SYSTEM, suidroot Kismet can be used to shut down the wireless and put files where you don't want to allow them to be put. If you have other users on your system, install kismet normally and 'su' to root before starting it. 7. Required Libraries & Utilities Kismet is primary self-contained, however for some features it requires some external libraries or utilities. For distributions which provide split library packages of somelib and somelib-devel, you will need both installed for Kismet to compile. - LibPcap (0.9+ preferred): http://tcpdump.org/ REQUIRED for the majority of packet capturing systems 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 (any version): http://gpsd.berlios.de/ REQUIRED for GPS support 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 Imagemagick is a graphics generation library which can read and write in almost any format. Kismet requires a recent version of Imagemagick due to IM's frequently changing API. If you do not plan to use gpsmap, you can skip this library. - Expat (1.95+): http://expat.sourceforge.net/ REQUIRED for gpsmap map generation Expat is an XML processing library. Kismet requires this for parsing netxml and gpsxml output logs. If you do not plan to use gpsmap, you can skip this library. Some versions of Expat included in distributions or other system utilities (ie, XFree86-cvs) contain errors that make it impossible to compile expat.h. Make sure you have the latest stable Expat version, and remove offending duplicate headers if necessary. - GMP: http://www.swox.com/gmp/ REQUIRED for gpsmap map generation GMP is an arbitrary-precision math library. Kismet needs this for high precision math functions when calculating graphics in gpsmap. If you do not plan to use gpsmap, you can skip this.
Page 26 of 46
8/1/2011
Kismet
- DBUS: http://dbus.freedesktop.org/ OPTIONAL for networkmanager control Networkmanager is a network connection management tool. It can reconfigure devices while Kismet is running, and should be stopped. If Kismet is compiled with DBUS support and the networkmanagersleep variable in kismet.conf is true, Kismet will use DBUS to send sleep/wake commands to Networkmanager 8. Compiling Compiling should be fairly straightforward. It uses the normal configure scripts found in most open-source projects, and should build with any modern version of gcc. 1. 2. 3. 4. Download any libraries and external utilities needed Run './configure' with any special options you want (see './configure --help') Run 'make' or 'gmake' Run 'make install' or 'make suidinstall' - SEE THE SECURITY SECTION OF THE README BEFORE INSTALLING KISMET SUIDROOT! IF YOU INSTALL SUIDROOT ON A SYSTEM WITH UNTRUSTED USERS, BAD THINGS CAN HAPPEN.
Page 27 of 46
Crosscompiling Kismet can sometimes have problems with the libpcap autoconf scripts not being able to detect the kernel type and version of the target system. Overriding the configuration script variables and passing extra configuration options can fix this: 'ac_cv_linux_vers=foo ./configure --with-pcap=linux ...' FreeBSD users should configure kismet to use the systemwide pcap, which supports multiple DLT types, with --enable-syspcap 9. Configuration Kismet is controlled by 2 primary configuration files: kismet.conf controls the server backend, and kismet_ui.conf controls the panels user interface. By default, these files are in /usr/local/etc/. Remote drone servers use a third file, kismet_drone.conf. Kismet configuration files are a simple 'directive=value' format. Basic server 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. 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. Set up channel hopping. The default channel hopping values will probably be fine for most, but the speed of channel hopping can be set with the 'channelvelocity' directive and the lists of channels to be hopped can be set with 'defaultchannels'. Additional per-source fine-grained channel hopping control is available via the 'sourcechannels' directives, which are explained in the configuration file comments. Channel dwelling (similar to hopping) can be set with the channeldwell option. Setting a channel dwell time controls the number of seconds between channel change, compared to the tenths of a second defined by channelvelocity. Most users will want to use channel hopping, but remember - just like
2.
3.
8/1/2011
Kismet
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. 4. Set up what clients are allowed to connect. By default this is limited to 'localhost', which is fine for most users. 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).
Page 28 of 46
5.
Client configuration: 1. Set the host and port. By default, Kismet is configured to connect to the localhost and standard port. 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. 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. Configure speech (or not). Kismet can write to Festival for speaking information about networks. Customize colors. colorized. Most components of the Kismet panels UI can be
2.
3.
4.
5.
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. More advanced server configuration: * 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. * Runtime filtering of packets is controlled by the 'filter_tracker', 'filter_dump', and 'filter_export' directives, which influence which packets are processed at all, logged to dump files, and logged to xml/csv/etc files, respectively. See the sub-section "Filtering Syntax" in this section for more information on filtering. * Including subconfig files. By using 'include=...' other files can be included into the Kismet config, with filtering, WEP keys, etc. * 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. * Probe tracking. By default, Kismet tracks probe requests and responses, and attempts to combine a probe request network with the network that responds to it. Sometimes this isn't the desired behavior, by setting 'trackprobenets' to 'false', probe requests will always remain separate.
8/1/2011
Kismet
Page 29 of 46
* 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) MAC addresses can be masked in the same fashion as IP netmasks. To match all networks of a certian manufacturer, restrict to the OUI: filter_tracker=BSSID(AA:BB:CC:00:00:00/FF:FF:FF:00:00:00) 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. 10. Ncurses/Panels Interface The ncurses/panels interface is the default frontend provided with Kismet. The panels interface is fairly intuitive, and has integrated help. 'h' will open the main help window showing all the options available. 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. All information about a network is contained in the network details window, and the following columns can be turned on in the main display: bssid BSSID (MAC address) of the network channel Last-advertised channel for network clients Number of clients (unique MACs) seen on network crypt Number of encrypted packets data Number of data packets decay Displays '!' or '.' or blank, based on network activity in the last 'decay' seconds (controlled by the 'decay' variable in the config file) dupeiv Number of packets with duplicate IVs seen flags Network status flags (Address size, decrypted, etc) info Extra AP info included by some manufacturers ip Detected/guessed IP of the network llc Number of LLC packets manuf Manufacturer, if matched maxrate Maximum supported rate as advertised by AP
8/1/2011
Kismet
name noise packets shortname shortssid signal signalbar snrbar size ssid type weak wep The clients crypt data decay ip mac manuf maxrate noise signal size type weak Name of the network or group Last seen noise level Total number of packets Shortened name of the network or group for small displays Shortened SSID for small displays Last seen signal level Graphical representation of signal strength Graphical representation of signal-to-noise ratio Amount of data transfered on network SSID/ESSID of the network or group Network type (Probe, Adhoc, Infra, etc) Number of packets which appear to have weak IVs WEP status (does network indicate it uses WEP) window has a similar selection of columns which can be enabled: Number of encrypted data packets transfered by client Number of data packets transfered by client Displays '!', '.', or ' ' based on network activity Last seen IP used by client MAC address of client Manufacturer of client (if known) Maximum rate client seen transfering Last seen noise level of client Last seen signal level of client Amount of data transfered by client Type of client (Established, To-DS, From-DS, etc) Number of packets which appear to have weak IVs
Page 30 of 46
11. Operating Systems 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. - Linux (Intel, PPC, MIPS, X-Scale, Arm, etc) Known supported cards: Atmel_USB, ACX100, ADMTek, Atheros, Cisco, Prism2, Orinoco, WSP100, Drone, wtapfile, pcapfile, wrt54g, ipw2100, rt2400, rt2500, rt73, rt8180, ipw2200, ipw2915, ipw3945, iwl3945, iwl4965, iwl5000, iwlagn, iwl5100, iwl5300 Broadcom 43xx 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 FreeBSD-current adds a common Radiotap packet header format. Thanks to Sam Leffler, Kismet supports the radiotap headers and should work with current FreeBSD systems. FreeBSD users should configure with the --enable-syspcap option to get multidlt support from the system-wide libpcap library instead of the bundled one.
8/1/2011
Kismet
- NetBSD Known supported cards: WSP100, Drone, wtapfile, pcapfile, radiotap There have been no reports positive or negative about NetBSD drivers. Please email if you have them working. NetBSD has radiotap support, in theory the radiotap_bsd_... source types should work. - MacOSX Known supported cards: Viha, Darwin, WSP100, Drone, wtapfile, pcapfile MacOSX is supported for Airport Classic cards using the Viha drivers at http://www.dopesquad.net/security/. 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. When compiling with AirPcap on Cygwin, it is necessary to pass both --enable-airpcap and --with-airpcap-devpack=Path, where Path is the CACE devpack containing winpcap and airpcap. Cygwin appears to have a bug which prevents proper linking if the devpack is not in the same directory as Kismet is compiled in. If kismet_server.exe instantly exits with no output, it is typically indicative of a linkage path problem. NO OTHER WIRELESS CARDS CAN CURRENTLY BE USED TO CAPTURE DATA NATIVELY IN WINDOWS. CACE has released a public API for their drivers to allow third-party programs to interface with them. Standard Windows wireless drivers are not rfmon capable. Due to interactions with Cygwin, users of the kismet_client ncurses frontend should disable sound in kismet_client.conf Win32 is also usable with REMOTE captures such as the Kismet drone running on a platform which supports native capture. 12. Capture Sources A capture source in Kismet is anything which provides packets to the Kismet engine. Capture sources define the underlying engine needed to capture data from the interface, how to change channel, and how to enter rfmon mode. It is necessary to tell Kismet what specific type of card you use because different drivers often use different methods to report information and enter monitor mode. Source type Cards OS Driver --------------- ------------------- ----------- ------------------------acx100 TI ACX100 Linux ACX100 http://acx100.sourceforge.net/ ACX100 drivers handle the 22mbit cards branded by D-Link and others. admtek ADMTek Linux ADMTek http://www.latinsud.com/adm8211/ (Patches) http://aluminum.sourmilk.net/adm8211/ (GPL driver) ADMTek drivers used in many consumer 802.11b cards. With the patches above, quasi-rfmon is possible - these cards appear to be almost entirely software controlled and
Page 31 of 46
8/1/2011
Kismet
always in a rfmon-like state. This card WILL BROADCAST while in rfmon, rendering the sniffer visible. The fully GPL drivers are supported, in addition to the hacks to the non-free drivers. airpcap Airpcap USB cygwin CACE Tech http://www.cacetech.com/products/airpcap.htm The CACE AirPcap USB device allows native capture on Win32/Cygwin. The explicit airpcap source expects the Win32/Cygwin interface name. This should be used once the source is identified via airpcap_ask or if multiple simultaneous sources are required. Airpcap USB cygwin CACE Tech http://www.cacetech.com/products/airpcap.htm The CACE AirPcap USB device allows native capture on Win32/Cygwin. The airpcap_ask source lists available airpcap devices and allows the user to pick interactively. The 'capture interface' field is irrelevant and can be filled with any value (for example, 'dummy') Atmel-USB Linux Berlios-Atmel http://at76c503a.berlios.de/ These drivers work ONLY on USB cards (Sorry, no PCMCIA support). Monitor mode support is limited and "faked" by bypassing part of the firmware and parsing packets directly, and is likely to not report all of the frames. This card MAY BROADCAST while in rfmon, rendering the sniffer visible. It appears that this card may be only formatting the beacons as an 802.11 stream, which means you likely will not see data frames, rendering most IDS functions, IP discovery, and data logging unavailable. Atheros Linux Kernel/Madwifi http://madwifi.org Based on the OpenBSD OpenHAL, the Ath5k drivers are the future of Atheros support and will be mainlined into the Linux kernel. Atheros Linux http://madwifi.org Ath5k source for 11a only Atheros Linux http://madwifi.org Ath5k source for 11a/11g Kernel/Madwifi
Page 32 of 46
airpcap_ask
atmel_usb
ath5k
ath5k_a
ath5k_ag
Kernel/Madwifi
bcm43xx
Broadcom Linux BCM43XX http://bcm43xx.berlios.de, kernel Linux native broadcom drivers incorporated into modern kernels. Broadcom Linux B43 broadcom drivers for current Broadcom devices in Linux kernels Broadcom Linux B43 broadcom drivers for legacy Broadcom devices in Linux kernels Aironet 340,350 Linux Kernel 2.4.10 - 2.4.19 Standard Cisco cards in Linux. Works only with the Linux kernel drivers, not the drivers found in pcmcia-cs. The drivers found on the cisco.com site can be patched with the files from the Kismet download site to add monitor mode with channel control, HOWEVER these drivers are extremely buggy for normal use and work only with the 2.4 kernel tree.
b43
b43legacy
cisco
8/1/2011
Kismet
The cisco drivers currently do not enter rfmon mode correctly, so channel control is not available. The firmware will hop to whatever channel it feels like hopping to, when it feels like hopping. cisco_wifix Aironet 340,350 Linux Kernel 2.4.20+, CVS http://sourceforge.net/projects/airo-linux/ Capture interface: 'ethX:wifiX' Kernel 2.4.20+ and CVS drivers use ethX for normal mode and wifiX for monitor mode. Kismet needs to know both devices, which may not necessarily be the same number, for example 'eth1:wifi0'. Linux kernel 2.4.20 and 2.4.21 have highly unstable cisco drivers and should be avoided. The cisco drivers currently do not enter rfmon mode correctly, so channel control is not available. The firmware will hop to whatever channel it feels like hopping to, when it feels like hopping.
Page 33 of 46
darwin
OSX native cards OSX/Darwin OSX Supports both Broadcom and Atheros Airport-Extreme cards. When using a Broadcom based card, it may be necessary to enable rfmon on the device for the first time using another program. When using an Atheros based card, 802.11a may also be supported by adding a 'sourcechannels' line to kismet.conf. Prism/2 Linux HostAP 0.4 http://hostap.epitest.fi/ HostAP drivers drive the Prism/2 chipset in access point mode, but also can drive the cards in client and monitor modes. The HostAP drivers seem to change how they go into monitor mode fairly often, but this source should manage to get them going. Intel/Centrino Linux ipw2100-0.44+ http://ipw2100.sourceforge.net/ The Linux IPW2100/Centrino drivers for 802.11b cards now support rfmon, so here's support for them. They act more or less like any other wireless interface would. Intel/Centrino Linux ipw2200-1.0.4+ http://ipw2200.sourceforge.net/ The Linux IPW2200/Centrino drivers for 802.11bg cards support rfmon as of 1.0.4 and firmware 2.3. Signal level reporting requires radiotap be turned on in the makefile while compiling the driver. Noise levels are not reported. Intel/Centrino Linux ipw2200-1.0.4+ http://ipw2200.sourceforge.net/ The Linux IPW2200/Centrino drivers for 802.11bga cards support rfmon as of 1.0.4 and firmware 2.3. This is the same as ipw2200 but defaults to scanning the 802.11a channel range in addition to 802.11b/g. Signal level reporting requires radiotap be turned on in the makefile while compiling the driver. Noise levels are not reported. Intel/Centrino Linux ipw3945 http://ipw3945.sourceforge.net/ The Linux IPW3945/Centrino drivers for Intel Core 802.11bga cards. Intel/Centrino Linux ipw2200/3945 http://ipw2200.sourceforge.net/ http://ipw3945.sourceforge.net/ The ipw3945 and patched ipw2200 drivers support a special mode which allows monitor-mode style sniffing while remaining associated. Channel hopping is not possible, as the card is still associated to a specific AP, but single-channel IDS and sniffing can be accomplished. See the ipw driver mailing list
hostap
ipw2100
ipw2200
ipw2915
ipw3945
ipwlivetap
8/1/2011
Kismet
archives for information about patching your drivers. iwl3945 Intel/Centrino Linux iwl3945 Intel's new IPW drivers using the mac80211 kernel layer. Intel/Centrino Linux iwl4965 Intel's new IPW drivers using the mac80211 kernel layer. Intel/Centrino Linux iwl4965 Intel's new IPW drivers using the mac80211 kernel layer. Intel/Centrino Linux iwl4965 Intel's new IPW drivers using the mac80211 kernel layer. Intel/Centrino Linux iwl4965 Intel's new IPW drivers using the mac80211 kernel layer. n/a Any n/a Capture interface: 'dronehost:port' The remote drone capture source connects to a Kismet drone and processes the packets. Refer to the Remote Drone section of the README for more details about how to set up a drone. Atheros Linux madwifi http://sourceforge.net/projects/madwifi/ Capture interface: 'athX' Capture interface: 'wifiX' (Madwifi-NG) Madwifi drivers in 802.11a-only mode. When using madwifi-ng, be sure all non-monitor VAPs have been removed, otherwise madwifi will not properly report most traffic. Atheros Linux madwifi http://sourceforge.net/projects/madwifi/ Capture interface: 'athX' Capture interface: 'wifiX' (Madwifi-NG) Madwifi drivers in 802.11b-only mode. When using madwifi-ng, be sure all non-monitor VAPs have been removed, otherwise madwifi will not properly report most traffic. Atheros Linux madwifi http://sourceforge.net/projects/madwifi/ Capture interface: 'athX' Capture interface: 'wifiX' (Madwifi-NG) Madwifi drivers in 802.11g-only mode. This will, obviously, also see 11b networks. When using madwifi-ng, be sure all non-monitor VAPs have been removed, otherwise madwifi will not properly report most traffic. Atheros Linux madwifi http://sourceforge.net/projects/madwifi/ Capture interface: 'athX' Capture interface: 'wifiX' (Madwifi-NG) Madwifi drivers in 802.11a and 802.11b combo mode. This will seamlessly switch between bands during channel hopping. When using madwifi-ng, be sure all non-monitor VAPs have been removed, otherwise madwifi will not properly report most traffic. Atheros Linux madwifi http://sourceforge.net/projects/madwifi/ Capture interface: 'athX' Capture interface: 'wifiX' (Madwifi-NG) Madwifi drivers in 802.11a and 802.11g combo mode.
Page 34 of 46
iwl4965
iwlagn
iwl5100
iwl5300
kismet_drone
madwifi_a
madwifi_b
madwifi_g
madwifi_ab
madwifi_ag
This
8/1/2011
Kismet
will seamlessly switch between bands during channel hopping. When using madwifi-ng, be sure all non-monitor VAPs have been removed, otherwise madwifi will not properly report most traffic. madwifing_a madwifing_ab madwifing_ag madwifing_g madwifing_b Atheros Linux madwifi-ng Atheros Linux madwifi-ng Atheros Linux madwifi-ng Atheros Linux madwifi-ng Atheros Linux madwifi-ng http://sourceforge.net/projects/madwifi/ Capture interface: 'wifiX' *Deprecated*. Detection for madwifi-ng is built into the standard madwifi sources. The _ng source names have been kept to allow old configs to continue functioning. Nokia Linux Nokiea http://maemo.org/ Nokia770 capture interface. Includes support for validating frame checksums to screen out junk packets, since the drivers pass us all data. Nokia 800,810 http://maemo.org/ Nokia 8x0 capture interface, including support for FCS validation. The Nokia drivers appear to exhibit instability while capturing where they stop reporting packets. This may be minimized by setting the Network Scan interval to "never" in the control panel->networking section.
Page 35 of 46
nokia770
nokia8x0
orinoco
Lucent, Orinoco Linux Patched orinoco_cs http://airsnort.shmoo.com/orinocoinfo.html The Orinoco drivers which have mainlined into the Linux kernel do support monitor mode, however only specific firmware versions are supported and often they do not work. An up-ported version of the older Orinoco drivers which more reliably supported rfmon may be available at: http://www.projectiwear.org/~plasmahh/orinoco.html Generally, Orinoco cards are not recommended for use with Kismet due to these limitations. Lucent, Orinoco Linux Orinoco 0.14+ https://savannah.nongnu.org/projects/orinoco/ This source is deprecated and should only be used with pre-release versions of a driver since merged into the Linux kernel. n/a Any n/a Capture interface: '/path/to/file' The pcapfile capture source feeds a stored 802.11-encap dump file through the Kismet engine again. This can be useful for debugging or rescanning old logs for alert conditions. Pcapfile sources are only available if Kismet was compiled with libpcap support. Prism/2 OpenBSD Kernel Full support for Prism2 under OpenBSD. PrismGT Linux prism54 http://www.prism54.org PrismGT 802.11g drivers supporting monitor mode.
orinoco_14
pcapfile
prism2_openbsd
prism54g
radiotap_bsd_ab Radiotap BSD Kernel Dual-band cards with radiotap headers. radiotap_bsd_a Radiotap BSD Kernel 802.11a cards (or dual-band on 11a channels only) with radiotap headers. radiotap_bsd_b Radiotap BSD Kernel
8/1/2011
Kismet
802.11b/g cards (or dual-band on 11b channels only) with radiotap headers. rt2400 Ralink 2400 11b Linux rt2400-gpl http://rt2x00.serialmonkey.com/ Ralink 2400 802.11b cards using the serialmonkey GPL'd rt2x00 drivers. Must use 1.2.2 beta 2 or newer drivers. Ralink 2500 11g Linux rt2500-gpl http://rt2x00.serialmonkey.com/ Ralink 2500 802.11g cards using the serialmonkey GPL'd rt2x00 drivers. Must use 1.1.0 beta 2 or newer drivers. Ralink 2860 Linux Ralink rt2860 out-of-kernel drivers Ralink 2860 Linux Ralink rt2860 out-of-kernel drivers Ralink 73 11g Linux rt73-gpl-cvs http://rt2x00.serialmonkey.com/ Ralink 73 802.11g USB cards using the serialmonkey GPL'd rt79 drivers (tested only with CVS driver versions) Realtek 8180 11b Linux rtl8180-sa2400 http://rtl8180-sa2400.sourceforge.net/ Realtek 8180 based cards (there seem to be an awful lot of them) using the GPL drivers. Airport OSX viha http://www.dopesquad.net/security/ Monitor mode support for Airport under OSX. support Airport Extreme.
Page 36 of 46
rt2500
rt2860
rt2860sta
rt73
rt8180
viha
Does not
vtar5k
Atheros 802.11a Linux vtar5k http://team.vantronix.net/ar5k/ vtar5k drivers handle some Atheros 802.11a cards. Chances are you'll have better luck with madwifi drivers. Prism/2 Linux wlan-ng 0.1.3 and earlier http://www.linux-wlan.com/ Old wlan-ng drivers didn't support pcap capturing and use a netlink socket to the kernel. These are still in use on some embedded systems (like the Zaurus). Prism/2 Linux wlan-ng 0.1.4 - 0.1.9 http://www.linux-wlan.com/ Wlan-ng prism2 drivers prior to the AVS headers. Prism/2 Linux wlan-ng 0.2.0+ http://www.linux-wlan.com/ Newer wlan-ng drivers support a new header type and slightly different monitor commands to report wepped packets. Linksys WRT54G Linux linksys http://seattlewireless.net/index.cgi/LinksysWrt54g Capture interface: 'wlX' Support for the newer firmware versions on the WRT54G/S/L devices (and any others using the broadcom reference chipset). Some systems generate a secondary device, prism0, while in monitor mode and require special care while channel hopping, it is no longer necessary to specify the prism0 device explicitly for Kismet. NetChem WSP100 Any n/a http://networkchemistry.com/ Capture interface: 'host:port' The WSP100 is an embedded device which reports 802.11 packets over UDP. The wsp100 capture source is (generally) system agnostic, however over time it has been less maintained than others. If you'd like to
wlanng_legacy
wlanng
wlanng_avs
wrt54g
wsp100
8/1/2011
Kismet
send me patches for this, please let me know. zd1211 ZyDAS USB Linux zd1211 http://zd1211.ath.cx The ZD1211 drivers have had some regressions which lead to data corruption while changing channel. Some versions work, and typically the aircrack patches resolve the corruption issues if your version doesn't properly handle rfmon.
Page 37 of 46
Chipsets known to NOT WORK: Broadcom - No linux drivers, only useable with ndiswrapper or linuxant wrappers around windows drivers. *** UPDATE *** See the bcm43xx source type entry. There are experimental reverse-engineered drivers which have monitor mode support now under Linux! If they don't work, however, then too bad. Airport Extreme - Really a Broadcom, with no rfmon in the OSX drivers. *** UPDATE *** See the bcm source for linux on ppc, it MAY work, it may not. Currently theres no solution for OSX but I'm looking for OSX hackers interested in redoing the Kismet port and looking into adding more support. Atmel - There is a hack for pseudo-monitor in USB. There is currently no equivalent hack for PCMCIA. HermesII - Proxim successor to the Orinoco/HermesI. No support yet in the drivers, may be available in the future. ndiswrapper - Anything using ndiswrapper is using WINDOWS drivers AND CAN NOT BE USED WITH KISMET. 13. Graphical Network Mapping Kismet provides a tool for drawing networks overlaid on downloaded maps called 'gpsmap'. Gpsmap reads the netxml and gpsxml files, sanitizes the data, 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. GPSMap currently can use maps from: NullMap (Blank white background) MapBlast (Vector) (Broken) MapPoint (Vector) (Broken, read warning) Terraserver (Satellite Photo) Tiger (Vector) (US Census data) Earthamap (Vector) (Requires perl) (Broken) Terraserver Topo (Vector-ish) Due to changes in the map websites (or their removal by vendors or corporate buyouts), many map sources no longer work. These mapsources are marked as "Broken" or "Unavailable". They have been left in GPSMap solely to enable easy plotting on previously saved map images. These will FAIL if they are selected and a user map is not also provided. 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
8/1/2011
Kismet
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. Plotting against non-vendor maps is possible by determining the equivalent scaling mechanism and setting the appropriate map type. Typically this must be done via trial and error. The extras/ directory contains an additional utility, 'gpsxml-sanitize', for cleaning invalid sample points out of the gpsxml data files for use in other programs. GPSMap cleans the data set automatically, reprocessing the gpsxml files is only needed if they are to be used in third-party programs. 14. Drone Remotes Remote Kismet drones are designed to turn Kismet into a stationary, distibuted IDS system. Drones support all of the capture sources Kismet supports, and can have multiple cards per drone. Drones capture wireless data and report it over a secondary connection (typically wired ethernet), and have very minimal hardware requirements. Each drone in the network can be configured for independent channel hopping, and even different 802.11 standards (such as one drone monitoring 802.11a and one monitoring 802.11b). 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). To start using drones, set up a kismet_drone on the system with a wireless card, using the kismet_drone.conf file. Then configure Kismet to have a kismet_drone capsource pointing to that host, start kismet_server, and use whatever client you like to connect to Kismet. 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. 15. Alerts and Intrusion Detection Kismet will provide alerts based on fingerprints (specific netstumbler versions, other specific attacks) and trends (unusual probes, excessive disassociation, etc). Kismet focuses on the 802.11 (layer 2) network layer, and provides integration via named pipes with layer3+ IDS systems such as Snort. Alerts are primarily meant to be used in a stationary IDS situation. are potentially useful in a mobile/wardriving setup, but others may generate false or useless information. Alert name: Alert type: Alert on: WVE: Alert message: Tool-specific: References: Details: Some
Page 38 of 46
NETSTUMBLER Fingerprint Netstumbler probe requests WVE-2005-0025 "Netstumbler ($version) probe detected from ($macsource)" Yes (Netstumbler 3.22, 3.23, 3.30) http://www.netstumbler.com In an attempt to disclose the SSID of a network, Netstumbler sends out unique packets. This is not done in all situations, but when it is detected the potential for false positives is very low. DEAUTHFLOOD Trend Deauthenticate/Disassociate Flood WVE-2005-0019 WVE-2005-0045 WVE-2005-0046 WVE-2005-0061 "Deassociate/Deauthenticate flood on $targetbssid" No http://802.11ninja.net
Alert name: Alert type: Alert on: WVE:
Alert message: Tool-specific: References:
8/1/2011
Kismet
http://home.jwu.edu/jwright/papers/l2-wlan-ids.pdf By spoofing disassociate or deauthenticate packets, arbitrary (or all) clients can be disconnected from a network. This attack lasts only as long as the attacker maintains the flood. LUCENTTEST Fingerprint Lucent link test "Lucent link test detected from $sourcemac" Yes (Lucent/Orinoco site survey software) http://www.agere.com/wlan/customercare/ (requires login) Lucent/Orinoco/Proxim/Agere provide site survey software. This rule will generate an alert when it is in use. WELLENREITER Fingerprint Wellenreiter SSID brute force attempt WVE-2006-0058 "Wellenteiter probe detected from $sourcemac" Yes (Wellenreiter 1.5, 1.6) http://home.jwu.edu/jwright/papers/l2-wlan-ids.pdf http://home.jwu.edu/jwright/papers/wlan-mac-spoof.pdf Wellenreiter attempts to use a dictionary to brute-force a hidden SSID. Between each probe attempt it resets the card to probe for 'this_is_used_for_wellenreiter'. CHANCHANGE Trend Previously detected AP changing to a new channel WVE-2005-0019 "Beacon on $bssid ($ssid) for channel $newchannel, previously detected on $oldchannel" No Man-in-the-middle attacks attempt to direct users to a fake AP on another channel. If Kismet sees an AP change to a new channel, this is often suspicious behavior. BCASTDISCON Fingerprint Broadcast disconnect/deauthenticate WVE-2005-0019 WVE-2005-0045 WVE-2005-0046 WVE-2005-0061 "Broadcast [disassociation|deathentication] on $bssid" No Many attacks use a broadcast disassociate or deauthenticate to disconnect all users on a network, either to redirect them to a new fake network or do cause a denial of service or disclose a cloaked SSID. Broadcast disassociations are rarely, if ever, legitimate. AIRJACKSSID Fingerprint SSID of 'airjack' WVE-2005-0018 "Beacon for SSID 'airjack' from $sourcemac" Yes (airjack) http://802.11ninja.net/airjack/ The AirJack tools set the initial SSID to 'airjack'. This alert is no longer highly relevant as the AirJack tool has long been discontinued. PROBENOJOIN Trend Clients probing for networks, being accepted by that network, and continuing to probe for networks. "Suspicious client $sourcemac - probing networks but never joining."
Page 39 of 46
Details:
Alert name: Alert type: Alert on: Alert message: Tool-specific: References: Details:
Alert name: Alert type: Alert on: WVE: Alert message: Tool-specific: References: Details:
Alert Alert Alert WVE: Alert
name: type: on: message:
Tool-specific: Details:
Alert message: Tool-specific: Details:
Alert name: Alert type: Alert on: WVE: Alert message: Tool-specific: References: Details:
Alert name: Alert type: Alert on: Alert message:
8/1/2011
Kismet
Tool-specific: Details: No 'Active' or 'Firmware' network scanning tools work by letting the card probe for any network and recording those that respond. These tools include NetStumbler, PocketStumbler, and many others. Kismet raises this alert when a client is seen to be probing for networks but never joins any of the networks which respond. False positives are possible in noisy/lossy situations, disabling this alert may be desirable in some installations. DISASSOCTRAFFIC Trend Traffic from a source within 10 seconds of a disassociation WVE-2005-0019 WVE-2005-0045 WVE-2005-0046 WVE-2005-0061 "Suspicious traffic on $sourcemac: Data traffic within 10 seconds of a disassociate." No "802.11 Denial-of-Service Attacks: Real Vulnerabilities and Practical Solutions" 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 Fingerprint Probe response packet with 0-length SSID tagged parameter WVE-2006-0064 "Probe response with 0-length SSID detected from $sourcemac" No Many firmware versions from different manufacturers have a fatal error when they receive a probe response with a 0-length SSID tagged parameter. BSSTIMESTAMP Trend Invalid BSS timestamps indicative of an access point being spoofed. WVE-2005-0019 "Out-of-sequence timestamp on $bssid got $timestamp expected $timestamp - this could indicate AP spoofing" No The BSS timestamp sent with beacons and some probe frames cannot be spoofed with standard firmware or drivers even when forging raw frames. A BSS mismatch is likely an indication of an attempt to spoof the SSID and BSSID of an access point. This alert contains flap-detection to minimise false positives caused by random bogons and AP recycling. MSFBCOMSSID Signature MAC src address used as CPU instructions by MSF when exploiting the Broadcom SSID overflow WVE-2006-0071 "MSF-style poisoned exploit packet for Broadcom drivers" Yes Some versions of the Windows Broadcom wireless drivers do not properly handle over-long SSIDs, leading to code execution. LONGSSID
Page 40 of 46
Alert message: Tool-specific: References: Details:
Alert name: Alert type: Alert on: WVE: Alert message: Tool-specific: Details:
Alert name:
8/1/2011
Kismet
Alert type: Alert on: Alert message: Tool-specific: Details: Signature SSID advertised as greater than IEEE spec of 32 bytes "Illegal SSID length ($len > 32) from $srcmac" No The IEEE 802.11 spec allows a maximum of 32 bytes for the SSID, however the IE tag structure allows for 256. Oversized SSIDs are indicative of an attack attempting to exploit SSID handling. MSFDLINKRATE Signature Beacon frame with over-long 802.11 rates tag containing exploit opcodes WVE-2006-0072 "MSF-style poisoned 802.11 rate field in beacon $srcmac for D-Link driver attack" Yes Some versions of the Windows D-Link wireless drivers do not properly handle over-long 802.11 accepted rate fields, leading to code execution. MSFNETGEARBEACON Signature Large beacon frame containing exploit opcodes "MSF-style poisoned 802.11 over-sized options beacon $srcmac for Netgear driver attack" Yes Some versions of the Windows Netgear wireless drivers do not properly handle over-sized beacon frames, leading to remote code execution DISCONCODEINVALID | DEAUTHCODEINVALID Signature Unknown / reserved / invalid reason codes in deauth and disassoc packets "Unknown {disassociation | deauthentication } reason code 0x$rc from $sourcemac" No Various drivers and access points have been reported to improperly handle unknown/invalid reason codes.
Page 41 of 46
Alert Alert Alert Alert
name: type: on: message:
Tool-specific: Details:
Alert name: Alert type: Alert on: Alert message: Tool-specific: Details:
16. Reporting Bugs Bugs happen, and I'm sure some are still in the code. bug report: To make a useful
* Check the "Troubleshooting" section to make sure it's not a known user error * Check the development CHANGELOG to make sure it hasn't already been fixed in -devel. http://svn.kismetwireless.net/code/trunk/CHANGELOG If the bug appears to be tied to specific packets: * 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 If the bug happens otherwise: * 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 Some common problems with Kismet have easy solutions: PROBLEM: Fatal errors about old configuration file values
8/1/2011
Kismet
Kismet has evolved over time. This has made changes to the config files necessary, and obsoleted old options. Kismet will automatically detect old config files and alert on them. FIX: Upgrade your config files. 'make forceinstall' or 'forcesuidinstall' will replace old files, or you can copy the config file from the conf/ directory manually and update it for your configuration. PROBLEM: Fatal error about being unable to find the suiduser Kismet drops the privileges of the main packet processor to a specified user for security - handling hostile remote data as root is just a bad idea. If a nonexistent user is specified, Kismet will bail. FIX: Set a valid user as the suiduser config variable. If you're sure you don't want privilege dropping, you can run configure with the '--disable-setuid' option, but this is NOT reccomended for most users. PROBLEM: Fatal error about specifying a uid-0 target for suiduser Kismet needs to drop out of root for security purposes. If you tell it that the user to switch to is 'root' (or another uid-0 user, if you happened to make one), it can't do this. FIX: See fix above for errors about finding the suiduser. 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: Fatal error about being unable to open the pidfile FIX: By default Kismet writes the pid to /var/run/. If you didn't install Kismet as suidroot, you need to start it as root so it can write to this directory and bind interfaces. If you're only using capture sources that don't require root, you can change this in kismet.conf to put pidfiles in /tmp (or any other directory). This isn't reccomended if you use Kismet as root on a system with untrusted users. PROBLEM: Fatal error about interface no longer available, and DHCP FIX: Many distributions turn on DHCP for wireless interfaces. When DHCP is turned on and rfmon is used, one of two things happens: 1. rfmon is entered before DHCP gets an address. After approximately a minute, DHCP times out, and turns off the interface. 2. DHCP gets an address, but when the address expires, it is unable to renew it, and turns off the interface. MAKE SURE YOU DISABLE DHCP before starting Kismet - either turn it off entirely for that interface, or kill the client (usually dhclient, dhcpcd, or pump) before starting Kismet. Similar problems can occur if networkmanager is running and active while Kismet is running, as it will try to reconfigure the interface
Page 42 of 46
8/1/2011
Kismet
Kismet is using. If Kismet is compiled with DBUS support, it can automatically put networkmanager to sleep if the 'networkmanagersleep' variable is set to true in kismet.conf Be sure to also disable wpa_supplicant on any interfaces being used by Kismet, as it will try to reconfigure the device. PROBLEM: Configure is unable to find libncurses or other libraries, but they're installed. FIX: If you are running a RPM-based distribution, you will need the foo-devel.rpm packages for each library. These packages contain the headers needed to compile against the libraries. 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: I get 'invalid mode: monitor' or similar errors trying to go into rfmon with madwifi FIX: First, make sure you have madwifi-cvs. Second, make sure you're running a recent kernel. You need wireless extensions >= 15. To be safe, upgrade to the latest stable kernel. 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. PROBLEM: Kismet immediately exits on Cygwin with no output FIX: Cygwin appears to have a problem in the linker. If Kismet is linked to the CASE airpcap/winpcap libraries, they MUST be inside a sub-directory of the Kismet source for compilation. Recompile Kismet with the airpcap devpack inside the source directory. PROBLEM: Kismet stops capturing packets with Madwifi FIX: Madwifi seems to have a race condition of some sort which is exposed while hopping channels. Decreasing the channel hop rate may reduce the frequency of the failures, but will not entirely stop the channel. 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. Madwifi-ng development has switched to the Ath5k driver, which may perform better. 18. Frequently Asked Questions
Page 43 of 46
8/1/2011
Kismet
Page 44 of 46
Q: Where did the name Kismet come from? A: The word itself means Fate or Destiny. While I wish I could make up some smart comment about picking it because Kismet will ultimately uncover every active wireless network in the area, really I just needed a name and was clicking through a thesaurus and liked the sound. Q: Is there anything illegal about Kismet? A: In and of itself, there should be nothing illegal about Kismet, and it's no different than any other network capture tool. Note, however: - Recording data from networks for which you do not have permission may be considered an illegal wiretap. - Using networks you do not have permission to use may be considered theft of service. - Don't be stupid using Kismet. - If you are stupid, I'm not responsible. Q: What happened to the version numbers? A: They stopped making sense. 3.0 to 3.1 was a 30,000 line diff, but calling it 4.0 doesn't make sense either. So, it's getting versioned by the release date, which should also help keep stable releases coming in a timely manner. 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: Does Kismet work differently than NetStumbler? A: Absolutely. Netstumbler (and MiniStumbler, and others) work by querying the firmware of the card for networks the card has seen. While this method is obviously able to detect networks in the area, it is noisy (people can see you're running NetStumbler), it can't decloak hidden networks, and it can't record data. Q: Will Kismet work with Linuxant or NDISwrapper drivers? A: No. These wrappers use the Windows drivers, which don't support rfmon. Until there are native drivers with rfmon support, Kismet won't work with these cards. Q: What can I do to get you to support card 'xyz'? A: Kismet support of a card is largely dependant on available drivers with rfmon support. I'll be happy to get in touch with driver authors about support. 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: Why am I not seeing all the traffic on a network? A: You're most likely channel hopping. You can't see all the traffic on a channel if you're hopping, just like you can't see all of a show on TV if you're channel surfing. If you need to see all of the data from a single network, you'll need to disable hopping or lock Kismet onto the network you want to watch. Additionally, Kismet can only process packets which are passed by the drivers. Some drivers, firmware versions, and cards simply don't send all the data frames while in rfmon, and not much
8/1/2011
Kismet
can be done to solve that. Q: What about 802.11n? A: Some 802.11n cards with the Atheros chipset are supported, however currently the link type still appears as 802.11g. In theory these cards will work with the madwifi-ng capture sources. A2: Intel ABGN cards using iwlwifi should work. Q: Why do I get a lot of nonsense networks, or lots of networks that only have one data packet? A: Some drivers (currently the worst offenders are wrt54g, zd1211rw, and some versions of prism54) toss up garbage packets sometimes. Usually these are chunks of valid frames, several valid frames mangled together, valid frames with extra noise before them, etc. Kismet does the best it can to screen these out, but if the packet headers look like a data frame it will usually get past - management frames can be rigorously validated, but data frames could contain anything so they slip past. There isn't a really good solution to this, but you can turn on the 'autogroup_data' option in kismet_ui.conf to make them less intrusive. Q: What are the signal and noise levels measured in? A: Depends on the drivers. Firmware. Modes. In other words, who knows. Most cards and drivers don't do very well measuring signal levels in rfmon. Some, like Cisco, don't even give us a per-packet signal level. To make matters worse, signal levels are often quite binary - rarely will a signal dwindle to 10 or 20 as you travel away from the source. Beyond a certain point the radio is unable to assemble a packet out of the weak signal, and it will simply disappear. Generally speaking, a signal level of 200 is better than a signal level of 100, but individually the numbers don't have much relevance. They can be useful for coloring the maps as "better" and "worse", but thats about the most you should use them for. Q: Can Kismet be used in a commercial product? A: As long as you follow the requirements of the GPL, I can't stop you. It would certainly be nice if you're using Kismet to make a profit to take a look at my wishlist or make a donation though. Q: What about plugins? A: Yeah, I know, I'm working on them. A2: Look at newcore. After years of work, it will be releasing soon. Q: 'configure' says it can't find libncurses/libcurses A: First, did you install ncurses-devel? Kismet needs the development headers. Second, run 'ldconfig'. Some distributions (Fedora) seem to have an out-of-date library cache that means ld can't find the library. Third, make sure you installed the libstdc++/g++ packages. Configure will erroneously blame libncurses if the linkage with libstdc++ fails. Q: Configure failed on something else A: Look at config.log and see why it failed. Sometimes packages don't properly define all their dependencies and linking fails. 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: What are the SSIDs full of strange characters, like ^A^B^J^J^K^H? A: WindowsXP leaks bits of memory into the probe requests. These are legit packets, and thats whats really in them. Q: Why is the range of a network sometimes hundreds of miles inside Kismet, but normal in GPSMap? A: GPSMap does some moderately advanced filtering on data points which allows it to sift the data collected and clean out invalid samples. These methods require all of the sample points to be available, however, and won't work during a live capture. If the GPS reports a momentary invalid, but not wholly invalid, sample then Kismet will get confused.
Page 45 of 46
8/1/2011
Kismet
Q: How can I merge multiple capture files into one? A: Use ``mergecap'' that comes with Ethereal to combine dump files. 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. Q: What if configure can't find the linux wireless headers? A: Make sure you installed the kernel-headers package for your distro. Barring that, find the location of your kernel headers, and pass configure the directory with: ./configure --with-linuxheaders=/path/to/headers Q: Do I need wiretap support? A: Not really. Wiretap is only for specific situations (reading compressed packets, or reading packets captured by some different system like aironet. Generally speaking, you can just use the pcapfile capture type which is included with libpcap. Q: What cards work in *BSD? A: Any card with radiotap support should work in any of the BSD variants (Net, Open, or Free). Check your kernel docs and consider upgrading to the latest release to get more radiotap device support.. With the exclusion of OpenBSD, non-radiotap devices are not supported. If you want to add support for a non-radiotap card, contact me over email or IRC and I can help explain it. Q: Why can't I use prism2 or USB cards on Darkwin? A: Because I don't have patches for them. Send me some. Q: I want to port Kismet to (X) or I want to support card (Y) A: Kismet is designed to be fairly modular. Contact me over IRC or email and I can explain what parts need to be changed. Q: Why won't Kismet work on Windows? A: Because there are few legally unencumbered drivers for Windows. I am unwilling to risk the legal repercussions of attempting to leverage the commercial drivers from sniffer demos. Thanks to the efforts of CACE Tech, the AirPcap device is available for Windows with drivers designed to let OSS projects use the device legally. Kismet will now work with this device on Windows, however this is the ONLY local capture device which will work. Q: What happens when I ask a question thats already answered here? A: I'll probably be rude to you and tell you to go read the docs. But of course everyone already read the docs all the way to the end, right? Right?
Page 46 of 46
top
dragorn@kismetwireless.net
8/1/2011

HTTP WWW - Kismetwireless.net Documentation

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

HTTP WWW - Kismetwireless.net Documentation

Enviado por

Direitos autorais:

Formatos disponíveis

Kismet

Returns the *CAPABILITY

Stop sending a sentence.

PROBLEM: FIX: PROBLEM: FIX:

Alert name: Alert type: Alert on: WVE:

Alert message: Tool-specific: References:

Alert Alert Alert WVE: Alert

name: type: on: message:

Alert name: Alert type: Alert on: WVE:

Alert message: Tool-specific: Details:

Alert name: Alert type: Alert on: Alert message:

Alert name: Alert type: Alert on: WVE:

Alert message: Tool-specific: References: Details:

Alert Alert Alert Alert

name: type: on: message:

Você também pode gostar