Resumen #

RADIUS ( Remote Authentication Dial-In User Service) es un protocolo de red que proporciona autenticación, autorización y gestión centralizada de usuarios y dispositivos. Es ampliamente utilizado por proveedores de servicios de Internet y empresas para controlar el acceso a Internet, servicios locales, redes inalámbricas a través de puntos de acceso Wi-Fi, etc.

El protocolo RADIUS se implementa en la capa de aplicación con una arquitectura cliente-servidor que puede usar TCP o UDP como capa de transporte y se comunica con una base de datos de usuarios como Active Directory , un servicio LDAP o un sistema de contabilidad Linux . Las soluciones RADIUS más populares son FreeRadius o Microsoft NPS Radius Server.

Protocolo de mensajería RADIUS #

La mensajería del protocolo se basa en la solicitud del cliente y la forma de respuesta del servidor, como se muestra a continuación.

1. El cliente envía un Acceso requerido al servidor para que cada usuario o dispositivo se autentique en el puerto del servidor TCP / UDP 1812 (Las versiones anteriores del servidor usarían 1645 para autenticación también).
2. El servidor responde según la política. Acceso-Aceptar si la autenticación está permitida, Acceso-Rechazar si el acceso no está permitido o Acceso-Desafío si el servidor requiere más información para determinar el acceso (como una segunda validación: PIN, contraseña, certificado, etc.)

Opcionalmente, el cliente y el servidor podrían intercambiar mensajes de contabilidad, como Accounting-Request y Accounting-Response, para mantener un identificador de sesión único.

3. El cliente envía un Solicitud de contabilidad al servidor a través del puerto TCP / UDP 1813 para la gestión de sesiones de contabilidad (las versiones anteriores del servidor usarían 1646 para autenticación también).
4. El servidor responde con un Respuesta Contable mensaje para confirmar la nueva sesión.

En un entorno RADIUS será necesario e importante considerar un servicio adicional de gestión de bases de datos de usuarios en alta disponibilidad, el cual será tratado en otro artículo específico.

Equilibrio de carga RADIUS y entorno de alta disponibilidad #

El problema si un servicio RADIUS no funciona podría producir el riesgo de que los usuarios no puedan acceder a una red de servidores, o iniciar sesión en una aplicación, los usuarios no puedan abrir una sesión en un dispositivo o no puedan obtener la autorización para usar un derecho en un proceso de negocio. Para resolver ese tipo de situaciones, el objetivo de este artículo es configurar el entorno que se muestra a continuación.

RELIANOID compartirá los mensajes del protocolo RADIUS entre todos los servidores RADIUS, ya sea que estén en sitios diferentes o locales. En las siguientes secciones explicamos la configuración de este tipo de entornos, los controles de estado avanzados de los servicios RADIUS y los desafíos de seguridad de este protocolo.

Configuración del servicio virtual RADIUS #

El protocolo RADIUS se basa en paquetes UDP, por lo que la configuración de un entorno RADIUS fiable se construye con una granja LSLB con perfil L4xNAT en la capa 4, puertos 1812 y 1813 , tipo de protocolo UDP y DNAT preferido para tener transparencia y obtener la IP del cliente en el lado del backend (aunque NAT también debería funcionar perfectamente).

En los Servicios , no se necesita persistencia por defecto, a menos que se requiera cierta vinculación entre el cliente y el servidor RADIUS.

Si se utiliza RADIUS a través de TCP en lugar de UDP, se puede modificar el tipo de protocolo. También se puede configurar como TODOS los protocolos para permitir TCP y UDP simultáneamente desde la misma IP virtual.

Finalmente, configure los backends sin puertos configurados (ya que usará el puerto de destino de la conexión del cliente) y pruebe la conexión. Una vez que el servicio virtual RADIUS esté configurado correctamente, podemos configurar la verificación de estado avanzada para este servicio.

Configuración avanzada de verificación de estado de RADIUS #

Se incluye un control avanzado en RELIANOID con nombre comprobar_radio bajo la carpeta predeterminada /usr/local/zenloadbalancer/app/libexec/.

La ayuda de este comando se puede enumerar:

root@noid5# /usr/local/zenloadbalancer/app/libexec/check_radius --help Prueba para ver si un servidor RADIUS acepta conexiones. Uso: check_radius -H host -F config_file -u nombre de usuario -p contraseña [-P puerto] [-t tiempo de espera] [-r reintentos] [-e expect] [-n nas-id] [-N nas-ip-addr ] Opciones: -h, --help Imprimir pantalla de ayuda detallada -V, --version Imprimir información de la versión --extra-opts=[sección][@file] Leer opciones de un archivo ini. Consulte https://www.monitoring-plugins.org/doc/extra-opts.html para conocer su uso y ejemplos. -H, --hostname=DIRECCIÓN Nombre de host, dirección IP o socket Unix (debe ser una ruta absoluta) -P, --port=INTEGER Número de puerto (predeterminado: 1645) -u, --username=STRING El usuario a authenticate -p, --password=STRING Contraseña para autenticación (RIESGO DE SEGURIDAD) -n, --nas-id=STRING Identificador NAS -N, --nas-ip-address=STRING Dirección IP NAS -F, --filename= STRING Archivo de configuración -e, --expect=STRING Cadena de respuesta que se espera del servidor -r, --retries=INTEGER Número de veces que se debe reintentar una conexión fallida -t, --timeout=INTEGER Segundos antes de que se agote el tiempo de espera de la conexión (predeterminado: 10) Este complemento prueba un servidor RADIUS para ver si acepta conexiones. En la invocación se debe especificar el servidor a probar, así como un nombre de usuario y contraseña. También puede haber un archivo de configuración presente. El formato del archivo de configuración se describe en las fuentes de la biblioteca RadiusClient. La opción de contraseña presenta un problema de seguridad sustancial porque la contraseña posiblemente se pueda determinar observando cuidadosamente la línea de comando en una lista de procesos. Este riesgo se ve exacerbado porque el complemento normalmente se ejecutará a intervalos regulares y predecibles. Asegúrese de que la contraseña utilizada no permita el acceso a recursos confidenciales del sistema.

En primer lugar, verifiquemos si funciona correctamente ejecutando el siguiente comando de ejemplo (use sus propios parámetros de configuración del cliente Radius desde RELIANOID):

root@noid5# cd /usr/local/zenloadbalancer/app/libexec/ root@noid5# ./check_radius -H -PAG -tú -pag -F

La prueba se realizará desde RELIANOID dispositivo a un determinado servidor RADIUS con una validación de usuario ficticia y, opcionalmente, un archivo de configuración de cliente para parámetros de cliente específicos. Probemos el comando y luego, cuando obtengamos el OK desde el servidor y el FRACASO cuando está inactivo podemos configurar la verificación de salud avanzada en el Servicios sección de nuestro recién creado servicio virtual.

No te olvides de usar el HOST token al configurar las comprobaciones de estado avanzadas en RELIANOID como se indica a continuación.

check_radius -H HOST -P 1812 -u johndoe -p johnspass -F /etc/radius_client.cfg

Consulte a continuación la configuración de la sección Servicios.

Opciones de seguridad RADIUS #

El protocolo RADIUS ha utilizado tradicionalmente algoritmos MD5 para la autenticación por paquete y las comprobaciones de integridad a través de UDP. Como estos dos no proporcionan ningún cifrado ni protección de seguridad, se han estudiado varios enfoques.

Implementaciones de RADIUS sobre IPsec or Seguridad del protocolo Internet Se han implementado ampliamente, pero existen algunas dificultades con esta opción ya que la capa de aplicación no conoce las políticas de seguridad, ya que están implícitas en la capa de red. Para utilizar este enfoque con RELIANOID se requiere alguna configuración manual ya que aún no está integrado.

La especificación de DTLS o Datagram Transport Layer Security permite proporcionar cifrado, monitorizar y controlar las políticas de seguridad de dicho tráfico.

Otra opción sería RADIUS sobre TLS , que proporciona capacidades TCP de confiabilidad y una capa de transporte en orden.

Para este tipo de enfoques, la IANA ha creado una entrada oficial para RadSec ( RADIUS Security ) para usar el puerto UDP 2083 para implementaciones de RADIUS/TLS.

Otra opción sería mejorar la capa de resumen y autorización con EAP ( Protocolo de Autenticación Extensible ), que no se utiliza en la capa de establecimiento de enlace, sino durante la fase de autenticación de la conexión, evitando el uso de resúmenes débiles MD5.

Además, con RELIANOID, los servicios RADIUS se pueden proteger con el módulo IPDS contra paquetes y hosts maliciosos, ataques DoS, intentos de fuerza bruta y mucho más.

Capacidades de proxy RADIUS #

Si se implementan varios servidores RADIUS en diferentes sitios, sería interesante reenviar la conexión del cliente al sitio que administra sus datos de autenticación, autorización y contabilidad. Actualmente, RELIANOID no admite capacidades de proxy RADIUS, pero se planea incluirlo pronto. ¡Esperemos las últimas novedades!

¡Disfrute de sus servicios de acceso a red escalables y de alta disponibilidad!