Cómo configurar la autenticación WiFi 802.1X: guía paso a paso

Cómo configurar la autenticación WiFi 802.1X: guía paso a paso Un podcast de Purple Enterprise WiFi Intelligence [INTRODUCCIÓN — aproximadamente 1 minuto] Bienvenidos de nuevo. Hoy les hablo como arquitecto de soluciones sénior, y si están escuchando esto, probablemente se enfrenten a un proyecto de seguridad de red que involucra la autenticación 802.1X, ya sea porque su equipo de cumplimiento normativo lo ha señalado, su aseguradora ha preguntado al respecto o simplemente acaban de heredar una red que funciona con una PSK compartida y saben que eso ya no es suficiente. Así que entremos en materia directamente. 802.1X es el estándar IEEE para el control de acceso a la red basado en puertos. Es la columna vertebral de la seguridad WiFi empresarial, el mecanismo que garantiza que cada dispositivo que se conecta a su red haya sido identificado y autorizado positivamente antes de que pase un solo byte de tráfico. Esto no es opcional para las organizaciones que manejan datos de tarjetas de pago bajo PCI DSS, no es opcional para los entornos sanitarios bajo GDPR y los estándares de seguridad de datos del NHS, y francamente, para cualquier organización que ejecute más de un puñado de puntos de acceso, es la arquitectura correcta. Durante los próximos diez minutos, los guiaré a través de la arquitectura técnica, la configuración de RADIUS, el despliegue de certificados y los escenarios del mundo real donde esto se complica. Vamos a ello. [INMERSIÓN TÉCNICA PROFUNDA — aproximadamente 5 minutos] Bien, el marco 802.1X tiene tres componentes. Tienen el suplicante: ese es el dispositivo cliente, el portátil, el teléfono, el sensor IoT. Tienen el autenticador: ese es su punto de acceso o su switch de red, a veces llamado NAS, el servidor de acceso a la red. Y tienen el servidor de autenticación, casi universalmente un servidor RADIUS en despliegues empresariales. Así es como funciona el saludo de conexión. Cuando un dispositivo intenta conectarse a un SSID protegido por 802.1X, el punto de acceso no se limita a dejarlo entrar. En su lugar, abre lo que se llama un puerto controlado, un canal limitado que solo pasa tráfico EAP, el protocolo de autenticación extensible. El AP envía un EAP-Request Identity al dispositivo. El dispositivo responde con su identidad. Luego, el AP reenvía eso al servidor RADIUS, envuelto en un paquete RADIUS Access-Request. El servidor RADIUS ejecuta la autenticación (comprobando las credenciales contra Active Directory, un almacén de certificados o cualquier backend de identidad que hayan configurado) y devuelve un Access-Accept o un Access-Reject. Solo con un Accept el AP abre el puerto de datos completo y asigna el dispositivo a la VLAN correspondiente. Ahora bien, el método EAP que elijan aquí importa enormemente. Hay cinco que encontrarán en los despliegues empresariales. EAP-TLS es el estándar de oro. Tanto el cliente como el servidor presentan certificados X.509. No hay contraseñas involucradas. Es la opción más segura y la requerida para los niveles de cumplimiento de PCI DSS más altos. El inconveniente es que necesitan una PKI completa (una infraestructura de clave pública) para emitir y gestionar certificados de cliente. Eso significa una autoridad de certificación, la gestión del ciclo de vida de los certificados y un mecanismo para enviar certificados a cada dispositivo. Para las organizaciones con Microsoft Active Directory y Active Directory Certificate Services, esto es muy viable. Para las organizaciones sin esa infraestructura, es una inversión significativa. PEAP-MSCHAPv2 es el método más implementado en la práctica. Crea un túnel TLS utilizando únicamente un certificado del lado del servidor, luego pasa las credenciales de usuario y contraseña dentro de ese túnel. Es compatible con prácticamente todos los dispositivos de forma nativa, se integra directamente con Active Directory a través de NPS en Windows Server y no requiere certificados de cliente. La contrapartida es que es vulnerable a ataques de recopilación de credenciales si se engaña a los usuarios para que se conecten a un AP no autorizado, porque el cliente no valida el certificado del servidor de forma predeterminada. Deben aplicar la validación del certificado del servidor en sus perfiles de suplicante. EAP-TTLS es similar a PEAP pero más flexible en el método de autenticación interno. Es común en entornos Linux y donde se necesita dar soporte a backends de autenticación heredados. EAP-FAST fue desarrollado por Cisco como respuesta a las debilidades de LEAP. Utiliza credenciales de acceso protegido en lugar de certificados. Es relevante principalmente si se encuentran en un entorno con gran presencia de Cisco o si tratan con dispositivos heredados que no pueden admitir los otros métodos. EAP-SIM y EAP-AKA se utilizan en despliegues de nivel de operador (piensen en OpenRoaming o Passpoint) donde la autenticación está vinculada a una tarjeta SIM o USIM. Estos son cada vez más relevantes para el WiFi de lugares públicos donde se desea una incorporación fluida y segura sin un Captive Portal. Hablemos ahora de la configuración de RADIUS. Ya sea que estén desplegando Microsoft NPS, FreeRADIUS, Cisco ISE o Aruba ClearPass, los pasos principales de configuración son los mismos. Primero, definen sus clientes RADIUS: estos son sus puntos de acceso o controladores de LAN inalámbrica. Cada cliente se registra con su dirección IP y un secreto compartido. Ese secreto compartido se utiliza para autenticar los mensajes RADIUS entre el AP y el servidor. Utilicen un mínimo de 22 caracteres, generados aleatoriamente y únicos por dispositivo NAS. Segundo, configuran su política de red. Aquí es donde definen quién tiene acceso a qué. En términos de NPS, están creando una política de red que coincide con condiciones (pertenencia a grupos en Active Directory, tipo de dispositivo, hora del día) y asigna atributos (ID de VLAN, tiempo de espera de sesión, límites de ancho de banda). El atributo RADIUS que más utilizarán es la asignación de VLAN, específicamente Tunnel-Type establecido en VLAN, Tunnel-Medium-Type establecido en 802 y Tunnel-Private-Group-ID establecido en su número de VLAN. Tercero, configuran su política de solicitud de conexión. Esto le indica a NPS cómo manejar las solicitudes RADIUS entrantes: si autenticarse localmente o reenviarlas a otro servidor RADIUS. En un despliegue distribuido, podrían tener un servidor RADIUS central con proxies NPS en cada sitio. Por el lado de los certificados, para PEAP y EAP-TLS, su servidor RADIUS necesita un certificado de servidor en el que confíen sus clientes. El camino más sencillo es utilizar un certificado de una CA pública (DigiCert, Sectigo, Let's Encrypt) porque esos certificados raíz ya son de confianza para todos los principales sistemas operativos. Si utilizan una CA interna, deben enviar el certificado raíz a todos los dispositivos cliente a través de directivas de grupo o su plataforma MDM. Para EAP-TLS específicamente, también necesitan certificados de cliente. En un entorno de Active Directory, utilizarían ADCS con inscripción automática a través de directivas de grupo para enviar certificados a los dispositivos unidos al dominio. Para dispositivos BYOD, utilizarían su MDM (Intune, Jamf, VMware Workspace ONE) para enviar tanto el certificado como el perfil WiFi. Por el lado del punto de acceso, la configuración es sencilla. Crean un nuevo SSID, establecen la seguridad en WPA2-Enterprise o WPA3-Enterprise, apuntan el servidor de autenticación RADIUS a la IP de su NPS en el puerto UDP 1812, establecen el servidor de contabilidad RADIUS en el puerto UDP 1813, introducen el secreto compartido y habilitan la asignación dinámica de VLAN si la están utilizando. La mayoría de las plataformas de AP empresariales (Cisco Meraki, Aruba, Ruckus, Extreme) tienen una interfaz gráfica para esto que lleva unos diez minutos una vez que el servidor RADIUS está listo. [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES — aproximadamente 2 minutos] Bien, hablemos de dónde suelen fallar los despliegues, porque aquí es donde me gano mis honorarios de consultoría. El punto de fallo más común es la validación de certificados. He visto organizaciones desplegar PEAP-MSCHAPv2 correctamente en el lado del servidor y luego dejar los perfiles de suplicante del cliente configurados para aceptar cualquier certificado. Eso socava por completo el modelo de seguridad. Cada perfil de suplicante, ya sea enviado a través de directivas de grupo o MDM, debe especificar la CA raíz de confianza y el nombre del servidor esperado. Sin eso, son vulnerables a ataques de tipo Evil Twin. El segundo problema común es la gestión de secretos compartidos de RADIUS. He visto redes de producción funcionando con el secreto compartido establecido en "radius" o el valor predeterminado del proveedor. Estos secretos son las claves de su infraestructura de autenticación. Genérenlos de forma aleatoria, almacénenlos en un gestor de secretos y rótenlos según un calendario. Tercero: configuración incorrecta de VLAN. La asignación dinámica de VLAN es potente: les permite colocar los dispositivos del personal en la VLAN corporativa, a los contratistas en una VLAN restringida y a los dispositivos IoT en una VLAN aislada, todo desde el mismo SSID. Pero si los atributos de RADIUS no están configurados correctamente, o los puertos troncales del switch no transportan las VLAN correctas, los dispositivos no podrán conectarse o terminarán en el segmento equivocado. Prueben esto a fondo en un laboratorio antes de lanzarlo a producción. Cuarto: redundancia. Su servidor RADIUS es ahora una pieza crítica de la infraestructura. Si se cae, nadie se conecta. Necesitan como mínimo un servidor RADIUS primario y secundario configurado en cada AP. En despliegues grandes, consideren clústeres de proxy RADIUS con monitorización de estado. Quinto, y esto es específico para entornos de hostelería y retail: separación de invitados y corporativo. Su SSID corporativo 802.1X y su SSID de WiFi de invitados deben estar completamente separados: diferentes VLAN, diferentes políticas de firewall, diferentes DNS. Una plataforma como Purple maneja el lado de invitados con su propio Captive Portal y capa de analíticas, mientras que su infraestructura 802.1X maneja el lado corporativo. Estos son sistemas complementarios, no competidores. [PREGUNTAS Y RESPUESTAS RÁPIDAS — aproximadamente 1 minuto] Permítanme repasar las preguntas que recibo con más frecuencia. ¿Puedo ejecutar 802.1X en una plataforma de AP gestionada en la nube? Sí, Meraki, Aruba Central y Ruckus Cloud lo admiten. Configuran los detalles del servidor RADIUS en el panel de control de la nube y los AP se encargan del proxying de EAP. ¿Necesito Active Directory? No. FreeRADIUS puede autenticar contra LDAP, bases de datos SQL, archivos planos o incluso API REST. Pero la integración de AD a través de NPS es, con diferencia, la ruta empresarial más común. ¿Qué pasa con los dispositivos IoT que no admiten 802.1X? Utilicen MAC Authentication Bypass (MAB) como alternativa. La dirección MAC del dispositivo se envía a RADIUS como usuario y contraseña. No es tan seguro como EAP, pero les permite incorporar dispositivos IoT manteniéndolos en una VLAN restringida. ¿Funciona 802.1X con WPA3? Sí. WPA3-Enterprise es esencialmente WPA3 con autenticación 802.1X. Añade un cifrado más fuerte (de 192 bits en el modo de alta seguridad) y es el estándar recomendado para nuevos despliegues. [RESUMEN Y PRÓXIMOS PASOS — aproximadamente 1 minuto] Para resumir: 802.1X no es algo opcional. Para cualquier organización que maneje datos sensibles, procese pagos o funcione en un entorno regulado, es la línea base para la seguridad WiFi empresarial. La arquitectura está bien establecida, las herramientas son maduras y la ruta de despliegue es clara. Comiencen con la selección de su método EAP: PEAP-MSCHAPv2 si necesitan resultados rápidos y una amplia compatibilidad, EAP-TLS si tienen la infraestructura de PKI y necesitan la postura de seguridad más sólida. Configuren su servidor RADIUS y su redundancia antes de tocar un solo AP. Envíen sus perfiles de suplicante a través de directivas de grupo o MDM antes de entrar en producción. Y mantengan su WiFi de invitados completamente separado: utilicen una plataforma diseñada específicamente para esa capa. Si operan en un entorno de múltiples sedes (hoteles, cadenas de tiendas, estadios), la complejidad escala con el número de sitios, pero la arquitectura no cambia. La clave es un RADIUS centralizado con redundancia local en cada sitio y un perfil de suplicante consistente enviado por MDM a toda su flota de dispositivos. Gracias por escuchar. La guía escrita completa, los diagramas de arquitectura y las listas de verificación de configuración están disponibles en purple.ai. Si están planeando un despliegue de 802.1X y desean hablar sobre los detalles específicos de su entorno, pónganse en contacto directamente con el equipo de Purple.