Proteger el VPN Portal de Sophos Firewall contra ataques de fuerza bruta

Muchos inicios de sesión fallidos en Sophos Firewall VPN Portal indican inicialmente que el portal es accesible desde Internet y está siendo atacado de forma automatizada. Todavía no demuestran que haya habido una intrusión. La situación se vuelve crítica cuando se prueban nombres de usuario reales, se bloquean cuentas en AD o Microsoft Entra ID, o aparece un inicio de sesión correcto desconocido entre los intentos fallidos.

Para contener el ataque, debe seguirse este orden:

1. Conservar en los logs el intervalo de tiempo, los usuarios, las IP de origen y los métodos de autenticación.
2. Comprobar los inicios de sesión correctos y los eventos de identidad del mismo periodo.
3. Limitar VPN Portal a los orígenes o países necesarios mediante una Local Service ACL.
4. Activar Block login y descartar que VPN Portal y SSL VPN compartan puerto.
5. Eliminar los métodos de autenticación que no sean necesarios y comprobar MFA o la protección de Entra.
6. Bloquear adicionalmente las fuentes IPv4 maliciosas conocidas mediante Threat Feeds y supervisar el efecto.

⚠️ No desactivar VPN Portal sin preparación. Sophos Connect Provisioning y Microsoft Entra ID SSO utilizan el puerto de VPN Portal. Antes de cambiar Device Access o los puertos, se necesita una segunda vía de administración probada y un plan para los perfiles de cliente, las Redirect URIs y la reversión.

Confirmar el ataque en Log Viewer

En Log Viewer, se abren los eventos de autenticación y se filtra por:

• Log component: VPN Portal Authentication
• Status: Failed

Para cada resultado son relevantes la hora, Source IP, Source country, Username, Authentication mechanism y Reason. En un SIEM se utilizan los campos Syslog log_component con el valor VPN Portal Authentication y status con el valor Failed; la sintaxis concreta de la consulta depende del SIEM utilizado.

Después se busca también Successful para los mismos nombres de usuario y el mismo intervalo. Un inicio de sesión correcto desconocido es más importante que el mero número de intentos fallidos y debe tratarse como un posible incidente de cuenta.

Una sola fuente o un ataque distribuido

La distribución determina qué protección resulta eficaz:

• Muchos intentos desde una dirección IP: Block login puede bloquear temporalmente el origen después de alcanzar el umbral.
• Pocos intentos desde muchas direcciones IP: Una botnet distribuida puede permanecer por debajo del umbral en cada origen. En ese caso, las ACL, la protección de identidad y los Threat Feeds cobran más importancia.
• Muchos nombres de usuario desde el mismo origen: Esto encaja con Password Spraying o Credential Stuffing.
• El mismo usuario real de forma repetida: Comprobar en los logs de AD, Entra o RADIUS los bloqueos de cuenta y los inicios de sesión correctos.
• Nombres aleatorios que no existen: Suele tratarse de escaneo automatizado, pero sigue generando carga y ruido en los logs.

Bloquear manualmente solo la IP de origen rara vez resuelve de forma duradera un ataque distribuido. Primero se reduce la superficie accesible y después se añaden automáticamente los orígenes maliciosos conocidos.

Revisar específicamente los logs sin procesar

Si Log Viewer no proporciona suficiente contexto, se descargan los archivos afectados en Diagnostics > Tools > Troubleshooting logs:

• vpnportal.log para el acceso al portal;
• access_server.log para la autenticación y autorización de usuarios;
• oauth_sso_vpn.log adicionalmente para Microsoft Entra ID SSO.

En cambio, sslvpn.log pertenece al servicio SSL VPN y solo es relevante cuando el error se produce al establecer el túnel y no al iniciar sesión en el portal. Los logs de autenticación pueden contener nombres de usuario, direcciones IP públicas y otros datos sensibles de las solicitudes. Por eso, los extractos se limitan por tiempo y contenido, se anonimizan antes de compartirlos y no se copian sin revisar en tickets públicos. Servicios y logs de Sophos Firewall permite identificar otros archivos de log; Guardar logs de Sophos Firewall describe un archivo de soporte estructurado.

Limitar VPN Portal a los orígenes necesarios

VPN Portal es un servicio local del firewall. Las reglas normales de firewall o DNAT no controlan este acceso; para ello se utiliza Administration > Device access. Los fundamentos completos se explican en Device Access y Local Service ACL.

Antes del cambio, se abre y se prueba realmente un acceso independiente mediante la consola, la LAN de gestión, una VPN de administración o Sophos Central. Después se crea primero la excepción restringida:

1. En Administration > Device access > Local service ACL exception rule, hacer clic en Add.
2. Name: por ejemplo vpn-portal-from-approved-countries.
3. Rule position: Top.
4. IP version: IPv4; si se publica IPv6, también se necesita una regla IPv6 independiente.
5. Source zone: WAN.
6. Source networks and hosts: redes fijas de socios, una lista de IP mantenida o un Country Group con los países realmente necesarios.
7. Destination host: la interfaz WAN o la IP WAN configurada en Sophos Firewall por la que llega el acceso. Si existe un router NAT anterior, no se refiere a la dirección pública de ese router.
8. Services: solo VPN portal.
9. Action: Accept.
10. Guardar la regla.

En el estado final, VPN Portal no está habilitado de forma general para WAN en la matriz Device Access, sino que solo es accesible mediante las excepciones ACL necesarias. Los cambios de Device Access se aplican de inmediato; por eso, el cambio seguro con prueba positiva, prueba negativa y reversión se explica expresamente en la guía detallada de Device Access.

A continuación, se prueba la excepción desde un origen externo permitido y otro no permitido. Mientras siga activa una habilitación WAN amplia, una prueba positiva correcta no demuestra por sí sola que la excepción limite el acceso como se espera.

La restricción por países resulta útil cuando el grupo de usuarios está claramente definido desde el punto de vista geográfico. Sin embargo, no es un control de identidad: los viajeros, las redes móviles, los proveedores VPN y las geolocalizaciones IP incorrectas pueden bloquear a usuarios legítimos. Por eso, el acceso mundial exige una identidad especialmente sólida, MFA, logging y un proceso de revisión.

Configurar correctamente Login Security y los puertos

En Administration > Admin and user settings > Login security, se activa Block login. Sophos Firewall Health Check utiliza como punto de partida cinco inicios de sesión fallidos en 60 segundos y una duración de bloqueo de cinco minutos. No obstante, el valor adecuado en producción depende del número de usuarios, del proceso de helpdesk y de los orígenes NAT compartidos.

El bloqueo funciona por IP de origen y, una vez alcanzado el umbral, no afecta únicamente a VPN Portal. WebAdmin, CLI, VPN Portal y User Portal tampoco se abrirán desde ese origen. De este modo, una oficina, un hotel o un NAT de proveedor puede afectar al mismo tiempo a varios usuarios legítimos y a un administrador. Por tanto, nunca se realiza una prueba negativa desde la única vía de administración disponible.

En un ataque distribuido, Block login es solo una capa de protección. Muchos bots pueden permanecer individualmente por debajo del umbral.

Descartar el uso compartido de puertos

Se comparan estos dos valores:

• Administration > Admin and user settings > VPN portal HTTPS port, de forma predeterminada TCP 443
• Remote access VPN > SSL VPN > SSL VPN global settings > Port, de forma predeterminada 8443 con TCP o UDP

Si VPN Portal y SSL VPN utilizan el mismo puerto y el mismo protocolo, los ajustes de Login Security no se aplican. Además, VPN Portal pasa a ser accesible desde las zonas permitidas para SSL VPN, aunque esté desactivado allí en Device Access.

Por tanto, la combinación debe ser inequívoca. Cambiar únicamente a un puerto aleatorio no impide un ataque. Si se modifica el puerto de VPN Portal, deben actualizarse la URL del portal, la Entra Redirect URI y el valor vpn_portal_port para Sophos Connect Provisioning, y volver a probarse con un usuario piloto.

Proteger la autenticación y las cuentas afectadas

En Authentication > Services > VPN portal authentication methods, solo permanecen activos los servidores que el concepto actual de Remote Access necesita realmente. Una vía local, AD, LDAP o RADIUS que ya no se utiliza no aporta ninguna ventaja, pero puede permitir probar más credenciales contra el portal público.

MFA no impide todos los intentos fallidos, pero reduce el riesgo de que baste una contraseña conocida o adivinada. MFA para VPN Portal y Remote Access explica la configuración para usuarios locales y de directorio. Con Microsoft Entra ID SSO, también se comprueban Entra MFA, Conditional Access, Sign-in Logs y Risk Events.

Un usuario real con intentos fallidos sospechosos no se analiza únicamente en el firewall:

1. Comprobar los bloqueos de cuenta y los inicios de sesión correctos en el Identity Provider correspondiente.
2. Finalizar las sesiones correctas desconocidas de acuerdo con el proceso de incidentes.
3. Restablecer la contraseña y los métodos MFA registrados si se sospecha de una cuenta comprometida.
4. Comprobar la pertenencia a grupos y la autorización de Remote Access.
5. Solo entonces, verificar mediante un inicio de sesión piloto documentado que el acceso legítimo vuelve a funcionar.

VPN Portal solo puede eliminarse por completo de WAN si ningún proceso necesario depende de él. Entra SSO y el Provisioning mediante .pro utilizan el puerto del portal. Si se distribuyen manualmente archivos .ovpn, puede ser posible un proceso de publicación más restringido, pero los cambios de perfil deben distribuirse y probarse de forma controlada.

Añadir Threat Feeds contra orígenes conocidos

Sophos Firewall también puede comparar direcciones IP de origen maliciosas conocidas en el tráfico dirigido al sistema hacia servicios como VPN Portal, WebAdmin y VPN. Los feeds IPv4 mantenidos son adecuados como capa de protección adicional.

Configurar Threat Feeds en Sophos Firewall explica la configuración completa, los requisitos de licencia, el piloto con Monitor, el funcionamiento con Block, los False Positives y los feeds de Cybora probados por Avanet. Para un feed nuevo, sigue siendo necesario comprobar la descarga y el contenido de IoC, observar primero el efecto y solo después bloquear de forma controlada.

Para que las coincidencias de Active Threat Response aparezcan en Log Viewer, debe activarse Local reporting para Active threat response en System services > Log settings.

Los Threat Feeds no sustituyen una ACL ni una identidad sólida. Solo detectan los indicadores incluidos, los Third-Party Feeds admiten actualmente IPv4 para IoC de IP de origen, y una IP de bot nueva o no incluida sigue siendo accesible. A la inversa, un False Positive puede bloquear a un usuario legítimo; por eso se necesita un proceso documentado de excepciones y revisión.

Comprobar el efecto y continuar supervisando

Después de cada cambio, se repite la misma prueba definida:

1. Un origen externo permitido alcanza VPN Portal y un usuario piloto puede iniciar sesión.
2. Un origen no permitido ya no alcanza el portal.
3. VPN Portal y SSL VPN utilizan una combinación única de puerto y protocolo.
4. Un intento fallido controlado aparece en Log Viewer con la IP de origen y el método de autenticación esperados.
5. Sophos Connect Provisioning, Entra SSO y el propio túnel VPN siguen funcionando.
6. Las coincidencias de Threat Feed aparecen en el log de Active Threat Response si se utiliza esta capa de protección.
7. No se producen bloqueos de cuentas AD o Entra ni inicios de sesión correctos desconocidos.

Para una detección a largo plazo, se envían los logs de autenticación a un SIEM. Las alertas útiles no solo tienen en cuenta el número de errores, sino también muchos orígenes distintos contra el mismo usuario, muchos nombres de usuario desde un origen e inicios de sesión correctos después de una serie de intentos fallidos.

Preguntas frecuentes