Crear o restaurar una copia de seguridad de Sophos Firewall

Una copia de seguridad de Sophos Firewall es más que un archivo para emergencias. Es la base para actualizaciones de firmware, reemplazo de hardware, migraciones de XG a XGS, reimagen, trabajos de HA y procesos de recuperación limpios. Si la copia de seguridad, la Secure Storage Master Key y la compatibilidad de restauración no están preparadas, un cambio planificado puede convertirse rápidamente en una interrupción innecesariamente larga.

El artículo explica cómo crear y restaurar copias de seguridad de Sophos Firewall, qué información adicional debe documentarse y qué verificaciones son importantes antes de una restauración en otro hardware o plataformas.

⚠️ Importante: Una copia de seguridad solo es útil si es localizable, descifrable y compatible con el entorno de destino. Antes de actualizaciones de firmware, reimagen, cambios de HA o migraciones, se debe verificar conscientemente el archivo de copia de seguridad, la contraseña de la copia de seguridad, la Secure Storage Master Key, la versión de destino, el acceso de gestión y el proceso de restauración.

Vídeo tutorial

¿Qué camino de recuperación es adecuado?

La copia de seguridad y la restauración a menudo son solo una parte del problema. Dependiendo de la situación, es más adecuado un procedimiento diferente:

• Planificar actualización de firmware: Actualización de firmware de Sophos Firewall: Preparación y mejores prácticas.
• Instalar imagen de firmware en WebAdmin: Realizar actualización de firmware de Sophos Firewall.
• Actualización central o política de grupo atascada: Revisar cola de tareas de gestión de firewall de Sophos Central.
• Reinstalar completamente el OS del firewall: Reinstalar Sophos Firewall OS: Reimagen con USB.
• Defecto de hardware, error repetido o RMA: Abrir ticket de soporte de Sophos: Preparación y portal.
• Restaurar o modificar clúster HA: Variantes de clúster HA de Sophos Firewall.

En la práctica, estos procedimientos se superponen. Antes de una reimagen, casi siempre se necesita una copia de seguridad. Antes de un caso de soporte, son importantes el número de serie, la versión de firmware, los registros y los pasos previos. Después de una actualización controlada por Central, la cola de tareas puede explicar por qué un cambio aún no ha llegado al firewall.

Por qué una copia de seguridad por sí sola no es suficiente

Una copia de seguridad descargada reduce el riesgo, pero no resuelve automáticamente todos los problemas de recuperación. En la práctica, también se necesita:

• un lugar de almacenamiento seguro fuera del firewall
• una asignación clara al firewall, número de serie, ubicación y versión de SFOS
• la Secure Storage Master Key (SSMK) adecuada
• la contraseña de la copia de seguridad, si la copia de seguridad fue cifrada
• información documentada sobre WAN, VLAN, HA, VPN y licencias
• un plan de restauración verificado para reemplazo de hardware, reimagen o migración

Especialmente antes de una actualización de firmware, una reimagen con USB o una verificación de actualización de SFOS 22, la copia de seguridad no solo debe crearse, sino también verificarse técnicamente.

Antes de la primera copia de seguridad: verificar la Secure Storage Master Key

Antes de utilizar copias de seguridad manuales o programadas de manera productiva, se debe establecer y documentar de manera segura la Secure Storage Master Key (SSMK). Sin esta clave, una restauración en un dispositivo nuevo o en ciertos escenarios de recuperación puede fallar.

Esto es especialmente relevante cuando:

• se prepara un firewall de reemplazo
• se planea una migración a otro modelo
• se trasladan configuraciones entre hardware, appliance virtual y nube
• las copias de seguridad se almacenan fuera del firewall

El SSMK debe estar en un gestor de contraseñas u otro procedimiento de recuperación seguro. No debe ser conocido solo por una persona. Si la clave se busca solo en caso de emergencia, ya se ha perdido un tiempo valioso de recuperación.

Importante: las copias de seguridad antiguas siguen vinculadas al SSMK con el que fueron creadas. Si la clave se cambia o restablece más tarde, la nueva clave no basta para esas copias antiguas. Por eso también deben documentarse versiones anteriores del SSMK con fecha, periodo de validez y firewall afectado. Cambiar el SSMK no es una limpieza casual, sino un cambio relevante para la recuperación.

Las copias de seguridad programadas sin SSMK configurado también son un caso especial. Sophos Firewall puede seguir generando esas copias según el plan restaurado, pero falta la protección adicional del SSMK. Además, la frecuencia de backup solo debería considerarse realmente gestionable cuando el SSMK está configurado. Para firewalls productivos tiene sentido: configurar SSMK, crear después un nuevo backup manual y solo entonces valorar los backups programados como una vía de recovery fiable.

Crear copia de seguridad: manual y automática

La ruta en WebAdmin es:

Backup & Firmware > Backup & Restore

Copia de seguridad manual antes de cambios

Para una copia de seguridad inmediata, use Backup Now. La copia de seguridad no debe quedarse solo en la carpeta de descargas del navegador, sino que debe almacenarse conscientemente.

Antes de estos trabajos, siempre se debe crear una copia de seguridad manual:

• Actualización de firmware o hotfix con riesgo de reinicio o cambio de comportamiento
• Reestructuración de interfaces, VLAN, enrutamiento, SD-WAN o VPN
• Configuración de HA, cambio de roles de HA o mantenimiento de HA
• Cambios importantes en NAT, WAF o reglas de firewall
• Reimagen, restablecimiento de fábrica o reemplazo de hardware
• Migración de XG a XGS, de hardware a virtual o de virtual a nube

Después de la descarga, se debe documentar al menos la fecha, el nombre del firewall, el número de serie, la versión de SFOS y el propósito de la copia de seguridad. Para cambios importantes, más tarde ayuda una comparación con Sophos Firewall Config Studio para rastrear las diferencias de configuración antes y después del cambio.

Configurar copias de seguridad automáticas

Para que no se olviden las copias de seguridad, se debe configurar una copia de seguridad automática. En Frequency se pueden definir copias de seguridad diarias, semanales o mensuales.

Las copias de seguridad generadas automáticamente se pueden almacenar localmente en el firewall, en un servidor FTP o por correo electrónico. Lo importante no es tanto el lugar de almacenamiento como el proceso alrededor:

• Quien almacene copias de seguridad por correo electrónico o en un servidor externo debe verificar el cifrado y la protección de acceso.
• Las copias de seguridad locales en el firewall no ayudan si el dispositivo debe ser reemplazado o reinstalado por completo.
• En el propio firewall solo sigue siendo relevante la última copia local. Quien deba conservar estados anteriores debe descargarlos conscientemente o asegurarlos externamente.
• En copias de seguridad por FTP o correo electrónico no basta con comprobar la configuración. También deben probarse entrega, recuperación, permisos y localizabilidad.
• Las copias de seguridad de Central son prácticas, pero no deben ser el único camino de recuperación conocido.
• Las copias de seguridad automáticas no reemplazan una copia de seguridad manual justo antes de cambios arriesgados.
• Las copias de seguridad antiguas deben gestionarse con un plazo de retención, acceso y proceso de eliminación. En backups FTP y Backup prefix no conviene usar caracteres especiales complejos a ciegas. Sophos tiene restricciones para el prefijo, el usuario y la contraseña. Después de configurarlo, lo que cuenta no es el ajuste guardado, sino una prueba real de backup, descarga y restore.

Si el firewall está conectado a Sophos Central, también puede ser útil el almacenamiento central de copias de seguridad de configuración. La conexión a Central se describe en el artículo Conectar Sophos Firewall con Sophos Central.

Clasificar correctamente Central Backups

Sophos Central puede programar backups de configuración de firewall, crearlos inmediatamente, descargarlos y tenerlos disponibles para un restore posterior. La ruta en Central es:

My Products > Firewall Management > Backup

Los Central Backups son útiles porque no residen en la propia firewall y forman parte del Account Health Check. Aun así, esta vía de backup requiere una operación consciente:

• La frecuencia global de backup en Sophos Central empieza como Never. Al configurarla manualmente mediante Schedule Backup, la UI puede mostrar otro valor sugerido. Cuando una firewall se añade automáticamente como la primera al calendario de backup, Sophos Central ajusta la frecuencia una vez a Monthly, con inicio el primer día del mes. Si una firewall no aparece en el calendario pese a tener activado Send configuration backup to Sophos Central, ayuda Schedule Backup > Add new firewall; alternativamente, quitar la casilla, Apply, activarla de nuevo, Apply y luego ejecutar accept-services en Sophos Central.
• Los Central Backups programados se ejecutan a las 08:00 en la zona horaria de la región de Sophos Central. Esta hora no se puede ajustar.
• Sophos Central intenta crear el backup hasta cinco veces. Si sigue fallando después, se genera un alert y un correo al administrador de Central.
• Central conserva los cinco backups más recientes. Un backup puede guardarse adicionalmente de forma permanente hasta que se sustituya o elimine.
• Al descargar desde Central, el backup se vuelve a cifrar con una nueva contraseña. Esa contraseña también debe formar parte del procedimiento de recovery.
• Si una firewall se elimina de Sophos Central Management, Sophos elimina también los archivos de Central Backup asociados. Antes de cambiar de account, limpiar tenants o tramitar un RMA, los backups necesarios deben descargarse.
• En clústeres HA, Primary y Auxiliary se incluyen en la planificación de backup, pero el backup lo genera el Primary.

Central Backup es, por tanto, una buena vía adicional de recovery, pero no justifica descuidar la restauración local, SSMK, acceso de administración y documentación del sitio.

Almacenar copias de seguridad de forma segura

Las copias de seguridad del firewall contienen información sensible sobre la estructura de la red, objetos, reglas, servicios, VPNs, certificados y, en algunos casos, datos de cuentas protegidos. Por lo tanto, deben tratarse como archivos de infraestructura confidenciales.

Para la operación, estas reglas son útiles:

• No almacenar archivos de copia de seguridad sin cifrar en carpetas de equipo generales.
• Limitar el acceso a las copias de seguridad del firewall a administradores y responsables de recuperación.
• Documentar la contraseña de la copia de seguridad y el SSMK por separado, pero de manera localizable.
• Usar una convención de nombres clara por ubicación o firewall.
• Después de salidas de administradores, verificar si el almacenamiento de copias de seguridad y el acceso al gestor de contraseñas aún son adecuados.
• Documentar por separado la información relevante para la restauración, como datos de acceso WAN, PPPoE, datos de proveedores estáticos o asignación de puertos de HA.

Una copia de seguridad no es un reemplazo para la documentación operativa. Especialmente en clústeres HA, múltiples enlaces WAN o entornos VPN complejos, también debe documentarse qué interfaces, datos de proveedores y dependencias deben verificarse primero después de una restauración.

Preparar un paquete de recuperación por firewall

En caso de emergencia, se pierde la mayor parte del tiempo no al cargar el archivo de copia de seguridad, sino al buscar la información adicional. Por lo tanto, para firewalls productivos, debe existir un pequeño paquete de recuperación por ubicación o cliente.

Este paquete debe incluir:

• Última copia de seguridad verificada: base para restauración, migración o reimagen.
• Contraseña de copia de seguridad y Secure Storage Master Key: necesario para copias de seguridad cifradas y datos protegidos.
• Número de serie, modelo y versión de SFOS: importante para soporte, licenciamiento y verificación de compatibilidad.
• Datos WAN e información del proveedor: necesario si después de la restauración falta acceso a Internet o conexión a Central.
• Asignación de interfaces y puertos: decisivo en migraciones de XG a XGS, puertos Flexi, troncos VLAN y HA.
• Acceso de administrador y de emergencia: permite acceso local si VPN, Central o SSO aún no funcionan.
• Licencias y asignación a Central: evita confusiones en hardware de reemplazo, firewalls virtuales o instancias en la nube.
• Servicios críticos y pruebas de aceptación: muestra rápidamente después de la restauración si VPN, NAT, WAF, DNS, DHCP y logging funcionan nuevamente.

Este paquete no debe estar como un archivo de texto sin protección junto a la copia de seguridad. Es mejor una combinación de gestor de contraseñas, documentación operativa interna y responsabilidad clara. Al menos dos personas autorizadas deben saber dónde se encuentran esta información y cómo acceder a ella en caso de emergencia.

Después de cambios de personal, remodelación de ubicaciones, cambio de proveedor, cambio de HA o gran migración, el paquete de recuperación debe ser revisado. Una copia de seguridad formalmente actualizada ayuda poco si la IP WAN documentada, la asignación de puertos o la asignación a Central ya no son correctas.

Preparar la restauración

Antes de una restauración, primero se debe aclarar cuál es el objetivo. Una restauración en el mismo dispositivo después de una mala configuración se evalúa de manera diferente a una restauración después de una reimagen, reemplazo de hardware o cambio de plataforma.

Preparación:

• ¿Existe una copia de seguridad reciente del estado actual?
• ¿Está el archivo de copia de seguridad claramente asignado al firewall correcto?
• ¿Están disponibles la contraseña de la copia de seguridad y el SSMK?
• ¿La versión de SFOS del sistema de destino coincide con la copia de seguridad?
• ¿Está el camino de restauración aprobado para la versión de origen, versión de destino y plataforma de destino?
• ¿Se restaurará en hardware idéntico, otro modelo, appliance virtual o nube?
• ¿Aparecerá el Asistente de restauración de copia de seguridad o se realizará una asignación automática de interfaces?
• ¿Está involucrado HA o se restaurará una copia de seguridad de HA en un dispositivo único?
• ¿Existe un acceso de gestión local si WAN, VPN o Central no funcionan inmediatamente después de la restauración?
• ¿Se conoce qué IP de WebAdmin quedará activa después de la restauración?
• ¿Están documentados zona horaria, servidores NTP y posibles ajustes manuales de fecha/hora?

⚠️ Una restauración sobrescribe la configuración actual. En un firewall productivo, se debe crear una nueva copia de seguridad del estado actual antes de la restauración, incluso si la configuración actual es incorrecta. En rutas de migración no admitidas, el firewall puede iniciar con configuración de fábrica después de una confirmación. Esta advertencia no debe tratarse como un mensaje normal de restauración y confirmarse.

Lo que una restauración no resuelve automáticamente

Una restauración restablece la configuración, pero no sustituye una comprobación operativa completa. Después del reinicio vuelven a aplicarse la IP de gestión, configuración de interfaces, Device Access, certificados, rutas y servicios de la configuración restaurada. Por eso WebAdmin puede estar de repente disponible en otra IP que durante la primera configuración del firewall de reemplazo.

Además, estos puntos deben revisarse conscientemente:

• Los valores manuales de fecha y hora no se restauran completamente como estado operativo. Zona horaria, NTP y hora actual deben comprobarse después de la restauración.
• La contraseña de la cuenta estándar admin no se sustituye por el backup durante el restore. La firewall de destino conserva la contraseña Default Admin existente.
• Logs, reports y datos externos de monitoring no sustituyen una copia de seguridad de configuración y deben guardarse por separado o centralizarse.
• Certificados, VPNs, conexión a Central, destinos Syslog y notificaciones pueden existir técnicamente tras una restauración, pero fallar por hora, DNS, routing o plataforma de destino modificada.
• Una restauración en otro hardware no resuelve automáticamente de forma técnica y operativa las diferencias de puertos e interfaces. El mapping debe encajar con el cableado y el modelo de zonas.
• Ajustes dependientes del modelo pueden volver a valores predeterminados al restaurar en otra plataforma si no encajan con el dispositivo de destino. Esto puede afectar, por ejemplo, opciones de rendimiento y puertos específicas de hardware o instancia.
• El registro en Sophos Central solo se conserva al restaurar en la misma firewall. Restaurar en otro hardware o HA desregistra la firewall de Sophos Central. Después del restore hay que registrarla de nuevo y comprobar individualmente, reconfigurando si es necesario, Security Heartbeat, Sophos ZTNA, Central Management, Central Backup, Central Reporting y la Task Queue. En políticas de grupo, la pertenencia al grupo también forma parte de esta verificación posterior.

Planificar prueba de restauración sin riesgo de producción

Una prueba de restauración es útil, pero no debe realizarse a la ligera en un firewall productivo. El objetivo no es sobrescribir regularmente dispositivos productivos, sino verificar de manera comprobable si se cumplen los requisitos de recuperación más importantes.

Una prueba de restauración segura puede verse así según el entorno:

• Recuperar el archivo de copia de seguridad del almacenamiento planificado.
• Verificar nombre de archivo, fecha, nombre del firewall, número de serie y versión de SFOS.
• Controlar contraseña de copia de seguridad y SSMK en el gestor de contraseñas.
• Ejecutar verificación de compatibilidad de restauración de copia de seguridad para el modelo de destino planificado.
• Documentar asignación de interfaces y desviaciones de puertos antes de una migración.
• Verificar la versión de destino planificada contra las rutas de actualización y restauración de copia de seguridad admitidas.
• Probar en un laboratorio o firewall de reemplazo si la copia de seguridad es aceptada en principio.
• Después de una restauración de prueba, no dejar activas sin control conexiones VPN productivas, accesos WAN o conexiones a Central.

Si no hay un laboratorio o firewall de reemplazo disponible, al menos es posible una prueba organizativa: encontrar la copia de seguridad, verificar el acceso, confirmar contraseña/SSMK, evaluar la plataforma de destino con el Compatibility Check y simular el proceso en el manual de recuperación. Esto no reemplaza una restauración real, pero previene muchos problemas clásicos de emergencia.

Para ubicaciones críticas, también debe estar claro cómo se volverá a acceder al firewall después de una reimagen o reemplazo de hardware: acceso local, puerto de gestión, datos WAN, estado de licencia, asignación a Sophos Central y contacto en el sitio. Esta información no solo pertenece a la copia de seguridad, sino a una documentación operativa separada.

Restaurar copia de seguridad

La restauración también se realiza en:

Backup & Firmware > Backup & Restore

Procedimiento básico:

1. Acceder al firewall de destino a través de WebAdmin.
2. Guardar el estado actual, si aún es posible.
3. En Restore configuration, seleccionar el archivo de backup con Choose file.
4. Si es necesario, introducir Encryption password o SSMK.
5. Iniciar Upload and Restore.
6. Esperar el reinicio y la restauración.
7. Abrir WebAdmin mediante la IP de gestión de la configuración restaurada.
8. Comprobar zona horaria, NTP y hora actual.
9. Luego verificar red, servicios, VPN, HA y conexión a Central.

Durante el restore, la configuración importada sustituye la configuración actual, elimina el backup guardado localmente en la firewall y reinicia la firewall. Por eso, el backup utilizado debe seguir disponible externamente antes del restore. Si la única copia está en la firewall de destino, el proceso de recovery es innecesariamente frágil.

Cuando se despliega un nuevo Sophos Firewall o uno de reemplazo, la copia de seguridad se puede aplicar después del primer acceso al dispositivo. La dirección IP inicial y el primer acceso dependen del modelo y tipo de implementación. En dispositivos de hardware, el acceso inicial local a través de la IP de gestión estándar o el asistente de configuración es común.

Una vez que el firewall es accesible y se ha completado el asistente de configuración, la restauración se puede realizar como se describe anteriormente.

Restaurar en otro hardware o plataformas

Especialmente en migraciones entre XG y XGS o entre hardware, appliance virtual y nube, se debe verificar antes de la restauración si la copia de seguridad es compatible. Sophos ofrece una verificación de compatibilidad de restauración de copia de seguridad pública para ello.

Además, la versión de destino debe ser adecuada. Sophos distingue entre rutas de actualización y restauración de copia de seguridad aprobadas y migraciones no aprobadas. Si un firewall advierte antes del reinicio que la migración planificada no está soportada, no se debe simplemente confirmar. Después de una migración no aprobada confirmada, el firewall puede iniciar con configuración de fábrica, perdiendo así la configuración actual.

Para una restauración productiva, esto significa:

• primero anotar versión de origen, versión de destino, modelo de destino y plataforma
• llevar el firewall de destino a una versión de SFOS compatible antes de la restauración
• ejecutar verificación de compatibilidad de restauración de copia de seguridad para la combinación concreta
• tomar en serio y documentar las advertencias en el diálogo de restauración o actualización
• en caso de duda, probar primero en hardware de reemplazo o en un entorno de prueba

Asistente de restauración de copia de seguridad y asignación automática de interfaces

Que aparezca el Asistente de restauración de copia de seguridad depende de condiciones concretas de versión y plataforma, no solo de que la copia sea “más reciente”:

• La copia de seguridad procede de un dispositivo (XG, SG con SFOS, XGS, virtual o cloud) que ejecutaba SFOS 19.5 MR4 o posterior.
• La restauración se realiza en SFOS 20.0 MR2 o posterior.
• La restauración se realiza en una serie XGS, un appliance virtual o cloud.
• En una restauración a la serie XG o SG, el asistente no aparece.

El asistente ayuda a asignar interfaces cuando se restaura una copia de seguridad de XG, SG con SFOS o XGS en una serie XGS, appliance virtual o firewall en la nube. Esto es especialmente importante si el firewall de destino tiene menos puertos, nombres de puertos diferentes, variantes inalámbricas o módulos Flexi-Port.

En copias de seguridad de SFOS 19.5 MR3 o anteriores, así como en cualquier restauración a XG/SG, el asistente no está disponible. Entonces, el firewall asigna interfaces automáticamente. Esto es más rápido, pero más arriesgado, ya que no se confirma conscientemente la asignación en el asistente. Después de una restauración de este tipo, se deben verificar cuidadosamente interfaces, zonas, puertas de enlace, VLANs, enlace HA, rutas SD-WAN, reglas NAT y VPNs.

Los casos especiales más importantes del interface mapping de un vistazo:

Los pseudo-puertos indican que queda abierta una decisión técnica de puertos. Después del restore deben revisarse, trasladarse a un puerto activo o eliminarse limpiamente. Para eliminar uno, se abre el pseudo-puerto en Network > Interfaces, se pone la zona en None y se reinicia el firewall. Los pseudo-puertos sin vincular con configuración VLAN no se eliminan automáticamente y necesitan limpieza adicional.

Otros puntos a aclarar tras el restore:

• ¿Coinciden los puertos disponibles y los tipos de zona con la plataforma de destino?
• ¿Deben reasignarse interfaces después de la restauración?
• ¿Se restaurará una copia de seguridad de HA en un dispositivo único o viceversa?
• ¿Está el sistema de destino en un estado de firmware razonable?
• ¿Debe reemplazarse un dispositivo XG o SG antiguo debido al ciclo de vida o compatibilidad con SFOS 22?
• ¿Están claros el estado de la licencia, el número de serie y la asignación a Sophos Central después de la restauración?

Si la asignación de puertos difiere, generalmente se debe verificar o ajustar una asignación de interfaces después de la restauración. Antes de migraciones de XG a XGS, también es relevante el artículo ¿Cuál es la diferencia entre un firewall XG y XGS?.

Después de trabajos de restauración o migración importantes, una comparación de configuraciones puede ayudar. Usar Sophos Firewall Config Studio muestra cómo comparar copias de seguridad antes y después de un cambio y verificar diferencias inesperadas de manera específica.

Firewalls cloud y virtuales

En firewalls virtuales o cloud no se debe confiar únicamente en backups de hypervisor, snapshots o del cloud provider. Sophos soporta para backups de configuración de firewall el mecanismo integrado Backup and Restore de la propia firewall. Los backups de plataforma pueden ser útiles como protección adicional de infraestructura, pero no sustituyen el backup de configuración soportado.

En la práctica, esto significa: VM snapshot, cloud image o mecanismo de marketplace pueden ayudar a restaurar la instancia. Para una configuración SFOS limpia, una migración o un análisis de soporte sigue siendo necesario un backup válido de Sophos Firewall con SSMK adecuado, contraseña de backup, versión de destino e interface mapping documentado.

Verificar después de la restauración

Después de la restauración, no solo se debe verificar si WebAdmin es accesible. El firewall puede ser accesible y aún así procesar incorrectamente servicios importantes.

Verificar directamente después de la restauración:

• IP de WebAdmin, redes de gestión permitidas y Device Access.
• Interfaces, zonas, VLANs, puentes, LAGs y interfaces alias.
• Enlaces WAN, PPPoE, datos de proveedores estáticos y puerta de enlace predeterminada.
• Rutas SD-WAN, rutas estáticas y enrutamiento dinámico.
• Reglas de firewall, reglas NAT, reglas WAF y orden de reglas.
• IPsec, SSL VPN, Sophos Connect, RED y acceso remoto.
• Certificados, certificados CA, certificado WebAdmin e inspección TLS.
• DNS, DHCP, NTP, zona horaria y servidores de autenticación.
• Estado de HA, si se utiliza un clúster.
• Estado de la licencia, actualizaciones de patrones, hotfixes y sincronización con Sophos Central.
• Registro, objetivos de Syslog, informes de firewall central y informes locales.

Para la verificación técnica, ayudan según el problema Log Viewer, Policy Test y Packet Capture, Packet Capture en WebAdmin y Servicios y registros.

Prueba de aceptación después de una restauración

Una restauración solo se completa cuando las funciones operativas más importantes se confirman con pruebas reales. Un WebAdmin accesible solo demuestra que el firewall es operable. No demuestra que el enrutamiento, NAT, VPN, WAF, autenticación o registro funcionen correctamente nuevamente.

Para firewalls productivos, debe haber una breve matriz de aceptación. Esta matriz no tiene que ser complicada, pero debe establecer por ubicación qué prueba se debe realizar obligatoriamente después de una restauración y quién documenta el resultado.

Pruebas obligatorias útiles:

• Gestión: abrir WebAdmin desde la red de gestión y probar un segundo acceso de administrador. Se espera que el acceso solo funcione desde redes permitidas.
• Acceso a Internet: un cliente de prueba en LAN o VLAN de cliente accede a objetivos externos definidos. Deben aplicarse la regla de firewall correcta, la regla NAT y la ruta WAN.
• DNS y DHCP: el cliente recibe dirección y resuelve nombres internos y externos. Rango DHCP, servidor DNS y DNS Request Routes deben encajar.
• Site-to-Site VPN: se alcanza un host definido por ubicación en ambas direcciones. Túnel, routing y regla de firewall deben coincidir.
• Remote Access: un usuario de prueba establece SSL VPN, IPsec o Sophos Connect. Login, MFA, perfil, DNS y objetivos internos deben funcionar.
• WAF o DNAT: el servicio publicado se prueba desde el exterior. Certificado, regla, backend y logging deben encajar.
• Autenticación: probar AD, LDAP, RADIUS, STAS o Entra SSO con usuario de prueba. El usuario debería ser reconocido y coincidir con la regla esperada.
• Logging: verificar Log Viewer, Syslog, Central Reporting o SIEM. La restauración y el tráfico de prueba deberían ser visibles de manera rastreable.
• HA: verificar estado del clúster, roles y sincronización. Primary y Auxiliary deberían estar en el estado esperado.

Es importante un punto de interrupción definido. Si después de una restauración no funcionan pruebas básicas como WAN, DNS, acceso remoto o HA, no se debe corregir en muchas áreas al mismo tiempo. Es mejor un caso de error estrecho con hora, fuente de prueba, objetivo, regla afectada y extracto de registro. Así se mantiene rastreable si el problema proviene de la copia de seguridad, la asignación de interfaces, el hardware de destino o un cambio posterior.

Errores típicos

• La copia de seguridad solo está local en el firewall: en caso de defecto de hardware o reimagen no es accesible. Las copias de seguridad deben guardarse externamente y de forma protegida.
• SSMK no documentado: la restauración de datos protegidos puede fallar o tardar mucho más. El SSMK pertenece al procedimiento de recuperación.
• SSMK antiguo tras cambio de clave ya no localizable: las copias antiguas ya no pueden descifrarse. Las versiones anteriores del SSMK deben mantenerse documentadas con periodo y referencia al firewall.
• Copia de seguridad sin referencia de versión o dispositivo: se aplica el archivo incorrecto. Nombre del firewall, número de serie, versión de SFOS y fecha pertenecen a la documentación de backup.
• Sin copia de seguridad del estado actual antes de la restauración: falta camino de regreso al estado actual. Antes de una restauración productiva debe crearse un nuevo backup.
• IP de WebAdmin restaurada desconocida: después de la restauración el firewall parece offline, aunque está en otra IP. Planificar de antemano IP de gestión del backup y acceso local.
• Hora y NTP no comprobados tras restauración: VPN, certificados, autenticación o conexión a Central pueden comportarse de forma errónea. Comprobar zona horaria, NTP y hora actual directamente después de la restauración.
• Ruta de restauración no aprobada confirmada: el firewall inicia con configuración de fábrica o la restauración falla de forma poco clara. Versión de destino, versión de origen y Compatibility Check deben comprobarse antes.
• Asignación de puertos no verificada: las interfaces terminan incorrectamente después de la migración. Preparar Compatibility Check y asignación de interfaces.
• Asignación automática de interfaces aceptada sin verificar: WAN, VLAN, VPN o enlace HA quedan en puertos incorrectos. Después de restaurar, comparar cada interfaz con cableado y modelo de zonas.
• Contexto de HA ignorado: el clúster no inicia correctamente o se activa el rol incorrecto. Planificar roles HA, estado de firmware y orden de restauración.
• Solo se verifica WebAdmin: problemas de VPN, NAT, WAF o DNS permanecen sin detectar. Después de la restauración hacen falta pruebas reales de servicios.

Lista de verificación operativa

Regularmente:

• Activar copias de seguridad automáticas o definir un proceso de copia de seguridad central.
• Verificar almacenamiento de copias de seguridad, acceso y retención.
• Controlar SSMK y contraseña de copia de seguridad en el gestor de contraseñas.
• Mantener actualizado el paquete de recuperación por ubicación o firewall.
• Verificar al menos de manera aleatoria si las copias de seguridad son localizables y asignables.

Antes de cambios importantes:

• Crear copia de seguridad manual y almacenar externamente.
• Documentar nombre del firewall, número de serie, versión de SFOS y propósito del cambio.
• Verificar SSMK, contraseña de copia de seguridad y acceso de administrador.
• Establecer plan de reversión o restauración.
• En migraciones, verificar Compatibility Check y asignación de interfaces.
• No confirmar advertencias sobre rutas de restauración o migración no admitidas antes de tener un plan alternativo.

Después de una restauración:

• Controlar IP de WebAdmin, redes de gestión y Device Access.
• Probar interfaces, enrutamiento, NAT, VPN, WAF, autenticación y Central.
• Comprobar zona horaria, NTP y hora actual.
• Completar matriz de aceptación con fuentes de prueba reales, objetivos de prueba y registros esperados.
• Verificar estado y roles de HA.
• Verificar registros y monitoreo.
• En versiones de destino a partir de SFOS 22.0 MR1, verificar nuevamente si una restauración o importación ha devuelto configuraciones antiguas de Legacy Remote Access IPsec.
• Crear nueva copia de seguridad del estado objetivo restaurado.
• Documentar desviaciones y, si es necesario, comparar con Config Studio.

FAQ