Detection of Rogue Access Points

Mailman List Mirror (Read Only)
1

Gentlemen,

An issue has come up in my organization recently with rogue access points.
So far it has manifested itself two ways:

1. A WAP that was set up specifically to be transparent and provided
unprotected wireless access to our network.

2. A consumer-grade wireless router that was plugged in and "just worked"
because it got an address from DHCP and then handed out addresses on its
own little network.

These are at remote sites that are on their own subnets (10.100.x.0/24;
about 130 of them so far). Each site has a decent Cisco router at the
demarc that we control. The edge is relatively low-quality managed layer 2
switches that we could turn off ports on if we needed to, but we have to
know where to look, first.

I'm looking for innovative ideas on how to find such a rogue device,
ideally as soon as it is plugged in to the network. With situation #2 we
may be able to detect NAT going on that should not be there. Situation #1
is much more difficult, although I've seen some research material on how
frames that originate from 802.11 networks look different from regular
ethernet frames. Installation of an advanced monitoring device at each site
is not really practical, but we may be able to run some software on a
Windows PC in each office. One idea put forth was checking for NTP traffic
that was not going to our authorized NTP server, but NTP isn't necessarily
turned on by default, especially on consumer-grade hardware.

Any ideas?

Thank you for your time,

Jonathan Rogers

2
3

I should probably mention that we do not have any legitimate wireless
devices at these locations. I realize that this complicates matters.

The most recent one we found was found exactly like Joe suggested; we were
looking at an ARP table for other reasons and found suspicious things
(smartphones).

--JR

4

I'm looking for innovative ideas on how to find such a rogue device,
ideally as soon as it is plugged in to the network.

There was a SIGCOMM paper a few years back that described a scheme based on measuring the the ACK delays of TCP sessions. In a nutshell, you can detect nodes on the wireless network by looking for the extra delay added by the radio link. It had very good accuracy, and caught new nodes quickly. It didn't require any prior knowledge of the network.

I don't have a copy of the paper at hand, and I don't remember the title/author or the publication date (2007ish?), but maybe this will ring a bell for someone else on the list who does.

--lyndon

5

Automated solution would be something like Air defense or Air Scout with sensors. Cheap solution would be to lock down your switches with port based authentication.

Dustin

Dustin Jurman
CEO
Rapid Systems Corporation
1211 N. West Shore Blvd. Suite 711
Tampa, FL 33607
Ph: 813-232-4887
http://www.rapidsys.com
"Building Better Infrastructure"

6

do you mean http://conferences.sigcomm.org/imc/2007/papers/imc122.pdf
?

Cheers
  matthias

7

That's the one!

8

Scan for devices with open port 80 as these are managed by a GUI.

9

That'd be tough if they plug the WAN port into your network and remote
access isn't enabled.

-A

10

Scan the local network from the local network.

11

This is actually a really tough problem to solve without either total
dictatorial control of your switchports or lots of telemetry and
monitoring.

At $DAYJOB, we detect the transparent bridge case by having a subset
of AP hardware setup as "monitors" that listen to 802.11 frames on the
various channels, keeping a log of the client MAC addresses and the
BSSID that they're associated with.
Then, by selecting out only those client MAC addresses that are not
associated to a known BSSID that we control, we compare that set of
"unknown" client MAC addresses to the Ethernet L2 FIBs on our switches
and look for matches.

If we see entries, than there is some 802.11 device bridging clients
onto our network and we hunt it down from there.

I've yet to see a solid methodology for detecting NATing devices,
short of requiring 802.1x authentication using expiring keys and
one-time passwords. :stuck_out_tongue:

Cheers,
jof

12

restricting the number of mac addresses per switch port to one for your
dhcp pool too, though more than one ap clones mac addresses. and make it
unpopulr for the usual use cases by firewalling off stuff like dropbox,
siri and icloud.

there is of course commercial wips gear like this ..
http://www.airtightnetworks.com/home/solutions/wireless-intrusion-prevention.html

13

I've yet to see a solid methodology for detecting NATing devices,
short of requiring 802.1x authentication using expiring keys and
one-time passwords. :stuck_out_tongue:

Or implement network access protection, w IPsec between the hosts
and the resources on the LAN; the systems behind the rogue NAT device
won't be able to prove their identity, pass system health checks for
antimalware, and get the x509 certificates required to communicate
with hosts on the LAN...

Packet sniffer, and look for packets sourced from hosts on the LAN
with a TTL not matching the default TTL of OS'es in use on the network.

Monitor ARP traffic. Start with the assumption that all devices are
NAT devices,
or malicious/unauthorized devices. Use TCP probes, to detect devices
listening on common ports which can be identified as OSes (eg
Windows, Printers, etc), which are known hosts on the network with a
known user, or known purpose, and known to not be NAT devices.

Delete known devices from the list of assumed rogue IP addresses.

All the remaining IPs have to be investigated, and get their MAC
address, hostname,
and purpose documented.

Once MAC addresses of all _known_ hosts are documented and manually verified,
by process of elimination, you can detect any unknown IP
addresses/MAC addresses,
which might be any kind of unauthorized device.

A NAT device is one example.....
another example of an unauthorized device could be an unauthorized
hardware keylogger/
network backdoor, with unauthorized connectivity to the LAN, and
possible covert
channels/backdoors/firewall bypasses.

14

SSL throughout the network, with access control enforced using certificates
is certainly a good idea.

But most of the problem you face is metrics and inventory control of
authorized devices. Commercial WIPS gear does a lot of this heavy lifting
without your having to script it all yourself.

15

No-one has said this yet, so I will - why are people working around your
normal network policies? This is often a sign of something lacking that
people need in their daily work. You can often reduce this sort of
"innocent thievery" down to a manageable minimum simply by making sure
that people have the tools they need to work.

Sometimes it's cheaper to give people what they want than to prevent
them taking it. Maybe at least consider that as an option.

Regards, K.

16

Install your own Access Points for official use and have them scan for SSIDs in the vicinity. Kills two birds. One you now have official wireless access and your AP can detect rogue SSIDs.

17

There are wireless IDS/IPS products available that monitor not only the
airspace, but the wire as well. Many of these products will also actively
defend the airspace. Search for "wIDS" and/or "wIPS". Often the cost of
purchasing and deploying these products is more expensive than the cost of
implementing simple 802.1x port authentication though.

If nothing else, set up guest wireless piped to a cheap broadband
connection and create and/or enforce proper acceptable use policies on your
LAN. The less you fight your users, the easier your job is.

Of course all of this is dependent on the business and legal jurisdiction
you are in.

-Jon

18

Do the layer 2 switches include sFlow instrumentation?

http://sflow.org/products/network.php

The following paper describes how IP TTL values can help identify
unauthorized NAT devices.

http://www.sflow.org/detectNAT/

Peter

19

How about some of the free network auditing tools like nmap even Spiceworks
to detect the devices on your network?

Martin

20

Amen to that - detecting rogue access points is one thing, but in order
to make the users stop doing it, you're going to need either a sufficiently
large carrot or a sufficiently large stick. If you don't deploy at least one,
the problem *will* keep recurring.