Arista EOS Hardening Guide

eos.arista.com/arista-eos-hardening-guide

Ethan Rahn August 24, 2016

Contents [hide]

Introduction
General Security Principles
Monitor Security Advisories and Responses
Log Collection and Monitoring
EOS binary distribution
EOS core OS
The internal process tree
EOS services
The Control Plane ACL
A sample of the default CP ACL
A sample of the default CP policy map
VLAN Management
Trunk configuration
Device Access
Password Management
FIPS restrictions
User Role Management
Console Access
Emergency Console Access
Management Interface
TACACS+/RADIUS
Authentication, Authorization, and Accounting
Sample tac_plus Configuration
SSL certificate and key management
Login Banner
Network Time Protocol
DNS Configuration
Logging
Reload Console Logs
SNMP Access
Routing Protocols
IGP Routing Protocols
BGP Routing Protocol
The default system security configuration
Supported Management and Security Features

1/26
 Frequent Questions
Tips & Tricks:
SSH tunnels

Introduction
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:
http://www.arista.com/en/support/security-advisories

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

2/26
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) =
847d1c1d0cd69154568242a9603b6cc96041523db7c5703f3db90c46a97a19836862b46cf2c9a736bda30d

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

3/26
init-+-EosOomAdjust
|-ProcMgr-master---ProcMgr-worker-+-Aaa---3*[{Aaa}]
| |-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
|-crond
|-dbus-daemon
|-7*[mingetty]
|-netnsd-watcher---netnsd-server-+-netnsd-session---Lldp
| |-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
|-ntpd
|-2*[python---inotifywait]
|-rsyslogd---3*[{rsyslogd}]
|-sshd-+-sshd---sshd---Cli-+-bash-+-more
| | | `-pstree
| | `-{Cli}
| `-sshd---sshd---Cli---{Cli}
|-tail
|-udevd---2*[udevd]
|-watchdog---wdog-cld
`-xinetd

EOS services

4/26
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

5/26
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

6/26
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

7/26
Starting Nmap 5.21 ( http://nmap.org ) at 2016-08-03 06:25 PDT
Nmap scan report for switch
Host is up (0.00019s latency).
rDNS record for 1.2.3.4: switch.aristanetworks.com
Not shown: 9981 filtered ports
PORT STATE SERVICE
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
MAC Address: AA:BBC:CC:DD:EE:FF

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

http://nmap.org/submit/ .
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

8/26
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:

9/26
 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-ctr aes256-ctr
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

10/26
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 deny mode config-router-general-control-functions command (pull |push ).*
60 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

11/26
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/BHpAIcwlomotORDm

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 10.20.20.1/24
ip route vrf mgmt 0/0 10.20.20.2

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:

12/26
management ssh
shutdown
vrf management
no shutdown
!
vrf prod1
shutdown

*** 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
switch(config-mgmt-ssh-vrf-management)#exit
switch(config-mgmt-ssh)#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+/RADIUS

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

13/26
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

server 172.17.55.123
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 server 172.17.55.123 server 172.17.55.124

Sample tac_plus Configuration

The following is a sample TACACS+ configuration to showcase a safe set of default
permit/deny commands. The basis for this configuration is the “network-operator” group
shown in the “User Role Management” section. This role is designed to be used with the
server located at https://shrubbery.net/tac_plus/

14/26
group = operatorgroup {
default service = permit
service = exec {
default attribute = permit
priv-lvl = 1
timeout = 0
idletime = 0

}
cmd = configure {
deny .*
}
cmd = bash {
deny .*
}
cmd = python-shell {
deny .*
}
cmd = | {
deny .*
}
}

One important detail to note here is that the pipe ( “|” ) operator is denied here. The pipe
operator is a powerful tool for allowing inputs to be transformed, filtered, and acted upon by
other tools. However the pipe operator can also be used to run bash commands, such as

show version | grep "unused" | bash -c "shutdown -t now"

which will shutdown the switch when ran. Because tac_plus uses regular expressions to
decide if commands should be allowed or disallowed it is possible to come up with
expressions that allow for smuggling in of bash commands. To illustrate this, consider the
following unsafe tac_plus configuration snippets:

cmd = | {
permit /^grep .*/
}

This will allow a command like the above show version | grep “unused” | bash -c “shutdown -t
now” to be ran.

Even a smarter regex such as

cmd = | {
permit /^grep ".*" <cr>/

will allow the same command to be ran. In this case the parenthesis match on the first ” next
to ‘grep’ and the final ” after ‘now’.

15/26
For this reason the pipe operator is generally considered unsafe to use unless it is by a
trusted network administrator.

SSL certificate and key management

SSL/TLS is an application-layer protocol that provides secure transport between client and
server through a combination of authentication, encryption and data integrity. SSL/TLS uses
certificates and private-public key pairs to provide this security. A user can manage
certificates, keys and also multiple SSL profiles. A SSL profile is a configuration which
includes certificate, key and trusted CA certificates used in SSL/TLS communication. A SSL
profile configuration can be attached to another EOS configuration which supports SSL/TLS
communication. Individual EOS features that use this infrastructure will document the details
of using SSL profile in their configuration. It is recomended that operators obtain a signed
certificate from their internal Certificate Authority (CA) to overwrite the default self-signed
certificate.

Only PEM (Privacy Enhanced Mail) encoded certificates and RSA keys are supported. A
PEM encoded certificate is enclosed between a header and footer.

-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----

A PEM encoded RSA key is enclosed between a header and footer.

—–BEGIN RSA PRIVATE KEY—–

—–END RSA PRIVATE KEY—–

You can copy certificate/key to the switch, using the ‘copy’ command. The certificate will be
copied to ‘certificate:’ file system and key will be copied to ‘sslkey:’ file system. The
certificate/key can be copied from any supported source URLs of the ‘copy’ command.

switch>enable

switch#!Copy a certificate
switch#copy file:/tmp/ssl/server.crt certificate:
Copy completed successfully.
switch#!Copy a RSA key
switch#copy file:tmp/ssl/server.key sslkey:
Copy completed successfully.

A SSL profile can be configured with a certificate and its corresponding RSA key. The public
key information in the certificate must match with the RSA key. This certificate and RSA key
pair are used to authenticate to the peer during SSL negotiation. The individual EOS features
that use SSL profile configuration will document whether the certificate and key configuration
is optional or mandatory.

16/26
For example the following configuration can be used to create a SSL profile which disables
TLSv1 support:

switch#conf
switch(config)#
switch(config)#management security
switch(config-mgmt-security)#ssl profile NoTLS1
switch(config-mgmt-sec-ssl-profile-NoTLS1)#tls versions 1.1 1.2
switch(config-mgmt-sec-ssl-profile-NoTLS1)#certificate server.crt key server.key
switch(config-mgmt-sec-ssl-profile-NoTLS1)#
switch(config-mgmt-sec-ssl-profile-NoTLS1)#management api http-commands
switch(config-mgmt-api-http-cmds)#protocol https ssl profile NoTLS1
switch(config-mgmt-api-http-cmds)#
switch(config-mgmt-api-http-cmds)#show management api http-commands
Enabled: Yes
HTTPS server: running, set to use port 443
HTTP server: running, set to use port 80
Local HTTP server: shutdown, no authentication, set to use port 8080
Unix Socket server: running, no authentication
VRFs: default
Hits: 0
Last hit: never
Bytes in: 0
Bytes out: 0
Requests: 0
Commands: 0
Duration: 0.000 seconds
SSL Profile: NoTLS1, valid
FIPS Mode: No
QoS DSCP: 0
Log Level: none
CSP Frame Ancestor: None
TLS Protocols: 1.1 1.2

Additional commands such as ‘cipher-list’ are a further way to customize the allowed TLS
options.

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.

17/26
 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.

Sample:

*** 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 172.16.0.23 prefer
ntp server 172.16.0.25

18/26
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 1.2.3.4
ip name-server 4.3.2.1
ip domain-name foo.com

Logging
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 10.1.1.1

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 10.20.20.1/24
ip route vrf mgmt 0/0 10.20.20.2
tacacs-server host 1.1.1.1 vrf mgmt
management ssh
shutdown
vrf mgmt
no shutdown

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

administrative access.

Reload Console Logs

19/26
Starting in the EOS-4.21.0F release, reload console logs are available to help in debugging
of unexpected reloads. The output of the serial console is available following any reload
whether it is planned or unplanned. This output can be used to help debug unexpected
reloads and complements the existing ‘show reload cause’ command.

By default, when supported, reload console logging is enabled. To disable it, use the
following command:

(config)#no hardware console persistent logging

The ‘show reload console status’ command shows if reload console logging is supported and
if it is enabled. If supported and enabled, it also shows the most recent logs. Up to 65536
bytes are recorded.

‘show reload console logs’ command allows viewing of this data.

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 10.20.20.1/24
ip route vrf mgmt 0/0 10.20.20.2
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

20/26
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 1.1.1.1 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.

21/26
!
management console
idle-timeout 0
!
management ssh
idle-timeout 0
!
management telnet
shutdown
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

22/26
!
control-plane
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: http://www.arista.com/en/support/supported-features

Frequent Questions
Q1. Can customers register for automatic security alerts?

A. Yes, there is an RSS Service from http://www.arista.com/support/securityadvisories-rss

Q2. Where does Arista post Security alerts?

A. Security Bulletins are posted on the Support Site at

http://www.arista.com/en/support/security-advisories. Registered access is required.

23/26
 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
psirt@arista.com. It is recommended to use Aristas PGP key for secure communication.
More info can be found at https://www.arista.com/en/support/advisories-notices

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

/etc/ssh/sshd_config

24/26
 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+isuyLx
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 10.83.12.22 user tacacs
port 22
switch(config-mgmt-ssh-tunnel-tacacs-protection)#local port 49
switch(config-mgmt-ssh-tunnel-tacacs-protection)#remote host 10.83.12.22 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@10.83.12.22:22
Remote Host:Port : 10.83.12.22:49
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 127.0.0.1 port 49 key 7 070E33455D1D18

Before the tunnel was in place, TACACS+ traffic would be easily identified when
sniffed:

172.28.160.227.59788 > 10.83.12.22.tacacs: 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:

172.28.160.227.33295 > 10.83.12.22.ssh: Flags [P.], seq 3140:3176, ack 3110, win 201,
options [nop,nop,TS val 377390393 ecr 4187852948], length 36

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

26/26