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
Very interesting food for thoughts! Personally I would consider:
It is always good to think how can we contain damage if some unwanted device gets adopted or reads MINT communication or reaches the WiNG communication VLAN, but I’d try to put all efforts possible in making that VLAN isolated from unnecessary contact from non-AP/controller ports and non-MINT VLANs.
Hope that helps,
Very often APs are installed on places where it is possible to reach phisicaly the device. And 802.1x is a good idea- maby the best - but problems start when switches to which APs are connected can’t support 802.1x on trunk ports. For instance my APs need to be connected to truk ports ( dynamic vlan assigment from Radius).
This is why I’m curious what can Wing do on his own to maximize security in depoyment.
Any other idea?
Agreed. It would be also good to distinguish particular attack vectors as they are going to have different countermeasures possible.
Assuming that securing access to MINT-related VLAN is not possible, we have controller/AP management plane to secure and MINT frames themselves.
Regarding management access, IMO Management Policy is fair enough to restrict management connection attempts to a controller (to just particular source IPs and to particular protocols and ports) and to APs (all can be disabled, you will always be able to reach AP CLI with a console port and thru controller’s CLI with ‘connect’ command).
Regarding MINT security without IPsec… I didn’t play with this command yet, but maybe could help with MINT encryption:
service wireless inter-ap-key
service wireless inter-ap-key
So.. to summarize pieces of secure deployment:
Something needs to be added?
If you want to tighten things down, then also consider setting up your auto-provisioning policy to include the serial numbers of the APs as a requirement for adoption. In this case, if an AP is wanting to adopt, it must have a serial number that matches what you’ve specified.
There are other match criteria, but the serial number would be the best selection here from a security perspective.
In a hypothetical situation if someone can spoof MAC of an AP he can also spoof a serial number. Correct me if I’m wrong.
I tired to test service wireless inter-ap-key but it seems not to work. I have a test RF-domain with 2 APs. And I set different keys on them. But they still can see each other, form neighbours link. Are still “mint pingable”. How to check if this command is working properly?
And I noticed that auto IPsec has a downside that on the controller you can set only one PSK and group ID for all APs. I thought I could build group ID + PSK per RF domain.
Agree about the spoofing...though the serial number part would certainly be more difficult...but the old adage - Security is like an onion. Layers. Make it as difficult for them as possible.
Not sure what you’re referring to with the “ service wireless inter-ap-key”. I’m wondering if maybe you’re referring to the MINT area-id. Please expand on that.
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.
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.
Isn’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.
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.
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:
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 ;)
do 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.
That might be crucial for some verticals probably.
Contact Us:Sam PirokCommunity@extremenetworks.com