Device access control e AAA

La sicurezza di un dispositivo Cisco inizia dal controllo di chi può accedere alla CLI e da come vengono protette le credenziali. Nell’esame CCNA questo tema unisce due livelli: l’hardening locale del singolo device e l’autenticazione centralizzata tramite AAA.

Password locali e loro cifratura

Su un router o switch IOS/IOS-XE esistono diversi tipi di password, con robustezza molto diversa:

Il punto chiave: service password-encryption è debole. Applica la cifratura Type 7 alle password in chiaro presenti nella config (console, VTY, enable password), ma è facilmente reversibile con tool offline. Serve solo a evitare lo “shoulder surfing” di chi legge la running-config, non è vera sicurezza.

enable secret invece salva un hash (MD5 di default, oppure SHA-256/scrypt con algorithm-type sha256|scrypt su IOS-XE): non è reversibile e ha sempre precedenza su enable password. Per gli account locali si usa username admin secret <pwd> (hashato) e mai username admin password <pwd> (in chiaro).

enable secret <password>
username admin privilege 15 secret <password>
service password-encryption

Accesso remoto sicuro con SSH

Le linee VTY governano l’accesso remoto. Telnet trasmette tutto in chiaro e va sostituito con SSH (idealmente SSHv2). I prerequisiti per generare le chiavi:

hostname R1
ip domain-name example.local
crypto key generate rsa modulus 2048
ip ssh version 2
line vty 0 4
 transport input ssh
 login local

crypto key generate rsa richiede hostname e domain-name già configurati (servono a comporre l’etichetta della chiave RSA). login local obbliga l’uso del database utenti locale; transport input ssh disabilita Telnet sulle VTY. Vanno completati con banner legali (banner motd), exec-timeout brevi e login block-for per mitigare brute force.

Politiche di password e fattori di autenticazione

L’hardening moderno prevede complessità minima (security passwords min-length), rotazione e, per gli accessi umani, fattori aggiuntivi. Nell’esame ricorrono i concetti di MFA (qualcosa che sai + qualcosa che hai/sei), certificati digitali e biometria: sono meccanismi che rafforzano l’autenticazione ma vengono orchestrati da un server centrale, non dal singolo IOS.

AAA: authentication, authorization, accounting

Gestire utenti locali su decine di device non scala. AAA centralizza tre funzioni distinte:

• Authentication — verifica dell’identità (chi sei);
• Authorization — cosa puoi fare (comandi, privilege level);
• Accounting — cosa hai fatto (log, audit).

Il device diventa un NAS/client AAA che interroga un server centralizzato. In casa Cisco il server è tipicamente Cisco ISE (Identity Services Engine), che applica policy uniformi, integra directory esterne, certificati e MFA. Configurazione tipica: aaa new-model, definizione dei server e delle liste di metodi, con fallback locale (local) per non restare tappati fuori se il server è irraggiungibile.

RADIUS vs TACACS+

I due protocolli AAA sono un classico dell’esame:

RADIUS cifra solo il campo password lasciando in chiaro username e attributi, usa UDP e fonde authentication e authorization in un’unica transazione: ideale per l’accesso end-user alla rete (802.1X). TACACS+ cifra l’intero corpo del pacchetto, gira su TCP e separa le tre A: questo permette autorizzazione granulare per singolo comando, perfetta per il device administration.

Trappole tipiche d’esame

• Scenario: serve proteggere davvero la password di enable → Risposta: enable secret (hash), non service password-encryption, che è Type 7 reversibile.
• Scenario: serve cifrare l’intero pacchetto e autorizzare i comandi per singolo admin → Risposta: TACACS+ (TCP/49, separa AAA), non RADIUS.
• Scenario: autenticazione 802.1X/Wi-Fi degli utenti di rete → Risposta: RADIUS (UDP, cifra solo la password).
• Scenario: crypto key generate rsa fallisce → Risposta: mancano hostname e ip domain-name; vanno impostati prima di generare le chiavi.
• Scenario: dopo login local sulle VTY nessuno entra → Risposta: manca un account con username ... secret ... nel database locale.