Sophos Firewall en modo failsafe: comprobar la causa

Si un Sophos Firewall se inicia en modo failsafe, SFOS ha detectado un error crítico y no ha iniciado el funcionamiento normal. Según la causa, el procesamiento de paquetes, las interfaces y el acceso de administración pueden fallar total o parcialmente. Por eso, no se debe deducir de un puerto de administración que aún sea accesible que el firewall sigue ofreciendo una protección fiable.

El primer paso más importante no es realizar un Factory Reset o reimage, sino guardar la causa que ha detectado SFOS:

1. Conectarse mediante la consola local, serie o del hipervisor.
2. Abrir Device Console en el menú failsafe.
3. Ejecutar el siguiente comando de solo lectura:

show failure-reason

Después, la consola puede mostrar, por ejemplo, lo siguiente:

failsafe> show failure-reason
Unable to apply Firewall Framework

failsafe> es solo el prompt y no se debe introducir. El mensaje exacto puede ser distinto. Lo importante es fotografiar o copiar la salida sin modificar y las primeras líneas visibles de la consola. Si SSH todavía funciona mientras el error está presente, también se puede acceder a Device Console por esta vía; en caso de fallo, la consola local, serie o del hipervisor sigue siendo el método más robusto.

⚠️ Guardar antes de reiniciar: Un reboot puede cambiar o eliminar temporalmente el estado de error visible. Antes del reinicio se deben documentar, como mínimo, el mensaje de error, la versión de SFOS con el build, el rol del appliance y la hora. Reset to Factory Defaults, Remove Firewall Rules y las intervenciones manuales en la base de datos o el sistema de archivos no son medidas de diagnóstico y pueden destruir configuraciones o pruebas importantes.

Qué significa el modo failsafe

Failsafe es un estado de protección y recuperación. SFOS lo inicia cuando un componente necesario para el funcionamiento seguro del firewall no arranca correctamente. Los mensajes conocidos y los casos reales de error afectan, por ejemplo, a la base de datos de configuración, al framework del firewall, al conjunto de reglas, al servicio de logging o de red, a la base de datos de firmas o, en un modelo XGS debidamente equipado, a la Network Processing Unit (NPU). Esta no es una matriz de reparación completa; la salida concreta de la consola sigue siendo determinante.

Que WebAdmin no sea accesible no demuestra por sí solo un estado failsafe. Si el tráfico sigue fluyendo y solo la interfaz no responde, primero corresponde realizar la comprobación específica o reiniciar la GUI de WebAdmin. Un estado failsafe real se identifica en la consola. Que además sigan funcionando un acceso de administración o algunas interfaces depende de la causa y no demuestra que el sistema esté en buen estado.

Esta distinción es importante: si solo ha fallado un servicio, puede ser conveniente reiniciarlo de forma específica. En modo failsafe, en cambio, falta un requisito crítico para el arranque. Reiniciar varios servicios por mera sospecha tiende entonces a ocultar la causa en lugar de corregirla.

Comprobar la causa del failsafe con show failure-reason

show failure-reason se ejecuta en Device Console, no en Advanced Shell. El comando no modifica la configuración. Muestra la categoría de error que SFOS ha detectado durante el arranque.

La salida es un punto de partida y no constituye una instrucción de reparación completa. Los siguientes grupos de mensajes ayudan a clasificar el problema:

• Configuration database: El firewall no ha podido iniciar correctamente su base de datos de configuración. Antes de cualquier reparación manual se guardan el mensaje de error, el build, el último cambio y el backup disponible. No se deben eliminar ni modificar archivos de la base de datos.
• Firewall framework o firewall rules: SFOS no ha podido aplicar la base para el procesamiento de paquetes o el conjunto de reglas. Son relevantes los últimos cambios de reglas, objetos, restore o firmware. Eliminar indiscriminadamente todas las reglas de firewall provocaría una pérdida de datos y no sería un diagnóstico inicial adecuado.
• Logging daemon: Un servicio crítico de logging no se ha iniciado. Además del mensaje de error, se comprueban el estado del almacenamiento, el build y los logs. No se deben vaciar a ciegas los reports o logs antes de guardar los datos necesarios.
• Network daemon: Los componentes de red no han podido iniciarse correctamente. En appliances virtuales, la comprobación debe incluir las vNIC existentes, el orden de los adaptadores y los cambios en el hipervisor.
• Signature database: No se ha podido cargar una base de datos de firmas necesaria. Son relevantes el estado de los patterns, el almacenamiento y la relación temporal con las actualizaciones; los archivos de firmas no se eliminan manualmente.
• NPU: En un modelo XGS con NPU, la primera línea de la consola puede indicar ya Network processing unit error. Aunque después show failure-reason no proporcione una salida útil, se guarda toda la consola y se prepara un caso de soporte o de hardware.

La escritura exacta de un mensaje puede variar según la versión de SFOS. Para el soporte, la salida sin modificar es por ello más valiosa que un resumen propio como El firewall no arranca.

Comprobar la plataforma y el último cambio

El siguiente paso depende de si el problema afecta al hardware, a un appliance virtual o de software, o a un clúster HA. El mismo mensaje de error no debe dar lugar automáticamente a la misma medida.

Firewall virtual y appliance de software

Un firewall virtual puede pasar al modo failsafe por el mero hecho de tener recursos inadecuados. Para appliances con SFOS 22 operados localmente en VMware, Hyper-V, KVM y Citrix, Sophos especifica actualmente como mínimo:

• 1 vCPU
• 4 GB vRAM
• 2 vNICs
• 32 GB Primary Disk
• 80 GB Report Disk

Además, las vCPU y la vRAM configuradas no pueden superar la licencia adquirida. Los valores mínimos son únicamente límites técnicos de arranque y no un dimensionamiento productivo para IPS, TLS Inspection o un rendimiento elevado.

La Auxiliary Disk incluida en las imágenes de VM es esta Report Disk independiente. No es opcional ni sustituye a la Primary Disk. Para AWS y Azure se utilizan, en cambio, los tipos de instancia cloud compatibles y los tamaños específicos de la plataforma.

En el hipervisor se comprueba si ambos discos y todas las vNIC previstas siguen presentes, conectados y asignados en el orden esperado. Cualquier cambio posterior en CPU, RAM, controlador de disco o red virtual debe incluirse también en la cronología del incidente. Las diferencias entre plataformas y los requisitos de recursos se explican con más detalle en un artículo específico.

Para un appliance de software con SFOS 22, no hay duda sobre x86-64, Legacy BIOS, un mínimo de 4 GB de RAM y dos tarjetas de red. Sin embargo, dos páginas actuales de Sophos se contradicen con respecto al disco: la descripción general de plataformas indica un mínimo de 10 GB, mientras que la página específica y más reciente del appliance de software indica un mínimo de 32 GB y recomienda 64 GB. Por tanto, no existe un límite uniforme publicado por Sophos. Para instalaciones nuevas, Avanet recomienda de forma conservadora un mínimo de 32 GB y, si es posible, 64 GB; así se sigue la página de producto más específica y se evita un sistema que ya tenga poco espacio al arrancar.

Durante un intento de recuperación con una causa incierta, no se deben modificar los recursos varias veces de forma arbitraria. Primero se documenta el estado actual y después se realiza una corrección planificada con una prueba de arranque definida.

Appliance de hardware y NPU

En un XGS físico también se tienen en cuenta los eventos de alimentación, la temperatura, los ventiladores, los errores de SSD o I/O y los primeros mensajes de arranque. Un error de NPU en un modelo XGS equipado con esta unidad no justifica probar comandos de reset o de servicio que no estén documentados. Si el mensaje vuelve a aparecer o el propio diagnóstico falla, el siguiente paso correcto es abrir un caso de soporte con una posible preparación de RMA.

Un solo reinicio satisfactorio no demuestra que se haya resuelto un problema de hardware. En caso de fallos repetidos, también resultan útiles las comprobaciones disponibles para temperatura y ventiladores y para el estado del SSD.

Failsafe en un clúster HA

En HA, primero se determina qué Node está afectado y si el peer procesa el tráfico productivo de forma estable. Se documentan Primary o Auxiliary, el estado del clúster, el último cambio de rol y la misma hora en ambos appliances.

No se deben reiniciar ambos Nodes simultáneamente ni desactivar HA por mera sospecha. Un cambio no coordinado puede poner en peligro la ruta que todavía funciona, cambiar la situación de los roles u obligar a reconstruir el clúster. Configurar High Availability en Sophos Firewall explica los roles, la sincronización y los logs específicos de cada Node; aun así, la causa concreta del failsafe se guarda en el Node afectado.

Después de una actualización de firmware o un restore

Si el modo failsafe aparece inmediatamente después de un upgrade, rollback o restore, se registran la versión de origen, la versión de destino y el número de build completo. En SFOS 22, Sophos corrigió con MR2 Build 546 varias causas concretas de failsafe, entre ellas errores tras el upgrade a GA, un logging daemon que no se iniciaba, una partición de configuración llena y determinados objetos de servicio defectuosos. El resumen de SFOS 22 MR2 enumera los Issue ID corregidos.

Esto no significa que todos los eventos failsafe se resuelvan con una actualización. Primero se comprueba si el mensaje de error y el build instalado coinciden realmente con un fix conocido. Un cambio de firmware sigue necesitando un backup, una ventana de mantenimiento, un plan de HA y una ruta de retorno. Para ello se utilizan la preparación de una actualización de firmware y la comprobación de upgrade a SFOS 22.

Failed to start Red server service

Si el firewall muestra exactamente este mensaje en modo failsafe, el comportamiento observado coincide con NC-178906. Sophos corrigió este error de failsafe en SFOS 22.0 MR2 Build 546. En un build anterior, después de guardar las pruebas se evalúa una ruta controlada de recuperación y upgrade al build 546 o posterior. Si el mensaje aparece en el build 546 o posterior, el Issue ID por sí solo no demuestra la causa; se abre un caso de soporte con los logs guardados.

Antes de reiniciar o cambiar el firmware, se guardan el número de build completo, la hora del fallo, el Node HA afectado y las entradas de sysinit.log, red.log y syslog.log correspondientes al momento del fallo. No se eliminan por mera sospecha interfaces RED, el patrón de firmware RED ni la configuración RED, y tampoco se reinicia repetidamente el servicio RED. Si el firewall arranca con normalidad y solo un túnel RED permanece offline, se utiliza en su lugar la solución de problemas de RED.

Guardar pruebas antes de la recuperación o el reinicio

Para poder realizar un análisis fiable, siempre que sea posible se recopila lo siguiente antes de la primera medida que modifique el estado:

• salida completa de show failure-reason y primeras líneas de arranque visibles
• modelo, número de serie y plataforma de hardware, virtual o de software
• versión exacta de SFOS, incluidos MR y build
• hora del fallo y última hora conocida con funcionamiento correcto
• últimos cambios de firmware, restore, reglas, objetos, interfaces, recursos de VM o almacenamiento
• en HA: Node afectado, rol, estado del peer y hora del último failover
• backup actual disponible y Secure Storage Master Key correspondiente
• en VM: vCPU, vRAM, vNIC, Primary Disk, Report Disk y límite de licencia
• síntomas recurrentes como reboots o errores de I/O, NPU, temperatura o almacenamiento

Si todavía se puede acceder a Advanced Shell, también se pueden guardar extractos de logs adecuados. Estos ejemplos solo leen las últimas 200 líneas y no modifican el sistema:

tail -n 200 /log/sysinit.log
tail -n 200 /log/syslog.log
tail -n 200 /log/postgres.log

sysinit.log es el log central del arranque del sistema, syslog.log contiene eventos del kernel y del sistema, y postgres.log resulta útil para la base de datos de configuración. Según show failure-reason, se aplica el mismo comando tail de solo lectura al log detallado correspondiente, por ejemplo:

tail -n 200 /log/networkd.log
tail -n 200 /log/sigdb.log
tail -n 200 /log/npu-startup.log

networkd.log corresponde a las interfaces físicas y virtuales, sigdb.log a la base de datos de firmas y npu-startup.log solo a los modelos de hardware con NPU. No todos los archivos existen en todas las plataformas. La asignación adicional se encuentra en Servicios y archivos de log de Sophos Firewall. Los extractos de logs pueden contener datos confidenciales y se deben transmitir de forma protegida.

Cuando WebAdmin vuelva a estar disponible, también se debe guardar un archivo CTR o de troubleshooting. El procedimiento se describe en Guardar logs de Sophos Firewall para el soporte.

Elegir el siguiente paso seguro

Después de guardar las pruebas, la ruta de recuperación se puede decidir con mayor precisión:

1. Diferencia clara de recursos en una VM o un appliance de software: Documentar el estado actual, comprobar los límites de la licencia y los valores mínimos actuales, apagar la VM de forma controlada, corregir exactamente la diferencia confirmada y observar el siguiente arranque.
2. Indicio de almacenamiento o logging: Comprobar la partición y el tipo de datos afectado mediante métodos de solo lectura. No eliminar archivos con rm. Comprobar de forma segura el espacio de almacenamiento y los reports muestra las vías previstas de diagnóstico y limpieza.
3. Error directamente después de un cambio de firmware: Comparar el build con los problemas conocidos y solo entonces decidir de forma controlada entre el Maintenance Release actual, un rollback o el soporte.
4. Indicio de NPU, I/O o hardware recurrente: Preparar un caso de soporte y, si es necesario, una RMA. Un reboot que funcione temporalmente no descarta un defecto.
5. Error de arranque de base de datos, framework, reglas o causa desconocida: Guardar la salida y los logs, y abrir un caso de Sophos Support con una descripción completa del error. No eliminar manualmente archivos de base de datos, conjuntos de reglas o firmas.
6. Reimage como recuperación: Utilizarlo solo cuando lo justifiquen daños en el sistema operativo, el soporte o el plan de recuperación documentado. Antes deben estar disponibles el backup, la contraseña y la SSMK. El procedimiento completo se describe en Reinstalar el sistema operativo de Sophos Firewall.

Después de cada medida no se comprueba únicamente WebAdmin. Los aspectos decisivos son el arranque normal de la consola, el estado correcto de HA, el estado de las interfaces y del routing, las conexiones de Internet y VPN, y si vuelve a aparecer el mismo mensaje de error. Si la causa sigue sin estar clara o se repite, no se debe ocultar con más cambios espontáneos.