forked from kismetwireless/kismet
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README.OLD
1707 lines (1359 loc) · 79.1 KB
/
README.OLD
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
******
nextgen-fields has just been merged into Kismet Master.
This is a major disruptive change to Kismet, and will present a bit more
thrash in git-dev than normal.
If you're looking for a stable Kismet build, grab a release tarball or grab
the Kismet-Stable git branch!
This is a major rewrite of how Kismet works, and will break any
third-party plugins as the API changes and solidifies.
This introduces the new web-based UI and removes the ncurses UI.
At the time of merge, text and xml logs are not functional. Support for
these logs will return as development continues.
There have been, and will continue to be, changes to the Kismet config files,
which are documented in:
README2 - Rewrite of this readme file, currently focused on the new GPS
and web options
README.SSL - Using SSL with the Kismet webserver interface
Developer documentation for the new API is in the docs/dev/ directory!
******
*OLD* readme to follow.
******
Kismet 2016-01-R1
Mike Kershaw <dragorn@kismetwireless.net>
http://www.kismetwireless.net
1. What is Kismet
2. Upgrading from earlier versions
3. Quick start
4. Suidroot & security
5. Capture sources
6. Caveats & quirks for specific drivers
7. Supported capture sources
8. Plugins
9. GPS
10. Logging
11. Filtering
12. Alerts & IDS
13. Server configuration options
14. Kismet UI
15. Kismet drones
16. Talking to Kismet
17. Troubleshooting
18. Frequently asked questions
1. What is Kismet
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
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
* 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.
* 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 Custom name for the source (otherwise it will be
named the same as the capture interface). This is
completely arbitrary and meaningful only to the
user.
type=foo Sources which can not autodetect the type must have
the type specified. This is rarely necessary.
Additional information on supported source types
follows.
uuid=foo Users wishing a static unique identifier on sources
may specify one here. This is not necessary for
most users. UUID is of the format:
XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
hop=true|false Disable channel hopping on this source. Default
behavior is for channel sources to hop channels to
cover the entire spectrum.
velocity=# Channel hop velocity (number of channels per
second), Kismet can hop 1-10 channels per second.
dwell=# Channel dwell time, the number of seconds Kismet
will wait on each channel. If hopping is enabled
and a channel dwell time is specified, Kismet will
hop at N seconds per channel, instead of N channels
per second.
channellist=name Use an alternate channel list instead of the
autodetected list of channels supported by this
interface. The channellist must be defined.
split=true|false When multiple sources use the same channel list
(either autodetected or by the channellist= option)
Kismet will split them so that they do not cover the
same channels at the same time. Sources can be
forced to ignore this and begin hopping at the
beginning of the channel list regardless of overlap.
retry=true|false Kismet will attempt to re-open a capture source
which has encountered an error. This behavior can
be disabled if the user wants the source to remain
closed.
vap=interface Create a secondary named interface for capture
instead of trying to change the mode of the
existing interface. This is primarily only for use
by drivers using the mac80211 interface under
Linux. Users wishing to do Kismet+Managed or
Kismet+Injection should create a vap.
forcevap=t|f True/False. Force creation of a monitor-mode VAP
when possible (all Linux mac80211 based drivers
support this). Default is "true", a VAP will be
made of the name '<interface>mon', ie 'wlan0mon',
'wlan1mon' and capture will be done with this VAP.
This behavior can be forced OFF with
'forcevap=false'.
wpa_scan=time When using a mac80211 VAP, Kismet can use
wpa_supplicant on a managed interface to trigger
hardware assisted scans, enabling some view of the
rest of the spectrum without significantly
disrupting operation of the managed VAP. Suggested
time for scan intervals is 15 seconds.
validatefcs=t|f True/False. Kismet normally will not bother trying
to validate the FCS checksum of incoming packets
because most drivers only report valid frames in
the first place. Packet sources which report
invalid frames by default will enable this option
automatically. If the drivers have been manually
configured to report invalid packets, this should
be specified to prevent Kismet from processing
broken packets.
fcs=true|false Force handling of FCS bytes on a packet source.
Default is "false", which implies "native FCS
handling". Packet sources which include per-packet
headers like radiotap or PPI will ignore this value
as the FCS is encoded in the radio header. Packet
sources such as pcapfile, reading raw 802.11 pcap
files with no headers, may need this turned on for
proper behavior.
fcsfail=true Force a mac80211 VAP to report packets with a known
bad FCS (packet checksum). This is only available
on Linux and only when using mac80211 drivers.
This MUST come after a 'vap=' option or it will be
ignored. Enabling 'fcsfail' will enable
'validatefcs' automatically. The 'fcsfail' option
should only be enabled when logging to PPI; Logging
to normal PCAP will not preserve the FCS data and
will produce unreadable output.
WARNING: With some driver versions, enabling this
seems to cause kernel OOPS warnings and the
interface will become unresponsive if capture is
stopped and resume. This option is for specific
expert use only, when in doubt, leave it alone.
plcpfail=true Force a mac80211 VAP to report packets which do not
pass the PLCP check (if possible on that
interface). The same warnings and conditions as
'fcsfail' apply. This option is for specific,
expert use only, when in doubt, leave it alone.
ignoreprimary=t Ignore the state of the primary interface on
mac80211. Normally, Kismet will shut down the
main interface (ie wlan0, wlan1) to prevent wpasupp
or NetworkManager from changing the channel, etc.
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. For greater
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. Kismet will not hop
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
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.
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
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 Kernel adm8211 driver
acx100 Kernel acx100 driver
hostap Kernel prism2 driver
ipw2100 Kernel Intel 2100 driver
ipw2200 Kernel Intel 2200 driver
ipw2915 Kernel Intel 2915 driver
ipw3945 Kernel intel 3945 driver
mac80211 Generic mac80211 catch-all source for any mac80211
drivers.
madwifi Madwifi/Madwifi-ng
madwifi_a Alias for madwifi, default 802.11a channels
madwifi_b Alias for madwifi, default 802.11b/g channels
madwifi_g Alias for madwifi, default 802.11b/g channels
madwifi_ag Alias for madwifi, default 802.11abg channels
nokia770 Conexant-based driver in Nokia Maemo tablets
nokia800 Alias for nokia770
nokia810 Alias for nokia770
nokiaitt Alias for nokia770
pcapfile Pcap-formatted previously recorded file
rt2870sta Out-of-kernel/Staging rt2870 11n driver (use
in-kernel instead)
wl12xx Patched wl12xx drivers for the N900, must use
patched drivers from http://david.gnedt.eu/blog/,
otherwise autodetected.
drone Remote Kismet packet capture, source options
"host=..." and "port=..." are required.
ncsource=drone:host=localhost,port=2502
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 Generic BSD capture source, default 802.11b/g channels
radiotap_bsd_g Default 802.11b/g channels
radiotap_bsd_a Default 802.11a channels
radiotap_bsd_ag Default 802.11abg channels
pcapfile Pcap-formatted previously recorded file
drone 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
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)
airpcap_ask List available sources and ask which one to use.
Should NOT be used when launched by the Kismet UI.
pcapfile Pcap-formatted previously recorded file
drone Remote Kismet packet capture, source options
"host=..." and "port=..." are required.
OSX/Macintosh Capture Sources:
darwin Any device controlled by the Airport IOKit drivers
under OSX. Default 802.11b/g channels.
pcapfile Pcap-formatted previously recorded file
drone Remote Kismet packet capture, source options
"host=..." and "port=..." are required.
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 Git 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).
"Restricted" plugins, which provide potentially invasive behavior such
as auto-guessing WEP based by the SSID or automatically running the PTW
WEP attack against captured data can be compiled and installed with:
make restricted-plugins
make restricted-plugins-install
-or-
make restricted-plugins-userinstall
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.
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. For
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 or Kismet otherwises looses
its connection, it will be re-established. Gpsmodelock compensates for
certain broken GPS/GPSd combinations, where the GPS never reports a
valid lock. By forcing a gpsmodelock=true, Kismet assumes the GPS
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.
Logs are controlled by the --log-types command-line option or the
logtypes= config file line. Logs are enabled by name (nettxt, gpsxml,
etc) or by class (text, pcap, etc). When enabled by class, Kismet will
enable all logs of that class. For example, enabling 'pcap' will turn
on pcap logging for plugins which can save packets.
Supported log classes:
alert IDS alerts
gps GPS data (xml)
text Text-formatted records (nettxt, etc)
xml XML-formatted records (netxml)
pcap Pcap-formatted packet logs
string Discovered strings
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
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
%T Starting time, HHMMSS
%i Incremental, in the case of multiple logs of the same name
%I Incremental, padded with zeroes (00001)
%l Log type (pcapdump, netxml, etc)
%h Home directory of the user Kismet was started as
The 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. To exclude
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
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:
ADVCRYPTO Trend/Stateful 802.11
An 802.11 AP changed advertised encryption options. This
may be a normal configuration change (though unlikely) or it
may indicate a spoofed AP which did not correctly clone the
original.
AIRJACKSSID Fingerprint 802.11 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 802.11
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).
BEACONRATE Trend/Stateful 802.11
An 802.11 AP changed advertised beacon rates. This may be
a normal configuration change (though unlikely) or it may
indicate a spoofed AP which did not correctly clone the
original.
BSSTIMESTAMP Trend/Stateful 802.11
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 802.11
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