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

RadSec: come il RADIUS over TLS migliora la sicurezza dell'autenticazione WiFi Un briefing informativo di Purple sulla Enterprise WiFi Intelligence Durata stimata: 10 minuti - - - [INTRODUZIONE E CONTESTO - circa 1 minuto] Benvenuti alla serie Purple Enterprise WiFi Intelligence. Sono il vostro presentatore e oggi affronteremo un argomento che si colloca proprio all'intersezione tra la sicurezza della rete e il rischio operativo: RadSec - formalmente definito nella RFC 6614 - e perché dovrebbe essere presente nella roadmap della vostra infrastruttura se non lo è già. Se siete un IT manager, un progettista di rete o un CTO responsabile del WiFi aziendale di un gruppo alberghiero, di un patrimonio retail, di uno stadio o di un campus del settore pubblico, questo briefing è per voi. Esamineremo cos'è in realtà 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. Nessuna teoria fine a se stessa - solo le informazioni necessarie per prendere una decisione in questo trimestre. Entriamo nel vivo dell'argomento. - - - [APPROFONDIMENTO TECNICO - circa 5 minuti] Iniziamo quindi dal problema. Il RADIUS - Remote Authentication Dial-In User Service - rappresenta la spina dorsale dell'autenticazione WiFi aziendale 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 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. UDP è privo di connessione, il che significa che non c'è handshake, non c'è stato di 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 mediante l'hashing MD5. L'MD5, come la maggior parte di voi saprà, è crittograficamente vulnerabile. È superato da anni. Cosa significa questo in pratica? Significa che su qualsiasi segmento di rete in cui un utente malintenzionato può 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 in cloud - è potenzialmente in grado di acquisire 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 proprietà, o per una catena di negozi con access point in ogni punto vendita che effettuano il backhaul verso un server RADIUS centrale tramite la rete internet pubblica, questo non è un rischio teorico. È 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 mutuale con certificati X.509. Sia il client RADIUS sia il server RADIUS presentano certificati, verificano l'identità reciproca e stabiliscono una sessione crittografata prima che venga scambiato qualsiasi dato di autenticazione. TLS 1.3 è la versione attualmente consigliata, 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 motivi di retrocompatibilità, ma non svolge più alcun ruolo di sicurezza significativo - è il TLS a farsi carico di tutto il lavoro. 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 oltre, utilizza RadSec da anni come parte della sua infrastruttura di roaming interistituzionale. Più di recente, lo standard OpenRoaming di Wi-Fi Alliance - che consente un roaming WiFi fluido tra le sedi partecipanti - impone l'uso di RadSec per tutto il traffico della federazione. Se stai distribuendo un'infrastruttura predisposta per OpenRoaming, RadSec non è opzionale; è un prerequisito. Purple supporta OpenRoaming con la sua licenza Connect, agendo come provider di identità all'interno della federazione, e RadSec è fondamentale per il funzionamento di questo tessuto 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 entra in contatto con ambienti di carte di pagamento - e nel retail e nell'hospitality succede di frequente - il gap di crittografia nel RADIUS tradizionale è un problema di conformità assicurato. Il GDPR richiede allo stesso modo misure tecniche adeguate per proteggere i dati personali; le credenziali degli utenti e i metadati di sessione che fluiscono non crittografati attraverso la tua rete sono difficili da difendere in un audit sulla protezione dei dati. Ora parliamo di architettura. Esistono due modelli di implementazione principali per RadSec. Il primo è il supporto nativo di RadSec sul tuo server RADIUS e sui tuoi 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 basate su Windows. Cisco ISE supporta RadSec. Aruba ClearPass supporta RadSec. Se sia il tuo server RADIUS sia il fornitore dei tuoi access point supportano RadSec nativamente, questo è il percorso più lineare: configura i certificati TLS su entrambi i lati, apri la porta TCP 2083 sul tuo firewall e crittograferai il traffico RADIUS end-to-end. Il secondo schema è 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 vostri access point e il vostro server RADIUS. Gli access point inviano il traffico RADIUS standard tramite UDP al proxy sulla rete locale. Il proxy termina tale 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 accessibile tramite internet pubblico. La gestione dei certificati rappresenta la complessità operativa da pianificare. Avrete bisogno di una PKI - Public Key Infrastructure - per emettere e gestire i certificati X.509 utilizzati per il mutual TLS. Ciò comporta una Certificate Authority, l'emissione di certificati per ciascun client e server RADIUS e un processo per la rotazione dei certificati prima della scadenza. I certificati che scadono inosservati bloccheranno l'autenticazione per ogni utente sulla rete contemporaneamente - e questo è uno scenario che si desidera evitare. Automatizzate il rinnovo dei certificati utilizzando ACME o l'API della vostra CA, e impostate avvisi di monitoraggio con largo anticipo rispetto alle date di scadenza. --- [IMPLEMENTATION RECOMMENDATIONS & PITFALLS - circa 2 minuti] Ecco alcuni consigli pratici. Primo: effettuate un audit prima dell'implementazione. Mappate ogni client RADIUS - access point, concentratori VPN, switch che eseguono 802.1X - e ogni server RADIUS nel vostro ambiente. Identificate quali supportano RadSec nativamente e quali necessitano di un proxy. Questo audit in genere fa emergere dispositivi legacy che non supportano affatto il TLS, i quali dovranno essere inseriti nella vostra roadmap di sostituzione. Secondo: iniziate con il traffico a più alto rischio. Se avete traffico RADIUS che attraversa l'internet pubblico - sedi remote, RADIUS ospitato in cloud, gruppi alberghieri con più proprietà - questa è la vostra priorità assoluta. Il traffico RADIUS locale su una VLAN di gestione ben segmentata è a minor rischio, ma dovrebbe comunque essere inserito nella roadmap. Terzo: testate a fondo il mutual TLS prima della messa in produzione. La causa di errore più comune nelle implementazioni RadSec riguarda gli errori di validazione dei certificati - Common Name non corrispondenti, certificati intermedi scaduti o client che non considerano attendibile la CA che ha firmato il certificato del server. Utilizzate openssl s_client per testare gli handshake TLS prima di deviare il traffico di produzione. Quarto: non trascurate il monitoraggio. RadSec aggiunge un livello di connessione TCP che il RADIUS tradizionale non ha. Errori di connessione TCP, timeout degli handshake TLS ed errori dei certificati si manifesteranno come fallimenti di autenticazione per i vostri utenti. Assicuratevi che i log del server RADIUS e i log del proxy vengano inviati al vostro SIEM o alla vostra 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 riguarda le organizzazioni che distribuiscono RadSec sul lato server ma si 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 hai l'abitudine di gestire regole UDP 1812, la porta TCP 2083 può essere facilmente dimenticata durante il processo di modifica del firewall. - [D&R RAPIDE - circa 1 minuto] Vediamo ora alcune delle domande che ricevo più di frequente. "RadSec sostituisce lo standard 802.1X?" No. RadSec protegge lo strato di trasporto tra l'access point e il server RADIUS. Lo standard 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 offrono tutti diversi livelli di supporto per RadSec - verifica la tua versione specifica del firmware. Laddove il supporto nativo sia assente, un proxy RadSec rappresenta la soluzione ideale. "E per quanto riguarda il DTLS - RADIUS su DTLS?" Lo standard RFC 7360 definisce RADIUS su DTLS, che utilizza il protocollo UDP anziché TCP, preservando alcune delle caratteristiche prive di 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 capacità. "In che modo questo influisce sulle prestazioni di roaming?" La connessione TCP di RadSec è persistente, il che può effettivamente migliorare le prestazioni di roaming negli 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 del RADIUS tradizionale. Se gestisci una rete WiFi aziendale su larga scala - su più sedi, tramite Internet o in ambienti soggetti alle normative PCI-DSS o GDPR - la domanda non è se implementare RadSec, ma quando e come farlo. I tuoi prossimi passi: avvia un controllo della tua infrastruttura RADIUS questa settimana. Identifica i flussi di traffico a più alto rischio. Verifica la documentazione del produttore del tuo server RADIUS e dei tuoi access point per il supporto nativo di RadSec. Se utilizzi FreeRADIUS, puoi avere un'installazione di prova di RadSec attiva in un giorno. Se utilizzi Microsoft NPS, inizia 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 ambienti WiFi aziendali che per ospiti. Se desideri capire come integrare RadSec nella tua specifica configurazione, il team di Purple è a tua disposizione per guidarti passo dopo passo. Grazie per l'attenzione. Alla prossima. - FINE DELLO SCRIPT