Objective

This Tech Tip is intended to provide Arista EOS users with the configuration guidelines and best practices to enable secure management plane protocols according to IT industry security standards. It is not the objective of this document to set the foundations or rules of a company security policy or a password policy.

Note: This document is not intended to set company security or password policy. Ultimate responsible to define and apply an end-to-end IT security policy is the responsibility of the end user and must take into account any regulations directly related with company activities.

Arista EOS includes a wide range of industry standard management protocols.  Some of these protocols, for example Telnet or HTTP, are insecure in nature and should be avoided whenever is possible and, instead, use secure alternatives provided by Arista EOS. Some of the examples exhibited in this Tech Tip do not show all the available options in Arista EOS and the author encourages the readers to review the Arista EOS User Manual and apply the configurations that best adapts to the company security policy.

Requisites

The features and examples documented in this Tech Tip are based on Arista EOS Version 4.13.1F. It is assumed that readers are familiar with Arista EOS CLI in particular and with management protocols in general.

Understanding Initial Access Configuration

Out of the box, and whenever Zero Touch Provisioning is not being used for auto provisioning, users can access to the switch CLI through the console port only. The default username is admin and no password is configured for this user. Default admin configuration:

username admin privilege 1 role network-admin nopassword

Once logged in with the admin user, by default, this will place us in EXEC mode (or privilege level 1). EXEC mode allows the user to display system information and perform basic tasks such as change terminal settings or connect to remote devices. The enable password is disabled and users can gain access to Privileged EXEC (or privilege mode 15) mode by simply typing enable or en. The next output shows the default privilege level for the user admin and how to enter in Privileged EXEC mode:

Arista>show privilege

Current privilege level is 1

Arista>enable

Arista#show privilege

Current privilege level is 15

Besides console access, EOS also provides two more connection methods:

• SSH – enabled by default

• Telnet – disabled by default

The next output shows the default Telnet and SSH configuration (not displayed in the running configuration):

management ssh

  idle-timeout 0

  authentication mode keyboard-interactive

  server-port 22

  no fips restrictions

  no hostkey client strict-checking

  no shutdown

  login timeout 120

  log-level info

!

management telnet

  shutdown

  idle-timeout 0

Arista Networks does not recommend to enable (no shutdown) Telnet unless is strictly necessary.

For SSH to work in the initial configuration, in addition to the the management IP address, the admin user needs to be assigned with a password. SSH sessions for users without a password assigned will not work.

Password Hashing Algorithm

Arista EOS supports two modes of hashing algorithms to encrypt passwords: MD5 and SHA512. By default, Arista EOS encrypts all the passwords configured in the system using the MD5 algorithm. It is commonly accepted that SHA512 provides a higher level of security to stored passwords and it is recommended to use it whenever is possible. To change the default hashing algorithm configuration from MD5 to SHA512, configure it under management configuration sub-mode:

Arista(config)#management defaults

Arista(config-mgmt-defaults)#secret hash sha512

Previous passwords stored using MD5 will not be re-encrypted and will have to be entered again. One way to distinguish password’s encryption algorithm is to look into the configuration file (running or start-up). In the following output, the admin user password has been hashed using MD5 (secret 5) and the noc user password using SHA512 (secret sha512):

username admin role network-admin secret 5 $1$5C7CVuxv$nnhvQ21cl8fsuw/HTaYpA/

username noc secret sha512 $6$RMxgK5ALGIf.nWEC$tHuKCyfNtJMCY561P52dTzHUmYMmLxb/Mxik.j3vMUs8lMCPocM00/NAS.SN6GCWx7d/vQIgxnClyQLAb7n3x0

Local Authentication and Enable Password

Arista EOS supports three access control methods:  local security database, TACACS+, and Radius. The admin user and subsequent users created in configuration mode are part of the local security database.

By default, the local security database or file provides the local authentication, but companies typically opt for a centralized model like Radius or TACACS+ for authentication, authorization, and accounting (AAA).

Whether the administrator decides to implement Radius or TACACS+, or none of them, a password should be always configured for the admin user since this user cannot be removed from the system. The following output shows how to assign a password to the admin user:

Arista(config)#username admin secret <password>

Additional users can be created in the local database with different options such as assigning a different default privilege level, or different roles. To know more about roles and privilege levels, please refer to Arista’s User Manual: http://www.aristanetworks.com/docs/Manuals/ConfigGuide.pdf

Enable Password

As a part of the local authentication, the enable password command gives local users access to Privileged EXEC mode from EXEC mode. By default, this password is not configured. Since this password authorizes access to the Privileged EXEC mode, it is recommended to configure it.

Configuring the enable secret password:

Arista(config)#enable secret <password>

Radius and TACACS+ Authentication

Radius and TACACS+ methods allow administrators to centrally manage AAA for the entire network, and are key elements of the security infrastructure. Arista Networks recommends using one of these solutions as long as they are available.

The following two examples show how to configure Radius and TACACS+ authentication with fallback authentication to the local database in case the connection with the servers is lost. To minimize the number of fallbacks to the local database, and as a general best practice, configure at least two servers.

Radius Authentication Configuration Example

Arista(config)#radius-server key <radius_key>

Arista(config)#radius-server host 10.0.0.3

RADIUS host 10.0.0.3 with auth-port 1812 and acct-port 1813 created

Arista(config)#radius-server host 10.0.0.4

RADIUS host 10.0.0.4 with auth-port 1812 and acct-port 1813 created

Arista(config)#aaa authentication login default group radius local

Arista(config)#aaa authentication enable default group radius local

Arista(config)#show aaa method-lists authentication

Authentication method lists for LOGIN:

 name=default methods=group radius, local

 name=login methods=group radius-servers, local

Authentication method list for ENABLE:

 name=default methods=group radius, local

TACACS+ Authentication Configuration Example

Arista(config)#tacacs-server key <tacacs_key>

Arista(config)#tacacs-server host 10.0.0.5

TACACS+ host 10.0.0.5 with port 49 created

Arista(config)#tacacs-server host 10.0.0.6

TACACS+ host 10.0.0.6 with port 49 created

Arista(config)#aaa authentication login default group tacacs+ local

Arista(config)#aaa authentication enable default group tacacs+ local

Arista(config)#show aaa method-lists authentication

Authentication method lists for LOGIN:

 name=default methods=group tacacs+, local

 name=login methods=group radius-servers, local

Authentication method list for ENABLE:

 name=default methods=group tacacs+, local

Bash Access and Root User

Access to the bash is restricted to the Privileged EXEC mode from the CLI.  By typing bash, the user gains access to the underlying Linux OS, and will be logged with the same CLI username being used, as the following output shows for the admin user:

Arista#bash

Arista Networks EOS shell

[admin@Arista ~]$ whoami

admin

[admin@Arista ~]$

On the other hand, remote direct access to the bash – through SSH or Telnet – is restricted to the root user. The root user is a special user and, like the admin user, cannot be deleted or edited.

Unlike the standard users, the root password is configured  by typing aaa root in configuration mode:

switch(config)#aaa root secret <password>

Assigning a password to the root user is also necessary to execute commands in root mode when logged in the bash with a different user:

Arista#bash

Arista Networks EOS shell

[admin@switch ~]$ su

Password: <enter root password here>

bash-4.1# whoami

root

bash-4.1#

SSH Access Control

Using a standard access list, SSH access security can be enhanced by restricting the source of the connection to a specific host or subnet.

The following example shows how to delimit the source of connections to the 192.168.1.0/24 subnet:

Arista(config)#ip access-list standard mgmt-acl

Arista(config-std-acl-ssh)#permit 192.168.1.0/24

Arista(config-std-acl-ssh)#management ssh

Arista(config-mgmt-ssh)#ip access-group mgmt-acl in

Access lists include an implicit “deny any any” at the end and it is not necessary to configure this unless we want to create a specific log of packets denied.

Simple Management Network Protocol (SNMP)

Arista switches support versions 1, 2c, and 3 of SNMP. Versions 1 and 2c security is based on community strings. Version 3 adds an additional level of security by encrypting the communication.

SNMP Version 1/2c Configuration Example

In SNMP v1 and 2c, typically, two different communities are used with different access rights: read-only and read-write. The recommendation is to use exclusively the read-only community and to not to enable the read-write community unless it is strictly necessary.

Community strings are similar to passwords sent in clear text.  For that reason, community strings should be elected carefully following the company’s password policy as if they were passwords. To add an additional level of security, and as in the SSH example shown before, the source of the SNMP queries can be restricted to a specific subnet or IP address using standard ACLs.

The following example shows how to configure a read-only community that can only be reached from the 192.168.1.0/24 subnet:

SNMP Version 3 Configuration Example

Although SNMP v3 does not change the foundations of the protocol operation, it does bring important security features that should be enabled as a general security best practice. In addition to username and password authentication, it also provides message integrity, and confidentiality through the use of encryption.

SNMPv3 requires three steps to be configured  in Arista EOS: view, group and user configuration. The following example shows how to configure a read-only group and a user with access to all the MIBs:

• Create SNMP View for all the MIBs:

Arista(config)#snmp-server view all iso included

• Create SNMPv3 group both with read access:

Arista(config)#snmp-server group noc v3 priv read all

• Create SNMPv3 user john part of the noc team with authentication and privacy passphrases:

Arista(config)#snmp-server user john noc v3 auth sha <authentication_passphrase> priv aes <privacy_passphrase>

NOTE: For the list of the MIBs supported by Arista EOS, please refer to the following link: http://www.aristanetworks.com/support/aristasnmpmibs

Disabling SNMP

SNMP is disabled by default. If SNMP has been configured but a new security policy mandates to disable it, it can be done using the  no snmp-server command:

Command API

EOS Command API is Arista’s JSON programmable interface that allows applications and administrators to have complete control over EOS using industry standard CLI served over HTTP or HTTPS. The Command API is disabled (shutdown) by default and, once enabled, can be accessed over HTTPS only. It is not recommended to enable HTTP unless is strictly necessary being that the username and passwords will be sent in clear text over the network.

If your security policy requires to use your own certificates or certificates trusted by a Certification Authority rather than the one self signed by EOS, this can be changed issuing the protocol https certificate command under the management api configuration sub-mode.

VRF Aware Management

VPN Routing and Forwarding (VRF) allows traffic separation by maintaining multiple isolated routing tables. All the Arista switches support the management VRF which should be always dedicated to management protocols and not be used for regular traffic.

Having a dedicated VRF for management purposes brings an additional level of security since this VRF becomes isolated from the normal data traffic avoiding unauthorized access from other networks than the management network, without the need of configuring layer 3 access lists.

To configure the management VRF, first of all, the VRF itself needs to be defined. And, secondly, the VRF needs to be assigned to the management interface.

Arista(config)#vrf definition mgmt

Arista(config-vrf-mgmt)#rd 64512:1

Arista(config-vrf-mgmt)#interface management 1

Arista(config-if-Ma1)#vrf forwarding mgmt

! Interface Management1 IP address 172.16.130.11 removed due to enabling VRF mgmt

Note that the IP address previously configured will be removed once the VRF is assigned to the interface. The IP address should be configured again, then.

On modular switches with dual supervisors, only the virtual ( active ) management interface ( ma0 ) can be configured in a VRF.  An error message will be displayed if VRF configuration is tried on the physical management interface like:

Arista(config-if-Ma1)#vrf forwarding mgmt

% VRF configuration is not supported on this interface.

The next step is to configure the different VRF aware management protocols so they only work through the management interface and, subsequently, the management VRF.  At the time of this writing, the following protocols are configurable to work in VRF mode:

• SSH
• Telnet
• Command API
• XMPP
• TACACS+
• NTP
• Syslog
• DNS

For details on how to configure each one of the above protocols, please, refer to the Arista EOS User Manual.

Configuring VRF aware management is not mandatory and it needs to be determined based on customer’s requirements.

Idle Timeout

Idle timeout defines the connection period between the last command entered and the automatic connection shutdown. By default, idle timeouts are set to zero, which means that the sessions will be never automatically disconnected. This can potentially become a security issue if the user doesn’t exit the console, Telnet, or SSH session. Especially in console sessions where an unauthorized user with physical access to the switch can gain admin access through a console session left open. It is recommended, then, to configure idle timeouts.

The following example sets an idle timeout of 15 minutes to the console port:

Arista(config-mgmt-console)#idle-timeout 15

And the next example sets an idle timeout of 15 minutes to the SSH connections:

Arista(config-mgmt-ssh)#idle-timeout 15

Additional Management and Security Best Practices

• Use always the management interface for management related tasks.
• Use trusted NTP sources and enable NTP authentication.
• Configure Syslog and send logs to a central Syslog server.
• Use SFTP or SCP for transferring files over the network instead of TFTP or FTP.
• Disable LLDP on ports where is not necessary.
• Visit http://www.aristanetworks.com/en/support/securityadvisories for the latest security advisories.