802.1X y RADIUS: cómo se controla quién se conecta a la red de la empresa

En muchas oficinas basta con enchufar un portátil a una roseta de la pared para tener red. 802.1X cambia eso: el puerto no deja pasar tráfico hasta que el equipo demuestra quién es. Y RADIUS es, en la mayoría de los casos, el servidor que decide si esa identidad es buena. Esta guía explica los dos con lo que dicen sus especificaciones en el IETF.

Qué es 802.1X

802.1X es un estándar del IEEE. Según la RFC 3580, que resume su relación con RADIUS, ofrece autenticación por puerto de red en redes Ethernet y WiFi. En la práctica intervienen tres piezas:

El autenticador hace de portero: mientras no hay respuesta positiva, el puerto no da acceso a la red. La RFC 3580 aclara que 802.1X no exige un servidor de autenticación aparte, así que puede funcionar con un switch o un punto de acceso solos. Pero cuando se quiere gestionar todo desde un sitio, lo esperado es que el autenticador funcione como cliente de un servidor central. Ahí entra RADIUS.

Qué es RADIUS

RADIUS son las siglas de Remote Authentication Dial In User Service. Nació para los módems de acceso telefónico, como indica su nombre, y hoy se usa para mucho más. Su especificación es la RFC 2865, de junio de 2000, que lo describe así:

• Modelo cliente-servidor: el equipo de red, al que la RFC llama NAS (Network Access Server), es el cliente. Pasa los datos del usuario al servidor RADIUS y aplica la respuesta que recibe.
• El servidor decide: recibe la petición, autentica al usuario y devuelve la configuración necesaria para darle servicio. También puede reenviar la petición a otros servidores.
• Un secreto compartido: el cliente y el servidor se autentican con un secreto que nunca viaja por la red, y las contraseñas de los usuarios van cifradas entre los dos.
• Ampliable: los mensajes están hechos de atributos, y se pueden añadir atributos nuevos sin romper lo que ya funciona.

Usa el puerto UDP 1812 para la autenticación, según la RFC 2865, y el 1813 para la contabilidad, es decir, el registro de quién se conectó y cuánto tiempo, según la RFC 2866. Si hay un cortafuegos entre los switches y el servidor, son los puertos que hay que permitir, solo entre esos equipos.

Cómo funcionan juntos

1. Un portátil se conecta a un puerto del switch o a la WiFi de la empresa.
2. El switch o el punto de acceso le piden que se identifique. El portátil está conectado, pero sin red.
3. El autenticador pasa las credenciales al servidor RADIUS.
4. El servidor las comprueba y responde: aceptado o rechazado.
5. Si es aceptado, el puerto se abre. Si no, el equipo se queda fuera.

La VLAN según quién se conecte

La respuesta del servidor puede llevar algo más que un «sí». La RFC 3580 describe cómo el servidor RADIUS puede indicar, en su respuesta de aceptación, en qué VLAN debe quedar el equipo. Así, el mismo puerto de la pared puede llevar a la red de contabilidad, a la de invitados o a la de impresoras según quién se conecte. La RFC pone como ejemplo que un equipo inalámbrico mantenga su VLAN mientras se mueve por un campus.

Es una forma de aplicar la idea de confianza cero en la red local: estar físicamente en la oficina no basta para entrar.

Los riesgos

La RFC 3580 avisa de que, al usar RADIUS, 802.1X hereda todas sus amenazas: modificación o falsificación de paquetes, ataques de diccionario, repetición de mensajes y problemas con la gestión de claves, entre otras. Por eso exige que, con 802.1X, todos los paquetes RADIUS vayan autenticados y protegidos frente a cambios con el atributo Message-Authenticator.

El caso más serio es reciente. En julio de 2024, INCIBE-CERT publicó un aviso de importancia crítica sobre Blast-RADIUS (CVE-2024-3596):

• A quién afecta: a todas las implementaciones de RADIUS que usen métodos de autenticación que no son EAP sobre UDP.
• Qué permite: a un atacante situado entre el cliente y el servidor, convertir un rechazo en una aceptación, sin conocer la contraseña. Podría acabar entrando en cualquier equipo que use RADIUS para autenticar o darse los privilegios que quiera.
• Cómo: combina un fallo del protocolo con un ataque de colisión sobre MD5.

INCIBE recomienda:

• Pasar a RADIUS sobre TLS (RadSec), con un canal cifrado y autenticado.
• Que clientes y servidores envíen y exijan el atributo Message-Authenticator en todas las peticiones y respuestas, como primer atributo en las de aceptación o rechazo.
• No enviar tráfico RADIUS sin restricciones por internet.
• En la red interna, aislar el tráfico RADIUS en una VLAN con acceso restringido, o llevarlo por un túnel TLS o IPsec.

Qué hace falta para ponerlo en marcha

Esto es criterio de esta web, a partir de lo anterior:

• Switches y puntos de acceso que admitan 802.1X. No todos lo hacen: compruébalo en la ficha de cada modelo antes de comprar.
• Un servidor RADIUS. Mira en la ficha de tu equipo si lo incluye y si admite Message-Authenticator y RadSec.
• Un plan para lo que no se puede autenticar. Impresoras, cámaras o equipos antiguos que no admiten 802.1X necesitan otra solución, como un puerto fijo en una VLAN separada y con reglas estrictas en el cortafuegos.
• Empezar por partes. Activarlo primero en la WiFi o en una planta permite detectar los equipos que se quedan fuera antes de llevarlo a toda la oficina.