Mode panique

Introduction

Parfois, les choses tournent mal. Très mal. Vous pouvez par exemple constater qu'un pirate attaque votre serveur ou qu'un virus se propage rapidement. Vous devez alors déconnecter l'ordinateur du réseau immédiatement.

firewalld fournit une fonction appelée mode panique. Lorsqu'il est activé, le pare-feu bloque immédiatement toutes les connexions entrantes et sortantes.

C'est pourquoi le mode panique relève de la réponse aux incidents, et non du réglage courant. Il est conçu pour contenir rapidement un incident lorsque le maintien de la connectivité est moins important que l'arrêt immédiat des communications.

Il s'agit d'une fonction de confinement d'urgence. Elle ne sert pas à l'administration courante, mais il est utile de la comprendre, car elle montre qu'une politique de pare-feu peut également servir d'outil d'isolation rapide pendant un incident.

Le problème des serveurs distants :

Si vous êtes devant le serveur physique, cela ne pose pas de problème. En revanche, dans un environnement distant, comme cette VM LabEx ou un serveur cloud, l'activation du mode panique coupera instantanément votre propre connexion. Vous serez bloqué et ne pourrez plus le désactiver !

Dans ce lab, vous apprendrez à simuler et à tester cette fonction en toute sécurité en créant un script de type « interrupteur d'homme mort ». Ce script activera le mode panique, exécutera un test, puis le désactivera automatiquement afin de vous permettre de reprendre l'accès.

Créer un script de test sécurisé

Comme nous ne pouvons pas exécuter directement firewall-cmd --panic-on sans perdre notre session, nous allons écrire un script qui gérera automatiquement le processus.

Il s'agit également d'une technique opérationnelle plus générale : lorsqu'une modification réseau risque de vous bloquer, automatisez le retour arrière avant d'effectuer la modification risquée. Vous réduisez ainsi le risque de transformer un test en interruption de service.

Ce script va :

Enregistrer un ping « Before » (réussi).
Activer le mode panique.
Enregistrer un ping « During » (qui devrait échouer).
Désactiver le mode panique (pour rétablir l'accès).

Créez un fichier nommé safe_panic_test.sh :

nano safe_panic_test.sh

Collez-y le contenu suivant :

#!/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

Enregistrez le fichier et quittez (Ctrl+O, Enter, Ctrl+X).

Rendez le script exécutable :

chmod +x safe_panic_test.sh

Exécuter le test en toute sécurité

Voici l'étape critique. Si vous exécutez normalement ce script, votre session risque de se déconnecter dès l'activation du mode panique, ce qui interromprait le script avant qu'il puisse désactiver ce mode.

Pour éviter cela, nous utilisons nohup (« No Hang Up », ou « ne pas raccrocher »). Le script peut ainsi continuer à s'exécuter en arrière-plan même si votre session de terminal est interrompue.

C'est un bon exemple de séparation de la durée de vie d'un processus et de celle du terminal. La sécurité de l'expérience dépend de la capacité du script de récupération à continuer de s'exécuter, même si votre session interactive ne le peut plus.

Exécutez le script avec sudo et nohup :

sudo nohup ./safe_panic_test.sh &

Voici ce qui devrait se produire :

Votre terminal peut se figer ou ne plus répondre pendant environ 5 à 10 secondes. Ne rechargez pas la page.
Une fois la phase 3 du script terminée (désactivation du mode panique), votre connexion devrait être automatiquement rétablie.

Attendez au moins 15 secondes.

Analyser les résultats

Maintenant que votre connexion est rétablie, examinons le fichier journal pour vérifier que le mode panique a bien fonctionné.

Cette vérification est particulièrement importante, car le mode panique est volontairement perturbateur. Vous devez disposer de la preuve que l'isolation a eu lieu pendant le test et que la connectivité normale a ensuite été rétablie.

Lisez le fichier journal :

cat panic_test.log

Vous devriez voir une séquence similaire à celle-ci :

PHASE 1 : ping réussi.
PHASE 2 : mode panique activé. La tentative de ping devrait afficher des erreurs telles que Network is unreachable ou 100% packet loss.
PHASE 3 : mode panique désactivé. Le ping réussit de nouveau.

Cela confirme que votre serveur a été complètement isolé du réseau pendant ces quelques secondes.

Vérifier l'état

Enfin, confirmons manuellement que le système est revenu à la normale et que le mode panique est bien désactivé.

Vérifiez l'état du mode panique :

sudo firewall-cmd --query-panic

La commande devrait renvoyer no.

Cette technique de « basculement par script » est une compétence précieuse pour les ingénieurs DevOps. Chaque fois que vous modifiez des paramètres réseau susceptibles de vous déconnecter, planifiez toujours une commande de retour arrière ou utilisez un script enveloppe comme celui-ci !

La leçon plus générale est la sécurité opérationnelle : les modifications risquées du pare-feu doivent prévoir à l'avance une procédure de récupération, et non être improvisées après la perte de l'accès.

Résumé

Dans ce lab, vous avez appris à utiliser le mode panique en toute sécurité dans un environnement distant. Vous avez :

Créé un script de type « interrupteur d'homme mort » pour activer et désactiver automatiquement le mode panique.
Utilisé nohup pour garantir que le script continue de s'exécuter malgré la déconnexion réseau.
Analysé les journaux pour vérifier que l'isolation réseau s'est effectivement produite.

Cette approche montre comment gérer des paramètres de sécurité dangereux sans vous bloquer hors de votre serveur.