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.

Antes de cada cambio, se anotan los ajustes actuales o se guarda una copia de la configuración. Esto incluye la selección WAN de VPN portal, todos los campos y el orden de las excepciones Local Service ACL, el estado y los tres valores de Block login, los puertos y protocolos de VPN Portal y SSL VPN y la selección y orden de los servidores de autenticación. Para Provisioning o Entra SSO, también se guardan vpn_portal_port, la URL del portal y la Redirect URI. Para Threat Feeds modificados se conservan URL, tipo de indicador, action, estado y opciones personalizadas. La reversión restaura estos valores, no supuestos valores predeterminados.

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. No todos aparecen como columnas estándar en cada vista; Detailed view y las columnas adicionales muestran los datos disponibles para el evento. Si falta contexto, se revisan después los logs sin procesar y los del Identity Provider. En un SIEM se filtra log_component por VPN Portal Authentication y status por Failed; la sintaxis depende del SIEM.

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. Rule 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.

Tras guardar, se prueba primero la excepción desde un origen externo permitido. Mediante la segunda vía de administración verificada se elimina la habilitación general WAN de VPN portal en Device Access y se guarda. Los cambios se aplican de inmediato. El origen permitido debe seguir llegando al portal y uno no permitido ya no debe hacerlo. Si falla la prueba positiva, se restaura la habilitación WAN anterior desde la segunda vía. La guía de Device Access describe otras variantes.

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.

El proxy web configurado en el firewall es una excepción importante. SFOS trata sus solicitudes HTTP y HTTPS como internas, no como tráfico de una zona. Un usuario con acceso al proxy puede alcanzar VPN Portal y otros servicios HTTP del firewall aunque Device Access los desactive para su zona. Si se usa el proxy, la prueba negativa se realiza una vez directamente y otra de forma verificable mediante el proxy explícito o transparente. Device Access no puede bloquear por zona esta ruta interna; si no se desea, debe limitarse el acceso al propio proxy.

Configurar correctamente Login Security y los puertos

En Administration > Admin and user settings > Login security, se activa Block login y se completan los tres campos de número de intentos, intervalo y duración del bloqueo. Cinco fallos en 60 segundos y cinco minutos de bloqueo son solo un ejemplo, no un valor predeterminado universal de Sophos ni un valor de producción que deba adoptarse sin piloto. Se eligen según usuarios, helpdesk y NAT compartidos. La prueba se ejecuta desde una IP controlada manteniendo abierta la segunda vía administrativa.

El bloqueo funciona por IP de origen y se aplica a todos los servicios al alcanzar el umbral, incluidos WebAdmin, CLI, VPN Portal y User Portal. Detrás del NAT de una oficina, hotel o proveedor puede afectar a varios usuarios y un administrador a la vez. Nunca se realiza la prueba negativa por la única vía administrativa disponible.

En un ataque distribuido, Block login es solo una capa de protección. Muchos bots pueden permanecer individualmente por debajo del umbral. Los fallos de CAPTCHA no cuentan como inicios de sesión fallidos ni activan el bloqueo.

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 necesarios. Una vía local, AD, LDAP o RADIUS sin uso permite intentos innecesarios contra otro directorio. Debe quedar al menos un servidor seleccionado. VPN Portal no admite RADIUS con challenge-based MFA, por lo que no debe planificarse como MFA del portal.

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 de WAN si ningún proceso necesario depende de él. El Provisioning .pro se conecta mediante vpn_portal_port. Con Entra SSO, la URL usada por VPN Portal y Remote Access y la Redirect URI registrada deben coincidir con gateway y puerto publicados. Los .ovpn distribuidos manualmente pueden permitir una publicación más restringida, pero los cambios de perfil requieren distribución y pruebas controladas.

Añadir Threat Feeds contra orígenes conocidos

Sophos Firewall también puede comparar IP de origen maliciosas conocidas en tráfico hacia sus propios servicios, incluidos VPN Portal, WebAdmin y VPN. Según la ayuda de SFOS 22, se aplica a MDR, NDR Essentials y Third-Party Threat Feeds, pero no a Sophos X-Ops Threat Feeds. Un Third-Party Feed IPv4 mantenido sirve así como capa adicional para fuentes conocidas.

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 aparezcan localmente en Log Viewer, se activa Local reporting para Active threat response en System services > Log settings. XGS 87/87w y 107/107w no admiten reporting local; se usa Sophos Central o un servidor Syslog.

Los Threat Feeds no sustituyen una ACL ni una autenticación sólida. Solo comparan direcciones listadas. Los Third-Party Feeds aceptan IPv4 individuales, no IPv6, rangos IP ni direcciones de red; una IP de bot nueva sigue siendo accesible. Un False Positive puede bloquear a usuarios legítimos. Un feed nuevo empieza en Monitor; se revisan errores y coincidencias inesperadas antes de pasar a Block. Una Threat Exclusion afecta a todos los módulos Active Threat Response, por lo que debe ser limitada, justificada y temporal. Las coincidencias y excepciones se revisan regularmente.

Para revertir, se devuelve un feed modificado a su action anterior; un feed nuevo se desactiva, pero no se elimina sin revisión. Después se comprueba que una fuente afectada por un False Positive vuelve a alcanzar el portal y que las demás protecciones siguen funcionando.

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 destino de logs configurado si se usa esta protección.
7. No aparecen nuevos bloqueos AD o Entra ni accesos correctos desconocidos durante el periodo definido.

Si una prueba falla, primero se restaura solo el último cambio a su valor anterior documentado. Puede ser la action del feed, un servidor, Block login, puerto y Redirect URI o Device Access. Para Device Access se restaura primero la antigua habilitación WAN mediante la segunda vía y luego se elimina la nueva excepción ACL. Para el puerto se restauran juntos puerto y protocolo, .pro, URL del portal y Redirect URI, y se repiten las pruebas permitida y denegada.

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