¿Qué es la autenticación PEAP? Cómo PEAP asegura su WiFi

¿Qué es la autenticación PEAP? Cómo PEAP protege su WiFi. Un informe de inteligencia de Purple Enterprise WiFi. Bienvenido. Si usted es responsable de la seguridad de la red en un grupo hotelero, un desarrollo de retail, un estadio o una organización del sector público, este informe es para usted. Durante los próximos diez minutos, cubriremos la autenticación PEAP: qué es realmente, cómo funciona internamente, dónde encaja en su arquitectura de seguridad y, fundamentalmente, cuándo es la decisión correcta frente a cuándo debería buscar algo más robusto. Comencemos. Sección uno: Contexto y por qué esto importa en este momento. La mayoría de las implementaciones de WiFi empresarial hoy en día todavía dependen de uno de dos modelos de autenticación. O bien tiene una clave precompartida (una única contraseña compartida en toda la organización) o tiene 802.1X, que es el estándar de IEEE para el control de acceso a la red basado en puertos. PEAP se sitúa firmemente en el campo de 802.1X, y es por mucho el método EAP más implementado en entornos corporativos e institucionales a nivel mundial. La razón por la que PEAP se volvió tan dominante es sencilla: resolvió un problema operativo real. Antes de PEAP, implementar la autenticación WiFi basada en certificados significaba emitir certificados de cliente para cada dispositivo: cada laptop, cada teléfono, cada tableta. Para una organización con quinientos empleados y una política de BYOD, eso representa un dolor de cabeza de implementación de PKI para el que la mayoría de los equipos de TI simplemente no tenían el presupuesto o el tiempo necesario. PEAP ofreció un camino intermedio: una autenticación sólida del lado del servidor a través de TLS, con credenciales de usuario y contraseña del lado del cliente. Sin necesidad de certificados de cliente. Ese compromiso convirtió a PEAP en el estándar de facto para la autenticación WiFi empresarial durante las décadas de 2000 y 2010, y sigue siendo extremadamente común hoy en día. Comprender su arquitectura - y sus limitaciones - es esencial para cualquiera que tome decisiones de infraestructura en 2024 y más allá. Sección dos: Inmersión técnica profunda. Analicemos exactamente qué sucede cuando un dispositivo se autentica a través de PEAP. El proceso tiene dos fases distintas, y comprender ambas es fundamental. Los tres actores en este intercambio son: el suplicante (que es el dispositivo cliente, ya sea una laptop, un smartphone o una terminal IoT); el autenticador (que suele ser el punto de acceso inalámbrico o el controlador de LAN inalámbrica); y el servidor de autenticación (que casi siempre es un servidor RADIUS, como Microsoft NPS, FreeRADIUS o un servicio RADIUS alojado en la nube). La fase uno es el establecimiento del túnel TLS. Cuando el suplicante intenta conectarse, el autenticador no otorga el acceso de inmediato. En su lugar, inicia un intercambio EAP a través de la red local (esto es EAPOL, EAP sobre LAN). El autenticador reenvía esto al servidor RADIUS, el cual presenta su certificado TLS del lado del servidor al cliente. El cliente valida ese certificado contra su almacén de certificados de confianza. Si la validación es exitosa, se establece un túnel TLS entre el cliente y el servidor RADIUS. Este túnel está cifrado (normalmente TLS 1.2 o 1.3 en implementaciones modernas).La fase dos es la autenticación interna. Dentro de ese túnel cifrado, se intercambian las credenciales reales. En la implementación más común - PEAP-MSCHAPv2 - el cliente envía un nombre de usuario y una contraseña utilizando el protocolo Microsoft Challenge Handshake Authentication Protocol versión 2. El servidor RADIUS valida esas credenciales con su almacén de identidades, que podría ser Active Directory, LDAP o un proveedor de identidad en la nube. Si las credenciales son válidas, el servidor RADIUS envía un mensaje de Access-Accept de vuelta a través del autenticador y se le concede al cliente el acceso a la red. La propiedad de seguridad clave aquí es que el intercambio MSCHAPv2 ocurre dentro del túnel TLS. Un atacante que monitoree pasivamente el canal inalámbrico no puede ver las credenciales en tránsito. Esa es la propuesta de valor principal de PEAP. Ahora bien, ¿dónde se queda corto PEAP-MSCHAPv2? Existen dos problemas significativos que cualquier arquitecto preocupado por la seguridad necesita entender. Primero: la validación del certificado del servidor. PEAP solo requiere que el servidor presente un certificado - no requiere que el cliente presente uno. Esto crea un vector de ataque ampliamente documentado. Si un dispositivo cliente está mal configurado para aceptar cualquier certificado - o para aceptar certificados de cualquier CA - un atacante puede montar un punto de acceso falso, presentar un certificado fraudulento e interceptar el saludo MSCHAPv2. Herramientas como hostapd-wpe han hecho que este ataque sea sumamente accesible. La mitigación consiste en una configuración rigurosa del suplicante: aplicar la validación del certificado del servidor, vincular la CA esperada y especificar el nombre común del servidor. Esto es innegociable en cualquier implementación seria. Segundo: MSCHAPv2 es un protocolo antiguo con debilidades conocidas. La investigación de 2012 de Moxie Marlinspike demostró que los pares de desafío-respuesta de MSCHAPv2 se pueden descifrar fuera de línea con suficiente capacidad de cómputo. Si un atacante logra capturar el intercambio de autenticación interna - por ejemplo, a través del ataque de punto de acceso falso descrito anteriormente - puede intentar recuperar la contraseña en texto plano fuera de línea. Por lo tanto, la solidez de su política de contraseñas afecta directamente a su exposición. Las contraseñas largas, complejas y generadas aleatoriamente reducen significativamente este riesgo. Compare esto con EAP-TLS, donde tanto el servidor como el cliente presentan certificados. No hay contraseñas que robar. La superficie de ataque se reduce drásticamente. La contrapartida es la complejidad operativa: necesita una PKI, necesita emitir y administrar certificados de cliente, y necesita un mecanismo para distribuirlos a cada dispositivo. Para las organizaciones con una implementación de MDM madura y una PKI bien administrada, EAP-TLS es el estándar de oro. Para todos los demás, PEAP-MSCHAPv2 con una configuración rigurosa sigue siendo una opción defendible y práctica. Sección tres: Recomendaciones de implementación y errores comunes. Permítame ofrecerle una guía práctica de implementación. Estos son los aspectos que diferencian una implementación segura de PEAP de una vulnerable. Número uno: aplique la validación del certificado del servidor en cada suplicante. Este es el elemento de configuración más importante. En Windows, esta es la casilla de verificación "Validar certificado de servidor" en el perfil de red inalámbrica. En iOS y Android, es el campo de certificado CA en la configuración EAP. Si esto no está configurado, su implementación PEAP es vulnerable a ataques de AP falsos, sin importar qué tan bien esté configurado todo lo demás. Número dos: implemente mediante MDM o GPO, no mediante configuración manual. La configuración manual por parte de los usuarios finales no es confiable. Los usuarios harán clic para omitir las advertencias de certificados. Configurarán de forma incorrecta el campo CA. Envíe sus perfiles inalámbricos a través de Microsoft Intune, Jamf o políticas de grupo. Esto garantiza una configuración del suplicante consistente y que cumpla con las políticas en todo su entorno. Número tres: use TLS 1.2 como mínimo en su servidor RADIUS. Desactive TLS 1.0 y 1.1. La mayoría de las implementaciones modernas de RADIUS admiten esto, pero vale la pena verificarlo - especialmente en implementaciones locales más antiguas. Número cuatro: intégrelo con su proveedor de identidad. PEAP-MSCHAPv2 se autentica contra un almacén de credenciales. Ese almacén debe ser su proveedor de identidad autorizado - Active Directory, Azure AD a través de la extensión NPS, o un servicio RADIUS en la nube con integración LDAP. Esto significa que cuando un empleado se va, la desactivación de su cuenta revoca inmediatamente su acceso a la WiFi. Sin secretos compartidos que rotar, sin desaprovisionamiento manual. Número cinco: considere su red de invitados por separado. PEAP es un método de autenticación empresarial. Para la WiFi de invitados - donde se da de alta a visitantes, clientes o asistentes a eventos - se necesita un enfoque diferente. Las plataformas como Purple proporcionan una capa de WiFi de invitados diseñada específicamente que maneja la autenticación del Captive Portal, la captura de datos y el análisis sin requerir una infraestructura RADIUS en el SSID de invitados. Mantenga su SSID empresarial en 802.1X con PEAP, y su SSID de invitados en una red separada e aislada con el proceso de registro adecuado. Número seis: planifique la rotación de certificados. El certificado de su servidor RADIUS caducará. Cuando lo haga, cada cliente que haya fijado ese certificado no podrá autenticarse hasta que se distribuya el nuevo certificado. Integre la renovación de certificados en su calendario operativo - al menos 90 días antes del vencimiento - y pruebe el proceso de rotación en un entorno de pruebas antes de implementarlo en producción. Los modos de falla más comunes que veo en el campo son: la validación del certificado no aplicada, lo que genera vulnerabilidad a AP falsos; certificados del servidor RADIUS que vencen sin previo aviso, causando fallas generalizadas de autenticación; y la autenticación interna MSCHAPv2 expuesta porque el servidor RADIUS es accesible desde el segmento de red incorrecto. Los tres son evitables con una planificación adecuada. Sección cuatro: Preguntas rápidas. ¿Puede PEAP funcionar con proveedores de identidad en la nube como Azure AD? Sí. La extensión NPS de Microsoft para Azure AD MFA le permite realizar un proxy de la autenticación PEAP a través de Azure AD, lo que habilita la autenticación multifactor en su WiFi. Alternativamente, los servicios de RADIUS en la nube como Cisco ISE, Aruba ClearPass o JumpCloud RADIUS pueden integrarse directamente con Azure AD u Okta. ¿Cumple PEAP con PCI-DSS? PEAP-MSCHAPv2 se puede utilizar en entornos PCI-DSS, pero debe asegurarse de que se aplique la validación del certificado del servidor, de que se utilice TLS 1.2 o superior y de que el servidor RADIUS esté correctamente segmentado. PCI-DSS 4.0 endurece los requisitos en torno a los controles de acceso a la red - revise los requisitos pertinentes con su QSA. ¿Debería migrar de PEAP a EAP-TLS? Si tiene una implementación de MDM madura y la capacidad operativa para administrar una PKI, sí - EAP-TLS es la opción más sólida. Si administra un entorno mixto con dispositivos personales, hardware heredado o cobertura de MDM limitada, PEAP-MSCHAPv2 con una configuración rigurosa sigue siendo adecuado. Esta es una decisión basada en el riesgo, no una opción binaria. ¿Qué pasa con WPA3-Enterprise? WPA3-Enterprise exige el modo de seguridad de 192 bits para entornos de alta seguridad, pero sigue admitiendo métodos EAP, incluido PEAP. WPA3 mejora el cifrado inalámbrico, pero no cambia el intercambio de autenticación EAP en sí. Sección cinco: Resumen y próximos pasos. En resumen: PEAP es un protocolo de autenticación de dos fases que envuelve las credenciales internas - normalmente MSCHAPv2 - dentro de un túnel TLS. Es el método 802.1X EAP más implementado porque elimina la necesidad de certificados de cliente sin dejar de proporcionar una sólida autenticación de servidor. Su principal vulnerabilidad son los ataques de AP no autorizados (rogue AP) permitidos por suplicantes mal configurados que no validan el certificado del servidor. Mitigue esto mediante perfiles inalámbricos aplicados por MDM, el anclaje de CA y la validación del nombre del servidor. Para la mayoría de las implementaciones de WiFi empresarial - oficinas corporativas, redes internas de hoteles, redes de personal de retail - PEAP-MSCHAPv2 con una configuración adecuada es una opción sólida y defendible. Para entornos de alta seguridad, industrias reguladas u organizaciones con una infraestructura PKI madura, EAP-TLS proporciona una seguridad significativamente más sólida y debería ser la arquitectura objetivo. Si también tiene una red WiFi para invitados junto a su red empresarial - y la mayoría de ustedes la tiene - recuerde que PEAP no es la herramienta adecuada para el registro de invitados. Conozca plataformas como Purple, que proporcionan autenticación de WiFi para invitados diseñada a la medida con analíticas, captura de datos e integración de marketing, manteniendo el tráfico de sus invitados y de la empresa correctamente separados y su postura de cumplimiento intacta. Para profundizar en el tema, consulte las guías de Purple sobre arquitectura de servidores RADIUS y autenticación WiFi empresarial. Los enlaces están en las notas del programa. Gracias por escuchar. Este ha sido un informe de inteligencia sobre WiFi empresarial de Purple.