Construire une règle avec ses critères

Une règle trop large peut autoriser des communications qui ne sont pas nécessaires au serveur. À l’inverse, une règle mal ciblée peut interrompre un accès utile, notamment votre session d’administration. Vous allez apprendre à préciser le trajet, le protocole et le port concernés, puis à préparer des règles sans les appliquer.

Décrire précisément le trafic visé

Une règle iptables associe des critères à une action sur une chaîne. Comme vu dans « Repérer les chaînes d’iptables », choisissez INPUT pour un paquet destiné au serveur. Les options -i et -o permettent respectivement de préciser l’interface d’entrée et l’interface de sortie ; elles ne sont pertinentes que si vous connaissez le nom de l’interface à cibler.

L’option -p sélectionne le protocole, par exemple tcp ou udp. Le module -m tcp fournit les critères propres à TCP, dont --dport, le port de destination, et --sport, le port source. Pour une connexion entrante à un service du serveur, c’est généralement le port de destination qui identifie le service visé.

Préparer des règles pour le serveur web

Pour le projet fil rouge, supposez que l’inventaire a confirmé SSH sur le port 22, HTTP sur le port 80 et HTTPS sur le port 443. Ces valeurs sont des exemples à remplacer par celles réellement observées ; en particulier, reprenez le port SSH de votre session, comme établi dans « Préserver l’accès SSH ». Les commandes suivantes sont des règles préparées : le préfixe iptables -A les ajoute à la chaîne, mais elles ne sont pas exécutées dans cette leçon.

sudo iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

Trois règles sont préparées : elles ciblent respectivement SSH, HTTP et HTTPS sur TCP, dans la chaîne INPUT. Aucune modification n’est effectuée tant que ces commandes ne sont pas lancées.

Chaque ligne exprime une intention distincte : autoriser un port de service précis. L’absence de -i signifie que ces exemples ne limitent pas l’autorisation à une interface particulière ; ajoutez ce critère seulement si votre configuration et votre besoin le justifient. Par exemple, si l’interface publique vérifiée se nomme ens3, vous pouvez ajouter -i ens3 à une règle entrante.

sudo iptables -A INPUT -i ens3 -p tcp -m tcp --dport 443 -j ACCEPT

Cette règle vise les paquets TCP entrant par ens3 dont le port de destination est 443, puis les accepte.

Pour une règle de sortie, la chaîne concernée est OUTPUT et le critère d’interface correspondant est -o. Le port source identifie le port émetteur du paquet ; ne le confondez pas avec le port de destination du service auquel un client se connecte. Une règle sur --sport ne remplace donc pas une autorisation entrante visant le port du service.

Vérifier avant toute application

Relisez chaque règle en répondant à quatre questions : la chaîne correspond-elle au trajet, l’interface est-elle exacte, le protocole est-il celui du service, et le port est-il le bon ? Vérifiez en premier la règle SSH et remplacez le port 22 si votre serveur en utilise un autre. Cette leçon ne modifie ni le pare-feu ni les fichiers de suivi du projet : les prochaines étapes traiteront notamment des connexions établies et du contrôle des règles.

À retenir

• Choisissez la chaîne selon le trajet du paquet ; INPUT vise ici les accès destinés au serveur.
• Utilisez -i pour préciser une interface d’entrée et -o pour une interface de sortie, après avoir vérifié son nom.
• Précisez le protocole avec -p ; pour TCP, --dport désigne le port de destination et --sport le port source.
• Préparez une autorisation distincte par service et vérifiez la règle SSH avant toute politique restrictive.
• Ne lancez pas une règle d’exemple sans avoir confirmé les ports et les interfaces de votre serveur.