RadSec: Proteggere il traffico di autenticazione RADIUS con TLS

RadSec: Proteggere il traffico di autenticazione RADIUS con TLS. Un briefing tecnico di Purple. Introduzione e contesto. Benvenuti a questo briefing tecnico di Purple. Vi guiderò attraverso RadSec — RADIUS su TLS — spiegando cos'è, perché è fondamentale in questo momento e come implementarlo concretamente. Questo documento si rivolge direttamente ad architetti di rete e ingegneri della sicurezza che attualmente gestiscono un RADIUS in cloud o che stanno pianificando di migrare verso di esso. Se utilizzate ancora server RADIUS on-premise con UDP e un segreto condiviso, questo briefing fa al caso vostro. Inquadriamo la situazione. RADIUS è la spina dorsale dell'autenticazione di rete da oltre trent'anni. È alla base di 802.1X, WPA2-Enterprise, WPA3-Enterprise e di quasi tutti i sistemi di Captive Portal attualmente in produzione. Il protocollo stesso, definito nella RFC 2865, è stato progettato in un'era in cui internet era un luogo molto diverso. Il traffico di autenticazione tra i dispositivi NAS — access point, switch e controller — e il server RADIUS viaggiava su UDP, porta 1812 per l'autenticazione e porta 1813 per l'accounting. E quel traffico? Era in gran parte non crittografato. L'unica protezione era un segreto condiviso utilizzato per offuscare l'attributo della password utente, e anche questo presenta vulnerabilità ampiamente documentate. Per anni, questo approccio è stato accettabile perché il traffico RADIUS rimaneva all'interno di reti private e controllate. I dispositivi NAS e il server RADIUS si trovavano sulla stessa LAN o erano collegati tramite un circuito MPLS dedicato. La superficie di attacco era gestibile. Ma il mondo è cambiato. L'infrastruttura cloud-native, le implementazioni in sedi distribuite, le reti sovrapposte SD-WAN e il passaggio ai servizi cloud RADIUS hanno modificato radicalmente il modello delle minacce. Il traffico di autenticazione ora attraversa la rete internet pubblica o, nel migliore dei casi, infrastrutture condivise che non controllate completamente. È qui che entra in gioco RadSec. Approfondimento tecnico. RadSec, formalmente definito nella RFC 6614, è RADIUS su TLS. Il concetto è semplice: invece di inviare pacchetti RADIUS su UDP, li si incapsula all'interno di una connessione TLS su TCP. Il risultato è che tutto il traffico di autenticazione e accounting tra il NAS e il server RADIUS è completamente crittografato, autenticato reciprocamente e protetto nell'integrità. La RFC 7360 estende questo concetto a DTLS — Datagram TLS su UDP — che preserva alcune delle caratteristiche di latenza del trasporto UDP originale aggiungendo al contempo la crittografia. Per la maggior parte delle implementazioni aziendali, TLS su TCP rappresenta la scelta corretta. Vale la pena considerare DTLS in ambienti ad alto rendimento e sensibili alla latenza, come le installazioni all'interno di grandi stadi.Parliamo degli aspetti tecnici. RadSec opera sulla porta TCP 2083, che è la porta assegnata da IANA per questo protocollo. Quando un dispositivo NAS avvia una connessione RadSec, apre una connessione TCP verso il server RADIUS sulla porta 2083 ed esegue un handshake TLS. Questo handshake è reciproco: sia il client (ovvero il tuo NAS) sia il server presentano certificati X.509. Il certificato del server viene convalidato rispetto a una CA attendibile. Il certificato client identifica il NAS presso il server RADIUS. Una volta stabilita la sessione TLS, i pacchetti RADIUS fluiscono all'interno di quel tunnel crittografato esattamente come farebbero su UDP, ma ora con totale riservatezza, integrità e protezione dai replay attack. Si tratta di un cambiamento significativo rispetto al RADIUS tradizionale per tre importanti motivi. In primo luogo, il trasporto è TCP, non UDP. Ciò significa che si ottiene una consegna affidabile e ordinata. I pacchetti persi vengono ritrasmessi automaticamente. In secondo luogo, l'autenticazione di entrambi gli endpoint è basata su certificati, non su segreti condivisi. Questo elimina un'intera classe di attacchi basati su segreti condivisi deboli o compromessi. In terzo luogo, l'intero pacchetto RADIUS è crittografato, non solo l'attributo della password. Ciò significa che i nomi utente, gli identificatori di sessione e tutti gli attributi RADIUS sono protetti durante il transito. Dal punto di vista della gestione dei certificati, è necessaria una PKI (Public Key Infrastructure) per emettere e gestire i certificati sia per il server RADIUS che per i dispositivi NAS. In pratica, la maggior parte dei provider RADIUS in cloud, inclusa l'infrastruttura di autenticazione cloud-native di Purple, gestisce la gestione dei certificati lato server per te. La tua responsabilità è il provisioning dei certificati client sui tuoi dispositivi NAS. Per implementazioni su larga scala, questo viene solitamente gestito tramite la tua piattaforma di gestione di rete o un sistema dedicato di gestione dei certificati. I certificati dovrebbero utilizzare come minimo RSA a 2048 bit o ECDSA P-256, con un periodo di validità che bilanci l'overhead operativo con le buone pratiche di sicurezza: dodici mesi rappresentano un valore predefinito ragionevole. Ora, affrontiamo il confronto con l'approccio alternativo che molte organizzazioni utilizzano oggi: tunnel IPsec o overlay VPN per proteggere il traffico RADIUS. IPsec è un approccio perfettamente valido, ma opera a un livello diverso. Crittografa tutto il traffico tra due endpoint, il che aggiunge complessità: è necessario gestire IKE, chiavi pre-condivise o certificati per il tunnel stesso, oltre all'overhead operativo per mantenere lo stato del tunnel in potenzialmente centinaia di sedi. RadSec è più mirato. Crittografa specificamente il traffico del protocollo RADIUS, opera a livello applicativo e si integra direttamente con la tua infrastruttura RADIUS. Per le implementazioni RADIUS in cloud in cui si collegano molti dispositivi NAS in sedi distribuite a un server cloud centralizzato, RadSec è strutturalmente più pulito e operativamente più semplice. Lascia che ti spieghi come si presenta in pratica una distribuzione multi-sito. Hai un server RADIUS in cloud — diciamo che si tratta della piattaforma Purple — con un certificato TLS valido proveniente da una CA affidabile. Hai tre tipi di sedi: un hotel, un negozio al dettaglio e un centro congressi. Ognuno ha dispositivi NAS — access point, switch o controller LAN wireless. Ogni dispositivo NAS deve essere configurato con l'indirizzo del server RadSec, la porta 2083 e un certificato client. Il NAS avvia la connessione TLS, l'handshake reciproco si completa e, da quel momento in poi, tutto il traffico di autenticazione 802.1X per gli ospiti e il personale di quella sede fluisce crittografato verso il server RADIUS in cloud. Se la connessione TLS si interrompe — ad esempio a causa di un'interruzione di rete — il NAS la ripristina automaticamente. Questo modello di connessione persistente è in realtà più efficiente di UDP per le distribuzioni ad alto volume, perché evita il sovraccarico dell'elaborazione per singolo pacchetto. Sul lato firewall, devi consentire il traffico TCP in uscita sulla porta 2083 dalla rete di gestione del tuo NAS verso l'indirizzo IP o l'FQDN del tuo server RADIUS. Se applichi una policy di uscita rigida, dovrai anche consentire il traffico di ritorno. Questo è più semplice rispetto alla gestione delle regole del firewall IPsec, che spesso richiedono eccezioni per il protocollo ESP e IKE su UDP 500 e 4500. Raccomandazioni di implementazione e insidie comuni. Parliamo di cosa va effettivamente storto nelle distribuzioni RadSec, perché ci sono alcuni scenari di errore ricorrenti che riscontro nelle varie organizzazioni. Il primo problema, nonché il più comune, riguarda i fallimenti nella validazione della catena dei certificati. Il tuo dispositivo NAS deve considerare attendibile la CA che ha firmato il certificato del server RADIUS. Se utilizzi un provider RADIUS in cloud con un certificato emesso da una CA pubblica nota — DigiCert, Let's Encrypt, Sectigo — la maggior parte dei dispositivi NAS moderni lo considererà attendibile per impostazione predefinita. Ma se utilizzi una CA interna, devi distribuire il certificato della CA su ogni dispositivo NAS. Questo aspetto viene spesso trascurato durante la distribuzione iniziale e si manifesta con errori di handshake TLS che sembrano problemi di connettività. La seconda insidia è la scadenza del certificato. A differenza dei segreti condivisi, che non scadono, i certificati hanno un periodo di validità definito. Se il certificato del tuo server RADIUS scade, tutti i dispositivi NAS della tua infrastruttura smetteranno di autenticarsi contemporaneamente. È necessaria una gestione del ciclo di vita dei certificati — con rinnovo automatico ove possibile, e un monitoraggio con avvisi con largo anticipo rispetto alla scadenza. Un preavviso di novanta giorni è il minimo; trenta giorni è ancora meglio. Il terzo problema è la compatibilità dei dispositivi NAS. Non tutti i dispositivi NAS supportano RadSec nativamente. Le versioni più vecchie di Cisco IOS, alcuni controller Aruba legacy e determinati access point di fascia consumer non supportano RadSec. Prima di impegnarsi in un'implementazione RadSec, effettua un audit del tuo parco NAS per verificarne la compatibilità. Cisco IOS-XE 16.x e versioni successive, Aruba AOS-CX, Ruckus SmartZone e la serie Juniper EX offrono tutti un solido supporto RadSec. Per i dispositivi che non supportano RadSec nativamente, un proxy RadSec — un'opzione open-source come radsecproxy — può colmare il divario, accettando UDP RADIUS dai dispositivi legacy e inoltrandolo tramite TLS al server RADIUS in cloud. La quarta considerazione riguarda la persistenza della connessione e i keepalive. RadSec utilizza connessioni TCP persistenti, ma i firewall e i dispositivi NAT con policy di timeout aggressive possono interrompere silenziosamente le connessioni inattive. Configura i keepalive TCP sulle tue connessioni RadSec — in genere un intervallo di keepalive di sessanta secondi è sufficiente per prevenire l'interruzione prematura della connessione. La maggior parte delle implementazioni di server RADIUS e dei dispositivi NAS supporta questa configurazione. Per Cisco IOS-XE, la configurazione RadSec si presenta così. Definisci un server RADIUS con l'indirizzo del tuo endpoint RADIUS in cloud, specifichi TLS come trasporto, fai riferimento al tuo trustpoint — che è l'archivio dei certificati sul dispositivo — e imposti la porta di destinazione su 2083. Successivamente, fai riferimento a questo server nella configurazione del tuo gruppo di server AAA. I dettagli variano a seconda della versione della piattaforma, ma la struttura logica è coerente tra i diversi vendor. Per i controller Aruba che eseguono AOS, configuri il server RADIUS con l'opzione RadSec abilitata, specifichi il certificato CA per la convalida del server e, facoltativamente, configuri un certificato client per il mutual TLS. L'implementazione di Aruba è matura e ben documentata. Domande e risposte rapide. Lasciami passare in rassegna le domande che mi vengono poste più spesso su RadSec. RadSec aggiunge latenza? L'handshake TLS aggiunge un piccolo sovraccarico alla creazione iniziale della connessione — in genere inferiore a 100 millisecondi. Una volta stabilita la connessione, il sovraccarico per pacchetto è trascurabile. Per l'autenticazione 802.1X, in cui l'handshake avviene una sola volta per sessione, questo non rappresenta un problema significativo. Posso eseguire RadSec insieme al tradizionale UDP RADIUS? Sì. La maggior parte dei server RADIUS supporta entrambi contemporaneamente. Durante una migrazione, puoi eseguire RadSec per i siti che lo supportano e ricorrere a UDP per i siti legacy. Questo è l'approccio di migrazione consigliato. RadSec è richiesto per la conformità PCI DSS? La versione 4.0 di PCI DSS richiede che il traffico di autenticazione sia protetto in transito. RadSec è uno dei modi più diretti per soddisfare questo requisito per l'autenticazione basata su RADIUS. Se elabori pagamenti con carta su una rete che utilizza l'autenticazione RADIUS, RadSec dovrebbe far parte della tua roadmap di conformità. RadSec funziona con EAP? Sì. EAP — Extensible Authentication Protocol — è incapsulato all'interno di RADIUS, quindi EAP-TLS, PEAP, EAP-TTLS funzionano tutti in modo trasparente su RadSec. Lo scambio EAP in sé non viene influenzato. E per quanto riguarda l'accounting RADIUS? La specifica RFC 6614 copre sia il traffico di autenticazione che quello di accounting. I dati di accounting — record di avvio, arresto e aggiornamento intermedio della sessione — vengono anch'essi crittografati sulla stessa connessione TLS sulla porta 2083. Riepilogo e prossimi passi. Per riassumere: RadSec è il livello di trasporto corretto per RADIUS in qualsiasi implementazione in cui il traffico di autenticazione attraversa un'infrastruttura che non si controlla completamente. Ciò significa RADIUS in cloud, implementazioni multi-sito, ambienti SD-WAN e qualsiasi scenario in cui il traffico RADIUS attraversa l'internet pubblico o l'infrastruttura di un operatore condiviso. Le azioni chiave per il vostro team sono: in primo luogo, verificare la compatibilità con RadSec del parco NAS e identificare eventuali dispositivi che necessiteranno di un proxy. In secondo luogo, coinvolgere il proprio provider RADIUS in cloud — o valutare provider che supportano RadSec nativamente — e comprendere il loro approccio alla gestione dei certificati. In terzo luogo, stabilire un processo di gestione del ciclo di vita dei certificati prima di andare online. In quarto luogo, aggiornare le regole del firewall per consentire la porta TCP 2083 in uscita dalla rete di gestione NAS. In quinto luogo, testare la configurazione RadSec in un ambiente di staging prima del rilascio in produzione, prestando particolare attenzione alla convalida della catena di certificati e alla persistenza della connessione sotto carico. Per le organizzazioni che utilizzano la piattaforma di Purple per il guest WiFi e l'autenticazione in sedi distribuite, RadSec è il trasporto consigliato per la connettività RADIUS in cloud. Si allinea con l'architettura cloud-native di Purple e garantisce che i dati di autenticazione che fluiscono tra le vostre sedi e la piattaforma siano completamente protetti — il che è fondamentale sia per la vostra postura di sicurezza sia per i vostri obblighi di conformità ai sensi del GDPR e PCI DSS. Se state pianificando un'implementazione o desiderate discutere della vostra architettura specifica, il team di Purple è il punto di partenza ideale. Questo è stato un briefing tecnico di Purple su RadSec. Grazie per l'attenzione.