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. Vi parlo oggi 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é il vostro assicuratore lo ha richiesto, o semplicemente perché avete ereditato una rete che funziona su una PSK condivisa e sapete bene che questo non è più sufficiente. Quindi entriamo subito nel merito. 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 vostra rete sia stato identificato e autorizzato in modo certo prima di poter far transitare anche un solo byte di traffico. Questo non è opzionale per le organizzazioni che gestiscono dati di carte di pagamento secondo lo standard PCI-DSS, non è opzionale per gli ambienti sanitari ai sensi del GDPR e degli standard di sicurezza dei dati 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 la situazione si fa complessa. Cominciiamo. [APPROFONDIMENTO TECNICO - circa 5 minuti] Bene, l'infrastruttura 802.1X si compone di tre elementi. Abbiamo il Supplicant - ovvero il dispositivo client, il laptop, il telefono, il sensore IoT. Abbiamo l'Authenticator - ovvero 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 lo fa semplicemente accedere. Al contrario, apre quella che viene chiamata una porta controllata - un canale limitato che trasmette solo traffico EAP, l'Extensible Authentication Protocol. L'AP invia un messaggio di 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 di 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 è estremamente importante. Ce ne sono cinque che si incontrano tipicamente 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 è necessaria 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 dotate di Microsoft Active Directory e Active Directory Certificate Services, questo è facilmente realizzabile. Per le organizzazioni prive di tale infrastruttura, rappresenta un investimento significativo. PEAP-MSCHAPv2 è il metodo più comunemente distribuito nella pratica. Crea un tunnel TLS utilizzando solo un certificato lato server, quindi passa 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 raccolta delle credenziali se gli utenti vengono indotti a connettersi a un AP non autorizzato - perché il client non convalida il certificato del server per impostazione predefinita. È necessario forzare 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 dove è necessario supportare backend di autenticazione legacy. EAP-FAST è stato sviluppato da Cisco come risposta ai punti deboli di LEAP. Utilizza Protected Access Credentials anziché certificati. È rilevante principalmente se ti trovi in un ambiente prevalentemente Cisco o se hai a che fare con dispositivi legacy che non supportano gli altri metodi. EAP-SIM ed EAP-AKA sono utilizzati nelle distribuzioni di livello carrier - come OpenRoaming o Passpoint - dove 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. Ora parliamo della configurazione RADIUS. Sia 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 - questi sono i tuoi access point o controller LAN wireless. Ogni client è registrato con il suo 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 dispositivo NAS. In secondo luogo, configuri la tua policy di rete. Qui definisci chi ha accesso a cosa. In termini di NPS, crei 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 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 - 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. Sul fronte dei certificati, per PEAP ed EAP-TLS, il server RADIUS necessita di un certificato server considerato attendibile dai client. Il percorso 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 aggiunti al dominio. Per i dispositivi BYOD, si utilizzerà il proprio 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 sull'IP del 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 per questa operazione che richiede circa dieci minuti una volta che il server RADIUS è pronto. [CONSIGLI DI IMPLEMENTAZIONE ED ERRORI COMUNI - circa 2 minuti] Bene, parliamo di dove le distribuzioni falliscono, perché è qui che guadagno le mie parcelle di consulenza. Il punto di errore più comune è la convalida del certificato. Ho visto organizzazioni distribuire PEAP-MSCHAPv2 correttamente 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 secondo una pianificazione. Terzo: configurazione errata della VLAN. L'assegnazione dinamica della VLAN è uno strumento potente - consente di inserire i dispositivi del personale nella VLAN aziendale, i consulenti 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 è ora 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. In implementazioni di grandi dimensioni, prendi in considerazione cluster proxy RADIUS con monitoraggio dello stato di salute. Quinto, e questo è specifico per i settori hospitality e retail: separazione tra reti ospiti e aziendali. L'SSID aziendale 802.1X e l'SSID WiFi ospiti devono essere completamente separati - VLAN diverse, policy firewall diverse, DNS diversi. Una piattaforma come Purple gestisce il lato ospiti con il proprio captive portal e il livello di analytics, mentre l'infrastruttura 802.1X gestisce il lato aziendale. Si tratta di sistemi complementari, non in competizione tra loro. [D&R 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 tutti. È 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 AD tramite NPS è di gran lunga il percorso aziendale più comune. Cosa fare con i dispositivi IoT che non supportano 802.1X? Usa 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 EAP, ma consente di integrare i dispositivi IoT mantenendoli in una VLAN limitata. Il protocollo 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 installazioni. [RIASSUNTO E PROSSIMI PASSI - circa 1 minuto] Quindi, per riassumere: 802.1X non è un'opzione superflua. Per qualsiasi organizzazione che gestisca dati sensibili, elabori pagamenti o operi in un ambiente regolamentato, rappresenta la base per la sicurezza 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 hai bisogno del massimo livello di sicurezza. Configura il tuo server RADIUS e la relativa ridondanza prima di toccare un singolo AP. Distribuisci i profili del supplicant tramite Group Policy o MDM prima di andare online. E mantieni il WiFi ospiti completamente separato - usa 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 server RADIUS centralizzato con ridondanza locale per ciascun 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 state pianificando un'implementazione di 802.1X e desiderate discutere i dettagli specifici del vostro ambiente, contattate direttamente il team di Purple.