Introduction
Les règles ajoutées avec la commande iptables modifient le pare-feu actif du noyau, mais une modification active ne constitue pas à elle seule une configuration durable. Les administrateurs sérialisent généralement les règles IPv4 avec iptables-save, puis rechargent ce format avec iptables-restore. Sur les systèmes Debian et Ubuntu, /etc/iptables/rules.v4 est un fichier de persistance couramment utilisé lorsqu’un chargeur approprié est activé au démarrage.
Considérez ce fonctionnement comme trois couches distinctes. Le jeu de règles actif correspond à ce que le noyau applique actuellement. Un fichier de règles sauvegardé n’est qu’un fichier texte sur le disque tant qu’un outil ou un service ne l’a pas restauré. Une sauvegarde de référence constitue un état initial connu, conservé pour permettre un retour en arrière. La modification d’une couche ne met pas automatiquement à jour les deux autres : les administrateurs doivent donc enregistrer, restaurer et vérifier volontairement chaque transition.
Dans ce laboratoire, vous préserverez le pare-feu d’origine comme point de retour, ajouterez et enregistrerez une règle de service ciblée, validerez le fichier sauvegardé avant de l’appliquer, simulerez le rechargement d’un jeu de règles, puis restaurerez la référence initiale. Ce processus distingue clairement trois états importants : les règles actives, le fichier de règles sauvegardé et la copie de retour en arrière.
Sauvegarder le pare-feu IPv4 actif
Dans cette étape, vous allez capturer l’état initial du pare-feu avant toute modification. Un fichier de retour en arrière vous fournit un état connu et fiable si les commandes suivantes ne se comportent pas comme prévu.
Accédez au répertoire du projet.
cd /home/labex/project
Vérifiez que le service de test est disponible avant de modifier les règles.
curl --noproxy '*' --fail --silent http://127.0.0.1:18087/status
Il s’agit d’un test de contrôle. 127.0.0.1 utilise l’interface de bouclage, --noproxy '*' garantit que la requête reste locale même si des variables de proxy sont configurées, et --fail --silent fournit une réponse propre avec un code de retour fiable. L’établissement d’un état de référence fonctionnel facilite l’interprétation du comportement ultérieur du pare-feu.
Utilisez iptables-save pour afficher l’ensemble des règles IPv4. Le tube transmet cette sortie à tee, qui écrit dans baseline.v4 tout en permettant d’exécuter la commande avec le compte utilisateur habituel.
sudo iptables-save | tee baseline.v4 >/dev/null
La séparation des privilèges est intentionnelle : sudo iptables-save lit le jeu de règles protégé du noyau, tandis que tee, exécuté sans privilèges élevés, écrit dans votre répertoire de projet. La redirection finale envoie la copie de la sortie affichée par tee vers /dev/null ; elle ne vide pas le fichier. La sauvegarde obtenue contient toutes les tables et chaînes IPv4 sérialisées signalées par cet hôte, et pas uniquement la règle que vous ajouterez plus tard.
Examinez le début du fichier sauvegardé.
head -n 12 baseline.v4
Les compteurs exacts peuvent varier, mais le fichier utilise le format d’iptables-restore, organisé en sections de tables. Une section minimale de filtrage ressemble à ceci :
*filter
:INPUT ACCEPT ...
...
COMMIT
Chaque section commence par le nom d’une table, comme *filter, déclare ses chaînes et leurs politiques, énumère les règles, puis se termine par COMMIT. iptables-restore n’applique une section de table que lorsqu’il atteint ce marqueur. Ne considérez pas ce fichier comme une simple liste de commandes shell indépendantes.
Vérifiez que le fichier contient un marqueur de table de filtrage ainsi qu’un marqueur de validation.
grep -E '^\*filter$|^COMMIT$' baseline.v4
Ajouter et enregistrer la règle du service
Dans cette étape, vous allez ajouter une règle d’autorisation explicite au pare-feu actif, puis enregistrer le jeu de règles obtenu dans le chemin de persistance IPv4 habituel.
Insérez au début de INPUT une règle qui autorise le trafic TCP de bouclage vers le port 18087. Les restrictions sur l’interface et le port limitent la règle au contexte de cet exercice.
sudo iptables -I INPUT 1 -i lo -p tcp --dport 18087 -j ACCEPT
INPUT concerne le trafic destiné à l’hôte lui-même. -I INPUT 1 place la règle en première position, -i lo la limite à l’interface de bouclage, -p tcp --dport 18087 sélectionne le service de test, et -j ACCEPT autorise les paquets correspondants. Une règle explicite et précisément délimitée est plus facile à auditer et à supprimer qu’une règle générale autorisant de nombreux services.
Vérifiez la règle active. Un code de retour nul signifie que la correspondance et la cible exactes existent ; l’implémentation reposant sur nftables sur cet hôte affiche également une forme normalisée de la règle correspondante.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT
Enregistrez l’ensemble des règles IPv4 actives. sudo tee est utilisé, car /etc/iptables nécessite des droits d’écriture administratifs.
sudo iptables-save | sudo tee /etc/iptables/rules.v4 >/dev/null
Cette commande crée un nouvel instantané après l’ajout de la règle. sudo est nécessaire des deux côtés du tube, pour des raisons différentes : le côté gauche lit l’état du pare-feu et le côté droit ouvre un fichier de destination appartenant à root. La simple création de rules.v4 ne l’active pas et ne planifie aucune opération ; elle prépare un fichier qu’une commande de restauration ou un service de démarrage pourra utiliser.
Recherchez le port du service dans le fichier sauvegardé. Le -- après grep met fin à l’interprétation des options, ce qui est utile lorsqu’un motif de recherche peut commencer par un tiret.
sudo grep -- '--dport 18087' /etc/iptables/rules.v4
La sortie doit contenir une règle INPUT se terminant par -j ACCEPT. À ce stade, le jeu de règles actif et le fichier sauvegardé contiennent tous deux la règle attendue.
Évitez de comparer le nouveau fichier avec la référence à l’octet près. Les compteurs de paquets et les règles gérées par d’autres logiciels peuvent légitimement évoluer. Pour cet exercice, l’élément essentiel est de constater que la règle attendue existe à la fois dans l’état actif et dans l’artefact sauvegardé.
Valider et restaurer le jeu de règles sauvegardé
Dans cette étape, vous allez supprimer la règle active, valider le fichier sauvegardé sans l’appliquer, puis le recharger. Cela simule l’élément essentiel d’une restauration au démarrage tout en restant dans une seule session de laboratoire.
Supprimez la règle de la chaîne INPUT active.
sudo iptables -D INPUT -i lo -p tcp --dport 18087 -j ACCEPT
Cette suppression ne modifie que le jeu de règles actuellement chargé dans le noyau. Elle ne modifie pas /etc/iptables/rules.v4, ce qui permet de restaurer la règle sauvegardée lors d’une commande ultérieure. Cette différence volontaire illustre la distinction entre l’état actif et l’état sauvegardé.
Vérifiez que la règle est absente. La vérification doit échouer ; l’opérateur || affiche donc un message et permet au processus de continuer.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT 2>/dev/null || echo "Live rule is absent"
Avant d’appliquer un pare-feu sauvegardé, utilisez iptables-restore --test. Cette commande analyse le fichier complet et signale les erreurs de syntaxe sans remplacer le jeu de règles actif.
sudo iptables-restore --test < /etc/iptables/rules.v4
L’opérateur < fournit le fichier comme entrée standard à iptables-restore. Une sortie silencieuse signifie que la syntaxe a été acceptée ; cela ne signifie pas que le fichier a déjà été appliqué. La validation est une mesure de sécurité importante, car un jeu de règles mal formé ou incomplet peut interrompre la connectivité lors de sa restauration.
Une validation réussie se termine silencieusement. Restaurez maintenant les règles sauvegardées dans le pare-feu actif.
sudo iptables-restore < /etc/iptables/rules.v4
Contrairement à l’ajout d’une seule règle avec iptables, iptables-restore traite toutes les sections de tables présentes dans le fichier. Considérez cette opération comme une intervention administrative à fort impact : validez d’abord, conservez une copie de retour en arrière et vérifiez immédiatement les accès essentiels. Dans ce laboratoire contrôlé, le fichier sauvegardé a été créé sur le même hôte quelques instants auparavant.
Vérifiez que la règle du service est revenue.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT
Confirmez que l’application reste accessible après la restauration.
curl --noproxy '*' --fail --silent http://127.0.0.1:18087/status
Revenir à la référence initiale
Dans cette étape, vous allez utiliser la sauvegarde créée à l’étape 1 pour supprimer la modification du laboratoire du pare-feu actif, tout en conservant le jeu de règles cible sauvegardé à des fins d’inspection.
Validez la référence avant de l’appliquer.
sudo iptables-restore --test < baseline.v4
Ici, baseline.v4 et /etc/iptables/rules.v4 ont volontairement des rôles différents. La référence représente l’état actif d’origine, tandis que rules.v4 représente l’état cible contenant la règle du service. La restauration d’un fichier ne modifie pas l’autre.
Restaurez le jeu de règles actif d’origine.
sudo iptables-restore < baseline.v4
Confirmez que la règle du laboratoire n’est plus active.
sudo iptables -C INPUT -i lo -p tcp --dport 18087 -j ACCEPT 2>/dev/null || echo "Original firewall baseline restored"
Le fichier cible sauvegardé est un artefact distinct et contient toujours la règle que vous avez appris à restaurer.
sudo grep -- '--dport 18087' /etc/iptables/rules.v4
Cette vérification démontre clairement la séparation des états : le pare-feu actif a été restauré à son état initial, mais l’artefact de persistance contient toujours la règle cible. Un administrateur pourrait la restaurer ultérieurement ou configurer un service de persistance pour la charger au démarrage.
Enfin, vérifiez que le retour à la référence permissive d’origine permet toujours au service local de rester accessible.
curl --noproxy '*' --fail --silent http://127.0.0.1:18087/status
En production, vérifiez quel service charge le fichier de persistance de la distribution au démarrage. Par exemple, les systèmes fondés sur Debian utilisent souvent un paquet tel que iptables-persistent associé à netfilter-persistent, mais la disponibilité et les politiques varient selon l’hôte. L’enregistrement d’un fichier rules.v4 correct prépare le jeu de règles ; c’est la présence et l’activation d’un chargeur qui déterminent si celui-ci sera restauré automatiquement.
Résumé
Vous avez sauvegardé le pare-feu IPv4 actif, ajouté et enregistré une règle de service ciblée, validé le jeu de règles sérialisé avec iptables-restore --test, rechargé celui-ci dans le noyau, puis restauré la référence initiale. Vous avez également distingué le pare-feu actif de ses fichiers de persistance et de retour en arrière — une habitude essentielle avant toute modification ou restauration de l’état du filtrage réseau.
