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

By admin

Securing EOS CLI

ObjectiveThis Tech Tip is intended to provide Arista EOS users with the configuration guidelines and best practices to enable secure management planeprotocols according to IT industry security standards. It is not the objective of this document to set the foundations or rules of a company securitypolicy 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 securitypolicy 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 insecurein nature and should be avoided whenever is possible and, instead, use secure alternatives provided by Arista EOS. Some of the examplesexhibited 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 UserManual and apply the configurations that best adapts to the company security policy.

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

Understanding Initial Access ConfigurationOut of the box, and whenever Zero Touch Provisioning is not being used for auto provisioning, users can access to the switch CLI through theconsole 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 displaysystem information and perform basic tasks such as change terminal settings or connect to remote devices. The enable password is disabled andusers can gain access to Privileged EXEC (or privilege mode 15) mode by simply typing enable or en. The next output shows the default privilegelevel 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 AlgorithmArista EOS supports two modes of hashing algorithms to encrypt passwords: MD5 and SHA512. By default, Arista EOS encrypts all the passwordsconfigured in the system using the MD5 algorithm. It is commonly accepted that SHA512 provides a higher level of security to stored passwordsand it is recommended to use it whenever is possible. To change the default hashing algorithm configuration from MD5 to SHA512, configure itunder 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 encryptionalgorithm 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 secretsha512 $6$RMxgK5ALGIf.nWEC$tHuKCyfNtJMCY561P52dTzHUmYMmLxb/Mxik.j3vMUs8lMCPocM00/NAS.SN6GCWx7d/vQIgxnClyQLAb7n3x0

Local Authentication and Enable PasswordArista EOS supports three access control methods: local security database, TACACS+, and Radius. The admin user and subsequent userscreated 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 orTACACS+ 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 usersince 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. Toknow 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. Bydefault, 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+ AuthenticationRadius and TACACS+ methods allow administrators to centrally manage AAA for the entire network, and are key elements of the securityinfrastructure. 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 leasttwo 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 UserAccess 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, andwill 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, likethe 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 ControlUsing 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 packetsdenied.

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 additionallevel 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 touse 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 thecompany’s password policy as if they were passwords. To add an additional level of security, and as in the SSH example shown before, the sourceof 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 ageneral security best practice. In addition to username and password authentication, it also provides message integrity, and confidentiality throughthe 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 aread-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 snmp-server 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 APIEOS Command API is Arista’s JSON programmable interface that allows applications and administrators to have complete control over EOS usingindustry standard CLI served over HTTP or HTTPS. The Command API is disabled (shutdown) by default and, once enabled, can be accessed overHTTPS only. It is not recommended to enable HTTP unless is strictly necessary being that the username and passwords will be sent in clear textover 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 ManagementVPN Routing and Forwarding (VRF) allows traffic separation by maintaining multiple isolated routing tables. All the Arista switches support themanagement 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 datatraffic 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 managementinterface.

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 configuredagain, 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 TimeoutIdle timeout defines the connection period between the last command entered and the automatic connection shutdown. By default, idle timeoutsare set to zero, which means that the sessions will be never automatically disconnected. This can potentially become a security issue if the userdoesn’t exit the console, Telnet, or SSH session. Especially in console sessions where an unauthorized user with physical access to the switch cangain 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 PracticesUse 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.