Pare-feu Linux : configuration iptables et nftables

Pare-feu Linux : configuration iptables et nftables

Un serveur exposé sur Internet n’a besoin d’ouvrir que quelques ports. Tout le reste doit être fermé — en IPv4 et en IPv6, au redémarrage comme en fonctionnement, y compris quand Docker s’en mêle. Nous écrivons votre politique de filtrage, l’appliquons sans jamais vous couper l’accès, et vous laissons un jeu de règles lisible que vous pouvez relire et modifier.

🎯 Le pare-feu n’est pas une case à cocher

Beaucoup de serveurs affichent un pare-feu « actif » tout en étant grands ouverts : règles perdues au redémarrage, IPv6 non filtré, ports republiés par Docker, ou politique par défaut restée en accept. Un jeu de règles se conçoit comme du code : une politique par défaut de refus, des ouvertures explicites, une journalisation qui permet de comprendre, et une procédure de retour arrière avant toute application.

Nous travaillons sur le pare-feu natif du noyau Linux — netfilter, piloté par iptables ou nftables — sans surcouche propriétaire ni licence.

✅ Ce que comprend la prestation

• Relevé de l’exposition réelle : ports réellement à l’écoute, services concernés, interfaces, présence de Docker, d’un hyperviseur ou d’un reverse proxy
• Politique de filtrage écrite et validée avec vous avant toute application : ce qui est ouvert, à qui, et pourquoi
• Jeu de règles commenté, en IPv4 et IPv6, avec suivi de connexion et limitation de débit sur les services sensibles
• Persistance des règles au redémarrage, vérifiée par un redémarrage réel
• Procédure anti-verrouillage : application avec retour arrière automatique, pour ne jamais perdre l’accès SSH
• Journalisation des paquets refusés, exploitable et sans saturer vos disques
• Sauvegarde et restauration du jeu de règles, avec la commande à lancer en cas de problème
• Documentation : comment ouvrir un port, autoriser une adresse, relire les compteurs

⚡ Nos trois formules

Le choix se fait sur le nombre de serveurs et sur la complexité de votre réseau.

⚠️ Les cinq pièges d’un pare-feu Linux

Ce sont les cinq raisons pour lesquelles un serveur « protégé par iptables » ne l’est pas.

1. Les règles disparaissent au redémarrage. Une règle ajoutée en ligne de commande vit en mémoire, pas sur le disque. Sans mécanisme de persistance explicite, le premier redémarrage — une mise à jour de noyau, une coupure chez l’hébergeur — remet le serveur à nu, sans le moindre message d’erreur. Nous vérifions la persistance en redémarrant réellement la machine, pas en supposant que ça marche.
2. IPv6 reste grand ouvert. Les règles iptables ne filtrent que l’IPv4. Si votre hébergeur vous a attribué une adresse IPv6 — c’est le cas par défaut chez la plupart —, tout ce que vous croyez fermé reste joignable par ce second chemin. C’est l’une des expositions les plus fréquentes et les plus silencieuses. Chaque règle est écrite dans les deux familles d’adresses, ou dans une table inet qui couvre les deux.
3. Docker republie vos ports sans vous demander votre avis. Docker écrit ses propres chaînes dans netfilter et traite le trafic des conteneurs avant vos règles d’entrée. Un conteneur lancé avec une publication de port est accessible depuis Internet même si vous croyez ce port fermé. Le filtrage doit alors passer par la chaîne prévue à cet effet, faute de quoi vos règles sont contournées à chaque démarrage de conteneur.
4. iptables n’est souvent plus iptables. Sur les distributions récentes, la commande iptables est en réalité une façade qui écrit dans nftables. Mélanger les deux moteurs — d’anciens scripts d’un côté, des règles nftables de l’autre — produit des jeux de règles qui se superposent sans se voir, impossibles à auditer. Nous établissons d’abord quel moteur est réellement en service, puis nous unifions.
5. Une politique de refus mal appliquée vous enferme dehors. Basculer la politique par défaut sur drop avant d’avoir autorisé votre propre accès SSH coupe la session en cours, et il ne reste que la console de secours de l’hébergeur. Toute application se fait chez nous avec un retour arrière programmé : si la connexion est perdue, les règles précédentes reviennent automatiquement.

🔗 Pare-feu et détection : deux briques différentes

Un pare-feu applique une décision statique : ce port est ouvert, celui-là est fermé. Il ne sait rien de l’adresse qui tente cent mots de passe SSH à la minute sur un port légitimement ouvert. C’est le rôle d’un système de détection, qui analyse les journaux et bannit dynamiquement. Les deux se complètent : le pare-feu réduit la surface d’attaque, la détection s’occupe de ce qui passe par les portes restées ouvertes. Voir notre prestation Protection serveur avec CrowdSec.

📋 Déroulement

1. Relevé — ports à l’écoute, services, interfaces, moteur de filtrage réellement en service, présence de Docker
2. Politique — rédaction de la matrice des flux autorisés, soumise à votre validation
3. Écriture — jeu de règles commenté, IPv4 et IPv6, testé hors production quand c’est possible
4. Application — mise en service avec retour arrière automatique armé
5. Vérification — scan des ports depuis l’extérieur, avant et après, service par service, puis redémarrage de contrôle
6. Remise — sauvegarde du jeu de règles, documentation, commandes d’exploitation courantes

💡 Pourquoi AbsoluInfo

• Nous administrons des serveurs Linux au quotidien. Le filtrage n’est pas un sujet théorique : c’est ce qui casse la production quand il est mal fait.
• Nous ne coupons jamais votre accès. Le retour arrière automatique est armé avant la première règle appliquée, pas après l’incident.
• Nous vous montrons le résultat. Scan avant, scan après, port par port : vous voyez ce qui est effectivement fermé.
• Le jeu de règles vous appartient, il est commenté et lisible : vous pouvez le reprendre ou le confier à quelqu’un d’autre.

❓ Questions fréquentes

📞 Parlons de votre serveur

Indiquez-nous le système d’exploitation, l’hébergeur, les services exposés et la présence éventuelle de Docker : nous vous confirmons la formule adaptée et le délai. Le relevé initial révèle en général au moins un port ouvert dont personne ne soupçonnait l’existence.

TVA non applicable, article 293 B du code général des impôts : le montant affiché est celui que vous réglez.

Prestations complémentaires : Fail2ban · Protection serveur CrowdSec · Sécurité informatique · Infogérance & maintenance.