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 presentatore e oggi affronteremo un argomento che si colloca esattamente all'intersezione tra la sicurezza di rete e il rischio operativo: RadSec - formalmente definito nella RFC 6614 - e perché dovrebbe far parte della vostra roadmap infrastrutturale se non lo è già. Se siete IT manager, network architect o CTO responsabili del WiFi aziendale di un gruppo alberghiero, di un parco retail, di uno stadio o di un campus del settore pubblico, questo briefing è per voi. Esamineremo cos'è in concreto RadSec, perché il protocollo RADIUS tradizionale vi lascia esposti, come distribuire RadSec in un ambiente reale e le trappole 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. Iniziamo. --- [APPROFONDIMENTO TECNICO - circa 5 minuti] Iniziamo quindi dal problema. Il protocollo 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 a fronte della vostra directory - Active Directory, LDAP o un provider di identità in cloud - e concede o nega l'accesso. Questo è il modello di autenticazione 802.1X che sta alla base delle reti WPA2-Enterprise e WPA3-Enterprise. Il problema è che il protocollo 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 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 oscurare la password dell'utente in transito tramite hashing MD5. L'MD5, come molti di voi sapranno, è crittograficamente compromesso. Lo è ormai 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 - e questo include switch compromessi, dispositivi non autorizzati sulla vostra VLAN di gestione o qualsiasi punto tra un access point remoto e un server RADIUS ospitato in cloud - si possono potenzialmente 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 strutture, o per una catena di negozi con access points in ogni punto vendita che si collegano a un server RADIUS centrale tramite la rete internet pubblica, questo non è un rischio teorico. È una superficie di attacco concreta. Questo è esattamente ciò che RadSec risolve. RadSec - definito nella RFC 6614 e aggiornato dalla RFC 7360 - racchiude 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 certificati, verificano reciprocamente l'identità e stabiliscono una sessione crittografata prima che avvenga qualsiasi scambio di dati di autenticazione. TLS 1.3 è la versione attualmente raccomandata, che garantisce la forward secrecy ed elimina una serie di vulnerabilità legate ai 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 intercetti il traffico sul cavo vedrà solo record TLS crittografati. Il segreto condiviso è ancora presente per motivi di compatibilità con le versioni precedenti, ma non svolge più alcun ruolo di sicurezza significativo - TLS si fa 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 della Wi-Fi Alliance - che consente un roaming WiFi fluido tra le sedi aderenti - impone RadSec per tutto il traffico della federazione. Se stai implementando un'infrastruttura predisposta 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 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 tocca ambienti con carte di pagamento - e nel retail e nell'hospitality succede di frequente - il divario di crittografia nel RADIUS tradizionale è un problema di conformità assicurato. Il GDPR richiede analogamente misure tecniche adeguate per proteggere i dati personali; le credenziali utente e i metadati di sessione che fluiscono non crittografati sulla tua rete sono difficili da difendere in un audit di protezione dei dati. Ora parliamo di architettura. Esistono due pattern 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 tuo 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 infrastruttura 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 RADIUS standard tramite 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 internet pubblica. 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 TLS reciproco. Ciò significa un'Autorità di Certificazione, 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 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 DA EVITARE - circa 2 minuti] Lascia che ti fornisca le raccomandazioni pratiche. Primo: effettua 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 TLS, i quali dovranno essere inseriti nella roadmap di sostituzione. Secondo: inizia con il traffico a più alto rischio. Se hai traffico RADIUS che attraversa l'internet pubblica - sedi remote, RADIUS ospitato nel cloud, gruppi alberghieri multiproprietà - questa è la tua prima priorità. Il traffico RADIUS locale su una VLAN di gestione ben segmentata è a minor rischio, ma dovrebbe comunque essere presente nella roadmap. Terzo: testa accuratamente il TLS reciproco prima del lancio. La modalità di errore più comune nelle distribuzioni RadSec è rappresentata dagli 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. Utilizza openssl s_client per testare gli handshake TLS prima di deviare il traffico di produzione. Quarto: non trascurare il monitoraggio. RadSec aggiunge un livello di connessione TCP che il RADIUS tradizionale non ha. Gli errori di connessione TCP, i timeout dell'handshake TLS e gli errori dei certificati si manifesteranno come errori di autenticazione per i tuoi utenti. Assicurati che i log del tuo server RADIUS e i log del tuo proxy vengano inseriti nel tuo SIEM o nella 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 è quello di organizzazioni che implementano 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 hai l'abitudine di gestire le regole UDP 1812, la porta TCP 2083 può essere facilmente dimenticata nel processo di modifica del firewall. - [Q&A VELOCE - circa 1 minuto] Passiamo in rassegna alcune domande che mi vengono poste regolarmente. "RadSec sostituisce 802.1X?" No. RadSec protegge il livello di trasporto tra l'access point e il server RADIUS. 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 vari livelli di supporto RadSec - verifica la tua versione specifica del firmware. Laddove manchi il supporto nativo, la soluzione è un proxy RadSec. "E per quanto riguarda DTLS - RADIUS su DTLS?" L'RFC 7360 definisce RADIUS su DTLS, che utilizza UDP anziché TCP, preservando alcune delle caratteristiche non orientate alla connessione del RADIUS tradizionale e aggiungendo 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 l'overhead 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 gestisci il 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 tuoi prossimi passi: esegui un audit della tua infrastruttura RADIUS questa settimana. Identifica i flussi di traffico a più alto rischio. Controlla la documentazione del server RADIUS e del produttore del tuo access point per il supporto nativo di RadSec. Se utilizzi FreeRADIUS, puoi avere un'implementazione di test 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 gli ambienti WiFi aziendali che per quelli degli ospiti. Se vuoi capire come RadSec si adatta alla tua specifica configurazione, il team di Purple può guidarti nel processo. Grazie per l'attenzione. Alla prossima. - FINE DELLA SCENEGGIATURA