Che cos'è l'autenticazione PEAP? Come il PEAP protegge il tuo WiFi

Cos'è l'autenticazione PEAP? In che modo PEAP protegge il tuo WiFi. Un documento informativo Purple Enterprise WiFi Intelligence. Benvenuto. Se hai la responsabilità della sicurezza di rete per un gruppo alberghiero, un patrimonio retail, uno stadio o un'organizzazione del settore pubblico, questo documento è per te. Nei prossimi dieci minuti parleremo dell'autenticazione PEAP - cos'è effettivamente, come funziona sotto il cofano, dove si colloca nella tua architettura di sicurezza e, soprattutto, quando rappresenta la scelta giusta rispetto a quando dovresti cercare qualcosa di più robusto. Entriamo nel vivo del discorso. Sezione uno: Contesto e perché questo è importante proprio ora. La maggior parte delle implementazioni di WiFi aziendali oggi si affida ancora a uno dei due modelli di autenticazione. O si dispone di una chiave precondivisa - una singola password condivisa in tutta l'organizzazione - o si dispone di 802.1X, lo standard IEEE per il controllo dell'accesso alla rete basato su porta. PEAP si colloca saldamente nel campo del 802.1X ed è di gran lunga il metodo EAP più diffuso negli ambienti aziendali e istituzionali a livello globale. Il motivo per cui PEAP è diventato così dominante è semplice: ha risolto un problema operativo reale. Prima di PEAP, l'implementazione dell'autenticazione WiFi basata su certificati significava emettere certificati client per ogni dispositivo - ogni laptop, ogni telefono, ogni tablet. Per un'organizzazione con cinquecento dipendenti e una politica BYOD, questo rappresentava un mal di testa per l'implementazione di PKI per cui la maggior parte dei team IT semplicemente non aveva il budget o il tempo. PEAP ha offerto una via di mezzo: una forte autenticazione lato server tramite TLS, con credenziali di nome utente e password sul lato client. Nessun certificato client richiesto. Questo compromesso ha reso PEAP lo standard de facto per l'autenticazione WiFi aziendale per tutti gli anni 2000 e 2010, e rimane estremamente comune oggi. Comprenderne l'architettura - e i suoi limiti - è essenziale per chiunque debba prendere decisioni sulle infrastrutture nel 2024 e oltre. Sezione due: Approfondimento tecnico. Esaminiamo esattamente cosa succede quando un dispositivo si autentica tramite PEAP. Il processo si articola in due fasi distinte, e comprenderle entrambe è fondamentale. I tre attori in questo scambio sono: il supplicant - ovvero il dispositivo client, sia esso un laptop, uno smartphone o un terminale IoT; l'authenticator - tipicamente l'access point wireless o il controller LAN wireless; e l'authentication server - quasi sempre un server RADIUS, come Microsoft NPS, FreeRADIUS o un servizio RADIUS ospitato in cloud. La fase uno consiste nello stabilire il tunnel TLS. Quando il supplicant tenta di connettersi, l'authenticator non concede l'accesso immediatamente. Al contrario, avvia uno scambio EAP sulla rete locale - questo è EAPOL, EAP over LAN. L'authenticator lo inoltra al server RADIUS, che presenta il suo certificato TLS lato server al client. Il client convalida tale certificato rispetto al suo archivio di certificati attendibili. Se la convalida ha esito positivo, viene stabilito un tunnel TLS tra il client e il server RADIUS. Questo tunnel è crittografato - in genere TLS 1.2 o 1.3 nelle implementazioni moderne. La seconda fase è l'autenticazione interna. All'interno di quel tunnel crittografato avviene lo scambio delle credenziali effettive. Nella distribuzione più comune - PEAP-MSCHAPv2 - il client invia un nome utente e una password utilizzando il protocollo Microsoft Challenge Handshake Authentication Protocol versione 2. Il server RADIUS convalida tali credenziali confrontandole con il proprio archivio di identità, che potrebbe essere Active Directory, LDAP o un provider di identità cloud. Se le credenziali sono corrette, il server RADIUS invia un messaggio di Access-Accept al dispositivo di autenticazione e al client viene concesso l'accesso alla rete. La proprietà di sicurezza fondamentale in questo caso è che lo scambio MSCHAPv2 avviene all'interno del tunnel TLS. Un utente malintenzionato che monitora passivamente il canale wireless non può vedere le credenziali in transito. Questo è il valore fondamentale offerto da PEAP. Ora, quali sono i punti deboli di PEAP-MSCHAPv2? Ci sono due problemi significativi che qualsiasi progettista attento alla sicurezza deve comprendere. Primo: la convalida del certificato del server. PEAP richiede solo che il server presenti un certificato - non richiede che il client ne presenti uno. Ciò crea un vettore di attacco ampiamente documentato. Se un dispositivo client è configurato in modo errato per accettare qualsiasi certificato - o per accettare certificati da qualsiasi CA - un utente malintenzionato può attivare un access point non autorizzato, presentare un certificato fraudolento e intercettare l'handshake MSCHAPv2. Strumenti come hostapd-wpe hanno reso questo attacco incredibilmente accessibile. La mitigazione consiste in una rigorosa configurazione del supplicant: imporre la convalida del certificato del server, bloccare la CA prevista e specificare il Common Name del server. Questo è un aspetto non negoziabile in qualsiasi installazione professionale. Secondo: MSCHAPv2 è un protocollo datato con vulnerabilità note. Una ricerca del 2012 di Moxie Marlinspike ha dimostrato che le coppie challenge-response di MSCHAPv2 possono essere decifrate offline con una potenza di calcolo sufficiente. Se un utente malintenzionato riesce a catturare lo scambio di autenticazione interno - ad esempio tramite l'attacco dell'access point non autorizzato descritto sopra - può tentare di recuperare la password in chiaro offline. La robustezza della policy sulle password influisce quindi direttamente sull'esposizione del sistema. Password lunghe, complesse e generate casualmente riducono significativamente questo rischio. Confrontiamo questo scenario con EAP-TLS, in cui sia il server sia il client presentano certificati. Non ci sono password da sottrarre. La superficie di attacco è drasticamente ridotta. Il compromesso risiede nella complessità operativa: è necessaria una PKI, occorre emettere e gestire i certificati client e serve un meccanismo per distribuirli a ogni dispositivo. Per le organizzazioni con una gestione MDM matura e una PKI ben gestita, EAP-TLS rappresenta lo standard di riferimento. Per tutte le altre, PEAP-MSCHAPv2 configurato in modo rigoroso rimane una scelta difendibile e pratica. Sezione tre: Raccomandazioni di implementazione e insidie comuni. Ecco alcune linee guida pratiche per l'implementazione. Questi sono gli accorgimenti che distinguono una distribuzione PEAP sicura da una vulnerabile. Numero uno: imporre la convalida del certificato del server su ogni supplicant. Questo è l'elemento di configurazione in assoluto più importante. In Windows, si tratta della casella di controllo "Convalida certificato server" nel profilo della rete wireless. In iOS e Android, è il campo del certificato CA nella configurazione EAP. Se questo non è configurato, la tua implementazione PEAP è vulnerabile ad attacchi di rogue AP, indipendentemente da quanto bene sia configurato tutto il resto. Numero due: distribuire tramite MDM o GPO, non tramite configurazione manuale. La configurazione manuale da parte degli utenti finali non è affidabile. Gli utenti cliccheranno per ignorare gli avvisi di certificato. Configureranno in modo errato il campo CA. Distribuisci i tuoi profili wireless tramite Microsoft Intune, Jamf o Criteri di gruppo. Questo garantisce una configurazione del supplicant coerente e conforme alle policy in tutta la tua infrastruttura. Numero tre: utilizzare TLS 1.2 come minimo sul server RADIUS. Disabilita TLS 1.0 e 1.1. La maggior parte delle implementazioni RADIUS moderne supporta questa opzione, ma vale la pena verificarlo - in particolare sulle implementazioni on-premises più datate. Numero quattro: integrare con il proprio identity provider. PEAP-MSCHAPv2 autentica a fronte di un archivio di credenziali. Tale archivio dovrebbe essere il tuo identity provider autorevole - Active Directory, Azure AD tramite estensione NPS o un servizio RADIUS in cloud con integrazione LDAP. Ciò significa che quando un dipendente lascia l'azienda, la disattivazione del suo account revoca immediatamente il suo accesso alla rete WiFi. Nessun segreto condiviso da ruotare, nessun deprovisioning manuale. Numero cinque: considerare la rete guest separatamente. PEAP è un metodo di autenticazione enterprise. Per il WiFi ospiti - in cui si registrano visitatori, clienti o partecipanti a eventi - è necessario un approccio diverso. Piattaforme come Purple forniscono un livello WiFi ospiti dedicato che gestisce l'autenticazione tramite Captive Portal, l'acquisizione dei dati e l'analisi senza richiedere un'infrastruttura RADIUS sul SSID guest. Mantieni il tuo SSID enterprise su 802.1X con PEAP e il tuo SSID guest su una rete separata e isolata con un onboarding appropriato. Numero sei: pianificare la rotazione dei certificati. Il certificato del server RADIUS scadrà. Quando ciò accadrà, ogni client che ha bloccato quel certificato non riuscirà a autenticarsi fino a quando non verrà distribuito il nuovo certificato. Inserisci il rinnovo del certificato nel tuo calendario operativo - almeno 90 giorni prima della scadenza - e testa il processo di rotazione in un ambiente di staging prima di distribuirlo in produzione. I problemi di malfunzionamento più comuni che riscontro sul campo sono: convalida del certificato non applicata, che porta alla vulnerabilità ai rogue AP; certificati del server RADIUS che scadono senza preavviso, causando interruzioni diffuse dell'autenticazione; e autenticazione interna MSCHAPv2 esposta perché il server RADIUS è accessibile dal segmento di rete errato. Tutti e tre sono evitabili con una corretta pianificazione. Sezione quattro: Domande a raffica. PEAP può funzionare con provider di identità cloud come Azure AD? Sì. L'estensione NPS di Microsoft per Azure AD MFA consente di inoltrare l'autenticazione PEAP tramite Azure AD, abilitando l'autenticazione a più fattori sul tuo WiFi. In alternativa, i servizi RADIUS cloud come Cisco ISE, Aruba ClearPass o JumpCloud RADIUS possono integrarsi direttamente con Azure AD o Okta. PEAP è conforme allo standard PCI-DSS? PEAP-MSCHAPv2 può essere utilizzato in ambienti PCI-DSS, ma è necessario assicurarsi che la convalida del certificato del server sia forzata, che sia in uso TLS 1.2 o superiore e che il server RADIUS sia adeguatamente segmentato. PCI-DSS 4.0 inasprisce i requisiti relativi ai controlli di accesso alla rete - verifica i requisiti pertinenti con il tuo QSA. Dovrei migrare da PEAP a EAP-TLS? Se disponi di una distribuzione MDM matura e della capacità operativa per gestire una PKI, sì - EAP-TLS rappresenta la scelta più solida. Se gestisci un parco dispositivi misto con dispositivi personali, hardware legacy o una copertura MDM limitata, PEAP-MSCHAPv2 con una configurazione rigorosa rimane appropriato. Si tratta di una decisione basata sul rischio, non di una scelta binaria. E per quanto riguarda WPA3-Enterprise? WPA3-Enterprise impone la modalità di sicurezza a 192 bit per gli ambienti ad alta sicurezza, ma supporta comunque i metodi EAP, incluso PEAP. WPA3 migliora la crittografia via etere ma non modifica lo scambio di autenticazione EAP in sé. Quinta sezione: Riepilogo e prossimi passi. Per riassumere: PEAP è un protocollo di autenticazione a due fasi che racchiude le credenziali interne - in genere MSCHAPv2 - all'interno di un tunnel TLS. È il metodo 802.1X EAP più diffuso perché elimina la necessità di certificati client pur fornendo una solida autenticazione del server. La sua vulnerabilità principale è rappresentata dagli attacchi tramite AP canaglia (rogue AP), resi possibili da supplicant configurati in modo errato che non convalidano il certificato del server. Puoi mitigare questo problema attraverso profili wireless imposti via MDM, il pinning della CA e la convalida del nome del server. Per la maggior parte delle distribuzioni WiFi aziendali - uffici aziendali, reti back-of-house degli hotel, reti per il personale di vendita al dettaglio - PEAP-MSCHAPv2 con una configurazione corretta rappresenta una scelta solida e difendibile. Per gli ambienti ad alta sicurezza, i settori regolamentati o le organizzazioni con un'infrastruttura PKI matura, EAP-TLS offre una sicurezza significativamente più forte e dovrebbe essere l'architettura di riferimento. Se gestisci anche un WiFi per gli ospiti parallelamente alla tua rete aziendale - come fa la maggior parte di voi - ricorda che PEAP non è lo strumento adatto per l'onboarding degli ospiti. Prendi in considerazione piattaforme come Purple, che offrono un'autenticazione WiFi per gli ospiti creata appositamente con funzionalità di analytics, acquisizione dati e integrazione di marketing, mantenendo il traffico degli ospiti e quello aziendale adeguatamente separati e preservando la tua conformità. Per ulteriori letture, consulta le guide di Purple sull'architettura dei server RADIUS e sull'autenticazione WiFi aziendale. I link si trovano nelle note del programma. Grazie per l'ascolto. Questa è stata una sessione informativa Purple Enterprise WiFi Intelligence Briefing.