eos.arista.

com

https://eos.arista.com/securing-eos-cli/

Securing EOS CLI

By admin

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 passwords 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
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 Aristas 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

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
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
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
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:
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
companys 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:
Arista(config)#ip access-list standard mgmt-acl
Arista(config-std-acl-mgmt-acl)#permit 192.168.1.0/24
Arista(config-std-acl-mgmt-acl)#exit
Arista(config)#snmp-server community ro mgmt-acl

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 . 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 priv aes
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 snmpserver command:
Arista(config)#no snmp-server
Arista(config)#show snmp
SNMP agent enabled in VRFs: default
SNMP agent disabled: no communities or users configured

Command API
EOS Command API is Aristas 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 customers 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
doesnt 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)#management console
Arista(config-mgmt-console)#idle-timeout 15
And the next example sets an idle timeout of 15 minutes to the SSH connections:
Arista(config)#management ssh
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.