• CloudVision Portal Hardening Guide

 
 
Print Friendly, PDF & Email

Introduction

This guide is provided as a starting point for securing CloudVision Portal, also known as CVP. In the below sections various best practices such as non-default configurations, setup instructions, and discussions of other monitoring systems are discussed. 

The best way to ensure that a CVP system remains secure is to combine the configuration instructions discussed below with a monitoring solution for log output. In addition, keeping CVP up to date and monitoring Arista’s list of security advisories ( https://www.arista.com/en/support/advisories-notices/security-advisories ) is always recommended. 

CVP Default Settings

By default CVP should be expected to ship with settings that will work for most users and not be vulnerable to immediate compromise. The default protocols/ports CVP has accessible are listed in Default Listening Ports.

By default only the root account will be accessible via SSH. The root users password is chosen by the admin during setup. No other services are accessible until the setup is complete.

Choosing of passwords

Advice on setting passwords at Arista is based on NIST 800-63B which is available here: https://pages.nist.gov/800-63-3/sp800-63b.html and was last referenced in Jan 2020.

Per section 5 of 800-63 passwords should:

  • Be at least 8 characters long.
  • Passwords should not fall into the following categories:
    • Passwords obtained from previous breach corpuses.
    • Dictionary words.
    • Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
    • Context-specific words, such as the name of the service, the username, and derivatives thereof.
    • Passwords which could be determined based on detailed knowledge of the user or of the company.
  • CVP does not provide the ability to check passwords do not fall into those above categories, especially since some of these categories may require customer specific knowledge.
  • It is recommended that users be made aware of the requirements and that they choose passwords accordingly.

 

Password selection for SSH login

In addition, the following changes can be made to help with password selection via SSH: 

Note: These changes will survive reboot and upgrade, unless the upgrade also changes these files. The recommended solution to ensure these are in place over time is to validate the file settings after each CloudVision Portal upgrade.

Edit /etc/pam.d/system-auth and change the line

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=

to

password requisite pam_cracklib.so try_first_pass retry=3 minlength=8 lcredit=1 ucredit=1 dcredit=1 ocredit=1 difok=4

This will enforce a password change criteria with a minimum of 8 characters with at least 1 lower case, 1 upper case, 1 digit, 1 character different from the previous password and at least 4 characters to be different from the previous password. 
Edit

/etc/login.defs

and change the following lines:

PASS_MAX_DAYS   99999
PASS_MIN_DAYS   0
PASS_MIN_LEN    5
PASS_WARN_AGE   7

to

PASS_MAX_DAYS   180
PASS_MIN_DAYS   0
PASS_MIN_LEN    8
PASS_WARN_AGE   7

This configuration will enforce that passwords will age out every 180 days, passwords can be changed as often as needed, passwords must be at least 8 characters, and 7 days before expiration users logging in will be warned their passwords need to be changed.

Forcing root login via SSH key

As an added security measure the root user can be forced to log in via ssh key. This is a more secure alternative to logging in via password. To force the use of ssh key logins for the root user:

  • Obtain the public portions of the ssh keys allowed to log in as root
  • Create the file “/root/.ssh/authorized_keys” if it does not already exist.
  • Ensure that the permissions for authorized_keys are “-rw-r–r–” or 644 in octal permissions. 
  • Add the public keys to the authorized_keys file, one key per line, with an optional description at the end of the key.
  • Attempt to log into the root user account via ssh key to ensure that this is configured correctly.
  • Update the entry in “/etc/ssh/sshd_config” to state “PermitRootLogin prohibit-password
  • Run “systemctl restart sshd” to update sshd to disallow passwords.

Password selection for CVP UI login

For CVP users login, Arista provides RADIUS and TACACS providers which can be used by customers. If they aren’t using these servers to login to CVP local user creation and login is available. Password selection criteria are not configurable for local users. The conditions for a valid password are:

  1. Password shouldn’t be empty
  2. Password minimum length is 7
  3. Password maximum length is 72

Restrict Listening Ports

Arista is only able to provide support for the services and features Arista has vetted and shipped. This means that running additional programs on CVP can expose the device to threats outside of the scope of Arista’s ability to protect against. 

Default Listening Ports

The following are the default ports being listened on:

  • SSH – Port 22: Only the root account is accessible by default. The root users password is chosen by the admin during setup.
  • HTTPS – Port 443: This is globally accessible as a TLS secured HTTPS connection.
  • HTTP – Port 80: HTTP web calls will redirect to HTTPS when made on this port. Some services may use HTTP for now while TLS upgrades are in progress.

Depending on other services running, some other ports may be seen open after setup:

  • Telemetry – Port 9910: This uses gRPC over TLS with mutual authentication.

In a High Availability (HA, multi-node cluster) setup, other ports may be opened that are only accessible to other nodes. Accessibility is enforced via firewall rules. These ports are:

Optional Services to Restrict

DHCPv6 is open on port 546 by default and is served by “dhcpv6-client”. This is the dhcpv6 client and if the VM IP is statically provisioned this is not required.

To disable it, delete its entry in both: “/etc/firewalld/zones/eth0-Zone.xml” and “/etc/firewalld/zones/eth1-Zone.xml”.

This change is persistent across CVP upgrades and VM reboots.

Logon Banner

Some customers may prefer to specify a logon banner when users connect via SSH. This message is displayed when connecting to the machine via SSH, before entering the password. To enable ssh pre-login banner edit /etc/cvpi/sshd_config and replace the line:

#Banner none

with

Banner /etc/cvpi/sshd_banner

Now open (create) the file /etc/cvpi/sshd_banner with the content you want. Example would be “This is a restricted system, only authorized uses are allowed access.” Admins configuring this may wish to consult with their Legal department to see if there is a specific preferred message for machine access.

Today sshd_config changes and thus Banner settings will not survive upgrades.

We can also enable post-login or message of the day via the file  /etc/motd. This message is to make sure users know which system they are on and what precautions to take while working on it. Sample message would be “This is the CVP Appliance… exercise caution when making any changes.” or similar.

Both the banner and /etc/motd will survive reboot and upgrade procedures.

Securing Web and gRPC Access

CVP makes extensive use of the Web UIs for accessing it on a normal basis along with gRPC based protocols, which are wrapped in TLS, for features such as telemetry and pushing configuration to switches. The following sections cover choosing secure settings for both.

Choosing TLS Certificates

TLS is based on a “chain of trust” model where TLS certificates are signed by a chain ( a directed linked list ) of one or more parents, ending in what is known as a “Root CA”. Clients connecting a server via TLS will have a set of “Root CA” certificates which they trust and the server will present its personal certificate and all parent certificates which signed the personal certificate leading to the Root CA.

When setting the TLS server certificate, it is recommended to use one issued by an internal IT department on their own chain of trust. It is recommended for the customer to contact their IT department and inquire about options around this.

Restrict TLS Ciphersuites

Nginx, the web server software, uses TLS ciphersuites that are considered safe to use, but may not meet the security standards of certain organizations. It is possible to change the settings used by adding/changing ssl_ciphers in /etc/nginx/conf.d/cvpi-server.conf under the server block. One suggested setting is:

ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA HIGH !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";

Restrict TLS Version

The TLS protocol itself has several different versions, each one having advantages as newer versions are used.

Nginx, by default, uses TLSv1.2. TLSv1.3 is not supported in nginx.

TerminAttr based connections use TLSv1.3 starting from v1.7.6 and TLSv1.2 in earlier versions.

Generate Diffie-Hellman Parameters

The Diffie-Hellman algorithm is used to exchange a symmetric key during the TLS handshake. Default 2048-bit parameters are generated upon first boot, but custom parameters can be generated via the following shell command:

openssl dhparam 4096 -out /etc/nginx/dhparam.pem 

And restarting nginx via “sudo systemctl reload nginx”

Disable older TLS Protocols

Older TLS protocols, such as TLS 1.0 and 1.1 are available on the switch to allow for legacy browsers to connect. To disable the older protocols the following should be changed in /etc/nginx/conf.d/cvpi-server.conf:

ssl_protocols TLSv1.2;

Role Based Access Control for CVP user interface

CloudVision Portal supports Role Based Access Control (RBAC) to further restrict access to different functional areas of the application called modules, broadly classified as Inventory, Provisioning, Settings, Events and Telemetry modules. Managing user roles is available under the ‘Access Control’ section of the settings page in the web based user interface:

When you create a new role, you specify the read and write permissions for each CVP module.

Once a role has been created, it is automatically added to the list of available roles to which users can be assigned. When you assign the role to a user, they inherit the read and write permissions defined in the role.

CloudVision Portal can also be configured to use an existing TACACS+/Radius server to:

  • Leverage existing access control for configuration changes on managed network devices – documented in detail in the configuration guide.
  • Leverage existing access control for SSH access to the CloudVision Portal host system

 The cvpadmin account is a local account and it’s recommended usage is for managing the initial deployment and subsequent upgrades of the CVP instance and other cluster management tasks. For managing device configuration, it is recommended to setup AAA with a TACACS/Radius server and create other local accounts to enable access to the switches (config management, CLI snapshots) from CVP.

 

Services to allow

 

Port/Port-Range Protocol Notes
53 udp+tcp DNS
123 udp NTP
49 (or custom port) tcp TACACS+ (if configured)
1645, 1812, 1813 (or custom port) udp RADIUS (if configured)

Appendix 1

Open Ports in CVP Cluster

The following is a list of ports opened between cluster nodes when CVP is run in HA mode. These ports are only accessible by the other CVP members in the cluster.

 

Port/Port-Range Protocol Notes
2181 tcp Zookeeper
2379 tcp etcd
2380 tcp etcd
2888 tcp Zookeeper
2889 tcp Zookeeper
2890 tcp Zookeeper
3888 tcp Zookeeper
3889 tcp Zookeeper
3890 tcp Zookeeper
6443 tcp Kubernetes Api-server
6783 tcp Alertmanager cluster-peer port
8020 tcp Hadoop Namenode
8080 tcp tomcat
8443 tcp ambassador envoy proxy
8472 udp flannel port for sending VXLAN encapsulated packets
8480 tcp JournalNode
8481 tcp JournalNode
8485 tcp JournalNode
9001 tcp Hadoop Namenode
9092 tcp Kafka
9093 tcp Alertmanager advertised address port
9200 tcp elasticsearch
9300 tcp elasticsearch
9900 tcp API server
9930 tcp dispatcher-1
9931 tcp dispatcher-2
9932 tcp dispatcher-3
9933 tcp dispatcher-4
9940 tcp grpc queue for apiserver
9941 tcp grpc queue for ingest
9942 tcp broadcast storage for apiserver
9943 tcp broadcast storage for ingest
10042 tcp User
10093 tcp cert
10250 tcp Kubernetes
12010 tcp Change Control aeris-service port
12011 tcp Change Control monitor port (ccapi monitoring)
12012 tcp Clover aeris-service port
12013 tcp Clover monitor port
12014 tcp TerminAttr Streaming aeris-service port
12015 tcp TerminAttr Streaming aeris-service monitor
12022 tcp TagSearch aeris-service port
12023 tcp TagSearch aeris-service monitor port
15010 tcp Hadoop Datanode
15020 tcp Hadoop Datanode
15070 tcp Hadoop Namenode
15075 tcp Hadoop Datanode
15090 tcp Hadoop Secondary Namenode
16000 tcp Hbase Master
16201 tcp Region Server
17000 tcp ClickHouse port
17040 tcp ClickHouse replication port
19531 tcp systemd-journal-gatewayd.socket port

 

Open Ports used by Prometheus Scraper for Health Monitoring

 

Port/Port-Range Protocol Notes
6061 tcp recorder monitoring
6062 tcp ingest monitoring
6063 tcp apiserver monitoring
6064 tcp dispatcher-1 monitoring
6065 tcp dispatcher-2 monitoring
6066 tcp dispatcher-3 monitoring
6067 tcp dispatcher-4 monitoring
6500 – 6600 tcp cvp-apps monitoring
6090 – 6092 tcp clover-ingest monitoring
7070 tcp zookeeper prom jmx
7072 tcp hbase master prom jmx
7073 tcp regionserver prom jmx
7074 tcp namenode prom jmx
7075 tcp zkfc prom jmx
7076 tcp journalnode prom jmx
7077 tcp datanode prom jmx
7078 tcp kafka prom jmx
7250 – 7500 tcp turbines monitoring
8901 tcp cvpservice monitoring
9100 tcp node_exporter
12011 tcp Change Control monitor port (ccapi monitoring)
12015 tcp TerminAttr Streaming aeris-service monitor

 

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: