Modo de pánico

LinuxBeginner
Practicar Ahora

Introducción

A veces, las cosas salen mal. Muy mal. Tal vez detecte que un hacker está atacando su servidor o que un virus se está propagando rápidamente. Necesita desconectar el equipo de la red de inmediato.

firewalld ofrece una función llamada modo de pánico. Al activarlo, el firewall descarta inmediatamente todas las conexiones entrantes y salientes.

Por eso, el modo de pánico forma parte de la respuesta a incidentes, no de la configuración habitual. Está diseñado para contener rápidamente un incidente cuando detener la comunicación es más importante que mantener la conectividad.

Esta función sirve para contener emergencias. No está pensada para la administración normal, pero es útil conocerla porque muestra que las políticas del firewall también pueden utilizarse como una herramienta rápida de aislamiento durante un incidente.

El problema con los servidores remotos:

Si usted se encuentra delante del servidor físico, no hay problema. Sin embargo, en un entorno remoto, como esta máquina virtual de LabEx o un servidor en la nube, activar el modo de pánico cortará inmediatamente su propia conexión. Se quedará sin acceso y no podrá desactivarlo.

En este laboratorio, aprenderá a simular y probar esta función de forma segura mediante un script tipo «interruptor de hombre muerto». El script activará el modo de pánico, ejecutará una prueba y lo desactivará automáticamente para garantizar que recupere el acceso.

Crear un script de prueba seguro

No podemos ejecutar directamente firewall-cmd --panic-on sin perder la sesión, así que escribiremos un script que gestione automáticamente todo el proceso.

Esta es también una técnica operativa más general: cuando un cambio de red podría dejarle sin acceso, automatice la reversión antes de realizar el cambio arriesgado. Así reducirá la posibilidad de que una prueba se convierta en una interrupción del servicio.

El script hará lo siguiente:

  1. Registrará un ping «Antes» (correcto).
  2. Activará el modo de pánico.
  3. Registrará un ping «Durante» (debería fallar).
  4. Desactivará el modo de pánico (restaurando el acceso).

Cree un archivo llamado safe_panic_test.sh:

nano safe_panic_test.sh

Pegue el siguiente contenido:

#!/bin/bash
LOGFILE="panic_test.log"

echo "--- PHASE 1: Normal State ---" > $LOGFILE
ping -c 2 8.8.8.8 >> $LOGFILE 2>&1

echo "" >> $LOGFILE
echo "--- PHASE 2: Enabling PANIC MODE ---" >> $LOGFILE
firewall-cmd --panic-on
echo "Panic Mode is ON." >> $LOGFILE

echo "Attempting to ping 8.8.8.8 (Should fail)..." >> $LOGFILE
## -W 2 means wait max 2 seconds for response
ping -c 2 -W 2 8.8.8.8 >> $LOGFILE 2>&1

echo "" >> $LOGFILE
echo "--- PHASE 3: Disabling PANIC MODE ---" >> $LOGFILE
firewall-cmd --panic-off
echo "Panic Mode is OFF." >> $LOGFILE

echo "Checking connectivity restored..." >> $LOGFILE
ping -c 2 8.8.8.8 >> $LOGFILE 2>&1

Guarde el archivo y salga (Ctrl+O, Enter, Ctrl+X).

Convierta el script en ejecutable:

chmod +x safe_panic_test.sh

Ejecutar la prueba de forma segura

Ahora viene la parte crítica. Si ejecuta el script normalmente, su sesión podría desconectarse en cuanto se active el modo de pánico. Esto podría finalizar el script antes de que pudiera desactivarlo.

Para evitarlo, utilizaremos nohup (No Hang Up, «no colgar»). Esto permite que el script continúe ejecutándose en segundo plano aunque la sesión del terminal se cierre.

Este es un buen ejemplo de cómo separar la duración de un proceso de la duración del terminal. La seguridad del experimento depende de que el script de recuperación siga ejecutándose aunque la sesión interactiva deje de estar disponible.

Ejecute el script con sudo y nohup:

sudo nohup ./safe_panic_test.sh &

Qué debe esperar:

  1. Es posible que el terminal se congele o deje de responder durante unos 5-10 segundos. No actualice la página.
  2. Cuando el script termine la fase 3 (desactivación del modo de pánico), la conexión debería recuperarse automáticamente.

Espere al menos 15 segundos.

Analizar los resultados

Ahora que la conexión se ha restablecido, examine el archivo de registro para verificar que el modo de pánico funcionó realmente.

La verificación es especialmente importante en este caso porque el modo de pánico interrumpe deliberadamente la conectividad. Necesita confirmar que el aislamiento se produjo durante la prueba y que la conectividad normal regresó después.

Lea el archivo de registro:

cat panic_test.log

Debería ver una secuencia similar a esta:

  1. PHASE 1: el ping se realizó correctamente.
  2. PHASE 2: el modo de pánico está activado. El intento de ping debería mostrar errores como Network is unreachable o 100% packet loss.
  3. PHASE 3: el modo de pánico está desactivado. El ping vuelve a realizarse correctamente.

Esto confirma que, durante esos pocos segundos, el servidor quedó completamente aislado de la red.

Verificar el estado

Por último, confirme manualmente que el sistema ha vuelto a la normalidad y que el modo de pánico está definitivamente desactivado.

Compruebe el estado del modo de pánico:

sudo firewall-cmd --query-panic

El comando debería devolver no.

Esta técnica de «activación y desactivación mediante un script» es una habilidad fundamental para los ingenieros de DevOps. Siempre que modifique una configuración de red que pueda desconectarle, programe de antemano un comando de reversión o utilice un script envoltorio como este.

La lección operativa más importante es la seguridad: los cambios arriesgados en el firewall deben contar con una ruta de recuperación planificada de antemano, no improvisada después de perder el acceso.

Resumen

En este laboratorio, aprendió a utilizar el modo de pánico de forma segura en un entorno remoto. Usted:

  1. Creó un script tipo «interruptor de hombre muerto» para activar y desactivar automáticamente el modo de pánico.
  2. Utilizó nohup para garantizar que el script continuara ejecutándose pese a la desconexión de red.
  3. Analizó los registros para verificar que el aislamiento de red se produjo realmente.

Este método muestra cómo gestionar configuraciones de seguridad peligrosas sin quedarse sin acceso al servidor.