Come configurare l'autenticazione WiFi 802.1X: una guida dettagliata

Come configurare l'autenticazione WiFi 802.1X: una guida passo dopo passo Un podcast di Purple Enterprise WiFi Intelligence [INTRODUZIONE — circa 1 minuto] Benvenuti di nuovo. 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 compliance l'ha segnalato, o perché il vostro assicuratore lo ha richiesto, oppure perché avete appena ereditato una rete che funziona su una chiave PSK condivisa e sapete bene che non è più sufficiente. Quindi entriamo subito nel vivo. Lo standard 802.1X è lo standard IEEE per il controllo dell'accesso alla rete basato su porte. È 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 ricevere anche un solo byte di traffico. Non si tratta di un'opzione facoltativa per le organizzazioni che gestiscono i dati delle carte di pagamento ai sensi dello standard PCI-DSS, non è facoltativa per gli ambienti sanitari ai sensi del GDPR e degli standard di sicurezza dei dati del SSN 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 complica. Cominciamo. [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 - che è il vostro access point o il vostro switch di rete, talvolta chiamato NAS, il Network Access Server. E infine 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 il traffico EAP, l'Extensible Authentication Protocol. L'AP invia un pacchetto 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 messaggio di Access-Accept o di 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. Ne esistono cinque che incontrerete nelle implementazioni aziendali. EAP-TLS è lo standard di riferimento. 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. Il problema è 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 è facilmente realizzabile. 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 con quasi tutti i dispositivi pronti all'uso, 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 supplicant. EAP-TTLS è simile a PEAP ma più flessibile nel metodo di autenticazione interno. È comune negli ambienti Linux e laddove è 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 ci si trova in un ambiente a forte presenza Cisco o se si gestiscono dispositivi legacy che non supportano gli altri metodi. EAP-SIM ed EAP-AKA sono utilizzati nelle distribuzioni di livello carrier - si pensi a OpenRoaming o Passpoint - in cui l'autenticazione è legata a una scheda SIM o USIM. Questi metodi sono sempre più rilevanti per il WiFi dei luoghi pubblici in cui si desidera un onboarding sicuro e senza interruzioni senza un Captive Portal. Parliamo ora della configurazione RADIUS. Sia che si stia distribuendo Microsoft NPS, FreeRADIUS, Cisco ISE o Aruba ClearPass, i passaggi fondamentali di configurazione sono gli stessi. In primo luogo, si definiscono i client RADIUS: questi sono i punti di accesso o i 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. Utilizzare un minimo di 22 caratteri, generati casualmente e univoci per ogni dispositivo NAS. In secondo luogo, si configura la policy di rete. Qui si definisce chi ottiene l'accesso a cosa. In termini NPS, si crea una Network Policy che soddisfa determinate condizioni - appartenenza a un gruppo in Active Directory, tipo di dispositivo, ora del giorno - e assegna attributi - ID VLAN, timeout di sessione, limiti di larghezza di banda. L'attributo RADIUS che verrà utilizzato 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 propria 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, potreste avere un server RADIUS centrale con proxy NPS presso ciascun sito. Per quanto riguarda i certificati, per PEAP ed EAP-TLS, il server RADIUS necessita di un certificato server considerato attendibile dai client. La via più semplice consiste nell'utilizzare un certificato rilasciato da una CA pubblica - DigiCert, Sectigo, Let's Encrypt - poiché tali certificati root sono già considerati attendibili da tutti i principali sistemi operativi. Se utilizzate una CA interna, dovete distribuire il certificato root a tutti i dispositivi client tramite Criteri di gruppo o la vostra piattaforma MDM. Specificamente per EAP-TLS, sono necessari anche i certificati client. In un ambiente Active Directory, utilizzereste ADCS con registrazione automatica tramite Criteri di gruppo per inviare i certificati ai dispositivi aggiunti al dominio. Per i dispositivi BYOD, utilizzereste il vostro MDM - Intune, Jamf, VMware Workspace ONE - per distribuire sia il certificato sia il profilo WiFi. Sul lato access point, la configurazione è semplice. Create un nuovo SSID, impostate la sicurezza su WPA2-Enterprise o WPA3-Enterprise, puntate il server di autenticazione RADIUS sull'IP del vostro NPS sulla porta UDP 1812, impostate il server di accounting RADIUS sulla porta UDP 1813, inserite il segreto condiviso e abilitate l'assegnazione dinamica della VLAN, se la utilizzate. La maggior parte delle piattaforme AP aziendali - Cisco Meraki, Aruba, Ruckus, Extreme - dispone di una GUI dedicata che richiede circa dieci minuti di configurazione una volta che il server RADIUS è pronto. [CONSIGLI DI IMPLEMENTAZIONE E TRAPPOLE COMUNI - circa 2 minuti] Bene, parliamo di dove i deployment tendono a fallire, perché è proprio qui che si gioca la mia reputazione di consulente. Il punto di vulnerabilità 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 in modo da accettare qualsiasi certificato. Questo vanifica completamente il modello di sicurezza. Ogni profilo supplicant - che sia distribuito tramite Criteri di gruppo o MDM - deve specificare la CA root attendibile e il nome del server previsto. Senza questo accorgimento, sarete vulnerabili agli attacchi di tipo "evil twin". Il secondo problema comune è la gestione del segreto condiviso RADIUS. Ho visto reti di produzione attive con il segreto condiviso impostato su "radius" o sul valore predefinito del fornitore. Questi segreti sono le chiavi di accesso alla vostra infrastruttura di autenticazione. Generateli in modo casuale, memorizzateli in un gestore di credenziali e ruotateli periodicamente. Terzo: la configurazione errata delle VLAN. L'assegnazione dinamica della VLAN è uno strumento potente - vi consente di inserire i dispositivi del personale sulla VLAN aziendale, i collaboratori esterni su una VLAN con restrizioni e i dispositivi IoT su una VLAN isolata, il tutto dallo stesso SSID. Tuttavia, se gli attributi RADIUS non sono configurati correttamente o se le porte trunk degli switch non trasportano le VLAN corrette, i dispositivi non riusciranno a connettersi o finiranno sul segmento sbagliato. Testate accuratamente questo aspetto in un ambiente di prova prima di passare alla produzione.Quarto: la 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 di grandi dimensioni, considera i cluster proxy RADIUS con monitoraggio dello stato. Quinto, e questo è specifico per i settori hospitality e retail: la separazione tra rete ospiti e aziendale. Il tuo SSID aziendale 802.1X e il tuo 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 relativo 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. Configura 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 di AD tramite NPS è di gran lunga il percorso aziendale più comune. E per i dispositivi IoT che non supportano 802.1X? Utilizza il MAC Authentication Bypass - MAB - come 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. 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: l'802.1X non è un optional. Per qualsiasi organizzazione che gestisce dati sensibili, elabora pagamenti o opera 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. Inizia con la selezione del metodo EAP - PEAP-MSCHAPv2 se hai bisogno di risultati rapidi e di un'ampia compatibilità, EAP-TLS se disponi di un'infrastruttura PKI e necessiti del massimo livello di sicurezza. Configura il tuo server RADIUS e impostalo come ridondante prima di toccare un singolo AP. Distribuisci i profili supplicant tramite Criteri di gruppo o MDM prima di andare online. E mantieni il tuo WiFi ospiti completamente separato - utilizza una piattaforma dedicata per quel livello. Se gestisci un ambiente multisede - 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 ogni 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 specificità del tuo ambiente, contatta direttamente il team di Purple.