Kismet Wireless

Kismet Forums


Posted by:theberries
Subject:What source captured the signal?
Date:11:10:21 11/09/2008

I replied to an older post but I wanted to bump the original in case it was burried and never saw the light of day:

> > I've just completed installing a number of kismet drones, and have them all configured properly and working very nicely with Kismet-2006-04-R1. They are apparently all seeing a variety of networks.
> >
> > The purpose of the separate drones is for rogue access point detection, and the drones are spread out over several buildings, across several towns connected through a wide area network.
> >
> > The problem I'm encountering is, that when a new AP is detected, is shows up in the display on my server, but I'm unable to tell what drone picked it up as a source! I've looked at kismet_ui.conf and kismet.conf to see if I'm missing anything, and I'm not having much luck.
> >
> > Aside from stopping the server, and disabling the drone sources one by one and restarting the server each time (to only use one drone at a time), is there a better way to determint the source? Part of my asking, is that if a rogue AP is discovered and is cloaked, a signifigant amount of time may pass before a client assicoates to the rogue, and thus a long time before kismet obtains ssid information....
> >
> > So, to make a long question short, is there an easy way with kismet server to determine which source an AP was discovered on?
> Currently, no. Drones present a highly interesting problem -- in newcore, capture interfaces are exported upstream to the server from the drones, however there is no restriction on multiple interfaces having the same name on different drones. Each interface DOES have a globally unique identifier (using the standard UUID system which combines the MAC of the capture interface, if it has one, a time component, and a fairly high-quality random component), however these change each time the source is created -- so a drone which is rebooted will have a different UUID for the interface when it comes back up.
> I've considered keeping some sort of state file in the ~/.kismet/ directory which would let it map UUIDs to names and keep a consistent UUID for the interface, so long as it exists in the state file. I'm not sure there is any reason NOT to do this, although there are interesting issues still -- strange things would happen if you changed cards but kept the same name, since any records on the server side about what sort of card it is would change halfway through.
> A similar problem exists trying to define a new pcap file packet format -- adding source and removing them runtime can lead to strangeness in logging, since it would change the header and resize the front of the capture file.
> -m

So I'm trying to implement a WIDS much like the OP. Multiple WRT54G drones spread out accross an organization. I'd like to pipe the results of the server to a snort instance and build a front-end to that. Or even for that matter, a custom client that will give me real-time info AND query a database and display the resulting alerts/messages.

The issue I'm having is that I cannot distinguish or deduce by what drone or source an SSID or client is captured on. Ideally, I could use that UUID you mentioned and tie that to each new discovery. Even more ideally, the log/pipe output would have the UUID/capture name/IP address of the drone associated with the entry being sent. All this, of course, being piped into snort/written to a log then converted to a mysql database.

Another issue I have is the broadcom drivers not reporting signal strength on the WRT54G's. Hopefully the B43 drivers will fix this but the Kamakazi release of OpenWRT hasn't successfully incorporated them in their release. However, deducing down to a couple or so drones where a rougue is coming from would be nice.

Like the original OP said, cycling the kismet server and drones would be a huge pain.

Any help is greatly appreciated.


Reply to this message