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

¿Qué es la autenticación PEAP? Cómo asegura PEAP su WiFi. Un informe de inteligencia de Purple Enterprise WiFi. Bienvenido. Si es responsable de la seguridad de la red en un grupo hotelero, un complejo comercial, un estadio o una organización del sector público, este informe es para usted. En los próximos diez minutos, cubriremos la autenticación PEAP: qué es en realidad, cómo funciona internamente, dónde encaja en su arquitectura de seguridad y, de manera crucial, cuándo es la opción correcta frente a cuándo debería buscar algo más sólido. Entremos en materia. Sección uno: Contexto y por qué esto es importante ahora mismo. La mayoría de las implementaciones de WiFi empresarial actuales todavía dependen de uno de dos modelos de autenticación. O bien dispone de una clave previamente compartida - una única contraseña compartida en toda la organización - o bien dispone de 802.1X, que es el estándar IEEE para el control de acceso a redes basado en puertos. PEAP se sitúa firmemente en el bando de 802.1X, y es, con diferencia, 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 ordenador portátil, cada teléfono, cada tableta. Para una organización con quinientos empleados y una política 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 ni el presupuesto ni el 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 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: Análisis técnico detallado. Repasemos 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 un ordenador portátil, un smartphone o un terminal IoT; el autenticador - que suele ser el punto de acceso inalámbrico o el controlador de red LAN inalámbrica; y el servidor de autenticación - que casi siempre es un servidor RADIUS, como Microsoft NPS, FreeRADIUS o un servicio RADIUS 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 contra 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 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 frente a su almacén de identidades, que podría ser Active Directory, LDAP o un proveedor de identidades 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 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? Existen dos problemas significativos 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 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 no es negociable en ninguna 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 pueden descifrarse sin conexión 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 sin conexión. 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 las organizaciones con una implementación madura de MDM 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 implementación. Estos son los aspectos que diferencian una implementación segura de PEAP de una 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 de certificado de CA en la configuración de EAP. Si esto no está configurado, su implementación de PEAP es vulnerable a ataques de puntos de acceso no autorizados, independientemente de lo bien que 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 fiable. Los usuarios harán clic para ignorar las advertencias de certificados. Configurarán mal el campo CA. Envíe sus perfiles inalámbricos a través de Microsoft Intune, Jamf o directivas de grupo. Esto garantiza una configuración del suplicante coherente y conforme a las directivas en todo su parque informático. 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 RADIUS modernas lo admiten, 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, al desactivar su cuenta se 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 está incorporando a visitantes, clientes o asistentes a eventos - necesita un enfoque diferente. Las plataformas como Purple proporcionan una capa de WiFi de invitados diseñada específicamente que gestiona 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 y aislada con la incorporación adecuada. Número seis: planifique la rotación de certificados. El certificado de su servidor RADIUS caducará. Cuando lo haga, todos los clientes que hayan anclado 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 caducidad - y pruebe el proceso de rotación en un entorno de pruebas antes de implementarlo en producción. Los fallos más comunes que veo en el sector son: no exigir la validación de certificados, lo que genera vulnerabilidad a puntos de acceso no autorizados; certificados de servidor RADIUS que caducan sin previo aviso, lo que provoca 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 funcionar PEAP 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, habilitando 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 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 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 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é ocurre con WPA3-Enterprise? WPA3-Enterprise exige el modo de seguridad de 192 bits para entornos de alta seguridad, pero sigue siendo compatible con los métodos EAP, incluido PEAP. WPA3 mejora el cifrado en el aire pero no cambia el propio intercambio de autenticación EAP. Sección cinco: Resumen y siguientes pasos. Para resumir: 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 implantado 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, la vinculación de CA y la validación del nombre del servidor. Para la mayoría de los despliegues de WiFi empresarial - oficinas corporativas, redes de trastienda de hoteles, redes de personal de tiendas minoristas - PEAP-MSCHAPv2 con una 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 mayor y debería ser la arquitectura de destino. Si además de su red empresarial dispone de una red WiFi para invitados - como la mayoría de ustedes - recuerde que PEAP no es la herramienta adecuada para la incorporación de invitados. Busque plataformas como Purple, que proporcionan una autenticación de WiFi para invitados diseñada a medida con análisis, captura de datos e integración de marketing, manteniendo el tráfico de sus invitados y el de la empresa debidamente separados y su nivel de cumplimiento intacto. Para seguir leyendo, consulte las guías de Purple sobre arquitectura de servidores RADIUS y autenticación WiFi para empresas. Los enlaces están en las notas del programa. Gracias por escucharnos. Esto ha sido un Informe de Inteligencia de WiFi Empresarial de Purple.