The Aruba ESP Campus Infrastructure Security section describes the technologies used in the implementation of an Aruba ESP device security configuration.
Table of contents
The main responsibility of a secure network is to guarantee that only authorized users and devices can access it. Security protocols must admit authorized users while keeping all other users out.
Using a centralized service to maintain user and device profiles is the easiest approach. A central service running a secure networking protocol provides better security and easier maintenance. Policy can be applied and usage can be tracked from a single point, for more consistent, accurate, and streamlined security management.
Other than required default accounts, local accounts should not be created. All management access should be authenticated through TACACS or RADIUS for accountability. This includes service accounts: the admin/root account should not be used for service accounts or monitoring systems. If a local account is necessary, it should comply with the organization’s password complexity and rotation requirements. Account information on any local account should be limited to as few people as possible, with strict access and usage requirements.
Users connected to Central, gateways, or switches should not be allowed to stay connected for extended periods of inactivity. This guideline limits the number of open sessions and reduces the risk of an unauthorized user potentially editing information on devices with an idle connection.
The recommended timeout varies between one and five minutes, depending on security policy. Ensure that the timeout is consistent across the network.
Complex passwords are required for almost all user access, and network infrastructure is no exception. Complex passwords dramatically decrease the likelihood of being “cracked.”
It is best practice across all Aruba platforms to require a complex password, defined as a password with eight or more characters, requiring a combination of uppercase letters, lowercase letters, numerals, and special characters.
It is also recommended that few to no local accounts exist on devices, and the admin/root account password is set to a 64-character complex password and stored in a safe or secured password-management application. Setting a password of this length and storing it in a safe typically reduces the need to rotate the admin/root account regularly. With RADIUS and TACACS, password complexity is generally controlled by a directory service that complies with the organization’s password complexity and expiration requirements.
The Secure Shell Protocol (SSH) is one of the most common ways to connect to network infrastructure because it is the most secure. It is important to ensure that the strongest ciphers are used to access the network devices. Different regions and systems support different ciphers, so review the Aruba hardening guide for details on which cipher to select. The hardening guide can be found on the Aruba support site.
Terminal Access Controller Access-Control System (TACACS) is a security protocol that provides centralized authentication and validation of users attempting to access a network device. TACACS servers should integrate with an existing directory service to enforce group permission, password complexity, and expiration requirements. It is recommended that all Aruba devices enable TACACS for authentication, command authorization, and auditing. Aruba ClearPass Policy Manager supports TACACS services for any hardware vendor that supports the TACACS protocol, including Aruba devices.
Replacing factory-issued certificates is a key recommendation of the Aruba hardening guide. Always replace certificates before devices go into production.
TLS 1.2 should be the only cipher enabled on any web interface. On gateways, the cipher strength can be set to high, as recommended in the hardening guide.
Using a wildcard certificate for management of web interfaces is acceptable across all Aruba platforms.
When using any application programming interface (API), it is critical to protect the interface. If the API is enabled, an ACL is recommended so that only a management subnet can access the API. Depending on the Aruba product, the management interface may no longer require enabling. Devices managed through Aruba Central no longer require the local web interface, and it can be disabled.