05-29-2020 08:18 AM
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
06-01-2020 03:21 PM
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.
06-01-2020 02:13 PM
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.
06-01-2020 01:35 PM
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.
05-30-2020 11:35 PM
So.. to summarize pieces of secure deployment:
Something needs to be added?
05-30-2020 10:21 PM
Hi,
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
CC
Hope that helps,
Tomasz