- tags
How to track your coworkers
Simple passive network surveillance
- tags
- toys
- ruby
- redis
Contents
How much information do you bleed?
Ever wonder who is else is using your network? Or,who has actually showed up at the office?
Networking primer
The simplest thing we can do to make this work is to check to see which devices have registered themselves on the network. As devices come and go, they connect automatically, so we will have a pretty good idea if people are there or not. Phones seem to attach and detach quite frequency, probably to conserve battery, so if we are want to answer the question “is so-and-so in the office” we’ll need to add additional logic to determine how far spaced the “sighting” events are to mean that the person has left the office, rather than the phone has gone to sleep.
There are a couple of ways to do this. One is to log on you your router and look at the DHCP routing tables to see which devices have leased an IP address. Have you looked at those router webpages though? Pretty gross. You’d need to do some scraping, something different for each of the router types, all together pretty gross.
Another thing to consider is DNS multicast, also called Bonjour or zero-config networking. This is pretty much the standard now for services announcing themselves on the human-used networks. (Server rooms have fancier service discovery mechanisms.) If you want to find a printer, or someone else’s iTunes library it works great, but it doesn’t do much for phones.
We are going to do this using ping. This is simple and works everywhere.
The plan
The code below using ruby and redis to track which devices have been seen. You’ll need to have redis installed and running for this code to work, but it should be easily portable to any Unix system, not just OSX. So if you have a RaspberryPIlaying around, it would be run to run it on there.
This code does the following things:
- Find the local broadcast address. This is normally
192.168.1.255on home routers but could be anything. - Send 4 pings to the broadcast address and listen for replies. It may take some time to return back,which is why we have multiple pings. Collect those IP addresses as a response.
- Do a reverse DNS lookup on those IP addresses, and mark them as seen in
redis. - (Commented out) Look at the arp table to see if any other devices have announced themselves. This will discover mode devices, but the ARP cache lasts an unknown amount of time, so this will not correctly track leaving events.
- The
def seenmethod will set a key inredisand expire it in30seconds. The scan runs every10seconds. So if we having seen a device in 2 or 3 scans then we assume it has left the network. We look at each of the keys in the redis sethoststo see if it still exists, and if not, assume that the device has left.
The Code
The only OSX ism of this script is that its using osascript to push a notification to the desktop that a device name has come on or left. See below for further things to play with:
| |
Next steps
Other things to play around with:
nmap -O hostnamewill do a scan of the device to see what operation system it is. However, this is a little more intrusive, needs to run as root, and takes a while to run so it should be queued.- Instead of using osascript, post the device joined, left, or presence events to an internal website to make a better UI.
- This would allow you to map multiple device names to a person. For example, I know that
willschiphone5s.homeis my phone andcombray.homeis my computer, but how do you keep a mapping of those names to people? MAC addressesshould be stable for devices once they may contact to the site. We can get this from thearptables, and those can’t be changed like the computer names can.
Remember, information can bleed and there’s a whole lot you can do to see about the people around you.
Previously
Next