Kismet 2004-10-01 Mike Kershaw <dragorn@kismetwireless.net> http://www.kismetwireless.net Licensed under the GPL 1. What is Kismet 2. Feature Overview 3. Typical Uses 4. Upgrading From Previous Versions 5. Suidroot & Security 6. Required Libraries & Utilities 7. Compiling 8. Configuration 9. Panels Interface 10. Operating Systems 11. Capture Sources 12. Graphical Network Mapping 13. Drone Remotes 14. Intrusion Detection 15. Troubleshooting 16. Frequently Asked Questions 1. 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, and 802.11g traffic. Kismet identifies networks by passively collecting packets and detecting standard named networks, detecting (and given time, decloaking) hidden networks, and infering the presence of nonbeaconing networks via data traffic. 2. Feature Overview Kismet has many features useful in different situations for monitoring wireless networks: - 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 - Over 20 supported card types 3. 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. 4. Upgrading from Previous Versions Upgrading to Kismet 3.1+: Kismet 3.1 has significantly changed how Kismet operates again. There have been config file changes, changes to the names of capture types, and various other mayhem. Be sure to upgrade your config file or things will definitely not work how you expect them to. 5. 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 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 convienent. 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. 6. Required Libraries & Utilities Kismet is primary self-contained, however for some features it requires some external libraries or utilities. - GPSD (any version): http://russnelson.com/gpsd/ 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 on a remote host. The latest versions of GPSD fix compile issues which occured on some systems and it's highly reccomended you get the latest. GPSDrive distributes an alternate version of GPSD, which should work with Kismet. - 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 IMs 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. - Ethereal (any): http://www.ethereal.com REQUIRED for wtapfile capture replay Ethereal is the premier packet dissector. The packet dump logs Kismet creates can be opened in Ethereal for further examination. Kismet uses libwiretap from Ethereal for saving packet dump files and replaying stored dumps, however Kismet has a builtin dump writer and can replay pcap files using libpcap. Kismet requires a compiled copy of the Ethereal source available to link the libwiretap library. By default the configure script will look in /usr/src/ for this. If you do not need to replay compressed dumps or dumps with other encodings (such as Airopeek), you don't need wtapfile. 7. 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. Download any libraries and external utilities needed 2. Run './configure' with any special options you want (see './configure --help') 3. Run 'make' or 'gmake' 4. 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. 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 8. 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 'variable=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. 2. Set up the capture sources. Most users will only need one, but it is possible to have any number of sources defined which will be combined into a single packet log. Sources are defined with the 'source' directive. Source lines are defined with 'source=type,interface,name[,channel]'. See the section 'Capture Types' 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. 3. 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 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. 5. Set the log template. By default, Kismet writes logs to the directory it is started in. By putting a full path into the 'logtemplate' directive you can force it to write them to another location (such as a directory guaranteed to be writeable by the target suiduser). Client configuration: 1. Set the host and port. By default, Kismet is configured to connect to the localhost and standard port. 2. Set columns to be displayed. The default set should be fine for most but it can be changed/expanded. Columns can be scrolled in the client with the arrow keys. 3. Set a sound player. For most, 'play' from Sox (the default) should be fine. If you use a sound daemon such as esd or ksd you will need to change the play command to call esdplay or similar. 4. Configure speech (or not). Kismet can write to Festival for speaking information about networks. 5. Customize colors. Most components of the Kismet panels UI can be colorized. The annoying popup window that opens every time you start the client can be disabled by setting 'showintro' to 'false' in your kismet_ui.conf. More advanced server configuration: * IDS alert rates can be controlled via the 'alert' directive, which specifies the alert type, rate per timeframe (ie, 5/min), and the burst limits. These controls are similar to the iptables limit controls. * Networks with known WEP keys can be decrypted 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. Once filters are enabled they control what packets are allowed through. To allow all packets NOT specified, invert the filter with '!'. Filtering can be done on address types (ANY, SOURCE, DEST, and BSSID), and can be inverted. For example, to exclude all packets from a given MAC, 'filter_tracker=ANY(!00:11:22:33:44:55)'. To include only one network, filter by BSSID - 'filter_tracker=BSSID(00:11:22:33:44:55)' Multiple filters can be chained together on one line with a ','. 'filter_tracker=ANY(..),BSSID(!...)' * 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. * 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. 9. 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 '.' based on network activity 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 name Name of the network or group noise Last seen noise level packets Total number of packets shortname Shortened name of the network or group for small displays shortssid Shortened SSID for small displays signal Last seen signal level signalbar Graphical representation of signal level size Amount of data transfered on network ssid SSID/ESSID of the network or group type Network type (Probe, Adhoc, Infra, etc) weak Number of packets which appear to have weak IVs wep WEP status (does network indicate it uses WEP) The clients window has a similar selection of columns which can be enabled: crypt Number of encrypted data packets transfered by client data Number of data packets transfered by client decay Displays '!', '.', or ' ' based on network activity ip Last seen IP used by client mac MAC address of client manuf Manufactuer of client (if known) maxrate Maximum rate client seen transfering noise Last seen noise level of client signal Last seen signal level of client size Amount of data transfered by client type Type of client (Established, To-DS, From-DS, etc) weak Number of packets which appear to have weak IVs 10. 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: ACX100, ADMTek, Atheros, Cisco, Prism2, Orinoco, WSP100, Drone, wtapfile, pcapfile, wrt54g, ipw2100 Kismet will work with any distribution of Linux. Currently, Linux is the reccomended platform for running Kismet because it has the largest selection of rfmon capable drivers. - OpenBSD Known supported cards: Prism2, WSP100, Drone, wtapfile, pcapfile 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. Performance with other cards may be varied. - 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 to get mutlidlt support. - NetBSD Known supported cards: WSP100, Drone, wtapfile, pcapfile There have been no reports positive or negative about NetBSD drivers. Please email if you have them working. - MacOSX Known supported cards: Airport, WSP100, Drone, wtapfile, pcapfile MacOSX is supported for Airport (classic) cards only, using the Viha drivers at http://www.dopesquad.net/security/. There are no rfmon drivers available for Airport Extreme cards currently. 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, wtapfile, pcapfile Win32 ONLY works with remote captures. There are no public rfmon drivers for win32, and no reports of any in development. Kismet on Win32 requires cygwin for the Posix layer. Don't use win32 if you want to capture data natively. 11. 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. Source type Cards OS Driver --------------- ------------------- ----------- ------------------------- acx100 TI ACX100 Linux ACX100 http://acx100.sourceforge.net/ Capture interface: 'ethX' ACX100 drivers handle the 22mbit cards branded by DLink and others. admtek ADMTek Linux ADMTek http://www.latinsud.com/adm8211/ 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 always in a rfmon-like state. This card WILL BROADCAST while in rfmon, rendering the sniffer visible. cisco Aironet 340,350 Linux Kernel 2.4.10 - 2.4.19 Capture interface: 'ethX' Standard Cisco cards in Linux. Works only with the Linux kernel drivers, not the drivers found on cisco.com or pcmcia-cs. 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. cisco_openbsd Aironet 340,350 OpenBSD Kernel Capture interface: 'anX' OpenBSD cisco drivers are not fully supported currently, but may become so. Packet capture probably will not work correctly. hostap Prism/2 Linux HostAP 0.4 http://hostap.epitest.fi/ Capture interface: 'wlanX' 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. ipw2100 Intel/Centrino Linux ipw2100-0.44+ http://ipw2100.sourceforge.net/ Capture interface: 'ethX' The Linux IPW2100/Centrino drivers for 802.11b cards now support rfmon, so heres support for them. They act more or less like any other wireless interface would. THIS IS NOT FOR WINDOWS OR FOR SYSTEMS USING NDISWRAPPER OR LINUXANT. kismet_drone n/a Any n/a Capture interface: 'dronehost:port' The remote drone capture source connects to a Kismet drone and proceses the packets. Refer to the Remote Drone section of the README for more details about how to set up a drone. madwifi_a Atheros Linux madwifi-cvs http://sourceforge.net/projects/madwifi/ Capture interface: 'athX' Madwifi drivers in 802.11a-only mode. madwifi_b Atheros Linux madwifi-cvs http://sourceforge.net/projects/madwifi/ Capture interface: 'athX' Madwifi drivers in 802.11b-only mode. madwifi_g Atheros Linux madwifi-cvs http://sourceforge.net/projects/madwifi/ Capture interface: 'athX' Madwifi drivers in 802.11g-only mode. This will, obviously, also see 11b networks. madwifi_ab Atheros Linux madwifi-cvs http://sourceforge.net/projects/madwifi/ Capture interface: 'athX' Madwifi drivers in 802.11a and 802.11b combo mode. This will seamlessly switch between bands during channel hopping. madwifi_ag Atheros Linux madwifi-cvs http://sourceforge.net/projects/madwifi/ Capture interface: 'athX' Madwifi drivers in 802.11a and 802.11g combo mode. This will seamlessly switch between bands during channel hopping. orinoco Lucent, Orinoco Linux Patched orinoco_cs http://airsnort.shmoo.com/orinocoinfo.html Capture interface: 'ethX' The standard orinoco_cs drivers do not support monitor mode but they work well after being patched with the above. As of Feb, 2004, the CVS tree and 2.6 kernels include monitor mode, but require the new orinoco source. orinoco_14 Lucent, Orinoco Linux Orinoco 0.14+, Kernel 2.6+ https://savannah.nongnu.org/projects/orinoco/ Capture interface: 'ethX' The new orinoco_cs drivers changed things subtly, but at least they include rfmon without patching. Patches to enable signal level reporting are available on the kismet download site. pcapfile 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. prism2_openbsd Prism/2 OpenBSD Kernel Capture interface: 'wiX' Full support for Prism2 under OpenBSD prism54g PrismGT Linux prism54 http://www.prism54.org Capture interface: 'ethX' PrismGT 802.11g drivers supporting monitor mode. radiotap_fbsd_ab Atheros FreeBSD Kernel Capture interface: 'athX' FreeBSD dual-band cards with radiotap headers (currently only Atheros) radiotap_fbsd_a Atheros FreeBSD Kernel Capture interface: 'athX' FreeBSD 802.11a cards (or dual-band on 11a channels only) with radiotap headers (currently only Atheros) radiotap_fbsd_b Atheros FreeBSD Kernel Capture interface: 'athX' Capture interface: 'wiX' FreeBSD 802.11b cards (or dual-band on 11b channels only) with radiotap headers (Currently Atheros or Prism2) viha Airport OSX viha http://www.dopesquad.net/security/ Capture interface: 'enX' Monitor mode support for Airport under OSX. Does not support Airport Extreme. 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. wlanng_legacy Prism/2 Linux wlan-ng 0.1.3 and earlier http://www.linux-wlan.com/ Capture interface: 'wlanX' 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). wlanng Prism/2 Linux wlan-ng 0.1.4 - 0.1.9 http://www.linux-wlan.com/ Capture interface: 'wlanX' Wlan-ng prism2 drivers prior to the AVS headers. wlanng_avs Prism/2 Linux wlan-ng 0.2.0+ http://www.linux-wlan.com/ Capture interface: 'wlanX' Newer wlan-ng drivers support a new header type and slightly different monitor commands to report wepped packets. wrt54g Linksys WRT54G Linux linksys http://seattlewireless.net/index.cgi/LinksysWrt54g Capture interface: 'ethX' Support for the drivers found in the embedded Linux inside the Linksys WRT54G (and probably other APs using the same firmware). wsp100 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. wtapfile n/a Any n/a Capture interface: '/path/to/file' Wtapfile sources are the same as pcapfile sources but they use the Ethereal libwiretap loader. libwiretap can automatically decompress gzipped files, etc. Wtapfile sources are only available if Kismet was compiled with libwiretap support. Chipsets known to NOT WORK: Broadcom - No linux drivers, only useable with ndiswrapper or linuxant wrappers around windows drivers. Airport Extreme - Really a Broadcom, with no rfmon in the OSX drivers. Atmel - The USB firmware has no rfmon feature. The pcmcia firmware -may-, but the drivers don't support it. Realtek - Cards seem to be primarily software-driven, no support in the drivers. HermesII - Proxim successor to the Orinoco/HermesI. No support yet in the drivers, may be available in the future. 12. 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. GPSMap currently can use maps from: NullMap (Blank white background) MapBlast (Vector) MapPoint (Vector) (Broken, read warning) Terraserver (Satellite Photo) Tiger (Vector) (US Census data) Earthamap (Vector) (Requires perl) Terraserver Topo (Vector-ish) Due to changes in the map websites, MapPoint cannot be used with new maps. These sources are left in GPSMap only for plotting previously kept map images, and they will fail if they are selected and a user map is not available. Earthamap map fetching requires prefetching a cookie from the website. This is automated through the gpsmap-helper-earthamaps script, which requires Perl, HTTP::Cookies, and Perl::LWP to be installed. All of these map sources rely on external data. By using them, you agree to whatever terms and conditions the map provider requires. Visit the map providers website for these conditions. 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. 13. 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 cardsource pointing to that host, start kismet_server, and use whatever client you like to connect to it. 14. 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. Some are potentially useful in a mobile/wardriving setup, but others may generate false or useless information. Alert name: NETSTUMBLER Alert type: Fingerprint Alert on: Netstumbler probe requests Alert message: "Netstumbler ($version) probe detected from ($macsource)" Tool-specific: Yes (Netstumbler 3.22, 3.23, 3.30) References: http://www.netstumber.com Details: 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. Alert name: DEAUTHFLOOD Alert type: Trend Alert on: Deauthenticate/Disassociate Flood Alert message: "Deassociate/Deauthenticate flood on $targetbssid" Tool-specific: No References: http://802.11ninja.net http://home.jwu.edu/jwright/papers/l2-wlan-ids.pdf Details: 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. Alert name: LUCENTTEST Alert type: Fingerprint Alert on: Lucent link test Alert message: "Lucent link test detected from $sourcemac" Tool-specific: Yes (Lucent/Orinoco site survey software) References: http://www.agere.com/wlan/customercare/ (requires login) Details: Lucent/Orinoco/Proxim/Agere provide site survey software. This rule will generate an alert when it is in use. Alert name: WELLENREITER Alert type: Fingerprint Alert on: Wellenreiter SSID brute force attempt Alert message: "Wellenteiter probe detected from $sourcemac" Tool-specific: Yes (Wellenreiter 1.5, 1.6) References: http://home.jwu.edu/jwright/papers/l2-wlan-ids.pdf http://home.jwu.edu/jwright/papers/wlan-mac-spoof.pdf Details: 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'. Alert name: CHANCHANGE Alert type: Trend Alert on: Previously detected AP changing to a new channel Alert message: "Beacon on $bssid ($ssid) for channel $newchannel, previously detected on $oldchannel" Tool-specific: No Details: 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. Alert name: BCASTDISCON Alert type: Fingerprint Alert on: Broadcast disconnect/deauthenticate Alert message: "Broadcast [disassociation|deathentication] on $bssid" Tool-specific: No Details: 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. Alert name: AIRJACKSSID Alert type: Fingerprint Alert on: SSID of 'airjack' Alert message: "Beacon for SSID 'airjack' from $sourcemac" Tool-specific: Yes (airjack) References: http://802.11ninja.net/airjack/ Details: The AirJack tools set the initial SSID to 'airjack'. Alert name: PROBENOJOIN Alert type: Trend Alert on: Clients probing for networks, being accepted by that network, and continuing to probe for networks. Alert message: "Suspicious client $sourcemac - probing networks but never joining." Tool-specific: No Details: '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 desireable in some installations. Alert name: DISASSOCTRAFFIC Alert type: Trend Alert on: Traffic from a source within 10 seconds of a disassociation Alert message: "Suspicious traffic on $sourcemac: Data traffic within 10 seconds of a disassociate." Tool-specific: No References: "802.11 Denial-of-Service Attacks: Real Vulnerabilities and Practical Solutions" Details: As discussed in the above research paper by Bellardo, J. and Savage, S., a host which legitimately disassociates or deauthenticates from a network should not be exchanging data immediately thereafter. Any client which DOES exchange data within 10 seconds of disassociating from the network should be considered a likely victim of a disassociate attack. Alert name: NOPROBERESP Alert type: Fingerprint Alert on: Probe response packet with 0-length SSID tagged parameter Alert message: "Probe response with 0-length SSID detected from $sourcemac" Tool-specific: No Details: Many firmware versions from different manufacturers have a fatal error when they receive a probe response with a 0-length SSID tagged parameter. Alert name: BSSTIMESTAMP Alert type: Trend Alert on: Invalid BSS timestamps indicative of an access point being spoofed. Alert message: "Out-of-sequence timestamp on $bssid got $timestamp expected $timestamp - this could indicate AP spoofing" Tool-specific: No Details: The BSS timestamp send 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. 15. Troubleshooting Some common problems with Kismet have easy solutions: PROBLEM: Fatal errors about old configuration file values 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. 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. 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: I get 'Could not set SSID, I/O error' going into monitor mode on prism54 cards FIX: Update to the latest CVS release of the prism54 driver. PROBLEM: Kismet can't enter monitor mode using MadWifi FIX: The CVS version of the MadWifi drivers are needed for rfmon. Additonally, you need kernel 2.4.23 or newer because of wireless extention dependencies. Make sure to upgrade your drivers and kernel. 16. Frequently Asked Questions 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 its 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. 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, madwifi, 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 tavel away from the source. Beyond a certian point the radio is unable to assemble a packet out of the weak signal, and it will simply dissapear. 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 certianly 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. 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: Compiling fails on OSX with undefined variables in pcapsource.cc A: Re-run configure with --without-pcap to bypass this. Viha doesn't use pcap, so you won't lose functionality. 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. 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 reccomended for lowpower systems. Q: What happens when I ask a question thats already answered here? A: I'll probably be rude to you and tell you go to go read the docs. But of course everyone already read the docs all the way to the end, right? Right?