PermitANY
AristaConfig389 downloads

Arista EOS Security Hardening

CIS-aligned security hardening for Arista EOS: password policy, management ACL, SSH restrictions, AAA with TACACS+, disable unused services, and control-plane hardening.

↓ example.txt

What is it?

Arista EOS hardening follows CIS Benchmark for Arista EOS and Arista's own Security Best Practices guide. Key areas: (1) Disable ZTP and unused services (HTTP, Telnet). (2) Enforce password complexity and lockout policy. (3) TACACS+ for centralized AAA with local fallback. (4) Management ACL to restrict SSH access to known management subnets. (5) Enable 'aaa accounting' to log every command executed — critical for compliance audit trails. EOS hardening is generally straightforward due to its clean architecture.

When to use

  • ·Before any production deployment — hardening is mandatory
  • ·After a security audit — management ACL, AAA accounting, and TLS enforcement are common findings
  • ·For PCI-DSS compliance — requirement 2 mandates no vendor defaults, requirement 10 mandates audit logging
  • ·After ZTP deployment — ZTP leaves default credentials that must be changed

When NOT to use

  • ·Lab environments — strict lockout and timeouts slow down testing

How it compares

vs Cisco IOS HardeningBoth use AAA, TACACS+, and management ACLs. Arista uses 'aaa authentication policy lockout' for lockout. IOS uses 'login block-for'. Arista's 'management ssh ip access-group' applies the ACL more cleanly than IOS VTY ACLs.
vs Palo Alto HardeningPalo Alto uses 'permitted-ip' for management ACL. Arista uses an extended ACL with 'ip access-group' on management SSH. Both enforce TLS 1.2+. Arista's AAA accounting is more granular for command-level logging.

Prerequisites

  • →Know all management workstation IPs before applying MGMT-ACCESS ACL — wrong entries cause lockout
  • →TACACS+ server must be reachable before changing 'aaa authentication login default group TACACS-GROUP local' — test first
  • →Record current admin password before changing password policy — policy enforcement happens immediately
  • →Have console access available as a backup before making hardening changes

Config Generator

Verification commands

show management ssh

Verify SSH hardening settings and access-group

ExpectedShows ciphers, MACs, idle-timeout, and applied ACL. Verify management ACL is applied.

show aaa

Show AAA authentication and authorization configuration

ExpectedShows authentication method lists (TACACS+ group + local fallback) and accounting settings

show ip access-lists MGMT-ACCESS

Show management ACL and hit counters

ExpectedLists permit entries for allowed management subnets and a deny-log entry at the bottom

Debug commands

show aaa counters

Show TACACS+ success and failure statistics

Common mistakes & fixes

SymptomLocked out after applying MGMT-ACCESS ACL
CauseManagement workstation IP not in the ACL permit list
FixUse console access. Remove or modify the ACL: 'no ip access-list MGMT-ACCESS' and recreate with correct IPs. Reapply to management SSH.
SymptomAll SSH logins failing after enabling TACACS+
CauseTACACS+ server unreachable or wrong key
FixLocal fallback should still work ('aaa authentication login default group TACACS-GROUP local'). Login with local credentials from console. Fix TACACS+ server IP and key.
SymptomAccount locked after failed login attempts
CauseLockout policy triggered
FixFrom console or another admin account: 'security login unlock username <user>'. Or wait for lockout duration (default 300 seconds).

Further learning

Recommended books to go deeper on this topic.

Network Security Architectures

Sean Convery · Cisco Press · Defense-in-depth, CoPP, control plane hardening, AAA design

CCNP Enterprise Core ENCOR 350-401 Official Cert Guide

Brad Edgeworth et al. · Cisco Press · AAA, RADIUS, TACACS+, device hardening best practices

Related configs