Wing - secure deployment in campus

[el_magneto]

Hi, 

In my network security is always a big concern and I wonder how can I maximaze the security of adoption process and communication beetwen APs in RF Domain (common VLAN). In a standard way of adoption  it is based on a MAC adress of an AP (as far as I understand MAC address is a factor that distinguish beetwen devices)  whether I use auto adoption policys or static configuration on controller. But what if I want to be 100% sure that device adopted is mine and noone changed it into its own “hacked” device with spoofed MAC adress (even if this is very hypotetical situation)? Is “auto ipsec” a solution here? Or maybe somthing else? But what about mint links between APs in RF domain - the cannot be secured by ipsec. Am I right?

So the question is - is there a way to secure deployment so only devices which where in my “hands” before deployment can be adopted and form mint link/adjacencies beetwen each other in RF-domain?

If my way of thinking is wrong then correct me please 

[Tomasz]

Hi,

@Chris Kellydo you have some thoughts on this inter-ap-key perhaps? Or other way round, is there a way to secure RF Domain from using a non-authorized AP to read MINT traffic? Regarding reading the controller config I only think about auto-prov. policy with serial numbers as a criteria but then also AP cfg in MINT should be secured so that any delicate part of the config does not leak.

Just IPsec?

That might be crucial for some verticals probably.

Thanks,

Tomasz

[el_magneto]

Tomasz, Chris

First of all - thank you for your involvement in the discussion and your answers. 

Speaking of impact. I’m not a hacker but things like man-in-the middle attacks or DoS, DDoS, service interuption and so on. Couple of them were described in this article:

https://gtacknowledge.extremenetworks.com/articles/Vulnerability_Notice/VN-2018-003

There is also a recommendation to use “service wireless inter-ap-key” so its strange that nobody use it 😉

Mitigation: AP Profile and Profile of Controller, i.e.: VX9000-1(config-profile-VX9000-PROFILE)#service wireless inter-ap-key <0,2> <secretpassword>
Additional Precautions: Proper security practices dictate that all default passwords should be changed. All releases listed above provide a method to update the secure MiNT keys. The "Secure MiNT Password" should be changed from the default. No software changes were needed to address this disclosure.

The problem for me is that there is lack of information which communiaction (or part of communication) this command secure, how it works and how to check if it works 😉

[ckelly]

So...that inter-ap-key syntax is used for configuring a encryption key used for securing inter-ap messaging.  This wouldn’t have any affect on securing APs during adoption...but good try! 🙂   Not ever used this myself and don’t know of anyone who has.

As far as duplicated AP objects in WiNG...I’m not sure what would happen in this case. Not a topic that’s ever been discussed, that I know of. 

[Tomasz]

Hi Chris,

I was seeking for some additional MINT security measures and we found this ‘service wireless inter-ap-key’ command. Never played with that yet though.

@el_magneto Another question I would like to ask (I appreciate this discussion as a mind excercise): what kind of impact you are concerned about when some unauthorized WiNG device spoofs MAC address and serial number (how is that feasible with WiNG APs?) or when some unathorized device spoofs MAC address, serial number and implements MINT protocol (how is that feasible and worth of efforts? what an attacker could get with that as a ‘return of investment’?)? Perhaps we can find another way to reduce a risk of that impact instead of trying to patch every hole in a wall.

@Chris KellyIsn’t there any mechanism to detect duplicate AP entities?

If we assume perfect spoofing and putting it somewhere else in a network - duplicate MAC address detection or dot1x might help somehow (BTW EXOS switches can authenticate APs and deliver all VLANs that are needed for this AP to serve WLANs). If we assume perfect spoofing and replacing the very same switch port connection, You can always get a syslog/alarm/e-mail with some monitoring/management systems that a port was down for a moment and decide to administratively keep it down until it is physically verified what’s happened. With XMC quite doable.

Ultimately, CCTV with motion detection in AP and switch locations.

Kind regards,

Tomasz