topic Re: rogue access point in Wireless

rogue access point

bluesea2010 — Sun, 10 Apr 2022 03:39:20 GMT

Hi,

What is the benefit of blocking detected rogue access points

Thanks

Re: rogue access point

balaji.bandi — Sun, 10 Apr 2022 09:48:39 GMT

Its security reason we need to detect and block it.

check some good documents:

https://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/112045-handling-rogue-cuwn-00.html#anc9

Re: rogue access point

bluesea2010 — Sun, 10 Apr 2022 11:05:59 GMT

Hi,

I did containment for multiple rogue ap , but still users can connect and use it

Thanks

Re: rogue access point

Arshad Safrulla — Sun, 10 Apr 2022 12:03:00 GMT

"Blocking detected rogue access points" this is a very sensitive topic as this is illegal in certain countries. Rogue Access point containment if done, must be done very carefully and preferably manually. In order for you to have a well working containment scenario you need to have the proper AP's (AP's with RF ASIC) or dedicated monitor mode AP's. If not best effort containment will be provided by client serving AP's when it goes off-channel. Also if you are deploying monitor mode AP's the AP positioning must be considered as well.
Why we need to do rogue ap containment?

There are many reasons, the most prominent one is to avoid evil twin AP's impersonating your wireless ssid's, avoid unauthorized AP connected to your LAN extending your wired LAN access, then there might be a business requirement where you have to prevent anyother AP's working in your premises, security policy demands etc.

How it works? Different vendors use different mechanisms, Cisco prominently use deauth broadcast spoofing rogue ap bssid source, deauth unicast spoofing the rogue ap bssid as source and destination client mac and also spoofing client mac sending deauth to rogue AP.

How effective? Certain newer clients simply ignore the deauth's and disassoc's when sent by the WIPS. In my extensive testing with numerous BU engineers we noticed that Cisco be default uses deauth frequency of 500msec contain rogue client at Auth phase, but this is not sufficient to effectively contain as client either ignores this or reassocaite very quickly. So we tested with lower values and we found 150msec to be somewhat working, but still not perfect.

So test this in your own environment and keep in mind this will work only if you have the correct infrastructure. If possible try to migrate to WPA3, but considering client support and the WLC side undiscovered bugs due to less usage this might be a challenge.

Re: rogue access point

Rich R — Sun, 10 Apr 2022 13:13:18 GMT

Most importantly make sure the AP you contain is really an "evil" rogue and not just a neighbour (by default everything is classified as a rogue even if it is harmless)

If you contain your neighbours' APs without a justifiable legal reason you will be breaking the law and subject to litigation by the victim and the authorities in most countries.

One of our customers with severely degraded service was the victim of such an attack when the neighbour enabled containment on their Meraki network without understanding what it actually did. After we tracked the source of the attack and had a polite chat with the network administrator who had enabled containment it was very promptly disabled with profuse apologies.

Re: rogue access point

bluesea2010 — Mon, 11 Apr 2022 09:21:58 GMT

Hi @Arshad Safrulla

What is less usage here