Actualización de firmware de Sophos Firewall: preparación y buenas prácticas

Una actualización de firmware de Sophos Firewall solo debe aprobarse cuando estén claros la ruta de upgrade, el backup, el acceso, el estado del sistema, HA y la vía de recuperación. Realizar una actualización de firmware de Sophos Firewall explica la instalación en WebAdmin o mediante Sophos Fusion (antes Sophos Central).

⚠️ Antes de cada actualización: Deben estar disponibles un backup actual, el Secure Storage Master Key correspondiente y un plan de rollback concreto. Para SFOS 22 o posterior, también se debe completar la comprobación de upgrade a SFOS 22.

Aprobación en diez puntos

Un cambio de firmware está listo cuando los diez puntos siguientes se pueden responder con un sí:

1. La versión actual, la versión de destino y la ruta de upgrade compatible están documentadas.
2. Las release notes y los known issues se han comprobado para la plataforma y configuración utilizadas.
3. La licencia y el derecho a soporte permiten la instalación.
4. Hay disponibles un backup reciente, la contraseña del backup y el Secure Storage Master Key correspondiente.
5. El espacio libre, el estado del sistema y, en los modelos XGS Appliance afectados, el firmware SSD cumplen los requisitos.
6. El estado, los roles y la sincronización de HA son correctos; ambos nodos cumplen los requisitos.
7. La ventana de mantenimiento, los responsables, la hora límite y los criterios de rollback están definidos.
8. Se ha preparado un acceso de gestión local o alternativo.
9. Se han definido pruebas para WAN, VPN, DNS, NAT, WAF, autenticación y aplicaciones centrales.
10. Se han preparado la monitorización, la comunicación y las evidencias del cambio.

Si falta uno de estos puntos, la actualización no debe iniciarse bajo presión de tiempo. Aplazar una ventana de mantenimiento es más económico que un reimage o una intervención in situ no planificados.

Comprobar versión, plataforma y autorización

Un proceso operativo fijo comprueba al menos una vez al mes en Sophos Fusion o en Backup & Firmware > Firmware si hay una actualización disponible. También se siguen activamente las nuevas release notes y los maintenance releases anunciados. Cada MR debe entrar en la planificación porque incluso una versión puramente de mantenimiento puede incluir correcciones de seguridad importantes. La instalación, las pruebas y el rollback siguen realizándose de forma controlada durante una ventana de mantenimiento.

Release notes y ruta de upgrade

Antes del cambio, se deben comparar la versión actual de SFOS, la versión de destino y la ruta compatible en las release notes. También conviene revisar los problemas conocidos para la plataforma, HA, VPN, routing, autenticación y las funciones realmente utilizadas.

Sophos Firewall puede mostrar una advertencia para una ruta de migración no compatible. Si aun así se confirma el cambio, el firewall puede arrancar con Factory Configuration y perder la configuración existente. El rollback automático no protege frente a una ruta de upgrade no compatible. Solo se debe utilizar una ruta aprobada; para un cambio de versión incompatible, el método correcto es un reimage seguido de un restore.

⚠️ Límite de plataforma: SFOS 21.0 GA y las versiones posteriores no son compatibles con appliances de hardware XG y SG. Para estos equipos se debe planificar una migración a XGS Appliance antes del upgrade.

La comprobación de upgrade a SFOS 22 documenta las versiones de origen admitidas para un upgrade directo y la interpretación de los bloqueos de SFOS 22.0 MR2 Build 546. Esta matriz es específica de ese build y no una ruta universal para SFOS 22; para cualquier otro build de destino, se deben comprobar justo antes del cambio sus versiones de origen compatibles y los bloqueos aplicables en las release notes vigentes.

Hay que descartar expresamente dos bloqueos de SFOS 22:

• SFOS 22.0 MR1 y posterior: La configuración heredada de Remote Access IPsec que aún exista bloquea el upgrade. Debe resolverse siguiendo las instrucciones de migración vigentes de Sophos; no basta con desactivarla.
• SFOS 22.0 MR2 y posterior: El etiquetado VLAN heredado configurado por CLI en interfaces bridge bloquea el upgrade. Se deben identificar los bridges afectados y resolver primero esa configuración según las release notes.

La comprobación independiente cubre otros temas de SFOS 22, como espacio, nombres de interfaces, STAS, firmware SSD y compatibilidad de plataforma. Para otras versiones de destino se aplican sus release notes actuales.

⚠️ Antes del primer upgrade a SFOS 21 o posterior: En Certificates > Certificate authorities, buscar los nombres de CA de Let’s Encrypt reservados. Una entrada existente con exactamente el mismo nombre puede interrumpir la migración debido a NC-146082. No se debe eliminar la CA sin comprobarla: primero hay que asegurar y revisar el backup, la clave privada, los certificados dependientes y los servicios.

Licencia y soporte

Desde SFOS 19.0 MR1 se permiten tres cambios gratuitos a versiones GA, MR o EAP sin Enhanced Support o Enhanced Plus Support. Después, el firmware puede seguir descargándose, pero no instalarse; Install queda desactivado.

Pattern Updates, hotfixes, reimage, Mandatory Firmware Upgrades y Assistant Firmware Upgrades están exentos de esta regla de soporte. Antes de la ventana de mantenimiento se debe comprobar igualmente que:

• Administration > Licensing muestra la licencia y el derecho a soporte esperados.
• Sophos Fusion muestra el firewall y el número de serie correctos.
• La versión de destino y la descarga están disponibles.
• Se conocen el acceso a soporte, los contactos y la vía de escalado.

Si el cambio requiere acceso externo, debe probarse de antemano. Para Avanet, véase Configurar el acceso de soporte a Sophos Firewall.

Comprobar por separado los hotfixes automáticos

Los hotfixes no son un slot de firmware ni un Pattern Update. SFOS 22 comprueba cada 30 minutos si hay hotfixes disponibles y los instala automáticamente por defecto. Sophos recomienda no cambiar este ajuste. El estado se lee en Device Console antes y después de un cambio de firmware:

system hotfix show

Para SFOS 22, Sophos indica que los hotfixes ya instalados se conservan después de un firmware upgrade. En cambio, la lista específica de la versión en SFOS 23 se vuelve a evaluar después de cada cambio de versión, como se explica en el siguiente apartado. Si la comprobación muestra que la instalación automática está desactivada, primero se determina quién la desactivó y por qué. Sin una excepción documentada, se vuelve a activar:

system hotfix enable

system hotfix disable solo desactiva la instalación automática y no es un paso general de troubleshooting. Un estado activado tampoco demuestra que un hotfix concreto ya se haya aplicado o que funcione la ruta de descarga. Para un error específico se comprueban también el build, la hora, el acceso a Internet, los logs y la referencia de error de Sophos.

SFOS 23: verificar los updates de seguridad aplicados

En SFOS 23, Backup & firmware > Hotfix: Security updates muestra qué updates de seguridad mediante hotfix se han aplicado desde el cambio a la versión de SFOS actualmente en ejecución. Los hotfixes corrigen el sistema en ejecución sin un firmware upgrade y no deben confundirse con la lista de imágenes de firmware disponibles. La instalación automática de hotfixes debe estar activada; está habilitada por defecto. system hotfix show comprueba este ajuste, pero no demuestra que se haya aplicado una corrección de seguridad concreta.

Para documentar las evidencias del cambio antes y después de actualizar el firmware:

1. Documentar la versión activa de SFOS, incluido el build y el momento de la comprobación, y abrir la página Hotfix: Security updates.
2. Ordenar las entradas por fecha de aplicación y registrar los updates correspondientes al problema investigado. Para las vulnerabilidades descritas públicamente, la columna Advisory enlaza al aviso de seguridad correspondiente. Las correcciones internas pueden aparecer sin ID de CVE ni enlace a un aviso.
3. En HA, incluir ambos dispositivos en la comprobación posterior: el Primary actual recibe el hotfix, lo sincroniza con el Auxiliary y el hotfix también se aplica en este último. Una comprobación correcta en un dispositivo no sustituye las evidencias para el clúster.

Una vulnerabilidad puede aparecer varias veces porque pueden ser necesarios varios hotfixes para corregirla por completo. Por tanto, una sola entrada coincidente no demuestra de forma general que la protección sea completa. Para una corrección de seguridad concreta, deben contrastarse los requisitos del aviso de seguridad correspondiente con el build en ejecución y los updates realmente aplicados.

Notificaciones y logs: En System services > Notification list, dentro del área Firmware, activar la opción Email para Security updates. No hay notificaciones SNMP disponibles para estos updates. Los updates de seguridad mediante hotfix también aparecen en Log viewer; se generan sus Audit Logs y se reenvían a Sophos Fusion para Central Firewall Reporting. Estas indicaciones sobre notificaciones y logs se aplican a los updates de seguridad mediante hotfix, no de forma general a todas las correcciones mediante hotfix. Por tanto, la ausencia de un correo electrónico no demuestra por sí sola ni el éxito ni el fallo.

Después de un cambio de versión: SFOS instala primero el nuevo firmware y después aplica los hotfixes disponibles para esa versión. La lista de hotfixes anterior se elimina y se sustituye por la lista de la nueva versión; no es un archivo que abarque varias versiones. La misma corrección puede volver a aparecer porque se ha aplicado de forma independiente a la nueva versión. Si las correcciones anteriores ya están incluidas en el nuevo firmware, pueden no aparecer como entradas de hotfix separadas.

Una lista vacía solo significa que todavía no se han aplicado y mostrado updates de seguridad mediante hotfix para la versión actual. No demuestra ni falta de protección, ni protección completa, ni que la instalación automática funcione. En caso de duda, comprobar conjuntamente la versión activa y el build, el ajuste de CLI, el aviso de seguridad, las release notes y los logs; una página vacía no justifica desactivar preventivamente la instalación automática ni decidir un rollback.

Preparar backup, recovery y evidencias

Backup, SSMK y slots de firmware

Antes de la actualización se debe descargar un backup reciente de la configuración y comprobar qué Secure Storage Master Key le corresponde. También deben registrarse en el cambio la contraseña del backup, el acceso de administrador, la versión de firmware activa y la versión de destino.

Sophos Firewall conserva como máximo dos versiones de firmware: una activa y otra inactiva. Cada partición tiene su propio estado de configuración. Por tanto, un rollback no solo activa el firmware anterior, sino también su configuración. Los cambios realizados después del upgrade pueden perderse al volver atrás.

El rollback automático está disponible desde SFOS 20.0 para determinados errores de migración de configuración. Es una función de seguridad, pero no sustituye un backup ni el análisis de la causa y no está disponible para una ruta de upgrade no compatible.

El proceso completo se describe en Crear o restaurar un backup de Sophos Firewall. Si no es posible un cambio de versión normal, véase Reinstalar Sophos Firewall OS con una memoria USB.

Definir previamente los criterios de rollback

Antes de empezar se debe definir durante cuánto tiempo se analizará un error y cuándo se iniciará la recuperación. Un rollback resulta adecuado si WAN, HA, las VPN centrales o los servicios publicados críticos para producción no pueden estabilizarse dentro del plazo acordado. Para una sola regla, un objeto o un servicio externo, el troubleshooting específico suele ser mejor.

Para una Maintenance Release normal bastan como evidencias un backup, una captura de la página de firmware, la ventana y el resultado de las pruebas. Para cambios mayores, Sophos Firewall Config Studio ayuda a comparar configuraciones y el Audit Trail registra los cambios realizados durante la ventana de mantenimiento.

Comprobar el estado del sistema, el almacenamiento y HA

Almacenamiento y SSD

Antes de un upgrade importante, se debe comprobar en WebAdmin que:

• Control center no muestra advertencias críticas sin resolver.
• Backup & Firmware > Firmware muestra los slots de firmware esperados.
• Diagnostics > Log viewer no contiene errores recurrentes del sistema o de migración.
• Los servicios relevantes funcionan de forma estable.
• Firewall Health Check no contiene puntos abiertos que afecten al cambio.

Tras iniciar sesión mediante SSH, se abre Device Management > Advanced Shell y se comprueba el espacio libre:

df -kh

Si una partición está casi llena, no se deben eliminar a ciegas archivos, logs o reports en Advanced Shell. Primero se debe identificar la causa y utilizar el método de limpieza documentado. Véase Comprobar el almacenamiento de Sophos Firewall y gestionar reports.

SFOS 22 puede requerir espacio adicional. En algunos modelos XGS Appliance también es necesario actualizar primero el firmware SSD; WebAdmin muestra un aviso cuando se requiere. En un clúster HA, cada nodo se evalúa por separado. Si un appliance no cumple los requisitos, puede bloquear todo el upgrade.

En appliances antiguos o con problemas de I/O, base de datos o reports, también se debe comprobar el estado del SSD mediante SMART. Sin un hallazgo concreto, los cambios manuales en bases de datos o sistemas de archivos no son una preparación útil.

Sophos menciona un reinicio antes del upgrade solo como opción para vaciar la caché de memoria. No es un requisito y provoca una interrupción adicional. Por tanto, el reinicio solo debe realizarse en la ventana de mantenimiento, después de guardar los logs relevantes y confirmar la vía de recuperación del acceso de gestión. Si el firewall muestra una inestabilidad sin explicar, se debe detener el upgrade; un reinicio no debe sustituir el análisis de la causa ni hacer que el sistema parezca sano solo temporalmente.

Clúster HA

No es necesario desactivar HA para una actualización de firmware normal. Sin embargo, antes de aprobarla, ambos appliances deben estar conectados, sincronizados y claramente identificados como Primary y Auxiliary. Una actualización HA también requiere una ventana de mantenimiento, ya que el failover puede interrumpir brevemente sesiones, túneles VPN o pings concretos.

Antes de empezar, se debe documentar:

• Roles, estado de HA y sincronización.
• Estado del enlace HA.
• Requisitos de firmware, almacenamiento y SSD de ambos nodos.
• Acceso de gestión alternativo.
• Failover previsto y posibles interrupciones breves.

El appliance Auxiliary no debe actualizarse por separado. El artículo de ejecución explica la secuencia exacta de actualización del Auxiliary, failover y actualización del Primary anterior. Otros escenarios HA se describen en Clúster HA de Sophos Firewall: variantes y mantenimiento.

Los Pattern Updates se instalan en el Primary y después se sincronizan con el Auxiliary. Los hotfixes y su estado deben considerarse por separado y comprobarse en ambos equipos tras la ventana de mantenimiento.

Planificar la ventana de mantenimiento, Central y las pruebas

Ventana de mantenimiento y acceso

Una ventana de mantenimiento abarca más que la hora de instalación:

• Hora de inicio, límite máximo y decisión de rollback.
• Responsables del firewall, red, servidores, aplicaciones y soporte.
• Contacto local, acceso out-of-band o una segunda vía de gestión.
• Vía de comunicación si fallan WAN o Remote Access.
• Modo de mantenimiento para monitorización y alertas.
• Secuencia de pruebas para los procesos empresariales más importantes.

En ubicaciones remotas no se debe depender únicamente de Sophos Fusion o de la conexión VPN existente. Si precisamente esa vía falla durante la actualización, debe seguir disponible un acceso o una vía de escalado definidos.

Planificar el firmware mediante Sophos Fusion

Las actualizaciones de firmware gestionadas desde Central se preparan y supervisan en My Products > Firewall Management > Firewalls. Task Queue corresponde a políticas de grupo y tareas de configuración MDR/API y no muestra actualizaciones de firmware.

Mediante Central solo se pueden instalar versiones de destino que hayan alcanzado la fase Available to all del proceso de lanzamiento. Las actualizaciones planificadas comienzan según la zona horaria configurada en el firewall, no según la hora del navegador del administrador. En ubicaciones internacionales, la zona horaria, la ventana local y la versión de destino deben registrarse en el cambio.

Durante el upgrade gira un icono de estado junto al firewall y desaparece al finalizar. Después sigue siendo obligatorio comprobar localmente la versión de firmware activa. Si se produce un rollback automático, Central muestra el aviso correspondiente junto a la versión.

Configurar actualizaciones periódicas de mantenimiento

Recurring Firmware Upgrade permite definir una ventana de mantenimiento periódica para la cuenta de Sophos Fusion. El plan se aplica a todos los firewalls de la cuenta; cuando hay firmware adecuado disponible, los dispositivos que cumplen los requisitos se actualizan según ese plan. La función requiere una activación expresa y no garantiza que cada firewall reciba una versión nueva en cada ejecución. El backup, la ruta de actualización, el derecho a soporte y los demás puntos de aprobación de este artículo siguen siendo requisitos previos.

1. En My Products > Firewall Management > Firewalls, abrir Recurring Firmware Upgrade y activar Schedule maintenance updates.
2. Seleccionar Weekly (Default) para una frecuencia semanal y establecer el día de la semana y la hora. Para Monthly, seleccionar primero 1st, 2nd, 3rd, 4th o Last como semana del mes y, después, el día de la semana y la hora. No se trata de una fecha arbitraria del calendario.
3. En Staging firewalls, seleccionar los firewalls adecuados para la prueba piloto. Se pueden seleccionar varios dispositivos; el siguiente apartado explica la selección y sus límites.
4. Activar Schedule major version updates solo tras decidir expresamente que se automatizarán los cambios de versión principal. Sin esta opción, el plan se limita a actualizaciones de mantenimiento dentro de la versión principal actual. Con ella, el mismo calendario y el mismo proceso de staging se aplican también a las versiones principales que cumplen los requisitos. Las nuevas funciones y los cambios de arquitectura siguen necesitando una comprobación de compatibilidad independiente.
5. Utilizar Review para revisar los ajustes y corregirlos si es necesario. Solo Confirm confirma el plan.
6. Después, abrir el icono Scheduled junto a cada firewall afectado y comprobar la fecha y hora realmente programadas. Registrar en el cambio la versión de destino, la ubicación, la zona horaria del firewall y la ventana de mantenimiento local.

Una posible ventana mensual es Monthly, 2nd, domingo, 02:00. El ejemplo significa el segundo domingo del mes a las 02:00 en la zona horaria de cada firewall. No es una recomendación para todas las ubicaciones: la ventana debe ajustarse al horario operativo, la ejecución del backup, la disponibilidad de los responsables y las pruebas posteriores. Las ubicaciones con distintas zonas horarias no empiezan simultáneamente. Antes de confirmar, comprobar la zona horaria de cada firewall y las fechas y horas mostradas.

Para los pares HA, Sophos Fusion programa la tarea de actualización en el Primary. El Auxiliary se actualiza automáticamente mediante el proceso de actualización HA existente y no recibe una tarea manual independiente. Las comprobaciones HA y las posibles interrupciones del apartado Clúster HA también se aplican a la programación periódica. Ni la hora de inicio ni un icono de estado que indique éxito garantizan una hora fija de finalización o un funcionamiento sin interrupciones; la ventana de mantenimiento también debe incluir la validación y, si es necesario, el rollback.

El staging es un control técnico, no la aceptación de las aplicaciones

Los firewalls de staging reciben primero el firmware. Si el servicio considera que la actualización se ha completado correctamente, los demás firewalls se actualizan según el calendario. Si falla una actualización de staging, el despliegue se detiene y los firewalls afectados vuelven al firmware anterior. La causa debe resolverse antes de reanudar el calendario. El plan de backup y recuperación existente sigue siendo necesario: este mecanismo del servicio no debe interpretarse como una vía de recuperación garantizada para cualquier fallo posible.

Los dispositivos piloto deben representar adecuadamente las funciones y plataformas utilizadas, y su fallo debe ser gestionable. Por ejemplo, una ubicación que solo proporciona acceso a Internet no comprueba automáticamente la configuración WAF o VPN de otras ubicaciones. Si no se seleccionan firewalls de staging, todos los firewalls que cumplen los requisitos se actualizan directamente según el calendario; no hay una fase piloto previa.

⚠️ Sin aprobación manual intermedia: El éxito del staging que indica el servicio no demuestra que funcionen DNS, VPN, los servicios publicados o las aplicaciones empresariales. Las pruebas funcionales descritas más abajo siguen siendo necesarias. En este procedimiento no se ha acreditado un paso de aprobación manual entre el staging correcto y el resto del despliegue. Si primero debe realizarse una aceptación funcional del piloto, no se debe confiar en que el servicio espere hasta entonces; activar la programación automática solo cuando el procedimiento elegido cumpla este requisito.

Cambiar u omitir ejecuciones individuales o ajustar el staging

Sin un plan periódico, se configura una actualización individual mediante el icono de flecha azul junto al firewall y Schedule upgrade: seleccionar la versión de destino, elegir Immediately o At, seleccionar la fecha y hora para At y confirmar con Schedule upgrade. Una vez que existe un plan periódico, utilizar las siguientes acciones para firewalls individuales. No modifican el plan periódico de los demás firewalls.

• Override schedule: Abrir el icono Schedule junto al firewall y seleccionar Override schedule. En la ventana Firmware upgrades, seleccionar la versión de destino y Immediately o At. Para At, establecer la fecha y hora mediante el icono del calendario; confirmar con Override schedule. Immediately inicia la tarea sin una fecha posterior, por lo que solo debe utilizarse dentro de una ventana de mantenimiento ya aprobada. Comprobar la versión seleccionada mediante el icono Release notes; al pasar el cursor sobre el icono Clock, se muestran la fecha, la hora y la hora local del firewall del plan actual. Volver a comprobar la programación mostrada después del cambio.
• Skip occurrence: Abrir el icono Schedule y seleccionar Skip occurrence si solo se debe omitir la siguiente actualización programada de este firewall. La tarea se desplaza a la siguiente repetición. En un calendario semanal de los viernes, significa el viernes siguiente, no una excepción permanente. Comprobar la nueva fecha y hora y contrastarlas de nuevo con la ventana de mantenimiento.
• Remove from upgrade staging: Mediante el icono Schedule, abrir Remove from upgrade staging. En la ventana Recurring Firmware Upgrade Schedule, desmarcar el firewall correspondiente en Staging firewalls y ejecutar Review y Confirm. Esto elimina su función de piloto, no su participación en la programación general de firmware. Después, comprobar los dispositivos de staging que quedan seleccionados y la programación del firewall. Para que el dispositivo vuelva a ser piloto, seleccionarlo de nuevo en la selección de staging del plan periódico y confirmar el plan con Review y Confirm.

Si falta una versión de destino, comprobar primero la fase Available to all, en lugar de eludirla mediante una carga local improvisada. Si las fechas y horas no coinciden con el cambio, contrastar primero la zona horaria del firewall y la hora local mostrada por Clock. Tras un fallo de staging, comprobar el firmware activo, el mensaje de rollback y los logs, resolver la causa y realizar las pruebas funcionales reales antes de aprobar más actualizaciones. Cambiar una programación o eliminar un firewall del staging no revierte una actualización de firmware ya realizada; se aplican los procedimientos de rollback y recuperación descritos anteriormente.

Pruebas funcionales reales

Un ping por sí solo no demuestra que el firewall funciona correctamente tras la actualización. Deben definirse previamente pruebas concretas con origen, destino y resultado esperado:

• Acceso a Internet y resolución DNS.
• DHCP, VLAN, uplinks WAN y rutas SD-WAN.
• Site-to-Site VPN, Remote Access VPN y RED.
• Reglas de firewall, NAT y servicios publicados.
• WAF, Web Protection y TLS Inspection.
• LDAP, RADIUS, Microsoft Entra ID y otra autenticación central.
• Flujo de correo y aplicaciones críticas para el negocio.
• Syslog, SIEM y monitorización.

Validar después de la actualización

Tras el reinicio, primero se comprueban la versión activa y el slot inactivo esperado en Backup & Firmware > Firmware. Después:

• Comprobar en Control center si hay nuevas advertencias o un rollback automático.
• Verificar interfaces, WAN, SD-WAN, roles HA y sincronización.
• Validar VPN, RED, DNS, DHCP, reglas, NAT, WAF y autenticación con las pruebas preparadas.
• Comprobar el estado de patterns y hotfixes.
• Verificar la sincronización con Sophos Fusion, así como la monitorización, syslog y SIEM.
• Registrar en el cambio el resultado, los tiempos, las desviaciones y las tareas posteriores.

Si falla una sola función, se deben utilizar primero Log Viewer, Policy Test, Packet Capture y los service logs correspondientes. Véanse Probar una regla de firewall con Log Viewer, Policy Test y Packet Capture y Troubleshooting de Sophos Firewall: servicios y logs.

FAQ