Come configurare l'autenticazione WiFi 802.1X: guida passo dopo passo

Come configurare l'autenticazione WiFi 802.1X: Una guida passo dopo passo Un Podcast di Purple Enterprise WiFi Intelligence [INTRODUZIONE — circa 1 minuto] Benvenuti. Vi parlo oggi in qualità di senior solutions architect e, se state ascoltando questo podcast, probabilmente vi trovate di fronte a un progetto di sicurezza di rete che prevede l'autenticazione 802.1X - o perché il vostro team di conformità lo ha segnalato, o perché la vostra compagnia assicurativa lo ha richiesto, o semplicemente perché avete ereditato una rete che funziona su una PSK condivisa e sapete che questo non è più sufficiente. Quindi andiamo dritti al punto. Lo standard 802.1X è lo standard IEEE per il controllo dell'accesso alla rete basato su porta. È la spina dorsale della sicurezza WiFi aziendale - il meccanismo che garantisce che ogni dispositivo che si connette alla vostra rete sia stato identificato positivamente e autorizzato prima di ricevere un solo byte di traffico. Questo non è opzionale per le organizzazioni che gestiscono i dati delle carte di pagamento ai sensi del PCI-DSS, non è opzionale per gli ambienti sanitari ai sensi del GDPR e, onestamente, per qualsiasi organizzazione che gestisca più di una manciata di access point, è l'architettura corretta. Nei prossimi dieci minuti vi guiderò attraverso l'architettura tecnica, la configurazione RADIUS, l'implementazione dei certificati e gli scenari reali in cui le cose si complicano. Cominciamo. [APPROFONDIMENTO TECNICO — circa 5 minuti] Bene, l'architettura 802.1X ha tre componenti. Abbiamo il Supplicant - ovvero il dispositivo client, il laptop, il telefono, il sensore IoT. Abbiamo l'Authenticator - che è il vostro access point o lo switch di rete, a volte chiamato NAS, Network Access Server. E infine abbiamo l'Authentication Server - quasi universalmente un server RADIUS nelle implementazioni aziendali. Ecco come funziona l'handshake. Quando un dispositivo tenta di connettersi a un SSID protetto da 802.1X, l'access point non lo fa semplicemente entrare. Invece, apre quella che viene chiamata una porta controllata - un canale limitato che trasmette solo traffico EAP, l'Extensible Authentication Protocol. L'AP invia un EAP-Request Identity al dispositivo. Il dispositivo risponde con la propria identità. L'AP la inoltra quindi al server RADIUS, racchiusa in un pacchetto RADIUS Access-Request. Il server RADIUS esegue l'autenticazione - verificando le credenziali rispetto ad Active Directory, a un archivio di certificati o a qualsiasi backend di identità configurato - e invia una risposta Access-Accept o Access-Reject. Solo in caso di Accept l'AP apre la porta dati completa e assegna il dispositivo alla VLAN appropriata. Ora, il metodo EAP scelto in questa fase è di fondamentale importanza. Ce ne sono cinque che si incontrano comunemente nelle implementazioni aziendali. EAP-TLS è lo standard di riferimento. Sia il client che il server presentano certificati X.509. Non ci sono password coinvolte. È l'opzione più sicura e quella richiesta per i livelli di conformità PCI-DSS più elevati. L'unico inconveniente è che occorre una PKI completa - una Public Key Infrastructure - per emettere e gestire i certificati client. Ciò significa una Certificate Authority, la gestione del ciclo di vita dei certificati e un meccanismo per distribuire i certificati a ogni dispositivo. Per le organizzazioni con Microsoft Active Directory e Active Directory Certificate Services, questo è un obiettivo assolutamente raggiungibile. Per le organizzazioni prive di tale infrastruttura, rappresenta un investimento significativo. PEAP-MSCHAPv2 è il metodo più ampiamente implementato nella pratica. Crea un tunnel TLS utilizzando solo un certificato lato server, quindi trasmette le credenziali di nome utente e password all'interno di tale tunnel. È compatibile praticamente con ogni dispositivo fin da subito, si integra direttamente con Active Directory tramite NPS su Windows Server e non richiede certificati client. Il compromesso è che è vulnerabile agli attacchi di harvesting delle credenziali se gli utenti vengono indotti a connettersi a un AP non autorizzato - poiché il client non convalida il certificato del server per impostazione predefinita. È necessario forzare la convalida del certificato del server nei profili supplicant. EAP-TTLS è simile a PEAP ma più flessibile nel metodo di autenticazione interno. È comune negli ambienti Linux e dove è necessario supportare backend di autenticazione legacy. EAP-FAST è stato sviluppato da Cisco in risposta ai punti deboli di LEAP. Utilizza Protected Access Credentials anziché certificati. È rilevante principalmente se ci si trova in un ambiente a forte presenza Cisco o se si gestiscono dispositivi legacy che non possono supportare gli altri metodi. EAP-SIM ed EAP-AKA sono utilizzati nelle implementazioni di livello carrier - come OpenRoaming o Passpoint - in cui l'autenticazione è legata a una scheda SIM o USIM. Questi sono sempre più rilevanti per il WiFi nei luoghi pubblici dove si desidera un onboarding sicuro e senza interruzioni senza un Captive Portal. Parliamo ora della configurazione RADIUS. Sia che si stia implementando Microsoft NPS, FreeRADIUS, Cisco ISE o Aruba ClearPass, i passaggi di configurazione principali sono i medesimi. In primo luogo, si definiscono i client RADIUS - questi sono gli access points o i wireless LAN controllers. Ogni client viene registrato con il proprio indirizzo IP e un segreto condiviso. Tale segreto condiviso viene utilizzato per autenticare i messaggi RADIUS tra l'AP e il server. Utilizzare un minimo di 22 caratteri, generati casualmente e univoci per ciascun dispositivo NAS. In secondo luogo, si configura la policy di rete. Qui si definisce chi ha accesso a cosa. In termini di NPS, si sta creando una Network Policy che corrisponde a determinate condizioni - appartenenza a un gruppo in Active Directory, tipo di dispositivo, ora del giorno - e assegna attributi - VLAN ID, timeout di sessione, limiti di larghezza di banda. L'attributo RADIUS che si utilizzerà più spesso è l'assegnazione della VLAN, in particolare Tunnel-Type impostato su VLAN, Tunnel-Medium-Type impostato su 802 e Tunnel-Private-Group-ID impostato sul numero della propria VLAN. In terzo luogo, si configura la politica di richiesta di connessione. Questa indica a NPS come gestire le richieste RADIUS in arrivo - se autenticarle localmente o inoltrarle a un altro server RADIUS. In una distribuzione distribuita, potreste avere un server RADIUS centrale con proxy NPS in ogni sito. Per quanto riguarda i certificati, per PEAP e EAP-TLS, il vostro server RADIUS ha bisogno di un certificato server considerato attendibile dai vostri client. La via più semplice è utilizzare un certificato di una CA pubblica - DigiCert, Sectigo, Let's Encrypt - perché tali certificati root sono già considerati attendibili da tutti i principali sistemi operativi. Se si utilizza una CA interna, è necessario distribuire il certificato root a tutti i dispositivi client tramite Criteri di gruppo o la piattaforma MDM. Specificamente per EAP-TLS, sono necessari anche i certificati client. In un ambiente Active Directory, si utilizzerà ADCS con registrazione automatica tramite Criteri di gruppo per distribuire i certificati ai dispositivi associati al dominio. Per i dispositivi BYOD, utilizzerete il vostro MDM - Intune, Jamf, VMware Workspace ONE - per distribuire sia il certificato che il profilo WiFi. Sul lato dell'access point, la configurazione è semplice. Si crea un nuovo SSID, si imposta la sicurezza su WPA2-Enterprise o WPA3-Enterprise, si punta il server di autenticazione RADIUS sull'IP del vostro NPS sulla porta UDP 1812, si imposta il server di accounting RADIUS sulla porta UDP 1813, si inserisce la chiave segreta condivisa e si abilita l'assegnazione dinamica della VLAN, se utilizzata. La maggior parte delle piattaforme AP aziendali - Cisco Meraki, Aruba, Ruckus, Extreme - dispone di una GUI per questo processo che richiede circa dieci minuti una volta che il server RADIUS è pronto. [RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE DA EVITARE - circa 2 minuti] Bene, parliamo di dove le distribuzioni tendono a fallire, perché è proprio qui che guadagno le mie parcelle di consulenza. Il punto di errore più comune è la validazione del certificato. Ho visto organizzazioni distribuire PEAP-MSCHAPv2 correttamente sul lato server, per poi lasciare i profili del supplicant client configurati per accettare qualsiasi certificato. Questo vanifica completamente il modello di sicurezza. Ogni profilo di supplicant - sia esso distribuito tramite Criteri di gruppo o MDM - deve specificare la CA root attendibile e il nome del server previsto. Senza questo, si è vulnerabili agli attacchi evil twin. Il secondo problema comune è la gestione della chiave segreta condivisa RADIUS. Ho visto reti di produzione funzionare con la chiave segreta impostata su "radius" o sul valore predefinito del fornitore. Queste chiavi segrete sono le chiavi d'accesso alla vostra infrastruttura di autenticazione. Generatele in modo casuale, memorizzatele in un gestore di segreti e ruotatele periodicamente. Terzo: la configurazione errata delle VLAN. L'assegnazione dinamica delle VLAN è potente - consente di inserire i dispositivi del personale sulla VLAN aziendale, i collaboratori esterni su una VLAN limitata e i dispositivi IoT su una VLAN isolata, il tutto dallo stesso SSID. Ma se gli attributi RADIUS non sono configurati correttamente, o se le porte trunk dello switch non trasportano le VLAN corrette, i dispositivi non riusciranno a connettersi o finiranno sul segmento sbagliato. Testate questo aspetto a fondo in un laboratorio prima di passare alla produzione. Quarto: ridondanza. Il vostro server RADIUS è ora un elemento critico dell'infrastruttura. Se si interrompe, nessuno si connette. È necessario configurare come minimo un server RADIUS primario e uno secondario su ogni AP. Nelle grandi distribuzioni, prendete in considerazione cluster proxy RADIUS con monitoraggio dello stato. Quinto, e questo è specifico per gli ambienti dell'ospitalità e del retail: separazione tra ospiti e rete aziendale. Il vostro SSID aziendale 802.1X e il vostro SSID WiFi per gli ospiti devono essere completamente separati - VLAN diverse, policy di firewall diverse, DNS diversi. Una piattaforma come Purple gestisce la parte ospiti con il proprio Captive Portal e il proprio livello di analytics, mentre l'infrastruttura 802.1X gestisce la parte aziendale. Si tratta di sistemi complementari, non concorrenti. [DOMANDE E RISPOSTE RAPIDE - circa 1 minuto] Esaminiamo le domande che ricevo più spesso. Posso eseguire 802.1X su una piattaforma AP gestita in cloud? Sì - Meraki, Aruba Central e Ruckus Cloud lo supportano. Configurate i dettagli del server RADIUS nella dashboard cloud e gli AP gestiranno il proxying EAP. Ho bisogno di Active Directory? No. FreeRADIUS può autenticarsi tramite LDAP, database SQL, file flat o persino API REST. Ma l'integrazione AD tramite NPS è di gran lunga il percorso aziendale più comune. E per i dispositivi IoT che non supportano 802.1X? Usate il MAC Authentication Bypass - MAB - come soluzione di ripiego. L'indirizzo MAC del dispositivo viene inviato a RADIUS come nome utente e password. Non è sicuro come l'EAP, ma vi consente di abilitare i dispositivi IoT mantenendoli in una VLAN limitata. L'802.1X funziona con WPA3? Sì. WPA3-Enterprise è essenzialmente WPA3 con autenticazione 802.1X. Aggiunge una crittografia più forte - a 192 bit nella modalità ad alta sicurezza - ed è lo standard raccomandato per le nuove distribuzioni. [RIASSUNTO E PROSSIMI PASSI - circa 1 minuto] Quindi, per riassumere: l'802.1X non è un optional. Per qualsiasi organizzazione che gestisca dati sensibili, elabori pagamenti o operi in un ambiente regolamentato, rappresenta la linea di base per la sicurezza WiFi aziendale. L'architettura è consolidata, gli strumenti sono maturi e il percorso di implementazione è chiaro. Iniziate con la scelta del metodo EAP - PEAP-MSCHAPv2 se avete bisogno di risultati rapidi e di un'ampia compatibilità, EAP-TLS se disponete dell'infrastruttura PKI e avete bisogno del massimo livello di sicurezza. Configurate il server RADIUS e assicuratevi che sia ridondante prima di toccare un singolo AP. Inviate i profili supplicant tramite Criteri di gruppo o MDM prima di andare online. E mantenete il vostro WiFi per gli ospiti completamente separato - utilizzate una piattaforma dedicata per quel livello. Se operate in un ambiente multi-sede - hotel, catene di negozi, stadi - la complessità aumenta con il numero di siti, ma l'architettura non cambia. La chiave è un RADIUS centralizzato con ridondanza locale per sito e un profilo supplicant coerente inviato tramite MDM a tutta la flotta di dispositivi.Grazie per l'ascolto. La guida scritta completa, i diagrammi di architettura e le checklist di configurazione sono disponibili su purple.ai. Se state pianificando un'implementazione di 802.1X e desiderate discutere i dettagli specifici del vostro ambiente, contattate direttamente il team di Purple.