Introduction
iptables est une interface en ligne de commande permettant de gérer les règles de filtrage des paquets Linux. Même si de nombreuses distributions modernes appliquent ces règles via un moteur nftables, les administrateurs rencontrent encore des tâches et des systèmes existants qui utilisent la syntaxe de la commande iptables.
Pour débuter, il est utile d’imaginer un pare-feu comme une liste de contrôle ordonnée. Un paquet entre dans une chaîne ; chaque règle vérifie s’il correspond à certaines conditions, comme une interface, un protocole ou un port ; puis une cible, telle que ACCEPT ou REJECT, détermine ce qui lui arrive. La chaîne INPUT traite les paquets destinés à l’hôte local. Comme les règles sont évaluées de haut en bas, leur contenu et leur position sont tous deux importants.
Dans ce laboratoire, vous travaillerez avec un seul service web local et n’apporterez que des modifications strictement limitées à son port TCP. Vous inspecterez le pare-feu actuel, ajouterez une règle rejetant les requêtes, vérifierez son effet avec du trafic réel, remplacerez cette règle par une autorisation explicite, puis supprimerez la règle créée par le laboratoire sans vider ni réécrire les autres règles du pare-feu.
Inspecter le pare-feu et tester le service
Dans cette étape, vous identifierez l’implémentation iptables installée et vérifierez que le service local de test fonctionne avant de modifier une règle du pare-feu.
Accédez au répertoire du projet afin que toutes les commandes suivantes soient exécutées depuis l’espace de travail du cours.
cd /home/labex/project
Utilisez command -v pour localiser l’exécutable que votre interpréteur de commandes utilisera.
command -v iptables
Cette vérification est plus fiable que de supposer qu’une commande est installée : elle affiche le chemin de l’exécutable résolu, généralement /usr/sbin/iptables, et renvoie un état différent de zéro si l’interpréteur ne trouve pas la commande.
Affichez les informations de version et de moteur. Sur cet hôte Ubuntu, la sortie contient normalement nf_tables ; cela signifie que la syntaxe habituelle d’iptables est traduite vers le moteur moderne de règles du noyau.
sudo iptables --version
Vous devriez obtenir une sortie similaire à ceci :
iptables v1.8... (nf_tables)
Le nom du moteur ne modifie pas les commandes utilisées dans ce laboratoire. Vous continuerez à créer et à inspecter les règles avec iptables ; l’implémentation se charge de leur représentation dans le noyau.
Avant de filtrer le port, interrogez le point d’accès de contrôle d’état. Une réponse réussie confirme que l’application est prête ; un échec ultérieur pourra donc être attribué à la règle du pare-feu.
curl --noproxy '*' --fail --silent http://127.0.0.1:18086/health
Ici, 127.0.0.1 est l’adresse IPv4 de bouclage. Le trafic passe donc par l’interface locale lo à l’aller comme au retour, sans atteindre de réseau externe. --noproxy '*' empêche les paramètres du proxy de rediriger la requête, --fail fait produire à curl un état d’échec en cas d’erreur HTTP, et --silent masque l’indicateur de progression afin que la réponse du service soit facile à lire.
Le service renvoie :
iptables filter service ready
Inspecter la chaîne INPUT et ajouter une règle de rejet
Dans cette étape, vous examinerez la chaîne INPUT actuelle et insérerez une règle précise rejetant le trafic TCP de bouclage destiné au port de test.
L’option -S affiche les règles sous une forme proche des commandes. En indiquant INPUT, vous limitez la sortie aux paquets destinés à cet hôte.
sudo iptables -S INPUT
La première ligne affiche généralement la politique de la chaîne, par exemple -P INPUT ACCEPT. Cette politique constitue l’action de secours utilisée uniquement lorsqu’aucune règle précédente ne prend de décision définitive. Les lignes suivantes commençant par -A INPUT correspondent aux règles actuellement ajoutées à cette chaîne.
Pour obtenir une vue plus opérationnelle, -L liste la chaîne, -n évite les résolutions de noms lentes et --line-numbers affiche la position de chaque règle. L’ordre est important, car la première cible terminale correspondant au paquet détermine son résultat.
sudo iptables -L INPUT -n --line-numbers
Ces deux affichages répondent à des besoins différents : -S est pratique lorsque vous avez besoin d’une syntaxe de règle réutilisable, tandis que -L est préférable pour connaître les positions, les compteurs de paquets et obtenir rapidement une vue d’ensemble opérationnelle.
Insérez la règle du laboratoire en première position avec -I INPUT 1. Elle correspond à l’interface de bouclage lo, au protocole TCP et au port de destination 18086. La cible REJECT avec tcp-reset refuse immédiatement la connexion au lieu de laisser le client attendre l’expiration d’un délai après une suppression silencieuse du paquet.
sudo iptables -I INPUT 1 -i lo -p tcp --dport 18086 -j REJECT --reject-with tcp-reset
Lisez la commande de gauche à droite : -i lo limite l’interface d’entrée, -p tcp sélectionne le protocole, --dport 18086 sélectionne le service et -j REJECT redirige vers la cible de rejet. -I insère la règle à une position donnée ; à l’inverse, -A l’ajouterait à la fin, où une règle précédente correspondante pourrait empêcher son exécution. Cette combinaison ciblée évite de bloquer les autres ports ou les interfaces externes.
REJECT et DROP ne sont pas équivalents. REJECT renvoie une réponse d’erreur, tandis que DROP supprime silencieusement le paquet. La réinitialisation TCP permet à ce test local d’échouer rapidement et de manière prévisible, ce qui est plus facile à diagnostiquer qu’une attente jusqu’à expiration du délai.
Utilisez -C pour vérifier que cette règle exacte existe. Une vérification réussie se termine avec l’état zéro. Sur cet hôte, l’implémentation reposant sur nftables affiche également la règle de correspondance normalisée ; d’autres implémentations peuvent terminer silencieusement.
sudo iptables -C INPUT -i lo -p tcp --dport 18086 -j REJECT --reject-with tcp-reset
L’état de sortie constitue le résultat portable de -C, et non la présence éventuelle d’un texte à l’écran. La même commande peut ainsi être utilisée dans des scripts shell et des contrôles de vérification.
Listez de nouveau la chaîne. La nouvelle règle doit apparaître en première position et mentionner tcp dpt:18086.
sudo iptables -L INPUT -n --line-numbers
Vérifier le trafic bloqué
Dans cette étape, vous répéterez la requête initiale et examinerez les compteurs de la règle afin de démontrer que le pare-feu, et non l’application, a rejeté le trafic.
Exécutez la requête dans une instruction if. Comme elle doit échouer, la branche else transforme cet échec attendu en un message explicite tout en permettant au parcours guidé de continuer.
if curl --noproxy '*' --fail --silent http://127.0.0.1:18086/health; then
echo "Unexpected: request succeeded"
else
echo "Expected: iptables rejected the request"
fi
Les conditions shell prennent leurs décisions à partir de l’état de sortie d’une commande : l’état zéro sélectionne then, tandis qu’un état différent de zéro sélectionne else. La réinitialisation envoyée par le pare-feu fait renvoyer à curl un état différent de zéro ; l’exécution de la branche else est donc le résultat attendu.
Le message attendu est :
Expected: iptables rejected the request
Listez maintenant la chaîne avec -v afin d’afficher les compteurs détaillés. Les compteurs de paquets et d’octets de la règle visant le port 18086 doivent être supérieurs à zéro après la requête.
sudo iptables -L INPUT -n -v --line-numbers
Dans la sortie, la colonne pkts compte les paquets correspondants et la colonne bytes indique leur taille cumulée. Les compteurs constituent un indice précieux : une vérification avec -C prouve que la règle existe, tandis qu’une augmentation du compteur prouve qu’un trafic réel l’a atteinte et a correspondu à ses critères. Si le compteur reste à zéro, vérifiez l’interface, le protocole, le port et la position de la règle avant d’incriminer l’application.
Remplacer la règle de rejet par une règle d’autorisation
Dans cette étape, vous supprimerez la règle de rejet exacte, ajouterez une règle autorisant explicitement le même trafic et vérifierez que l’accès est rétabli.
La forme -D ci-dessous identifie la règle grâce à l’ensemble complet de ses critères et de sa cible. Cette méthode est plus sûre que de vider la chaîne, car elle ne supprime que la modification apportée par le laboratoire.
sudo iptables -D INPUT -i lo -p tcp --dport 18086 -j REJECT --reject-with tcp-reset
Les règles peuvent également être supprimées par numéro de ligne, mais les numéros changent chaque fois qu’une règle est insérée ou supprimée. Supprimer une règle en indiquant sa spécification exacte est plus clair dans une procédure répétable et réduit le risque de supprimer une règle voisine. N’utilisez pas iptables -F ici : vider la chaîne supprimerait toutes les règles de la chaîne sélectionnée, y compris celles qui ne concernent pas ce laboratoire.
Insérez une règle ACCEPT pour la même interface, le même protocole et le même port.
sudo iptables -I INPUT 1 -i lo -p tcp --dport 18086 -j ACCEPT
ACCEPT autorise un paquet correspondant à poursuivre son traitement dans la pile réseau. La règle est insérée en première position afin que son résultat ne soit pas neutralisé par une règle terminale précédente. Remarquez que les critères de correspondance restent aussi précis qu’auparavant ; seule la cible change.
Vérifiez la règle d’autorisation exacte.
sudo iptables -C INPUT -i lo -p tcp --dport 18086 -j ACCEPT
Répétez la requête initiale vers le point de contrôle d’état.
curl --noproxy '*' --fail --silent http://127.0.0.1:18086/health
La réponse est de nouveau disponible :
iptables filter service ready
Supprimer la règle créée par le laboratoire
Dans cette étape, vous supprimerez la règle d’autorisation temporaire et vérifierez qu’aucune règle issue de cet exercice ne subsiste.
Supprimez la règle ACCEPT exacte. Comme précédemment, cette opération ne vide pas la chaîne et ne modifie pas les règles gérées par la plateforme ou par un autre administrateur.
sudo iptables -D INPUT -i lo -p tcp --dport 18086 -j ACCEPT
La suppression d’une règle d’autorisation explicite ne signifie pas automatiquement que le service sera bloqué. Une fois la règle supprimée, les règles restantes, puis finalement la politique de la chaîne, déterminent le sort du paquet. Dans cet environnement préparé, le pare-feu d’origine autorise la requête locale.
Vérifiez une dernière fois la présence de la règle. Cette fois, l’échec est attendu ; || exécute donc le message situé à droite uniquement lorsque iptables -C renvoie un état différent de zéro.
sudo iptables -C INPUT -i lo -p tcp --dport 18086 -j ACCEPT 2>/dev/null || echo "Lab allow rule removed"
Vous devriez voir :
Lab allow rule removed
Enfin, vérifiez que la suppression de la règle explicite n’a pas interrompu l’application. La politique et les règles initiales de la chaîne déterminent de nouveau l’accès.
curl --noproxy '*' --fail --silent http://127.0.0.1:18086/health
Résumé
Vous avez inspecté l’implémentation d’iptables et la chaîne INPUT, inséré et vérifié une règle de rejet ciblée, démontré son effet avec du trafic réel et des compteurs, remplacé cette règle par une autorisation, puis supprimé uniquement la modification créée par le laboratoire. Ces opérations fournissent la pratique nécessaire pour manipuler le filtrage des paquets en ligne de commande tout en évitant de vider les règles de pare-feu sans rapport avec l’exercice.
