Configurar y probar un servidor RADIUS en Sophos Firewall

RADIUS conecta Sophos Firewall con Microsoft NPS, una puerta de enlace MFA u otro servicio de autenticación centralizado. Primero se preparan el sistema remoto y la ruta de red. A continuación, se crea el servidor en Authentication > Servers y se asigna únicamente a los servicios de inicio de sesión necesarios en Authentication > Services. La validación se realiza con un inicio de sesión real y comprobaciones del usuario, el grupo y las reglas.

Para las consultas clásicas de usuarios y grupos de un dominio de Windows, suele resultar adecuada la integración de Active Directory con Sophos Firewall. En escenarios modernos de acceso remoto, Microsoft Entra ID SSO para Sophos Connect y VPN Portal puede ser la arquitectura más apropiada. Si el objetivo es que el firewall reconozca a usuarios Wi-Fi ya autenticados a partir de paquetes de accounting entrantes, debe seguirse otro procedimiento: configurar RADIUS SSO con accounting en Sophos Firewall.

Cuándo conviene utilizar RADIUS

El firewall envía el nombre de usuario y las credenciales al servidor RADIUS. Allí, el origen de usuarios, la Network Policy y, si procede, MFA determinan si se devuelve Access-Accept o Access-Reject. Solo entonces el grupo de usuarios local, la política de VPN y las reglas de firewall determinan a qué recursos se puede acceder.

En el modelo RADIUS, los datos de autenticación y autorización se almacenan en perfiles de usuario. Para autorizar un servicio, la solicitud debe coincidir con los atributos previstos, por ejemplo, con la dirección IP del cliente RADIUS que realiza la solicitud. El Shared Secret protege las contraseñas de los usuarios; esto no implica que se cifre todo el transporte RADIUS.

Algunos casos de uso habituales son:

• Remote Access VPN con Microsoft NPS o un servicio MFA;
• inicio de sesión centralizado en User Portal, VPN Portal o Captive Portal;
• una solución de transición cuando no se desea conectar AD o LDAP directamente al firewall;
• varios dispositivos de red que utilizan el mismo servicio RADIUS.

Una red WLAN empresarial administrada desde el firewall utiliza además la selección de servidores de Wireless > Wireless settings. Por ello, el procedimiento completo de 802.1X se describe en configurar una red WLAN directamente en Sophos Firewall.

En una red WLAN empresarial administrada por SFOS, Accounting Request y Accounting Response contienen información de sesión y de accounting. Son independientes de las solicitudes, respuestas y desafíos de acceso utilizados para iniciar sesión. Para esta vía inalámbrica, Sophos documenta la compatibilidad con accounting en todos los dispositivos con capacidad Wi-Fi; Wireless Network debe utilizar 802.1X y el accounting debe estar habilitado en el servidor RADIUS. La guía WLAN enlazada explica los puertos separados y la ausencia de Interim Accounting Updates. La compatibilidad con accounting no implica que se admita un servidor RADIUS secundario.

Documentar el estado inicial y la vía de retorno

Antes de migrar un servicio de producción, se debe anotar lo siguiente para cada sección afectada de Authentication > Services:

• los servidores seleccionados y su orden;
• el estado de Set authentication methods same as firewall, Same as VPN o Same as firewall;
• el valor actual de Default group en la autenticación del firewall;
• un usuario con el que se haya comprobado que el método anterior funciona.

Durante el cambio de los inicios de sesión de administrador, se debe mantener abierta una sesión de WebAdmin existente. También hay que comprobar un superadministrador local a través de una ruta de administración que ya esté permitida. La selección de servidores para administradores no se aplica a este superadministrador, pero nunca debe cambiarse el método de inicio de sesión de un administrador externo sin haber confirmado antes una vía de retorno local.

Planificar la conexión RADIUS

Funciones, ruta de red y protocolos

En un entorno NPS, Sophos Firewall es el cliente RADIUS y NPS es el servidor RADIUS. NPS contrasta la solicitud con su Connection Request Policy y su Network Policy y, por lo general, también con Active Directory. Una política de VPN o una regla de firewall posterior sigue siendo la que determina el acceso efectivo.

La ayuda general de SFOS 22 describe la comunicación entre el firewall y el servidor RADIUS mediante PAP. Sin embargo, en Authentication > Services, Sophos enumera PAP, CHAP y MSCHAPv2 para conexiones L2TP y PPTP. Esta matriz de protocolos no demuestra que se admitan los mismos métodos para IPsec u otras vías de inicio de sesión. Por tanto, deben comprobarse conjuntamente el servicio, el cliente y el método permitido en el servidor RADIUS.

RADIUS clásico utiliza UDP y la interfaz documentada de SFOS no ofrece campos de TLS ni de certificados. Por ello, el tráfico debe circular por una ruta interna controlada o protegida de otra forma. Un Shared Secret robusto no sustituye ni a la segmentación ni a una autorización restrictiva entre el firewall y el servidor RADIUS.

Los sistemas antiguos pueden requerir otros puertos, como 1645/UDP y 1646/UDP. Lo determinante son los puertos realmente configurados en ambos extremos, no estos valores históricos.

Elegir los valores de ejemplo de forma consciente

Esta guía utiliza los siguientes valores:

• nombre del servidor: NPS-HQ-RADIUS;
• IP del servidor: 10.20.30.15;
• puerto de autenticación: 1812;
• puerto de accounting: 1813;
• tiempo de espera: 5 segundos;
• nombre de dominio: corp.example.

10.20.30.15 y corp.example deben sustituirse por la dirección interna y la convención de nombres propias. Cinco segundos es un valor inicial para una comprobación directa de contraseña, no el valor predeterminado de Sophos. En el caso de una notificación push, una llamada telefónica o un desafío externo, el valor debe ajustarse al proveedor y al cliente real dentro del intervalo de 1 a 60 segundos permitido por SFOS.

El Shared secret es el secreto técnico compartido por el cliente y el servidor RADIUS, no la contraseña de un usuario. Sophos lo limita a 48 caracteres. El valor debe intercambiarse por una vía independiente y protegida, almacenarse de forma segura e introducirse exactamente igual en ambos extremos; RADIUS no transmite el propio secreto por la red.

Crear el servidor RADIUS en Authentication

La ruta del menú es Authentication > Servers.

1. Abra Add y, en Server type, seleccione RADIUS server.
2. En Server name, introduzca, por ejemplo, NPS-HQ-RADIUS.
3. En Server IP, introduzca la dirección IP interna del servidor RADIUS; en este ejemplo, 10.20.30.15.
4. Ajuste Authentication port al servidor, normalmente 1812.
5. Defina Time-out. Para la primera prueba directa, el ejemplo utiliza 5 segundos.
6. Active Enable accounting solo si el sistema remoto debe procesar datos de accounting. En ese caso, ajuste también Accounting port, normalmente 1813.
7. Introduzca el Shared secret exactamente como está configurado en el sistema remoto.
8. De forma opcional, configure Domain name. Si se utilizan AD y RADIUS en paralelo, un dominio uniforme evita que una misma persona aparezca como distintos objetos de usuario locales. Con Domain name, en el primer inicio de sesión se crea automáticamente una entrada local con el formato user@domainname. Sin este valor, RADIUS crea un usuario sin dominio, mientras que AD crea una entrada con el dominio incluido; por ello, pueden generarse dos entradas locales para la misma persona.
9. Introduzca Group name attribute únicamente si se ha comprobado que el sistema remoto proporciona el atributo esperado. La ayuda de Sophos lo define como un alias del nombre de grupo configurado, pero no documenta aquí una asignación general de atributos NPS arbitrarios a grupos locales.
10. Abra Enable additional settings solo si existe una política adecuada. NAS-identifier identifica el Network Access Server solicitante, por ejemplo mediante un FQDN. NAS-port-type describe el tipo de puerto del inicio de sesión.
11. Ejecute Test connection con un usuario piloto propio y, a continuación, seleccione Save.

El firewall admite un máximo total de 20 servidores de autenticación configurados. También pueden seleccionarse como máximo 20 servidores por método de autenticación en Authentication > Services.

Nota sobre la API de SFOS 23: La referencia de la API para añadir y editar servidores RADIUS incorpora el parámetro opcional EmailAddressAttribute (cadena de texto, máximo 50 caracteres) y lo incluye en el ejemplo XML de RADIUSServer. No se indica ningún valor predeterminado. Esta nota se refiere a la documentación de la API, no a un campo adicional de WebAdmin.

Interpretar correctamente el accounting

Con Enable accounting, el firewall envía un mensaje Accounting-Start al iniciar sesión y un mensaje Accounting-Stop al cerrar sesión normalmente para los tipos de cliente compatibles. Sophos enumera Windows client, HTTP client, Linux client, Android, iOS, iOS HTTP client, Android HTTP client y API client. Las solicitudes de inicio y fin también contienen, respectivamente, el momento del inicio y del cierre de sesión.

Cuando el firewall se apaga o reinicia, no se envía ningún Accounting-Stop. Si una sesión permanece abierta en el servidor RADIUS, debe contrastarse el momento del reinicio con los registros de RADIUS. Esta función de accounting saliente no es el RADIUS SSO Accounting entrante con el que el firewall aprende sesiones de otros sistemas.

Preparar Microsoft NPS como sistema remoto

Sophos Firewall debe estar configurado en NPS como cliente RADIUS. La comprobación mínima en la consola Network Policy Server es la siguiente:

1. Abra RADIUS Clients and Servers > RADIUS Clients.
2. Cree un New RADIUS Client con un Friendly name inequívoco, como Sophos-Firewall-HQ.
3. En Address (IP or DNS), introduzca la dirección desde la que NPS recibe realmente la solicitud.
4. En Vendor, seleccione normalmente RADIUS standard.
5. Introduzca el mismo Shared secret que en el firewall.
6. En la Connection Request Policy y la Network Policy correspondientes, compruebe las condiciones, la decisión de acceso y el método de autenticación permitido para el usuario piloto.
7. Tenga disponibles Event Viewer y los registros de accounting de NPS para la validación.

En clústeres de HA, conexiones enrutadas o entornos con NAT, la dirección del cliente NPS no debe deducirse únicamente de la topología. Una primera prueba muestra en NPS qué IP de origen llega realmente. Si la solicitud no llega en absoluto o NPS no puede validarla, compruebe primero el enrutamiento, la regla que permite el tráfico UDP, la dirección del cliente RADIUS y el Shared Secret. En cambio, un Access-Reject normal apunta al usuario, a la política o al método de autenticación.

Asignar RADIUS a los servicios correctos

Después de guardar, el objeto de servidor todavía no está activo para ningún inicio de sesión. En SFOS 22, Authentication > Services contiene las siguientes secciones:

• Firewall authentication methods;
• User portal authentication methods;
• VPN portal authentication methods;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods;
• Administrator authentication methods;
• SSL VPN authentication methods.

En User Portal, VPN Portal, VPN y administradores, la selección de servidores puede estar vinculada a la autenticación del firewall. SSL VPN ofrece Same as VPN y Same as firewall. Antes de realizar cualquier cambio, compruebe si la sección afectada utiliza una lista propia o una lista vinculada.

Para una prueba piloto limitada, añada NPS-HQ-RADIUS únicamente en la sección necesaria, colóquelo en la posición prevista y seleccione Apply. El firewall consulta varios servidores en el orden mostrado. Si el mismo usuario ya puede autenticarse correctamente mediante un servidor anterior, no se alcanzará una política RADIUS MFA situada después.

Captive Portal y Default Group

Captive Portal no dispone de una sección propia en Authentication > Services. Utiliza Firewall authentication methods. Además, la zona prevista debe tener habilitado Captive portal en Administration > Device access y debe existir una regla de firewall basada en usuarios correctamente configurada. Una prueba funcional oficial consiste en iniciar sesión en https://<firewall-ip>:8090.

La opción Default group de Firewall authentication methods es relevante para la seguridad. Cuando un usuario externo inicia sesión correctamente por primera vez en un servicio del firewall, se crea en Authentication > Users. Si no existe una asignación adecuada a un grupo local, se aplica el valor configurado en Default group. Antes de la prueba piloto, compruebe las políticas del grupo y todas las reglas en las que se utiliza; un Default group con permisos excesivos no debe convertirse inadvertidamente en el grupo de reserva.

Delimitar la MFA con desafío según el servicio

Según la ayuda de SFOS 22, VPN Portal no admite autenticación RADIUS con MFA basada en desafíos. Por tanto, una ejecución correcta de Test connection no demuestra que esta vía del portal funcione. Push, llamada, OTP y desafío tampoco son intercambiables: cada cliente y servicio previsto debe probarse por separado. Para la MFA local de Sophos Firewall, consulte el procedimiento específico para activar MFA en Sophos Firewall WebAdmin, VPN Portal y Remote Access.

Validar la configuración

1. Conexión y sistema remoto

En Authentication > Servers, abra NPS-HQ-RADIUS y ejecute Test connection con el usuario piloto. Al mismo tiempo, compruebe en NPS o en los registros del otro sistema remoto que:

• la solicitud procede de la dirección esperada del firewall;
• la procesa la política correcta;
• el resultado es Access-Accept;
• están presentes los atributos de respuesta esperados.

La prueba confirma las credenciales y la comunicación con el servidor. Todavía no confirma el orden de los servicios, la política de VPN, el grupo local ni la regla de firewall.

2. Probar el servicio real

A continuación, inicie sesión con el mismo usuario a través del servicio previsto. Captive Portal, SSL VPN, IPsec, User Portal y WebAdmin tienen requisitos diferentes. En WebAdmin, el usuario externo también debe recibir el perfil de administrador previsto; una autenticación RADIUS correcta no concede por sí sola permisos de administrador. Las vías que no sean necesarias deben permanecer sin cambios. Para SSL VPN, configurar el acceso remoto SSL VPN en Sophos Firewall explica la política, Device Access y la regla de firewall.

Después de iniciar sesión correctamente, compruebe:

1. En Authentication > Users, el usuario local, el dominio y el Main Group efectivo.
2. En Current activities > Live users, la sesión activa; si es necesario, puede finalizarla allí con Disconnect.
3. En Log viewer, situado en la parte superior derecha de WebAdmin, abra el módulo Authentication y filtre por usuario, IP de origen y un intervalo de prueba reducido.
4. En el registro de tráfico, la Firewall Rule ID efectiva y únicamente el recurso de destino permitido.
5. El caso negativo con un usuario que no pertenezca a la política NPS autorizada.

Si el inicio de sesión funciona, pero no se puede acceder a la aplicación, compruebe la zona, el grupo de direcciones IP de VPN, el grupo, la posición de la regla, NAT y el enrutamiento. La regla de Sophos Firewall no se aplica: comprobar las causas recorre esta ruta de datos. Si la identidad, la selección del servicio o el Main Group ya presentan dudas, consulte solucionar sistemáticamente los errores de autenticación de Sophos Firewall.

Acotar los errores según lo observado

No llega ninguna solicitud al sistema remoto

Compruebe primero los valores configurados en Server IP y Authentication port. A continuación, revise el enrutamiento y la regla que permite el tráfico UDP 1812 entre la dirección de origen utilizada por el firewall y 10.20.30.15. Un objeto de servidor RADIUS no crea automáticamente una regla de firewall de tránsito.

Para una red inalámbrica administrada por SFOS, Sophos documenta un caso especial muy limitado: si el servidor RADIUS está conectado al firewall a través de un túnel IPsec, se necesita una asignación de Source NAT para las redes de los puntos de acceso. Esta traduce la IP de origen exactamente a la dirección IP del firewall que este utiliza para acceder al servidor RADIUS. La ayuda de Wireless remite para ello a una configuración mediante la shell con sys-traffic-nat; sin embargo, no proporciona aquí un comando completo que pueda ejecutarse. Antes de realizar un cambio, deben verificarse y documentarse las redes de los puntos de acceso, la dirección de origen realmente utilizada, la dirección del firewall para la traducción de origen, el túnel, la ruta de retorno y los registros de RADIUS. Sin una sintaxis confirmada para este fin, la configuración concreta de la shell, incluidas su comprobación y reversión, debe ser objeto de una escalación técnica específica. Para otras vías RADIUS, esta guía inalámbrica no demuestra que exista un requisito general de NAT. Una regla de LAN a VPN o un ejemplo de Forwarding-IPsec-Route no sustituye este procedimiento de tráfico del sistema.

NPS responde con Access-Reject

Un rechazo indica que la ruta de red y el puerto funcionan en principio. Compruebe ahora en NPS el Reason Code, la Network Policy aplicable, el estado del usuario y el método de autenticación permitido. En cambio, un Shared Secret incorrecto provoca respuestas ausentes, no válidas o que no pueden verificarse.

Test connection funciona, pero el inicio de sesión en el servicio no

En Authentication > Services, compruebe la sección correcta, los controles de vinculación, el orden de los servidores y Apply. Para Captive Portal, revise además Device access y la regla de firewall basada en usuarios. En SSL VPN, deben ser correctos el Policy Member, el acceso de SSL VPN en Device Access y la regla de firewall necesaria.

El inicio de sesión funciona, pero se aplica el grupo equivocado

En Authentication > Users, revise el dominio y el Main Group. A continuación, compare Group name attribute, los atributos de respuesta del sistema remoto y Default group. Una autenticación correcta no demuestra que la autorización sea la esperada. Por ello, debe comprobarse que el usuario de la prueba negativa no cumple la condición del grupo o de NPS.

Una notificación push o un desafío agota el tiempo de espera

Utilice el cliente real y compare las marcas de tiempo de los registros del firewall, NPS y el proveedor de MFA. Aumente el tiempo de espera de SFOS únicamente dentro del intervalo de 1 a 60 segundos y elija el valor más bajo que cubra de manera fiable el flujo normal del desafío. En VPN Portal, la MFA RADIUS basada en desafíos no puede corregirse ampliando el tiempo de espera, ya que Sophos no admite esta vía.

Revertir la configuración de forma segura

Si la prueba piloto falla, restaure en la sección afectada de Authentication > Services la lista de servidores anotada previamente, incluido su orden, así como los controles de vinculación y el valor de Default group; después, seleccione Apply. A continuación, inicie sesión con el usuario de referencia mediante el método original y compruebe el superadministrador local.

Solo cuando todos los servicios afectados vuelvan a funcionar debe eliminar NPS-HQ-RADIUS de las demás asignaciones de servicios. El objeto de servidor de Authentication > Servers solo debe eliminarse si ya no se prevé utilizarlo. En NPS, restaure el cliente, la política y el Shared Secret al estado anterior documentado. Los objetos de usuario locales que ya se hayan creado deben revisarse por separado; eliminarlos no finaliza automáticamente todas las sesiones existentes, por lo que también debe comprobar Current activities > Live users.

Operación

RADIUS es un servicio de identidad de producción. Después de modificar NPS, el proveedor de MFA, AD o el orden de los servicios, la validación debe incluir un inicio de sesión real positivo y otro negativo. El Shared Secret debe documentarse de forma protegida y rotarse según lo planificado. Configure la supervisión del sistema remoto y defina el periodo de conservación de sus registros de decisiones. Así podrá determinarse si un error se produjo antes del firewall, durante la autenticación o solo en la autorización.

FAQ