Une plongée profonde dans Iptables et l'architecture Netfilter

De Get Docs
Aller à :navigation, rechercher

Introduction

Les pare-feu sont un outil important qui peut ê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 s'interface avec le cadre de filtrage de paquets netfilter du noyau. Pour les utilisateurs et les administrateurs qui ne comprennent pas l'architecture de ces systèmes, la création de politiques de pare-feu fiables peut être intimidante, non seulement en raison d'une syntaxe difficile, mais également en raison du nombre de parties interdépendantes présentes dans le cadre.

Dans ce guide, nous plongerons dans l'architecture iptables dans le but de la rendre plus compréhensible pour les utilisateurs qui ont besoin de créer leurs propres politiques de pare-feu. Nous verrons comment iptables interagit avec netfilter et comment les différents composants s'emboîtent pour fournir un système complet de filtrage et de manipulation.

Qu'est-ce qu'IPTables et Netfilter ?

Le logiciel de pare-feu de base le plus couramment utilisé sous Linux s'appelle iptables. Le pare-feu iptables fonctionne en interagissant avec les hooks de filtrage de paquets dans la pile réseau du noyau Linux. Ces hooks du noyau sont connus sous le nom de framework netfilter.

Chaque paquet entrant dans le système réseau (entrant ou sortant) déclenchera ces crochets au fur et à mesure de sa progression dans la pile, permettant aux programmes qui s'enregistrent avec ces crochets d'interagir avec le trafic à des points clés. Les modules du noyau associés à iptables s'enregistrent à ces crochets afin de s'assurer que le trafic est conforme aux conditions définies par les règles du pare-feu.

Crochets Netfilter

Il existe cinq hooks netfilter avec lesquels les programmes peuvent s'enregistrer. Au fur et à mesure que les paquets progressent dans la pile, ils déclenchent les modules du noyau qui se sont enregistrés avec ces crochets. Les hooks déclenchés par un paquet dépendent du fait que le paquet est entrant ou sortant, de la destination du paquet et du fait que le paquet a été abandonné ou rejeté à un point précédent.

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

  • NF_IP_PRE_ROUTING : ce crochet sera déclenché par tout trafic entrant très peu de temps après son entrée dans la pile réseau. Ce crochet est traité avant que toute décision de routage n'ait été prise concernant l'endroit où envoyer le paquet.
  • NF_IP_LOCAL_IN : ce crochet est déclenché après le routage d'un paquet entrant 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 transmis à un autre hôte.
  • NF_IP_LOCAL_OUT : ce crochet est déclenché par tout trafic sortant créé localement dès qu'il atteint 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 a eu lieu et juste avant d'être mis sur le réseau.

Les modules du noyau qui souhaitent s'enregistrer sur ces crochets doivent fournir un numéro de priorité pour aider à déterminer l'ordre dans lequel ils seront appelés lorsque le crochet est déclenché. Cela permet de connecter plusieurs modules (ou plusieurs instances du même module) à chacun des crochets avec un ordre déterministe. Chaque module sera appelé à son tour et renverra une décision au framework netfilter après traitement qui indique ce qu'il convient de faire avec le paquet.

Tables et chaînes IPTables

Le pare-feu iptables utilise des tableaux pour organiser ses règles. Ces tableaux classent les règles selon le type de décisions qu'elles sont utilisées pour prendre. Par exemple, si une règle traite de la traduction d'adresse réseau, elle sera placée dans la table nat. Si la règle est utilisée pour décider s'il faut autoriser le paquet à continuer jusqu'à sa destination, il sera probablement ajouté à la table filter.

Dans chaque tableau iptables, les règles sont ensuite 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 crochets netfilter qui les déclenchent. Les chaînes déterminent essentiellement quand les règles seront évaluées.

Comme vous pouvez le voir, les noms des chaînes intégrées reflètent les noms des crochets netfilter auxquels elles sont associées :

  • PREROUTING : Déclenché par le hook NF_IP_PRE_ROUTING.
  • INPUT : Déclenché par le hook NF_IP_LOCAL_IN.
  • FORWARD : Déclenché par le hook NF_IP_FORWARD.
  • OUTPUT : Déclenché par le hook NF_IP_LOCAL_OUT.
  • POSTROUTING : Déclenché par le hook NF_IP_POST_ROUTING.

Les chaînes permettent à l'administrateur de contrôler où, dans le chemin de livraison d'un paquet, une règle sera évaluée. Étant donné que chaque table a plusieurs chaînes, l'influence d'une table peut être exercée à plusieurs points du traitement. Étant donné que certains types de décisions n'ont de sens qu'à certains points de la pile réseau, chaque table n'aura pas de chaîne enregistrée avec chaque crochet du noyau.

Il n'y a que cinq crochets de noyau netfilter, donc les 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 NF_IP_PRE_ROUTING associé, elles spécifient une priorité qui dicte l'ordre dans lequel la chaîne PREROUTING de chaque table est appelée. Chacune des règles à l'intérieur de la chaîne de priorité la plus élevée PREROUTING 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 instant.

Quels tableaux sont disponibles ?

Revenons un instant en arrière et examinons les différentes tables fournies par iptables. Celles-ci représentent des ensembles de règles distincts, organisés par domaine de préoccupation, pour l'évaluation des paquets.

Le tableau des filtres

La table de filtrage est l'une des tables les plus largement utilisées dans iptables. La table filter est utilisée pour décider s'il faut laisser un paquet continuer vers sa destination prévue ou refuser sa demande. Dans le jargon du pare-feu, cela s'appelle "filtrer" les paquets. Ce tableau fournit l'essentiel des fonctionnalités auxquelles les gens pensent lorsqu'ils parlent de pare-feu.

Le tableau NAT

La table nat est utilisée pour implémenter les règles de traduction d'adresse réseau. Au fur et à mesure que les paquets entrent dans la pile réseau, les règles de ce tableau détermineront si et comment modifier les adresses source ou de destination du paquet afin d'avoir un impact sur la manière dont le paquet et tout trafic de réponse sont acheminés. Ceci est souvent utilisé pour acheminer les paquets vers les réseaux lorsque l'accès direct n'est pas possible.

La table de mutilation

La table mangle est utilisée pour modifier les en-têtes IP du paquet de diverses manières. Par exemple, vous pouvez ajuster la valeur TTL (Time to Live) d'un paquet, soit en allongeant soit en raccourcissant le nombre de sauts de 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 une « marque » de noyau interne sur le paquet pour un traitement ultérieur dans d'autres tables et par d'autres outils de mise en réseau. Cette marque ne touche pas le paquet réel, mais ajoute la marque à la représentation du paquet par le noyau.

La table crue

Le pare-feu iptables est dynamique, 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 au-dessus du cadre netfilter permettent au iptables de visualiser les paquets dans le cadre d'une connexion ou d'une session en cours au lieu d'un flux de paquets discrets et non liés. La logique de suivi de connexion est généralement appliquée très peu de temps après que le paquet a atteint l'interface réseau.

La table raw a une fonction très étroitement définie. Son seul but est de fournir un mécanisme de marquage des paquets afin de désactiver le suivi des connexions.

Le tableau de sécurité

La table security est utilisée pour définir des marques de contexte de sécurité internes SELinux 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 par paquet ou par connexion.

Quelles chaînes sont implémentées dans chaque table ?

Nous avons parlé des tables et des chaînes séparément. Passons en revue les chaînes disponibles dans chaque tableau. Cette discussion implique une autre discussion sur l'ordre d'évaluation des chaînes enregistrées sur le même crochet. Si trois tables ont des chaînes PREROUTING, dans quel ordre sont-elles évaluées ?

Le tableau suivant indique les chaînes disponibles dans chaque tableau iptables lorsqu'il est lu de gauche à droite. Par exemple, nous pouvons dire que la table raw a les chaînes PREROUTING et OUTPUT. Lorsqu'il est lu de haut en bas, il affiche également l'ordre dans lequel chaque chaîne est appelée lorsque le crochet netfilter associé est déclenché.

Quelques éléments doivent être notés. Dans la représentation ci-dessous, la table nat a été divisée entre les opérations DNAT (celles qui modifient l'adresse de destination d'un paquet) et les opérations SNAT (celles qui modifient l'adresse source ) afin d'afficher plus clairement leur ordre. Nous avons également inclus des lignes qui représentent les points où les décisions de routage sont prises et où le suivi des connexions est activé afin de donner une vue plus globale des processus en cours :

Tableaux↓/Chaînes→ PREROUTING SAISIR AVANT PRODUCTION POSTROUTAGE
(décision d'acheminement)
cru
(suivi de connexion activé)
mutiler
nat (ADNT)
(décision d'acheminement)
filtre
Sécurité
nat (SNAT)

Lorsqu'un paquet déclenche un hook netfilter, les chaînes associées seront traitées telles qu'elles sont répertoriées dans le tableau ci-dessus de haut en bas. Les crochets (colonnes) déclenchés par un paquet dépendent du fait qu'il s'agit d'un paquet entrant ou sortant, des décisions de routage prises et du fait que le paquet passe ou non les critères de filtrage.

Certains événements entraînent le saut de 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. Toute décision nat prise pour le premier paquet sera appliquée à tous les paquets suivants dans la connexion sans évaluation supplémentaire. Les réponses aux connexions NAT auront automatiquement les règles NAT inversées appliquées pour un routage correct.

Ordre de traversée de la chaîne

En supposant que le serveur sait comment router un paquet et que les règles du pare-feu autorisent 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 présenté dans le tableau précédent, nous pouvons voir qu'un paquet entrant destiné au système local sera d'abord évalué par rapport aux chaînes PREROUTING du raw, Tableaux mangle et nat. Il traversera ensuite les chaînes INPUT des tables mangle, filter, security et nat avant d'être finalement livré au local prise.

Règles IPTables

Les règles sont placées dans une chaîne spécifique d'une table spécifique. Au fur et à mesure que chaque chaîne est appelée, le paquet en question sera vérifié par rapport à chaque règle de la chaîne dans l'ordre. Chaque règle a un composant correspondant et un composant d'action.

Correspondant à

La partie correspondante d'une règle spécifie les critères qu'un paquet doit respecter 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 les extensions iptables disponibles sur le système. Les règles peuvent être construites pour correspondre par type de protocole, adresse de destination ou source, port de destination ou source, réseau de destination ou source, interface d'entrée ou de sortie, en-têtes ou état de connexion, entre autres critères. Ceux-ci peuvent être combinés pour créer des ensembles de règles assez complexes pour faire la distinction entre différents trafics.

Cibles

Une cible est l'action déclenchée lorsqu'un paquet répond aux critères de correspondance d'une règle. Les cibles sont généralement divisées en deux catégories :

  • Cibles de terminaison : les cibles de terminaison effectuent une action qui met fin à l'évaluation au sein de la chaîne et rend le contrôle au hook netfilter. En fonction de la valeur de retour fournie, le hook peut abandonner le paquet ou permettre au paquet de passer à l'étape suivante du traitement.
  • Cibles sans fin : les cibles sans fin effectuent une action et continuent l'évaluation au sein de la chaîne. Bien que chaque chaîne doive éventuellement renvoyer une décision de terminaison finale, n'importe quel nombre de cibles non terminales peut être exécuté à l'avance.

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 correspondantes peuvent également affecter la disponibilité des cibles.

Sauter aux chaînes définies par l'utilisateur

Il convient de mentionner une classe spéciale de cible non terminale : la cible de saut. Les cibles de saut sont des actions qui entraînent le déplacement de l'évaluation vers une chaîne différente pour un traitement supplémentaire. Nous avons beaucoup parlé des chaînes intégrées qui sont intimement liées aux hooks netfilter qui les appellent. Cependant, iptables permet également aux administrateurs de créer leurs propres chaînes à des fins d'organisation.

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 qu'en leur "sautant" à partir d'une règle (elles ne sont pas elles-mêmes enregistrées avec un crochet netfilter).

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

Cette construction permet une plus grande organisation et fournit le cadre nécessaire pour une arborescence plus robuste.

IPTables et suivi des connexions

Nous avons présenté le système de suivi des connexions implémenté au-dessus du cadre netfilter lorsque nous avons discuté de la table raw et des critères de correspondance d'état de connexion. Le suivi de connexion permet à iptables de prendre des décisions concernant les paquets affichés dans le contexte d'une connexion en cours. Le système de suivi de connexion fournit à iptables la fonctionnalité dont il a besoin pour effectuer des opérations « avec état ».

Le suivi des connexions est appliqué très peu de temps après l'entrée des paquets dans la pile réseau. Les chaînes de table raw et certaines vérifications de cohérence de base sont la seule logique qui est effectuée sur les paquets avant d'associer les paquets à une connexion.

Le système compare chaque paquet à 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 si nécessaire. Les paquets qui ont été marqués avec la cible NOTRACK dans l'une des chaînes raw contourneront les routines de suivi de connexion.

É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 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 prenant en charge la connexion comme TCP et pour les protocoles sans connexion comme UDP.
  • ESTABLISHED : Une connexion passe de NEW à ESTABLISHED 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 d'origine sont commutées.
  • RELATED : les paquets qui ne font pas partie d'une connexion existante, mais qui sont associés à une connexion déjà présente dans le système sont étiquetés RELATED. Cela peut signifier une connexion d'assistance, comme c'est le cas avec les connexions de transmission de données FTP, ou il peut s'agir de réponses ICMP à des tentatives de connexion par d'autres protocoles.
  • INVALID : les paquets peuvent être marqués INVALID s'ils ne sont pas associés à une connexion existante et ne sont pas appropriés pour ouvrir une nouvelle connexion, s'ils ne peuvent pas être identifiés ou s'ils ne sont pas routables entre autres raisons.
  • UNTRACKED : les paquets peuvent être marqués comme UNTRACKED s'ils ont été ciblés dans une chaîne de table raw pour contourner le suivi.
  • SNAT : un état virtuel défini lorsque l'adresse source a été modifiée par des opérations NAT. Ceci est utilisé par le système de suivi de connexion afin qu'il sache qu'il doit modifier les adresses source dans les paquets de réponse.
  • DNAT : un état virtuel défini lorsque l'adresse de destination a été modifiée par des opérations NAT. Ceci est utilisé par le système de suivi de connexion afin qu'il sache qu'il doit changer l'adresse de destination lors du routage des paquets de réponse.

Les états suivis dans le système de suivi des connexions permettent aux administrateurs d'élaborer des règles qui ciblent des points spécifiques dans la durée de vie d'une connexion. Cela fournit la fonctionnalité nécessaire pour des règles plus complètes 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 crochets du noyau netfilter sont suffisamment proches de la pile réseau pour fournir un contrôle puissant sur les paquets lorsqu'ils sont traités 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 noyau. En apprenant comment ces pièces s'emboîtent, vous pouvez mieux les utiliser pour contrôler et sécuriser vos environnements de serveur.

Si vous souhaitez en savoir plus sur la façon 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 :