Slashdot Mirror
Fighting Rogue Access Points At linux.conf.au
An anonymous reader writes "Last week's linux.conf.au saw the return of the rogue access points. These are Wi-Fi access points which bear the same SSID as official conference hotspots. Often it might be a simple mistake, but sometimes it's more nefarious. To combat the attacks this year, conference organisers installed a Linux-based Wi-Fi 'intrusion prevention and detection system' supplied by sponsor Xirrius." At most conferences I've been to, I'd be grateful just to be able to get on any access point.
At a recent event, we utilized Cisco's Wireless Access Controller. We are an all-Cisco house, so it was an easy choice.
http://www.cisco.com/en/US/products/ps6302/Products_Sub_Category_Home.html
I'd rather you do it wrong, than for me to have to do it at all.
android phone + cyanogenmod + grandfathered verizon unlimited data plan = "it may not be perfect, but it gets the job done and it is still way better than the dialup connection I used back in the day."
unless I'm in some building shielded with sandwiched lead sheets or something. in which case, hell, screw it, time to read an ebook.
Note for next revision of the protocol... public key signed SSID names. Or SSL certed SSIDs
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
As wi-fi becomes a mainstream Internet on-ramp when you're out and about, I think the rogue AP issue needs to be addressed FAR better than it is today. As the story's submitter said, tech. conferences might be the least of the problem since most of the time, you've got a massive flood of wi-fi usage attempts concentrated under one roof at such things. The tech-savvy will already plan on other forms of connectivity (such as 3G or 4G cellular). Plus, the vast majority of conference-goers are trying to send photos, video or blog entries of the happenings ... not taking out time to do their online banking, shopping or what-not. So rogue sites trying to scape for data are less likely to capture anything really useful.
My co-workers have started asking me, "How do I know if it's safe to connect to a wi-fi hotspot when I'm traveling?" ... and I'm realizing the answer isn't very clear-cut. I can advise them that certain companies contract to provide thousands of APs for chain restaurants, and typically have an AP identifying themselves as such. (You'll often see an SSID of "wayport" at a McDonalds for example.) But beyond that, the average laptop or smartphone user really doesn't even think about someone spoofing a legitimate-looking SSID. I've even run across such things as multiple SSIDs showing up with no password at our airport, where I knew at least 1 or 2 of them were fakes. (One had an SSID of "airport wifi", as I recall, when I know our airport only provides wifi in the terminal waiting area via AT&T - who would NOT name it anything like that.)
At a recent event, we utilized Cisco's *cha-ching* Wireless Access Controller. We are an all-Cisco *cha-ching* house, so it was an easy choice.
http://www.cisco.com/en/US/products/ps6302/Products_Sub_Category_Home.html *cha-ching*
Cisco. *cha-ching*
Have an SSH server somewhere, and tunnel everything through that; this is the equivalent of using a VPN. If you see host key warnings, then abort -- better than the headache of dealing with someone pwning your bank account.
Palm trees and 8
I would have hoped all the normal standard practices would protect you almost totally from this.... Don't use an important password except over https where your browser doesn't raise red flags. Use a VPN or ssh to connect to servers that are important to you. Seems the same practices that protect you from your normal ISP would protect you from rogue access points too, no?
At most conferences I've been to, I'd be grateful just to be able to get on any access point.
I hope you have a ssh thumbprint to verify of any hosts you plant to connect directly to, and tunnel everything else!
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Airespace had something where you could actively "discourage" or otherwise overwhelm the rogue AP within a defined area. Now that Cisco took over, it's just a "spot the rogue, hope you're right" type of deal.
Twitter supports and protects racists - by smearing their critics with the "Hate Speech" label.
Just window foil and energy efficient windows in a concrete/steel building will do it. I work for a mobile telco and we can't get any 3G at all inside the building, getting GSM900 reception is a struggle. It's so bad, we can't even use our cell phones in 90% of the rooms.
I was promised a flying car. Where is my flying car?
android phone + wireless ap detection software of choice + conference management + exit door = problem solved. (find them and kick them out)
Show me packet captures and log entires, or it never happened.
This is not free speech. A "Rogue access point" is an attempt at idenitity theft.
Free speech is go setup your own show in a different place, and see who is willing to show up and listen.
Clearly A/C has never had to do an enterprise deployment.
.. probably, but who's going to support that long term?.
The reason for going "all $vendor" (be it Cisco or Microsoft) is because our business is not about finding the absolute lowest line-item cost for every piece of IT gear.
Our business is doing something ELSE, and IT is just in support of that.
Could Cisco's technology be replicated with a bunch of WRT54GLs and a room full of grad students?
Trust me, the "fun" of making two random things work together wanes real fast when you've got a job to do.
Clearly A/C has never had to do an enterprise deployment.
Clearly you have misread A/C's point.
He wasn't (unless my understanding is wrong, of course) commenting on the expense of the equipment, he was commenting on the fact that the parent post looked like a very amateur paid shill. A worthwhile informative post would not have simply stated "we use this stuff, here go look at this link", it would explain how that equipment was pertinent to the article at hand. Perhaps it makes solving the problem easier in some way, if so he could have stated that rather than just getting the link in as fast as possible to try get it as close to the top of the post list as possible - just slapping "cisco cisco csico link cisco" in a post is essentially spam.
And yet, wifi coverage was fairly spotty for the conference. Some of those access points definitely weren't working, you'd have to manually choose which MAC address to use, or point your antenna in a different direction before you could connect properly.
If you wanted to setup a rouge AP, you could probably get away with it in the corridors. Though you wouldn't be able to hack everyone, there were plenty of people hanging around outside the main halls checking emails etc.
But overall, it was a pretty cool conference.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
From the point of view of the infrastructure/security go-to man for a small company, what options are there for locating unauthorised APs? We scan for unauthorised MAC addresses turning up on the network so an alert goes out if something unwanted is plugged into the LAN, but that wouldn't detect a soft-AP running on an otherwise expected machine (nor would it spot a device with a faked MAC, but that is another matter). Are there any reliable methods of picking up on new APs turning up (even those that are not broadcasting their ID) and then finding their approximate physical location (we are in a manged office block, so a new AP turning up is most likely to be on one of their LANs so not something we need to worry about).
Some of our clients trust us with data that they are (understandable) sensitive regarding the safety of, so if there is anything I can do to decrease the chance we'll ever be the source of any leak is useful to reduce my paranoia levels!
Yes, there were a lot of "rogue" DHCP servers at LCA, although a better term might be miss-configured because I am almost certain it wasn't deliberate. But the story neglects to mention the reason. Attendees were invited to set up wireless access points because the accommodation didn't provide wireless. There were I guess 20 or 30 units, and I be surprised if every one of those units didn't have at least 1 AP set up by a community minded resident. It is inevitable that some of those will have forgotten to turn DHCP off, or perhaps plugged the internet connection into the switch rather than the upstream port on the router.
This is avoidable. LCA owns some 50 or so access points, which have been deployed in the past to supply wireless to the accommodation. Doing so means the attendees don't bother unpacking their access points, and the rogue DHCP problem goes away. However, deploying those access points takes a substantial amount of time and organisation. LCA is run by volunteers. So they have a tradeoff - they can put in a substantial amount of work and the problem largely goes away, or deal with the problem during the conference as it arises. As LCA attendees are a pretty sophisticated bunch networking wise, either way works well enough.
The one thing that doesn't make any sense is blaming the attendees, which is the way this story tries to slant it. That is like leaving the nappy off the baby and then blaming it for the piss on the carpet. The consequences of not supplying wireless are entirely predictable. Reasonable adults either supply wireless, or accept the consequences and don't whinge about it.
A more interesting topic of discussion is the collapse of the network in the accommodation on Friday night. In hindsight the cause is obvious. For the second LCA in a row they got all most of the conference video's up before the conference closed. Come Friday night many attendees decided to download huge quantities of them, the usual reason given being "so I have something to watch on the way home". It was a really good idea actually - LCA this year had 4 streams, and inevitably people ended up missing what in hindsight were "must see" talks. The problem was the link between the residences and LCA simply could not cope with the traffic.
Again, that could have been solved. Indeed it was solved at LCA 2011 using DNS tricks. In that year a copy of the videos was put on a server in the residences, and FQDN for the video server resolved to that server for the residences only. Or perhaps enabling torrents for the videos would have worked well enough. As it was, internet connectivity was almost non-existent Friday night, and that caused howls of anguish - far more anguish than the rogue DHCP servers.
When I use a public wireless access point, my networking scripts immediately set up an OpenVPN tunnel and make that the default route. If you don't route all your traffic over a VPN when you use public wireless of any kind, you're asking for trouble.