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 de seguridad se conservan independientemente del firewall y se supervisan, con responsable y plazo de conservación definidos?
• ¿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

VPN Portal no sirve solo para descargas: Los clientes VPN y las configuraciones modificadas se distribuyen mediante VPN Portal. SSO también necesita mantener la accesibilidad WAN requerida: Microsoft Entra ID SSO en SFOS 22 y OpenID Connect SSO en SFOS 23. No cerrar una ruta SSO aún necesaria tras las descargas. User Portal permanece desactivado en WAN; el acceso remoto se realiza por VPN. Proteger VPN Portal con ACL adecuadas y lo más restrictivas posible, un certificado válido y supervisión de ataques de fuerza bruta. Para OIDC, exigir MFA en el IdP, no mediante OTP adicional del firewall. Los pasos OTP locales siguientes se aplican a la autenticación tradicional, no a OIDC. La configuración se explica en Entra VPN SSO y Google Workspace OIDC. Tras cambios de ACL o autenticación, probar un nuevo inicio de sesión y el túnel VPN real desde la red externa prevista; si falla, revisar ACL, certificado y correspondencia de redirecciones en vez de abrir WAN ampliamente.

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.

Mantener CAPTCHA activado por defecto, especialmente en páginas de acceso desde WAN o redes no confiables. No sustituye a MFA ni a Block login; un CAPTCHA incorrecto no cuenta como intento fallido para ese bloqueo. Cambiar y restaurar CAPTCHA de forma selectiva describe una excepción VPN justificada y aprobada para WebAdmin o User Portal. Registrar antes el ámbito, el destino y el valor inicial, comprobar acceso y MFA y después verificar con show y un nuevo inicio de sesión por la ruta VPN prevista. La reversión restaura exactamente el valor registrado; para volver deliberadamente al valor predeterminado activado se usa enable. Desactivarlo globalmente no es hardening ni una solución para la limitación de SFOS 22.0 GA descrita allí. Los comandos de excepción no afectan a VPN Portal ni a SPX Portal.

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.

Comprobar la autorización de VPN de acceso remoto

Conceder acceso VPN solo a los usuarios y grupos que lo necesitan y únicamente a los recursos requeridos. No seleccionar para ello el grupo de fallback predeterminado Open group. Los usuarios sin una asignación de grupo coincidente pueden acabar allí, por ejemplo durante la sincronización AD. Revisar periódicamente los miembros y asignarlos a los grupos correctos. Este grupo predeterminado no es una regla firewall de fallback ni el grupo de fallback IdP deliberadamente restringido de la guía SSO enlazada. La asignación específica del proveedor sigue descrita allí. Para la aceptación, probar un usuario autorizado, uno de fallback/no asignado y un recurso denegado: solo debe funcionar el acceso previsto. Si una prueba tiene éxito inesperadamente, corregir grupos y permisos VPN/firewall y repetirla.

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.

No publicar directamente en Internet servicios RDP internos ni accesos administrativos. VPN o ZTNA es la ruta preferida para el acceso remoto a sistemas internos y la administración remota. Los Threat Feeds no justifican la exposición pública. Los dispositivos IoT sin un diseño de proxy en la nube que requieren acceso NAT entrante directo necesitan aislamiento, sustitución o retirada planificados, no una exposición WAN permanente. Un proxy en la nube tampoco garantiza por sí solo la seguridad. Antes de una desconexión aprobada, aclarar con el responsable las dependencias, los efectos operativos y la continuidad necesaria del servicio.

Como revisión concreta, inventariar una publicación RDP existente y una asignación NAT de IoT: host de destino, servicio, orígenes permitidos, IDs de regla firewall/NAT, responsable y necesidad real de acceso remoto. Planificar la migración a VPN/ZTNA o la retirada aprobada. Una publicación existente inevitable solo debe permanecer como excepción temporal expresamente documentada y restringida, con política IPS adecuada, parches actuales, logging, responsable y caducidad; no equivale a VPN/ZTNA. Tras la migración, probar conexiones nuevas permitidas y accesos externos deliberadamente denegados: el servicio necesario debe funcionar por la ruta prevista y la accesibilidad pública no deseada debe desaparecer. Ante fallos, revisar primero reglas, NAT, routing y la ruta sustitutiva en vez de reabrir WAN ampliamente.

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.

DMZ en lugar de la LAN principal: Los servidores accesibles desde Internet deben estar en un segmento separado y una zona DMZ. Comprobar la asignación real en Network > Zones y Network > Interfaces; el nombre de una VLAN o zona no impone aislamiento por sí solo. En Rules and policies > Firewall rules, denegar DMZ a LAN por defecto, salvo conexiones explícitamente necesarias y restringidas. Un ejemplo adaptable permite WAN al servidor web DMZ solo por HTTPS y la red de administración a DMZ solo para el servicio administrativo aprobado, sin acceso general de DMZ a la LAN de clientes. Sustituir hosts y servicios por los objetos propios aprobados. Planificar zonas e interfaces, en el apartado sobre definir las direcciones de acceso antes de crear reglas, explica el modelo. Probar acceso permitido a la aplicación y conexiones DMZ a LAN denegadas con flujos nuevos, Rule ID esperado y Packet Capture cuando sea necesario. Ante accesos inesperados, revisar primero orden, zonas, objetos y permisos más amplios. Antes de introducir reglas de bloqueo web en producción, respetar la salvedad HTTP/HTTPS Drop sin resolver del apartado Action y registro del artículo de reglas; aquí no se promete un bloqueo web universal.

Internet solo para usuarios LAN autenticados: Activar Match known users en la regla de clientes prevista y seleccionar usuarios/grupos autorizados tras establecer una correspondencia fiable entre usuario y tráfico. El apartado Match known users explica autenticación y requisitos. Servidores, IoT y demás tráfico sin inicio de sesión necesitan reglas separadas y restringidas; una asignación IP no es autenticación. Ninguna regla amplia de fallback debe permitir el mismo tráfico de usuarios sin comprobar la identidad. Probar un usuario autorizado y otro desconocido/no autorizado, verificando que usuario, grupo, Rule ID y acceso real coinciden con lo previsto. Ante diferencias, revisar asignación, orden y fallback en vez de quitar la vinculación de usuarios.

Configurar Security Heartbeat conscientemente: El registro de gestión por sí solo no aísla endpoints comprometidos. Synchronized Security Heartbeat explica los requisitos: Network Protection, un Sophos Endpoint gestionado con licencia, la misma cuenta de gestión en la nube y Heartbeat activado. Configurar Minimum source HB permitted y, cuando corresponda para destinos internos, Minimum destination HB permitted en las reglas afectadas; no usar Heartbeat de destino para WAN. Green permite solo Green, Yellow permite Green o Yellow y No restriction también permite Red y dispositivos sin Heartbeat. Revisar expresamente las opciones separadas Block clients with no heartbeat y Block request to destination with no heartbeat: los dispositivos que nunca han enviado Heartbeat se bloquean solo cuando ambas están activadas. Los dispositivos sin Sophos Endpoint y las Web Exceptions que omiten Policy checks impiden garantizar aislamiento universal. Planificar un piloto aprobado con casos definidos de estado/sin Heartbeat, conexiones nuevas y logs; no provocar una infección en producción como prueba. Si falta la restricción esperada, revisar coincidencia de regla, requisitos, estado y excepciones y revertir solo el último cambio. Estas comprobaciones son pasos de aceptación para el entorno propio, no pruebas realizadas aquí en un appliance.

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 solo complementan la protección para un módulo y una ruta de tráfico establecidos. Desde SFOS 22 está documentada la comparación de la IPv4 de origen del tráfico entrante reenviado DNAT/WAF con MDR, NDR y Third-Party Threat Feeds. Para servicios locales como VPN Portal, la protección adicional establecida es la comparación de IPv4 de origen con Third-Party Feeds compatibles; esta ruta no pasa por una regla firewall de tránsito. Los indicadores de dominio/URL se refieren a comparaciones adecuadas del destino saliente, no a la IP de origen de un inicio de sesión entrante. Debe ser adecuada la ruta DNS/IPS/Application Classification o web/inspección TLS; las rutas URL HTTPS completas requieren descifrado. Los orígenes IPv6 no están cubiertos por esta protección.

Límite X-Ops sin resolver: El texto ATR y la matriz de tráfico SVG discrepan sobre ciertas direcciones de comparación X-Ops, en particular destino y origen local del tráfico saliente. No trasladar afirmaciones de MDR, NDR o Third-Party Feeds a Sophos X-Ops, tampoco para DNAT/WAF o portales locales. Hasta una aclaración autorizada, no depender de efectos discutidos: ACL restrictivas, reglas firewall/WAF, parches y MFA siguen siendo necesarios independientemente del feed. Verificar módulo, dirección, logs y efecto real solo mediante pruebas autorizadas y controladas. MDR Threat Feeds y la guía NDR enlazada más abajo amplían este límite.

Monitor detecta y registra coincidencias, pero no bloquea; Block debe configurarse para la ruta verificada. Una coincidencia por sí sola no demuestra bloqueo ni registro completo. Revisar el log ATR/firewall/WAF pertinente junto con la conexión real; allowlist, gestión de falsos positivos y responsabilidad siguen siendo necesarios. Los ejemplos siguientes solo se aplican dentro de estos límites de módulo y ruta.

Son especialmente útiles para:

• servidores web públicos detrás de WAF o DNAT,
• excepciones de transición RDP, SSH o admin expresamente aprobadas y temporales durante la migración a VPN/ZTNA; solo como protección adicional en el módulo/ruta establecido, no como recomendación de exposición pública,
• 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. Además, el envío básico de datos de configuración y uso está activado por defecto: el dispositivo 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. El uso, la verificación de fuentes y los límites de los procedimientos guiados se explican en Usar Sophos Assistant de forma segura.

Logging, alertas y SIEM

Las reglas firewall sin logging suelen ser inútiles para troubleshooting e incident response. La base documentada es la generación central de informes en Sophos Fusion (antes Sophos Central) más una solución SIEM elegida. Definir clases de eventos, destinatarios, responsable, plazo de conservación y supervisión con procedimiento de respuesta. Documentar explícitamente cualquier excepción arquitectónica: debe ofrecer una ruta equivalente conservada independientemente del firewall y supervisada; no toda arquitectura necesita destinos duplicados. La revisión periódica del Log Viewer local por sí sola no basta. MDR, XDR y NDR no son archivos de logs intercambiables. Con un evento de prueba autorizado e inocuo, verificar entrega a cada destino previsto, búsqueda en los logs almacenados y ruta de supervisión/alerta. Si falla la entrega, corregir selección de eventos, conectividad y destinatarios y repetir la prueba. Comprobar también conservación y permisos en el destino.

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:

1. Restringir acceso WAN a WebAdmin y SSH, mantener User Portal desactivado y conservar y probar VPN Portal para las descargas y SSO necesarios.
2. Activar MFA para administradores y Remote Access.
3. Limpiar cuentas admin locales, roles y políticas de contraseña.
4. Comprobar firmware, hotfixes, pattern updates y estado de soporte.
5. Documentar backup, SSMK, ruta de restore y prueba de recovery.
6. Revisar la necesidad de publicaciones DNAT, WAF y VPN; limitar grupos/recursos VPN, no autorizar Open group y probar accesos permitidos y denegados.
7. Limpiar reglas con Any, sin logging o sin owner claro.
8. Activar IPS, Spoof Protection, DoS Settings y Threat Feeds de forma dirigida.
9. Introducir Web, DNS, TLS y Zero-Day Policies por fases.
10. Establecer Health Check, logs conservados independientemente y supervisados, pruebas de entrega, alertas y revisiones periódicas con responsable y plazo de conservación.

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.

FAQ