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

¿Qué es la autenticación PEAP? Cómo asegura PEAP su WiFi. Un informe de inteligencia de WiFi empresarial de Purple. Bienvenido. Si es responsable de la seguridad de la red en un grupo hotelero, una cadena de tiendas, un estadio o una organización del sector público, este informe es para usted. Durante los próximos diez minutos, analizaremos la autenticación PEAP: qué es realmente, cómo funciona internamente, dónde encaja en su arquitectura de seguridad y, lo que es más importante, cuándo es la opción adecuada frente a cuándo debería buscar algo más robusto. Comencemos. Sección uno: Contexto y por qué esto es importante ahora mismo. La mayoría de los despliegues de WiFi empresariales actuales siguen basándose en uno de dos modelos de autenticación. O bien se dispone de una clave precompartida (una única contraseña compartida en toda la organización) o bien se cuenta con 802.1X, que es el estándar 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, con diferencia, el método EAP más desplegado en entornos corporativos e institucionales de todo el mundo. La razón por la que PEAP se volvió tan dominante es sencilla: resolvió un problema operativo real. Antes de PEAP, desplegar una autenticación WiFi basada en certificados significaba emitir certificados de cliente para cada dispositivo: cada portátil, cada teléfono, cada tableta. Para una organización con quinientos empleados y una política BYOD, eso supone un dolor de cabeza en el despliegue de PKI para el que la mayoría de los equipos de TI simplemente no tenían presupuesto ni tiempo. PEAP ofreció un camino intermedio: una sólida autenticación del lado del servidor a través de TLS, con credenciales de usuario y contraseña en el lado del cliente. Sin necesidad de certificados de cliente. Ese equilibrio 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 en adelante. Sección dos: Análisis técnico detallado. Veamos exactamente qué sucede cuando un dispositivo se autentica a través de PEAP. El proceso consta de dos fases distintas, y comprender ambas es fundamental. Los tres actores en este intercambio son: el suplicante (que es el dispositivo cliente, ya sea un portátil, un smartphone o un terminal IoT); el autenticador (normalmente el punto de acceso inalámbrico o el controlador de LAN inalámbrica); y el servidor de autenticación (casi siempre 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 concede 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, que presenta su certificado TLS del lado del servidor al cliente. El cliente valida ese certificado frente a su almacén de certificados de confianza. Si la validación tiene éxito, se establece un túnel TLS entre el cliente y el servidor RADIUS. Este túnel está cifrado, normalmente con TLS 1.2 o 1.3 en los despliegues modernos. La fase dos es la autenticación interna. Dentro de ese túnel cifrado, se intercambian las credenciales reales. En el despliegue más común (PEAP-MSCHAPv2), el cliente envía un nombre de usuario y una contraseña utilizando el Protocolo de autenticación por desafío mutuo de Microsoft versión 2. El servidor RADIUS valida esas credenciales frente a su almacén de identidad, que podría ser Active Directory, LDAP o un proveedor de identidad en la nube. Si las credenciales son correctas, 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 monitorice 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? Hay dos problemas importantes que cualquier arquitecto preocupado por la seguridad debe comprender. 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 bien 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 no autorizado, presentar un certificado fraudulento e interceptar el saludo MSCHAPv2. Herramientas como hostapd-wpe han hecho que este ataque sea extremadamente accesible. La mitigación consiste en una configuración rigurosa del suplicante: exigir la validación del certificado del servidor, vincular la CA esperada y especificar el nombre común (CN) del servidor. Esto no es negociable en ningún despliegue serio. 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 captura el intercambio de autenticación interna (por ejemplo, a través del ataque de AP no autorizado 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 gestionar certificados de cliente, y necesita un mecanismo para distribuirlos a cada dispositivo. Para organizaciones con un despliegue de MDM maduro y una PKI bien gestionada, 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 despliegue. Estos son los aspectos que diferencian un despliegue de PEAP seguro de uno vulnerable. Número uno: exija 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 del certificado de CA en la configuración de EAP. Si esto no está configurado, su despliegue de PEAP será vulnerable a ataques de AP no autorizados, independientemente de lo bien configurado que esté todo lo demás. Número dos: realice el despliegue a través de MDM o GPO, no mediante configuración manual. La configuración manual por parte de los usuarios finales no es fiable. Los usuarios harán clic para omitir las advertencias de certificado. Configurarán mal el campo de la CA. Envíe sus perfiles inalámbricos a través de Microsoft Intune, Jamf o directivas de grupo (GPO). Esto garantiza una configuración del suplicante coherente y conforme con las directivas en todo su parque de dispositivos. Número tres: utilice 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 lo admiten, pero vale la pena verificarlo, especialmente en despliegues locales más antiguos. 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 de referencia: 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 marcha, al desactivar su cuenta se revoca inmediatamente su acceso a la red 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 red WiFi de invitados (donde se incorpora a visitantes, clientes o asistentes a eventos), se necesita un enfoque diferente. Plataformas como Purple proporcionan una capa de WiFi de invitados diseñada específicamente para gestionar la autenticación de Captive Portal, la captura de datos y la analítica sin requerir 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 y aislada con el proceso de incorporación adecuado. Número seis: planifique la rotación de certificados. El certificado de su servidor RADIUS caducará. Cuando lo haga, todos los clientes que hayan vinculado ese certificado no podrán autenticarse hasta que se distribuya el nuevo certificado. Incorpore la renovación de certificados en su calendario operativo (al menos 90 días antes de la expiración) y pruebe el proceso de rotación en un entorno de pruebas antes de implementarlo en producción. Los modos de fallo más comunes que veo en el terreno son: la validación de certificados no obligatoria, lo que genera vulnerabilidad a AP no autorizados; certificados de servidor RADIUS que caducan sin previo aviso, causando fallos de autenticación generalizados; 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 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 exija 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 dispone de un despliegue de MDM maduro y la capacidad operativa para gestionar una PKI, sí: EAP-TLS es la opción más sólida. Si gestiona un parque 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 elecció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 en el aire, 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 EAP 802.1X más desplegado porque elimina la necesidad de certificados de cliente al tiempo que proporciona una sólida autenticación de servidor. Su principal vulnerabilidad son los ataques de AP no autorizados facilitados por suplicantes mal configurados que no validan el certificado del servidor. Mitigue esto mediante perfiles inalámbricos impuestos por MDM, vinculación de CA y validación del nombre del servidor. Para la mayoría de los despliegues de WiFi empresariales (oficinas corporativas, redes de personal interno de hoteles, redes de personal de tiendas), PEAP-MSCHAPv2 con la configuración adecuada es una opción sólida y defendible. Para entornos de alta seguridad, sectores regulados u organizaciones con una infraestructura PKI madura, EAP-TLS proporciona una seguridad significativamente más sólida y debería ser la arquitectura de destino. Si también ofrece WiFi de invitados junto con su red empresarial (como la mayoría de ustedes), recuerde que PEAP no es la herramienta adecuada para la incorporación de invitados. Considere plataformas como Purple, que proporcionan autenticación de WiFi de invitados diseñada específicamente con analítica, captura de datos e integración de marketing, manteniendo el tráfico de invitados y el empresarial 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 escucharnos. Este ha sido un informe de inteligencia de WiFi empresarial de Purple.