RadSec: come RADIUS over TLS migliora la sicurezza dell'autenticazione WiFi

RadSec: Come RADIUS over TLS Migliora la Sicurezza dell'Autenticazione WiFi Un briefing informativo di Purple Enterprise WiFi Durata stimata: 10 minuti --- [INTRODUZIONE E CONTESTO — circa 1 minuto] Benvenuti alla serie Purple Enterprise WiFi Intelligence. Sono il vostro ospite e oggi affronteremo un argomento che si colloca esattamente all'intersezione tra sicurezza di rete e rischio operativo: RadSec — formalmente definito nella RFC 6614 — e perché dovrebbe essere presente nella roadmap della vostra infrastruttura, se non lo è già. Se siete IT manager, network architect o CTO responsabili del WiFi aziendale in un gruppo alberghiero, in una catena di negozi, in uno stadio o in un campus del settore pubblico, questo briefing fa al caso vostro. Analizzeremo cos'è concretamente RadSec, perché il protocollo RADIUS tradizionale vi lascia esposti, come implementare RadSec in un ambiente reale e le insidie che mettono in difficoltà i team di lavoro. Niente teoria fine a se stessa — solo le informazioni necessarie per prendere una decisione in questo trimestre. Entriamo nel vivo. --- [APPROFONDIMENTO TECNICO — circa 5 minuti] Iniziamo quindi dal problema. Il RADIUS — Remote Authentication Dial-In User Service — è stato la spina dorsale dell'autenticazione WiFi aziendale fin dagli anni '90. Quando un utente o un dispositivo si connette al vostro WiFi aziendale o guest, l'access point funge da client RADIUS, inoltrando le richieste di autenticazione a un server RADIUS, che convalida le credenziali rispetto alla vostra directory — Active Directory, LDAP o un provider di identità cloud — e concede o nega l'accesso. Questo è il modello di autenticazione 802.1X alla base delle reti WPA2-Enterprise e WPA3-Enterprise. Il problema è che il RADIUS tradizionale è stato progettato per un'era diversa. Funziona su UDP — User Datagram Protocol — sulle porte 1812 e 1813. L'UDP è privo di connessione, il che significa che non c'è handshake, non c'è stato della sessione e, cosa fondamentale, non c'è crittografia nativa. L'unica protezione tra l'access point e il server RADIUS è un segreto condiviso — essenzialmente una password — utilizzato per offuscare la password dell'utente in transito tramite l'hashing MD5. L'MD5, come la maggior parte di voi saprà, è crittograficamente compromesso. Lo è da anni. Cosa significa questo all'atto pratico? Significa che in qualsiasi segmento di rete in cui un utente malintenzionato possa intercettare il traffico RADIUS — inclusi switch compromessi, dispositivi non autorizzati sulla VLAN di gestione o qualsiasi punto tra un access point remoto e un server RADIUS ospitato nel cloud — quest'ultimo può potenzialmente catturare gli scambi di autenticazione, tentare attacchi dizionario offline contro il segreto condiviso e, in alcune configurazioni, esporre completamente le credenziali dell'utente. Per un gruppo alberghiero che gestisce il WiFi guest in 200 strutture, o per una catena di negozi con access point in ogni punto vendita che si collegano a un server RADIUS centrale tramite la rete internet pubblica, questo non è un rischio teorico. Si tratta di una superficie di attacco reale.Questo è esattamente ciò che RadSec risolve. RadSec — definito in RFC 6614 e aggiornato da RFC 7360 — incapsula il traffico RADIUS all'interno di un tunnel TLS. Invece di UDP, utilizza TCP sulla porta 2083. Invece di un segreto condiviso e MD5, utilizza l'autenticazione TLS reciproca con certificati X.509. Sia il client RADIUS che il server RADIUS presentano i certificati, verificano l'identità reciproca e stabiliscono una sessione crittografata prima che venga scambiato qualsiasi dato di autenticazione. TLS 1.3 è la versione attualmente raccomandata, che garantisce la forward secrecy ed elimina una serie di vulnerabilità dei cifrari legacy. L'effetto pratico è significativo. I dati delle credenziali, gli attributi utente e i token di sessione sono crittografati end-to-end tra l'access point — o un proxy RadSec — e il server RADIUS. Un utente malintenzionato che intercetta il traffico sulla rete vede solo record TLS crittografati. Il segreto condiviso è ancora presente per compatibilità con le versioni precedenti, ma non svolge più alcun lavoro di sicurezza significativo: è il TLS a farsi carico di tutto. C'è un'altra dimensione qui che è sempre più rilevante: il roaming. La federazione Eduroam, utilizzata da università e istituti di ricerca in tutta Europa e non solo, utilizza RadSec da anni come parte della sua infrastruttura di roaming interistituzionale. Più di recente, lo standard OpenRoaming di Wi-Fi Alliance — che consente il roaming WiFi continuo tra le sedi partecipanti — impone RadSec per tutto il traffico della federazione. Se si distribuisce un'infrastruttura abilitata per OpenRoaming, RadSec non è opzionale; è un prerequisito. Purple supporta OpenRoaming con la sua licenza Connect, agendo come identity provider all'interno della federazione, e RadSec è fondamentale per il funzionamento di questa rete di roaming sicuro. Dal punto di vista della conformità, RadSec è sempre più rilevante per PCI DSS 4.0, che inasprisce i requisiti relativi alla protezione dei dati di autenticazione in transito. Se la tua infrastruttura WiFi tocca ambienti con carte di pagamento — e nel retail e nell'hospitality accade di frequente — il divario di crittografia nel RADIUS tradizionale è una vulnerabilità che aspetta solo di essere rilevata. Il GDPR richiede allo stesso modo misure tecniche adeguate per proteggere i dati personali; le credenziali utente e i metadati di sessione che transitano non crittografati sulla rete sono difficili da difendere in un audit di protezione dei dati. Ora parliamo di architettura. Esistono due modelli di implementazione principali per RadSec. Il primo è il supporto nativo di RadSec sul server RADIUS e sugli access point. FreeRADIUS 3.0 e versioni successive supportano RadSec nativamente. Microsoft NPS non supporta RadSec nativamente nelle versioni attuali, il che rappresenta un limite significativo per le organizzazioni che gestiscono infrastrutture incentrate su Windows. Cisco ISE supporta RadSec. Aruba ClearPass supporta RadSec. Se sia il server RADIUS che il fornitore dell'access point supportano RadSec nativamente, questo è il percorso più lineare: configura i certificati TLS su entrambi i lati, apri la porta TCP 2083 sul firewall e crittograferai il traffico RADIUS end-to-end. Il secondo modello è un proxy RadSec. Questa è l'implementazione più comune nella pratica, in particolare per le organizzazioni con infrastrutture RADIUS legacy o ambienti multi-vendor. Un proxy RadSec — radsecproxy è l'implementazione open-source più diffusa — si posiziona tra i tuoi access point e il tuo server RADIUS. Gli access point inviano il traffico RADIUS standard su UDP al proxy sulla rete locale. Il proxy termina quella connessione, reincapsula il traffico RADIUS all'interno di un tunnel TLS e lo inoltra al server RADIUS a monte tramite TCP 2083. Questo approccio consente di aggiungere RadSec a un'infrastruttura esistente senza sostituire il server RADIUS, ed è particolarmente utile quando il server RADIUS è ospitato nel cloud o vi si accede tramite l'internet pubblico. La gestione dei certificati è la complessità operativa che è necessario pianificare. Avrai bisogno di una PKI — Public Key Infrastructure — per emettere e gestire i certificati X.509 utilizzati per il mutual TLS. Ciò significa una Certificate Authority, l'emissione di certificati per ogni client e server RADIUS e un processo per la rotazione dei certificati prima della scadenza. I certificati che scadono inosservati interromperanno l'autenticazione per ogni utente sulla rete contemporaneamente — e questo è uno scenario che si desidera evitare. Automatizza il rinnovo dei certificati utilizzando ACME o l'API della tua CA e imposta avvisi di monitoraggio con largo anticipo rispetto alle date di scadenza. --- [RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE COMUNI — circa 2 minuti] Permettetemi di fornirvi alcune raccomandazioni pratiche. Primo: effettuare un audit prima dell'implementazione. Mappa ogni client RADIUS — access point, concentratori VPN, switch che eseguono l'802.1X — e ogni server RADIUS nel tuo ambiente. Identifica quali supportano RadSec nativamente e quali avranno bisogno di un proxy. Questo audit in genere fa emergere dispositivi legacy che non supportano affatto il TLS, e questi devono essere inseriti nella roadmap di sostituzione. Secondo: iniziare con il traffico a più alto rischio. Se hai traffico RADIUS che attraversa l'internet pubblico — sedi remote, RADIUS ospitato in cloud, gruppi alberghieri multi-proprietà — questa è la tua prima priorità. Il traffico RADIUS locale su una VLAN di gestione ben segmentata è a minor rischio, ma dovrebbe comunque essere inserito nella roadmap. Terzo: testare a fondo il mutual TLS prima del go-live. La modalità di errore più comune nelle implementazioni RadSec è rappresentata dagli errori di validazione dei certificati — Common Name non corrispondenti, certificati intermedi scaduti o client che non si fidano della CA che ha firmato il certificato del server. Usa openssl s_client per testare gli handshake TLS prima di trasferire il traffico di produzione. Quarto: non trascurare il monitoraggio. RadSec aggiunge un livello di connessione TCP che il RADIUS tradizionale non ha. I fallimenti di connessione TCP, i timeout degli handshake TLS e gli errori dei certificati si manifesteranno come fallimenti di autenticazione per i tuoi utenti. Assicurati che i log del tuo server RADIUS e i log del tuo proxy vengano inviati al tuo SIEM o alla tua piattaforma di monitoraggio, in modo da poter distinguere un problema di connettività RadSec da un problema di policy di autenticazione. L'errore che vedo più spesso è che le organizzazioni distribuiscono RadSec sul lato server ma dimenticano di aggiornare le regole del firewall. La porta TCP 2083 deve essere aperta tra ogni client RADIUS e il server o proxy RADIUS. Se si è abituati a gestire le regole UDP 1812, la porta TCP 2083 può essere facilmente dimenticata nel processo di modifica del firewall. --- [Q&A RAPIDO — circa 1 minuto] Vediamo di rispondere ad alcune domande che sento regolarmente. "RadSec sostituisce l'802.1X?" No. RadSec protegge il livello di trasporto tra l'access point e il server RADIUS. L'802.1X è il framework di autenticazione tra il dispositivo client e l'access point. Operano su livelli diversi e sono complementari. "RadSec è supportato da tutti i produttori di access point?" Non universalmente. Cisco, Aruba, Ruckus e Meraki hanno tutti diversi livelli di supporto RadSec — verificate la vostra versione specifica del firmware. Laddove manchi il supporto nativo, un proxy RadSec rappresenta la soluzione ideale. "E per quanto riguarda DTLS — RADIUS su DTLS?" La specifica RFC 7360 definisce RADIUS su DTLS, che utilizza UDP anziché TCP, preservando alcune delle caratteristiche senza connessione del RADIUS tradizionale e aggiungendo al contempo la crittografia. È meno diffuso rispetto a RadSec su TLS, ma vale la pena valutarlo se la latenza rappresenta un problema in ambienti ad alta velocità di trasmissione. "In che modo questo influisce sulle prestazioni di roaming?" La connessione TCP di RadSec è persistente, il che può effettivamente migliorare le prestazioni di roaming in ambienti federati riducendo il sovraccarico di configurazione della connessione per le successive richieste di autenticazione. --- [RIASSUNTO E PROSSIMI PASSI — circa 1 minuto] Per concludere: RadSec è la risposta matura e basata su standard a una reale lacuna di sicurezza nel RADIUS tradizionale. Se gestite una rete WiFi aziendale su larga scala — su più sedi, tramite Internet o in ambienti soggetti a PCI DSS o GDPR — la domanda non è se implementare RadSec, ma quando e come. I vostri prossimi passi: verificate la vostra infrastruttura RADIUS questa settimana. Identificate i flussi di traffico a più alto rischio. Controllate la documentazione del server RADIUS e del produttore dell'access point per verificare il supporto nativo a RadSec. Se utilizzate FreeRADIUS, potete avere un'implementazione RadSec di prova attiva in un giorno. Se utilizzate Microsoft NPS, iniziate a valutare un proxy o un percorso di migrazione verso un server compatibile con RadSec. La piattaforma di Purple è progettata per integrarsi con l'infrastruttura RADIUS aziendale, supportando flussi di autenticazione sicuri sia per gli ambienti WiFi aziendali che per quelli guest. Se desiderate capire come RadSec si adatta alla vostra specifica implementazione, il team di Purple può guidarvi nel processo. Grazie per l'attenzione. Alla prossima. --- FINE DELLO SCRIPT