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 en Sophos Fusion (inicio de sesión en fusion.sophos.com), 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.

Una zona agrupa interfaces. En una zona personalizada, el acceso a los servicios locales también se puede permitir o bloquear en Network > Zones. Por eso, antes de efectuar un cambio hay que identificar la interfaz de entrada real y su zona. También deben prepararse el objeto de origen preciso, el Interface Host necesario como destino y el puerto real del servicio. Los IP Hosts existentes se encuentran en Hosts and services > IP host; los Interface Hosts se mantienen mediante Network > Interfaces.

Interpretar la matriz predeterminada como punto de partida

Una nueva configuración de SFOS 22 permite de forma predeterminada los servicios locales desde las siguientes zonas. Esta matriz no es un objetivo de hardening: una restauración, una migración, el asistente y los cambios posteriores pueden producir otro estado, y los servicios innecesarios se eliminan después de una prueba positiva y negativa.

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: Solo para administración o soporte y, preferiblemente, con clave pública. Para SSH a través de la red, la vía de inicio de sesión documentada en SFOS 22/23 utiliza la cuenta integrada admin; un permiso de acceso CLI en el perfil no confirma una vía de inicio de sesión SSH para una cuenta de administrador con nombre propio. Solo el administrador predeterminado gestiona la configuración de claves públicas y las propias claves.
• 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.

El diálogo de servicios ofrece además AD SSO, Captive portal, Chromebook SSO, Clients, IPsec, Web proxy y Wireless Protection. Que un servicio se pueda seleccionar no es una recomendación para habilitarlo ampliamente por zonas; cada selección necesita una ruta concreta de cliente, peer o administración. Los campos de búsqueda de Source Network / Host, Destination host y Services también buscan por atributos. Por ejemplo, al introducir 53 se encuentra el servicio DNS.

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.

Además, restrict-admin-console-wan-access puede bloquear globalmente el acceso WebAdmin desde todos los orígenes WAN. Comprobar Advanced Firewall Settings de forma segura explica la lógica enable/disable deliberadamente invertida y su diferencia respecto a Local Service ACL.

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. SFOS no permite crear la excepción ACL cuando Source Network / Host está configurado como Any o la dirección IP de origen es 0.0.0.0. Esta restricción del producto no convierte automáticamente otras redes grandes en seguras. 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 Fusion.

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.
• En SFOS 22/23, TCP 443 está documentado como valor predeterminado de WAF; antes de comprobar posibles conflictos, anote los listeners WAF realmente configurados.
• SSL VPN utiliza TCP 8443 de forma predeterminada; también se puede seleccionar UDP como protocolo.
• 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

Antes del acceso directo a WebAdmin desde WAN: En la Device Console, utilizar primero el comando de solo lectura show advanced-firewall para registrar el valor real de restrict-admin-console-wan-access y el build instalado. En SFOS 22/23, Sophos describe enable como un bloqueo de WebAdmin desde todos los orígenes WAN y como el valor predeterminado; este valor no sustituye al valor anterior registrado. Las instrucciones ACL describen excepciones WAN precisas, pero no aclaran su prioridad frente a esta restricción global. Por tanto, no debe suponerse que la siguiente excepción ACL basta para hacer accesible WebAdmin desde WAN. Con enable, conservar la restricción y utilizar la vía de acceso autorizada y ya probada mediante VPN de administración, red de gestión o Fusion. Si el acceso WAN directo es inevitable y no está claramente establecido cómo interactúan ambos controles en el build instalado, detener el cambio de acceso WAN directo y aclararlo con Sophos Support. Si falla una prueba positiva, comprobar primero este requisito en lugar de ampliar la ACL.

Este ejemplo ACL no indica que deba ponerse el ajuste global en disable. Modificar la restricción global requiere un cambio autorizado por separado, con una vía administrativa independiente que funcione, el valor anterior real documentado, pruebas propias desde orígenes WAN permitidos y bloqueados y la restauración exacta de ese valor anterior al interrumpir el cambio y al finalizar el acceso temporal. No realizar el cambio si no se pueden determinar de forma fiable el valor inicial o la vía de recuperación. El siguiente ejemplo WAN preciso solo se aplica una vez aclarados estos requisitos.

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. Rule position: Para una excepción WAN específica, seleccionar Top y comprobar si existen solapamientos con las demás reglas.
3. Description: Documentar la finalidad, el ticket y la fecha de caducidad prevista.
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

Los valores del ejemplo no deben copiarse sin adaptarlos. Para una red de gestión interna, el mismo patrón podría utilizar Source zone: LAN o una zona de gestión personalizada, Source Network / Host: mgmt-net, el Interface Host de la IP de gestión como Destination host, HTTPS y Accept. Para excluir un origen conocido dentro de una zona que necesita acceso en general, se utiliza una regla separada y colocada en la posición adecuada con el objeto de origen preciso, solo los servicios afectados y Drop. Un grupo de países es, como máximo, un límite de red aproximado, no un sustituto de un origen de administración fijo o una VPN.

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.

Automatización XML: ajuste de zona, no excepción ACL

La documentación XML de zonas de SFOS 22/23 sitúa HTTPS y SSH en Zone/ApplianceAccess/AdminServices/HTTPS y Zone/ApplianceAccess/AdminServices/SSH, respectivamente. Se trata del acceso a servicios locales a nivel de zona: no es una regla de firewall para tráfico de tránsito ni una Local service ACL exception rule para un origen concreto. Modificar esta rama afecta a la accesibilidad de la administración desde la zona; no limita el acceso a una única IP de administración. Para autorizar un origen de forma precisa, la excepción ACL descrita arriba sigue siendo el límite adecuado.

La documentación se contradice respecto a los valores: el ejemplo XML muestra Enable/Disable, mientras que la tabla conjunta de parámetros repite Enable e incluye también 12 y 40. Esto no permite establecer una codificación booleana o numérica fiable. Antes de cualquier escritura automatizada, hay que aclarar la sintaxis para el firmware instalado; esta explicación de la jerarquía no es una plantilla ejecutable para conceder acceso.

Tampoco Zone/MemberPorts es una instrucción de escritura: el comentario del ejemplo XML indica expresamente que los puertos miembros son de solo lectura. La fila CSV opcional de la tabla describe su visualización, no una forma verificada de modificarlos. Antes de cualquier cambio automatizado de zona, pruebe una vía de recuperación independiente con una sesión iniciada y, después, compruebe los orígenes permitidos y bloqueados como se explica en el despliegue de abajo.

Eliminar una zona personalizada de forma segura

Eliminar una Local service ACL exception rule elimina solo esa excepción, no la zona identificada por su nombre. Desactivar un servicio local tampoco elimina una zona. Zonas e interfaces explica las asociaciones.

1. En Network > Zones, identificar el nombre exacto de la zona personalizada que ya no se necesita en producción y documentar su estado anterior. Retired_Test es solo un ejemplo, no un destino de eliminación para copiar. Primero, iniciar sesión y probar la vía administrativa independiente descrita en el despliegue de abajo; no debe depender de esta zona ni de las interfaces o reglas que se van a modificar.
2. En Network > Interfaces, revisar todas las asignaciones a esta zona y, en Rules and policies > Firewall rules, todas las referencias como Source zone o Destination zone. No eliminar interfaces ni reglas necesarias: reasignarlas a la zona restante prevista solo dentro de un cambio autorizado y verificar el efecto. Si deben conservarse referencias o su uso no está claro, conservar la zona y sus dependencias y detener la eliminación. No eliminar en cascada dependencias de producción para forzarla.
3. Solo después de resolver las dependencias, eliminar exclusivamente esa zona identificada por su nombre. La documentación XML de SFOS 22/23 exige Name con un máximo de 60 caracteres: primero A-Za-z1-9 (no 0), después A-Za-z0-9_. Esto no demuestra compatibilidad con comodines ni eliminación automática en cascada; aquí no se prescribe una solicitud XML ni un diálogo de eliminación no respaldado.
4. Después, verificar que solo falta la zona prevista, que las asignaciones de interfaces y reglas de firewall restantes son correctas y que el tráfico de tránsito necesario sigue funcionando. Volver a probar los servicios locales desde orígenes permitidos y bloqueados y la vía administrativa independiente. Si el comportamiento difiere, detenerse y utilizar esa vía para revertir de forma selectiva los cambios documentados, no ampliar permisos.

Los estados XML documentados son 200 (ZoneDeleteSuccess), 500 (ZoneDeleteFailed), 503 (ZoneInterfaceExists) y 504 (ZoneFirewallRuleExists). Ante 503 o 504, revisar las referencias de interfaces o reglas correspondientes en lugar de eliminar indiscriminadamente objetos dependientes. 500 no indica éxito; ni siquiera 200 sustituye la comprobación posterior.

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.

Detalles operativos antes del cambio

Tras una actualización o restauración desde una versión anterior a SFOS 20, VPN Portal hereda el puerto anterior de User Portal, incluido un puerto personalizado. User Portal pasa a 4443 o a 65040 si aquel está ocupado. Compruebe el puerto configurado, no solo el predeterminado, antes de investigar un aparente permiso ACL ausente. Los usuarios o grupos de VPN Portal también deben pertenecer a una política Remote Access adecuada; la accesibilidad no concede por sí sola autorización al usuario.

El listener WAF debe diferenciarse de VPN Portal en la IP WAN o el puerto. Frente a SSL VPN también basta un protocolo distinto: WAF y VPN Portal utilizan TCP, mientras que SSL VPN puede utilizar TCP o UDP. Separar los listeners no equivale a conceder un permiso ACL; repita las pruebas de los servicios afectados después de cada cambio de puerto.

Dynamic Routing permite actualizaciones de routing hacia el firewall, no el tráfico de datos que lo atraviesa. Se habilita para la zona real del peer, no automáticamente para WAN. En el ejemplo WAN con dos firewalls RIP, solo el lado que tiene el acceso habilitado recibe las actualizaciones; el otro las descarta y no aprende las redes anunciadas. Si faltan rutas en un solo lado, compruebe la zona del peer en ambos extremos y después la configuración del protocolo en el artículo de routing enlazado.

El widget Messages de Control center puede advertir del acceso WAN a HTTPS y SSH. Revise los permisos de zona y las excepciones ACL y limite el acceso a una VPN o a hosts y redes concretos. Las alertas no se pueden eliminar manualmente; algunas desaparecen al cumplir su requisito. Su desaparición no sustituye las pruebas positivas y negativas. Las alertas de clave maestra, registro, licencias, informes y firmware pertenecen a sus procesos operativos respectivos, no a una regla ACL adicional.

Desplegar los cambios sin perder el acceso

Los cambios de Device Access surten efecto de inmediato.

La vía de recuperación debe seguir funcionando tras el cambio de zona o puerto previsto. Una segunda pestaña que utilice la misma vía bloqueada no es independiente. Antes de empezar, anote los ajustes anteriores exactos y quién dispone de acceso a la consola; sin una vía de recuperación funcional no se realiza el cambio remoto. 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 Fusion.
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 falla el acceso permitido, utilice la vía independiente para devolver el último ajuste modificado a su valor anterior documentado y vuelva a probar el acceso. Si un origen bloqueado sigue llegando al servicio, no amplíe los permisos: investigue el proxy, Port Sharing y las reglas ACL solapadas y restrinja la vía no deseada sin perder el acceso de recuperación. Repita ambas pruebas solo después de corregir el problema.

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.

El permiso de acceso CLI no equivale a poder iniciar sesión por SSH: Según la descripción del perfil para SFOS 22/23, Administrator concede acceso completo a la CLI sin especificar el transporte. En cambio, la guía de PuTTY para esas mismas versiones exige el nombre de usuario admin para SSH a través de la red y excluye otros nombres de usuario; esto también se aplica al inicio de sesión con contraseña. De ello no se deduce aquí que las cuentas de administrador con nombre propio puedan acceder por SSH, ni se formula una afirmación general sobre todas las vías de acceso CLI. La función Console de WebAdmin abre una consola en el navegador a través del acceso a WebAdmin y no demuestra que sea posible iniciar sesión por SSH a través de la red. Debe comprobarse por separado si una cuenta concreta con nombre propio puede utilizar ese acceso desde el navegador, en función de sus permisos y del firmware instalado. La gestión de claves, permitida únicamente al administrador predeterminado, también es un permiso independiente y no determina qué cuentas pueden iniciar sesión por SSH con contraseña.

Comprobar la vía de recuperación real antes de modificar una ACL: Para la vía documentada de SSH a través de la red, utilizar la cuenta integrada admin con sus credenciales actuales o con una clave configurada para ella. Iniciar sesión mediante la vía elegida en una sesión nueva, abrir la consola necesaria y registrar la cuenta, el transporte y la versión del firmware en el registro del cambio; que un puerto TCP sea accesible no basta. Un acceso funcional a Console desde el navegador sigue dependiendo de la vía de acceso a WebAdmin y no constituye una vía de recuperación independiente si esta se bloquea. Si se necesita una cuenta con nombre propio como vía de recuperación por SSH o si el comportamiento observado contradice la guía, detener el cambio, conservar un acceso autorizado ya probado y aclarar con Sophos Support el alcance exacto en cuanto a cuentas y transportes. No ampliar la ACL ni recurrir a intentos repetidos de inicio de sesión como sustituto de esa aclaración.

Elimine una excepción caducada en Administration > Device access > Local service ACL exception rule mediante Delete en la regla correspondiente y confirme con OK. Antes, pruebe la vía administrativa que debe conservarse; después, compruebe que el antiguo origen de soporte ya no puede conectarse. Una fecha de caducidad anotada aquí es una obligación de revisión, no una prueba de eliminación automática.

Solución de problemas

Si un inicio de sesión deja de ser accesible de repente, compruebe también Administration > Admin and user settings > Login security > Block login. Este bloqueo por IP de origen depende de los intentos fallidos y puede afectar a WebAdmin, CLI, VPN Portal y User Portal. No es una regla ACL. Los intentos CAPTCHA fallidos no cuentan como esos intentos de inicio de sesión. Revise la duración configurada del bloqueo y los eventos en lugar de habilitar HTTPS para toda una zona o desactivar la protección de forma indiscriminada.

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.

Matices de las fuentes

STAS proporciona autenticación de usuarios; no es una VPN ni un transporte administrativo cifrado. El permiso para su servicio de autenticación no sustituye una vía de administración protegida.

Las instrucciones conservadas sobre claves SSH de SFOS 22/23 son ambiguas: especifican RSA/DSA con al menos 2048 bits y enumeran ECDSA excluyendo ED25519. No deduzca compatibilidad con ED25519 ni considere DSA una recomendación. Antes de registrar la clave, confirme el algoritmo compatible con el firmware real; cargue solo la clave pública y conserve una vía de recuperación independiente. Un permiso de Device Access no valida un algoritmo de clave.

Adaptive Learning también incluye URL de virus detectados, nombres/URL/direcciones IP de amenazas, direcciones IP de origen y aplicaciones utilizadas. El envío HTTPS predeterminado abarca datos del dispositivo, firmware y licencias (sin información del propietario), estado de funciones/HA/gestión en la nube, cantidades de objetos, errores y porcentajes de uso de CPU/memoria/disco. Trátelo como una decisión sobre divulgación de datos, no como un control ACL. Sophos Assistant está activado de forma predeterminada; para desactivarlo, desmarque Turn on Sophos Assistant en Administration > Admin and user settings, pulse Apply y cierre la sesión para volver a iniciarla. Esto no desactiva la telemetría.

FAQ