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 encuentren frente a un proyecto de seguridad de red que involucra la autenticación 802.1X — ya sea porque su equipo de cumplimiento lo ha señalado, su aseguradora lo ha solicitado o simplemente acaban de heredar una red que funciona con una PSK compartida y saben que eso ya no es suficiente. Así que entremos de lleno en el tema. 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 de manera positiva antes de que se le permita transmitir 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 de atención médica bajo el GDPR y los estándares de seguridad de datos del NHS, y francamente, para cualquier organización que opere 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. Comencemos. [INMERSIÓN TÉCNICA PROFUNDA — aproximadamente 5 minutos] Muy bien, el marco de trabajo de 802.1X tiene tres componentes. Tienen el Supplicant (Suplicante) — que es el dispositivo cliente, la laptop, el teléfono, el sensor IoT. Tienen el Authenticator (Autenticador) — que 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 (handshake). Cuando un dispositivo intenta conectarse a un SSID protegido por 802.1X, el punto de acceso no lo deja entrar simplemente. En su lugar, abre lo que se llama un puerto controlado — un canal limitado que solo transmite tráfico EAP, el Protocolo de Autenticación Extensible. El AP envía una solicitud de identidad EAP (EAP-Request Identity) al dispositivo. El dispositivo responde con su identidad. Luego, el AP reenvía eso al servidor RADIUS, empaquetado en un paquete RADIUS Access-Request. El servidor RADIUS ejecuta la autenticación — verificando 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, el método EAP que elijan aquí es sumamente importante. 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 de por medio. Es la opción más segura y la requerida para los niveles más altos de cumplimiento de PCI DSS. El inconveniente es que se necesita una PKI completa (una infraestructura de clave pública) para emitir y gestionar los certificados de cliente. Eso significa 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 que cuentan con Microsoft Active Directory y Active Directory Certificate Services, esto es muy viable. Para las organizaciones que no disponen de esa infraestructura, representa una inversión significativa. PEAP-MSCHAPv2 es el método más utilizado 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 es vulnerable a ataques de extracción de credenciales si se engaña a los usuarios para que se conecten a un AP no autorizado, ya que el cliente no valida el certificado del servidor de forma predeterminada. Debe exigir 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 interna. 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 (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 pueden soportar los otros métodos. EAP-SIM y EAP-AKA se utilizan en implementaciones 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 segura y sin interrupciones, sin necesidad de un Captive Portal. Ahora hablemos de la configuración de RADIUS. Ya sea que esté implementando Microsoft NPS, FreeRADIUS, Cisco ISE o Aruba ClearPass, los pasos principales de configuración son los mismos. Primero, 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 aleatoriamente y únicos para cada dispositivo NAS. Segundo, configure su política de red. Aquí es donde define quién tiene acceso a qué. En términos de NPS, estará creando una política de red que coincida con ciertas condiciones (pertenencia a grupos en Active Directory, tipo de dispositivo, hora del día) y asignará atributos (ID de VLAN, 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 configurado en VLAN, Tunnel-Medium-Type configurado en 802 y Tunnel-Private-Group-ID configurado con su número de VLAN. Tercero, configuras tu política de solicitud de conexión. Esto le indica a NPS cómo manejar las solicitudes RADIUS entrantes, ya sea para autenticar localmente o reenviarlas a otro servidor RADIUS. En una implementación distribuida, podrías tener un servidor RADIUS central con proxies NPS en cada sitio. En el lado del certificado, para PEAP y EAP-TLS, tu servidor RADIUS necesita un certificado de servidor en el que confíen tus clientes. El camino más sencillo es usar 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 estás utilizando una CA interna, debes enviar el certificado raíz a todos los dispositivos cliente a través de la Directiva de grupo o tu plataforma MDM. Específicamente para EAP-TLS, también necesitas certificados de cliente. En un entorno de Active Directory, usarías ADCS con autoinscripción a través de la Directiva de grupo para enviar certificados a los dispositivos unidos al dominio. Para dispositivos BYOD, usarías tu MDM (Intune, Jamf, VMware Workspace ONE) para enviar tanto el certificado como el perfil de WiFi. En el lado del punto de acceso, la configuración es sencilla. Creas un nuevo SSID, estableces la seguridad en WPA2-Enterprise o WPA3-Enterprise, apuntas el servidor de autenticación RADIUS a tu IP de NPS en el puerto UDP 1812, configuras el servidor de contabilidad RADIUS en el puerto UDP 1813, ingresas el secreto compartido y habilitas la asignación dinámica de VLAN si la estás utilizando. La mayoría de las plataformas de AP empresariales (Cisco Meraki, Aruba, Ruckus, Extreme) tienen una GUI para esto que toma unos diez minutos una vez que tu servidor RADIUS está listo. [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES — aproximadamente 2 minutos] Bien, hablemos de dónde fallan las implementaciones, porque aquí es donde me gano mis honorarios de consultoría. El punto de falla más común es la validación de certificados. He visto organizaciones implementar 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 la Directiva de grupo o MDM, debe especificar la CA raíz de confianza y el nombre de servidor esperado. Sin eso, eres vulnerable a ataques de gemelo malvado. El segundo problema común es la gestión del secreto compartido 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 llaves de tu infraestructura de autenticación. Generálos de forma aleatoria, almacénalos en un gestor de secretos y rótalos de forma programada. Tercero: mala configuración de VLAN. La asignación dinámica de VLAN es potente: te 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 se conectarán o terminarán en el segmento equivocado. Prueba esto a fondo en un laboratorio antes de lanzarlo a producción. Cuarto: redundancia. Su servidor RADIUS es ahora una pieza crítica de infraestructura. Si se cae, nadie se conecta. Necesita como mínimo un servidor RADIUS primario y secundario configurado en cada AP. En implementaciones grandes, considere clústeres de proxy RADIUS con monitoreo de estado. Quinto, y esto es específico para entornos de hotelería y retail: separación de invitados frente a corporativos. Su SSID corporativo 802.1X y su SSID de WiFi de invitados deben estar completamente separados: diferentes VLAN, diferentes políticas de firewall, diferente 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ítame repasar las preguntas que recibo con más frecuencia. ¿Puedo ejecutar 802.1X en una plataforma de AP administrada en la nube? Sí — Meraki, Aruba Central y Ruckus Cloud lo admiten. Configura los detalles del servidor RADIUS en el panel de la nube y los AP se encargan del proxy EAP. ¿Necesito Active Directory? No. FreeRADIUS puede autenticarse contra LDAP, bases de datos SQL, archivos planos o incluso API REST. Pero la integración de AD a través de NPS es, por mucho, la ruta empresarial más común. ¿Qué pasa con los dispositivos IoT que no admiten 802.1X? Use la omisió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 mientras los mantiene en una VLAN restringida. ¿Funciona 802.1X con WPA3? Sí. WPA3-Enterprise es esencialmente WPA3 con autenticación 802.1X. Agrega un cifrado más fuerte (de 192 bits en el modo de alta seguridad) y es el estándar recomendado para nuevas implementaciones. [RESUMEN Y PRÓXIMOS PASOS — aproximadamente 1 minuto] Para resumir: 802.1X no es algo opcional. Para cualquier organización que maneje datos confidenciales, procese pagos o funcione en un entorno regulado, es la base de la seguridad WiFi empresarial. La arquitectura está bien establecida, las herramientas son maduras y la ruta de implementación es clara. Comience con la selección de su método EAP: PEAP-MSCHAPv2 si necesita resultados rápidos y una amplia compatibilidad, EAP-TLS si tiene la infraestructura PKI y necesita la postura de seguridad más sólida. Configure su servidor RADIUS y su redundancia antes de tocar un solo AP. Distribuya sus perfiles de suplicante a través de directivas de grupo o MDM antes de entrar en producción. Y mantenga su WiFi de invitados completamente separado: use una plataforma diseñada específicamente para esa capa. Si opera en un entorno de múltiples sedes (hoteles, cadenas de retail, estadios), la complejidad aumenta con el número de sitios, pero la arquitectura no cambia. La clave es un RADIUS centralizado con redundancia local por sitio y un perfil de suplicante consistente 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 verificación de configuración están disponibles en purple.ai. Si está planeando una implementación de 802.1X y desea analizar los detalles específicos de su entorno, póngase en contacto directamente con el equipo de Purple.