Sophos Firewall: buenas prácticas de seguridad de red

Durante mucho tiempo, los firewalls fueron el lugar donde se bloqueaban los ataques. Hoy, ellos mismos se han convertido en uno de los objetivos más atractivos. Es lógico: un firewall se encuentra en una posición privilegiada entre Internet, redes de sedes, servicios cloud, accesos VPN y aplicaciones internas. Quien encuentra aquí una vulnerabilidad, una contraseña débil o una mala configuración ya no está delante de la puerta, sino a menudo dentro del edificio.

Por eso ya no basta con considerar un firewall solo como un motor de policies para reglas Allow y Deny. La seguridad de red moderna necesita tres pilares: hardening, protección y detección y respuesta. Hay que reducir la superficie de ataque antes de un ataque, bloquear correctamente durante el ataque y reconocer después con rapidez qué ha ocurrido.

Trabajo desde hace muchos años con entornos Sophos Firewall de tamaños y sectores muy distintos. Las siguientes recomendaciones no son una lista teórica de funciones, sino aquello que se ha demostrado útil una y otra vez en entornos reales de clientes, migraciones, auditorías y casos de soporte.

Por qué los firewalls están tanto en el foco

Un firewall es un objetivo valioso para los atacantes porque está expuesto, tiene privilegios y suele ser crítico para el negocio. Además, muchos entornos operan firewalls, portales VPN o accesos de gestión remota durante años. No todos los entornos están parcheados correctamente, no todas las superficies de gestión están realmente aisladas y no todos los inicios de sesión están protegidos con multi-factor authentication.

En la práctica se repiten sobre todo tres causas en ataques exitosos:

• Vulnerabilidades en firewalls y sistemas edge, especialmente cuando los parches se aplican tarde o no se aplican.
• Credenciales comprometidas y ataques de identidad, a menudo sin MFA o con una configuración MFA débil. El Sophos Active Adversary Report 2026 identifica causas relacionadas con identidad como root cause en el 67.32 % de los casos analizados.
• Sistemas expuestos, como RDP, portales VPN, User Portals o interfaces de administración accesibles directamente desde Internet.

La idea clave es esta: muchos ataques ya no son una «entrada forzada» espectacular. Muy a menudo, los atacantes simplemente inician sesión. Si una cuenta de usuario, una contraseña de administrador o un acceso VPN están comprometidos, el primer paso parece inicialmente uso legítimo para el firewall.

Los tres pilares de la seguridad de red moderna

Sophos describe la protección de redes modernas como un espectro de proactivo a reactivo:

1. Hardening: reducir la superficie de ataque, eliminar sistemas obsoletos, usar productos seguros, revisar configuraciones y restringir accesos.
2. Protection: bloquear ataques, controlar tráfico cifrado y usar con criterio funciones Web, IPS, Zero-Day y Application Control.
3. Detection and Response: detectar anomalías, aislar dispositivos comprometidos, correlacionar datos de amenazas y responder automáticamente.

Muchos firewalls son tradicionalmente fuertes en el segundo pilar. Bloquean tráfico, inspeccionan paquetes, reconocen patrones conocidos y aplican policies. Eso es importante, pero ya no es suficiente. Si el propio firewall está mal configurado, si Remote Access funciona sin MFA o si un sistema sin parchear sigue en producción, existe un problema estructural que ninguna regla IPS individual puede resolver limpiamente.

Mi experiencia muestra que los mejores resultados no se consiguen con una función mágica, sino con una configuración base limpia, revisiones regulares y un firewall integrado en el proceso de seguridad global.

Pilar 1: Hardening antes del ataque

El hardening es la parte del trabajo de seguridad que rara vez recibe aplausos, pero que marca la diferencia en un incidente. Se trata de reducir superficie de ataque, sistemas heredados, rutas de gestión abiertas y dependencia de reacciones manuales.

Reducir infraestructura y eliminar sistemas antiguos

La forma más sencilla de reducir una superficie de ataque es a veces la más incómoda: apagar cosas. Cada appliance antigua, servicio VPN olvidado, portal de gestión o servidor sin soporte es un punto de ataque adicional. Son especialmente críticos los sistemas en el borde de red o aquellos que permiten indirectamente acceso privilegiado a redes internas.

Para admins de Sophos Firewall, esto significa concretamente:

• Revisar regularmente qué firewalls, REDs, gateways VPN, controladores WLAN, reverse proxies y componentes Remote Access siguen en producción.
• Retirar sistemas end-of-life o end-of-support de posiciones privilegiadas.
• Consolidar funciones cuando esto reduzca complejidad: firewall, SD-WAN, DNS Protection, ZTNA, Threat Feeds, reporting y central management deben estar alineados de la forma más limpia posible.
• Documentar qué servicios realmente deben ser accesibles desde Internet.

El objetivo no es meter lo máximo posible en un producto. El objetivo es evitar legacy oculto. Una infraestructura pequeña, actual y bien controlada casi siempre es más segura que un entorno grande, crecido históricamente, con muchas excepciones de «siempre ha sido así».

Asegurar de forma consecuente el acceso de gestión

Una de las best practices más importantes es simple: la Web Admin Console y el User Portal no deberían ser accesibles innecesariamente desde WAN. Si la administración remota es necesaria, debería realizarse mediante Sophos Central, una red de gestión dedicada, ZTNA u otro camino controlado.

En entornos de clientes veo una y otra vez que el problema no es la técnica de ataque más complicada, sino un acceso admin antiguo, un portal crecido históricamente o una excepción «temporal» que nunca se eliminó. Esos puntos pertenecen a cualquier revisión regular del firewall.

En todo entorno Sophos Firewall deberían revisarse estos puntos:

• Activar MFA para administradores, especialmente para el admin predeterminado y todas las cuentas con derechos amplios.
• Exigir MFA para inicios de sesión VPN y portales si estos accesos siguen usándose.
• Evitar acceso WAN a Admin Console y User Portal o limitarlo fuertemente a redes fuente dedicadas.
• Configurar reglas de contraseña fuertes para usuarios y administradores.
• Asegurar SSH, idealmente con autenticación por clave pública y sin amplia exposición WAN.
• Activar copias de seguridad centrales y proteger su acceso, ya que los backups de configuración pueden contener información sensible.
• Activar notificaciones y logging para que los eventos relevantes de seguridad no se pierdan en la operación diaria.

El punto de los backups suele subestimarse. Un backup de firewall no solo contiene ajustes inocuos, sino información sobre redes, reglas, certificados, VPNs y estructuras internas. Por eso los backups deben estar cifrados, almacenados de forma controlada y probados regularmente.

Configurar conscientemente Device Access y Local Service ACL

Cuando se habla de acceso WAN, en Sophos Firewall hay que hablar concretamente de Device Access y Local Service ACL. La matriz Device Access define por zonas qué servicios locales del firewall son accesibles: HTTPS admin, User Portal, SSH, ping, DNS, Captive Portal, portales VPN y otros servicios.

La best practice aquí es muy simple, pero eficaz: desde la zona WAN solo debería estar accesible lo realmente necesario. El acceso admin, SSH y User Portal no pertenecen ampliamente a Internet. Si hacen falta excepciones, deberían limitarse mediante Local Service ACL Exception Rules a direcciones IP fuente concretas o redes de gestión.

Reglas por país como protección mínima

Si las direcciones IP fuente fijas no son realistas, recomiendo trabajar al menos con reglas por país. El acceso solo desde unos pocos países relevantes sigue siendo mucho mejor que la exposición mundial. Alternativamente, se pueden bloquear países con los que la empresa no tiene relación y en los que empleados o admins normalmente no se encuentran. Esto no sustituye MFA, roles fuertes ni ACLs limpias, pero reduce ruido innecesario y muchos intentos automatizados.

Desde mi punto de vista, este es uno de los primeros puntos en toda revisión de firewall. Muchas configuraciones arriesgadas no surgen por mala intención, sino porque un servicio se abrió brevemente para una migración, un caso de soporte o una prueba y nunca se volvió a cerrar. Precisamente esos detalles distinguen un firewall que simplemente funciona de un firewall operado de forma limpia.

Revisar Login Security y roles admin

MFA es importante, pero la capa de login es más que un segundo factor. Los administradores deberían usar cuentas personales y trazables, y no trabajar permanentemente con un full admin compartido. Los permisos basados en roles ayudan a separar accesos de soporte, reporting o helpdesk de la administración real del firewall.

Además, deberían limitarse los intentos fallidos de login, cerrar sesiones limpiamente y restringir accesos admin a redes definidas. Un login disclaimer puede tener sentido legal en ciertos entornos, pero no sustituye controles técnicos reales. Más importantes son políticas de contraseña fuertes, sesiones inactivas cortas, protección brute-force y least privilege.

Evitar patch fatigue: los Hotfixes deben actuar rápido

El patching es uno de esos temas en los que teoría y práctica se alejan mucho. Por supuesto, todo admin sabe que las actualizaciones firmware son importantes. En la realidad significan ventanas de mantenimiento, análisis de riesgo, planificación HA, comunicación con áreas de negocio y a veces downtime. Esto lleva a patch fatigue: las actualizaciones se posponen porque son costosas.

Aquí el factor tiempo es peligroso. Los ataques de identidad son ya la root cause dominante, pero la explotación de vulnerabilidades sigue siendo un vector real, especialmente en sistemas edge como firewalls, VPNs y otros servicios cercanos a Internet. El Sophos Active Adversary Report 2026 cita como ejemplo CVE-2024-40766 en SonicOS, visible en una gran parte de los casos de explotación confirmados del conjunto de datos. Al mismo tiempo, la mediana entre advisory o parche del fabricante y explotación observada fue de 322 días. La señal es clara: patch fatigue no es un problema operativo abstracto, sino una ventana de ataque.

Sophos Firewall da aquí un paso importante: Automated Hotfixes permiten live patches de seguridad sin una ventana de mantenimiento clásica. Para admins esto es muy valioso, porque el efecto crítico de protección no espera al siguiente hueco de mantenimiento.

Aun así, los Hotfixes no sustituyen una estrategia de actualización limpia. Cierran la brecha peligrosa entre una vulnerabilidad descubierta y el upgrade firmware regular. La best practice es por tanto:

• Mantener Hotfixes activados.
• Revisar versiones firmware regularmente y documentar la preparación de firmware updates.
• Leer previamente rutas de upgrade y compatibilidad.
• Preparar backups y plan de rollback.
• Planificar por separado clusters HA y sedes remotas.

No tratar VPN como prueba de confianza

Remote Access VPN fue el estándar durante años. El problema: el VPN clásico piensa a menudo en redes, no en aplicaciones. Quien se conecta correctamente ya está, desde la perspectiva de muchos entornos, en una zona de confianza. Si el endpoint está comprometido o las credenciales fueron robadas, un atacante puede moverse desde ahí.

Zero Trust Network Access (ZTNA) no resuelve este problema por magia, sino con un principio mejor: Trust nothing, verify everything. El acceso no se concede de forma amplia a una red, sino que se evalúa por usuario, dispositivo, estado y aplicación. Un dispositivo debe estar sano y compliant, la identidad debe verificarse y la policy decide granularmente qué aplicación es accesible.

ZTNA no es una decisión automática por Sophos

Lo importante es esto: ZTNA no es una decisión que automáticamente deba significar Sophos ZTNA. Según el entorno, proveedores especializados de ZTNA, SSE o SASE pueden estar más avanzados funcionalmente, ofrecer mejores integraciones o encajar mejor con la organización. Lo decisivo no es el nombre del fabricante, sino si identidad, postura del dispositivo, acceso a aplicaciones, logging y operación encajan limpiamente.

Esta es también mi postura general en proyectos Sophos: no elijo Sophos automáticamente para cada tema. Si una solución de terceros para ZTNA, SSE, Threat Intelligence, SIEM o NDR encaja mejor técnicamente, esa es la mejor recomendación. Una buena arquitectura de seguridad no nace de la máxima dependencia de un fabricante, sino de componentes bien integrados con responsabilidades claras.

En entornos puramente Sophos, la integración puede ser interesante porque ZTNA, Endpoint, Firewall y Sophos Central pueden utilizarse juntos. Un dispositivo comprometido o no conforme puede perder acceso sin que un admin tenga que reconstruir manualmente reglas de firewall. También merece la pena revisar el ZTNA Gateway en Sophos Firewall. En entornos mixtos o más grandes, conviene comparar conscientemente y no elegir automáticamente al fabricante del firewall existente como plataforma ZTNA.

Quien todavía dependa mucho de SSL VPN o IPsec Remote Access debería revisar al menos estos puntos:

• Exigir MFA para cada acceso Remote Access.
• Eliminar usuarios VPN antiguos o no utilizados.
• Controlar la importación de grupos desde AD o Entra ID para que Remote Access no se active involuntariamente.
• Reducir Split-Tunnel, redes permitidas y permisos al mínimo.
• Planificar una migración gradual a una solución ZTNA, SSE o SASE adecuada, especialmente para web apps internas, RDP, SSH, portales administrativos y aplicaciones de negocio.

Segmentación contra lateral movement

Cuando los atacantes entran con credenciales válidas o mediante un servicio expuesto, la segmentación interna decide hasta dónde pueden moverse. Un firewall no debe ser solo gateway perimetral, sino separar zonas internas de forma limpia: usuarios, servidores, management, IoT, red de invitados, producción, backup y sistemas especialmente críticos no pertenecen ciegamente al mismo modelo de confianza.

En la práctica, esto significa construir VLANs y zonas no solo por orden, sino protegerlas con reglas reales de firewall. Entre redes de usuarios y servidores solo deberían permitirse las aplicaciones necesarias. Los accesos de gestión pertenecen a redes admin dedicadas. Redes IoT e impresoras no deberían hablar libremente con servidores. Backups y domain controllers merecen reglas especialmente restrictivas y buen logging.

Aquí se cierra el círculo con la afirmación «los atacantes inician sesión». Si una cuenta comprometida tiene acceso a una aplicación, pero no a toda la red, un incidente no se convierte automáticamente en una compromisión completa.

En nuevos proyectos planifico la segmentación lo antes posible. Después sigue siendo posible, pero mucho más trabajosa, porque primero hay que desenredar aplicaciones, excepciones y dependencias históricas.

Hacer visibles las malas configuraciones

Un firewall puede ser técnicamente muy potente y aun así volverse peligroso por una mala configuración. Reglas demasiado amplias, objetos “Any”, autenticación débil, policies IPS ausentes, pattern updates desactivados o portales abiertos son ejemplos típicos. Lo difícil es que en entornos crecidos estos riesgos no siempre se ven de inmediato.

El Sophos Firewall Health Check aborda exactamente este problema. Comprueba decenas de ajustes frente a best practices y benchmarks y muestra en Control Center dónde las configuraciones son arriesgadas o se desvían de estándares recomendados. Los resultados se priorizan por riesgo, llevan directamente a los ajustes afectados y pueden corregirse o sobrescribirse conscientemente según la situación.

Health Check es especialmente útil para procesos operativos recurrentes:

• después de un nuevo rollout de firewall,
• después de cambios grandes de reglas,
• antes y después de firmware upgrades,
• antes de auditorías,
• después de migraciones desde hardware antiguo,
• como revisión trimestral regular.

Pero también es importante: un Health Check no sustituye el criterio de los admins. No toda recomendación encaja en todo entorno. Algunos puntos tienen razones de compliance u operación, otros son brechas claras de seguridad. Lo decisivo es evaluar desviaciones conscientemente y no dejarlas crecer sin visibilidad.

Desde mi punto de vista, Health Check es especialmente fuerte como herramienta operativa continua. No es solo algo para el primer go-live, sino un buen punto de partida para revisiones trimestrales, preparación de auditorías y limpieza de reglas antiguas.

Secure by Design: endurecer el propio firewall

Desde mi punto de vista no se necesitan solo productos de seguridad, sino productos de seguridad seguros. Es una diferencia importante. Un firewall no solo debe bloquear ataques contra otros sistemas, sino también estar endurecido contra ataques dirigidos a él mismo.

En Sophos Firewall esto incluye varias capas:

• Kernel endurecido y arquitectura modernizada: la arquitectura Xstream más reciente se apoya más en aislamiento, modularización, contenedorización y separación de privilegios. Esto reduce ciertas clases de vulnerabilidades y limita impactos mediante mejor aislamiento. También se añaden mitigaciones contra vulnerabilidades side-channel y CPU. Esto hace la plataforma más robusta, pero no inmune a vulnerabilidades.
• Automated Hotfixes: las correcciones de seguridad pueden distribuirse muy rápido y sin ventana de mantenimiento clásica.
• Remote Integrity Monitoring: el Sophos XDR Linux Sensor integrado puede supervisar la integridad del sistema en tiempo real, por ejemplo cambios de configuración no autorizados, Rule Exports, ejecución sospechosa de programas o File Tampering. Pero solo es valioso si la función está activada, licenciada, conectada y supervisada en operación.
• Gestión Central segura: la administración puede realizarse mediante Sophos Central sin abrir ampliamente puertos de gestión a Internet.
• Health Check: las configuraciones de riesgo se vuelven visibles directamente.
• Backups cifrados: los datos de configuración se transmiten y almacenan protegidos.

Además, Sophos apuesta por la supervisión proactiva de la base instalada de firewalls. La telemetría de firewalls puede ayudar a reconocer antes indicios de ataques o manipulación. Cuando aparece un patrón, Sophos puede apoyar de forma dirigida a clientes o partners y desplegar Hotfixes de forma amplia y rápida.

Estos puntos son menos espectaculares en el día a día que una nueva regla de firewall o un ataque bloqueado en el log. A largo plazo, sin embargo, son decisivos. Un producto endurecido reduce la probabilidad de que el propio firewall se convierta en punto de entrada. Pero no sustituye un proceso limpio de parches, monitoring ni revisión regular de configuración.

Qué esperar de un fabricante de firewalls

Secure by Design no es solo una propiedad de producto, sino también una cuestión de fabricante. Los clientes deberían esperar que los fabricantes traten vulnerabilidades de forma transparente, comuniquen claramente información de lifecycle, desplieguen fixes de seguridad rápido y construyan sus productos de manera que malas configuraciones y componentes comprometidos se hagan visibles lo antes posible.

La responsabilidad es compartida. Los fabricantes deben entregar productos seguros y reaccionar de forma transparente. Los clientes deben aplicar updates, sustituir sistemas EOL, usar MFA y revisar la operación regularmente. Ambas cosas van juntas.

Pilar 2: Protection durante el ataque

El hardening es la base. Después, el firewall debe seguir haciendo aquello para lo que se usa: controlar tráfico y bloquear ataques. En Sophos Firewall esto incluye, entre otros, IPS, Web Protection, Application Control, Zero-Day Protection, TLS Inspection, DNS Protection y Threat Intelligence Feeds.

Sophos se apoya mucho en la arquitectura Xstream. El tráfico confiable puede procesarse de forma más eficiente, tareas intensivas como operaciones crypto pasan por rutas optimizadas, y queda más reserva de rendimiento para tráfico de mayor riesgo, como Deep Packet Inspection, TLS Inspection y Zero-Day Protection.

TLS Inspection es un buen ejemplo del equilibrio entre seguridad y operación. Sin descifrado, gran parte del tráfico moderno permanece invisible. Pero con reglas TLS mal planificadas se generan casos de soporte, problemas de certificados o cuellos de botella de rendimiento. La best practice no es «descifrar todo a ciegas», sino clasificar limpiamente:

• primero grupos de usuarios y servidores críticos,
• excluir limpiamente banking, health, privacy y categorías problemáticas conocidas,
• probar páginas de bloqueo y advertencia,
• documentar la distribución de certificados,
• evaluar logs activamente.

Mi recomendación es no iniciar TLS Inspection como un proyecto de todo o nada. Es mejor un rollout limpio con grupos de usuarios claros, excepciones, ventanas de prueba y análisis de logs. Así aumenta la visibilidad sin saturar al helpdesk el primer día.

Threat Feeds también pertenecen a esta área de protección. Estos feeds ayudan a bloquear IPs, dominios o URLs maliciosos conocidos directamente en el perímetro de red. En versiones recientes de Sophos Firewall están mucho más integrados en Active Threat Response y mecanismos de protección.

Los Threat Feeds se vuelven especialmente interesantes cuando no se usan solo listas genéricas, sino feeds de terceros curados con contexto actual. Un ejemplo es Cybora.io, donde IPs y dominios maliciosos de distintas fuentes y telemetría de firewalls se consolidan en feeds utilizables. He descrito con más detalle cómo pueden usarse estos feeds en firewalls en el artículo Threat Intelligence Feeds para el firewall.

También aquí aplica: los Threat Feeds deben probarse y observarse. Feeds demasiado agresivos, procesos de allowlist ausentes o responsabilidades poco claras pueden bloquear tráfico legítimo y causar más daño que beneficio en operación. Buenos feeds no sustituyen una revisión de reglas, sino que son un componente adicional con su propio tuning.

Tampoco hay que olvidar los hardenings clásicos de SFOS: Spoof Protection, ajustes DoS adecuados y Geo-IP-Blocking pueden reducir accesos simples, ruidosos u obviamente no deseados. Esto no sustituye una policy limpia, pero reduce ruido innecesario en el firewall y bloquea rutas de ataque que en muchos entornos no tienen ningún propósito legítimo.

Aquí recomiendo proceder de forma pragmática: primero controlar limpiamente los grandes riesgos, luego endurecer paso a paso las funciones de protección y demostrar con logs qué funciona realmente. Una policy sobrecargada que nadie entiende ya no aporta seguridad sostenible.

Pilar 3: Detection and Response tras la primera señal

La parte más interesante de la seguridad de red moderna es la respuesta. Un firewall no debería trabajar aislado, sino usar señales de Endpoint, Server, NDR, MDR, XDR y Threat Intelligence. Sophos puede aportar ventajas de ecosistema, pero solo si esas integraciones encajan realmente con el entorno.

Los ecosistemas solo ayudan si encajan

Synchronized Security y Security Heartbeat son buenas ideas: el firewall puede considerar el estado de endpoints y restringir o bloquear la comunicación de dispositivos comprometidos. En la realidad, sin embargo, cada vez más empresas usan Microsoft Defender u otras soluciones endpoint. Entonces esta parte del ecosistema Sophos funciona solo parcialmente o no funciona. Precisamente por eso no se debería comprar automáticamente todo del mismo fabricante solo porque se ofrece como ecosistema integrado.

Mi recomendación aquí es clara: lo decisivo es qué encaja con la empresa y puede implementarse limpiamente. Si Microsoft Defender, otro EDR, un NDR de terceros o un SIEM externo son la mejor base, el firewall debe integrarse limpiamente en esa arquitectura. Más importante que el cross-selling es que los logs lleguen al sitio correcto, las alertas se entiendan y alguien revise regularmente qué reportan los sistemas. Sin análisis de logs, tuning y proceso de incidentes, incluso la mejor integración ayuda poco.

Con Active Threat Response, las amenazas detectadas pueden traducirse automáticamente en decisiones de red. Y con NDR Essentials, el firewall obtiene visibilidad adicional sobre tráfico de red sospechoso, también donde no hay un agente endpoint clásico instalado.

La automatización necesita runbooks

La automatización necesita límites claros. Debe estar definido qué señales pueden bloquear automáticamente, quién levanta un aislamiento, cómo se tratan falsos positivos y cómo se prueban estos procesos. Sin runbooks, responsabilidades y ejercicios regulares, en un incidente nadie sabe si un bloqueo fue intencionado, correcto o demasiado agresivo.

¿Qué ocurre en un incidente? Un dispositivo comprometido puede aislarse, la comunicación C2 interrumpirse, la exfiltración bloquearse y un analista MDR o XDR puede activar Active Threat Response sin construir primero una regla manual en el firewall. Esto es especialmente valioso cuando un ataque se detecta fuera del horario normal.

Para admins, lo más importante es que la reacción sea suficientemente rápida. Si un analista MDR o XDR primero debe llamar, escribir un ticket y un admin local tiene que crear manualmente una regla un viernes por la tarde, el tiempo de respuesta es demasiado largo. Respuesta automatizada no significa sustituir personas. Significa que la primera contención ocurre de inmediato y el equipo puede investigar después con calma.

Esta automatización es especialmente valiosa en equipos IT pequeños. No todas las empresas tienen un especialista de firewall disponible 24/7. Cuando Endpoint, Firewall, NDR, MDR y SIEM trabajan juntos de forma sensata entre fabricantes, se gana tiempo, y el tiempo suele ser el factor más importante durante ataques activos.

Checklist práctica para admins de Sophos Firewall

Quien quiera endurecer hoy una Sophos Firewall puede empezar con esta lista:

Revisar de inmediato

• ¿Están activados los Hotfixes?
• ¿Está MFA activo para administradores?
• ¿Son accesibles Web Admin Console y User Portal desde WAN?
• ¿SSL VPN o IPsec Remote Access están protegidos con MFA?
• ¿Existen cuentas admin locales no utilizadas?
• ¿Los backups están planificados, cifrados y probados?
• ¿Device Access y Local Service ACL están reducidos al mínimo?
• ¿Los servicios accesibles desde WAN están limitados al menos a países relevantes o redes fuente conocidas?
• ¿Pattern updates y firmware están actualizados?

En las próximas semanas

• Ejecutar Health Check y priorizar findings.
• Revisar reglas antiguas de firewall con “Any” en origen, destino o servicio.
• Revisar roles admin, Login Security, session timeouts y protección brute-force.
• Inventariar servicios expuestos como RDP, SSH, servidores web, portales y reglas NAT.
• Revisar zonas internas y reglas VLAN contra lateral movement.
• Comparar opciones ZTNA, SSE o SASE para aplicaciones Remote Access típicas.
• Revisar Threat Feeds y DNS Protection.
• Activar Spoof Protection, protección DoS y Geo-IP-Blocking según riesgo.
• Probar TLS Inspection de forma estructurada y desplegarla por fases.

Planificar estratégicamente

• Sustituir sistemas end-of-life.
• Coordinar de forma sensata operación de firewall, VPN, DNS, SD-WAN y ZTNA/SSE.
• Estandarizar gestión central, reporting y alerting, por ejemplo mediante Sophos Central, SIEM o plataformas de seguridad existentes.
• Definir export Syslog/SIEM y retención de logs para análisis forense.
• Integrar señales MDR/XDR/NDR en el proceso de incidentes.
• Introducir revisiones recurrentes de firewall hardening.

Conclusión

Las Network Security Best Practices no son un proyecto único, sino un modelo operativo. Precisamente porque los firewalls en el perímetro son tan privilegiados, deben endurecerse, parchearse, revisarse e integrarse en la detección de forma regular.

Mi recomendación tras muchos años con Sophos Firewall es clara: un firewall moderno debe ser más que un producto de protección. Lo decisivo son un diseño seguro, malas configuraciones visibles, correcciones de seguridad rápidas y una respuesta que en un incidente funcione con Endpoint, NDR, XDR y MDR.

O dicho de forma práctica: si un firewall es tan antiguo que pertenece más a un museo que a un rack, no es solo un riesgo operativo. Es una superficie de ataque. Y esa superficie de ataque la mantengo lo más pequeña posible.

Soporte de Avanet

Si se necesita apoyo para endurecer una Sophos Firewall, Avanet puede ayudar. Como especialista Sophos de muchos años, apoyo a equipos IT con auditorías de firewall, revisiones Health Check, limpieza de reglas, planificación Remote Access y ZTNA/SSE, estrategias de actualización y formaciones.

Una mirada externa a accesos de gestión, configuración VPN, reglas antiguas, servicios expuestos por WAN y estado de updates suele merecer la pena. Muchos riesgos no nacen de un único ajuste incorrecto, sino de excepciones acumuladas que en el día a día nadie cuestiona.

Si hay interés, basta un breve mensaje mediante el formulario de contacto. Después se puede aclarar conjuntamente si una revisión compacta del firewall, una auditoría o una formación es lo más adecuado para el entorno correspondiente.

FAQ

Enlaces relacionados

• Avanet Blog: Sophos Firewall v22: resumen y todas las novedades
• Avanet Blog: Threat Intelligence Feeds para el firewall
• Avanet Blog: Sophos ZTNA Gateway en Sophos Firewall
• Avanet Blog: Sophos NDR - eliminar puntos ciegos en la red
• Avanet KB: Sophos Firewall Firmware Update - preparación y best practices

Fuentes

• Sophos: Firewall: Network Security Best Practices
• Sophos Docs: Hardening your Sophos Firewall
• Sophos X-Ops: Nowhere, man: The 2026 Active Adversary Report