Sophos Firewall en modo failsafe: proceder con seguridad

Cuando Sophos Firewall muestra failsafe, se debe tratar la situación como un incidente de recuperación. La documentación pública de SFOS 22 no describe un comando general de diagnóstico que identifique de forma fiable la causa de cualquier estado failsafe. Por eso, este runbook no utiliza ni show failure-reason ni un sustituto inventado.

Primero se guarda sin cambios el mensaje visible y después se evalúan la plataforma, el rol HA, el build del firmware y el último cambio. Mientras la causa no esté demostrada, no se deben modificar manualmente bases de datos, firmas, reglas ni archivos del sistema.

⚠️ Documentar antes de reiniciar: Un reinicio puede cambiar el error visible. Fotografiar toda la consola, incluidos los primeros mensajes de boot, y anotar la hora, el modelo, el número de serie, la versión completa de SFOS con el build y, en HA, el Node afectado. Reset to Factory Defaults, Remove Firewall Rules y los cambios manuales en la base de datos o el sistema de archivos no son un diagnóstico inicial seguro.

Capturar con seguridad el mensaje failsafe

1. Utilizar la consola directa disponible: local o serie en hardware y la consola del hipervisor en una VM. Esta vía sigue disponible cuando WebAdmin o la red no son accesibles.
2. Fotografiar literalmente el mensaje junto con las líneas de boot inmediatamente anteriores. No sustituir el mensaje real por un ejemplo de Internet.
3. Anotar plataforma y modelo, número de serie, build completo de SFOS, hora del fallo y última hora conocida de funcionamiento.
4. Registrar los cambios recientes, especialmente upgrade del firmware, rollback, restore, reglas u objetos, recursos de VM, discos virtuales, vNIC y eventos de almacenamiento.
5. En HA, anotar Node afectado, rol, estado del peer y último cambio de rol. No reiniciar ambos Nodes a la vez ni desactivar HA por mera sospecha.

Que WebAdmin no sea accesible no demuestra por sí solo un estado failsafe. Si el firewall arranca normalmente y el tráfico sigue fluyendo, pero solo la interfaz no responde, primero corresponde la comprobación específica o reiniciar la GUI de WebAdmin. En cambio, un mensaje failsafe explícito se trata como un problema de arranque o recuperación.

Delimitar las causas documentadas

Sophos documenta varios desencadenantes concretos, pero no exhaustivos, para SFOS 22. Las Release Notes de SFOS 22.0 MR2 Build 546 incluyen failsafe por una partición de configuración llena (NC-181331), un logging daemon que no se iniciaba en el dispositivo HA Primary (NC-180110), failsafe en el dispositivo Primary inicial tras el upgrade a 22.0 GA (NC-177441) y Failed to start Red server service (NC-178906). Estas entradas demuestran defectos conocidos y corregidos, no una matriz general de reparación.

Si el estado observado, la plataforma o el rol HA y el historial de versiones coinciden con precisión con una entrada de las Release Notes, se incluyen el Issue ID y el build instalado en el caso de soporte. Una coincidencia parcial no demuestra la misma causa ni que un cambio de firmware no coordinado vaya a recuperar el firewall. Sophos solo cita literalmente el mensaje mostrado para NC-178906. Si el firewall arranca normalmente y solo un túnel RED está desconectado, corresponde seguir la resolución de problemas de RED.

Appliance de software

Para un appliance de software SFOS 22 instalado en hardware propio, Sophos establece, entre otros, estos requisitos mínimos relevantes para el sistema en funcionamiento e indica expresamente que el firewall entra en modo fail-safe si no se cumplen:

• CPU x86-64 y Legacy BIOS
• al menos 4 GB de RAM
• HDD o SSD de al menos 32 GB; se recomiendan 64 GB
• 2 tarjetas de red

Documentar el estado actual antes de modificar nada. Ante una diferencia confirmada, consultar a Sophos Support si basta con un ajuste de recursos compatible o si hace falta un reimage controlado. No improvisar cambios de disco ni del modo de arranque. Diferencias entre plataformas y requisitos de recursos explica con más detalle los appliances de hardware, virtuales y de software.

Appliance virtual y de hardware

En una VM, registrar las vNIC y los discos virtuales presentes y conectados, CPU, RAM, controlador de disco y cambios recientes del hipervisor. Las plataformas cloud y de hipervisor tienen requisitos compatibles propios; no aplicar automáticamente los valores del appliance de software a todos los despliegues virtuales.

En hardware, incluir en el caso de soporte fallos de boot repetidos, eventos de alimentación, indicios de I/O o SSD, temperatura y ventiladores. Un reinicio correcto no descarta un defecto. Ayudan las comprobaciones de temperatura y ventiladores, estado del SSD y preparación de RMA.

Guardar logs y backup

Si Advanced Shell sigue accesible, sysinit.log, syslog.log y, ante un indicio de base de datos, postgres.log son logs oficiales de troubleshooting relevantes. Para el mensaje RED documentado, incluir también red.log. Este runbook no ofrece deliberadamente comandos shell para copiar, eliminar o reparar: la vía de acceso y las herramientas disponibles pueden variar durante la recuperación.

Cuando WebAdmin vuelva a estar disponible, generar un archivo de troubleshooting o CTR. El procedimiento se describe en Guardar logs de Sophos Firewall para soporte. Los logs y archivos pueden contener datos confidenciales de red, usuarios y configuración y solo deben transmitirse de forma protegida a destinatarios autorizados.

Antes de un restore o reimage deben estar disponibles un backup adecuado, su contraseña y el Secure Storage Master Key asociado. Backup y restore de Sophos Firewall explica estas dependencias.

Usar fsck-on-nextboot solo con Sophos Support

system fsck-on-nextboot no es una comprobación general de estado. Sophos advierte que solo debe utilizarse por recomendación de Sophos Support. Está previsto para errores de montaje de /sig, /conf o /var; si el hardware o SSD no están en buen estado, la comprobación puede dañar el sistema de archivos.

La sintaxis documentada de Device Console es:

system fsck-on-nextboot [on | off | show]

on fuerza la comprobación de todas las particiones en el siguiente reinicio, off la cancela antes de ese reinicio y show muestra la configuración actual; el valor predeterminado es off. SFOS puede programar automáticamente la comprobación en modo failsafe si no se inicia la base de datos de configuración, informes o firmas, si no se puede aplicar una migración o si no se encuentra el deployment mode.

No reiniciar únicamente porque se muestre on. Incluir primero en el mismo plan de mantenimiento la recomendación del soporte, acceso estable a consola, alimentación, backup, posibles errores de I/O y, en HA, estado del peer. Sophos no indica duración fija ni garantía de éxito.

Elegir una ruta de recuperación segura

• Requisito de software claramente inferior al mínimo: Guardar el estado actual y ejecutar en una ventana de mantenimiento el ajuste o reimage confirmado por Sophos Support. Observar el siguiente arranque desde la consola.
• Mensaje que coincide con un problema conocido de las Release Notes: Guardar build completo e Issue ID. Solicitar a Sophos Support que confirme la ruta de recovery, upgrade o rollback para este estado.
• Incidente HA: Proteger el peer que sigue operativo. No realizar reinicios simultáneos ni cambios no planificados de rol o clúster. Consultar High Availability en Sophos Firewall.
• Error de almacenamiento, base de datos, reglas, NPU, I/O o desconocido: No retirar archivos ni elementos de configuración por sospecha. Escalar a Sophos Support con la consola, los logs y la cronología.
• Reimage: Utilizarlo solo si Sophos Support o un plan de recuperación documentado lo justifica y se cumplen todos los requisitos de restore. Consultar Reinstalar Sophos Firewall OS.

Después de cualquier medida, no comprobar solo WebAdmin y el login. Verificar arranque normal en consola, estado HA, interfaces, routing y conexiones necesarias de Internet y VPN. Si vuelve el mensaje, añadir la hora y la salida sin cambios al caso en vez de improvisar otras modificaciones.

Escalar a Sophos Support

Escalar el incidente failsafe cuando la causa no pueda limitarse a una diferencia de recursos documentada y corregible sin riesgo. El caso de Sophos Support debe incluir como mínimo:

• foto o copia completa de los mensajes failsafe y de boot
• modelo, número de serie, plataforma y build completo de SFOS
• hora del fallo, última hora funcional y cronología de cambios
• en HA: Node, rol, estado del peer y último cambio de rol
• logs relevantes o CTR e indicios de almacenamiento, I/O, NPU o alimentación
• backup disponible y estado de contraseña y SSMK, sin revelar secretos en el texto del ticket
• reinicios o cambios ya realizados y sus resultados

Si WebAdmin está disponible y Sophos solicita acceso remoto, activar temporalmente Support access en Diagnostics > Support access. Compartir el Access ID generado solo mediante el canal de soporte acordado; el acceso se puede desactivar en cualquier momento.