Arista EOS Hardening Guide


This document is provided as a template to securing Arista devices.
Configurations alone are not able to completely secure a network. Due operational diligence including threat assessment and reaction are necessary to ensure device security.
This document provides recommendations that you are advised to implement, however, no document can be comprehensive for every unique environment.

General Security Principles

A level of security ought to be applied to all network nodes. This should govern how nodes are accessed by users and what traffic is allowed to enter the nodes:

  • Each user should be assigned an individual user-account, with a security class and unique user ID.
  • A set of security classes to be identified for governing and limiting access to the appropriate level.
  • Secure protocols will be used for access of the nodes – EOS only permits SSH login by default.
  • Root account should not be able to directly log onto the nodes – root login is disabled by default.
  • Only specific ingress-traffic for a node should be allowed.
  • By default all other traffic types should be denied.
  • Routing protocol authentication should be enabled where possible.

Implementation of security policies should reflect the Operator’s own requirements and standards, bearing in mind more complex policies may incur an administration overhead.

Monitor Security Advisories and Responses

Arista maintains a Product Security Response Team, which is responsible for creating and publishing common security advisories for any security related vulnerability in an Arista product. These security advisory responses are available at:

Log Collection and Monitoring

Logging collection and monitoring will provide an understanding of the existing and historic events that may be related to any security vulnerability. It is recommended that you leverage a centralized logging facility to which all network devices subscribe. Other log analysis mechanisms are recommended to correlate any activities that could occur.
Please refer to the logging section of this document for more information on implementing logging on an Arista switch.

EOS binary distribution

Arista EOS is distributed as a compressed binary image. It has a .swi file type. Arista provides sha512 checksums along with the .swi image to validate integrity once the image is transferred to the flash storage of the device.

switch#verify /sha512 flash:EOS-4.17.0F.swi
verify /sha512 (flash:EOS-4.17.0F.swi) = 847d1c1d0cd69154568242a9603b6cc96041523db7c5703f3db90c46a97a19836862b46cf2c9a736bda30d6452362434a2ec828eef17305b05cda0dc91cd47a2

EOS core OS

Once the EOS .swi file is expanded into runtime memory, EOS runs as a modular operating system. EOS is based on a modern Linux 3.4.43 kernel, which is unmodified aside from the ASIC interface kernel module. EOS has an affinity for the Fedora Core 18 Distribution. Although we leverage the Fedora distribution, packages are carefully selected and packages that are nonessential for our OS have been removed. All packages that are used are done so under the GPL and are monitored for security vulnerabilities. The core OS also has inherent patching functionality, which allows in service mitigation of security vulnerabilities if they arise. The routing and switching functions that EOS provides are separated from the core OS kernel and isolated from each other in protected memory spaces.

The internal process tree

     |                                 |-Arp
     |                                 |-FanDetector
     |                                 |-Fru
     |                                 |-IgmpSnooping
     |                                 |-Lag+LacpAgent
     |                                 |-Launcher
     |                                 |-Lm73Agent
     |                                 |-Mirroring
     |                                 |-PhyEthtool
     |                                 |-PowerSupplyDete
     |                                 |-Sb820Agent
     |                                 |-Smbus
     |                                 |-Stp---{Stp}
     |                                 |-StpTopologyAgen
     |                                 |-SuperServer
     |                                 |-Sysdb
     |                                 |-Thermostat
     |                                 |-TopoAgent
     |                                 |-Ucd9012Agent
     |                                 |-XcvrAgent
     |                                 |-11*[netns]
     |                                 `-ribd
     |                                |-netnsd-session---Ira
     |                                |-netnsd-session---LedPolicyAgent
     |                                |-netnsd-session---PowerManager
     |                                |-netnsd-session---Acl
     |                                |-netnsd-session---PciBus
     |                                |-netnsd-session---Gn2405
     |                                |-netnsd-session---ScdAgent
     |                                |-netnsd-session---StrataAgent---9*[{StrataAgent}]
     |                                |-netnsd-session---Ebra
     |                                `-netnsd-session---Pmbus
     |      |                   |      `-pstree
     |      |                   `-{Cli}
     |      `-sshd---sshd---Cli---{Cli}

EOS services

The standard management protocols implemented in EOS leverage openly penetration tested services like sshd, rsyslogd, snmpd, ntpd and HTTPS with eAPI. These are based on open source packages that are up to date with all relevant security patches. Other services like routing protocols and MLAG are all disabled by default. The default control plane ACL entries filter connections to all available management interfaces.

The Control Plane ACL

The control plane is critical to all network operations as it is the component used to build all forwarding paths for the data plane. It is also instrumental with ongoing network management functions that keep the switches and links available for providing network services. Hence, any disruption to the control and management planes can result in mission critical network outages.
A DoS attack targeting the control plane can be perpetrated either inadvertently or maliciously involving high rates of punted traffic resulting in excessive control plane CPU and memory utilization. To maintain network stability the switch must be able to securely handle specific control plane and management plane traffic that is destined to it.
Control plane policing can be used to increase the security of Arista switches by protecting the control plane from unnecessary or malicious traffic. Filtering and rate limiting the traffic flow of control plane packets can be implemented to protect the switch against attacks. This allows the control plane to maintain packet forwarding and protocol states despite an attack.
The default control plane ACL filters all IP traffic inbound and outbound on any management interface. SSH, Telnet, NTP, SNMP, IP protocols, and logging/matching on management traffic are done by this ACL. The default control plane ACL permits the following protocols:

  • Telnet
  • SSH
  • HTTP/S
  • BootP
  • SNMP
  • ICMP
  • MLAG
  • IGMP
  • OSPF
  • BGP
  • VRRP
  • PIM
  • AHP
  • VNC

A sample of the default CP ACL

switch#show ip access-lists default-control-plane-acl
IP Access List default-control-plane-acl [readonly]
        statistics per-entry
        10 permit icmp any any [match 117, 0:09:50 ago]
        20 permit ip any any tracked [match 409, 0:00:00 ago]
        30 permit udp any any eq bfd ttl eq 255
        40 permit udp any any eq bfd-echo ttl eq 254
        50 permit ospf any any
        60 permit tcp any any eq ssh telnet www snmp bgp https msdp ldp [match 2, 0:00:10 ago]
        70 permit udp any any eq bootps bootpc snmp rip ntp ldp
        80 permit tcp any any eq mlag ttl eq 255
        90 permit udp any any eq mlag ttl eq 255
        100 permit vrrp any any
        110 permit ahp any any
        120 permit pim any any
        130 permit igmp any any
        140 permit tcp any any range 5900 5910
        150 permit tcp any any range 50000 50100
        160 permit udp any any range 51000 51100
        170 permit tcp any any eq cvx-license
        180 permit tcp any any eq nat ttl eq 255
        190 permit tcp any eq bgp any

switch#show ipv6 access-lists default-control-plane-acl
IPV6 Access List default-control-plane-acl [readonly]
        statistics per-entry
        10 permit icmpv6 any any
        20 permit ipv6 any any tracked
        30 permit udp any any eq bfd hop-limit eq 255
        40 permit udp any any eq bfd-echo hop-limit eq 254
        50 permit ospf any any
        60 permit 51 any any
        70 permit 50 any any
        80 permit tcp any any eq ssh telnet www snmp bgp https
        90 permit udp any any eq bootps bootpc snmp ntp
        100 permit tcp any any eq mlag hop-limit eq 255
        110 permit udp any any eq mlag hop-limit eq 255
        120 permit tcp any any range 5900 5910
        130 permit tcp any any range 50000 50100 hop-limit eq 255
        140 permit udp any any range 51000 51100 hop-limit eq 255
        150 permit udp any any eq dhcpv6-client dhcpv6-server
        160 permit tcp any eq bgp any
        170 permit tcp any any eq nat hop-limit eq 255
        180 permit udp any any eq nat hop-limit eq 255

The default control-place ACL can be re-configured to permit or deny additional protocols that can be matched via an extended access-list for management traffic. It is highly recommended to keep the default ACL as a template to ensure protocol and management operations function correctly.

A sample of the default CP policy map

It is recommended to implement control plane protection by classifying traffic types based on importance levels and configure filters to restrict and rate limit the traffic punted to the processor according to each class. The default configuration comes with a pre-configured policy map to ensure adequate rate limiting for most traffic types punted to the CPU.
The following is an extract of the default policy-map:

policy-map type control-plane copp-system-policy
   class copp-system-bpdu
      shape pps 5000
      bandwidth pps 5000
   class copp-system-lacp
      shape pps 5000
      bandwidth pps 5000
   class copp-system-bfd
      shape pps 10000
      bandwidth pps 5000
   class copp-system-mlag
      shape pps 5000
      bandwidth pps 5000
   class copp-system-vrrp
      shape pps 5000
      bandwidth pps 1000
   class copp-system-lldp
      shape pps 10000
      bandwidth pps 1000
   class copp-system-bgp
      shape pps 5000
      bandwidth pps 5000
   class copp-system-OspfIsis
      shape pps 10000
      bandwidth pps 5000
   class copp-system-pim
      shape pps 10000
      bandwidth pps 5000
   class copp-system-l3ttl1
      shape pps 10000
      bandwidth pps 1000
   class copp-system-urm
      shape pps 10000
      bandwidth pps 1000
======> output omitted < ======

Results of external stealth scan
~ @server> sudo nmap -sS -O -p 1-10000 switch

Starting Nmap 5.21 ( ) at 2016-08-03 06:25 PDT
Nmap scan report for switch
Host is up (0.00019s latency).
rDNS record for
Not shown: 9981 filtered ports
22/tcp   open   ssh
23/tcp   closed telnet
80/tcp   closed http
161/tcp  open   snmp
443/tcp  open   https
639/tcp  closed unknown
646/tcp  closed ldp
3333/tcp closed dec-notes
5900/tcp closed vnc
5901/tcp closed vnc-1
5902/tcp closed vnc-2
5903/tcp closed vnc-3
5904/tcp closed unknown
5905/tcp closed unknown
5906/tcp closed unknown
5907/tcp closed unknown
5908/tcp closed unknown
5909/tcp closed unknown
5910/tcp closed unknown

Device type: specialized|general purpose|webcam|PBX|WAP|firewall
Running (JUST GUESSING) : Crestron 2-Series (91%), Linux 2.6.X|2.4.X (91%), AXIS Linux 2.6.X (88%), Vodavi embedded (88%), Gemtek embedded (86%), Siemens embedded (86%), Check Point embedded (85%), Check Point Linux 2.4.X (85%)

OS detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 28.69 seconds

VLAN Management

VLAN 1 is a special VLAN that tags and handles most of the control plane traffic. VLAN 1 is enabled on all trunks and ports by default. Instability in one part of the network could affect VLAN 1, thereby influencing control-plane stability and therefore STP stability for all other VLANs.
Ensure VLAN1 is pruned from all trunk and access ports that do not require it.

vlan 1
   state suspend #disable VLAN 1 altogether
interface Ethernet 1

   switchport trunk native vlan 1000 #change native VLAN to 1000 
   switchport trunk allowed vlan except 1 #allow all VLANs except VLAN 1

Alternatively, you can use trunk groups to determine which trunks service which VLANs:

vlan 1
   trunk group DO_NOT_USE

If switchports are not a member of the trunk group “DO_NOT_USE”, that VLAN(s) will not be serviced by the switchport(s).

Trunk configuration

An attack could be initiated by an attacker who has access to the native VLAN of a switch. The attacker would need to know the MAC address and have a path from one device through the network to the destination network. This path is often created through by allowing the native VLAN on all trunk ports.
The first defense against these attacks is to ensure that only the necessary ports are configured for trunking. Only configure trunking where necessary and disable trunking on all unnecessary access ports.
Configuration example:

interface Ethernet 1

   switchport mode access #unconditionally configures the port as “access”

In order to minimize an attackers ability to forge a path throughout the entire network, it is recommended that VLAN 1 be suspended from use on trunk ports and a new native VLAN should be defined.
Configuration example:

vlan 1

    state suspend #disable VLAN 1 altogether
interface e1

    switchport trunk native vlan 1000 #change native VLAN to 1000

Device Access

Password Management

Once a management connection is made, passwords are the next line of defense on limiting access to a switch. The Arista switches use a series of passwords or secret keys to authenticate the user to the device. The standard response/reply is challenged when a user provides their password. The user can be allowed access or denied access based upon the security configuration within the device. Leveraging mechanisms such as TACACS+ the user can also be granted access on a limited basis including limiting their ability to execute specific commands from the CLI. It is necessary to configure a locally administered password in the case where a TACACS+ server is unavailable and device access is needed.
It is recommended that the enable secret password be used at all times to grant administrative access to the Arista switch. For configuration information on the enable password please see the Arista Configuration Guide.
The default switch configuration allows usernames that are not password protected to log in only from the console. The aaa authentication policy local command configures the switch to allow unprotected usernames to log in from any port. To reverse this setting to the default state, use no aaa authentication policy local allow-nopassword-remote-login.

Common security practices specify the following password complexity recommendations:

  • Minimum password size: 8 characters
  • Should not be based on a dictionary or known word such as username, server name, owner (e.g. Arista, Ubuntu, etc).
  • Password should contain characters from at least 3 of the following 4 character sets:
    1. uppercase characters ‘A’ – ‘Z’
    2. lowercase characters ‘a’ – ‘z’
    3. numbers ‘0’ – ‘9’
    4. other, e.g. !ӣ$%^&*()@

FIPS restrictions

The switch must use FIPS­ validated encryption algorithms to fulfill Common Criteria requirements. To do this one would run the following commands:

management security
        entropy source hardware
management ssh
        fips restrictions
reset ssh hostkey rsa #regenerates RSA key pair

The following set of commands will put the SSH server and SSH Tunnels on the switch into a Common Criteria approved mode:

management ssh
        cipher aes128-­cbc aes256-­cbc
        key­-exchange diffie-­hellman-­group-14-­sha1
        mac hmac­-sha1
        hostkey server rsa
        hostkey client strict­-checking
        log­-level verbose
        idle-­timeout 10

Note that the “hostkey client strict-­checking” command means that any remote host connected to via SSH must have their hostkey saved on the switch prior to connecting or the connection
will be rejected. This only applies to connections made from the switch to an external host but not connections entering the switch. To add known hosts use the following command:

management ssh
        known-­hosts HOST rsa BASE_64_STR

Where HOST is the remote host and BASE_64_STR is the base64 portion of the public key to connect to. Since it is only the base64 portion key comments are not saved. It is a violation of Common Criteria requirements to use DSA keys.

User Role Management

Role based authorization is a method of restricting access to CLI command through the assignment of profiles, which are called roles to user accounts.
Each role consists of rules that permit or deny access to a set of commands within specified command modes.

show role
The default role is network-operator

role: network-admin
        10 permit command .*
role: network-operator
        10 deny mode exec command configure|bash|python-shell|\|
        20 permit mode exec command .*

The default role is assigned to the following users:
• local or remote users assigned to a role that is not configured.
• local users to whom a role is not assigned.

When the default-role is not specified network-operator is assigned to qualified users as the default role. The network-operator role authorizes assigned users access to all CLI commands in EXEC and Privileged EXEC modes. However, it does not allow commands through which configuration changes can be made.

Additional custom roles can be defined as needed or AAA services – such as TACACS+ – can be used to provide more granular access to the switch.

The following operator role limits all the commands that can touch the file system and that can be used to escalate permissions. The forcing of “show run sanitized” may not be needed but it forces hiding passwords from non-authorized users.

role operator
   !! Note: Use ctrl-v as a Cli escape before entering the special character “?”
   10 permit command show running-config (all)? ?sanitized
   20 deny command >|>>|extension|\||session|do|delete|copy|rmdir|mkdir
   30 deny command python-shell|bash|platform|scp|append|redirect|tee|more|less|who|show run.*
   40 deny mode config command (no |default )?(username|role|aaa|tcpdump|schedule|event.*)
   50 permit command .*

Console Access

Network elements with no password for administrative access via the console provide the opportunity for anyone with physical access to the device to make configuration changes enabling them to disrupt network operations resulting in a network outage.
It is recommended to time-out access to the console port after 10 minutes or less of inactivity.
Configuration example:

management console
   idle-timeout 10

Emergency Console Access

Authentication for administrative access to the device should be required at all times. A single account should be created on the device’s local database for use in an emergency such as when the authentication server is down or connectivity between the device and the authentication server is not operable. The console or emergency account logon credentials should be stored in a secure location.
Configuration example:

#sha512 password hash should always be used if available#
management defaults
   secret hash sha512
username admin privilege 15 role network-admin secret 5uP3r_53Cr37_p455
#the result is the following line in running-config
username admin privilege 15 role network-admin secret sha512 $6$5TvDKp7afe5OBM2/$0BB5GMrdBbKox/wLhVaoLnUV9F2s6k8n9bs42StHnEi37owhb/BHpAIcwlomotORDmIBoCvfMie5myiemsJkd.

To further mitigate against an attacker with physical access an Aboot password should be configured:

switch(config)#boot secret 5uP3r_53Cr37_p455

Additionally a physical USB port lock should be installed to prevent USB access.

Management Interface

All ports, including the internal management interface are configured by default to be members of VLAN 1. In a VLAN-based network, Arista switches use VLAN 1 as the default VLAN for in-band management and to communicate with other networking devices. As a consequence, VLAN 1 may unwisely span the entire network if not appropriately pruned.
To maximize the security domain a dedicated management VLAN or VRF (introduced in EOS 4.10) should be defined to keep management traffic separate from user data and control plane traffic.
Configuration example:

vrf definition mgmt 
   rd 101:1
int vlan 44

   vrf forwarding mgmt

   ip address
   ip route vrf mgmt 0/0

In order to ensure the separation of management network traffic and normal production traffic it is recommended that the Management Interface be configured on a VLAN that does not exist in the normal production traffic. An alternative to this approach is to place the management interface in a different management VRF. Once VRF is introduced on the switch, SSH access will be enabled on the VRF interfaces automatically. This can be changed by shutting down SSH management in the undesired VRFs:

management ssh
   vrf management
      no shutdown
   vrf prod1

*** Please note the "no shutdown" MUST be configured under the desired VRF before the "shutdown" statement under the global VRF

switch(config)#management ssh
switch(config-mgmt-ssh)#vrf management
switch(config-mgmt-ssh-vrf-management)#no shutdown

If a VLAN is utilized on the management VRF it is recommended that this VLAN be removed from all trunk interfaces on the production network.

vlan 1
   state suspend #disable VLAN 1 altogether 
interface Ethernet1
   switchport trunk native vlan 1000 #change native VLAN to 1000 
   switchport trunk allowed vlan except 1 #allow all VLANs except VLAN 1

Alternatively you can use trunk groups to determine which trunks service which VLANs:

vlan 1

   trunk group DO_NOT_USE

If switchports are not a member of group “DO_NOT_USE”, that VLAN(s) will not be serviced by the switchport(s).


TACACS+ is an authentication protocol that can be used for authentication of management users against a remote AAA server. TACACS+ provides the ability to provide each individual a specified administrative account which eliminates the need for a single shared admin password.

RADIUS is a similar protocol to TACACS+ and can be used to provide similar level functionality, however, RADIUS only encrypts the password in the packet which doesn’t protect the username and accounting information.
Please note that as TACACS+ encryption is considered weak and outdated by current standards an additional layer of security should be added for enhanced protection. SSH Tunnels detailed later provide this functionality.

TACACS+ makes it possible to have different methods and servers for authentication, authorization, and accounting whereas RADIUS combines authentication and authorization.
Lastly TACACS+ can restrict the commands specific users can run thus allowing for more granular control over network functions and services.

Utilizing TACACS+ or RADIUS as a network control mechanism will assist in preventing unauthorized access and will enforce the organization’s security policy. Levels of access should be defined based upon the needs of the administration and operations of the network. Authorization requires an individual account identifier that has been approved, assigned, and configured on an authentication server. Lack of authentication has inherent risks, which could include a security breach and catastrophic network outages.

Authentication, Authorization, and Accounting

The Authentication, Authorization, and Accounting (AAA) framework is essential to securing a network device. The AAA framework provides a mechanism to authenticate and limit specific actions being performed within a management session. AAA also allows for accounting and logging of any commands that are executed within a management session.
Configuration example:

aaa group server tacacs+ tacplus 
aaa authentication login default group tacacs+ local

aaa authentication enable default group tacacs+ local

aaa authorization exec default group tacacs+ local

aaa authorization commands all default group tacacs+ local

The use of Authentication, Authorization, and Accounting (AAA) affords the best methods for controlling user access, authorization levels, and activity logging. By enabling AAA on the switches in conjunction with an authentication server such as TACACS+ or RADIUS the administrators can easily add or remove user accounts, add or remove command authorizations, and maintain a log of user activity.
It is recommended to use two or more authentication servers for the purpose of granting administrative access.
Configuration example:

aaa group server tacacs+ tacplus

Login Banner

A legal banner is recommended on all external administrative interfaces.
The purpose of a legal banner is to:

  • Provide Legal Protection should evidence need to be used from a device.
  • Act as a deterrent to potential intruders.
  • This banner must be displayed prior to login.

There are certain items that must be included in a legal banner. These include:

  • Statement that the device is for authorized users only.
  • The device is for official use only.
  • Users have no expectations of privacy.
  • All access and use may (not will) be monitored and/or recorded.
  • Monitoring and/or recording may be turned over to the appropriate authorities.
  • Use of the system implies consent to the previously mentioned conditions.

The banner must not contain:

  • Mention of the purpose, location or owner of the device or any other identification information.
  • It should not say “Welcome” anywhere in the description.


                             *** WARNING ***

This system is private and may be accessed only by authorized users for official purposes.  The system owner reserves the right to monitor any and all activity taking place on this system and any attempts to connect to it. Individuals using this computer system are subject to having all of their activities monitored and recorded by system personnel.  Use of this system evidences an express consent to such monitoring and agreement that if such monitoring reveals evidence of possible abuse or criminal activity, system personnel may provide the results of such monitoring to appropriate officials. Unauthorized users or users who exceed (or attempt to exceed), their authorized level of access are subject to prosecution under any local or international laws that apply as well as Company initiated proceedings.

Network Time Protocol

Without synchronized time accurately correlating information between devices becomes difficult, if not impossible. If logs cannot be successfully compared between each of the routers, switches, and firewalls, it will be very difficult to determine the exact events that resulted in a network breach incident. NTP provides an efficient and scalable method for network elements to synchronize to an accurate time source.
A trusted time source is important to ensure proper logging and correlation of events to a syslog server where forensic information can be gathered in addition to any information concerning potential threats.
The NTP authentication model is the opposite of the typical client-server authentication model. NTP authentication enables an NTP client or peer to authenticate time received from their servers and peers. It’s not used to authenticate NTP clients because NTP servers don’t care about the authenticity of their clients as they never accept any time from them.
If possible it is recommended to configure more than one NTP server and configure authentication between the NTP server and peers.
Configuration Example:

ntp authenticate
ntp authentication-key 234 sha1 timeSync
ntp trusted-key 234
ntp server local-NTP
ntp server prefer
ntp server

DNS Configuration

The susceptibility of IP addresses to spoofing translates to DNS host name and IP address mapping vulnerabilities. For example, suppose a source host wishes to establish a connection with a destination host and queries a DNS server for the IP address of the destination host name. If the response to this query is the IP address of a host operated by an attacker, the source host will establish a connection with the attacker’s host, rather than the intended target. The user on the source host might then provide logon, authentication, and other sensitive data.
It is recommended that a DNS server be defined for client resolver.
Configuration example:

ip name-server

ip name-server

ip domain-name


Logging is a critical part of network security. Maintaining an audit trail of system activity logs (syslog) can help identify configuration errors, understand past intrusions, troubleshoot service disruptions, and react to probes and scans of the network. Syslog levels 0-6 are the levels required to collect the necessary information to help in the recovery process.
It is recommended to log all messages except debugging and send all log data to a syslog server.
Configuration example:

logging trap 6
logging host

The network element should only allow management connections for administrative access from hosts residing in the management network.
It is recommended to review the configuration and verify management access to the device is allowed only from hosts within the management network.
Example Configuration:

vrf definition mgmt
   rd 101:1 
int vlan 44
   vrf forwarding mgmt
   ip address

ip route vrf mgmt 0/0 
tacacs-server host vrf mgmt
management ssh
   vrf mgmt
      no shutdown

It is recommended to log all attempts to establish a management connection for administrative access.

SNMP Access

Detailed information about the network is sent across the network via SNMP. If this information is discovered by attackers it could be used to trace the network, show the network topology, and possibly gain access to network devices.
Only allow SNMP access from addresses belonging to the management network.
Configuration example:

vrf definition mgmt 
   rd 101:1
int vlan 44

   vrf forwarding mgmt

   ip address
ip route vrf mgmt 0/0
snmp-server vrf mgmt

Enabling write access to the device via SNMP provides a mechanism that can be exploited by an attacker to set configuration variables that can disrupt network operations.
Only allow SNMP read access and ensure that the default or well-known SNMP community strings public and
 private are not used. Also an ACL can be used to further restrict which remote hosts can query the switch.
Configuration example:

snmp-server community community1 ro  snmp-security-acl

The network element should use SNMP Version 3 for any SNMP agent configured on the device.
Configuration example:

snmp-server group group1 v3 priv

snmp-server user user1 group1 v3 auth sha 12345 priv aes 12345 
snmp-server engineID remote server1 1234567890

snmp-server host server1 version 3 priv user1

Routing Protocols

IGP Routing Protocols

Securing the routing protocols is an essential task to minimize the ability for a rogue device to send incorrect information and potentially disrupt the forwarding plane. Using fictitious information could also allow an attacker the ability to send information to an unsecure location where the data could be captured and analyzed.
It is recommended to authenticate all IGP Peers:
Configuration example:

interface vlan 12
   ip ospf authentication

   ip ospf authentication-key md5  
   ip ospf authentication message-digest

BGP Routing Protocol

Securing an IGP is important for internal threats to a network. When utilizing BGP the threat profile becomes much larger as routes external to the data center will be updating routing information in the devices. Much like with the IGP an attacker could redirect traffic to an insecure location where traffic could be analyzed and confidential information extracted. In the case of BGP a peer AS can send erroneous prefix information and as a result could allow packets to be sent to an insecure network.
It is recommended that peer authentication be used for all peers. A password or key should be defined for each BGP neighbor regardless of the peer’s autonomous system.
Configuration example:

router bgp 1
   neighbor password1

The default system security configuration

The configuration sample below demonstrates the default security configuration and available services that can be configured. Note that only SSH is enabled by default. All cleartext protocols (telnet, SNMP) are disabled by default.

management console
   idle-timeout 0
management ssh
   idle-timeout 0
management telnet
   idle-timeout 0
aaa authentication login default local
no aaa authentication login console
aaa authentication enable default local
no aaa authorization console
no aaa authorization exec default
no aaa authorization commands all default
aaa authorization config-commands
no aaa accounting exec console
no aaa accounting commands all console
no aaa accounting exec default
no aaa accounting commands all default
no enable secret
no aaa root
no aaa authentication policy local allow-nopassword-remote-login
username admin privilege 1 nopassword
no radius-server key
radius-server timeout 5
radius-server retransmit 3
no radius-server deadtime
no snmp-server engineID local
no snmp-server chassis-id
no snmp-server contact
no snmp-server location
no snmp-server source-interface
snmp-server enable traps
default snmp-server enable traps entity
default snmp-server enable traps lldp
default snmp-server enable traps snmp
default snmp-server enable traps spanning-tree
default snmp-server enable traps test
spanning-tree mode mstp
spanning-tree max-age 20
spanning-tree forward-time 15
spanning-tree transmit hold-count 6
spanning-tree max-hops 20
no spanning-tree portfast bpduguard default
no spanning-tree loopguard default
spanning-tree bpduguard rate-limit default
spanning-tree mst 0 priority 32768
   ip access-group default-control-plane-acl in
no tacacs-server key
tacacs-server timeout 5
no banner login
no banner motd

Supported Management and Security Features

  • Out of band management via dedicated port
  • In-band Management
  • SSHv2
  • Telnet
  • Control-Plane Access Control Lists (CP-ACL)
  • TACACS+ Authentication and Authorization (PAP)
  • TACACS+ Accounting
  • RADIUS Authentication
  • RADIUS Accounting
  • RADIUS Authorization
  • Management port isolation
  • Syslog
  • File download via SCP, HTTP, HTTPS, FTP and TFTP
  • Login and MOTD banners
  • SSH Host Keys
  • User-configurable Hardware Control Plane Policing
  • Management VRF
  • Role Based Access Control
  • SNMP v2, SNMP v3

A full list of features can be found here:

Frequent Questions

  • Q1. Can customers register for automatic security alerts?

A. Yes, there is an RSS Service from

  • Q2. Where does Arista post Security alerts?

A. Security Bulletins are posted on the Support Site at Registered access is required.

  • Q3. How can a potential security issue be reported to Arista Networks?

A. Report security vulnerabilities found in Arista products to the PSIRT team via It is recommended to use Aristas PGP key for secure communication. More info can be found at

  • Q4. Is there a guide, or best practice list of things to change, or an existing report from a security penetration scan?

A. Default nmap scan results are in this document. No defaults need to be modified to pass a port scan test.

  • Q5. Is a customer responsible for loading any security fixes to the Linux system or making changes to default settings?

A. Customers are not responsible for patching any Linux specific packages or the kernel. If there is an EOS vulnerability we will release a version of EOS that mitigates the risk. We do not recommend that customers patch the EOS system with a standard Fedora RPM for security purposes.

  • Q6. What is the policy on security alerts and response time for release of fixes?

A. From a core OS perspective Arista actively monitors CERT and if there is a vulnerability are quick to respond and update with a field notice/security advisory.

Tips & Tricks:

SSH tunnels

To provide an additional layer of security and encryption the Arista switches can use SSH tunnels to transport TCP traffic for protocols like TACACS+ and Syslog (with TCP transport). This requires configuration on both the SSH server and the SSH client(the switch in this case).
For example, the configuration required to tunnel TACACS+ traffic is as follows:

  • Server config
  • SSH server must allow TCP forwarding. For Linux based servers this is achieved by un-commenting the

    "#AllowTcpForwarding yes"

    line which is found in the sshd config file


    The public SSH key from the client switch must be added in the relevant authorized_keys file. Use the “show management ssh hostkey rsa public” command to display the public SSH key on an Arista switch.

    switch# show management ssh hostkey rsa public
    ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDKXeSQT5GgbV9n8CR6o4Zjt2YJt1qaBmfpD3jPlPBbtvvQr9t+isuyLx7aNjNYtBo9gI8IXxziiXNw+aIaWAUByKsspxHuciuMpmr4f5Imj15qGyx4IknsAxcLAv7ywEupsQ22QZawhEImOFjbNHaESSAcEMmA5lem2dqIkBFPfsJY+1zKg8NYasYn2qUG4icvqAG0n+gcmYfICytlhSSeOUfydWoMgGiRQP1GX9Q2z16Ew5XnhUsoEgA3JiFKzTeHZ2tpSNVsipjczwWF32E7stMeZkh2pHkHGv2CxBNjctLIdX+hDTzz+0GY1AK56jAf18M+LrqaWhWvL18ZiI15 chassisAddr=00:1c:73:69:1d:55
  • Switch config
  • switch(config)#management ssh
    switch(config-mgmt-ssh)#tunnel tacacs-protection
    switch(config-mgmt-ssh-tunnel-tacacs-protection)#ssh-server user tacacs port 22
    switch(config-mgmt-ssh-tunnel-tacacs-protection)#local port 49
    switch(config-mgmt-ssh-tunnel-tacacs-protection)#remote host port 49
    switch(config-mgmt-ssh-tunnel-tacacs-protection)#no shutdown

    To check the status of the tunnel “show management ssh” should be used:

    switch(config)#show management ssh
    SSHD status for Default VRF is enabled
    SSH Tunnel Information:
    SSH Tunnel tacacs-protection
     Status :                                                     established
     Local Port :                                                          49
     SSH Server:Port :                                  tacacs@
     Remote Host:Port :                              
     Max Packet Drops :                                3 packets / 10 seconds
     Restart Count :                                                        0
     Last Restart Time :                                                never
     Last Restart Cause :

    Next configure the “tacacs-server host” pointing to the local host and the local port configured earlier. This will ensure all TACACS+ traffic is sent via the SSH tunnel to the remote tunnel endpoint.

    switch(config)#tacacs-server host port 49 key 7 070E33455D1D18

    Before the tunnel was in place, TACACS+ traffic would be easily identified when sniffed: > Flags [F.], seq 100, ack 20, win 115, options [nop,nop,TS val 377387354 ecr 4187840792], length 0

    After the tunnel is established the traffic will look like a common ssh connection: > Flags [P.], seq 3140:3176, ack 3110, win 201, options [nop,nop,TS val 377390393 ecr 4187852948], length 36

    Multiple TACACS+ servers can be defined with the caveat that each will require its own unique ssh tunnel and local port.