07-02-2014 09:01 AM - edited 02-12-2016 12:55 AM
I've just completed the first draft of an ArubaOS security hardening guide. This is intended for anyone who is facing a security audit, pen test, or just wants to operate their controllers/switches in the most secure manner possible.
I would really appreciate comments/questions so I can improve this and make it more useful. Let me know what you think.
Jon Green, ACMX, CISSP
Solved! Go to Solution.
07-02-2014 06:52 PM
Thanks a lot for this.
Here are my notes:
1) It's not said whether the open syslog port, if not blocked, will be vulnerable to DoS from any IP address, or whether it filters against the registered AP list; same may be worth mentioning for other services intended for APs.
2) Please use the full term "local proxy arp" rather than "proxy arp" everywhere where you mean that.
3) Aruba should also provide recommendations for best-of-breed password-based AAA. While password-based schemes
have their faults as adequately described, EAP-TLS and other exclusively-material-based schemes are weak in the two-factor department and EAP-TLS will be passed over in any environment where the flexibilities of a password-based scheme is valued. (The reality is of course that users will store either their AAA creds or their certificate password when the OS offers to. Meanwhile maybe if we all wish hard enough, more OS-native clients would start to support support specifying a client cert alongside an inner authentication method rather than making them mutually exclusive for no good reason.)
4) How the system operates with ip spoofing protection in the absence of also enabling enforce DHCP is not described, and
while I know this isn't going to go into every option because it isn't the manual, DHCP exhaustion protection is IMO a serious enough DoS threat to deserve mention.
08-12-2015 01:15 PM
Bjulin - I realize this thread is over a year old, but I was wondering if you could elaborate on two things
#3 - "more OS-native clients would start to support support specifying a client cert alongside an inner authentication method rather than making them mutually exclusive for no good reason" -- are you referring to how say clients connect to a corp WiFi that first checks if the system has a device certificate, but then forces into a captive portal requiring a password (in our case that syncs to AD)? Or am I misunderstanding this
#4 "DHCP exhaustion protection" - is that not a feature set in ArubaOS, or am I misreading this?
08-12-2015 03:47 PM
About 3) No, I am referring to the fact that there is nothing other than bad choices by
supplicant designers stopping you from issing a validated client-side certificate to
users, as you do in EAP-TLS, checking that the certificate is valid at the TLS-terminating
RADIUS server, and then (if it was a valid certificate) continuing to do a PEAP session
and check that, i addition to having that validated certificate, the use also can enter
If we had this we could control machine enrollment and password expiration separately.