L'architecture d'Iptables et Netfilter

Un pare-feu est un dispositif de sécurité (matériel/logiciel) qui protège le réseau en filtrant le trafic et en bloquant les accès indésirables/non autorisés aux données privées. Disposer d’un pare-feu approprié est important pour protéger vos serveurs et votre infrastructure. Il peut non seulement bloquer le trafic indésirable, mais aussi empêcher les logiciels malveillants d’infecter le système.

Dans l’écosystème Linux, iptables est un pare-feu populaire qui s’interface avec le netfilter framework du noyau Linux. La plupart des systèmes Linux modernes sont livrés avec ces outils préinstallés. Pour tirer le meilleur parti de ces systèmes, il est essentiel de comprendre leur architecture. Sinon, l’élaboration de politiques de pare-feu fiables peut s’avérer décourageante. Cela pourrait conduire à la création de syntaxes complexes, de parties interdépendantes dans le framework, etc.

Ce guide plongera au cœur de l’architecture de iptables pour aider les utilisateurs qui ont besoin de créer leurs propres politiques de pare-feu. Nous explorerons également comment iptables s’interface avec netfilter et comment les différents composants s’assemblent.

Iptables et Netfilter

Sous Linux, le iptables pare-feu est le plus courant. Il fonctionne en s’interfaçant avec les hooks de filtrage de paquets de la pile réseau du noyau Linux. Ce sont ces hooks du noyau qui sont collectivement appelés le netfilter framework.

Chaque paquet entrant/sortant dans le système déclenchera ces hooks au fur et à mesure de sa progression dans la pile. Ainsi, les programmes enregistrés auprès de ces hooks sont capables d’interagir avec le trafic à des moments clés. Enfin, les modules du noyau associés à iptables se connectent à ces hooks pour appliquer les règles de pare-feu spécifiées.

Hooks Netfilter

Pour que les programmes se connectent, il existe cinq différents netfilter hooks. Au fur et à mesure que les paquets progressent dans la pile, les hooks déclenchent les modules du noyau enregistrés auprès d’eux. La condition de déclenchement dépend de conditions telles que : le sens du paquet (entrant/sortant), la destination du paquet, si le paquet a été rejeté/abandonné à un point précédent, etc.

Voici les hooks représentant différents points bien définis dans la pile réseau :

• NF_IP_PRE_ROUTING : ce hook est déclenché par tout trafic entrant. Le déclenchement a lieu avant qu’une décision de routage ne soit prise concernant la destination du paquet.

• NF_IP_LOCAL_IN : ce hook est déclenché après le routage d’un paquet entrant. Le paquet doit également être destiné au système local.

• NF_IP_FORWARD : ce hook est également déclenché après le routage d’un paquet entrant. Cependant, il se déclenche si le paquet doit être routé vers un autre hôte.

• NF_IP_LOCAL_OUT : tout trafic local sortant, dès qu’il atteint la pile réseau, déclenche ce hook.

• NF_IP_POST_ROUTING : ce hook est déclenché par tout trafic sortant/transféré après que le routage a eu lieu, avant que le paquet n’atteigne le réseau.

Les modules du noyau souhaitant s’enregistrer sur ces hooks doivent fournir un numéro de priorité. Cette valeur permet de déterminer l’ordre dans lequel ils seront appelés une fois le hook déclenché. Un tel mécanisme permet à plusieurs modules (différents modules ou plusieurs copies du même module) de se connecter à chacun des hooks dans un ordre déterministe. Chaque module renverra une décision au netfilter framework après avoir traité les paquets.

Tables et chaînes dans Iptables

Pour organiser ses règles, le pare-feu iptables utilise des tables. Les tables catégorisent les règles en fonction du type de décisions qu’elles prennent. Par exemple, si une règle concerne le NAT (traduction d’adresses réseau), elle est alors placée sous la table nat . De même, si une règle décide d’autoriser ou de refuser un paquet vers sa destination, elle est ajoutée à la table filter .

À l’intérieur de chaque table de iptables, les règles sont en outre organisées au sein de “chaînes” distinctes. Alors que la table représente le type de règles qu’elles contiennent, les chaînes décrivent les netfilter hooks qui déclenchent les règles. En résumé, les chaînes déterminent quand la règle sera évaluée.

Voici les chaînes intégrées de iptables. Fait intéressant, les noms des chaînes reflètent également le nom des hooks netfilter associés :

En utilisant les chaînes, les administrateurs peuvent déterminer à quelle étape de la distribution des paquets la règle sera évaluée. Comme chaque table contient plusieurs chaînes, elle peut également étendre son influence à plusieurs points du traitement. Certaines décisions n’ont de sens qu’à certains points de la pile réseau. Ainsi, toutes les tables n’auront pas une chaîne enregistrée pour chaque hook du noyau.

Le framework netfilter ne propose que 5 hooks de noyau. À ce titre, des chaînes de plusieurs tables sont enregistrées à chaque point des hooks. Par exemple, si trois chaînes ont les chaînes PREROUTING , alors elles sont enregistrées auprès du hook NF_IP_PRE_ROUTING . Chacune d’elles doit fournir une priorité qui décide dans quel ordre la chaîne PREROUTING de chaque table est appelée. La chaîne PREROUTING ayant la priorité la plus élevée est évaluée en premier, celle de priorité immédiatement inférieure en second, et ainsi de suite.

Les tables iptables

Prenons un peu de recul et examinons les tables que propose iptables . Comme mentionné précédemment, chaque table représente différents ensembles de règles, organisés par domaine de préoccupation, pour l’évaluation des paquets.

• Table filter

Dans iptables , la table filter est l’une des plus populaires. Elle est utilisée pour déterminer si un paquet sera autorisé à continuer vers sa destination ou non. Dans la terminologie des pare-feu, ce processus est appelé le “filtrage” de paquets.

Ce sont les fonctions de la table filter auxquelles les gens font référence lorsqu’ils parlent de pare-feu (pour la plupart).

• Table nat

Cette table implémente des règles régissant le NAT. Lorsque des paquets entrent dans la pile réseau, les règles décrites dans cette table décident de la manière de modifier l’adresse source/destination du paquet, ce qui a un impact sur le routage du paquet et sur tout trafic de réponse.

Souvent, la table nat est utilisée pour acheminer des paquets vers des réseaux où il n’y a pas d’accès direct.

• Table mangle

Cette table contient les règles qui modifient les en-têtes IP des paquets de diverses manières. Par exemple, elle peut modifier la valeur TTL (Time to Live) d’un paquet en prolongeant/raccourcissant le nombre de sauts réseau valides que le paquet peut supporter. De plus, la table mangle peut modifier d’autres en-têtes IP de manière similaire.

Cette table est également autorisée à apposer une “marque” interne du noyau sur le paquet, que d’autres tables et outils réseau peuvent récupérer pour un traitement ultérieur. Cette marque ne touche pas au paquet réel, mais ajoute plutôt la marque à la représentation du paquet par le noyau.

• Table raw

Le pare-feu iptables est à conservation d’état (stateful), ce qui implique que les paquets sont évalués dans le contexte de leur relation avec les paquets précédents. La fonctionnalité de suivi des connexions développée au-dessus du framework netfilter permet à iptables de considérer les paquets comme faisant partie d’une connexion ou d’une session en cours plutôt que comme un flux de paquets distincts et sans relation. Généralement, la logique de suivi des connexions est appliquée très rapidement après que le paquet a atteint l’interface réseau.

La table raw possède une fonction très précisément définie. Le seul but de cette table est de fournir un mécanisme de marquage des paquets afin de les exclure du suivi des connexions.

• Table security

La table security place des marques de contexte de sécurité SELinux internes sur les paquets. Cela affecte à son tour la manière dont SELinux (ou toute autre application qui interprète les contextes de sécurité SELinux) gérera les paquets.

Les marques SELinux peuvent être appliquées par paquet ou par connexion.

Chaînes implémentées dans chaque table

Jusqu’ici, nous avons parlé des tables et des chaînes séparément. Il est temps de passer en revue les chaînes disponibles pour chaque table. Ce sujet prolonge la discussion sur l’ordre d’évaluation des chaînes enregistrées sur le même hook. Par exemple, que se passe-t-il si trois tables ont des chaînes PREROUTING ? Quel est leur ordre d’évaluation ?

Ensuite, jetez un œil au tableau suivant. Il indique les chaînes disponibles dans chaque table iptables .

Lorsqu'il est lu de gauche à droite, il décrit quelles tables contiennent quelles chaînes. Par exemple, la table raw possède à la fois les chaînes PREROUTING et OUTPUT . Lorsqu'il est lu de haut en bas, il décrit dans quel ordre chaque chaîne est appelée lorsque son hook netfilter associé est déclenché.

Notez que la table nat a été divisée entre les opérations DNAT (modifiant la destination d'un paquet) et les opérations SNAT (modifiant la source d'un paquet) pour spécifier leur ordre plus clairement. Le tableau comprend également des points de représentation où les décisions de routage sont prises et où le suivi des connexions est activé.

Les hooks (colonnes) qu'un paquet va déclencher dépendent de la nature du paquet (entrant/sortant), des décisions de routage prises et du fait que le paquet réponde ou non aux critères de filtrage.

Certains événements peuvent ignorer la chaîne d'une table lors du traitement. Par exemple, seul le premier paquet d'une connexion sera évalué par rapport aux règles NAT comme décrit par la table nat . Tout paquet ultérieur de la même connexion se verra appliquer les mêmes décisions nat sans aucune évaluation supplémentaire. Les réponses aux connexions NAT se verront automatiquement appliquer les règles NAT inverses pour un routage correct.

Ordre de traversée des chaînes

En supposant que le serveur connaisse les règles de routage des paquets et que les règles du pare-feu autorisent la transmission, les flux suivants représentent la manière dont les différents chemins seront traversés :

• 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

En conclusion, en combinant toutes les informations dont nous avons discuté jusqu'à présent, nous pouvons voir que tout paquet entrant destiné au système local sera évalué par rapport aux chaînes PREROUTING des tables raw, mangle, et nat . Ensuite, il passera par les chaînes INPUT des tables mangle, filter, security, et nat avant d'atteindre finalement le socket local.

Règles Iptables

Les règles de pare-feu iptables sont placées dans une chaîne spécifique d'une table spécifique. Lorsqu'une chaîne est appelée, le paquet en question sera évalué par rapport à chaque règle de la chaîne. Chaque règle comporte deux composants : un composant de correspondance et un composant d'action.

• Correspondance

La partie correspondance d'une règle spécifie les conditions qu'un paquet doit remplir avant que l'action spécifiée (ou “cible”) ne soit exécutée.

Le système de correspondance offre une flexibilité incroyable. Ses fonctionnalités peuvent également être étendues à l'aide des extensions iptables . Des règles peuvent être définies pour faire correspondre les paquets selon le type de protocole, l'adresse source/destination, le port source/destination, le réseau source/destination, l'interface d'entrée/sortie, les en-têtes, l'état de la connexion et d'autres critères. Une règle peut également combiner ces conditions, ce qui permet d'obtenir des ensembles de règles complexes pour différencier les différents trafics.

• Cibles

Une cible est l'action entreprise lorsqu'un paquet remplit les critères de correspondance d'une règle. Généralement, les cibles sont divisées en deux groupes :

• • Cibles de terminaison : elles terminent le processus d'évaluation au sein de la chaîne et renvoient le contrôle au hook netfilter . En fonction de la valeur de retour, le hook permettra au paquet de continuer son chemin ou le rejettera.

  • Cibles sans terminaison : la cible effectue une action et l'évaluation dans la chaîne se poursuit. Bien que chaque chaîne doive passer par une décision finale de terminaison, un nombre illimité de cibles sans terminaison peut intervenir auparavant.

La disponibilité de chaque cible au sein des règles dépend du contexte. Par exemple, le type de chaîne et de table peut avoir un impact sur la disponibilité des cibles. D'autres facteurs possibles incluent les extensions activées dans la règle et les clauses de correspondance.

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 effectuées lorsque l’évaluation passe d’une chaîne à une autre pour un traitement supplémentaire. Jusqu’à présent, nous avons parlé des chaînes intégrées qui sont étroitement liées aux netfilter hooks qui les appellent. Cependant, iptables permet également aux administrateurs de créer leurs propres chaînes personnalisées.

Les règles des chaînes définies par l’utilisateur sont également similaires à celles des chaînes intégrées. La différence clé est que les chaînes définies par l’utilisateur ne sont accessibles qu’en “sautant” vers elles depuis une règle. C’est parce que les chaînes définies par l’utilisateur ne sont liées à aucun netfilter hooks.

Vous pouvez considérer les chaînes définies par l’utilisateur comme des extensions de la chaîne qui les a initialement appelées. Par exemple, dans une chaîne définie par l’utilisateur, l’évaluation retournera à la chaîne d’appel si elle atteint la fin de la liste des règles ou si une règle correspondante exécute une RETURN cible. Fait intéressant, une chaîne définie par l’utilisateur peut également faire “sauter’ l’évaluation vers une autre chaîne définie par l’utilisateur.

Cette fonctionnalité jette les bases d’une meilleure organisation et fournit le cadre nécessaire à un branchement robuste.

Suivi des connexions

Lors de la discussion de la table raw et des critères de correspondance de l’état de connexion, nous avons abordé le système de suivi des connexions implémenté au-dessus du framework netfilter. Cette fonctionnalité permet à iptables  de visualiser les paquets dans le contexte d’une connexion en cours. Le système de suivi des connexions fournit également à iptables les fonctionnalités nécessaires pour effectuer des opérations “à état”.

Juste après qu’un paquet entre dans la pile réseau, le suivi des connexions est appliqué. Les chaînes de la table raw et quelques vérifications de base de cohérence constituent toute la logique nécessaire pour associer les paquets à une connexion.

Le système vérifie chaque paquet par rapport à un ensemble de connexions existantes. Si nécessaire, le système mettra à jour l’état des connexions existantes ou en créera de nouvelles. Les paquets marqués avec la cible NOTRACK dans n’importe quelle chaîne de la table raw contourneront les routines de suivi de connexion ultérieures.

• États disponibles

Les connexions suivies par le système de suivi des connexions se verront attribuer l’un des états suivants :

• • NEW : À l’arrivée d’un paquet qui n’est pas associé à une connexion existante mais qui n’est pas invalide en tant que premier paquet, une nouvelle connexion est ajoutée au système avec cette étiquette. Cela se produit à la fois pour les protocoles orientés connexion (TCP, par exemple) et les protocoles sans connexion (UDP, par exemple).

  • ESTABLISHED: L’état d’une connexion est mis à jour de NEW  à ESTABLISHED lorsqu’elle reçoit une réponse valide de la direction opposée. Pour les connexions TCP, cela signifie un SYN/ACK. Pour le trafic UDP et ICMP, cela signifie une réponse où la source et la destination du paquet d’origine sont inversées.

  • RELATED: Les paquets qui ne font pas partie d’une connexion mais qui sont liés à une connexion établie sont étiquetés comme RELATED . Cela peut signifier une connexion auxiliaire (par exemple, dans une connexion de transmission de données FTP), ou des réponses ICMP à des tentatives de connexion par d'autres protocoles.

  • INVALID: Les paquets qui ne font pas partie d’une connexion établie, sont jugés inappropriés pour ouvrir une nouvelle connexion, ne peuvent pas être identifiés, ne sont pas routables, etc., sont étiquetés comme INVALID.

  • UNTRACKED: Un paquet peut être étiqueté comme UNTRACKED s’il a été ciblé dans une chaîne de la table raw pour contourner le suivi.

  • SNAT: Cela signifie un état virtuel défini lorsque l’adresse source est modifiée par une opération NAT. Il est géré par le système de suivi des connexions afin que les adresses sources soient traduites dans les paquets de réponse.

  • DNAT: Similaire à SNAT, cela signifie un état virtuel lorsque l'adresse de destination est modifiée par une opération NAT. Le système de suivi des connexions le gère de manière à savoir retraduire l'adresse de destination lors du routage des paquets de réponse.

Ces états suivis par le système de suivi des connexions permettent aux administrateurs de concevoir des règles spécifiques ciblant des moments précis de la durée de vie d'une connexion. Cela fournit les fonctionnalités nécessaires pour des règles plus approfondies et sécurisées.

Réflexions finales

Sous Linux, le netfilter framework et le iptables pare-feu servent de base à la plupart des pare-feu. Les hooks netfilter sont suffisamment proches de la pile réseau pour permettre un contrôle puissant sur les paquets traités par le système. En tirant parti de ces capacités, le iptables pare-feu offre un moyen flexible de communiquer les exigences de politique au noyau.

Ce guide examine en détail la structure interne du netfilter framework et de iptables pare-feu. De plus, il aborde le système de suivi des connexions. En comprenant comment ces éléments s'assemblent, vous pourrez mieux les utiliser pour concevoir des environnements de serveurs plus robustes et sécurisés.

Enfin, bien que ce guide aborde le fonctionnement interne, consultez ce guide sur la configuration d'iptables pour les mettre en pratique. De plus, vous pouvez voir comment le pare-feu UFW simplifie encore plus iptables. De plus, il sera utile d'apprendre comment lister et supprimer les règles de pare-feu iptables.

Bonne informatique !