¿Qué es un suplicante 802.1X? Tipos de clientes y configuración de dispositivos

Hable en inglés británico con un tono seguro, autoritario y conversacional, como un consultor sénior de seguridad de redes informando a un cliente. Ritmo pausado, dicción clara, profesional pero no rígido. Pausas naturales ocasionales para enfatizar: Bienvenido a la serie de sesiones informativas técnicas de Purple. Hoy trataremos algo que se encuentra en el centro de la seguridad de la red WiFi empresarial: el suplicante 802.1X. Si alguna vez se ha preguntado por qué algunos dispositivos se conectan a su red corporativa sin solicitar contraseña, mientras que otros lanzan errores de certificado y tickets de soporte, este es el episodio para usted. [pausa media] Empecemos por lo básico. El suplicante 802.1X es el componente de software de un dispositivo cliente (un ordenador portátil, un smartphone, una tableta) que gestiona el saludo de autenticación cuando ese dispositivo intenta unirse a una red protegida por IEEE 802.1X. Piense en él como el presentador de la tarjeta de identificación del dispositivo. La red no deja entrar a cualquiera. Pide credenciales. El suplicante es el que da un paso al frente y dice: aquí está quién soy, aquí está mi certificado, déjame entrar. El propio estándar - IEEE 802.1X - define el control de acceso a la red basado en puertos. Antes de que la autenticación se realice correctamente, el punto de acceso o switch solo permite el paso de un tipo muy específico de tráfico: tramas EAPOL, que significa Protocolo de Autenticación Extensible sobre LAN. Todo lo demás está bloqueado. Una vez que el suplicante demuestra su identidad al servidor RADIUS a través del autenticador, el puerto se abre y el tráfico normal fluye. [pausa media] Ahora bien, hay tres actores en esta obra. Primero, el suplicante: el dispositivo cliente. Segundo, el autenticador: su punto de acceso o switch, hardware como Cisco Meraki, HPE Aruba, Ruckus o Juniper Mist. Tercero, el servidor de autenticación: casi siempre un servidor RADIUS, que valida las credenciales contra un directorio como Microsoft Entra ID u Okta. El suplicante inicia el proceso enviando un mensaje EAPOL-Start. El autenticador responde con una solicitud EAP-Request de identidad. El suplicante responde con su identidad. Esa identidad se reenvía al servidor RADIUS, que luego desafía al suplicante con el método EAP acordado. Si todo es correcto, el servidor RADIUS envía un Access-Accept, el puerto se abre y el dispositivo se ubica en la VLAN correspondiente. [pausa media] Hablemos de los métodos EAP, porque aquí es donde se toman la mayoría de las decisiones de implementación. EAP-TLS - que es el Protocolo de Autenticación Extensible con Seguridad en la Capa de Transporte - es el estándar de oro. Requiere que tanto el cliente como el servidor presenten certificados. Autenticación mutua. Sin contraseñas. El certificado de cliente demuestra la identidad del dispositivo; el certificado del servidor demuestra que la red es legítima, lo que protege contra ataques de "evil twin" en los que un punto de acceso no autorizado intenta recopilar credenciales. EAP-TLS se completa en doce pasos y utiliza criptografía de clave pública-privada en todo el proceso. Es el método requerido para WPA3-Enterprise en su modo de seguridad más alto y se alinea con los requisitos de NIST SP 800-171 para la verificación de identidad de dispositivos. PEAP - EAP protegido - es el punto de partida más común para las organizaciones que aún no disponen de una PKI completa. PEAP envuelve un método interno basado en contraseña, normalmente MSCHAPv2, dentro de un túnel TLS. El servidor presenta un certificado; el cliente no. Esto significa que la implantación es más sencilla - no es necesario suministrar certificados de cliente - pero es menos segura. MSCHAPv2 utiliza el cifrado MD4, que se considera comprometido desde 1995. Si un usuario se conecta a un punto de acceso no autorizado que presenta un certificado que parece de confianza, se pueden capturar sus credenciales. Por lo tanto, la validación del certificado del servidor en el lado del cliente no es negociable cuando se ejecuta PEAP. [medium pause] Ahora entremos en el suplicante en sí, concretamente en la elección entre los suplicantes nativos del sistema operativo y el software de cliente de terceros. Todos los sistemas operativos principales incluyen un suplicante 802.1X integrado. Windows lo admite de forma nativa desde XP, a través de los servicios de Configuración automática de redes cableadas e inalámbricas. macOS e iOS gestionan 802.1X a través de sus perfiles de configuración de red. Android lo admite a través del panel de ajustes de WiFi. Estos suplicantes nativos cubren EAP-TLS y PEAP-MSCHAPv2 en todas las plataformas actuales. La ventaja de los suplicantes nativos es obvia: no hay software adicional que implementar, no hay costes de licencia, se dispone de actualizaciones de seguridad automáticas del sistema operativo y ofrece una estrecha integración con el almacén de certificados del sistema operativo. Para flotas de dispositivos gestionados - equipos Windows registrados en Microsoft Intune o Macs gestionados a través de Jamf - se pueden enviar perfiles de configuración 802.1X de forma silenciosa a través de MDM, y los usuarios nunca verán ningún aviso. El dispositivo se autentica automáticamente cada vez que entra dentro del alcance. Los suplicantes de terceros entran en juego en escenarios específicos. Si tiene una infraestructura Cisco y desea utilizar EAP-FAST (el método EAP patentado de Cisco), necesitará el software de cliente de Cisco, históricamente el Secure Services Client o AnyConnect Network Access Manager. Si necesita una gestión de configuración coherente en un parque de sistemas operativos mixtos y desea bloquear los ajustes del suplicante para que los usuarios no puedan desconfigurarlos accidentalmente, un cliente de terceros le ofrece ese control. Las herramientas como la suite JoinNow de SecureW2 también actúan como agentes de incorporación: configuran el suplicante nativo en lugar de reemplazarlo, guiando a los usuarios a través del registro de certificados y la instalación de perfiles. [medium pause] Permítame guiarle a través de dos escenarios del mundo real para que esto sea más concreto. Primero, un hotel de 400 habitaciones. El establecimiento gestiona hoy una red para el personal en WPA2-Enterprise con PEAP-MSCHAPv2. El equipo de TI quiere migrar a EAP-TLS para eliminar la autenticación basada en contraseñas y reducir el riesgo de robo de credenciales. El desafío: los dispositivos del personal son una mezcla de portátiles Windows gestionados a través de Intune, teléfonos Android personales utilizados para el software de gestión del establecimiento y un puñado de equipos heredados con Windows 7 en las oficinas internas. El enfoque aquí es gradual. Comience con la flota administrada de Windows. Implemente un perfil de configuración de Intune que instale el certificado CA raíz del servidor RADIUS, configure el perfil de WiFi para EAP-TLS e inicie el registro de certificados basado en SCEP desde la PKI interna. Esos dispositivos se autentican automáticamente desde el primer día. Para los dispositivos BYOD de Android, implemente un portal de incorporación de autoservicio: los usuarios visitan una URL, descargan un perfil de configuración y el suplicante se configura para ellos. Las máquinas heredadas con Windows 7 se mantienen en PEAP con una validación estricta del certificado del servidor aplicada, aisladas en una VLAN independiente con acceso limitado, hasta que se retiren de servicio. [medium pause] Segundo escenario: una gran cadena de tiendas con 200 establecimientos. Cada tienda tiene una combinación de terminales de punto de venta, tabletas para el personal y una red WiFi para invitados. La normativa PCI-DSS requiere que los entornos de datos de titulares de tarjetas estén aislados de otros segmentos de la red. El minorista utiliza 802.1X en las redes de personal y POS, con asignación de VLAN impulsada por atributos de certificado. Un terminal POS presenta un certificado de dispositivo con una unidad organizativa de "POS": la política RADIUS lo asigna a la VLAN de PCI. Una tableta del personal presenta un certificado con "Staff" y aterriza en la VLAN del personal. Los dispositivos de los invitados se conectan a un SSID totalmente independiente, gestionado por una solución de Captive Portal. La configuración del suplicante en los terminales POS está bloqueada mediante MDM. No se requiere interacción del usuario. Los terminales se autentican de forma silenciosa al arrancar. La renovación de certificados se automatiza a través de SCEP, por lo que no hay intervención manual cuando expiran los certificados. [medium pause] Ahora, errores de implementación. Permítame presentarle los cuatro más comunes. Número uno: la falta de validación del certificado del servidor en despliegues PEAP. Si no se configura el suplicante para validar el certificado del servidor RADIUS y comprobar el nombre del servidor, los usuarios quedan expuestos a conectarse a un punto de acceso no autorizado. Especifique siempre la CA raíz de confianza y el nombre del servidor en el perfil del suplicante. Número dos: la caducidad de los certificados que causa fallos masivos de autenticación. Los certificados de cliente tienen un periodo de validez. Si no dispone de una renovación automatizada a través de SCEP o NDES, se enfrentará a un problema crítico en el que cientos de dispositivos dejarán de autenticarse simultáneamente. Desarrolle la automatización de la renovación antes de la puesta en marcha. Número tres: dispositivos BYOD con un comportamiento del suplicante inconsistente. Android, en particular, tiene un soporte 802.1X fragmentado entre los distintos fabricantes. Algunas versiones requieren que el usuario instale manualmente el certificado de la CA antes de que el perfil de WiFi lo acepte. Un portal de incorporación que gestione este paso reduce significativamente el volumen de consultas al servicio de soporte. Número cuatro: las actualizaciones de funciones de Windows 11 que alteran la configuración del suplicante. Microsoft ha cambiado el comportamiento de 802.1X en varias actualizaciones de Windows 11. En concreto, la actualización 24H2 introdujo cambios en la forma en que el suplicante nativo gestiona la caída a EAP-TLS. Pruebe los perfiles de su suplicante con las nuevas versiones del sistema operativo antes de distribuirlos en producción. [pausa media] Preguntas rápidas ahora. ¿Pueden los dispositivos IoT soportar 802.1X? La mayoría no. Por lo general, los dispositivos IoT carecen por completo de un suplicante. La alternativa es MAC Authentication Bypass - MAB - donde el servidor RADIUS autentica el dispositivo basándose en su dirección MAC. Las direcciones MAC se pueden suplantar, por lo que los dispositivos MAB siempre deben acabar en una VLAN de IoT aislada con reglas de firewall estrictas. ¿Necesito una PKI para ejecutar 802.1X? Para PEAP, no; solo necesita un certificado de servidor en el servidor RADIUS. Para EAP-TLS, sí; necesita una PKI para emitir certificados de cliente. Los servicios de PKI basados en la nube reducen considerablemente los costes de infraestructura. ¿Cómo interactúa 802.1X con la plataforma de acceso a la red de Purple? Purple funciona como una capa de nube sobre su hardware existente: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist y otros. En las redes WiFi para empleados, el complemento SecurePass de Purple se integra con su proveedor de identidad - Microsoft Entra ID, Okta o Google Workspace - para aplicar la autenticación 802.1X y las políticas de VLAN por usuario sin necesidad de una infraestructura RADIUS local. [pausa media] Para resumir: el suplicante 802.1X es el agente del lado del dispositivo que hace que funcione el control de acceso a la red basado en puertos. La elección del método EAP - EAP-TLS para una seguridad máxima, PEAP como opción de transición - determina los requisitos de su PKI y el enfoque de configuración del suplicante. Los suplicantes nativos del sistema operativo cubren la mayoría de los escenarios de dispositivos gestionados cuando se despliegan a través de MDM. Los clientes de terceros aportan valor en casos específicos: métodos EAP propietarios, entornos con sistemas operativos mixtos que requieren una configuración coherente o incorporación de BYOD en modo de autoservicio. Las tres ideas clave que debe recordar: valide el certificado de su servidor RADIUS en cada perfil de suplicante, automatice la renovación de certificados antes de implementar EAP-TLS a gran escala e aísle los dispositivos que no admiten 802.1X - IoT, hardware heredado - en VLANs dedicadas con MAC Authentication Bypass como alternativa de respaldo. Para obtener más información sobre cómo se integra Purple con su arquitectura de acceso a la red, visite purple dot ai. Gracias por escucharnos.