Recently I have been wanting a wireless IDS (WIDS) to detect nefarious wifi activity. I also had a Beaglebone Black hanging around that I wanted to put to good use. This seemed like a perfect match, and indeed it seems to be so!
I did some research on WIDSs, and although there is SUPPOSED to be several out there, nearly all that I seemed to find was commercial and Windows-based products, not something I could use myself.
About the only exception to that rule was Kismet, so I decided to give that a try. Kismet is supposed to work as a WIDS, and per its documentation should catch the following attacks:
It is obvious that a lot of these attacks are old and irrelevant any longer, but some of them are still good. Some of the alerts I wanted to catch were Rogue APs, Reaver Attacks, DoS attacks, and client disassociations. It looked like Kismet might be able to do most of those.
To install Kismet on the Beaglebone, I downloaded Ubuntu 13.04 from here:
I put this image on a card, and booted it up. Since I wanted my WIDS to be headless, I added "service ssh start" in the /etc/rc.local file.
I wanted to use the entire Beaglebone SD card, so I repartitioned the card to use all available space. This was basically running fdisk, deleting the #2 partition, and adding it back with the defaults.
-p (look at partition table)
-d (delete a partition)
-2 (partition number to delete)
-p (show the new partition table with the old partition missing)
-n (make a new partition)
-p (make it a primary partition)
- (give it the same number that was previously deleted)
-default starting point
-default ending point
-p (show the changes)
-w (if all looks good, write the changes to disk)
I edited the /etc/network/interfaces to give the Bone a static IP so I could reach it through SSH.
- iface eth0 inet static
- to prepare for kismet, I had to add a bunch of dependencies:
- apt-get install g++, libpcap-dev, libncurses-dev, libnl-dev, make
- make dep
- make, make install
- since I was going to run Kismet headless, and I wanted to be able to see the kismet "GUI" through ncurses yet still be able to get to the terminal to do stuff while kismet was running, I installed 'screen.'
- apt-get install screen
- I could then ssh into my Bone, type 'screen bash' and screen would be running. Then, when I start kismet, I can type '
d' to detach from that window and bring up a new terminal window. I can log out and everything and kismet will keep running in a background screen. If I ever want to get back into the running kismet, I just type 'screen -r' and I'll return to the kismet screen. I love screen!
- I downloaded kismet-2010-07-R1.tar.gz and unzipped it, untarred it, and ran make and make install.
- I tried Kismet, and it worked like a champ! But of course, it's configuration needed some tweaking for a WIDS (vs a packet capture system and such).
- I edited the /usr/local/etc/kismet.conf file
- I edited the "apspoof" for the SSIDs on my LAN (added their MACs)
Next came the testing!
I put up a Rogue AP, and WHAM! Kismet caught it perfectly.
I disassociated all the wireless clients on my AP, and POW! Kismet caught that perfectly as well.
However, when I disassociated a single client, something I would typically do in order to get a handshake on a WPA-protected network, this slipped right by! That was unacceptable.
I looked through the source code, and found the rule that Kismet makes for that alert. With a couple of quick edits, I made a rule for a single client disassociation.
Basically, I saw that the kismet.conf file had a BCASTDISCON field for the alert in question. I copied that to make an alert called CLIENTDISASS. I also looked where this was called, and I noticed references to 'bcastdcon.' So I also copied the references from 'bcastdcon' to 'clientdisass.' In total, I edited only 4 files! These were (from the kismet directory) conf/kismet.conf, conf/kismet.conf.in, netracker.cc, and netracker.h. Here's what I made them (the changes are clearly visible):
conf/kismet.conf and conf/kismet.conf.in (they were the same):
I then tested it. Kismet caught single client disassociation attacks as well as broadcast disassociations! Here's a screenshot of Kismet alerting on (from the bottom up) a Rogue AP, a broadcast disassociation, and a client disassociation:
I tried a few Reaver attacks, and they seem to give off the same 'Client deauthentication/disassociation' alerts that a deauth of a client gives. I think that this is because when the Attacker attempts to connect to an AP it legitimately gets kicked off by the real AP, triggering the deauth alert. Since none of my APs are vulnerable to a Reaver attack, this seems like an alert that I can live with for now. I'll need to put up a vulnerable AP to do some more testing if I want to refine this alert.