Crear o restaurar una copia de seguridad de Sophos Firewall

Una copia de seguridad de Sophos Firewall es la base para actualizaciones de firmware, sustituciones de hardware, reimage, trabajos de HA y migraciones. Sin embargo, el archivo por sí solo no basta: para una restauración fiable también se necesitan la contraseña de la copia de seguridad, la Secure Storage Master Key (SSMK) correspondiente, una versión de destino compatible y un acceso de gestión operativo.

⚠️ Importante: Antes de un cambio arriesgado, el archivo de copia de seguridad, la contraseña, la SSMK, la versión de destino, la IP de gestión y la ruta de restauración deben estar disponibles y verificados. Una copia que solo se encuentre localmente en el firewall o cuya clave falte no constituye una vía de retorno fiable.

Ruta de recuperación y requisitos

Elegir la ruta de recuperación adecuada

Una restauración no es la primera medida adecuada para todos los problemas:

• Planificar una actualización de firmware: Actualización de firmware de Sophos Firewall: preparación y buenas prácticas.
• Instalar firmware en WebAdmin: Realizar una actualización de firmware de Sophos Firewall.
• Una tarea de Central está bloqueada: Comprobar la cola de tareas de Sophos Central Firewall Management.
• Reinstalar SFOS por completo: Reinstalar Sophos Firewall OS mediante una memoria USB.
• Fallo de hardware o RMA: Abrir un ticket de soporte de Sophos.
• Restaurar un clúster HA: Variantes de clúster HA de Sophos Firewall.

Antes de un reimage casi siempre se necesita una copia para restaurar. En cambio, un rollback de firmware no sustituye una copia de seguridad, porque el slot de firmware y el estado de configuración guardado son rutas de recuperación diferentes.

Contraseña de backup y Secure Storage Master Key

Las copias de seguridad actuales de Sophos Firewall están cifradas con una contraseña. Si la copia se creó después de configurar la SSMK, la restauración requiere la contraseña de la copia y también la SSMK vigente en ese momento.

La SSMK protege información sensible como contraseñas, secretos y claves. La configura la cuenta admin predeterminada y debe guardarse en un gestor de contraseñas u otro procedimiento de recuperación protegido. Al menos dos personas autorizadas deben saber dónde se encuentra.

Si la SSMK se cambia posteriormente, las copias antiguas siguen vinculadas a la clave anterior. Por ello, se deben conservar las versiones actuales y anteriores de la SSMK junto con su periodo y el firewall correspondiente.

Las copias legacy sin SSMK se pueden restaurar sin Master Key. Si se restaura una copia programada sin SSMK, el calendario guardado continúa, pero la frecuencia no se puede modificar hasta configurar una SSMK. Después se debe crear inmediatamente una nueva copia manual.

Paquete de recuperación por firewall

Además de la copia de seguridad, cada ubicación o tenant debe disponer de un paquete de recuperación protegido:

• última copia verificada con fecha y finalidad
• contraseña del backup y SSMK actual y anteriores
• nombre del firewall, número de serie, modelo y versión de SFOS
• credenciales WAN, datos del proveedor y Default Gateway
• asignación de interfaces, VLAN, LAG, bridges y puertos HA
• acceso de administrador local y break-glass
• asignación de licencia y Sophos Central
• servicios críticos con pruebas de aceptación concretas

La copia de seguridad y las credenciales no deben almacenarse juntas sin protección. El paquete de recuperación debe actualizarse después de cambios de personal, proveedor, puertos, HA o ubicación.

Crear y operar copias de seguridad de forma segura

Backup manual antes de cambios

Backup & Firmware > Backup & Restore

Backup Now crea una copia inmediata. Después, el archivo se debe guardar externamente y documentar al menos el nombre del firewall, el número de serie, la versión de SFOS, la fecha y la finalidad del cambio.

Un backup manual es especialmente importante antes de:

• cambios de firmware, interfaces, VLAN, routing, SD-WAN o VPN
• configuración de HA, cambios de roles o mantenimiento del clúster
• cambios importantes en reglas NAT, WAF o firewall
• reimage, Factory Reset, sustitución de hardware o migración de plataforma

Para cambios de mayor alcance, Sophos Firewall Config Studio también puede mostrar diferencias de configuración. Sin embargo, una comparación de Entities.xml no sustituye una copia de restauración.

Si solo hay que transferir o modificar una parte de configuración claramente delimitada, exportar e importar selectivamente la configuración describe el flujo separado en WebAdmin. Este import tampoco sustituye la ruta completa de recuperación.

Backups automáticos

En Frequency se pueden configurar copias diarias, semanales o mensuales. Según la configuración, los destinos disponibles son el almacenamiento local, FTP y correo electrónico.

Aspectos importantes para la operación:

• Una copia local no sirve si el appliance falla o se reinstala.
• En el firewall solo permanece la última copia local; las versiones anteriores necesarias deben guardarse externamente.
• Las copias por FTP y correo electrónico solo se consideran operativas después de una prueba real de entrega, descarga y descifrado.
• No utilizar caracteres especiales en Backup prefix, el nombre de usuario FTP o la contraseña sin haberlos probado.
• Las copias automáticas no sustituyen una copia manual reciente inmediatamente antes de un cambio arriesgado.
• El periodo de conservación, el acceso y el proceso de borrado deben ajustarse a las necesidades de protección de la configuración.

Las copias de firewall contienen información confidencial sobre redes, reglas, VPN, certificados y datos de cuentas. El acceso debe limitarse a administradores y responsables de recuperación; la contraseña y la SSMK se mantienen separadas, pero localizables en caso de emergencia.

Backups de Sophos Central

Sophos documenta actualmente dos rutas de navegación en Central, según la vista y la página de ayuda:

Global Settings > Products and Services > Firewall
My Products > Firewall Management > Backup

El firewall debe estar conectado a Sophos Central y habilitado para copias de configuración. Conectar Sophos Firewall con Sophos Central describe cómo establecer la conexión.

El calendario debe comprobarse siempre de forma explícita en vez de asumir un valor predeterminado. Cuando el primer firewall se añade automáticamente a un calendario vacío con Never, Central puede cambiarlo una única vez a Monthly y al primer día del mes. Los calendarios existentes no se modifican.

Otras propiedades fijas:

• Los backups se ejecutan a las 08:00 en la zona horaria de la región de Central; la hora no se puede cambiar.
• Central intenta crear la copia hasta cinco veces y, después, genera una alerta y un correo electrónico al administrador.
• Se conservan los cinco backups más recientes; además, se puede guardar de forma permanente exactamente uno.
• Al descargarlo, el backup vuelve a cifrarse con una contraseña nueva.
• Si el firewall se elimina de Central Management, Sophos borra sus backups de Central. Antes de cambiar de cuenta, realizar un RMA o limpiar el tenant, se deben descargar los archivos necesarios.
• En HA, Primary y Auxiliary se añaden al calendario, pero el backup lo crea el Primary.

Si un firewall registrado no aparece en el calendario, añadirlo en Schedule Backup. Si Send configuration backup to Sophos Central ya está activado, desmarcar la casilla, aplicar, volver a marcarla, aplicar de nuevo y aceptar después en Central la autorización de servicio pendiente.

Central es una buena ubicación de almacenamiento adicional, pero no sustituye la SSMK, el acceso local, los datos WAN ni una copia accesible de forma independiente.

Preparar y realizar una restauración

Preparación y prueba segura de restauración

Antes de restaurar, confirmar lo siguiente:

• están disponibles el archivo correcto, la contraseña y la SSMK vigente entonces
• la versión de origen, la versión de destino, el modelo y la plataforma son compatibles
• existe una copia externa del estado actual de la configuración
• se conocen la IP de gestión incluida en el backup y el acceso local
• están documentados los datos WAN, NTP, DNS, de licencia y de Central
• están definidos el destino HA y el orden de restauración
• están preparados el interface mapping y las asignaciones de puertos diferentes

⚠️ Atención: Una restauración sobrescribe la configuración actual y reinicia el firewall. Una advertencia sobre una ruta de migración no compatible no se debe confirmar de forma rutinaria; el firewall podría iniciarse después con la configuración de fábrica.

Una prueba real de restauración debe realizarse en un firewall de laboratorio o de sustitución adecuado. Antes de la prueba, desactivar o aislar las conexiones WAN, VPN y Central de producción para evitar conflictos de direcciones, túneles o registros duplicados.

Si no se dispone de un equipo de prueba, al menos se puede realizar una prueba organizativa: recuperar el backup del almacenamiento previsto, comprobar su asignación, confirmar la contraseña y la SSMK, evaluar la plataforma de destino y recorrer en el runbook el acceso de gestión y las pruebas de aceptación. Esto no sustituye una restauración real, pero elimina muchos problemas habituales en una emergencia.

Restaurar un backup

Backup & Firmware > Backup & Restore

1. Acceder al firewall de destino mediante WebAdmin.
2. Guardar el estado actual si todavía es posible.
3. En Restore configuration, seleccionar el archivo de backup con Choose file.
4. Introducir Encryption password y, si el backup está protegido con SSMK, también la SSMK vigente en ese momento.
5. Iniciar Upload and Restore.
6. Esperar al reinicio y a la restauración.
7. Abrir WebAdmin mediante la IP de gestión incluida en el backup.
8. Comprobar la zona horaria, NTP y la hora actual.
9. Validar la red, los servicios, VPN, HA y la conexión con Central.

La restauración elimina la copia almacenada localmente en el firewall de destino. Por tanto, el archivo utilizado debe seguir disponible externamente. En un appliance nuevo, primero se debe completar el asistente de configuración y después restaurar el backup.

Lo que una restauración no resuelve automáticamente

• La contraseña de la cuenta admin predeterminada no se restaura desde el backup; el firewall de destino conserva su contraseña actual. Si se ha perdido, el artículo independiente sobre recuperación de contraseña explica la recuperación serie para appliances físicos y las limitaciones de los firewalls virtuales y cloud.
• Después del reinicio, la IP de gestión, Device Access, las rutas y los servicios vuelven a proceder del backup.
• La zona horaria, NTP y la hora se deben comprobar como estado operativo actual.
• Los valores dependientes del modelo o de la instancia pueden volver a sus valores predeterminados si no son válidos en el destino.
• Sophos Central solo permanece registrado cuando se restaura en el mismo firewall. Un firewall diferente o un clúster HA se debe registrar de nuevo; después hay que comprobar Security Heartbeat, ZTNA, Central Management, Backup, Reporting, Task Queue y la asignación de grupos.
• Los logs, reports y datos de monitorización externos no forman parte de un rollback completo de la configuración.

Durante una migración al modo FIPS 140-3, el estado del backup también es decisivo: Un backup con FIPS desactivado restaura el estado sin FIPS y, por tanto, es una vía de retorno, no una transferencia sin cambios al modo FIPS.

Restaurar en otro hardware y otras plataformas

Compatibilidad y versiones de SFOS

Antes de una migración, anotar la versión de origen, la versión de destino, el modelo de destino y la plataforma. El Backup-restore compatibility check forma ahora parte de Sophos Firewall Config Studio. Abrir allí Backup-restore compatibility y comprobar la compatibilidad de los modelos XG/XGS, así como de los módulos Flexi Port y transceptores utilizados. La herramienta se aplica a SFOS 20.0 MR2 y versiones posteriores; además, tener en cuenta la información de actualización de las release notes actuales y las indicaciones del SFOS 22 Upgrade Check.

Para SFOS 22 se aplican límites estrictos:

• SFOS 22.0 GA y versiones posteriores no son compatibles con hardware XG o SG.
• Las copias con legacy CLI VLAN tagging en interfaces bridge no se pueden restaurar en SFOS 22.0 GA o versiones posteriores. La limpieza se describe en Comprobar las Bridge VLAN antes de SFOS 22.
• Legacy Remote Access IPsec bloquea la actualización a SFOS 22.0 MR1 y versiones posteriores. Al restaurar o importar en estas versiones, la configuración antigua no se migra; antes se debe cambiar al método compatible. El procedimiento se describe en Migrar Legacy Remote Access IPsec.

Backup-Restore Assistant e interface mapping

El Assistant solo aparece cuando se cumplen todas las condiciones:

• El backup procede de XG, SG con SFOS, XGS, virtual o Cloud con SFOS 19.5 MR4 o posterior.
• El destino ejecuta SFOS 20.0 MR2 o posterior.
• El destino es un appliance XGS, virtual o Cloud.

El Assistant no aparece en destinos XG o SG ni con backups de SFOS 19.5 MR3 o anteriores. En ese caso, el firewall realiza el mapping automáticamente; después hay que comprobar con especial atención las interfaces, zonas, gateways, VLAN, HA link, SD-WAN, NAT y VPN.

El Assistant también se puede utilizar en el mismo appliance compatible para mover VLAN o configuraciones de interfaces a otro puerto físico.

Interfaces físicas y lógicas

• Puerto físico: asignarlo deliberadamente a un puerto de destino o dejarlo sin asignar; comprobar el cableado, la zona y la función WAN/LAN.
• VLAN o alias: sigue la interfaz parent asignada; el parent port debe ser correcto desde el punto de vista operativo.
• LAG o bridge: se vuelve a crear a partir de los puertos físicos asignados; comprobar el número de members y la configuración del switch.
• RED o Cellular: se migra la configuración asociada; probar la conexión específicamente después de la restauración.

Pseudo-ports, breakout, management y HA

• Pseudo-port: conserva la configuración, pero no procesa tráfico. Mover routing, NAT, VLAN y reglas a un puerto activo.
• Breakout Root Port: solo se pueden asignar root ports, no members individuales. El destino necesita un número y una combinación de puertos compatibles.
• Management-Port: se asigna a un Management-Port existente o se conserva como Pseudo-Port. Planificar previamente la red de gestión y el acceso local.
• Dedicated HA-Link: el tipo de puerto debe mantenerse; el Assistant no puede cambiar el puerto HA-Link. En LAG debe coincidir el número de members; en VLAN, el VLAN ID; y en monitored ports, el estado de destino.

Antes de eliminar un Pseudo-Port, mover todas las rutas y configuraciones NAT, firewall y VLAN dependientes. Después, en Network > Interfaces, establecer la zona en None y reiniciar el firewall durante una ventana de mantenimiento. A continuación, comprobar que se haya eliminado el puerto; los Pseudo-Ports no vinculados con una configuración VLAN no se eliminan automáticamente.

El Backup-Restore Assistant reasigna las interfaces, pero no convierte en compatible una configuración Wireless o bridge que el destino no admite. Estas dependencias deben corregirse en el origen antes de crear el backup de migración o volver a planificarse para el destino.

Destinos HA, Wireless, virtuales y Cloud

Para conservar la configuración HA, un backup de HA solo se puede restaurar en un clúster HA. Se puede configurar primero el nuevo clúster y restaurar el backup en el Primary, o restaurar primero y configurar HA después. A continuación, comprobar los roles, la versión de firmware, el Dedicated HA-Link y los monitored ports.

Las migraciones Wireless tienen límites adicionales:

• Para Wireless-to-Non-Wireless, se deben eliminar las Wireless Networks antes de crear el backup.
• Los backups de modelos Gen.2 XGS Wireless no se pueden restaurar en modelos XG o Gen.1 XGS Wireless.
• Al migrar modelos Wireless anteriores a Gen.2 XGS se aplican límites adicionales para SSID, WPA, bridge mode y bandas de radio.

LocalWiFi y configuraciones bridge durante la migración

Para restaurar un backup de XG Wireless o Gen.1 XGS Wireless en un modelo Gen.2 XGS W se aplican estos requisitos y restricciones:

• En LocalWiFi0 y LocalWiFi1 solo hay asignados SSID con WPA2 como mínimo.
• El cifrado no utiliza ni TKIP ni TKIP/AES.
• Ninguna interfaz Wireless forma parte de un bridge físico.
• LocalWiFi0 y LocalWiFi1 utilizan conjuntamente un máximo de ocho SSID únicos.
• Si ambas radios utilizan la misma banda de frecuencia, solo se restauran los ajustes de LocalWiFi0.

La diferencia entre los bridges es decisiva. Para un Wireless Network del tipo Bridge to AP LAN, los modelos Gen.1 XGS 87w, 107w, 116w, 126w y 136w conectan la red Wi-Fi local a la LAN mediante un bridge físico. Los modelos Gen.2 XGS 88w, 108w, 118w y 128w no son compatibles con este diseño; en ellos se utiliza Bridge to Ethernet con exactamente un puerto Ethernet y la zona LAN en Wireless > Access points > LocalWiFi > Advanced settings. Configurar Wi-Fi directamente en Sophos Firewall describe la configuración en Gen.2.

Si el backup de Gen.1 todavía contiene un bridge físico con la interfaz de un Wireless Network del tipo Bridge to AP LAN, la restauración en Gen.2 falla. Sophos documenta este comportamiento como Known Issue NC-135094. Si OSPF, OSPFv3, RIP, SPX Portal Setting o Quarantine hacen referencia a esta interfaz, la restauración finaliza, pero la configuración dependiente no funciona en Gen.2.

Por tanto, antes de crear el backup de migración hay que comprobar en Network > Interfaces si una interfaz Wireless forma parte de un bridge y documentar todos los ajustes dependientes. No se debe eliminar un bridge de producción sin preparación: primero hay que migrar la dirección IP, la zona, DHCP, los puertos conectados y las dependencias de routing a un diseño compatible con Gen.2 durante una ventana de mantenimiento. Después se crea un backup nuevo. En el destino se configura Bridge to Ethernet y se prueban específicamente los SSID, el Security mode, las bandas de frecuencia, DHCP y los servicios que dependían previamente de la interfaz.

Antes de una migración XG a XGS también resulta útil la comparación entre XG y XGS.

Para firewalls virtuales y Cloud, el procedimiento integrado de backup y restore de Sophos es la única ruta de recuperación de SFOS compatible. Sophos no admite snapshots de hypervisor, imágenes de Cloud ni backups de terceros para este fin, ya que pueden provocar problemas de integridad de datos o configuraciones no compatibles.

Validar después de la restauración

Control técnico

Inmediatamente después de la restauración, comprobar:

• IP de WebAdmin, redes de gestión permitidas y Device Access
• interfaces, zonas, VLAN, bridges, LAG y alias interfaces
• WAN, PPPoE, Default Gateway, rutas estáticas y rutas SD-WAN
• reglas de firewall, NAT y WAF, incluido su orden
• IPsec, SSL VPN, Sophos Connect, RED y Remote Access
• certificados, TLS Inspection, DNS, DHCP, NTP y Authentication Server
• estado HA, roles y sincronización
• estado de licencia, Pattern Updates, Hotfixes y sincronización con Central
• Log Viewer, Syslog, Central Reporting y reporting local

Según el problema, pueden ayudar Log Viewer, Policy Test y Packet Capture, Packet Capture en WebAdmin y la vista general de Services and Logs. Sophos no indica una ruta de logs SSH universal y fiable para errores generales de restauración, por lo que aquí no se recomienda ningún comando shell.

Pruebas de aceptación

Que WebAdmin sea accesible no demuestra que el tráfico de producción funcione. Para cada ubicación se deben documentar el origen concreto, el destino, la regla esperada y la entrada de log prevista para estas pruebas:

• Gestión: acceso desde la red de gestión y un segundo inicio de sesión de administrador.
• Internet: un cliente de prueba alcanza un destino externo definido mediante la regla, NAT y ruta WAN correctas.
• DNS y DHCP: un cliente recibe una dirección y resuelve nombres internos y externos.
• Site-to-Site VPN: los hosts definidos son accesibles en ambas direcciones.
• Remote Access: un usuario de prueba verifica login, MFA, perfil, DNS y un destino interno.
• WAF o DNAT: una prueba externa confirma el certificado, la regla, el backend y el logging.
• Autenticación: AD, LDAP, RADIUS, STAS o Entra SSO identifica correctamente a un usuario de prueba.
• Logging: el tráfico de prueba es visible en Log Viewer, Syslog, Central Reporting o SIEM.
• HA: los roles, el estado del clúster y la sincronización coinciden con el plan.

Si WAN, DNS, Remote Access o HA no funcionan, no modificar varias áreas al mismo tiempo. Delimitar el error con la hora, el origen de prueba, el destino, la regla y un extracto del log, y volver a probar después de cada corrección.

Troubleshooting y operación

Errores habituales

• El backup solo está en el firewall: no estará disponible tras un fallo o reimage; almacenarlo externa y protegidamente.
• Falta la SSMK: los datos protegidos no se pueden restaurar; documentar las claves actuales y anteriores.
• Archivo sin referencia al equipo o la versión: se selecciona el backup equivocado; registrar nombre del firewall, número de serie, versión y fecha.
• Sin backup del estado actual antes de restaurar: no existe una vía de retorno al estado anterior.
• Se desconoce la IP de gestión restaurada: el firewall parece estar offline; documentar previamente la dirección y el acceso local.
• Hora o NTP incorrectos: VPN, certificados, autenticación y Central pueden fallar.
• Se confirma una ruta de restore no compatible: la restauración falla o el destino arranca con la configuración de fábrica.
• Interface mapping sin comprobar: WAN, VLAN, VPN o HA-Link terminan en puertos incorrectos.
• Se ignoran los límites Wireless: el backup es incompatible o la configuración inalámbrica no funciona como se esperaba.
• Se ignora el contexto HA: la configuración o los roles del clúster se pierden o se inician incorrectamente.
• Central es la única copia: al eliminar el firewall de Central también se borran sus backups.
• Solo se comprueba WebAdmin: los fallos de routing, NAT, VPN, WAF, DNS o logging pasan inadvertidos.

Ritmo operativo

Periódicamente:

• comprobar los backups automáticos, la entrega, la recuperación y la conservación
• revisar el almacenamiento de backups, los permisos y las SSMK actuales y anteriores
• mantener actualizados el paquete de recuperación y las pruebas de aceptación
• comprobar de forma aleatoria el archivo, la contraseña, la SSMK y la compatibilidad de destino

Antes de cambios importantes:

• crear un backup manual, guardarlo externamente y etiquetarlo de forma inequívoca
• definir el acceso de gestión, la ruta de restauración y los criterios de cancelación
• en migraciones, comprobar la compatibilidad, la versión de SFOS y el interface mapping

Después de una restauración:

• documentar por completo el control técnico y las pruebas de aceptación
• corregir las desviaciones y, si es necesario, comparar con Config Studio
• crear un nuevo backup del estado de destino verificado y actualizar el paquete de recuperación