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

Cómo configurar la autenticación WiFi 802.1X: una 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 sénior de soluciones, y si están escuchando esto, probablemente se enfrenten a un proyecto de seguridad de red que implica la autenticación 802.1X, ya sea porque su equipo de cumplimiento normativo lo ha señalado, su aseguradora lo ha solicitado o simplemente porque acaban de heredar una red que funciona con una clave compartida PSK y saben que eso ya no es suficiente. Así que entremos en materia directamente. El estándar 802.1X es la norma de la IEEE para el control de acceso a redes 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 sea identificado y autorizado de forma inequívoca antes de poder transmitir un solo byte de tráfico. Esto no es opcional para las organizaciones que manejan datos de tarjetas de pago bajo la normativa PCI-DSS, no es opcional para los entornos sanitarios bajo el GDPR y las normas de seguridad de datos del NHS, y, para ser sinceros, para cualquier organización que gestione más de un puñado de puntos de acceso, es la arquitectura adecuada. Durante los próximos diez minutos, les 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. Comencemos. [ANÁLISIS TÉCNICO DETALLADO — aproximadamente 5 minutos] Bien, el marco de trabajo de 802.1X consta de tres componentes. Por un lado, tenemos el suplicante (Supplicant), que es el dispositivo cliente: el portátil, el teléfono o el sensor IoT. Por otro, está el autenticador (Authenticator), que es el punto de acceso o el conmutador de red, a veces denominado NAS (Network Access Server). Y, por último, está el servidor de autenticación (Authentication Server), que en los despliegues empresariales es casi de forma universal un servidor RADIUS. Así es como funciona el proceso de negociación (handshake). Cuando un dispositivo intenta conectarse a un SSID protegido por 802.1X, el punto de acceso no permite el acceso directamente. En su lugar, abre lo que se denomina un puerto controlado, un canal limitado que solo transmite tráfico EAP (Extensible Authentication Protocol). El punto de acceso envía una solicitud de identidad EAP-Request Identity al dispositivo. El dispositivo responde con su identidad. A continuación, el punto de acceso reenvía esa información al servidor RADIUS, empaquetada en un paquete RADIUS Access-Request. El servidor RADIUS ejecuta la autenticación (comprobando las credenciales con Active Directory, un almacén de certificados o cualquier backend de identidad que tengan configurado) y devuelve un Access-Accept o un Access-Reject. Solo tras recibir un mensaje de aceptación (Accept), el punto de acceso abre el puerto de datos completo y asigna el dispositivo a la VLAN correspondiente. Ahora bien, el método EAP que elijan aquí es sumamente importante. Hay cinco métodos con los que se 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 de por medio. Es la opción más segura y la requerida para los niveles de cumplimiento de PCI-DSS más elevados. El inconveniente es que se necesita una PKI completa (una infraestructura de clave pública) para emitir y gestionar los certificados de cliente. Eso implica una autoridad de certificación, la gestión del ciclo de vida de los certificados y un mecanismo para distribuir los certificados a cada dispositivo. Para las organizaciones con Microsoft Active Directory y Active Directory Certificate Services, esto es muy factible. Para las organizaciones que no disponen de esa infraestructura, representa una inversión significativa. PEAP-MSCHAPv2 es el método más implantado en la práctica. Crea un túnel TLS utilizando únicamente un certificado del lado del servidor y, a continuación, transmite las credenciales de usuario y contraseña dentro de ese túnel. Es compatible de forma nativa con prácticamente cualquier dispositivo, se integra directamente con Active Directory a través de NPS en Windows Server y no requiere certificados de cliente. La desventaja es que resulta vulnerable a ataques de recopilación de credenciales si se engaña a los usuarios para que se conecten a un AP malicioso, ya que el cliente no valida el certificado del servidor de forma predeterminada. Debe 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 habitual en entornos Linux y cuando se necesita ofrecer 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 (PAC) en lugar de certificados. Es relevante principalmente si se encuentra en un entorno con fuerte presencia de Cisco o si trabaja con dispositivos heredados que no admiten las otras opciones. EAP-SIM y EAP-AKA se utilizan en despliegues de nivel de operador (como OpenRoaming o Passpoint) donde la autenticación está vinculada a una tarjeta SIM o USIM. Estos métodos son cada vez más relevantes para el WiFi de lugares públicos donde se busca una incorporación fluida y segura sin un Captive Portal. Hablemos ahora de la configuración de RADIUS. Tanto si despliega Microsoft NPS, FreeRADIUS, Cisco ISE o Aruba ClearPass, los pasos fundamentales de configuración son los mismos. En primer lugar, defina 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. Utilice un mínimo de 22 caracteres, generados de forma aleatoria y únicos para cada dispositivo NAS. En segundo lugar, configure su política de red. Aquí es donde define quién tiene acceso a qué. En términos de NPS, consiste en crear una política de red que coincida con ciertas condiciones (pertenencia a grupos en Active Directory, tipo de dispositivo, hora del día) y asigne atributos (VLAN ID, tiempo de espera de la sesión, límites de ancho de banda). El atributo RADIUS que más utilizará 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. En tercer lugar, debe configurar su política de solicitud de conexión. Esto le indica a NPS cómo gestionar las solicitudes RADIUS entrantes, ya sea para autenticarlas localmente o para reenviarlas a otro servidor RADIUS. En un despliegue distribuido, puede tener un servidor RADIUS central con proxies NPS en cada sitio. En cuanto a 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 sistemas operativos principales. Si utiliza una CA interna, deberá enviar el certificado raíz a todos los dispositivos cliente mediante directivas de grupo o su plataforma MDM. Específicamente para EAP-TLS, también necesita certificados de cliente. En un entorno de Active Directory, utilizaría ADCS con autoinscripción mediante directivas de grupo para enviar los certificados a los dispositivos unidos al dominio. Para los dispositivos BYOD, utilizaría su MDM - Intune, Jamf, VMware Workspace ONE - para enviar tanto el certificado como el perfil de WiFi. En lo que respecta al punto de acceso, la configuración es sencilla. Debe crear un nuevo SSID, establecer la seguridad en WPA2-Enterprise o WPA3-Enterprise, apuntar el servidor de autenticación RADIUS a la IP de su NPS en el puerto UDP 1812, configurar el servidor de contabilidad RADIUS en el puerto UDP 1813, introducir el secreto compartido y habilitar la asignación dinámica de VLAN si la está utilizando. La mayoría de las plataformas de AP empresariales - Cisco Meraki, Aruba, Ruckus, Extreme - tienen una GUI para esto que requiere unos diez minutos una vez que su servidor RADIUS está listo. [RECOMENDACIONES DE IMPLEMENTACIÓN Y ESCOLLOS 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 a 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 de servidor esperado. Sin eso, se es vulnerable 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 en el valor por defecto del proveedor. Estos secretos son las llaves de su infraestructura de autenticación. Genérelos de forma aleatoria, almacénelos en un gestor de secretos y rótelos de manera programada. Tercero: la configuración incorrecta de las VLAN. La asignación dinámica de VLAN es muy potente - le permite colocar los dispositivos del personal en la VLAN corporativa, los contratistas en una VLAN restringida y los dispositivos IoT en una VLAN aislada, todo desde el mismo SSID. Pero si los atributos RADIUS no se configuran correctamente, o si los puertos troncales del switch no transportan las VLAN correctas, los dispositivos no podrán conectarse o terminarán en el segmento equivocado. Pruebe 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. Necesita como mínimo un servidor RADIUS primario y otro secundario configurados en cada AP. En despliegues grandes, considere clústeres de proxy RADIUS con supervisión de estado. Quinto, y esto es específico para entornos de hostelería y comercio minorista: separación de invitados frente a corporativos. Su SSID corporativo de 802.1X y su SSID de WiFi para invitados deben estar completamente separados - diferentes VLANs, diferentes políticas de firewall, diferentes DNS. Una plataforma como Purple gestiona la parte de invitados con su propio Captive Portal y capa de analítica, mientras que su infraestructura 802.1X se encarga de la parte corporativa. Son sistemas complementarios, no competitivos. [PREGUNTAS Y RESPUESTAS RÁPIDAS - aproximadamente 1 minuto] Permítame 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. Configura 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 autenticarse contra LDAP, bases de datos SQL, archivos planos o incluso REST APIs. Pero la integración de AD a través de NPS es, con diferencia, la vía empresarial más común. ¿Qué pasa con los dispositivos IoT que no son compatibles con 802.1X? Utilice la derivación de autenticación MAC - MAB - como alternativa. La dirección MAC del dispositivo se envía a RADIUS como nombre de usuario y contraseña. No es tan seguro como EAP, pero le 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] En resumen: 802.1X no es un lujo. Para cualquier organización que maneje datos sensibles, procese pagos o funcione en un entorno regulado, es el punto de partida para la seguridad de la red WiFi empresarial. La arquitectura está muy consolidada, las herramientas están maduras y el camino de despliegue está claro. Empiece por elegir su método EAP - PEAP-MSCHAPv2 si necesita resultados rápidos y una amplia compatibilidad, EAP-TLS si dispone de la infraestructura de PKI y necesita el nivel de seguridad más sólido. Configure y haga redundante su servidor RADIUS antes de tocar un solo AP. Distribuya sus perfiles de suplicante a través de Directivas de Grupo o MDM antes de entrar en servicio. Y mantenga su WiFi de invitados completamente separado - utilice una plataforma diseñada específicamente para esa capa. Si gestiona un entorno con múltiples ubicaciones - hoteles, cadenas de tiendas, estadios -, la complejidad aumenta con el número de centros, pero la arquitectura no cambia. La clave es un RADIUS centralizado con redundancia local por sitio, y un perfil de suplicante coherente distribuido por MDM en toda su flota de dispositivos. Gracias por escucharnos. La guía escrita completa, los diagramas de arquitectura y las listas de comprobación de configuración están disponibles en purple.ai. Si está planificando un despliegue de 802.1X y desea analizar los detalles específicos de su entorno, póngase en contacto directamente con el equipo de Purple.