- 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 administrez des distributions Linux pour protéger votre sécurité et votre confidentialité , vous serez tôt ou tard amené à utiliser iptables. Ce système de filtrage de paquets est au cœur du pare-feu classique de GNU/Linux ; il contrôle le trafic entrant, sortant et acheminé entre les réseaux. Correctement configuré, il agit comme un gardien extrêmement compétent à l'entrée de votre réseau, appliquant vos règles avec une précision chirurgicale.
Vous trouverez ci-dessous un guide complet et actualisé qui aborde les notions essentielles : concepts de pare-feu , Netfilter, tables et chaînes, flux de paquets, commandes clés, extensions de règles et cibles avancées , ainsi que des scénarios pratiques tels que la NAT, les redirections, les politiques par défaut et une DMZ fonctionnelle. Tout est expliqué clairement et rigoureusement, vous permettant ainsi de l'appliquer immédiatement à votre infrastructure.
Les pare-feu en contexte : des videurs de boîtes de nuit à la DMZ
Un pare-feu est essentiellement un filtre entre les réseaux qui applique des règles pour décider du sort de chaque paquet. Imaginez un videur à l'entrée d'une boîte de nuit avec une liste de contrôle : si le paquet remplit les critères, il est autorisé ; sinon, il est refusé. Cette métaphore permet de comprendre que l'important réside dans la logique des règles et l'ordre dans lequel elles sont évaluées.
En matière de conception de réseaux, 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 site web ou un serveur FTP), les séparant du réseau local de l'entreprise. Pourquoi ? Parce que si un attaquant parvenait à compromettre 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 doté de points d'entrée permettant d'intercepter et de manipuler les paquets . Côté utilisateur, iptables définit les règles que le noyau appliquera au trafic. Cette séparation entre noyau et utilisateur garantit des performances élevées et une grande flexibilité.
Il est utile de distinguer les utilitaires selon leur 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 correspondance entre les extensions et les cibles. À noter historiquement : iptables a remplacé ipchains, puis nftables a succédé à iptables dans le noyau 3.13 , bien qu’iptables reste largement utilisé 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 de règles . Chaque règle spécifie des 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 atteint une chaîne, il est comparé séquentiellement à chaque règle ; s'il correspond, sa cible est exécutée et le parcours s'arrête. S'il atteint la fin sans correspondre à aucune règle et que la chaîne est prédéfinie, la politique de chaîne par défaut est appliquée.
Flux de paquets : où ils passent et quand
Comprendre le cheminement du trafic est essentiel pour appliquer correctement les règles. Un paquet quittant votre réseau local pour Internet est généralement traité comme suit : d’abord le PREROUTING (éventuellement DNAT/mangle), puis le FORWARD (filtrage de transit), et avant de quitter le périphérique, il subit un POSTROUTING (SNAT/MASQUERADE le cas échéant).
À l'inverse, si la destination est le pare-feu lui-même, le chemin sera PREROUTING → INPUT ; s'il provient de la machine locale, le chemin sera OUTPUT → POSTROUTING . Ce schéma mental vous évitera bien des soucis en cas d'incohérence.
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 le protocole UDP, vous pouvez également restreindre les ports source et de destination . Un exemple classique : ouvrir les ports 80 et 443 pour un serveur web ou autoriser les requêtes DNS sortantes sur le port 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 pour annoncer 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.
Vous appliqueriez d'abord une politique DROP par défaut sur le trafic FORWARD , puis autoriseriez explicitement le trafic B→C sur TCP (et, le cas échéant, C→B). Ce modèle de « refus par défaut et autorisation du strict minimum » constitue le fondement d'une sécurité robuste.
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.
Une mesure de renforcement de base consiste à bloquer les paquets WAN entrants avec des adresses IP source incorrectes (votre propre adresse IP publique, les 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.
Les services d'infrastructure typiques incluent le DHCP (trafic des ports 68 à 67) sur l'interface LAN et le DNS du résolveur faisant autorité (UDP 53) en cas de filtrage par source. Ces ports permettent aux clients d'obtenir des adresses IP et de résoudre des noms de domaine.
Si vous devez bloquer l'accès, la commande DROP pour les connexions SSH/Telnet entrantes est simple ; vous pouvez également rejeter les messages sortants vers les adresses IP bloquées sur le 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, même si les interfaces changent , l'idée persiste : définir des règles, les tester et les rendre persistantes afin qu'elles survivent aux redémarrages, que ce soit avec des outils système ou 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 règle générale, commencez par mettre en place des règles qui autorisent votre session SSH , appliquez les modifications progressivement et prévoyez une fenêtre de restauration (par exemple, une tâche cron qui rétablit les règles dans 5 minutes si vous ne les validez 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
Considérons un pare-feu Linux 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 adresse IP attribuée par DHCP) . La DMZ héberge un serveur web Apache (192.168.2.2) et un serveur FTP (192.168.2.3).
Objectifs de la politique : publier les protocoles HTTP/HTTPS et FTP depuis la DMZ vers Internet , permettre l’administration SSH depuis le réseau local vers le pare-feu, et permettre au réseau local de naviguer (HTTP/HTTPS), de transférer des fichiers via FTP et de résoudre les noms de domaine (DNS). Tout autre accès est interdit.
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 les règles d'hygiène réseau : bloquez le trafic vers les plages d'adresses invalides sur le WAN (réseau privé, bouclage, votre propre réseau public) et ne consignez que les données pertinentes. 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 à l’aide d’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 dans de nombreuses distributions, mais si votre plateforme/produit utilise iptables, une compréhension approfondie de ces composants vous permettra d'en avoir un contrôle total . Et si vous migrez, vous comprendrez facilement le fonctionnement équivalent dans nftables.
Grâce aux connaissances acquises, 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 pouvez implémenter la NAT et publier avec DNAT/SNAT, et vous savez comment configurer une DMZ sécurisée . Il s'agit maintenant de l'adapter à vos besoins spécifiques, d'effectuer des audits réguliers et de veiller à ce que vos règles soient aussi claires que votre modèle réseau.