Re: Detection of Rogue Access Points

[Jonathan Rogers <quantumfoam () gmail com>]

I like the idea of looking at the ARP table periodically, but this presents
some possible issues for us. The edge routers at our remote sites are Cisco
1841 devices, typically with either an MPLS T1 or a Public T1 (connected
via an IAD owned by Centurylink; router to router, so dumb). Aside from
manually logging in to those individual routers (all 140 or so of them) and
checking them on a schedule, can anyone think of a good way to capture that
information automatically? If I had to I could probably come up with a
script to log in to them and scrape the info then process it but...eww.

Another possible option (although costly) is installing a Ruckus device at
each location; we have a Ruckus infrastructure at our HDQ and it works
great (almost too good, it's super sensitive) at picking up rogues. A
Ruckus WAP could talk to our ZoneDirector appliance and do that for us at
each site, I think, but it may be difficult to justify the cost.

--JR

On Thu, Oct 18, 2012 at 9:15 AM, Jason Antman <jason () jasonantman com> wrote:

> Some very good points were made in the thread. I've dealt with this
> problem a few times. I'll admit, the only perfect solution I've found is to
> install a Internet-only (its own router interface or VLAN, firewalled off
> from everything else) AP for people to use because, frankly, consumer-grade
> APs are just too easy to install.
>
> On the technical side, to reiterate what others have suggested:
> - Scan MACs from the router ARP table or DHCP logs, flag anything from a
> common wireless vendor
> - Script to pull new DHCP leases, check each with NMAP, alert on anything
> suspicious
> - Port security, if you can
> - Scanning the air
>
> The only *real* way to detect rogue APs is to actually scan the airwaves.
> There's a bunch of vendors who sell hardware/software solutions for this,
> and there are also a lot of APs that support it, especially if you can deal
> with something manual. Ubiquiti Networks sells some sub-$100 USD access
> points that do a nice "site survey" as well as a spectrum analyzer, and
> could be used to get this info. Of course that becomes more of a burden if
> there are multiple other wireless networks within range of you (should be
> fine if your branches are on their own property, could be a problem if
> they're in commercial/professional buildings). I don't know if the Ubiquiti
> products are easily scriptable, but they *do* offer a SDK and with some
> amount of effort, it would probably be possible to pull this data via a
> script.
>
> The times that I've done this, we've just grabbed a bunch of
> decommissioned corporate laptops with wireless & wired ethernet interfaces,
> put Linux on them, and written a script that scans for visible wireless
> networks every 5-30 minutes, and emails any changes to us. Laptops were
> configured for DHCP, and just plugged in and nestled somewhere in the
> wiring closet. Net cost $0 (well maybe some patch cables), and worked fine
> for us.
>
> -Jason
>
>
> On 10/14/2012 04:59 PM, Jonathan Rogers wrote:
>
> > 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