Aruba SD-Branch Hardening Guide

Aruba SD-Branch Hardening Guide
Version 1.0
Technical Note
Change Log
The following table lists the revisions of this document:
Version Date Modified By Comments

1.0 2019-04-17 Samuel Pérez Buñuel First official version
Copyright Information
Copyright © 2019 Hewlett Packard Enterprise Development LP.
Open Source Code

This product includes code licensed under the GNU General Public License, the GNU Lesser General Public License, and/or certain other
open source licenses. A complete machine-readable copy of the source code corresponding to such code is available upon request. This
offer is valid to anyone in receipt of this information and shall expire three years following the date of the final distribution of this
product version by Hewlett Packard Enterprise Company. To obtain such source code, send a check or money order in the amount of US
$10.00 to:
Hewlett Packard Enterprise Company
Attn: General Counsel
6280 America Center Drive
San Jose, CA 95002
USA
www.arubanetworks.com
3333 Scott Blvd
Santa Clara, CA 95054
Phone: 1-800-WIFI-LAN (+800-943-4526)
Fax 408.227.4550
Contents
Contents
Change Log ........................................................................................................................................... 2
Context—Security in Aruba SD-Branch............................................................. 5
Security Layers ..................................................................................................................................... 6
Introduction—Security Testing ......................................................................... 7
Security Testing and Accreditation ...................................................................................................... 7
Vulnerability Management Process ................................................................................................ 7
Bug Bounty Program ....................................................................................................................... 7
Locking Down Services ......................................................................................8
Cryptography ........................................................................................................................................ 8
HTTPS .............................................................................................................................................. 8
SSH .................................................................................................................................................. 9
IPSec ................................................................................................................................................... 10
Diffie-Hellman .................................................................................................................................... 11
Authenticated NTP ............................................................................................................................. 11
SNMP .................................................................................................................................................. 12
External Syslog ................................................................................................................................... 13
RADIUS Secrets ................................................................................................................................... 14
Control Path Defense ......................................................................................................................... 14
Locking Down Administrative Access ............................................................. 15
Console Port and Password Recovery ................................................................................................ 15
Control Plane Protection .................................................................................................................... 16
Centralized Authentication and Authorization .................................................................................. 17
Locking Down Network Access ....................................................................... 18
WAN interface protection .................................................................................................................. 18
WAN Protect ACL .......................................................................................................................... 18
Geolocation and reputation filtering ............................................................................................ 22
LAN Interface protection .................................................................................................................... 23
User Roles and Firewall Policies.................................................................................................... 23
Aruba SD-Branch Hardening Guide 3

Implementing User-Centric Policies.............................................................................................. 23
Valid IP Address ACL ..................................................................................................................... 24
Global Firewall Settings ...................................................................................................................... 26
Preventing Inter-User Traffic ........................................................................................................ 26
Prohibit IP Spoofing ...................................................................................................................... 28
Prohibit ARP Spoofing ................................................................................................................... 28
Enforce DHCP ................................................................................................................................ 29
Typical Vulnerability Scan Results ................................................................... 30
Open Ports.......................................................................................................................................... 30
Common false positives ..................................................................................................................... 32

SD-Branch Hardening Guide
Context—Security in Aruba SD-Branch

Security is an integral part of the Aruba SD-Branch solution. First and foremost because the solution is built from
the ground up to be completely policy-driven (or, in Aruba terms, role-based). Secondly, because of the fact that
in most cases branches will be directly exposed to the Internet, which mandates very robust hardening policies.
And lastly, due to the firm belief that branch networks should also benefit from “best-of-breed” security.
The security of the Aruba SD-Branch solution is built in layers, from the hardening of the operating system to the
integration with best-of-breed security partners.
Figure 1 - SD-Branch Security Layers

Security Layers
First of all, the Aruba Gateways use ArubaOS, which is a tightly hardened platform, as the operating system for
the gateways. This includes:
• Secure boot—Heavily restricting communications until the Gateway has received its configuration from
Aruba Central.
• Secure Zero Touch Provisioning—Leveraging the TPM loaded in the Aruba Gateways to secure
communications with Aruba Central.
• AES 256 encryption for all branch-hub tunnels.
• Aruba Role-based Stateful firewall—With support for scalable configuration using firewall aliases, ALGs,
and role-based policies.
• Deep Packet Inspection module with capacity to identify close to 3200 applications.
• Web content and reputation filteringusing WebRoot’s machine learning technology to classify content,
reputation, and geolocation for billions of URLs.
Secondly, the Aruba SD-Branch solution can integrate with Aruba ClearPass (or other AAA servers) to form a true
policy-driven branch. This model dynamically assigns policies based on users and devices, as opposed to the
traditional way of assigning these policies manually based on ports, VLANs, and IP addresses. This policy-driven
branch can be enhanced by leveraging integrations with the 100+ partners in the 360 Secure exchange program.
And it can go even further by integrating with Aruba Introspect for User Entity and Behavioral Analytics (UEBA).
Lastly, the Aruba SD-Branch solution can integrate with best-of-breed third-party security infrastructure partners.
With these integrations, the Aruba SD-Branch architecture seeks to offer enterprise-grade advanced threat
protection in a scalable manner. With this in mind, the integration with Palo Alto Global Protect Cloud Service
(PAN GPCS) provides a simple and scalable solution to deliver advanced threat protection in branch networks.
This document describes how to harden the configuration running in the SD-WAN Gateways. It also provides
some aditional suggestions on how to further enhance branch security that, strictly speaking, wouldn’t be
considering “hardening”.

Chapter 1
Introduction—Security Testing
This document has been produced to assist Aruba customers and partners in configuring Aruba SD-WAN Gateways
in the most secure manner.
Please note that security recommendations often involve tradeoffs; not every recommendation listed in this document
will be appropriate for every deployment scenario.
Security Testing and Accreditation

Aruba Networks spends a significant amount of time and money conducting independent third-party security
testing of its products. While the majority of this testing is relevant to and required by government agencies, it
has value to all types of users. In some cases, organizations may choose to rely on recognized security testing
authorities rather than conducting their own product testing.
Each ArubaOS release goes through extensive quality assurance testing. As part of the testing process, several
commercial vulnerability scanners are used. These include:
• QualysGuard
• nCircle
• Nessus
• Retina
Any findings returned by these scanners are examined to determine if they are genuine vulnerabilities or false
positives. Actual vulnerabilities will cause a bug to be opened.
In addition to quality assurance testing, an internal group known as Aruba Threat Labs provides advanced
vulnerability research against Aruba products. Aruba Threat Labs conducts penetration testing through both black-
box and white-box testing, also including source code analysis. From time to time, Aruba Threat Labs also contracts
with external third-party penetration testing firms to conduct targeted testing.
Vulnerability Management Process
Aruba publishes a vulnerability response policy at http://www.arubanetworks.com/support- services/security-
bulletins/. This website also hosts security advisories published by Aruba. An RSS feed is available from this page
as well. Any customer with an active support contract will receive vulnerability advisories by email; interested
parties who want to receive advisories but who do not have a support contract can subscribe to the thread at
http://community.arubanetworks.com/t5/AAA-NAC- Guest-Access-BYOD/Security-vulnerability-advisories/m-
p/176738 to be notified when an update is posted.
Bug Bounty Program
Aruba operates a bug bounty program, through which security researchers are paid a reward for finding and
reporting security vulnerabilities in Aruba products. The program is managed by BugCrowd, a third- party company
that manages the researcher pool, reward payout, and the tracking and reporting process on behalf of Aruba. For
more information, see http://www.bugcrowd.com.

Locking Down Services
Cryptography
ArubaOS employs cryptography as a part of several services, including HTTPS, SSH, IPsec, and others. While an
administrator has a great deal of flexibility in configuring IPsec services, other services tend to provide few or no
options. Algorithms such as DES (56-bits of strength) and MD5 (<64 bits of strength) are permitted to be used,
although this is not the default configuration.
HTTPS
Even though the local UI of Aruba Gateways is rarely used, TLS 1.2 is supported and should be used whenever
possible; this may require browser configuration to ensure that TLS 1.2 is enabled. For the strongest security
configuration, TLS 1.0 and TLS 1.1 should be disabled. This can be done from Gateway Management > System >
Certificates page in the Aruba Central UI.”:
Figure 2 - Restrict to TLS1.2
Disabling TLS 1.0 and 1.1 may lead to compatibility problems with older browsers when accessing the Aruba Gateway’s
local UI.

Chapter 1
SSH
Starting from ArubaOS version 8.4.0.0-1.0.5.0, Aruba SD-WAN Gateways default to AES-CTR for SSH access. Aruba
recommends configuring SSH clients to support the highest level of encryption.
It is possible to restrict the use of specific SSH ciphers and MACs.
• By default, the available SSH ciphers are aes128-cbc, aes256-cbc, aes128-ctr, aes192-ctr, and
aes256-ctr.
• By default, the available SSH MACs are hmac-sha1 and hmac-sha1-96. Administrators can
disable these encryption settings on Gateway Management > System > Admin page in the
Aruba Central UI:
Figure 3 - SSH settings

Some vulnerability scanners complain about the use of HMAC-SHA1-96 and AES-CBC, claiming that such use is weak.
These vulnerability scanners are incorrect; it appears that the scanner vendors have an incomplete understanding of
cryptography. A full explanation is outside the scope of this document, but truncating the output bits from HMAC does
not produce a weaker MAC (see RFC 2104 and NIST SP800-107). In addition, note that weaknesses in SHA1 do not
translate to HMAC- SHA1; the two are different algorithms with different properties (see NIST SP800-107 and SP800-
131A).

IPSec
ArubaOS provides extensive configuration ability for IPsec. The configuration used for IAP-VPN and SD-Branch
tunnels is automatic, but the configuration for other use cases will depend on a number of factors, including peer
capabilities. In general, Aruba recommends use of IKEv2 and a security strength of at least 112 bits.
The following configuration would provide the necessary strength:
Figure 4 - AES-256 Encryption

Chapter 1
Diffie-Hellman
An integral part of IPsec and TLS is the Diffie-Hellman key exchange. In October, 2015, a group of researchers
speculated that entities with nation-state resources may have the ability to break 1024-bit Diffie- Hellman
parameters through a massive pre-computation attack. For details, see the paper at
https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf. Although this paper is speculative, Aruba has
responded by beginning the process to move away from common 1024-bit DH groups.
ArubaOS still uses DH group 2 by default, largely for performance (in the case of SD-WAN tunnels, which are
negotiated using TPMs or Custom certificates) and backwards compatibility reasons. However, factory-default IKE
policies (with priority numbers of 10000 or higher) may be disabled, and replaced with administrator-defined IKE
policies.
As long as performance reasons don’t suggest otherwise, integrations with third party security solutions should
use DH group 14, as it uses 2048-bit encryption and is therefore considered more secure.
Diffie-Hellman is also used during TLS key exchanges, when communicating with a mobility Gateway through
HTTPS. The common DH group used by the Apache web server was replaced with a custom, Aruba-generated DH
group. While a 1024-bit group is still being used, it should be unique to Aruba and thus unlikely to be precomputed
by a nation-state. Aruba’s future goal is to allow for custom DH parameters to be imported by the administrator.
Authenticated NTP
To ensure that audit logs contain accurate timestamps, it is critical that the system clock be correct. The Network
Time Protocol (NTP) is typically used to synchronize clocks on Internet-connected devices. For a higher degree of
security, NTP updates should be authenticated, to prevent an attacker from intercepting NTP communication and
responding with false time data. To enable NTP authentication, in the Aruba Central UI, go to Gateway
Management > System > General > Clock:
Figure 5 - Authenticated NTP

SNMP
Even though all configuration and monitoring of SD-WAN Gateways is done via Aruba Central, some customers
choose to also monitor the Gateways using SNMP. SNMP is commonly used by network management systems to
poll devices for information such as port configuration, status, and interface counters. But SNMP versions 1 and 2
provide very little security beyond the community string. If an attacker has network access to a device and can
guess the community string, it may lead to disclosure of sensitive information. Aruba strongly recommends the
use of SNMPv3, which includes much stronger security through authentication and encryption. To configure
SNMPv3, add an SNMP user as shown below.
For a full explanation of SNMP configuration, see the SD-WAN User Guide on the Aruba Central Documentation site.
Figure 6 - Enable SNMPv3

Chapter 1
External Syslog
In the event that a system is compromised, one of the first things an attacker will often do is to remove evidence
of the intrusion from the system logs. For this reason, it is important to send logs to an external system – preferably
one with automated log analysis tools that can identify and flag unusual activity. Aruba Branch Gateways can only
be configured from Aruba Central, which provides an audit-trail of all management actions performed on a given
device.
Nevertheless, ArubaOS also supports industry-standard “syslog” to facilitate the integration with customer tools.
External logging configuration supports a number of filters and options, but enabling the sending of all logs to an
external server is straightforward:
Figure 7 - Enable external syslog

RADIUS Secrets
The RADIUS protocol provides a weak form of encryption, which uses the RADIUS shared secret as the basis for
the encryption key. While Aruba Gateways (as well as Aruba ClearPass) support RadSec, it’s still not commonly
deployed in many customer environments. Therefore, make that the RADIUS shared secret is as long and as
complex as possible – ArubaOS supports a maximum length of 63 characters. There is no need for this secret to
be memorable by a human, so use a service such as http://www.random.org to generate a truly random string.
Control Path Defense

A number of features are available to defend the ArubaOS control path from attack. The current settings can be
viewed by using the “show firewall” command from the ArubaOS CLI. Relevant output includes:
Monitor/police CP attacks Enabled 20/30sec
Rate limit CP untrusted ucast traffic Enabled 9765 pps
Rate limit CP untrusted mcast traffic Enabled 3906 pps
Rate limit CP trusted ucast traffic Enabled 65535 pps
Rate limit CP trusted mcast traffic Enabled 3906 pps
Rate limit CP route traffic Enabled 976 pps
Rate limit CP session mirror traffic Enabled 976 pps
Rate limit CP auth process traffic Enabled 976 pps
Rate limit CP vrrp traffic Enabled 512 pps
Rate limit CP ARP traffic Enabled 3906 pps
Rate limit CP L2 protocol/other traffic Enabled 1953 pps
Traffic destined for an IP address belonging to the Gateway itself will be subject to these rules. For example,
unicast traffic originating from an untrusted interface and destined for the Gateway’s management interface will
be rate-limited to using the default configuration above. To configure the “Monitor/police CP attacks” value, the
following configuration is used:
Figure 8 - Monitor CP Attack Rate

Chapter 1
Locking Down Administrative Access
Aruba Gateways are managed by Aruba Central, which has its own mechanisms for Single Sign-On. However,
configurations can be seen through the local admin interface (WebUI or CLI) and troubleshooting can be
performed through the local interface as well. For this reason, securing local administrative access becomes a
critical security component.
Console Port and Password Recovery

The serial console port on an Aruba Gateway is considered a privileged interface. An attacker with physical access
to the console port can easily compromise the Gateway using the password recovery procedure, which is widely
known and is given out by Aruba Technical Support frequently when customers lose access to administrative
passwords. The password recovery procedure can be used to change the password for the “admin” account – it
does not reboot the Gateway or change any other configuration.
If good physical security can’t be provided for an Aruba Gateway, Aruba recommends applying tamper-evident
labels (TELs) on the console port. However, TELs are only effective if the Gateway is routinely inspected to see if
the label has been removed.
It is possible to disable the console port through software. This will prevent the password recovery procedure
from being available. However, this command only disables the serial port while ArubaOS is running. If the
Gateway is rebooted, the boot ROM may still be accessed through the console port, which can be used to boot
alternative configuration files, boot alternative software images, or to erase data from flash memory. To disable
console port access, go to Gateway Management > System > Admin > Management User and clear the Enable
console block check box.
Figure 9 - Console Block

Control Plane Protection
Aruba recommends using firewall rules to permit access to the Gateway’s control plane (either for administrative
access or for network services served by the Branch Gateway) only from authorized sources. This could be a
particular subnet which is only used by authorized administrators. If network design permits, it may also be wise
to create a dedicated management network that carries only network management traffic; only the management
interface on the Gateway would permit administrative access.
The easiest way to implement access control for administrative access is use of the “service ACL”. This is a set of
firewall policies that affect all network traffic destined to any control plane element within the Gateway. While
service ACLs can be used to control any network traffic destined for the Gateway, it is mostly commonly used for
administrative access. By default, all traffic for ArubaOS control interfaces is permitted from any destination –
these rules can be viewed by executing the “show firewall-cp internal” command:
(Gateway) #show firewall-cp internal
CP firewall policies
--------------------
IP Version Source IP Source Mask Protocol Start Port End Port Action hits contract
---------- --------- ----------- -------- ---------- -------- -------------- ---- --------
ipv4 any 6 1723 1723 Permit 545
ipv4 any 17 1701 1701 Permit 6
ipv4 any 6 23 23 Permit 523302 cpbwc-ipv4-telnet
ipv4 any 6 8084 8084 Deny 9
ipv4 any 6 3306 3306 Deny 175
ipv4 any 17 8209 8209 DenyNotSecure 0
ipv4 any 6 8211 8211 DenyNotMaster 0
ipv4 any 6 8212 8212 DenyNotMaster 2
ipv4 any 6 873 873 DenyNotSecure 961
…
These default rules would be overridden by any administrator-configured rules. So, for example, while the output
above shows TCP traffic destined for port 22 (SSH) to be permitted from any source IP, an administrator may lock
this traffic down further by specifying additional rules on the Gateway Management > Security > Advanced > ACL
white list page in the Central UI. The following example demonstrates restricting of SSH traffic only to a specific
subnet:
Figure 10 - Firewall-CP

Chapter 1
Centralized Authentication and Authorization
In an organization where multiple administrators exist, who potentially have multiple privilege levels, the use of
centralized authentication helps to prevent insider attacks. With centralized authentication, Aruba Gateways
don’t need to have local administrative accounts. Instead, administrative users login with credentials that are
authenticated remotely by a RADIUS or TACACS+ server. This authentication process can also potentially return
role information back to the Aruba device, allowing the user to be placed into an administrative privilege level
(e.g. ‘root’ or ‘read-only’).
Centralized authentication is enabled through “aaa authentication mgmt" configuration commands. The following
configuration excerpt shows a common setup for authenticating administrative users against a RADIUS server.
The local “admin” account should be set with a randomly-generated password to prevent anyone from using it.
In an emergency, the “admin” password may be reset by accessing the serial console port and executing the lost
password procedure or by changing it from Aruba Central, but under normal circumstances nobody should know
the password to the local admin account.
Alternatively, local authentication may be completely disabled through the following knob:
Figure 11 - Disable Local Auth
If local authentication is disabled, nobody will be able to access the Gateway’s management interface in the event the
authentication server becomes unavailable. For this reason, redundant authentication servers should always be used if
local authentication is disabled. Nevertheless, as long as the device is connected to the cloud, regaining access would be
as simple as changing the configured administrative authentication from Aruba Central.

Locking Down Network Access
Unlike traditional perimeter firewalls, Aruba Gateways have a very user-centric approach to security policies. The
main nuance is the difference between “trusted” and “untrusted” interfaces. In a typical perimeter firewall, a
“trusted” interface is generally where corporate devices reside, and an “untrusted” interface is where you have a
lower degree of control; guest subnets, Internet, etc. This is not the case for Aruba Role-Based firewall.
In Aruba's role-based firewall, trusted/untrusted refers to whether the firewall should track user-sessions for all
traffic coming through an interface (and potentially AAA-driven policies) or simply behave like a perimeter firewall.
• The Gateway will not try to maintain user-sessions for traffic coming through trusted interfaces (ports,
VLANs, tunnels, etc). Instead of that, firewall policies will be
applied to such interfaces – This is generally the case of WAN
interfaces.
• The Gateway will maintain user-sessions for all devices coming
from untrusted interfaces (ports VLANs, tunnels). This means
that a Role Assignment Policy (also referred to as AAA Profile)
must be assigned to all VLANs attached to untrusted interfaces,
regardless of whether AAA is enabled or not – This is generally
the case of LAN interfaces.
WAN interface protection

Aruba Gateways are often directly exposed to the Internet. For that
reason, additional security mechanisms are put in place to ensure the
device is protected from external threats, even with its factory configuration.
WAN Protect ACL
Once the Gateway is loaded with an SD-WAN image, all copper ports but for GE 0/0/1 will start in the ZTP VLAN
(4094). GE0/0/1 would act as "service port", and provide a UI-based workflow to provision the Gateway.
Figure 12 - Default port mapping

Chapter 1
To ensure that Branch GWs are always protected from external threats, all ZTP ports (all copper ports except for
0/0/1) will be protected with the following ACL (note that traffic sourced from the control-plane such as DNS
requests or communication with Aruba Central is by default allowed):
(Gateway) *#show ip access-list wan-uplink-protect-acl
ip access-list session wan-uplink-protect-acl

wan-uplink-protect-acl
----------------------
Priority Source Destination Service Application Action TimeRange Log Expired Queue TOS 8021P Blacklist Mirror DisScan
IPv4/6 Contract
-------- ------ ----------- ------- ----------- ------ --------- --- ------- ----- --- ----- --------- ------ -------
------ --------
1 any any sys-svc-dhcp permit Low
4
2 any any sys-svc-v6-dhcp permit Low
6
3 any any sys-svc-esp permit Low
4
4 any any sys-svc-natt permit Low
4
5 any any sys-svc-ike permit Low
4
6 any any sys-svc-icmp permit Low
4
7 any any sys-svc-icmp6 permit Low
6
Everything else, including all inbound traffic (for non-previously-established sessions) would be blocked.
Once the Gateway is provisioned, the configuration for your WAN ports will be whatever you configure in Aruba
Central. Nevertheless, as soon as you mark an interface as WAN, the GUI automatically applies the wan-uplink-
protect-acl to that port to at least have a basic protection. This security policy can of course be modified, although
the recommendation would be to create a new policy and apply it, instead of editing the default ACL.
Figure 13 - Default wan-uplink-protect-acl
Aruba recommends further tightening the firewall policies applied to WAN interfaces as much as possible.
When doing so, the following should be taken into consideration:

• The firewall in Aruba Gateways is only hit once for a given traffic flow, which means that any traffic
sourced from branch net-works would not be affected by this policy (it should've already hit the policies
tied to the LAN interfaces).
• Traffic sourced from the rest of the corporate network (DC, HQ, other branches, etc) would come into the
branch through the overlay networks (IPSec tunnels). This traffic is seen by the WAN interface as NAT-T
(UDP4500).
Sample WAN Protect ACLs

Branch Gateways are the ones to initiate IPSec tunnels, so the only thing traffic flow strictly needed would be to
allow outbound DHCP requests for Zero Touch Provisioning. Traffic sourced from the control-plane such as DNS
requests or communication with Aruba Central is by default allowed. A more restrictive could therefore be
something similar to this:

Chapter 1
Headend Gateways do need to accept inbound IPSec tunnels coming from the Branch Gateways. On the other
hand, DHCP is not as commonly seen in a Data Center environment. The policy could be as restrictive as the
following (Aruba Gateways use NAT-T for the establishment of SD-WAN tunnels):
Figure 14 -Sample VPNC policy
The policies above are only provided as reference. Different environments could require additional traffic flows to be
allowed. As an example, VRRP keepalives or routing protocol communications should be taken under consideration.

Geolocation and reputation filtering
Aruba Branch Gateways leverage the collaboration with Webroot's Brightcloud service to fetch IP reputation and
geolocation database. The IP reputation database contains known IP addresses associated with various malicious
activities/threats (like botnet, DOS, spam sources). The Geolocation IP database contains the geographical
location of the IP address from where the traffic is received or to which the traffic is sent. This allows the Aruba
Gateways to provide geolocation and reputation filtering as part as the security suite.
Figure 15 - Geolocation and reputation Filtering
When a new session is received, the source and destination IP are fetched and table lookup is done for both the
IP addresses to get the reputation/geolocation information of these IPs. If the table lookup succeeds, then the
session is marked as classified and subjected to IP classification-based firewall policies. If the table lookup fails, IP
classification query message is sent to the control plane to have the classification for these IPs downloaded from
Webroot's Brightcloud service. Once the cloud lookup is resolved, entry is be added to the datapath table, which
is capable of caching information for as many as 1 million IPs or URLs.

Chapter 1
Reputation and geolocation based policies can be configured from the Security > Applications > Applications
Visibility menu in the Gateway Management app in Aruba Central.
Figure 16 - Geolocation and reputation configuration
LAN Interface protection

User Roles and Firewall Policies
Aruba recommends deployment of role-based access control for all branch users. Rather than granting one-size-
fits-all access to the network, only grant access appropriate for that user’s role in the organization; for example,
preventing non-administrative users from accessing the administrative interfaces on network equipment. Another
example includes preventing regular users from running local network services, such as DHCP servers or web
servers. There is no single approach that works for all organizations; administrators will need to evaluate their
own needs and requirements.
Note that many factory-default firewall rules may NOT be appropriate for a secure network. For example, the
“logon-control” ACL permits NAT-T (IPsec over UDP port 4500), and the default captive portal role includes the
“logon-control” ACL. This could lead to captive portal users establishing IPsec sessions without logging in. Examine
default rules carefully by using the “show rights” command, and edit out those that are not necessary.
Implementing User-Centric Policies
The ArubaOS firewall works best when client devices are coming from untrusted interfaces and there's a Role
Assignment Policy (or AAA profile) associated to the VLAN they're coming from. It's important to note that there's
an AAA profile associated to the VLAN does not mean that there has to be any type of authentication. To use role-
based policies without authentication, the following steps are required:
• Create the role that would have to be associated to the VLAN (from Security > Roles)
• Create the Role Assignment Policy (or AAA profile) and use the previously created role as initial role (from
Security > Role Assignment (AAA Profiles))
• Apply the AAA profile to the VLAN (from Security > Apply Policy)
This initial setup facilitates an incremental approach to implementing granular access control policies in branch
networks. Once the initial policy is in place, and the Aruba Gateway is keeping track of all user sessions; security
can gradually be enhanced by enabling MAC/dot1X authentication for all devices (i.e., unique MAC addresses)
reaching the Gateway from an untrusted interface. Devices that fail authentication would be placed in the initial-

role, but devices that are successfully authenticated would be derived to the user-role determined by the AAA
server.
Valid IP Address ACL
ArubaOS defines a default firewall policy called “validuser”, which prevents invalid IP addresses from appearing
in the user table (either accidentally or maliciously). From a security standpoint, insertion of a rogue IP address
into the user table could cause a denial of service attack; for example, if a user were to statically define his/her IP
address to be the same address as the local DNS server. The default validuser ACL is as follows:
ip access-list session validuser
network 127.0.0.0 255.0.0.0 any any deny
host 255.255.255.255 any any deny
any any any permit
ipv6 host fe80:: any any deny
ipv6 network fc00::/7 any any permit
ipv6 network fe80::/64 any any permit
ipv6 alias ipv6-reserved-range any any deny ipv6 any any any permit
Using the default settings, certain IP address ranges are prevented from appearing in the user table – for example,
the IP multicast address range of 224.0.0.0. Aside from the specific “deny” entries, all other IP addresses are
permitted for wireless users. For maximum security, the validuser ACL should be modified so that ONLY IP
addresses valid for wireless clients are permitted. One way to do this is to manually specify entries that should be
permitted. For example, if all wireless clients belong in the subnet 192.168.15.0/24, the following modification to
the default ACL should be made:
Figure 17 - Validuser ACL
Verify the output using “show ip access-list validuser” and note that the IPv4 entries are indicated by “4” and IPv6
entries are indicated by “6”. Although IPv4 and IPv6 rules appear in the same ACL, they are processed separately.
The “validuser” ACL should not be applied to an interface or role. This ACL is automatically referenced each time
a user is added to the user-table.
Another, simpler method to configure the same functionality is through the use of the “local-valid-users” feature
in the global firewall configuration. If this feature is enabled, only IP addresses within the locally-defined VLAN
interfaces address space will be permitted in the user table. As long as the Gateway has an IP interface defined in
every wireless subnet (i.e. an “interface vlan x; ip address a.b.c.d” configuration statement for each wireless
VLAN), this feature works automatically. If the Gateway does not have an IP interface in each wireless subnet, use
the manual ACL method described above.

Chapter 1
To enable “local-valid-users”, in the Aruba Central UI, go to Security >Firewall and enable the Only allow local
subnets in user table check box.
Figure 18 - ACL Local Users

Global Firewall Settings
A number of firewall options that apply to all user traffic on the system are available. This section discusses a few
of these important settings when locking down security settings. Other settings are available (consult the User
Guide for details) but these are considered to be the most useful/valuable for locking down security controls.
Preventing Inter-User Traffic
When this setting is enabled, tunneled users are prevented from communicating with each other. All traffic
originating from a tunneled user, destined for another tunneled user, is dropped. Note that this option may have
significant impacts on network behavior; all forms of peer-to-peer communication are interrupted.
To enable this feature, go to Security >Firewall and enable “deny-inter-user-traffic”:
Figure 19 - Deny inter-user-traffic

Chapter 1
A related feature will block only non-IP traffic, but will permit IP traffic between users (subject to firewall policies
that have been applied to the user role.) This is a less-restrictive option than the previous setting. Because ARP
traffic is considered non-IP, this setting will also disrupt ARP between tunneled clients. For this reason, you may
wish to enable proxy ARP on the user VLANs, which will cause the Gateway to proxy-ARP on behalf of wireless
users. To enable this feature, go to Security >Firewall and enable “deny-inter-user-bridging”:
Figure 20 - Deny inter-user-bridging
The use of “interface vlan 1; bcmc-optimization” will also enable proxy-arp; consult the ArubaOS User Guide to
determine which feature is more appropriate to use.

Prohibit IP Spoofing
An IP spoofing attack occurs when a user statically configures a device with an IP address belonging to another
device on the network. ArubaOS includes a feature that locks a particular IP address with a particular MAC address.
Enabling this feature prevents an attacker from from cloning another user’s IP address.
To enable the prohibit-ip-spoofing feature, in the Aruba Central UI, go to Security >Firewall and enable the
Prohibit IP spoofing check box.
Figure 21 - Prohibit IP spoofing
Prohibit ARP Spoofing

The prohibit-arp-spoofing feature blocks a wireless client from sending ARP responses, or gratuitous ARP
messages, for an IP/MAC combination that is not its own.
To enable this feature, in the Aruba Central UI, go to Security >Firewall and enable the Prohibit ARP spoofing
check box:
Figure 22 - Prevent ARP Spoofing

Chapter 1
Enforce DHCP
In an environment where DHCP is used for client IP address assignment, the enforce DHCP feature forces clients
to use DHCP; static IP address assignments would not be supported. When this feature is enabled, traffic is
dropped from clients that do not complete a DHCP negotiation, and from clients who are assigned an IP address
through DHCP, but then attempt to use a different IP address. The feature is enabled through the Role Assignment
Policy (also referred to as AAA profile) – if there are multiple AAA profiles in use on the Gateway, it is enabled on
a per-policy basis.

Annex
Typical Vulnerability Scan Results

It is common for customers to run their own vulnerability scans against Aruba devices. This section documents
common results and answers frequently asked questions.
Open Ports
The following table lists all ports that are used by an Aruba controller, Gateway, switch, or access point. The table
includes notes on what the port is used for, and whether it may be blocked using firewall rules.
Port Explanation Notes
Number
17/TCP Used to support Nortel Contivity VPN clients Can safely be blocked for most users. Vulnerability scanners
report this as “quote of the day” and may flag an alert for
“quote of the day traffic amplification”.
21/TCP FTP This port may be safely blocked.

22/TCP SSH. Used for administrative access to the ArubaOS It is recommended to enable access to this port only from
command line. trusted subnets.
23/TCP Telnet. Used for administrative access to the ArubaOS Port is open by default, but connection attempts will be
command line. immediately closed. Telnet can be enabled through the
configuration command “telnet cli”.
Aruba does not recommend enabling Telnet. This port may
be blocked by firewall rules if Telnet is not needed.
53/UDP DNS responder. This service responds to all DNS queries Can be blocked by firewall rules if the Gateway is not
with the IP address of the Gateway. Often used when serving as DNS server for any branch devices.
DNS Cache and DNS redirect are needed in branch Vulnerability scanners often report problems with this port,
networks. such as “DNS cache snooping”. Because this port does not
connect to an actual DNS server, warnings may be safely
ignored.
DHCP server. ArubaOS is capable of providing DHCP Disabled automatically if DHCP service is not enabled.
67/UDP server functionality when configured to do so.
80/TCP HTTP. Accepts connections for both Captive Portal and
for WebUI administrative management. Redirects to May be blocked if not needed.
other ports using HTTPS.
123/UDP NTP. Can provide time synchronization for other This port may be safely blocked.
network devices.
161/UDP SNMP. Provides SNMP management access. Disabled by default – enabled when a SNMP community is
configured. Access to this port should be restricted to
authorized SNMP management systems. Aruba recommends
the use of SNMPv3.
443/TCP HTTPS. Used for captive portal authentication, WebUI WebUI will redirect to TCP/4343 unless “web- server web-
administrative management, and VIA. https-port-443” has been configured.
Captive portal will redirect to TCP/8081.
VIA clients require this port to be available in order to
perform profile download, and for SSL fallback mode.

Chapter 1
500/UDP ISAKMP/IKE. Used by IPsec. May be blocked if the Gateway is not being used as a VPN
server. VIA will use UDP/4500 by default to establish their
IPsec tunnels.
514/UDP Syslog. This port may be blocked.
1701/UDP L2TP. Used for VPN termination. Port may be safely blocked if the Gateway is not being used
as a VPN server for L2TP.
1723/TCP PPTP. Used for VPN termination. Port may be safely blocked if the Gateway is not being used
as a VPN server for PPTP.
4343/TCP HTTPS. Used for WebUI administrative management. Connections to TCP/443 will redirect to this port by default,
unless WebUI access through TCP/443 has been enabled.
4500/UDP ISAKMP/IKE NAT Traversal. Used by VIA client, IAP-VPN This port should not be blocked.
and SD-WAN tunnels.
HTTP. Used for captive portal. May be blocked if captive portal is not in use.
8080/TCP
8081/TCP HTTPS. Used for captive portal. May be blocked if captive portal is not in use.
8088/TCP HTTP/HTTPS. Used for captive portal for proxied clients. May be blocked if captive portal is not in use with clients
that require proxy.
8082/TCP Used for Single Sign-On with other Aruba infrastructure May be blocked if single sign-on is not in use.
9070-9080 ZMQ ports 9070 to 9080 are opened by OpenFlow May be blocked if OpenFlow is not being used.
Controller to be used by registered apps.

Common false positives
The most common type of false positive seen by vulnerability scanners occurs when the scanner looks only at a
version number presented as part of a protocol handshake. For example, a scan against a controller’s SSH service
may indicate that the SSH server is OpenSSH version 5.8. If the scanning tool’s database finds known vulnerabilities
for OpenSSH 5.8, it will report that the Gateway is vulnerable. Most vulnerability scanners do not actually attempt
to exploit vulnerabilities, so the resulting report should be viewed as a list of possible vulnerabilities. Aruba
incorporates a number of open- source packages within ArubaOS, such as Apache and OpenSSH. In the interest of
software stability, Aruba typically does not update open-source packages to their latest version when a security
vulnerability is found. This is because, in addition to security fixes, there may be potentially thousands of other
source code changes which may introduce bugs. Instead, Aruba will patch specific vulnerabilities by fixing only the
flaw itself.
The following table includes a number of common false positives for ArubaOS:
Service CVE Notes
OpenSSH CVE-2016-10009 CVE-2016- These vulnerabilities were either patched in source code, or are non- applicable for
6210 CVE-2015-6564 CVE- ArubaOS due to configuration or limited use of a particular feature.
2015-6563 CVE-2015-5600 No currently supported version of ArubaOS contains these vulnerabilities.
CVE-2015-5352 CVE-2014-
1692 CVE-2014-2532 CVE-
2014-2653 CVE-2011-5000
CVE-2011-4327 CVE-2010-
5107 CVE-2010-4755 CVE-
2008-3259 CVE-2007-4752
CVE-2007-2243 CVE-2007-
2768 CVE-2004-1653
SSH CVE-2008-5161 Numerous vulnerability scanners report that the use of AES-CBC in SSH is not
secure. See http://community.arubanetworks.com/t5/Unified- Wired-Wireless-
Access/SSH-and-AES-CBC/m-p/248919 for a full explanation. Note that beginning in
ArubaOS 6.5.4.4, it is possible to disable AES-CBC.
sssd CVE-2009-2410 ArubaOS does not include this service
DNS / CVE-2008-1447 ArubaOS includes a “DNS responder” that listens on UDP port 53. Any query sent to
Nameserver this responder will result in a response that contains the Gateway’s IP address.
Vulnerability scanners may report that this service responds to recursive queries,
that it allows cache snooping, or that it enables traffic amplification attacks. It is
important to note that this service is not an actual DNS server, and these warnings
may be safely ignored.
Web server CVE-2002-0840 CVE-2012- Warnings such as the following may be reported:
0053 “Apache server mod_info is publicly available”
Error page XSS using wildcard DNS
Warnings related to PHP
Warnings related to WebGlimpse
Warnings related to phpCMS
Warnings related to WordPress
Warnings related to ComicPress
Warnings related to SodaHead

Chapter 1
Very often, vulnerability scans are run against a mobility controller’s Captive Portal
interfaces, such as ports 8080, 8081, and 8088. These interfaces have unusual
properties in that all requests result in a redirect/refresh. The request contents will
be reflected back in the response, encapsulated into an HTTP “meta” tag. A number
of vulnerability scanners incorrectly flag these responses as Cross-Site Scripting
(XSS) based on seeing script code in the request appear in the response (i.e. they
do not parse the “meta” tag).
Additionally, because all requests to these interfaces, regardless of URL, are
answered (with a redirect/refresh), the vulnerability scanner incorrectly identifies a
web application as being present on these ports.
Aruba is taking steps to change captive portal behavior in future software versions
so that vulnerability scanners will not be triggered by these false positives. In the
meantime, these warnings are safe to ignore.
TLS / SSL CVE-2009-3555 CVE-2011- CVE-2011-3389 (“BEAST”) is a client-side vulnerability and as such cannot be “fixed”
3389 CVE-2013-0169 on the server side. To mitigate, disable the use of TLS 1.0 and TLS 1.1, as described
in this guide. CBC ciphers may also be disabled on the client side as mitigation.
CVE-2014-0160 CVE-2014- CVE-2014-3566 (“Poodle”) is a vulnerability in SSL 3.0. Older versions of ArubaOS
0224 CVE-2014-3566 CVE- allowed SSL 3.0 to be disabled; newer versions remove SSL 3.0 completely.
2014-8730 CVE-2015-4000 CVE-2015-4000 (“Logjam”) is not a vulnerability within ArubaOS, and never has
CVE-2016-2183 been. Numerous vulnerability scanners appear to report that all TLS servers are
vulnerable, even when they are not.
Some vulnerability scanners report that ArubaOS is vulnerable to CVE- 2016-2183
(“SWEET32”). Since mid-2016, 3DES support was removed from ArubaOS, so this is
a false positive.
TLS/SSL Warnings such as the following may be reported:
Certificate Untrusted TLS/SSL server X.509 certificate
X.509 Certificate Subject CN Does Not Match the Entity Name
SHA-1 based Signature in TLS/SSL Server X.509 Certificate
TLS Server Certificate Modulus less than 2048 bits
SSL Certificate Name Mismatch
ArubaOS ships with a factory-default X.509 certificate called
“securelogin.arubanetworks.com”. This certificate should not be used in production
networks. Typically, warning messages produced by vulnerability scanners are
related to this certificate. Administrator should properly install a unique X.509
certificate, as described in this guide, to eliminate these warnings. These warnings
are NOT false positives, but action from the administrator is required to correct the
problem.
IP stack CVE-2004-0230 CVE-2002-
0510 CVE-1999-0524 These items are labeled, respectively, as:
TCP sequence number approximation
UDP constant identification field / UDP IP ID Zero
TCP / ICMP timestamp response
While by their nature these cannot be fixed, Aruba has judged that the risk of
exploitation is low enough that no further action is required.
Cryptography Warnings such as the following may be reported:

Weak MAC
Weak ciphers in use
TLS Server Supports DES and IDEA Cipher Suites
TLS Server Supports Cipher Block Chaining Ciphers
TLS Server Supports use of Static Key Ciphers

TLS Server Supports Insecure TLS 1.0
Please see the section below entitled “Cryptography” for more information. In
general, Aruba has spent significant time researching various cryptographic
protocols, and believes that products are using a secure configuration. In some
cases, the most secure settings cannot be used, in order to achieve compatibility
with a wide range of client systems (e.g. support for static key ciphersuites such as
TLS_RSA_*) so the resulting configuration is a reasonable tradeoff. In other cases,
the international security standard Common Criteria mandates which cipher suites
must be supported.

Aruba SD-Branch Hardening Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aruba SD-Branch Hardening Guide

Uploaded by

Copyright:

Available Formats

Aruba SD-Branch Hardening Guide

Version Date Modified By Comments

Open Source Code

Aruba SD-Branch Hardening Guide 3

Aruba SD-Branch Hardening Guide 4

Context—Security in Aruba SD-Branch

Figure 1 - SD-Branch Security Layers

Aruba SD-Branch Hardening Guide 5

Aruba SD-Branch Hardening Guide 6

Security Testing and Accreditation

Aruba SD-Branch Hardening Guide 7

Figure 2 - Restrict to TLS1.2

Aruba SD-Branch Hardening Guide 8

Figure 3 - SSH settings

Aruba SD-Branch Hardening Guide 9

Figure 4 - AES-256 Encryption

Aruba SD-Branch Hardening Guide 10

Figure 5 - Authenticated NTP

Aruba SD-Branch Hardening Guide 11

Figure 6 - Enable SNMPv3

Aruba SD-Branch Hardening Guide 12

Figure 7 - Enable external syslog

Aruba SD-Branch Hardening Guide 13

Control Path Defense

Figure 8 - Monitor CP Attack Rate

Aruba SD-Branch Hardening Guide 14

Console Port and Password Recovery

Figure 9 - Console Block

Aruba SD-Branch Hardening Guide 15

Aruba SD-Branch Hardening Guide 16

Figure 11 - Disable Local Auth

Aruba SD-Branch Hardening Guide 17

WAN interface protection

Figure 12 - Default port mapping

Aruba SD-Branch Hardening Guide 18

ip access-list session wan-uplink-protect-acl

Figure 13 - Default wan-uplink-protect-acl

Aruba SD-Branch Hardening Guide 19

Sample WAN Protect ACLs

Aruba SD-Branch Hardening Guide 20

Figure 14 -Sample VPNC policy

Aruba SD-Branch Hardening Guide 21

Figure 15 - Geolocation and reputation Filtering

Aruba SD-Branch Hardening Guide 22

Figure 16 - Geolocation and reputation configuration

LAN Interface protection

Aruba SD-Branch Hardening Guide 23

Figure 17 - Validuser ACL

Aruba SD-Branch Hardening Guide 24

Figure 18 - ACL Local Users

Aruba SD-Branch Hardening Guide 25

Figure 19 - Deny inter-user-traffic

Aruba SD-Branch Hardening Guide 26

Figure 20 - Deny inter-user-bridging

Aruba SD-Branch Hardening Guide 27

Figure 21 - Prohibit IP spoofing

Prohibit ARP Spoofing

Figure 22 - Prevent ARP Spoofing

Aruba SD-Branch Hardening Guide 28

Aruba SD-Branch Hardening Guide 29

Typical Vulnerability Scan Results

21/TCP FTP This port may be safely blocked.

Aruba SD-Branch Hardening Guide 30

Aruba SD-Branch Hardening Guide 31