Sophos Firewall: Device Access y Local Service ACL

En Administration > Device access se define desde qué zonas se puede acceder a los servicios locales de Sophos Firewall. Entre ellos se encuentran HTTPS para WebAdmin y la API, SSH, Ping, DNS, SNMP, SSL VPN, User Portal y VPN Portal.

Estos servicios terminan directamente en el firewall y conforman su superficie de administración y servicios. Si una autorización es demasiado amplia, bots, clientes internos comprometidos o atacantes externos pueden acceder directamente a las páginas de inicio de sesión, la API y SSH para probar credenciales, vulnerabilidades conocidas o configuraciones erróneas. MFA y las contraseñas seguras siguen siendo importantes, pero no limitan quién puede alcanzar estos servicios: Device Access reduce la superficie de ataque antes del inicio de sesión y, por ello, es una de las primeras medidas de hardening.

La fuente de identidad se mantiene separada. Si WebAdmin debe utilizar credenciales TACACS+ centrales, TACACS+ para administradores de Sophos Firewall explica la conexión del servidor, la asignación local de perfiles, el inicio de sesión piloto y el fallback; la accesibilidad HTTPS se sigue limitando aquí.

Lo decisivo es el destino de la conexión:

• Tabla de zonas de Device Access: Permite de forma general un servicio local del firewall desde una zona.
• Local service ACL exception rule: Permite o bloquea un servicio local para orígenes, destinos y servicios concretos.
• Regla de firewall: Controla el tráfico a través del firewall, por ejemplo desde LAN hasta un servidor en DMZ.

Por ejemplo, al abrir https://172.16.16.16:4444, la conexión termina en el firewall. Por eso, una regla de firewall normal no sustituye una habilitación de Device Access.

⚠️ WebAdmin, SSH y los portales solo deberían ser accesibles desde las redes que realmente los necesitan. Para la administración externa, una VPN de administración, Sophos Central Firewall Management, una red de gestión o una excepción ACL precisa son más seguras que una habilitación amplia desde WAN.

Dos casos especiales pueden eludir la tabla de zonas para servicios HTTP y HTTPS:

• Web Proxy: Las solicitudes realizadas a través del Web Proxy se consideran internas y no se pueden controlar por zona de origen mediante Device Access. Quien tenga permiso para utilizar el proxy puede acceder a WebAdmin, Captive Portal, VPN Portal y User Portal aunque el servicio esté desactivado para su propia zona.
• Port Sharing: Si VPN Portal y SSL VPN utilizan el mismo puerto y el mismo protocolo, VPN Portal queda accesible desde todas las zonas de acceso de SSL VPN. Además, los ajustes de Login security dejan de aplicarse.

Estas dos rutas deben probarse por separado durante la validación. El artículo general Hardening de Sophos Firewall sitúa Device Access dentro del endurecimiento completo del sistema.

Planificar zonas y servicios locales

La tabla de zonas es adecuada para permisos básicos claros, como DNS desde LAN, Ping desde una zona de monitorización o HTTPS desde una red de gestión. Si solo necesitan acceso una dirección IP o una red pequeña, una ACL Exception Rule es más precisa.

Decisiones habituales:

• HTTPS: Permitir WebAdmin y la API solo desde redes de gestión u orígenes de administración definidos de forma precisa.
• SSH: Permitirlo únicamente para administración o soporte y, si es posible, con clave pública. Los administradores con el perfil Administrator pueden obtener acceso CLI; solo el administrador predeterminado gestiona la configuración y las claves públicas.
• DNS: Permitirlo solo para zonas de clientes internas que utilicen el firewall como resolver DNS. DNS desde WAN no es un caso normal de cliente.
• Ping/Ping6: Permitirlo para la monitorización necesaria, no de forma general desde zonas no fiables.
• SNMP: Permitirlo solo desde el sistema o la red de monitorización; la configuración se describe en Monitorización de hardware mediante SNMP.
• RADIUS SSO: Solo desde el remitente de accounting fijo. RADIUS SSO con accounting explica la asociación de la IP del cliente y el usuario.
• SSL VPN: Exponerlo al exterior solo en la medida necesaria, con MFA, registro y un puerto y protocolo elegidos de forma consciente.
• VPN Portal: Desde SFOS 20 proporciona Sophos Connect y configuraciones de IPsec y SSL VPN.
• User Portal: Entre otras funciones, permite acceder a datos personales, tokens OTP, cuarentena, excepciones y Policy Overrides, pero no descargar la configuración VPN.
• RED, SMTP Relay y Dynamic Routing: Permitirlos solo en las redes previstas o para los pares definidos. Configurar PIM-SM en Sophos Firewall muestra cómo comprobar este límite para los vecinos multicast; para dominios de routing IPv4 pequeños, configurar RIPv2 en Sophos Firewall explica la autorización separada de la zona del peer y del tráfico de datos.

Desde SFOS 22, WebAdmin, VPN Portal y User Portal admiten TLS 1.3. Sin embargo, un cifrado seguro no reduce la superficie de ataque de un servicio accesible sin necesidad.

Device Access solo determina desde qué red se puede acceder a la consola WebAdmin. Si el inicio de sesión debe utilizar Microsoft Entra ID, Entra ID SSO para WebAdmin de Sophos Firewall explica la asignación independiente de roles y grupos de Entra a perfiles locales de administrador.

Limitar los orígenes de forma precisa

Una ACL Exception Rule admite como origen Country, Country group, FQDN host/group, Host group, IP address/list/range, MAC address/list y Network. No se admiten FQDN comodín.

No se debe permitir WebAdmin desde WAN para todos los orígenes. Una IP fija de administración, una red de gestión pequeña o un objeto FQDN mantenido son considerablemente más seguros. Para usuarios móviles cuyas direcciones de origen cambian, el acceso administrativo debería realizarse mediante VPN o Sophos Central.

Desde SFOS 19.5 MR2, las habilitaciones amplias desde WAN para WebAdmin y User Portal se desactivan automáticamente tras 90 días consecutivos sin un inicio de sesión correcto. Esto no afecta a los orígenes WAN específicos de las ACL Exception Rules, que deben seguir revisándose periódicamente. El Sophos Firewall Health Check ayuda a revisar regularmente los accesos de gestión, MFA y la configuración.

Comprobar Web Proxy y Port Sharing de antemano

Antes de aplicar el hardening, deben anotarse los puertos y protocolos utilizados en Administration > Admin and user settings y en SSL VPN global settings.

• WebAdmin utiliza de forma predeterminada TCP 4444, User Portal TCP 4443 y VPN Portal TCP 443.
• SSL VPN utiliza de forma predeterminada TCP o UDP 8443.
• WebAdmin y User Portal no pueden compartir su puerto con otros servicios.
• VPN Portal y SSL VPN no deberían utilizar el mismo puerto y protocolo, ya que las restricciones de zona y Login Security dejarían de funcionar como se espera.

Si el Web Proxy está activo, una prueba sin proxy no es suficiente. La misma solicitud a un portal o a WebAdmin debe probarse también mediante el proxy explícito desde una zona que debería estar bloqueada.

Configurar Direct Web Proxy con un archivo PAC explica cómo limitar el listener proxy a un cliente piloto y validar esta exposición de forma controlada.

Crear una Local Service ACL Exception Rule precisa

Una excepción típica permite WebAdmin desde WAN únicamente para una IP fija de soporte. La ruta de menú es Administration > Device access > Local service ACL exception rule > Add.

1. Rule name: admin-https-from-support-ip
2. Description: Documentar la finalidad, el ticket y la fecha de caducidad prevista.
3. Rule position: Para una excepción WAN específica, seleccionar Top y comprobar si existen solapamientos con las demás reglas.
4. IP version: Seleccionar la versión que corresponda al origen, normalmente IPv4.
5. Source zone: WAN
6. Source Network / Host: Seleccionar una IP de administración concreta o un objeto preciso y mantenido.
7. Destination host: Limitarlo a la dirección o interfaz necesaria del firewall. Any amplía las direcciones o interfaces de destino accesibles, no los servicios seleccionados en Services.
8. Services: Seleccionar solo HTTPS; no añadir SSH por comodidad.
9. Action: Accept

A continuación, se guarda la regla y se realizan pruebas desde un origen permitido y otro no permitido. La posición de la regla es importante: las reglas superiores pueden influir en el resultado. Si existen reglas solapadas, debe comprobarse el efecto real en el firewall en lugar de deducirlo únicamente de la lista.

Acceso API

Para el acceso API deben cumplirse tres condiciones:

1. La API está activada en Administration > API access.
2. La dirección de origen está incluida en Allowed IP hosts.
3. Device Access permite HTTPS desde la zona correspondiente o mediante una excepción ACL adecuada.

Desde SFOS 22, la configuración de la API se encuentra en Administration y admite objetos de host IP para direcciones, rangos y redes. Se pueden utilizar hasta 64 objetos. No es necesaria una habilitación amplia de HTTPS. La configuración completa se describe en Limitar de forma segura el acceso API de Sophos Firewall.

DNS desde WAN

Una excepción ACL para DNS desde WAN no hace por sí sola que el firewall responda allí a consultas DNS. Además, habría que configurar un host DNS estático con Publish on WAN en Network > DNS. Esto solo debería hacerse para un caso de uso autoritativo concreto; el firewall no debe convertirse en un resolver recursivo público. Configurar y probar DNS Host Entries en Sophos Firewall explica la delegación, la DNS Host Entry y las pruebas positivas y negativas.

Desplegar los cambios sin perder el acceso

Los cambios de Device Access surten efecto de inmediato. Para trabajos remotos, debe haberse iniciado y probado una sesión a través de la segunda vía de administración antes del cambio.

1. Documentar los permisos de zona, excepciones ACL, puertos y servicios necesarios actuales.
2. Abrir una vía de acceso independiente, por ejemplo la consola local, la LAN de gestión, una VPN de administración o Sophos Central.
3. Para cambios de mayor alcance, disponer de una copia de seguridad actual y del Secure Storage Master Key.
4. Crear la nueva excepción Accept precisa sin eliminar todavía la habilitación amplia existente.
5. Probar el acceso permitido como referencia. Mientras la habilitación amplia de zona siga activa, esta prueba todavía no demuestra que la nueva excepción esté surtiendo efecto.
6. En Diagnostics > Packet capture, establecer un filtro preciso para el origen, el destino y el puerto, y activar Trace On.
7. Eliminar la antigua habilitación amplia de zona mediante la vía de administración independiente.
8. Realizar inmediatamente una prueba funcional del servicio desde el origen permitido. Una conexión TCP/TLS o al servicio correcta y, normalmente, Status: Consumed confirman el caso positivo; no es necesario que aparezca Reason: LOCAL_ACL.
9. Probar el mismo servicio desde un origen no permitido. Para el intento bloqueado, normalmente se esperan Status: Violation y Reason: LOCAL_ACL.
10. Para HTTP/HTTPS, probar también la ruta del Web Proxy; para los portales, comprobar las zonas de acceso de SSL VPN.
11. Detener Packet Capture y comprobar los eventos complementarios de servicio o inicio de sesión en Log viewer. El ID de regla que muestra Packet Capture es el ID de la regla de firewall, no el ID de la ACL Exception Rule, y puede ser 0 para el tráfico local.
12. Documentar la regla, finalidad, responsable, ticket, origen, servicio y fecha de revisión o caducidad.

Interrupción y reversión: Si el origen permitido no funciona después de eliminar la habilitación amplia o un origen bloqueado sigue llegando al servicio, debe restablecerse inmediatamente la habilitación amplia mediante la vía de administración independiente. Después se corrige la regla ACL nueva o conflictiva y se repite el proceso.

Unos ejemplos compactos de documentación facilitan las revisiones posteriores:

• HTTPS: Regla admin-https-from-mgmt, origen mgmt-net, finalidad WebAdmin, revisión trimestral.
• SSH: Origen support-ip-temporary, finalidad caso de soporte, eliminar al cerrar el ticket.
• SNMP: Origen monitoring-server, finalidad monitorización de hardware e interfaces, revisión semestral.
• SSL VPN: Origen WAN, finalidad Remote Access, revisar los logs mensualmente.

Si hay varios firewalls o un clúster HA, primero debería modificarse un sistema con buenas opciones de reversión. La guía Configurar High Availability en Sophos Firewall aborda los cambios de rol y el acceso de mantenimiento.

Casos especiales y protección adicional

User Portal, VPN Portal y SSL VPN

Primero debe determinarse qué portal se necesita realmente. Los clientes y las configuraciones VPN corresponden a VPN Portal; User Portal ofrece otras funciones para los usuarios. Comparativa de los portales de Sophos Firewall ofrece una visión general.

Si un servicio Remote Access debe estar disponible en todo el mundo, MFA, los grupos de usuarios restrictivos y el registro son más importantes que una restricción por países poco adecuada. La configuración se describe en MFA para WebAdmin, VPN Portal y Remote Access. Aun así, debe evitarse Port Sharing: la autenticación no sustituye un control correcto de la accesibilidad.

Los inicios de sesión de WebAdmin, User Portal, VPN Portal y SSL VPN accesibles públicamente son detectados rápidamente por escáneres y bots. Incluso con MFA, esto genera tráfico de fuerza bruta, ruido en los logs y carga adicional.

Si ya se producen muchos intentos fallidos de inicio de sesión en VPN Portal o bloqueos de cuentas, Proteger el VPN Portal de Sophos Firewall contra ataques de fuerza bruta combina la revisión de logs, el control de identidad, la contención mediante ACL y la comprobación posterior en un flujo de respuesta a incidentes.

Si un portal debe seguir accesible desde todo el mundo, Sophos Firewall Threat Feeds con la acción Block puede bloquear además orígenes IPv4 maliciosos conocidos procedentes de Third-Party Feeds como Cybora, incluso en el tráfico dirigido al propio firewall. Los IoC de dominio o URL no protegen un inicio de sesión frente a una IP de origen maliciosa; actualmente no se admiten orígenes IPv6. Por tanto, los Threat Feeds son una protección adicional y no sustituyen unas ACL precisas. El artículo enlazado explica la configuración, las pruebas y el allowlisting.

SSH y reglas temporales de soporte

SSH solo debería ser accesible cuando sea necesario desde una red de gestión, mediante VPN o para una IP fija de soporte. Es preferible utilizar autenticación con clave pública. La excepción ACL temporal se elimina después del caso de soporte; no debe presuponerse un estado de desactivación que no se haya confirmado en la interfaz actual. Los pasos adicionales se describen en Conectarse a Sophos Firewall mediante SSH.

Solución de problemas

Si un servicio local no está accesible o bloqueado como se esperaba, deben comprobarse los siguientes puntos en este orden:

1. Destino y puerto: ¿La IP del firewall es correcta y el servicio utiliza el puerto esperado?
2. Zona de origen: ¿El cliente se conecta directamente desde la zona prevista, mediante una VPN o a través del Web Proxy?
3. Tabla de zonas: ¿Está permitido el servicio para esa zona en Administration > Device access?
4. Excepciones ACL: ¿Coinciden IP version, Source zone, el objeto de origen, Destination host, Service, Action y la posición?
5. Port Sharing: ¿VPN Portal y SSL VPN comparten puerto y protocolo?
6. API: ¿Coinciden la activación de la API, Allowed IP hosts y HTTPS Device Access?
7. DNS: ¿Está permitido DNS para los clientes internos? La publicación en WAN requiere además Publish on WAN.
8. Logs: ¿Muestra Log Viewer eventos complementarios de servicio o inicio de sesión?
9. Packet Capture: Iniciar el trace antes de repetir la prueba. El acceso permitido debe funcionar y normalmente muestra Status: Consumed; el intento bloqueado suele mostrar Status: Violation y Reason: LOCAL_ACL. El ID de regla no es el ID de la excepción ACL. El funcionamiento se explica en Packet Capture de Sophos Firewall.

Si WebAdmin o un portal siguen accesibles aunque la zona de origen esté desactivada, primero deben probarse Web Proxy y Port Sharing. Una regla de firewall adicional no resuelve este problema.

Para la trazabilidad a largo plazo pueden utilizarse Central Firewall Reporting o Enviar syslog de Sophos Firewall a un SIEM.

Lista de comprobación operativa

• WebAdmin no está accesible de forma general desde WAN ni desde zonas de invitados, IoT o VoIP.
• HTTPS, SSH y SNMP están limitados a orígenes concretos de gestión o monitorización.
• User Portal, VPN Portal y SSL VPN solo están activos si el modelo operativo los necesita.
• VPN Portal y SSL VPN no comparten el mismo puerto y protocolo.
• El acceso mediante Web Proxy a servicios HTTP/HTTPS locales se ha probado por separado.
• API access, Allowed IP hosts y HTTPS Device Access están coordinados.
• Las excepciones ACL temporales incluyen una finalidad y una fecha de caducidad y se eliminan al finalizar.
• Se han probado orígenes permitidos y bloqueados; los logs confirman el resultado.
• Las reglas se revisan periódicamente para detectar orígenes obsoletos, servicios innecesarios y excepciones Accept demasiado amplias.

FAQ