Preparación para la recuperación antes de un cambio de endurecimiento: acceso a consola, una copia de seguridad, una reversión automática programada y un registro de cambios

Objetivo

Reducir un cambio de endurecimiento que afecte a la red, a la autenticación o al firewall a algo que se revierta por sí solo si bloquea el acceso del operador, en lugar de requerir acceso físico o fuera de banda para solucionarlo.

Requisitos previos

Una vía fuera de banda hacia el host que no dependa del cambio que se está realizando (consola serie/IPMI/de hipervisor, o el acceso a la consola del proveedor de nube), confirmada como accesible antes de empezar; permiso para programar un trabajo puntual en el sistema operativo de destino.

Pasos

1. Confirmar que el acceso fuera de banda funciona justo ahora, antes de tocar nada, no «funcionó el mes pasado». Si el propio acceso a consola necesita el cambio que se está probando (por ejemplo, el cambio afecta al host de salto), preparar el cambio desde una sesión que no dependa de lo que se va a cambiar.
2. Hacer una copia de seguridad exactamente de lo que va a cambiar: el archivo de configuración concreto, el conjunto de reglas de firewall o la exportación de GPO, con una marca de tiempo en el nombre del archivo, no solo «existen copias de seguridad recientes en algún lugar».
3. Armar una reversión programada e incondicional antes de aplicar el cambio arriesgado:
   • Linux, puntual y transitoria (como root): systemd-run --unit=rollback-net --on-active=10min /usr/local/sbin/rollback-network.sh, usando el temporizador --on-active= de systemd para dispararse en relación con el momento actual, independientemente de lo que le ocurra al shell actual o a la sesión SSH; esto crea rollback-net.timer y rollback-net.service.
   • Linux, cola clásica: echo /usr/local/sbin/rollback-network.sh | at now + 10 minutes, usando at, documentado como una herramienta para «encolar, examinar o eliminar trabajos para su ejecución posterior» — atq lista los trabajos pendientes, atrm cancela uno en cuanto se confirma el éxito. Se requieren el paquete at y un atd en ejecución, y faltan en muchas instalaciones mínimas.
   • Windows: Register-ScheduledTask con un desencadenador construido mediante New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(10), ejecutando un script de reversión bajo un principal que no dependa del cambio, por ejemplo New-ScheduledTaskPrincipal -UserId SYSTEM -RunLevel Highest.
4. Aplicar el cambio de endurecimiento.
5. Confirmar el éxito por el mismo canal que se usará en adelante (no solo la sesión actual, que puede estar exenta por herencia). Si se confirma, cancelar la reversión programada (atrm <job>, systemctl stop rollback-net.timer, o Unregister-ScheduledTask -TaskName <name> -Confirm:$false) y comprobar que ha desaparecido (atq, systemctl list-timers, Get-ScheduledTask).
6. Registrar el cambio, su marca de tiempo, la ubicación de la copia de seguridad y el ID del trabajo de reversión en un registro de cambios antes de pasar a la siguiente tarea; esto es lo que permite rastrear un incidente posterior hasta una acción concreta y fechada.

Resultado esperado

Si el cambio rompe la vía de acceso que se está usando, el trabajo programado se dispara sin intervención y restaura la configuración anterior dentro de la ventana elegida; si el cambio tiene éxito, la reversión se cancela y nunca se dispara.

Límites y base de verificación

Una reversión programada solo ayuda si el propio script de reversión es correcto y se probó contra el formato de copia de seguridad concreto tomado en el paso 2; probar el script de reversión en una ventana que no sea de producción al menos una vez. El comportamiento ante un reinicio difiere: un temporizador transitorio de systemd-run se pierde al reiniciar, así que un cambio que solo surte efecto tras un reinicio no queda cubierto por él; los trabajos de at se conservan en el directorio de spool y sobreviven a un reinicio, así que una reversión pendiente puede seguir ejecutándose en cuanto atd vuelva a iniciarse; una tarea programada de Windows persiste hasta que se anula su registro. Comprobar el estado de atd/systemd/Task Scheduler si un trabajo parece no haberse disparado. Ninguno de estos pasos requiere por sí mismo un reinicio.