Asegurar Sophos Firewall con Device Access

En Administration > Device access se define desde qué zonas son accesibles los servicios locales de Sophos Firewall. Esto incluye, por ejemplo, HTTPS para la WebAdmin Console, SSH para la CLI, Ping, DNS, User Portal, VPN Portal y otros servicios.

Para el contexto general de hardening, sirve el hub Sophos Firewall Hardening: buenas prácticas para una configuración segura.

Esta área es crítica para la seguridad. Las reglas normales de firewall controlan el tráfico a través del firewall. Device access controla el tráfico hacia el propio firewall. Si WebAdmin o SSH son accesibles desde una zona no segura, se obtiene acceso directo de gestión al dispositivo de seguridad.

También es importante la API: la habilitación de Device Access para HTTPS/WebAdmin también afecta al acceso API. Desde SFOS 22, las fuentes de acceso API se gestionan adicionalmente en Administration > API access, pero un host API permitido no ayuda si Device Access bloquea el acceso HTTPS local desde esa zona.

⚠️ WebAdmin, SSH y los portales solo deberían ser accesibles desde redes de confianza. Para entornos productivos, es mejor restringir el acceso a una red de gestión, una IP fija de administrador, VPN o Sophos Central Firewall Management.

En la práctica, esta separación ayuda:

• Tabla de zonas de Device Access: permitir o bloquear un servicio de forma general por zona, por ejemplo DNS para LAN, Ping para una zona de monitorización o SSL VPN para una zona de Remote Access necesaria.
• Local Service ACL Exception Rule: controlar el acceso con más precisión por origen, destino y servicio, por ejemplo WebAdmin solo desde la red de gestión, SSH solo desde una IP de soporte o SNMP solo desde el sistema de monitorización.
• Regla de firewall normal: permitir o bloquear tráfico a través del firewall, por ejemplo cuando un cliente de LAN accede a un servidor en DMZ o a un servicio de internet.

Así queda claro: una regla de firewall no sustituye al endurecimiento de Device Access. Si HTTPS o SSH está accesible de forma demasiado amplia mediante Device Access, un cliente llega al servicio local del firewall antes de que una regla clásica de tránsito sea siquiera el punto de comprobación adecuado.

Por qué Device Access no funciona como una regla de firewall

Una regla típica de firewall permite o bloquea conexiones entre zonas, por ejemplo, de LAN a WAN o de VPN a Server. Device Access es diferente: se trata de servicios que se ejecutan directamente en Sophos Firewall.

Ejemplos:

• Un administrador abre https://172.16.16.16:4444.
• Un cliente utiliza el firewall como servidor DNS.
• Un sistema de monitoreo hace ping al firewall.
• Un usuario abre el User Portal o VPN Portal.
• Un administrador se conecta por SSH al firewall.

Este tipo de tráfico no tiene como destino un servidor detrás del firewall, sino el propio firewall. Por eso se controla a través de la ACL de servicio local.

Esta es también la razón por la que Device Access es parte del endurecimiento básico de cualquier Sophos Firewall. Un conjunto de reglas limpio de LAN a WAN no protege automáticamente los servicios de gestión y portal del propio firewall. Estos servicios deben ser revisados y restringidos conscientemente por separado.

Comprender las autorizaciones de zona

En la parte superior de Administration > Device access se ve una tabla con zonas y servicios. Si un servicio está activado para una zona, se permite el acceso a ese servicio local desde esa zona.

La tabla de zonas es práctica, pero general y adecuada para zonas internas claras, como LAN, Management o VPN. Cuando un servicio solo debe ser accesible para direcciones IP de administrador individuales, ubicaciones, países u objetivos de soporte, las Local service ACL exception rules son la mejor opción.

En Custom Zones también se deben revisar los ajustes de zona. Los servicios locales pueden verse influidos allí igualmente. Aun así, Administration > Device access sigue siendo el lugar central donde se habilitan o restringen conscientemente los servicios locales del firewall.

Ejemplos típicos:

• HTTPS: acceso a WebAdmin desde la red de gestión. No permitir ampliamente desde WAN.
• SSH: acceso CLI para administradores o soporte. Permitir solo de forma específica, preferiblemente con Public Key.
• Ping/Ping6: monitoring y pruebas simples de accesibilidad. No activar innecesariamente desde zonas no seguras.
• DNS: los clientes usan el firewall como resolvedor DNS. Activar solo para zonas internas de clientes.
• SSL VPN: usuarios de SSL VPN establecen una conexión con el firewall. Abrir externamente solo lo necesario y proteger con MFA; revisar el puerto por separado en el área de Remote Access.
• User Portal: los usuarios descargan configuraciones VPN o tokens. Externamente, preferiblemente vía VPN/ZTNA o con limitación estrecha.
• VPN Portal: usuarios de Remote-Access-VPN. Solo si realmente es necesario y protegido con MFA.
• RED: RED Appliances se conectan al firewall. Permitir solo para ubicaciones RED reales o fuentes definidas.
• SMTP Relay: sistemas internos usan el firewall como SMTP Relay. No liberar como relay abierto desde zonas no seguras.
• SNMP: el monitoring consulta valores del firewall. Permitir solo desde el sistema de monitoring; los detalles están en Monitoreo de hardware SNMP.
• Dynamic Routing: protocolos de routing entre routers y firewall. Activar solo en segmentos de red previstos para ello.

En SFOS 22, WebAdmin, VPN Portal y User Portal soportan TLS 1.3. Esto es bueno para el cifrado, pero no cambia el principio básico: un servicio accesible desde demasiadas fuentes sigue siendo una superficie de ataque innecesaria. El cifrado de transporte no sustituye una ACL limpia.

¿Qué servicios se pueden restringir mediante reglas ACL?

A través de Local Service ACL y ACL Exception Rules, se pueden controlar muy finamente los servicios locales del firewall. Estos servicios son especialmente relevantes:

• DNS: el firewall responde a consultas DNS desde redes que no debería atender.
• Dynamic Routing: los protocolos de routing son accesibles desde segmentos incorrectos.
• HTTPS: la WebAdmin Console es accesible desde demasiadas fuentes.
• Ping/Ping6: el firewall es innecesariamente visible y escaneable.
• RED: los servicios RED son accesibles desde rangos de origen demasiado amplios.
• SMTP Relay: las configuraciones incorrectas pueden favorecer el abuso de relay.
• SNMP: los datos de monitoring son consultables desde redes incorrectas.
• SSH: el acceso CLI directo al firewall está demasiado abierto.
• SSL VPN: los puntos de login VPN son accesibles mundialmente y son escaneados.
• User Portal: login del portal y descargas VPN están innecesariamente expuestos.
• VPN Portal: el portal de Remote Access es objetivo de bots e intentos de fuerza bruta.

Cuantos más de estos servicios sean accesibles desde WAN, redes de invitados, redes IoT o zonas mal definidas, mayor será la superficie de ataque. El objetivo no es desactivar todo, sino hacer que cada servicio sea accesible solo donde realmente se necesita.

Definir las fuentes de acceso lo más estrechamente posible

Una regla ACL no tiene que permitir simplemente Any. Como fuente, se puede trabajar de manera muy precisa, por ejemplo, con:

• direcciones IP de administrador individuales
• redes de gestión
• rangos de IP
• listas de IP
• hosts FQDN
• grupos de hosts FQDN
• hosts DNS o grupos DNS
• objetos de país o grupos de países
• redes VPN o de soporte dedicadas

Esto permite limitar mucho mejor un acceso. Un ejemplo: si un servicio de soporte externo solo proviene de un FQDN fijo o un rango de IP definido, no debería permitir que toda la zona WAN tenga acceso a HTTPS o SSH. Si un sistema de monitoreo necesita SNMP, no debería permitirse que toda una red de servidores consulte SNMP en el firewall.

En escenarios de acceso remoto global, la delimitación es más difícil. Algunas empresas no pueden permitir SSL VPN o VPN Portal solo para Suiza, Alemania o un solo país, porque los empleados están en movimiento por todo el mundo. En tales casos, se debe trabajar adicionalmente con MFA, registros, configuraciones restrictivas de portal y Threat Feeds.

Modelo de decisión para servicios locales

Para cada servicio local, se debe decidir conscientemente qué nivel de acceso es adecuado. Rara vez es sensato tratar WebAdmin, SSH, User Portal, VPN Portal, DNS y SNMP de la misma manera.

• Desactivado: adecuado si el servicio no se necesita en el entorno. Ejemplo: SSH desactivado permanentemente si no se prevé acceso CLI.
• Solo zona interna: adecuado si el servicio lo necesitan muchos clientes internos. Ejemplo: DNS desde LAN, si los clientes usan el firewall como resolvedor DNS.
• Red de gestión: adecuado para servicios administrativos o relacionados con monitoring. Ejemplo: HTTPS, SSH y SNMP solo desde Management.
• Admin-VPN: adecuado si los administradores deben trabajar externamente, pero no directamente desde Internet. Ejemplo: WebAdmin solo accesible vía VPN.
• ACL Exception Rule: adecuado si el acceso debe provenir de una fuente muy concreta. Ejemplo: una IP de soporte puede acceder temporalmente a HTTPS o SSH.
• WAN ampliamente accesible: solo para servicios reales de Remote Access y con protección adicional. Ejemplo: SSL VPN para usuarios móviles con MFA, logging y Threat Feeds.

Esta decisión debe documentarse. Especialmente en el caso de excepciones desde WAN, debe ser posible rastrear más tarde por qué el servicio es accesible, quién lo necesita y cuándo se revisará nuevamente la excepción.

El acceso desde WAN es una excepción

WAN no es simplemente otra zona. Todo lo que es accesible desde WAN es encontrado por escáneres, bots y herramientas de fuerza bruta. Por eso, WebAdmin desde WAN no debería planificarse como una variante operativa normal.

Si se necesita acceso de gestión externo, estas variantes suelen ser más seguras:

• Sophos Central Firewall Management para tareas administrativas.
• Admin-VPN con MFA y un grupo de usuarios claro.
• Una regla de excepción ACL temporal para una IP de origen fija.
• Una red de gestión dedicada a través de VPN de sitio a sitio.

Para la imagen general de endurecimiento, también es adecuado Utilizar correctamente el Sophos Firewall Health Check, ya que allí se evalúan conjuntamente los accesos de gestión, MFA, copias de seguridad e higiene de reglas.

Sophos protege adicionalmente WebAdmin para que no se habilite para todas las fuentes WAN. Si el acceso WAN es realmente necesario, debe limitarse mediante fuentes específicas como IP individuales, redes u objetos FQDN. Las autorizaciones antiguas procedentes de configuraciones anteriores deben revisarse con regularidad: Sophos puede desactivar automáticamente determinadas liberaciones WAN amplias para WebAdmin o User Portal tras un periodo prolongado de inactividad, mientras que excepciones ACL dirigidas a fuentes WAN concretas pueden seguir aplicándose.

Regla de excepción de servicio local ACL

Si un servicio no debe ser accesible para toda una zona, se utiliza una Local service ACL exception rule. Esto permite definir con mucha precisión quién puede acceder a qué servicio local.

Ruta:

1. Abrir Administration.
2. Seleccionar Device access.
3. Desplazarse hasta Local service ACL exception rule.
4. Hacer clic en Add.

Procedimiento típico para una excepción de administración estrecha desde WAN:

1. Definir Rule name, por ejemplo admin-https-from-support-ip.
2. Definir Rule position como Top si una regla Drop o Allow existente podría coincidir antes.
3. Seleccionar la IP version adecuada para la fuente, normalmente IPv4.
4. Definir Source zone como WAN.
5. Definir Source Network / Host como la IP concreta del administrador, una pequeña red de administración o un objeto FQDN/IP mantenido.
6. Limitar Destination host a la dirección o interfaz del firewall afectada, si no se pretende conscientemente cubrir todos los destinos locales.
7. Definir Services como el servicio local necesario, por ejemplo HTTPS para WebAdmin o API, no HTTPS y SSH al mismo tiempo por comodidad.
8. Definir Action como Accept.
9. Guardar y probar inmediatamente desde una fuente permitida y otra no permitida.

Una regla de excepción ACL consta esencialmente de estos campos:

• Rule name: nombre único, por ejemplo admin-https-from-mgmt.
• Rule position: orden de las reglas ACL.
• Source zone: zona desde la que proviene el acceso, por ejemplo WAN, LAN o VPN.
• Source Network / Host: IP de administrador permitida, red de gestión, FQDN Host o lista de IP.
• Destination host: IP del firewall o interfaz a la que se accede.
• Services: servicio local, por ejemplo HTTPS, SSH, Ping o DNS.
• Action: Accept o Drop.

Para el acceso a WebAdmin desde Internet, nunca se debe usar Any como fuente. Sophos evita conscientemente el acceso a WebAdmin desde la zona WAN para todas las fuentes, ya que esto sería un alto riesgo. Si realmente se necesita acceso desde WAN, solo debe permitirse a través de direcciones IP de origen específicas, redes definidas, objetos FQDN u otras fuentes estrechas.

La misma lógica se aplica a la automatización API. Un host puede estar permitido en Administration > API access y aun así fallar si falta la habilitación HTTPS en Device Access. A la inversa, una habilitación HTTPS no debería ampliarse solo porque se conecte una herramienta API. Para los detalles de API, consulte limitar de forma segura el acceso API de Sophos Firewall.

También es importante el orden. Las reglas de excepción ACL se evalúan de arriba a abajo. Una regla Drop superior puede hacer que una regla Accept posterior sea ineficaz. Por el contrario, una regla Accept formulada demasiado ampliamente puede anular restricciones planificadas posteriormente. Por lo tanto, el orden de las reglas debe revisarse tan conscientemente como en las reglas de firewall.

El Destination host es especialmente importante cuando el firewall tiene varias interfaces, direcciones alias, direcciones VPN u objetivos separados de portal/administración. Una regla debería apuntar con la mayor precisión posible a la dirección del firewall que realmente se va a administrar o usar. De lo contrario, una liberación de origen aparentemente estrecha puede afectar de repente a más servicios locales o interfaces de lo previsto.

Evitar el bloqueo antes del cambio

Los cambios en Device Access afectan directamente a los accesos de gestión y portal. Por lo tanto, antes de cualquier restricción, debe estar claro cómo volver a acceder al firewall si una regla se aplica incorrectamente.

Antes de guardar un cambio arriesgado, se debe verificar:

• ¿Está disponible un segundo administrador con un perfil de derechos adecuado?
• ¿Hay acceso a través de otra red, como Management-LAN, Admin-VPN o Sophos Central?
• ¿Existe accesibilidad local a la consola o fuera de banda, en caso de que WebAdmin ya no sea accesible?
• ¿Se está trabajando en un clúster HA donde un cambio de rol puede cambiar la ruta de acceso?
• ¿Están documentados el archivo de copia de seguridad actual, la clave maestra de almacenamiento seguro y el acceso de emergencia?
• ¿Hay una ventana de mantenimiento corta en la que se puedan detectar inmediatamente los accesos incorrectos?

Especialmente en ubicaciones remotas, no se debe eliminar primero el acceso amplio y luego probar. Es más seguro el proceso inverso: crear una nueva regla de excepción ACL estrecha, probar el acceso permitido, confirmar el segundo camino de administrador y solo entonces reducir la antigua autorización de zona amplia.

Implementar cambios de manera segura

Los cambios en Device Access pueden bloquear a los administradores. Por lo tanto, no deben cambiarse de manera casual, sino tratarse como un cambio de gestión.

Proceso probado:

1. Documentar el acceso actual: WebAdmin, SSH, User Portal, VPN Portal, SSL VPN, DNS, SNMP y Ping.
2. Asegurarse de que haya un segundo camino de administrador disponible, como consola local, Admin-VPN o Sophos Central.
3. Crear una copia de seguridad antes de implementar cambios mayores en ACL.
4. Crear una nueva regla de excepción ACL lo más específica posible.
5. Probar el acceso desde la fuente permitida.
6. Probar el acceso desde una fuente no permitida.
7. Revisar el Log Viewer para ver si los eventos esperados son visibles.
8. Eliminar la antigua autorización de zona amplia solo cuando se haya confirmado el nuevo acceso.
9. Documentar el cambio con fecha, fuente, servicio y responsable.

Si se ven afectadas varias firewalls o clústeres HA, el cambio debe probarse primero en un sistema con buena posibilidad de retroceso. Para entornos HA, también es adecuado Configurar Sophos Firewall High Availability, ya que allí se deben considerar conjuntamente los accesos de gestión, cambios de rol y ventanas de mantenimiento.

Revisión posterior a los cambios en Device Access

Después de un ajuste, no basta con verificar solo el acceso propio a WebAdmin. Se deben probar tanto las fuentes permitidas como las no permitidas, de lo contrario, no queda claro si el endurecimiento realmente funciona.

• WebAdmin desde la red de gestión: el acceso funciona como se planificó.
• WebAdmin desde una red de clientes normal: el acceso está bloqueado si no está permitido explícitamente.
• SSH desde la red de administración: el acceso solo funciona si SSH está liberado conscientemente.
• SSH desde WAN o red de invitados: el acceso está bloqueado.
• DNS desde la red de clientes: DNS solo funciona en redes que deben usar el firewall como resolvedor.
• User Portal o VPN Portal: solo los portales necesarios son accesibles.
• SNMP desde el sistema de monitoring: el monitoring funciona, otras fuentes están bloqueadas.

Si un acceso funciona inesperadamente, no solo se debe revisar la regla de excepción ACL. También la tabla de zonas en la parte superior de Device Access, la configuración de zonas personalizadas, la zona VPN, el comportamiento del proxy y las reglas Accept amplias existentes pueden ser la causa.

Para la documentación suele bastar una lista breve por servicio:

• HTTPS: fuente permitida mgmt-net, motivo Acceso de administrador a WebAdmin, review trimestral.
• SSH: fuente permitida support-ip-temporary, motivo Caso de soporte, review tras cierre del ticket.
• SNMP: fuente permitida monitoring-server, motivo Monitoring de hardware e interfaces, review semestral.
• SSL VPN: fuente permitida WAN, motivo Remote Access, review con comprobación mensual de logs.

En cada revisión posterior también debe comprobarse si los accesos permitidos y bloqueados son visibles. Para pruebas cortas, a menudo basta el Log viewer. Para conservación más larga o preguntas de auditoría son más adecuados Central Reporting o Syslog, porque los logs locales rotan o pueden perderse en incidentes.

Configuración básica recomendada

Para muchos entornos productivos, la siguiente lógica es sensata:

• Permitir HTTPS/WebAdmin solo desde Management, Admin-VPN o una IP fija de administrador.
• Permitir API solo desde hosts definidos de automatización o monitoring y limitar además HTTPS adecuadamente mediante Device Access.
• SSH desactivado por defecto y solo permitirlo de manera específica mediante ACL cuando sea necesario.
• Activar DNS solo en zonas donde los clientes realmente usen el firewall como servidor DNS.
• Permitir Ping para sistemas de monitoreo internos, pero no de manera general desde WAN.
• Activar User Portal, VPN Portal y SSL VPN solo si se necesitan.
• Permitir RED solo para ubicaciones o áreas de origen donde realmente haya dispositivos RED.
• Permitir SNMP solo para el sistema de monitoreo.
• Permitir SMTP Relay solo para sistemas internos definidos.
• Activar Dynamic Routing solo en segmentos de enrutamiento donde realmente se utilicen protocolos de enrutamiento dinámico.
• Revisar MFA para WebAdmin, VPN Portal y acceso remoto; la configuración está en Activar MFA para Sophos Firewall WebAdmin, VPN Portal y acceso remoto.
• Usar Sophos Central Firewall Management si se necesita un acceso de gestión externo seguro.

Para una trazabilidad más prolongada, también se debe revisar la estrategia de registros. Los registros locales son suficientes para la búsqueda de fallos agudos, pero no para todas las preguntas de auditoría o respuesta a incidentes. Si los accesos a portales o de gestión deben ser rastreables a largo plazo, Central Firewall Reporting o Enviar Sophos Firewall Syslog a SIEM son los componentes más adecuados.

Tratar SSH con especial cuidado

SSH es muy útil para la resolución de problemas y el soporte, pero no debería estar abierto de manera amplia de forma permanente. Para SSH se aplica:

• Solo el usuario admin puede iniciar sesión por SSH.
• La autenticación con clave pública es el método preferido.
• El acceso desde WAN solo debe realizarse a través de direcciones IP de origen fijas o VPN.
• Después de completar un análisis, se debe verificar si SSH sigue siendo necesario.

Más detalles se encuentran en la guía Conectar Sophos Firewall por SSH.

Bots, fuerza bruta y Threat Feeds

En la práctica, se observa muy a menudo que los servicios demasiado abiertos son encontrados inmediatamente por bots. Los más afectados son WebAdmin, User Portal, VPN Portal y SSL VPN. Incluso si un servicio está protegido por contraseña y MFA, los inicios de sesión públicos generan intentos de ataque, tráfico de fuerza bruta, ruido en los registros y carga innecesaria en el firewall.

Esto no significa automáticamente que se esté produciendo un ataque exitoso. Sin embargo, muestra que el servicio es parte de la superficie de ataque pública. Cuantas menos fuentes lleguen al inicio de sesión, mejor.

Si un portal debe ser accesible mundialmente, los filtros de países o direcciones IP de origen individuales a menudo no son suficientes. En tales entornos, recomendamos además Third-Party Threat Feeds. Los Threat Feeds proporcionan al firewall indicadores de compromiso actualizados continuamente, como direcciones IP maliciosas, dominios o URLs. Los escáneres, botnets y atacantes conocidos pueden ser bloqueados antes de que lleguen a WebAdmin, VPN Portal, SSL VPN u otros servicios publicados.

El artículo propio Sophos Firewall Threat Feeds explica la planificación, la lista de permitidos y la operación.

Errores comunes

Se revisó una regla de firewall en lugar de Device Access

Si WebAdmin, SSH, DNS o Ping no son accesibles en el firewall, una regla de firewall normal no ayuda. El tráfico no pasa a través del firewall, sino que termina en el propio firewall. Por lo tanto, se debe revisar Administration > Device access.

WebAdmin permitido desde demasiadas zonas

WebAdmin no debería ser accesible desde cada zona interna. Una red de invitados, IoT o VoIP normalmente no necesita acceso a la gestión del firewall. Incluso internamente, se debe asumir que pueden existir clientes comprometidos. Una red de gestión separada o un Admin-VPN reduce significativamente este riesgo.

DNS no activado para la zona de clientes

Si los clientes deben usar el firewall como servidor DNS, DNS debe estar permitido para la zona adecuada. De lo contrario, los clientes alcanzan la IP del firewall, pero no reciben una respuesta DNS. Por el contrario, DNS no debería permitirse desde zonas donde el firewall no se utiliza como resolvedor DNS.

Confusión entre User Portal y VPN Portal

El User Portal y el VPN Portal son servicios diferentes. Dependiendo del concepto de acceso remoto, se debe verificar qué portal realmente se necesita. A menudo se activa un portal porque un usuario necesitaba descargar una configuración una vez, pero luego permanece abierto durante años. Estas cargas heredadas deben eliminarse regularmente.

Si los portales deben seguir siendo accesibles desde Internet, no basta con revisar la casilla. Son importantes MFA, grupos de usuarios, proceso de tokens/provisioning, expiración de usuarios temporales, logging y la pregunta de si el portal sigue siendo necesario de forma permanente tras el despliegue.

Se pasó por alto el caso especial del Web Proxy

Si se utiliza el Web Proxy, las solicitudes HTTP y HTTPS pueden parecer internas desde la perspectiva del proxy. Esto puede afectar cómo se controlan los accesos a WebAdmin, Captive Portal, VPN Portal o User Portal. En entornos con proxy, se debe probar con especial cuidado qué accesos son realmente posibles.

Regla ACL formulada demasiado ampliamente

Una regla de excepción ACL con Source zone: Any, Source Network / Host: Any y Services: HTTPS, SSH casi nunca es una buena idea. Tales reglas eluden el verdadero beneficio de seguridad de la excepción ACL. Es mejor una regla pequeña y clara con una fuente inequívoca y solo los servicios necesarios.

Regla de Drop en la posición incorrecta

Si una regla de Drop está por encima de una regla de Accept, el acceso permitido puede ser bloqueado de todos modos. En las reglas de excepción ACL, el orden es tan importante como en las reglas de firewall.

Al contrario, una regla Accept amplia al principio de la lista puede volver prácticamente inútiles reglas Drop posteriores. Tras cada cambio de regla se debe revisar no solo la nueva regla, sino también la lógica de coincidencia de las reglas superiores.

SSL VPN y VPN Portal dejados demasiado abiertos

El acceso remoto a menudo debe ser accesible desde el exterior. Sin embargo, se debe verificar si realmente todos los países, redes y grupos de usuarios necesitan acceso. Si no es posible una limitación de fuente estrecha, se deben utilizar MFA, registros y Threat Feeds de manera aún más consistente.

Solución de problemas

Si un servicio local no es accesible, esta es la secuencia que ayuda:

1. ¿Es correcta la IP de destino del firewall?
2. ¿El cliente proviene de la zona esperada?
3. ¿Está permitido el servicio en Administration > Device access para esta zona?
4. ¿Existe una regla de excepción ACL de servicio local adecuada?
5. ¿Se aplica tal vez una regla ACL superior con Drop?
6. ¿Está el servicio configurado en otro puerto?
7. ¿Se ve el acceso de manera diferente a través de VPN, proxy o NAT de lo esperado?
8. ¿Muestra el Log Viewer algún indicio?
9. ¿Puede Packet Capture ver el intento de conexión en la interfaz?

Para accesos de soporte, puede ser útil crear una regla de excepción ACL específica y eliminarla o desactivarla después de completar el soporte.

Lista de verificación operativa

• WebAdmin no accesible ampliamente desde WAN.
• SSH permitido solo temporalmente o desde redes de gestión/administración.
• DNS activo solo para zonas de clientes que realmente usan el firewall como resolvedor.
• SNMP permitido solo desde el sistema de monitoreo o red de monitoreo.
• User Portal, VPN Portal y SSL VPN activos solo si se necesitan en el concepto de acceso remoto.
• MFA revisado para WebAdmin, VPN Portal y acceso remoto.
• Reglas de excepción ACL nombradas con fuente clara, servicio y propósito.
• Reglas de soporte temporales documentadas con fecha de vencimiento.
• Acceso probado desde fuentes permitidas y no permitidas.
• Registros, Central Reporting o Syslog revisados para accesos relevantes a portales y gestión.
• Review trimestral planificado para WebAdmin, SSH, SNMP, User Portal, VPN Portal y SSL VPN.

FAQ