Wireless Access

Reply
Moderator

ArubaOS Security Hardening Guide

Hi everyone-

 

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

---
Jon Green, ACMX, CISSP
Security Guy
Super Contributor I

Re: ArubaOS Security Hardening Guide

 

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.

 

New Contributor

Re: ArubaOS Security Hardening Guide

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?

Super Contributor I

Re: ArubaOS Security Hardening Guide

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

a password.

 

If we had this we could control machine enrollment and password expiration separately.

 

 

Super Contributor I

Re: ArubaOS Security Hardening Guide

 

About #4, yes that is an AOS feature.  I was saying it should be mentioned in the guide.

 

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: