- Structure et flux : tables, chaînes et flux de trafic
- Règles et politiques : commandes, matchs et objectifs clés
- NAT et édition : SNAT/MASQUERADE et DNAT dans des scénarios réels
- Conception sécurisée : DMZ fonctionnelle et bonnes pratiques d'exploitation
Si vous parvenez Distributions Linux pour protéger votre sécurité et votre confidentialité, tôt ou tard, vous devrez faire face à iptables. Ce système de filtrage de paquets est le cœur du pare-feu classique de GNU/Linux, capable de déterminer le trafic entrant, sortant ou transmis entre les réseaux. Correctement configuré, c'est comme avoir un gardien très précis à la porte de votre réseau, appliquant vos règles sans broncher et avec une précision chirurgicale.
Dans les lignes suivantes, vous trouverez un guide complet et mis à jour qui intègre l'essentiel : concepts de pare-feuNetfilter, tables et chaînes, flux de paquets, commandes clés, extensions de règles et objectifs avancé, ainsi que des scénarios pratiques tels que NAT, redirections, politiques par défaut et une DMZ fonctionnelle. Le tout expliqué dans un langage accessible et rigoureux, pour une application immédiate à votre infrastructure.
Les pare-feu en contexte : des videurs de boîtes de nuit à la DMZ
Un pare-feu est, par essence, un filtre entre les réseaux qui applique des règles pour décider de la destination de chaque paquet. Pensez-y comme à un videur de boîte de nuit avec une liste de critèresSi le paquet est conforme, il est accepté ; sinon, il est rejeté. Cette métaphore permet de comprendre que ce qui compte, c'est la logique des règles et l'ordre dans lequel elles sont évaluées.
Dans la conception du réseau, certaines topologies sont plus sécurisées que d’autres. La DMZ (zone démilitarisée) est un réseau intermédiaire qui héberge des services publics (comme un serveur web ou FTP) en les séparant du réseau local de l'entreprise. Pourquoi ? Parce que si un attaquant compromettait un serveur public, la segmentation l'empêcherait d'accéder directement au reste du réseau interne.
Linux comme pare-feu : Netfilter et iptables
Le noyau Linux intègre Netfilter, un framework avec des hooks pour intercepter et manipuler les paquetsEn espace utilisateur, iptables est l'utilitaire qui définit les règles que le noyau appliquera au flux de trafic. Cette séparation noyau/utilisateur permet d'obtenir des performances élevées et une grande flexibilité.
Il est pratique de distinguer les utilitaires par protocole : iptables (IPv4), ip6tables (IPv6), arptables (ARP) et ebtables (trames Ethernet)Dans le noyau, le module commun est x_tables, qui partage la logique de mise en correspondance des extensions et des cibles. À noter : iptables a remplacé ipchains et, par conséquent, nftables a succédé à iptables dans le noyau 3.13, bien qu'iptables soit encore très présent dans de nombreux systèmes.
Pour fonctionner, vous aurez besoin de privilèges d'administrateur. Exécutez iptables en tant que root (ou avec sudo), généralement dans /usr/sbin/iptables (Debian/dérivés) ou /sbin/iptables (Red Hat/dérivés). La documentation officielle est disponible à l'adresse man iptables et sur netfilter.org.
Structure d'iptables : tables, chaînes et règles
Iptables organise sa logique en tables composées de chaînes pleines de règlesChaque règle spécifie les conditions de correspondance et une cible à appliquer lorsque le paquet correspond.
- Tableau de filtrage (par défaut, filtrage pur)
- CONTRIBUTION:trafic dirigé vers la machine elle-même.
- AVANT: trafic qui transite par l'équipement (routage).
- SORTIE: trafic généré localement.
- Table Nat (traduction d'adresse ; évaluée sur les nouvelles connexions)
- PREROUTING: avant de décider d'un itinéraire ; idéal pour DNAT/transfert de port.
- SORTIE: paquets d'origine locale avant le routage.
- POSTROUTING: après le routage ; typique pour SNAT/MASQUERADE.
- Table de mangrove (réglages fins de l'en-tête : TOS, TTL, marquage, etc.)
- PRÉROUTING, ENTRÉE, TRANSFERT, SORTIE, POSTROUTING: disponible jusqu'au bout.
- Tableau brut (contrôle de suivi de connexion/conntrack)
- PREROUTING y SORTIE: pour marquer le trafic qui doit être ignoré par conntrack.
Lorsqu'un paquet arrive dans une chaîne, est comparé séquentiellement à chaque règle; si elle correspond, son objectif est exécuté et le parcours s'arrête. Si elle atteint la fin sans correspondre à aucun élément et que la chaîne est prédéfinie, le politique par défaut (politique de chaîne) de cette chaîne.
Flux de paquets : où ils passent et quand
Comprendre l’itinéraire suivi par la circulation est essentiel pour localiser correctement les règles. Un paquet quittant votre réseau local vers Internet Il est généralement traité comme ceci : d’abord PREROUTING (possible DNAT/mangrove), passe par AVANT (filtrage du trafic), et avant de partir l'équipe touche POSTROUTING (SNAT/MASQUERADE si applicable).
Cependant, si la destination est le pare-feu lui-même, PREROUTING → INPUT interviendra; s'il est émis par la machine locale, le chemin sera SORTIE → POSTROUTINGCette matrice mentale vous évite des maux de tête lorsque quelque chose ne va pas.
Commandes de base : lister, effacer, créer et définir les stratégies par défaut
Pour vérifier l'état actuel, USA iptables -L (en option) -v pour plus de détails et -n (pour ne pas résoudre les noms). Vous pouvez également créer et supprimer des chaînes avec -N y -X respectivement, et définir des politiques par défaut avec -P.
Lorsque vous devez repartir de zéro, règles propres avec -F (affleurer) et, le cas échéant, des compteurs. N'oubliez pas que vous pouvez spécifier des tables avec -t et des chaînes spécifiques ; par exemple, iptables -F -t nat pour le NAT.
Lors de la définition des règles, les options les plus courantes sont simples : -A canard, -I insérer, -R remplace et -D effacer. Ensuite, vous ajoutez des sélecteurs comme -p (protocole), -s/-d (origine/destination), -i/-o (interfaces) et la cible avec -j (par exemple., ACCEPTER, ABANDONNER ou REJETER).
Les politiques par défaut définir ce qui se passe si aucune règle ne correspond. Un schéma renforcé typique sur un hôte serait INPUT DROP, FORWARD DROP, OUTPUT ACCEPT, bloquer tout ce qui entre sauf ce qui est explicitement autorisé et permettre ce qui sort.
Extensions de correspondance (-m) : TCP, UDP, ICMP, MAC, avec état et multiport
Iptables étend ses filtres avec des modules correspondants utilisant -m. Le TCP permet le réglage par ports et drapeaux: --dport/--sport y --syn pour de nouvelles ouvertures de connexion, par exemple.
Pour UDP, Vous pouvez également délimiter les ports d'origine et de destinationUn cas classique : ouvrir le 80/443 vers un serveur web ou autoriser les requêtes DNS sortantes sur 53/UDP.
Avec ICMP, --icmp-type vous permet de distinguer les types (par exemple., demande d'écho y écho-réponse (pour les pings). Ceci est utile pour permettre des diagnostics sans laisser la porte ouverte à un ICMP complet.
Il y a aussi le module mac pour filtrer par adresse MAC avec --mac-source. Utile si vous souhaitez autoriser un ordinateur géré avec une IP dynamique à envoyer une requête ping au pare-feu sans dépendre de l'IP.
Et, peut-être plus important encore au niveau opérationnel, le module state (ou conntrack) avec --state NEW, ESTABLISHED, RELATEDCela permet d'autoriser les réponses provenant de connexions déjà établies, réduisant ainsi considérablement le nombre de règles requises.
Pour regrouper les ports, multiport ajouter --sports y --dports avec des listes séparées par des virgulesIl est pratique d'ouvrir HTTP, HTTPS et SSH dans une seule règle.
Cibles au-delà d'ACCEPT/DROP : NAT et entreprise
En plus d'accepter ou de rejeter, iptables peut réécrire les adresses et les ports pour connecter des réseaux privés à Internet ou publier des services internes.
MASCARADE (A POSTROUTING du tableau nat) remplace l'IP source par l'IP de sortie du pare-feu, idéal lorsque l'IP publique est dynamique (DHCP). Il s'agit du NAT sortant typique pour un réseau local (LAN) complet.
SNAT (aussi dans POSTROUTING) définit explicitement l'IP/le port source avec --to-source. Il est utilisé lorsque vous avez une IP publique statique et vous souhaitez contrôler précisément la traduction.
DNAT (A PREROUTING o OUTPUT) changer l'IP de destination avec --to-destination. Ce sont les fameux « ports ouverts »:Vous recevez du trafic sur l'IP publique et le redirigez vers un serveur dans la DMZ, par exemple un site Web interne à 192.168.1.2.
Exemple simple : filtrage du trafic entre deux réseaux
Imaginez une machine agissant comme un routeur/pare-feu entre deux sous-réseaux. Si vous souhaitez que seul l'hôte B parle à C et uniquement via TCP, la table sera filter et la chaîne correcte est FORWARD, car le trafic passe par l'équipement.
Tout d'abord, vous appliqueriez un politique par défaut DROP sur FORWARD et vous autoriseriez ensuite explicitement le trafic B→C sur TCP (et, le cas échéant, C→B). Ce modèle « refuser par défaut, autoriser le moins possible » constitue le fondement d'une posture de sécurité solide.
Cas courants sur un podium : règles typiques
Une passerelle avec deux interfaces, par exemple eth1 (LAN) et eth0 (WAN), a généralement besoin de transférer des paquets du réseau local vers Internet. Pour ce faire, il ajoute FORWARD -i eth1 -o eth0 -j ACCEPTet autorise uniquement la marche arrière ESTABLISHED,RELATED avec -m state.
Dans le pare-feu lui-même, il est conseillé d'autoriser trafic entrant qui est une réponse aux connexions sortantes avec INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT, et autorisez toujours le bouclage : INPUT -i lo -j ACCEPT.
Pour permettre aux ordinateurs du réseau local de naviguer, appliquez le NAT sortant : -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j SNAT --to-source X.Y.Z.W (o MASQUERADE (si l'adresse IP est dynamique). Cela convertit les adresses IP privées en adresses IP publiques.
Un durcissement de base est bloquant Paquets entrants sur le WAN avec des adresses IP sources incorrectes (votre propre IP publique, plages privées 192.168.0.0/24, 127.0.0.0/8, etc.), car elles indiquent généralement une usurpation d'identité.
Pour exposer des services sur le pare-feu (par exemple, SMTP 25, HTTP 80, HTTPS 443 ou SSH 22), vous pouvez autoriser les paquets TCP avec l'indicateur SYN vers ces ports de destination. Si vous souhaitez affiner par IP de destination, ajoutez -d à l'IP du service.
Services d'infrastructure communs : DHCP (trafic du port 68 à 67) sur l'interface LAN, et DNS du résolveur autorisé (UDP 53) si vous filtrez par source. Ces ouvertures permettent aux clients d'obtenir des adresses IP et de résoudre des noms.
Si vous devez fermer l'accès, DROP vers SSH/Telnet entrant C'est direct ; vous pouvez également REJECT renvoie vers des adresses IP interdites du réseau local afin que l'expéditeur reçoive une notification de rejet.
Installation et gestion du service sur les systèmes Red Hat/CentOS
Dans les environnements hérités avec CentOS/RHEL 5/6, il suffisait de installer avec yum -y install iptablesBien que de nombreuses nouvelles distributions privilégient aujourd'hui nftables, iptables est toujours présent dans les systèmes et appareils de production.
Intégration avec Services SysV autorisé à gérer et à conserver les règles : service iptables start|stop|restart y service iptables save, économiser dans /etc/sysconfig/iptables. Pour activer au démarrage : chkconfig iptables on aux niveaux 2 à 5.
Dans les systèmes modernes, bien que le wrappers, l'idée persiste : définir des règles, les tester et s'y tenir afin qu'ils survivent aux redémarrages, soit avec des outils système, soit avec des scripts.
Lister, supprimer et modifier les règles avec précision
Pour voir le statut avec les numéros de règle, USA iptables -L --line-numbers -n -v. De cette façon, vous pouvez supprimer par index avec -D INPUT 3 ou remplacer par -R sans confusion.
Si vous avez besoin d'une suppression sélective, Nettoyez uniquement la chaîne ou la planche qui touche (-F FORWARD o -F -t nat). Évitez les balayages globaux à distance sans « filet de sécurité » ou vous risquez de perdre l’accès SSH.
En tant que pratique courante, Définissez d'abord les règles qui autorisent votre session SSH, appliquez les modifications progressivement et disposez d'une fenêtre de restauration (par exemple, un cron qui restaure les règles en 5 minutes si vous ne vous engagez pas).
Persistance avec iptables-save et iptables-restore
Pour enregistrer vos paramètres, iptables-save > /ruta/backup/iptables.rules Génère un vidage lisible par machine de toutes les tables. Idéal pour le contrôle des modifications et les migrations.
Pour le charger, utilisez iptables-restore < /ruta/backup/iptables.rulesVous pouvez automatiser la restauration du démarrage avec systemd, des scripts d'initialisation ou une tâche cron. @reboot, garantissant que le pare-feu reste actif après un redémarrage.
Ajoutez à cela de bonnes pratiques opérationnelles : s'exécute avec les privilèges appropriés, enregistrer les fichiers à l'extérieur /tmp et les aligner avec l'environnement (interfaces et sous-réseaux corrects) pour éviter les surprises.
DMZ en détail : un exemple complet et réaliste
Supposons qu'un pare-feu Linux soit connecté à un routeur en mode « mono-utilisateur » (sans NAT), avec trois interfaces : eth0 (LAN 192.168.1.1/24), eth1 (DMZ 192.168.2.1/24) et eth2 (WAN avec IP par DHCP)La DMZ abrite un Serveur Web Apache (192.168.2.2) et un FTP (192.168.2.3).
Objectifs de la politique : publier HTTP/HTTPS et FTP depuis la DMZ vers Internet, autoriser l'administration SSH du réseau local vers le pare-feu, et autoriser la navigation (HTTP/HTTPS), les transferts FTP et la résolution DNS sur le réseau local. Tout le reste est refusé.
En gros : en filtre/AVANT permet le transit LAN→WAN avec réponse, et WAN→DMZ vers les ports publiés uniquement avec ESTABLISHED,RELATED pour les réponses. Dans nat/PRÉROUTING, applique DNAT pour publier des services ; dans nat/POSTROUTING, SNAT/MASQUERADE pour sortie LAN/DMZ.
Exemples d'ouvertures : DNAT 80/443 à 192.168.2.2 et 21/20 (selon le mode) à 192.168.2.3 avec le correspondant FORWARD Autoriser ces ports. Sécuriser les canaux de contrôle et de données pour FTP (actif/passif) ou limiter la portée passive et refléter cette situation sur le pare-feu.
Pour le réseau local : permet la sortie vers 80, 443, 21 et 53 et son retour, en appliquant le NAT sortant dans POSTROUTING. Dans le pare-feu, autorisez SSH entrant uniquement depuis le sous-réseau 192.168.1.0/24 et bloque les accès indésirables depuis le WAN.
N'oubliez pas l'hygiène : DROP vers des plages non valides sur le WAN (privé, en boucle, public) et enregistrez tout ce qui vous intéresse. Grâce à des politiques par défaut restrictives et des ouvertures minimales, votre exposition est réduite au strict minimum.
Bonnes pratiques et astuces opérationnelles
Travaillez toujours avec un plan : documentez ce que vous autorisez et pourquoi, vérifiez le flux attendu avec un schéma simple et appliquez les règles dans le bon ordre pour éviter les chevauchements.
Utiliser une combinaison de modules avec une tête : état/piste de connexion pour les réponses, tcp con --syn dans les ouvertures, et multiport grouperDe cette façon, vous simplifiez et réduisez le risque d’incohérences.
Pour les environnements avec des changements fréquents, pensez à séparer les règles par fonction : chaînes personnalisées (Avec -N) appelle depuis INPUT/OUTPUT/FORWARD, de sorte que conserver ou inverser les pièces est plus propre.
La transition vers nftables est en cours sur de nombreuses distributions, mais si votre plateforme/produit utilise iptables, Connaître ces pièces à fond vous donnera un contrôle total.Et si vous migrez, vous comprendrez facilement la carte mentale équivalente dans nftables.
Avec ce que vous avez vu, vous disposez désormais d'une base solide pour déployer et maintenir iptables en production : Vous comprenez l'architecture (tables, chaînes et flux), vous maîtrisez les commandes essentielles, vous appliquez le NAT et la publication avec DNAT/SNAT, et vous savez mettre en place une DMZ sécurisée.À partir de là, c'est à vous de vous adapter à votre cas spécifique, d'effectuer des audits périodiques et de maintenir vos règles aussi claires que votre modèle de réseau.