AAA - Authentication Authorization Accounting - RADIUS e TACACS+

Che cos'e'

#

AAA (Authentication, Authorization, Accounting) e' il framework concettuale che governa l'accesso alle risorse di rete. Non e' un protocollo ma un modello in tre fasi che ogni sistema di accesso deve implementare. RADIUS e TACACS+ sono i protocolli concreti che lo realizzano, con uso e architettura diversi.

Il framework AAA centralizza il controllo degli accessi di rete: chi entra (Authentication), cosa puo' fare (Authorization), cosa ha fatto (Accounting). RADIUS implementa AAA per VPN e Wi-Fi via UDP. TACACS+ implementa AAA separato per la gestione dei dispositivi Cisco via TCP.

TL;DR

#

1. Un utente vuole accedere alla VPN aziendale.
2. Il VPN Concentrator (NAS) riceve le credenziali ma NON le verifica lui stesso.
3. Le inoltro al RADIUS Server tramite UDP porta 1812.
4. RADIUS consulta Active Directory / LDAP per verificare le credenziali.
5. RADIUS risponde: Access-Accept (con VLAN e policy da applicare) o Access-Reject.
6. Il Concentrator apre (o nega) il tunnel. Tutto e' loggato sul RADIUS Accounting (porta 1813).

Il Framework AAA

#

AAA e' un modello in tre fasi sequenziali obbligatorie. Senza Authentication non c'e' Authorization, senza Authorization non c'e' niente di significativo da registrare nell'Accounting. I tre pilastri non sono opzionali: mancarne uno rompe la sicurezza del sistema.

RADIUS - Remote Authentication Dial-In User Service

#

RADIUS e' il protocollo AAA piu' diffuso per il controllo degli accessi di rete. Nato negli anni '90 per le connessioni dial-up, oggi gestisce VPN, Wi-Fi aziendale (WPA2/WPA3-Enterprise) e accesso agli switch. Il suo punto di forza e' la scalabilita': un unico RADIUS Server centralizza l'autenticazione per centinaia di switch, AP e VPN concentrator.

Flusso RADIUS con VPN Concentrator

#

Il VPN Concentrator (chiamato NAS - Network Access Server) non valida le credenziali direttamente. Le delega al RADIUS Server, che le confronta con il database delle identita' (AD / LDAP). Questo pattern vale anche per switch (802.1X) e Access Point Wi-Fi.

sequenceDiagram
    participant C as Client
    participant NAS as VPN Concentrator (NAS)
    participant R as RADIUS Server
    participant AD as Active Directory

    C->>NAS: 1 - Connessione VPN (user+password)
    NAS->>R: 2 - Access-Request (UDP 1812)
    Note over NAS,R: shared secret cifra la password
    R->>AD: 3 - Verifica credenziali su LDAP
    AD->>R: 4 - Credenziali valide / non valide
    R->>NAS: 5 - Access-Accept (VLAN 20, policy X) o Access-Reject
    NAS->>C: 6 - Tunnel VPN aperto o connessione negata
    NAS->>R: 7 - Accounting-Request (sessione aperta, UDP 1813)
    R->>NAS: 8 - Accounting-Response (ricevuto)

Lettura diagramma: Il NAS e' il proxy che raccoglie le credenziali e le invia al RADIUS (passo 2). RADIUS non ha il suo database utenti: lo delega all'AD/LDAP (passo 3-4). In caso di Access-Accept, RADIUS include anche gli attributi di autorizzazione (VLAN, policy) nello stesso messaggio. L'accounting (passi 7-8) e' separato su porta 1813.*

Perche' si chiama NAS? Network Access Server: e' il server che fa da "cancello" per l'accesso alla rete. Non decide lui - raccoglie, delega, applica. Il termine nasce dal mondo dial-up ma si usa ancora per VPN concentrator, switch, AP.

TACACS+ - Terminal Access Controller Access-Control System Plus

#

TACACS+ e' il protocollo AAA sviluppato da Cisco per la gestione dei dispositivi di rete. A differenza di RADIUS (che combina auth e authz in un unico response), TACACS+ separa completamente le tre fasi AAA. Questo permette una granularita' molto maggiore: l'autorizzazione puo' essere valutata comando per comando, e ogni singola operazione CLI viene loggata nell'accounting.

RADIUS vs TACACS+ - Confronto

#

La scelta tra RADIUS e TACACS+ non e' mai casuale: dipende dall'uso. RADIUS e' nato per autenticare utenti che accedono alla rete. TACACS+ e' nato per autenticare admin che gestiscono dispositivi di rete. Questa distinzione e' la chiave dell'esame.

Architettura con VPN Concentrator

#

La combinazione VPN Concentrator + RADIUS Server + AD/LDAP e' l'architettura piu' comune in ambiente enterprise. Il concentrator gestisce i tunnel, RADIUS gestisce l'identita', AD gestisce il database degli utenti. Nessuno fa il lavoro di un altro.

graph LR
    C["Client (dipendente
    da casa)"]

    subgraph BORDER["Perimetro"]
        VPN["VPN Concentrator
        NAS - proxy auth"]
    end

    subgraph INTERNAL["Rete interna"]
        RAD["RADIUS Server
        UDP 1812 / 1813"]
        AD["Active Directory
        LDAP database"]
        FS["File Server
        Risorse interne"]
    end

    C -->|tunnel cifrato| VPN
    VPN -->|Access-Request UDP 1812| RAD
    RAD -->|query LDAP 389/636| AD
    AD -->|risultato query| RAD
    RAD -->|Access-Accept + policy| VPN
    VPN -->|tunnel autorizzato| FS
    VPN -->|Accounting UDP 1813| RAD

Lettura diagramma: Il client apre un tunnel cifrato verso il VPN Concentrator (NAS). Il Concentrator non valida le credenziali: manda un Access-Request al RADIUS Server via UDP 1812. RADIUS interroga Active Directory via LDAP. AD risponde. RADIUS manda Access-Accept con gli attributi (VLAN, policy) o Access-Reject. Il Concentrator applica la risposta. L'accounting fluisce su UDP 1813.*

802.1X - Port-Based NAC con RADIUS

#

802.1X e' lo standard IEEE per il controllo degli accessi basato sulla porta di rete (port-based NAC). RADIUS e' il backend che decide chi entra. Ogni dispositivo che si connette a uno switch o a un Wi-Fi Enterprise deve autenticarsi prima che la porta venga abilitata.

I tre attori di 802.1X hanno nomi precisi che l'esame usa sempre:

sequenceDiagram
    participant SUP as Supplicant (device)
    participant AUTH as Authenticator (switch/AP)
    participant RADIUS as Auth Server (RADIUS)

    SUP->>AUTH: 1 - EAPOL Start (collegato alla porta)
    AUTH->>SUP: 2 - EAP-Request Identity
    SUP->>AUTH: 3 - EAP-Response (username)
    AUTH->>RADIUS: 4 - RADIUS Access-Request
    RADIUS->>AUTH: 5 - EAP-Challenge
    AUTH->>SUP: 6 - EAP-Request (challenge)
    SUP->>AUTH: 7 - EAP-Response (prova identita')
    AUTH->>RADIUS: 8 - RADIUS Access-Request
    RADIUS->>AUTH: 9 - Access-Accept (VLAN 20)
    AUTH->>SUP: 10 - EAP-Success
    Note over AUTH: Porta sbloccata, device nella VLAN 20

Lettura diagramma: EAPOL (EAP over LAN) e' il protocollo tra Supplicant e Authenticator. EAP (Extensible Authentication Protocol) trasporta il metodo di autenticazione (certificato, PEAP, EAP-TLS). Il RADIUS Server decide in base alla challenge. Il trigger "Supplicant + Authenticator" in una domanda esame identifica sempre 802.1X.*

Varianti WPA2/WPA3 Enterprise (Wi-Fi):

• WPA2-Enterprise = 802.1X + EAP + RADIUS - standard attuale
• WPA3-Enterprise = 802.1X + EAP + RADIUS + cifratura piu' forte
• WPA2/WPA3-Personal = PSK/SAE, password condivisa, NO 802.1X

Accounting - Granularita' e Audit Trail

#

L'Accounting non logga solo il momento del login: logga tutte le azioni post-login. La granularita' dipende da chi gestisce l'accounting.

RADIUS Accounting in pratica: per ogni sessione VPN, RADIUS riceve un Accounting-Start (sessione aperta), aggiornamenti periodici Accounting-Interim-Update, e un Accounting-Stop (sessione chiusa con durata e dati trasferiti). Questo permette di sapere chi era connesso, quando, e per quanto tempo.

Scenario Reale Blue Team

#

Il RADIUS Server e' un target critico: se viene compromesso o disabilitato, l'autenticazione di rete va giu'. I log RADIUS sono anche la prima fonte per ricostruire chi era connesso durante un incidente.

# Verificare il servizio FreeRADIUS su Ubuntu
systemctl status freeradius

# Log RADIUS (FreeRADIUS default path)
tail -f /var/log/freeradius/radius.log

# Cercare Access-Reject (autenticazioni fallite) nell'ultimo giorno
grep "Access-Reject" /var/log/freeradius/radius.log | grep "$(date +%Y-%m-%d)"

# Analizzare sessioni VPN attive (se RADIUS ha accounting log)
grep "Acct-Status-Type = Start" /var/log/freeradius/radius.log | tail -20

# Verificare connettivita' verso RADIUS (dal NAS - test porta UDP 1812)
nc -zu RADIUS_SERVER_IP 1812 && echo "RADIUS raggiungibile"

# Test autenticazione manuale con radtest (FreeRADIUS tools)
radtest username password RADIUS_SERVER_IP 0 testing123

# 802.1X - vedere dispositivi autenticati su switch Cisco
# (da CLI switch)
# show authentication sessions
# show dot1x all

# Log AAA su switch Cisco (vedere cosa logga TACACS+)
# debug aaa authentication
# debug tacacs

Collegato a

#

• ids-ips - i log RADIUS alimentano i SIEM per detection di autenticazioni anomale
• ssh-protocol - TACACS+ autentica le sessioni SSH verso dispositivi Cisco
• ssl-tls - RADIUS su TLS (RadSec, RFC 6614) per cifrare l'intero traffico RADIUS su porta 2083

Dev parallel (PHP/Node): In un'app PHP/Node, il pattern AAA e' implementato esattamente come il middleware stack. In Symfony: il security.yaml gestisce Authentication (firewall, form login, JWT). Il voter o @IsGranted gestisce Authorization. Il bundle SecurityBundle logga ogni accesso: e' l'Accounting. In un'API REST con JWT: sub claim = identification, verifica firma HS256/RS256 = authentication, roles nel payload = authorization, ogni request log = accounting. Non lo chiami AAA ma e' la stessa struttura in tre fasi.

RADIUS centralizza questo per l'infrastruttura di rete: invece di avere credenziali locali su ogni switch, VPN concentrator e AP, si delega tutto a un server centrale. Il vantaggio pratico: basta disabilitare l'utente su Active Directory una volta sola per bloccare l'accesso a VPN, Wi-Fi e switch in un colpo solo. Senza RADIUS, dovresti aggiornare le credenziali su ogni singolo dispositivo di rete.