Sophos Firewall Hardening: buenas prácticas para una configuración segura
El hardening de Sophos Firewall significa reducir de forma consciente la superficie de ataque innecesaria alrededor del propio firewall y de los servicios publicados a través de él. No es una única opción mágica, sino un proceso operativo repetible: limitar el acceso de administración, exigir MFA, mantener el firmware actualizado, revisar reglas, activar funciones de protección y evaluar logs.
Este artículo es el punto de entrada central. No sustituye las guías detalladas, sino que ordena las buenas prácticas más importantes y enlaza los artículos adecuados de la KB de Avanet.
Qué comprobar primero
En hardening, el orden importa. Una política IPS perfectamente ajustada ayuda poco si WebAdmin es accesible mundialmente desde WAN o si un antiguo portal VPN está expuesto sin MFA.
Comprobaciones inmediatas más importantes:
- ¿WebAdmin es accesible desde la zona WAN?
- ¿SSH solo está permitido desde redes de administración confiables?
- ¿MFA está activo para administradores, VPN Portal y Remote Access?
- ¿Firmware, hotfixes y pattern updates están actualizados?
- ¿Existen accesos DNAT, WAF o VPN que ya no se necesitan?
- ¿Los servicios publicados tienen IPS, WAF, Threat Feeds, logging y propietario claro?
- ¿Los logs relevantes para seguridad se guardan centralmente o al menos se revisan regularmente?
- ¿Existe una copia de seguridad actual y probada, incluido el Secure Storage Master Key?
Asegurar el acceso de administración
El área más importante de hardening es el acceso al propio firewall. WebAdmin, SSH, User Portal, VPN Portal, Captive Portal y los servicios locales no son reglas normales de firewall, sino servicios locales del firewall. Deben limitarse mediante Device Access y Local Service ACL.
Device Access y Local Service ACL
En Administration > Device access se define por zona qué servicios locales son accesibles. Para la zona WAN solo debería estar activo lo realmente necesario. El acceso de administración y SSH normalmente no deben exponerse ampliamente a Internet.
Si se necesita administración remota, estas variantes son más limpias:
- Gestión mediante Sophos Central.
- Acceso mediante una red dedicada de administración.
- Acceso mediante VPN o ZTNA.
- Local Service ACL Exception Rules limitadas a IPs de origen fijas de administradores.
La implementación concreta está descrita en Asegurar el acceso a Sophos Firewall: configurar Device Access correctamente. Si se necesita SSH, también ayuda Conectar Sophos Firewall por SSH.
MFA, roles y seguridad de inicio de sesión
MFA debería ser obligatorio para administradores y usuarios de Remote Access. Son especialmente críticos las cuentas admin locales, VPN Portal, User Portal y Remote Access VPN. Pero MFA es solo una parte del hardening del login. También son importantes cuentas admin nominativas, roles claros, políticas de contraseña fuertes, intentos de login limitados y session timeouts cortos.
La configuración práctica está en Activar MFA para Sophos Firewall WebAdmin, VPN Portal y Remote Access. Para escenarios WAF con inicio de sesión de usuario encaja Asegurar Sophos Firewall WAF con MFA.
Firmware, hotfixes y recovery
Un firewall es un sistema de borde. Las actualizaciones retrasadas no son un detalle menor, sino una ventana real de ataque. Al mismo tiempo, las actualizaciones no deben hacerse a ciegas porque pueden afectar sedes remotas, clústeres HA, VPN y reglas NAT productivas.
Hacer planificables las actualizaciones
Las actualizaciones de firmware deben prepararse con copia de seguridad, ventana de mantenimiento, revisión de release notes, planificación HA y criterios de rollback. En las versiones actuales de SFOS 22, la página WebAdmin Backup & Firmware > Firmware ya no muestra una sección Hotfix separada. La función hotfix sigue existiendo: Sophos instala hotfixes automáticamente por defecto y recomienda no cambiar esta configuración. Si hay que comprobar el estado, usar system hotfix show en Device Console. Los hotfixes no sustituyen un proceso regular de actualización. El proceso está descrito en Sophos Firewall firmware update: preparación y buenas prácticas.

Para saltos mayores de versión, también hay que comprobar ruta de upgrade, licencia, plataforma y limitaciones conocidas. Comprobar Sophos Firewall antes del upgrade a SFOS 22 encaja aquí.
Comprobar backup y restore
El hardening no termina con la prevención. Un firewall endurecido también debe poder recuperarse. Esto incluye una copia de seguridad actual, la contraseña del backup, el Secure Storage Master Key, un camino de acceso documentado después del restore y una prueba de aceptación.
Los detalles están en Crear o restaurar backup de Sophos Firewall. Un paquete completo de recovery es obligatorio antes de actualizaciones de firmware, migraciones, reimage y sustitución de hardware.
Reducir la superficie de ataque en las reglas
Muchos riesgos no vienen de ataques exóticos, sino de reglas demasiado amplias, excepciones antiguas y servicios publicados que ya no tienen un responsable claro.
NAT, WAF y servicios publicados
Cada servicio publicado por DNAT o WAF es una entrada abierta deliberadamente. Puede ser necesario, pero debe planificarse de forma estricta: source, destination, service, orden NAT, regla firewall, política IPS/WAF, logging, prueba y owner van juntos.
Para servidores publicados ayudan Publicar un servidor con DNAT en Sophos Firewall y Entender NAT en Sophos Firewall. Si se publican servidores web, Sophos Firewall WAF: publicar servidores web de forma segura es la base más adecuada.
Reglas firewall y segmentación
Las reglas con Any como source, destination o service no son automáticamente erróneas, pero siempre requieren explicación. Para hardening importan estas preguntas:
- ¿La regla sigue siendo necesaria?
- ¿Logging está activado?
- ¿Existe una source o destination más clara?
- ¿La regla está correctamente posicionada antes de reglas más amplias?
- ¿Las redes admin, servidor, cliente, IoT, invitado y backup están claramente separadas?
Las bases están en Entender y configurar reglas de Sophos Firewall de forma segura. Para comprobar una regla concreta encaja Probar reglas de Sophos Firewall correctamente.
Activar funciones de protección conscientemente
Las funciones de protección solo ayudan cuando encajan con la regla, el tráfico y el proceso operativo. Activarlas a ciegas genera falsos positivos, problemas de rendimiento o casos de soporte. Dejarlas desactivadas mantiene abierta una superficie de ataque innecesaria.
IPS, Spoof Protection y DoS
IPS debe usarse en tráfico entrante no confiable y en transiciones internas relevantes. Son importantes políticas IPS adecuadas, logging, proceso de falsos positivos y control de rendimiento. La implementación está en Configurar y probar Sophos Firewall IPS de forma segura.
Spoof Protection y DoS Settings reducen fuentes no plausibles y patrones simples de flooding. Deben probarse con cuidado, especialmente con VoIP, VPN, alta carga de paquetes o diseños especiales de routing. El artículo adecuado es Comprobar Sophos Firewall Spoof Protection y DoS Settings.
Threat Feeds para WAF y DNAT
Los Threat Feeds son una ampliación muy útil cuando hay servicios accesibles mediante WAF, DNAT, VPN Portal u otros accesos públicos. Pueden bloquear antes IPs, dominios o URLs maliciosos conocidos, antes de que lleguen a la aplicación o regla real.
Son especialmente útiles para:
- servidores web públicos detrás de WAF o DNAT,
- accesos RDP, SSH o admin aún no sustituidos completamente por ZTNA,
- accesos VPN y portales con mucho ruido de Internet,
- entornos donde el bloqueo por países es demasiado general,
- clientes que quieren usar feeds de terceros curados además de Sophos X-Ops.
La operación es decisiva: calidad del feed, acción Monitor o Block, allowlist, falsos positivos, logging y responsabilidad deben estar claros. La configuración está descrita en Configurar y operar Sophos Firewall Threat Feeds de forma segura. Para feeds curados, Cybora puede ser un componente útil, especialmente cuando los servicios publicados deben protegerse de forma coherente contra fuentes maliciosas conocidas.
Web, DNS, TLS y Zero-Day Protection
Web Protection, DNS Protection, TLS Inspection y Zero-Day Protection aumentan visibilidad y capacidad de bloqueo, pero necesitan planificación limpia. TLS Inspection no debe empezar como proyecto todo-o-nada. DNS Protection debe encajar con las rutas DNS usadas. Zero-Day Protection solo ayuda si los tipos de archivo y políticas relevantes están integrados con sentido.
Los artículos detallados son Crear Sophos Firewall Web Protection con Web Policies, Configurar Sophos DNS Protection con Sophos Firewall, Introducir correctamente Sophos Firewall TLS Inspection y Entender y operar Sophos Firewall Zero-Day Protection.
Detección, logging y revisión
El hardening no es una tarea única. Reglas, usuarios, portales, excepciones NAT y versiones de firmware cambian. Por eso se necesitan revisiones regulares y logs disponibles antes de un incidente.
Health Check como punto de partida
El Sophos Firewall Health Check es un buen punto de partida porque hace visibles configuraciones arriesgadas. Los findings no deben aplicarse a ciegas, sino evaluarse según riesgo, impacto operativo y arquitectura local.
Buenos momentos para un Health Check:
- después del setup inicial,
- después de migraciones,
- antes y después de upgrades de firmware,
- después de grandes cambios de reglas,
- antes de auditorías,
- trimestralmente en operación.
Logging, alertas y SIEM
Las reglas firewall sin logging suelen ser inútiles para troubleshooting e incident response. Para retención más larga, el Log Viewer local normalmente no basta. Según el entorno, Sophos Central Reporting, Syslog, SIEM, MDR, XDR o NDR son útiles.
La configuración técnica de Syslog está descrita en Enviar Sophos Firewall Syslog de forma segura a SIEM. Para informes centrales encaja Activar y operar Sophos Firewall Central Reporting. Si NDR y Active Threat Response son relevantes, ayuda Operar Sophos Firewall NDR y Active Threat Response.
Checklist compacta de hardening
Para una primera revisión, usar este orden:
- Comprobar acceso WAN a WebAdmin, SSH, User Portal y VPN Portal.
- Activar MFA para administradores y Remote Access.
- Limpiar cuentas admin locales, roles y políticas de contraseña.
- Comprobar firmware, hotfixes, pattern updates y estado de soporte.
- Documentar backup, SSMK, ruta de restore y prueba de recovery.
- Revisar publicaciones DNAT, WAF y VPN por necesidad.
- Limpiar reglas con
Any, sin logging o sin owner claro. - Activar IPS, Spoof Protection, DoS Settings y Threat Feeds de forma dirigida.
- Introducir Web, DNS, TLS y Zero-Day Policies por fases.
- Establecer Health Check, Syslog, alertas y revisiones regulares como proceso operativo.
Errores frecuentes
El acceso WAN queda abierto por comodidad
Se abre acceso WebAdmin o SSH para un caso de soporte y luego se olvida. Estas excepciones temporales deben documentarse con fecha de caducidad, owner y control posterior.
Threat Feeds se activan sin concepto operativo
Los Threat Feeds son fuertes, pero no libres de mantenimiento. Sin monitoring, allowlist y proceso de falsos positivos, un partner, proveedor o servicio cloud legítimo puede ser bloqueado. Por eso primero probar con Monitor o scope limitado, luego cambiar limpiamente a Block.
Falta logging en reglas críticas
Si una regla DNAT pública, WAF o VPN no registra logs, durante un incidente se ve demasiado poco. Al menos entradas relevantes para seguridad, accesos admin, reglas deny y transiciones críticas entre segmentos deberían ser trazables.
Health Check se trata como tarea única
Una buena puntuación tras el setup no es un estado permanente. Nuevas reglas, nuevos usuarios VPN, excepciones temporales y cambios de firmware pueden cambiar la situación. El hardening necesita ritmo de revisión.