Pare-feu Linux : relire une configuration iptables avant migration

Inventorier le moteur et les règles en place

L’ancienne recette vidait les tables puis reconstruisait un pare-feu iptables. Sur un serveur distant, cette méthode peut interrompre l’accès ou ouvrir temporairement des flux. Identifiez le gestionnaire en charge : nftables, firewalld, une interface de distribution ou un autre composant. Certaines commandes iptables utilisent un moteur de compatibilité nft.

Exportez les règles existantes et vérifiez les responsabilités des conteneurs et de la virtualisation. Plusieurs outils qui modifient les mêmes chaînes compliquent le diagnostic.

sudo nft list ruleset
sudo iptables-save

Décrire les flux avant d’écrire les règles

Distinguez le trafic vers la machine, celui qu’elle émet et celui qu’elle transfère. Listez sources, destinations, protocoles, ports et état des connexions. Une règle IPv4 n’applique pas automatiquement la même protection à IPv6. NAT et filtrage répondent également à des besoins différents.

Ajoutez les dépendances nécessaires au service, notamment résolution de noms, synchronisation temporelle et supervision. Testez depuis un poste extérieur au serveur ; une connexion locale ne traverse pas forcément les mêmes chaînes.

Préparer une application avec retour arrière

Validez la syntaxe du fichier candidat et utilisez un mécanisme de retour arrière adapté au gestionnaire choisi. La vérification de syntaxe ne prouve pas que SSH restera accessible. Gardez une console de secours et un second test de connexion avant de fermer la session courante.

Après application, vérifiez les flux autorisés et refusés, puis la persistance au redémarrage. Retirez progressivement les règles inutiles, avec un journal des changements, plutôt qu’en effaçant tout le jeu de règles à l’aveugle.

sudo nft -c -f candidat.nft