Device access control e AAA

Perché proteggere l’accesso al device

Un router o switch enterprise espone diversi punti di ingresso amministrativo: la console (accesso fisico), le linee VTY (accesso remoto via SSH/Telnet) e la porta AUX. In ENCOR il principio guida è difesa in profondità: prima si mette in sicurezza l’accesso locale al singolo device, poi si centralizza il controllo con AAA verso un server esterno come Cisco ISE.

Enable secret e privilege level

La password di accesso all’enable mode (privileged EXEC) va sempre configurata con enable secret, non con enable password. La differenza è sostanziale:

I privilege level vanno da 0 a 15: il livello 1 è lo user EXEC, il 15 è il privileged EXEC completo, mentre lo 0 è minimale. Assegnando comandi a livelli intermedi (es. 5, 10) si costruisce un RBAC granulare sul singolo device. Con service password-encryption si offusca (debolmente, type 7) tutte le password in chiaro nella running-config.

Login locale sulle linee

Per proteggere le VTY con il database utenti locale:

username admin privilege 15 secret <pwd>
line vty 0 15
 login local
 transport input ssh

login local forza l’autenticazione contro gli account definiti con username; transport input ssh disabilita Telnet in chiaro. È l’approccio corretto per device isolati o come fallback quando il server AAA non risponde.

AAA: le tre A

AAA disaccoppia tre funzioni distinte:

• Authentication — chi sei (verifica credenziali)
• Authorization — cosa puoi fare (comandi, privilege level, VLAN)
• Accounting — cosa hai fatto (logging di sessioni e comandi)

Si abilita con aaa new-model e si definiscono method list, ovvero sequenze ordinate di metodi provati fino al primo che risponde. La best practice è includere sempre local come ultimo metodo di fallback:

aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local

Senza il fallback local, se il server AAA diventa irraggiungibile ci si può chiudere fuori dal device (lockout).

TACACS+ vs RADIUS

Entrambi lavorano con Cisco ISE, ma hanno vocazioni diverse.

TACACS+ è ideale per l’amministrazione dei device: separa autorizzazione e accounting, permettendo di autorizzare comando per comando (aaa authorization commands 15 ...) e di cifrare l’intero scambio. RADIUS è la scelta per l’accesso di rete degli endpoint (802.1X, MAB, VPN) perché fonde authn e authz in un unico scambio Access-Request/Access-Accept, veicolando gli attributi di policy (VLAN, dACL) nella risposta.

Configurazione verso Cisco ISE

tacacs server ISE-1
 address ipv4 10.1.1.10
 key <shared-secret>
!
radius server ISE-1
 address ipv4 10.1.1.10 auth-port 1812 acct-port 1813
 key <shared-secret>

La shared key deve coincidere sul device e su ISE. Su IOS-XE si preferisce la sintassi tacacs server/radius server (named server) rispetto ai vecchi comandi globali tacacs-server host, ormai deprecati.

Trappole tipiche d’esame

• Scenario: device admin con cifratura completa del traffico AAA e autorizzazione per-command → risposta: TACACS+ (TCP 49, cifra tutto il payload), non RADIUS.
• Scenario: accesso 802.1X/VPN degli endpoint con push di VLAN e dACL → risposta: RADIUS (UDP, combina authn/authz), non TACACS+.
• Scenario: dopo aaa authentication login default group radius, il server ISE cade e nessuno può più loggarsi → risposta: mancava il fallback local nella method list (rischio lockout).
• Scenario: serve proteggere l’enable con hashing forte → risposta: enable secret (type 5/9), non enable password (type 7 reversibile).
• Scenario: un admin deve eseguire solo un sottoinsieme di comandi → risposta: assegnare i comandi a un privilege level intermedio (o command authorization TACACS+), non dare privilege 15.
• Scenario: confusione sulle porte → risposta: RADIUS auth 1812 e accounting 1813 (legacy 1645/1646); TACACS+ TCP 49.