Proteger el acceso a Sophos Firewall: Device Access

En Administration > Device access se define desde qué zonas son accesibles los servicios locales de Sophos Firewall. Entre ellos están HTTPS para WebAdmin Console, SSH para la CLI, Ping, DNS, User Portal, VPN Portal y otros servicios.

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

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

Por qué Device Access no es una regla firewall

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

Ejemplos:

• Un admin abre https://172.16.16.16:4444.
• Un cliente usa la firewall como servidor DNS.
• Un sistema de monitoring hace ping a la firewall.
• Un usuario abre User Portal o VPN Portal.
• Un admin se conecta a la firewall por SSH.

Ese tráfico no tiene como destino un servidor detrás de la firewall, sino la propia firewall. Por eso se controla mediante la local service ACL.

Este es también el motivo por el que Device Access forma parte del hardening básico de cualquier Sophos Firewall. Un conjunto limpio de reglas LAN-to-WAN no protege automáticamente los servicios de gestión y portales de la firewall. Estos servicios deben revisarse y restringirse por separado.

Entender los permisos por 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, el acceso a ese servicio local queda permitido de forma general desde esa zona.

La tabla de zonas es práctica, pero amplia. Sirve para zonas internas claras, por ejemplo LAN, Management o VPN. Cuando un servicio solo debe ser accesible desde IPs admin concretas, sedes, países o destinos de soporte, las Local service ACL exception rules son la mejor opción.

Ejemplos típicos:

En Custom Zones, la accesibilidad de servicios locales también puede influirse mediante los ajustes de zona. Aun así, Device Access debe revisarse siempre de forma consciente porque es la vista central de los servicios locales de la firewall.

Qué servicios se pueden limitar con ACL Rules

Con Local Service ACL y ACL Exception Rules se pueden controlar servicios locales de la firewall con mucha precisión. Estos servicios son especialmente relevantes:

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

Definir las fuentes lo más estrictamente posible

Una ACL Rule no tiene por qué permitir simplemente Any. Las fuentes pueden definirse con mucha precisión, por ejemplo con:

• direcciones IP admin individuales
• redes de gestión
• IP ranges
• IP lists
• FQDN hosts
• FQDN host groups
• DNS hosts o DNS groups
• Country objects o grupos de países
• redes VPN o de soporte dedicadas

Así el acceso se puede limitar mucho mejor. Ejemplo: si un servicio externo de soporte solo viene de un FQDN fijo o de un rango IP definido, no se debe dar acceso a toda la zona WAN para HTTPS o SSH. Si un sistema de monitoring necesita SNMP, una red completa de servidores no debería poder consultar SNMP en la firewall.

En escenarios Remote Access globales, la delimitación es más difícil. Algunas empresas no pueden permitir SSL VPN o VPN Portal solo desde Suiza, Alemania o un único país, porque los usuarios trabajan en todo el mundo. En estos casos se debe añadir MFA, logging, ajustes restrictivos del portal y Threat Feeds.

Local Service ACL Exception Rule

Si un servicio no debe habilitarse para toda una zona, se usa una Local service ACL exception rule. Con ella se define con 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.

Una ACL Exception Rule se compone principalmente de estos campos:

Para acceso WebAdmin desde Internet, nunca se debería usar Any como fuente. Sophos impide deliberadamente el acceso WebAdmin desde la zona WAN para todas las fuentes porque sería un riesgo alto. Si el acceso WAN es realmente necesario, debe permitirse solo mediante IPs fuente específicas, redes definidas, objetos FQDN u otras fuentes estrictas.

El orden también importa. Las ACL Exception Rules se evalúan de arriba hacia abajo. Una regla Drop superior puede hacer ineficaz una regla Accept posterior. A la inversa, una regla Accept demasiado amplia puede saltarse restricciones previstas. Por eso el orden de reglas debe revisarse tan cuidadosamente como en las reglas firewall.

Configuración básica recomendada

Para muchos entornos productivos tiene sentido esta lógica:

• Permitir HTTPS/WebAdmin solo desde Management, admin VPN o una IP admin fija.
• Desactivar SSH por defecto y permitirlo solo si se necesita mediante una ACL específica.
• Activar DNS solo en zonas donde los clientes realmente usan la firewall como servidor DNS.
• Permitir Ping para sistemas internos de monitoring, pero no de forma general desde WAN.
• Activar User Portal, VPN Portal y SSL VPN solo si se necesitan.
• Permitir RED solo para sedes o rangos fuente donde realmente haya appliances RED.
• Permitir SNMP solo desde el sistema de monitoring.
• Permitir SMTP Relay solo para sistemas internos definidos.
• Activar Dynamic Routing solo en segmentos donde realmente se usan protocolos de routing dinámico.
• Revisar MFA para WebAdmin, VPN Portal y Remote Access.
• Usar Sophos Central Firewall Management si se necesita acceso externo seguro de gestión.

Tratar SSH con especial cuidado

SSH es muy útil para troubleshooting y soporte, pero no debe quedar ampliamente abierto. Para SSH:

• Solo el usuario admin puede iniciar sesión por SSH.
• La autenticación con public key es el método preferido.
• El acceso desde WAN solo debería permitirse mediante IPs fuente fijas o VPN.
• Tras un análisis, comprobar si SSH sigue siendo necesario.

Más información: Conectarse a Sophos Firewall por SSH.

Bots, brute force y Threat Feeds

En la práctica se ve con frecuencia que servicios demasiado abiertos son encontrados inmediatamente por bots. WebAdmin, User Portal, VPN Portal y SSL VPN se ven especialmente afectados. Aunque un servicio esté protegido con contraseña y MFA, los logins públicos generan intentos de ataque, tráfico brute-force, ruido en los logs y carga innecesaria en la firewall.

Esto no significa automáticamente que un ataque tenga éxito. Pero muestra que el servicio forma parte de la superficie pública de ataque. Cuantas menos fuentes puedan llegar siquiera al login, mejor.

Si un portal debe estar accesible en todo el mundo, los filtros por país o IPs fuente individuales a menudo no bastan. En estos entornos recomendamos además Third-Party Threat Feeds. Threat Feeds proporcionan continuamente a la firewall Indicators of Compromise actuales, por ejemplo direcciones IP, dominios o URLs maliciosos. Así se pueden bloquear scanners conocidos, botnets y atacantes antes de que alcancen WebAdmin, VPN Portal, SSL VPN u otros servicios publicados.

Más información: Sophos Firewall Threat Feeds

Errores frecuentes

Revisar una regla firewall en vez de Device Access

Si WebAdmin, SSH, DNS o Ping hacia la firewall no son accesibles, una regla firewall normal no ayuda. El tráfico no atraviesa la firewall, termina en la propia firewall. Por eso hay que revisar Administration > Device access.

WebAdmin permitido desde demasiadas zonas

WebAdmin no debería ser accesible desde cada zona interna. Una red guest, IoT o VoIP normalmente no necesita acceso a la administración de la firewall. Incluso internamente hay que considerar clientes comprometidos. Una red de gestión separada o admin VPN reduce claramente este riesgo.

DNS no activado para la zona de clientes

Si los clientes deben usar la firewall como servidor DNS, DNS debe permitirse para la zona correcta. De lo contrario, los clientes alcanzan la IP de la firewall pero no reciben respuesta DNS. A la inversa, DNS no debería permitirse desde zonas donde la firewall no debe actuar como DNS resolver.

Confundir User Portal y VPN Portal

User Portal y VPN Portal son servicios distintos. Según el concepto Remote Access, hay que comprobar qué portal se necesita realmente. A menudo se activa un portal porque un usuario tuvo que descargar una configuración una vez, y luego queda abierto durante años. Estas herencias deben eliminarse regularmente.

Pasar por alto el caso especial de Web Proxy

Cuando se usa Web Proxy, las solicitudes HTTP y HTTPS pueden parecer internas desde la perspectiva del proxy. Esto puede afectar a cómo se controla el acceso a WebAdmin, Captive Portal, VPN Portal o User Portal. En entornos con proxy hay que probar cuidadosamente qué accesos son realmente posibles.

Regla ACL demasiado amplia

Una ACL Exception Rule con Source zone: Any, Source Network / Host: Any y Services: HTTPS, SSH casi nunca es una buena idea. Estas reglas evitan el beneficio de seguridad de la excepción ACL. Es mejor una regla pequeña y clara, con una fuente definida y solo los servicios necesarios.

Regla Drop en la posición incorrecta

Si una regla Drop está por encima de una regla Accept, el acceso previsto puede quedar bloqueado igualmente. En ACL Exception Rules, el orden es tan importante como en reglas firewall.

SSL VPN y VPN Portal demasiado abiertos

Remote Access a menudo debe ser accesible desde fuera. Aun así, hay que revisar si todos los países, redes y grupos de usuarios necesitan realmente acceso. Si no es posible limitar estrictamente por fuente, MFA, logging y Threat Feeds deben aplicarse con mayor rigor.

Troubleshooting

Si un servicio local no es accesible, ayuda este orden:

1. ¿La IP de destino de la firewall es correcta?
2. ¿El cliente viene de la zona esperada?
3. ¿El servicio está permitido para esta zona en Administration > Device access?
4. ¿Existe una Local service ACL exception rule adecuada?
5. ¿Coincide una regla ACL superior con Drop?
6. ¿El servicio está configurado en otro puerto?
7. ¿El acceso se ve de otra forma por VPN, proxy o NAT?
8. ¿Log Viewer muestra alguna pista?
9. ¿Packet Capture ve el intento de conexión en la interface?

Para accesos de soporte puede ser útil crear una ACL Exception Rule específica y eliminarla o desactivarla al finalizar.

Más información

• Sophos Firewall - Device access
• Sophos Firewall - Device access best practices
• Conectarse a Sophos Firewall por SSH
• Activar MFA para Sophos Firewall WebAdmin, VPN Portal y Remote Access