Should you worry about rogue wireless network access points?

The subject of rogue access points (RAPs) has been on our minds lately, and in our ongoing 2011-2012 benchmark interviews we have been asking folks about their experiences with them.

As it turns out, lots of folks aren't worried. This insouciance comes from either a generally laid-back attitude toward security, or from a sense that it is a problem not of great concern to them, or from a simple admission that with limited resources they simply can't afford to buy a tool to address the problem and so have put it out of mind for now.

MOBILE THREAT: Angry Birds, Monkey Jump apps wrapped with malware

The laid-back folks (who are fewest) still tend to look at security as the "Great Disabler" -- the thing that gets in the way of staff using resources to the fullest and as creatively as possible. For them, "more power to them" is the basic response to the idea of staff plugging in their own access points to expand wireless networks. Some have even been happy that staff are proactively solving reception and capacity issues in this way, and are less concerned that they may be extending access beyond the borders of the building or campus.

This category blurs into the second group, the folks who may worry about security in lots of other ways but who don't think RAPs are of specific concern to them. They may have deep enough security on the network to not sweat too much about the unplanned access; or, as was the case for a couple of the folks I've spoken to so far, they may be isolated enough physically to not worry -- if the nearest neighbors are cornfields and cattle, a little signal bleed is not much concern.

The folks with resource concerns, though, are in a bind. They see the problem, they acknowledge it is a problem for them, but feel unable to address it for lack of resources. For some, scale is the problem: They can afford a tool, just not enough tool to scan their thousands of addresses quickly enough to be of real use. If a full scan takes days and the average rogue is up only during business hours, there is a problem.

One solution is to spend the money on the robust, scaled-up package they know would get the job done. This is hard if they can't well justify the expense because they can't really quantify the risk because they can't tell how many rogue access points are out there because they don't have a good enough tool ...

Another idea is to buy the robust solution but not at full scale, and to deploy it differently: Instead of using it as a rake, simultaneously combing through lots of network segments, use it as an arrow aimed at one bit at a time. Develop a hot list for it to scan during business hours and a cold list for off hours. Put some things on the hot list because of where they are (open network ports in conference rooms, for example) and move others from cold to hot as they get flagged as hosting a RAP. It may take some Perl scripting to automate, but it will squeeze more value from the tool.

And of course, a commercial offering can be supplemented (or possibly replaced) by an open source one. Using an open source tool to scan the cold list and bump things to the hot list, for example. Windows scripting can extend the net further, since it is possible to automate use of any existing PC as a signal detector -- to tap the list of accessible WLANs visible from a machine at any given time.

Bottom line, to beat the RAP you have to find it first. You can use arrow or rake, and even if you don't think you need to clamp down on such things you certainly should make sure you can see them -- so if the need does suddenly arise, you are not caught flatfooted.

Burke is principal research analyst with Nemertes Research. He is filling in for Andreas Antonopoulis, who is on leave.

Read more about wide area network in Network World's Wide Area Network section.

This story, "Should you worry about rogue wireless network access points?" was originally published by Network World.

What’s wrong? The new clean desk test
Join the discussion
Be the first to comment on this article. Our Commenting Policies