Un plongeon profond dans l’architecture d’Iptables et de Netfilter

Introduction

Les pare-feu sont un outil important pouvant être configuré pour protéger vos serveurs et votre infrastructure. Dans l’écosystème Linux, iptables est un outil de pare-feu largement utilisé qui fonctionne avec le framework de filtrage de paquets netfilter du noyau. La création de politiques de pare-feu fiables peut être intimidante en raison de la syntaxe complexe et du nombre de parties interdépendantes impliquées.

Dans ce guide, nous plongerons dans l’architecture de iptables dans le but de la rendre plus compréhensible pour les utilisateurs qui doivent créer leurs propres politiques de pare-feu. Nous discuterons de la manière dont iptables interagit avec netfilter et de comment les différents composants s’assemblent pour fournir un système de filtrage complet.

Qu’est-ce que IPTables et Netfilter?

Pendant de nombreuses années, le logiciel de pare-feu le plus couramment utilisé dans Linux s’appelait iptables. Dans certaines distributions, il a été remplacé par un nouvel outil appelé nftables, mais la syntaxe de iptables est encore couramment utilisée comme référence. Le pare-feu iptables fonctionne en interagissant avec les crochets de filtrage des paquets dans la pile réseau du noyau Linux. Ces crochets du noyau sont connus sous le nom de cadre netfilter.

Chaque paquet qui passe par la couche réseau (entrant ou sortant) déclenchera ces crochets, permettant aux programmes d’interagir avec le trafic à des points clés. Les modules noyau associés à iptables s’enregistrent auprès de ces crochets afin de garantir que le trafic est conforme aux conditions établies par les règles du pare-feu.

Crochets Netfilter

Il existe cinq crochets netfilter auxquels les programmes peuvent s’enregistrer. Au fur et à mesure que les paquets progressent dans la pile, ils déclenchent les modules noyau qui se sont enregistrés auprès de ces crochets. Les crochets déclenchés par un paquet dépendent de la direction du paquet (entrant ou sortant), de sa destination et du fait que le paquet ait été rejeté ou abandonné à un point antérieur.

Les crochets suivants représentent ces points bien définis dans la pile réseau :

• NF_IP_PRE_ROUTING: Ce crochet sera déclenché par tout trafic entrant très rapidement après avoir pénétré dans la pile réseau. Ce crochet est traité avant que des décisions de routage n’aient été prises concernant où envoyer le paquet.
• NF_IP_LOCAL_IN: Ce crochet est déclenché après qu’un paquet entrant a été routé si le paquet est destiné au système local.
• NF_IP_FORWARD: Ce crochet est déclenché après qu’un paquet entrant a été routé si le paquet doit être transféré à un autre hôte.
• NF_IP_LOCAL_OUT: Ce crochet est déclenché par tout trafic sortant créé localement dès qu’il touche la pile réseau.
• NF_IP_POST_ROUTING: Ce crochet est déclenché par tout trafic sortant ou transféré après que le routage ait eu lieu et juste avant d’être envoyé sur le fil.

Les modules du noyau qui doivent s’enregistrer à ces crochets doivent également fournir un numéro de priorité pour aider à déterminer l’ordre dans lequel ils seront appelés lorsque le crochet sera déclenché. Cela fournit les moyens pour que plusieurs modules (ou plusieurs instances du même module) soient connectés à chacun des crochets avec un ordre déterministe. Chaque module sera appelé à son tour et renverra une décision au cadre netfilter après traitement, indiquant ce qui doit être fait avec le paquet.

Tables et chaînes IPTables

Le pare-feu iptables utilise des tables pour organiser ses règles. Ces tables classent les règles en fonction du type de décisions qu’elles sont utilisées pour prendre. Par exemple, si une règle concerne la translation d’adresse réseau, elle sera placée dans la table nat. Si la règle est utilisée pour décider si le paquet doit continuer vers sa destination, elle sera probablement ajoutée à la table filter.

A l’intérieur de chaque table iptables, les règles sont en outre organisées dans des « chaînes » distinctes. Alors que les tables sont définies par l’objectif général des règles qu’elles contiennent, les chaînes intégrées représentent les points d’ancrage netfilter qui les déclenchent. Les chaînes déterminent quand les règles seront évaluées.

Les noms des chaînes intégrées correspondent aux noms des points d’ancrage netfilter auxquels elles sont associées:

• PREROUTING: Déclenché par le point d’ancrage NF_IP_PRE_ROUTING.
• INPUT: Déclenché par le point d’ancrage NF_IP_LOCAL_IN.
• FORWARD: Déclenché par le point d’ancrage NF_IP_FORWARD.
• OUTPUT: Déclenché par le point d’ancrage NF_IP_LOCAL_OUT.
• POSTROUTING: Déclenché par le point d’ancrage NF_IP_POST_ROUTING.

Les chaînes permettent à l’administrateur de contrôler à quel moment le traitement d’une règle aura lieu dans le parcours de livraison d’un paquet. Étant donné que chaque table possède plusieurs chaînes, l’influence d’une table peut s’exercer à plusieurs points du traitement. Étant donné que certains types de décisions n’ont de sens qu’à certains points de la pile réseau, toutes les tables n’ont pas une chaîne enregistrée avec chaque point d’ancrage du noyau.

Il y a seulement cinq crochets du noyau netfilter, donc des chaînes de plusieurs tables sont enregistrées à chacun des crochets. Par exemple, trois tables ont des chaînes PREROUTING. Lorsque ces chaînes s’enregistrent au crochet associé NF_IP_PRE_ROUTING, elles spécifient une priorité qui dicte l’ordre d’appel de la chaîne PREROUTING de chaque table. Chacune des règles à l’intérieur de la chaîne PREROUTING de plus haute priorité est évaluée séquentiellement avant de passer à la chaîne PREROUTING suivante. Nous examinerons l’ordre spécifique de chaque chaîne dans un moment.

Quelles tables sont disponibles?

Reculons un moment et examinons les différentes tables fournies par iptables. Elles représentent des ensembles distincts de règles, organisés par domaine d’intérêt, pour l’évaluation des paquets.

La table Filter

La table de filtrage est l’une des tables les plus largement utilisées dans iptables. La table filter est utilisée pour prendre des décisions sur la poursuite ou le refus d’une demande de paquet vers sa destination prévue. Dans le jargon des pare-feu, cela s’appelle « filtrer » les paquets. Cette table fournit la majeure partie des fonctionnalités que les gens associent aux pare-feu.

La table NAT

La table nat est utilisée pour mettre en œuvre des règles de translation d’adresses réseau. Lorsque les paquets entrent dans la pile réseau, les règles de cette table déterminent si et comment modifier les adresses source ou destination du paquet afin d’impact l’acheminement du paquet et de tout trafic de réponse. Cela est souvent utilisé pour acheminer les paquets vers des réseaux lorsque l’accès direct n’est pas possible.

La table Mangle

La table mangle est utilisée pour modifier les en-têtes IP du paquet de différentes manières. Par exemple, vous pouvez ajuster la valeur TTL (Time to Live) d’un paquet, en allongeant ou en raccourcissant le nombre de sauts réseau valides que le paquet peut supporter. D’autres en-têtes IP peuvent être modifiés de manière similaire.

Cette table peut également placer un « marquage » interne du noyau sur le paquet pour un traitement ultérieur dans d’autres tables et par d’autres outils de mise en réseau. Ce marquage n’affecte pas le paquet réel, mais ajoute le marquage à la représentation du paquet par le noyau.

La table Raw

Le pare-feu iptables est étatique, ce qui signifie que les paquets sont évalués en fonction de leur relation avec les paquets précédents. Les fonctionnalités de suivi de connexion, construites sur le framework netfilter, permettent à iptables de voir les paquets comme faisant partie d’une connexion ou d’une session en cours plutôt que comme un flux de paquets distincts et non liés. La logique de suivi de connexion est généralement appliquée très rapidement après que le paquet atteint l’interface réseau.

La table raw a une fonction très précisément définie. Son seul but est de fournir un mécanisme pour marquer les paquets afin de les exclure du suivi de connexion.

La Table de Sécurité

La table security est utilisée pour définir des marques de contexte de sécurité SELinux internes sur les paquets, ce qui affectera la manière dont SELinux ou d’autres systèmes pouvant interpréter les contextes de sécurité SELinux gèrent les paquets. Ces marques peuvent être appliquées sur une base par paquet ou par connexion.

Relations entre les Chaînes et les Tables

Si trois tables ont des chaînes PREROUTING, dans quel ordre sont-elles évaluées?

La table suivante indique les chaînes disponibles dans chaque tableau iptables lorsqu’elles sont lues de gauche à droite. Par exemple, on peut voir que le tableau raw a à la fois les chaînes PREROUTING et OUTPUT. Lorsqu’elles sont lues de haut en bas, elle affiche également l’ordre dans lequel chaque chaîne est appelée lorsque le crochet associé à netfilter est déclenché.

A few things should be noted. In the representation below, the nat table has been split between DNAT operations (those that alter the destination address of a packet) and SNAT operations (those that alter the source address) in order to display their ordering more clearly. We have also include rows that represent points where routing decisions are made and where connection tracking is enabled in order to give a more holistic view of the processes taking place:

À mesure qu’un paquet déclenche un crochet netfilter, les chaînes associées seront traitées comme indiqué dans le tableau ci-dessus, de haut en bas. Les crochets (colonnes) qu’un paquet déclenchera dépendent de s’il s’agit d’un paquet entrant ou sortant, des décisions de routage prises et de la satisfaction des critères de filtrage.

Certains événements feront que la chaîne d’une table sera ignorée lors du traitement. Par exemple, seul le premier paquet d’une connexion sera évalué par rapport aux règles NAT. Toutes les décisions nat prises pour le premier paquet seront appliquées à tous les paquets ultérieurs de la connexion sans évaluation supplémentaire. Les réponses aux connexions NAT auront automatiquement les règles NAT inverses appliquées pour être routées correctement.

Ordre de Traversée des Chaînes

En supposant que le serveur sait comment router un paquet et que les règles du pare-feu permettent sa transmission, les flux suivants représentent les chemins qui seront parcourus dans différentes situations:

• Paquets entrants destinés au système local: PREROUTING -> INPUT
• Paquets entrants destinés à un autre hôte: PREROUTING -> FORWARD -> POSTROUTING
• Paquets générés localement: OUTPUT -> POSTROUTING

Si nous combinons les informations ci-dessus avec l’ordre établi dans le tableau précédent, nous pouvons voir qu’un paquet entrant destiné au système local sera d’abord évalué par les chaînes PREROUTING des tables raw, mangle, et nat. Il traversera ensuite les chaînes INPUT des tables mangle, filter, security, et nat avant d’être finalement remis à la prise locale.

Règles IPTables

Les règles sont placées dans une chaîne spécifique d’une table spécifique. À chaque appel de chaîne, le paquet en question sera vérifié par rapport à chaque règle dans la chaîne, dans l’ordre. Chaque règle a une composante de correspondance et une composante d’action.

Correspondance

La partie correspondante d’une règle spécifie les critères qu’un paquet doit remplir pour que l’action associée (ou « cible ») soit exécutée.

Le système de correspondance est très flexible et peut être étendu de manière significative avec des extensions iptables supplémentaires. Les règles peuvent être construites pour correspondre au type de protocole, à l’adresse de destination ou source, au port de destination ou source, au réseau de destination ou source, à l’interface d’entrée ou de sortie, aux en-têtes ou à l’état de la connexion, entre autres critères. Ils peuvent être combinés pour créer des ensembles de règles complexes afin de distinguer différents types de trafic.

Cibles

A “target” refers to the actions that are triggered when a packet meets the matching criteria of a rule. Targets are generally divided into two categories:

• Cibles de terminaison: Les cibles de terminaison effectuent une action qui met fin à l’évaluation dans la chaîne et renvoie le contrôle au crochet netfilter. Selon la valeur de retour fournie, le crochet peut abandonner le paquet ou permettre au paquet de continuer vers la prochaine étape du traitement.
• Cibles non terminales: Les cibles non terminales effectuent une action et poursuivent l’évaluation dans la chaîne. Bien que chaque chaîne doive finalement renvoyer une décision finale de terminaison, un nombre quelconque de cibles non terminales peuvent être exécutées au préalable.

La disponibilité de chaque cible dans les règles dépendra du contexte. Par exemple, le type de table et de chaîne peut dicter les cibles disponibles. Les extensions activées dans la règle et les clauses de correspondance peuvent également affecter la disponibilité des cibles.

Passer aux chaînes définies par l’utilisateur

Il existe également une classe spéciale de cibles non terminales : la cible de saut. Les cibles de saut sont des actions qui entraînent le déplacement de l’évaluation vers une autre chaîne pour un traitement supplémentaire. Nous avons couvert les chaînes intégrées qui sont liées aux crochets netfilter qui les appellent. Cependant, iptables permet également aux administrateurs de créer leurs propres chaînes à des fins organisationnelles.

Les règles peuvent être placées dans des chaînes définies par l’utilisateur de la même manière qu’elles peuvent être placées dans des chaînes intégrées. La différence est que les chaînes définies par l’utilisateur ne peuvent être atteintes que par un « saut » vers elles à partir d’une règle (elles ne sont pas enregistrées avec un crochet netfilter eux-mêmes).

Les chaînes définies par l’utilisateur agissent comme des extensions de la chaîne qui les a appelées. Par exemple, dans une chaîne définie par l’utilisateur, l’évaluation passera de nouveau à la chaîne appelante si la fin de la liste des règles est atteinte ou si une cible RETURN est activée par une règle correspondante. L’évaluation peut également sauter vers des chaînes définies par l’utilisateur supplémentaires.

Ce dispositif permet une meilleure organisation et fournit le cadre nécessaire pour des branchements plus robustes.

IPTables et suivi des connexions

Nous avons introduit le système de suivi des connexions implémenté sur le dessus du framework netfilter lorsque nous avons discuté de la table raw et des critères de correspondance d’état de connexion. Le suivi des connexions permet à iptables de prendre des décisions concernant les paquets visualisés dans le contexte d’une connexion en cours. Le système de suivi des connexions fournit à iptables la fonctionnalité nécessaire pour effectuer des opérations « étatiques ».

Le suivi des connexions est appliqué très rapidement après l’entrée des paquets dans la pile réseau. Les chaînes de la table raw et quelques vérifications de cohérence sont les seules logiques effectuées sur les paquets avant d’associer les paquets à une connexion.

Le système vérifie chaque paquet par rapport à un ensemble de connexions existantes. Il mettra à jour l’état de la connexion dans son magasin si nécessaire et ajoutera de nouvelles connexions au système lorsque cela sera nécessaire. Les paquets marqués avec la cible NOTRACK dans l’une des chaînes raw contourneront les routines de suivi des connexions.

États disponibles

Les connexions suivies par le système de suivi des connexions seront dans l’un des états suivants :

• NEW : Lorsqu’un paquet arrive qui n’est pas associé à une connexion existante, mais qui n’est pas non plus invalide en tant que premier paquet, une nouvelle connexion sera ajoutée au système avec cette étiquette. Cela se produit à la fois pour les protocoles conscients de la connexion comme TCP et pour les protocoles sans connexion comme UDP.
• ÉTABLIE: Une connexion passe de NOUVELLE à ÉTABLIE lorsqu’elle reçoit une réponse valide dans la direction opposée. Pour les connexions TCP, cela signifie un SYN/ACK et pour le trafic UDP et ICMP, cela signifie une réponse où la source et la destination du paquet original sont inversées.
• CONNEXE: Les paquets qui ne font pas partie d’une connexion existante, mais qui sont associés à une connexion déjà dans le système, sont étiquetés CONNEXE. Cela pourrait signifier une connexion auxiliaire, comme c’est le cas avec les connexions de transmission de données FTP, ou cela pourrait être des réponses ICMP à des tentatives de connexion par d’autres protocoles.
• INVALIDE: Les paquets peuvent être marqués comme INVALIDE s’ils ne sont pas associés à une connexion existante et ne conviennent pas pour ouvrir une nouvelle connexion, s’ils ne peuvent pas être identifiés, ou s’ils ne sont pas routables entre autres raisons.
• NON SUIVIE: Les paquets peuvent être marqués comme NON SUIVIS s’ils ont été ciblés dans une chaîne de table raw pour contourner le suivi.
• SNAT: Il s’agit d’un état virtuel défini lorsque l’adresse source a été modifiée par des opérations NAT. Cela est utilisé par le système de suivi de connexion afin qu’il sache changer les adresses source dans les paquets de réponse.
• DNAT: Il s’agit d’un état virtuel défini lorsque l’adresse de destination a été modifiée par des opérations NAT. Cela est utilisé par le système de suivi de connexion afin qu’il sache changer l’adresse de destination lors du routage des paquets de réponse.

Les états suivis dans le système de suivi de connexion permettent aux administrateurs de créer des règles ciblant des points spécifiques de la durée de vie d’une connexion. Cela offre les fonctionnalités nécessaires pour des règles plus approfondies et sécurisées.

Conclusion

Le framework de filtrage de paquets netfilter et le pare-feu iptables sont à la base de la plupart des solutions de pare-feu sur les serveurs Linux. Les hooks du kernel netfilter sont suffisamment proches de la pile réseau pour fournir un contrôle puissant sur les paquets lors de leur traitement par le système. Le pare-feu iptables exploite ces capacités pour fournir une méthode flexible et extensible de communication des exigences de politique au kernel. En comprenant comment ces éléments s’articulent, vous pouvez mieux les utiliser pour contrôler et sécuriser vos environnements serveur.

Si vous souhaitez en savoir plus sur la manière de choisir des politiques iptables efficaces, consultez ce guide.

Ces guides peuvent vous aider à commencer à mettre en œuvre vos règles de pare-feu iptables:

• Comment configurer un pare-feu avec Iptables
• Essentiels d’Iptables : Règles et commandes de pare-feu courantes
• Comment configurer un pare-feu avec UFW sur Ubuntu 22.04
• Comment configurer un pare-feu en utilisant firewalld sur Rocky Linux 8
• Comment configurer un pare-feu Iptables pour protéger le trafic entre vos serveurs