Come configurare l'autenticazione WiFi 802.1X: una 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. Oggi vi parlo in veste 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 con una PSK condivisa e sapete bene che non è più sufficiente. Andiamo dritti al punto. L'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 rete sia stato identificato e autorizzato in modo certo prima di poter trasmettere anche un solo byte di traffico. Questo non è opzionale per le organizzazioni che gestiscono dati di carte di pagamento ai sensi del PCI DSS, non è opzionale per gli ambienti sanitari ai sensi del GDPR e degli standard di sicurezza dei dati del NHS e, francamente, 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 si compone di tre elementi. Abbiamo il Supplicant — ovvero il dispositivo client, il laptop, il telefono, il sensore IoT. Abbiamo l'Authenticator — cioè l'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 si limita a farlo accedere. Al contrario, apre quella che viene definita una porta controllata — un canale limitato che trasmette solo traffico EAP, l'Extensible Authentication Protocol. L'AP invia una richiesta EAP-Request Identity al dispositivo. Il dispositivo risponde con la propria identità. L'AP la inoltra quindi al server RADIUS, incapsulata 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 restituisce un Access-Accept o un 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 che sceglierete in questa fase è di fondamentale importanza. Ne incontrerete principalmente cinque nelle implementazioni aziendali. EAP-TLS è il gold standard. Sia il client che il server presentano certificati X.509. Non sono coinvolte password. È l'opzione più sicura e quella richiesta per i livelli di conformità PCI DSS più elevati. L'unico inconveniente è che è necessaria una PKI completa — una Public Key Infrastructure — per emettere e gestire i certificati client. Ciò significa un'Autorità di Certificazione, la gestione del ciclo di vita dei certificati e un meccanismo per distribuire i certificati su ogni dispositivo. Per le organizzazioni con Microsoft Active Directory e Active Directory Certificate Services, questo è un obiettivo decisamente raggiungibile. Per le organizzazioni prive di tale infrastruttura, rappresenta un investimento significativo. PEAP-MSCHAPv2 è il metodo più diffuso nella pratica. Crea un tunnel TLS utilizzando solo un certificato lato server, quindi trasmette le credenziali di nome utente e password all'interno di quel tunnel. È compatibile con quasi tutti i dispositivi 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 raccolta 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 imporre la convalida del certificato del server nei profili del supplicant. EAP-TTLS è simile a PEAP ma più flessibile nel metodo di autenticazione interno. È comune negli ambienti Linux e laddove sia 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 soprattutto se ti trovi in un ambiente prevalentemente Cisco o se gestisci dispositivi legacy che non possono supportare gli altri metodi. EAP-SIM ed EAP-AKA sono utilizzati nelle distribuzioni di livello carrier — come OpenRoaming o Passpoint — in cui l'autenticazione è legata a una scheda SIM o USIM. Questi metodi sono sempre più rilevanti per il WiFi nei luoghi pubblici in cui si desidera un onboarding sicuro e senza interruzioni, senza un Captive Portal. Parliamo ora della configurazione RADIUS. Che tu stia distribuendo Microsoft NPS, FreeRADIUS, Cisco ISE o Aruba ClearPass, i passaggi di configurazione principali sono gli stessi. In primo luogo, definisci i tuoi client RADIUS — ovvero i tuoi punti di accesso o controller LAN wireless. 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. Utilizza un minimo di 22 caratteri, generati casualmente e univoci per ciascun dispositivo NAS. In secondo luogo, configuri i criteri di rete. Qui definisci chi ha accesso a cosa. In termini NPS, stai creando un criterio di rete che soddisfa determinate condizioni — appartenenza a un gruppo in Active Directory, tipo di dispositivo, ora del giorno — e assegna attributi — ID VLAN, timeout della sessione, limiti di larghezza di banda. L'attributo RADIUS che utilizzerai di più è 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 tua VLAN. In terzo luogo, si configura il criterio di richiesta di connessione. Questo indica a NPS come gestire le richieste RADIUS in entrata, ovvero se autenticarle localmente o inoltrarle a un altro server RADIUS. In una distribuzione distribuita, si potrebbe avere un server RADIUS centrale con proxy NPS in ciascun sito. Per quanto riguarda i certificati, per PEAP ed EAP-TLS, il server RADIUS necessita di un certificato server attendibile per i client. La via più semplice è utilizzare un certificato di una CA pubblica (DigiCert, Sectigo, Let's Encrypt), poiché 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 (Group Policy) 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 aggiunti al dominio. Per i dispositivi BYOD, si utilizzerà l'MDM (Intune, Jamf, VMware Workspace ONE) per distribuire sia il certificato sia il profilo WiFi. Sul lato 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 all'IP di NPS sulla porta UDP 1812, si imposta il server di accounting RADIUS sulla porta UDP 1813, si inserisce il segreto condiviso e si abilita l'assegnazione dinamica della VLAN se la si utilizza. La maggior parte delle piattaforme AP aziendali (Cisco Meraki, Aruba, Ruckus, Extreme) dispone di una GUI dedicata che richiede circa dieci minuti una volta che il server RADIUS è pronto. [RACCOMANDAZIONI DI IMPLEMENTAZIONE E TRAPPOLE COMUNI — circa 2 minuti] Bene, parliamo di dove le distribuzioni falliscono, perché è qui che si giustificano le mie tariffe di consulenza. Il punto di errore più comune è la convalida del certificato. Ho visto organizzazioni distribuire correttamente PEAP-MSCHAPv2 sul lato server, per poi lasciare i profili supplicant dei client configurati per accettare qualsiasi certificato. Questo mina completamente il modello di sicurezza. Ogni profilo 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 del segreto condiviso RADIUS. Ho visto reti di produzione funzionare con il segreto condiviso impostato su "radius" o sul valore predefinito del fornitore. Questi segreti sono le chiavi della vostra infrastruttura di autenticazione. Generateli in modo casuale, memorizzateli in un gestore di segreti e ruotateli periodicamente. Terzo: configurazione errata della VLAN. L'assegnazione dinamica della VLAN è potente: consente di inserire i dispositivi del personale nella VLAN aziendale, i collaboratori esterni in una VLAN limitata e i dispositivi IoT in 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 server RADIUS è ormai un elemento critico dell'infrastruttura. Se smette di funzionare, nessuno si connette. È necessario configurare come minimo un server RADIUS primario e uno secondario su ogni AP. Nelle implementazioni su larga scala, prendi in considerazione i cluster proxy RADIUS con monitoraggio dello stato. Quinto, e questo è specifico per i settori hospitality e retail: separazione tra rete ospiti e aziendale. L'SSID aziendale 802.1X e l'SSID del WiFi 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 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] Passiamo in rassegna 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. È sufficiente configurare 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. Tuttavia, l'integrazione con AD tramite NPS è di gran lunga il percorso aziendale più comune. E per i dispositivi IoT che non supportano l'802.1X? Utilizza il MAC Authentication Bypass (MAB) come soluzione di fallback. L'indirizzo MAC del dispositivo viene inviato a RADIUS come nome utente e password. Non è sicuro come l'EAP, ma consente di integrare 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 consigliato per le nuove implementazioni. [Riepilogo e passaggi successivi — circa 1 minuto] Quindi, per riassumere: l'802.1X non è un optional. Per qualsiasi organizzazione che gestisce dati sensibili, elabora pagamenti o opera in un ambiente regolamentato, rappresenta lo standard di base per la sicurezza del WiFi aziendale. L'architettura è consolidata, gli strumenti sono maturi e il percorso di implementazione è chiaro. Inizia con la selezione del metodo EAP: PEAP-MSCHAPv2 se hai bisogno di risultati rapidi e di un'ampia compatibilità, EAP-TLS se disponi dell'infrastruttura PKI e necessiti del massimo livello di sicurezza. Configura il server RADIUS e la ridondanza prima di toccare un singolo AP. Distribuisci i profili supplicant tramite Group Policy o MDM prima di andare online. E mantieni il WiFi ospiti completamente separato, utilizzando una piattaforma dedicata per quel livello. Se gestisci 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 distribuito tramite MDM su 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 stai pianificando una distribuzione 802.1X e desideri discutere le specifiche del tuo ambiente, contatta direttamente il team di Purple.