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 pódcast de Purple Enterprise WiFi Intelligence [INTRODUCCIÓN: aproximadamente 1 minuto] Bienvenidos de nuevo. Hoy os hablo como arquitecto sénior de soluciones y, si estáis escuchando esto, probablemente os estéis enfrentando a un proyecto de seguridad de red que implica la autenticación 802.1X - ya sea porque vuestro equipo de conformidad lo ha señalado, vuestra aseguradora ha preguntado por ello o simplemente acabáis de heredar una red que funciona con una PSK compartida y sabéis que eso ya no es suficiente. Así que entremos en materia de inmediato. 802.1X es el estándar 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 vuestra red ha sido identificado y autorizado positivamente antes de que pase un solo byte de tráfico. Esto no es opcional para las organizaciones que gestionan datos de tarjetas de pago bajo PCI-DSS, no es opcional para los entornos sanitarios bajo el GDPR y las normas de seguridad de datos del NHS y, francamente, 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, os 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 consta de tres componentes. Está el Suplicante - que es el dispositivo cliente, el portátil, el teléfono, el sensor IoT. Está el Autenticador - que es vuestro punto de acceso o vuestro switch de red, a veces llamado NAS (Network Access Server). Y está el Servidor de Autenticación - que es casi universalmente un servidor RADIUS en los 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 se limita a dejarlo entrar. 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. A continuación, el AP la reenvía 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 hayáis 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 elijáis aquí es de enorme importancia. Hay cinco que encontraréis 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 conformidad con 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 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 implantado en la práctica. Crea un túnel TLS utilizando únicamente un certificado en el lado del servidor y, a continuación, transmite 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 desventaja es que es vulnerable a ataques de obtenció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 común en entornos Linux y cuando se necesita dar soporte a sistemas 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 encuentra en un entorno con fuerte presencia de Cisco o si trabaja con dispositivos heredados que no admiten los otros métodos. 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 desea 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 aleatoriamente 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, creará una política de red que coincida con ciertas condiciones (pertenencia a un grupo en Active Directory, tipo de dispositivo, hora del día) y asignará 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 autenticarse localmente o para reenviarlas a otro servidor RADIUS. En una implementación distribuida, es posible que tenga un servidor RADIUS central con proxies NPS en cada ubicación. 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 gozan de la confianza de todos los sistemas operativos principales. Si utiliza una CA interna, deberá distribuir 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 inscripción automática mediante directivas de grupo para distribuir los certificados a los dispositivos unidos al dominio. Para los dispositivos BYOD, utilizaría su MDM - Intune, Jamf, VMware Workspace ONE - para distribuir tanto el certificado como el perfil de WiFi. En cuanto al punto de acceso, la configuración es sencilla. Crea un nuevo SSID, establece la seguridad en WPA2-Enterprise o WPA3-Enterprise, apunta el servidor de autenticación RADIUS a la IP de su NPS en el puerto UDP 1812, configura el servidor de contabilidad (accounting) RADIUS en el puerto UDP 1813, introduce el secreto compartido y habilita 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 - disponen de una interfaz gráfica de usuario para esto que se configura en unos diez minutos una vez que el servidor RADIUS está listo. [RECOMENDACIONES DE IMPLEMENTACIÓN Y ERRORES COMUNES - aproximadamente 2 minutos] Bien, hablemos de los puntos en los que las implementaciones suelen fallar, 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 implementar PEAP-MSCHAPv2 correctamente en el servidor y luego dejar los perfiles de suplicante del cliente configurados para aceptar cualquier certificado. Eso debilita por completo el modelo de seguridad. Cada perfil de suplicante - ya sea distribuido 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, queda expuesto 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 configurado como "radius" o con el valor predeterminado del fabricante. Estos secretos son las llaves de su infraestructura de autenticación. Generelos 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, 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 RADIUS no están configurados 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 monitorización de estado. Quinto, y esto es específico para entornos de hostelería y retail: separación entre invitados y corporativo. Su SSID corporativo 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 gestiona la parte corporativa. 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 gestionada en la nube? Sí - Meraki, Aruba Central y Ruckus Cloud lo soportan. Configura los detalles del servidor RADIUS en el panel de control de la nube y los AP se encargan del proxying EAP. ¿Necesito Active Directory? No. FreeRADIUS puede autenticar contra LDAP, bases de datos SQL, archivos planos o incluso APIs REST. Pero la integración de AD a través de NPS es, con diferencia, el camino empresarial más común. ¿Qué pasa con los dispositivos IoT que no soportan 802.1X? Utilice MAC Authentication Bypass - 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] Para resumir: 802.1X no es un capricho. Para cualquier organización que maneje datos sensibles, procese pagos o funcione en un entorno regulado, es la base de la seguridad WiFi empresarial. La arquitectura está bien consolidada, las herramientas son maduras y el camino de despliegue está claro. Comience con la selección de su método EAP - PEAP-MSCHAPv2 si necesita resultados rápidos y una amplia compatibilidad, EAP-TLS si dispone de 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 para invitados completamente separado - utilice una plataforma diseñada específicamente para esa capa. Si gestiona un entorno multi-establecimiento - hoteles, cadenas de retail, 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 centro, 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 comprobación de configuración están disponibles en purple.ai. Si está planificando un despliegue de 802.1X y desea hablar sobre los detalles específicos de su entorno, póngase en contacto directamente con el equipo de Purple.