Cos'è l'autenticazione PEAP? Come PEAP protegge il tuo WiFi

Che cos'è l'autenticazione PEAP? Come il PEAP protegge il tuo WiFi. Un briefing informativo di Purple Enterprise WiFi. Benvenuto. Se ti occupi della sicurezza di rete per un gruppo alberghiero, un patrimonio retail, uno stadio o un'organizzazione del settore pubblico, questo briefing fa al caso tuo. Nei prossimi dieci minuti parleremo dell'autenticazione PEAP: cos'è in realtà, come funziona dietro le quinte, come si inserisce nella tua architettura di sicurezza e, soprattutto, quando rappresenta la scelta giusta e quando invece dovresti considerare soluzioni più solide. Entriamo nel vivo. Sezione uno: Contesto e perché questo è importante proprio ora. La maggior parte delle implementazioni WiFi aziendali oggi si affida ancora a uno dei due modelli di autenticazione. O si dispone di una chiave pre-condivisa (una singola password condivisa in tutta l'organizzazione) o si utilizza lo standard 802.1X, che è lo standard IEEE per il controllo dell'accesso alla rete basato su porta. Il PEAP si colloca saldamente nel campo dell'802.1X ed è di gran lunga il metodo EAP più diffuso negli ambienti aziendali e istituzionali a livello globale. Il motivo per cui il PEAP è diventato così dominante è semplice: ha risolto un problema operativo reale. Prima del PEAP, implementare l'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 problema di implementazione PKI per il quale la maggior parte dei team IT semplicemente non aveva né il budget né il tempo. Il PEAP ha offerto una via di mezzo: una solida autenticazione lato server tramite TLS, con credenziali nome utente e password lato client. Nessun certificato client richiesto. Questo compromesso ha reso il PEAP lo standard de facto per l'autenticazione WiFi aziendale negli anni 2000 e 2010, e rimane estremamente comune ancora oggi. Comprenderne l'architettura (e i 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 di questo scambio sono: il supplicant (il dispositivo client, che si tratti di un laptop, di uno smartphone o di un terminale IoT); l'authenticator (in genere 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 è l'attivazione del tunnel TLS. Quando il supplicant tenta di connettersi, l'authenticator non concede l'accesso immediatamente. Al contrario, avvia uno scambio EAP sulla rete locale: si tratta di EAPOL, ovvero EAP over LAN. L'authenticator inoltra la richiesta al server RADIUS, che presenta il proprio certificato TLS lato server al client. Il client convalida tale certificato confrontandolo con il proprio archivio di certificati attendibili. Se la convalida va a buon fine, viene stabilito un tunnel TLS tra il client e il server RADIUS. Questo tunnel è crittografato, in genere tramite TLS 1.2 o 1.3 nelle implementazioni moderne. La fase due è 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 rispetto al 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 attraverso l'autenticatore 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. Questa è la proposta di valore centrale di PEAP. Ora, dove fallisce PEAP-MSCHAPv2? Ci sono due problemi significativi che qualsiasi architetto 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ò configurare un access point fittizio, presentare un certificato fraudolento e intercettare l'handshake MSCHAPv2. Strumenti come hostapd-wpe hanno reso questo attacco estremamente 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 non è negoziabile in qualsiasi distribuzione seria. Secondo: MSCHAPv2 è un protocollo obsoleto con punti deboli noti. La ricerca del 2012 di Moxie Marlinspike ha dimostrato che le coppie challenge-response di MSCHAPv2 possono essere violate offline con una potenza di calcolo sufficiente. Se un utente malintenzionato cattura lo scambio di autenticazione interna — ad esempio attraverso l'attacco con l'access point fittizio descritto sopra — può tentare di recuperare la password in chiaro offline. La forza della tua policy sulle password influisce quindi direttamente sulla tua esposizione. Password lunghe, complesse e generate casualmente riducono significativamente questo rischio. Confronta questo scenario con EAP-TLS, in cui sia il server che il client presentano certificati. Non ci sono password da rubare. La superficie di attacco è drasticamente ridotta. Il compromesso è la complessità operativa: hai bisogno di una PKI, devi emettere e gestire i certificati client e hai bisogno di un meccanismo per distribuirli a ogni dispositivo. Per le organizzazioni con una distribuzione MDM matura e una PKI ben gestita, EAP-TLS rappresenta lo standard di riferimento. Per tutti gli altri, PEAP-MSCHAPv2 con una configurazione rigorosa rimane una scelta difendibile e pratica. Sezione tre: Raccomandazioni per l'implementazione e insidie. Permettetemi di fornirvi una guida pratica alla distribuzione. Questi sono gli elementi che distinguono una distribuzione PEAP sicura da una vulnerabile. Numero uno: applica 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 agli attacchi di rogue AP, indipendentemente da quanto sia configurato bene tutto il resto. Numero due: distribuisci tramite MDM o GPO, non tramite configurazione manuale. La configurazione manuale da parte degli utenti finali non è affidabile. Gli utenti faranno clic per superare gli avvisi sui certificati. Configureranno in modo errato il campo CA. Invia i tuoi profili wireless tramite Microsoft Intune, Jamf o Criteri di gruppo. Ciò garantisce una configurazione del supplicant coerente e conforme alle policy in tutta la tua infrastruttura. Numero tre: utilizza TLS 1.2 come minimo sul tuo server RADIUS. Disabilita TLS 1.0 e 1.1. La maggior parte delle moderne implementazioni RADIUS supporta questo standard, ma vale la pena verificarlo, in particolare sulle distribuzioni on-premise più datate. Numero quattro: integrati con il tuo provider di identità. PEAP-MSCHAPv2 esegue l'autenticazione rispetto a un archivio di credenziali. Tale archivio dovrebbe essere il tuo provider di identità autorevole: Active Directory, Azure AD tramite estensione NPS o un servizio RADIUS cloud con integrazione LDAP. Ciò significa che quando un dipendente se ne va, la disattivazione del suo account revoca immediatamente il suo accesso WiFi. Nessun segreto condiviso da ruotare, nessun deprovisioning manuale. Numero cinque: considera la tua rete ospiti separatamente. PEAP è un metodo di autenticazione aziendale. Per il WiFi ospiti, dove stai registrando visitatori, clienti o partecipanti a eventi, hai bisogno di un approccio diverso. Piattaforme come Purple forniscono un livello WiFi ospiti appositamente progettato che gestisce l'autenticazione tramite Captive Portal, l'acquisizione dei dati e l'analisi senza richiedere un'infrastruttura RADIUS sull'SSID ospite. Mantieni il tuo SSID aziendale su 802.1X con PEAP e il tuo SSID ospite su una rete separata e isolata con un onboarding appropriato. Numero sei: pianifica la rotazione dei certificati. Il certificato del tuo server RADIUS scadrà. Quando ciò accadrà, ogni client che ha bloccato quel certificato non riuscirà a autenticarsi finché 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 casi di errore più comuni che riscontro sul campo sono: convalida del certificato non applicata, con conseguente 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 eseguire il proxy dell'autenticazione PEAP tramite Azure AD, abilitando l'autenticazione a più fattori sul 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 garantire che la convalida del certificato del server sia applicata, che sia in uso TLS 1.2 o superiore e che il server RADIUS sia adeguatamente segmentato. Lo standard 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 è 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 stesso. Sezione cinque: Riepilogo e passaggi successivi. Per riassumere: PEAP è un protocollo di autenticazione a due fasi che racchiude le credenziali interne — tipicamente 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 AP non autorizzati (rogue AP), resi possibili da supplicant configurati in modo errato che non convalidano il certificato del server. Mitiga questo rischio tramite profili wireless imposti da MDM, pinning della CA e convalida del nome del server. Per la maggior parte delle distribuzioni WiFi aziendali — uffici aziendali, reti back-of-house di hotel, reti del personale di vendita al dettaglio — PEAP-MSCHAPv2 con una corretta configurazione è 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 accade nella maggior parte dei casi — ricorda che PEAP non è lo strumento giusto per l'onboarding degli ospiti. Prendi in considerazione piattaforme come Purple, che forniscono un'autenticazione WiFi per gli ospiti creata appositamente con analisi, 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 sono nelle note dell'episodio. Grazie per l'ascolto. Questo è stato un Purple Enterprise WiFi Intelligence Briefing.