TCP Tricks to Detect Rogue Wireless Access Points

Published: 2011-03-28
Last Updated: 2011-03-28 20:43:19 UTC
by John Bambenek (Version: 1)
9 comment(s)

(Credit to fellow ISC handler Richard Porter for the idea given to someone who e-mailed in looking for ways to detect rogue APs)

Most organizations have policies to disallow wireless access points not controlled by the organization which then requires trying to find such devices when they crop up.  There are commercial devices that can be deployed to do this and you could always have someone do a walkthrough with a laptop.  However, there are some network tricks you can use to provide another "dirty" detection method.

If rogue APs are plugged into your network, they will decrease the TTL value in all packets by one that traverse through the access point.  This can make it easy to detect the presence of those by using p0f/tcpdump/snort to look for packets that have TTL values that are lower than expected.  This also works for unauthorized routers, virtual images, bad network stack configurations, etc.  It won't detect APs that aren't plugged into your network and has some gaps (for instance, a savvy individual could modify the TTL they use before sending packets out), but again it is a "dirty" method of detection.  The advantage of looking for bad "TTLs" is that you will also have advance detection of network problems as well.

You can profile your network and find legitimate TTL values by running tcpdump -v and verifying the information with a network diagram (each router, NAT device, etc will lower TTL by 1).

--
John Bambenek
Bambenek Consulting
bambenek at gmail /dot/ com

Keywords:
9 comment(s)

Comments

A wireless router will decrease the TTL, but an access point functioning as a layer 2 switch will not.
For access points that act like a layer 2 switch, what about arpwatch? I've used this to keep an eye on associations via a legitimate access point. It would also reveal traffic via any rogue AP as well (although arpwatch can't really say which), plus probably the presence of the AP itself on the network.
"If rogue APs are plugged into your network, they will decrease the TTL value in all packets by one that traverse through the access point. "

Err... Not always. An AP operating as a Layer2 device, pure bridge, or true AP will not decrease TTL on any packet, as a bridge doesn't look beyond the Ethernet header of a packet in the first place.

However, if you login the upstream switch of such an AP, and check the MAC address table, you can see multiple MAC addresses of all the different devices attached to that one AP; the AP will look like a switch.

If you deploy port security on your switches with a 1 or 2 MAC addresses per port limit, and a short memory and recovery time, rogue Layer 2 APs will be foiled.


An AP operating as a Layer3 device will decrease TTL, but different applications or users may have different starting TTL values; regardless of your findings from probing, differing TTLs don't necessarily indicate anything. But the bigger hint there will either be multiple IP addresses bound to the same MAC address, or (in case of a NAT device), you will see an IP address emitting lots HTTP requests with a certain user agent, but none of the normal broadcast/discovery messages used by the OS in the user-agent.



A simpler way is if you have good control over your time look-ups. If you point everything at an internal time server, then the only NTP traffic trying to leave the network should be the internal time servers. Since home-type routers usually use NTP by default, any rogue routers could be located by their use of NTP. If you see one, try pinging or port scanning it. If something is making outbound requests but is not pingable, that's usually a problem. We caught a couple within minutes of them being plugged in through a firewall email alert for unauthorized outbound NTP.
...or get your company to cough up some money for a wireless IDS like Airmagnet or Airdefense with enough sensors to cover your facility :)
There are other "poor mans" solution to this. One is to look for Mac-addresses that does not belong on your networki. WIll catch ny type of unauthorized equipment. Mac cloning will hide this though.

Then there is "fingerprinting" traffic from IP adresses, Looking ofr strange pattern, like too many logons, too many simultaneous TCP connections, source port (where sequential).
Would any of these methods work to detect virtual machines?
most soho AP's have a web admin interface up on LAN nic, regular nmaps help to find em. nmapping is generally a good approach to identify new or unknown systems and services.

AP's with non static LAN ip config will perform dhcp requests. checking your dhcp server logs will identify hostnames like DIR-825 etc.

Arpwatch, nac/nap has been said more or less.
ps: like the idea of ttl recon anyway though

Diary Archives