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 Fusion (antes 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.
Al crear una excepción WAN hay que evitar quedarse sin acceso. Primero se inicia sesión y se prueba una vía de recuperación independiente mediante consola, LAN de gestión, VPN administrativa o Sophos Fusion. Después, en Administration > Device access, se hace clic en Add bajo Local service ACL exception rule. Un ejemplo adaptable es WAN-Admin-203.0.113.10 con Rule position Top, IP version IPv4, Source zone WAN, la IP pública fija del administrador como Source network / host, la interfaz WAN del firewall como Destination host, Services HTTPS y SSH solo si es necesario, y Action Accept. 203.0.113.10 es una dirección de documentación que debe sustituirse por la IP administrativa fija real. Mantener abierta la sesión existente, probar el acceso en una segunda sesión desde ese origen y solo entonces retirar el permiso WAN más amplio para HTTPS o SSH en Local service ACL. Si la prueba falla, el acceso anterior permanece sin cambios; corregir la excepción antes de modificar el permiso de zona.
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.
En SFOS 22, la configuración de usuarios está en Authentication > Multi-factor authentication (MFA). En One-time password (OTP), seleccionar All users o Specific users and groups, activar Generate OTP token with next sign-in para tokens basados en aplicaciones y marcar cada servicio realmente utilizado en Require MFA for. La cuenta integrada admin se protege por separado en Administration > Device access > MFA for default admin. Antes de exigir MFA, al menos una cuenta de administrador nominativa debe haber registrado su token; comprobar su emisión en Issued tokens. Después, probar un nuevo inicio de sesión manteniendo una sesión admin existente abierta como vía de recuperación.
La configuración práctica está en Activar MFA para Sophos Firewall WebAdmin, VPN Portal y Remote Access. Configurar de forma segura administradores y perfiles en Sophos Firewall explica cómo interactúan las cuentas locales personales, los perfiles Device Access, los orígenes de acceso y el offboarding. 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. Conviene comprobar regularmente las maintenance releases disponibles e instalarlas con prontitud tras su aprobación. 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.
La página conserva como máximo dos versiones de firmware. Un rollback arranca la versión anterior con su configuración previa correspondiente; se pierden los cambios realizados desde el cambio de versión. Desde SFOS 19.0 MR1, los cambios de firmware requieren Enhanced Support o Enhanced Plus tras tres actualizaciones gratuitas; los hotfixes no requieren esta suscripción de soporte. Por eso hay que verificar el firmware esperado, el acceso de administración, las VPN y las publicaciones críticas antes de realizar más cambios de configuración tras la actualización.
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.
Una migración de cumplimiento especial es el modo FIPS 140-3 en Sophos Firewall: Su activación realiza un restablecimiento de fábrica y exige una reconstrucción totalmente planificada con valores VPN y de certificados conformes a FIPS.
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.
En SFOS 22, abrir el widget Firewall health check en el Control Center o ir a Monitor & analyze > Firewall health check. Los datos se actualizan al cambiar una configuración supervisada. Es importante saber que un finding puede marcarse manualmente como compliant sin corregir su causa. La validación debe confirmar el requisito de la política, no solo el estado mostrado.
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.
Evaluar por separado la telemetría y Sophos Assistant
En Administration > Admin and user settings, Sophos Adaptive Learning controla qué datos de uso y amenazas envía el firewall a Sophos. Esto incluye aplicaciones sin clasificar y datos sobre alertas IPS, virus detectados, spam y hallazgos de Active Threat Response. El dispositivo también envía periódicamente por HTTPS datos de configuración, funciones, errores y utilización de recursos. Sophos indica que no recopila información específica ni personalizada de los usuarios. Aun así, la decisión debe documentarse conscientemente según los requisitos de privacidad y el modelo operativo, en lugar de confundir esta opción con una función de protección del tráfico local.
Turn on Sophos Assistant, en cambio, solo afecta a textos de ayuda, smart tips y guías de configuración en WebAdmin. Después de cambiar la opción hay que cerrar la sesión y volver a iniciarla. Desactivar el asistente no reduce la superficie de ataque de red ni detiene automáticamente la telemetría; ambas opciones deben evaluarse por separado.
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, los informes en Sophos Fusion, Syslog, SIEM, MDR, XDR o NDR son útiles.
Además, seleccionar los eventos del sistema necesarios para correo electrónico o SNMP en System services > Notification list. Antes hay que configurar el destino de correo en Administration > Notification settings, o el agente SNMP y la comunidad o el usuario en Administration > SNMP. Tras pulsar Save, un evento controlado e inocuo debería llegar al destinatario previsto; si no llega, comprobar primero el destino de correo o SNMP, la conectividad y la clase de evento seleccionada.
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.
Validar cambios y revertirlos de forma segura
Aplicar el hardening en pasos pequeños y trazables. Antes de cada grupo de cambios, registrar el valor actual, el owner y la vía de recuperación prevista. Después, cambiar una sola área, por ejemplo Device Access, una regla firewall o la acción de un Threat Feed. Probar tanto la ruta permitida esperada como una ruta deliberadamente denegada y revisar los logs correspondientes. Solo entonces continuar con el área siguiente.
Para el rollback, devolver únicamente el último ajuste modificado a su valor inicial documentado. En cambios de Device Access, mantener disponibles tanto la sesión admin existente como una vía de gestión independiente probada previamente. No eliminar la regla anterior antes de validar correctamente su sustituta más restrictiva. Iniciar los Threat Feeds con Monitor, revisar coincidencias y posibles falsos positivos, y pasar después a Block; si el bloqueo causa problemas, volver a Monitor y añadir solo exclusiones verificadas. Un restore completo del backup no es un cómodo botón Undo, sino la vía de recovery para fallos mayores.
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.