Une plongée approfondie dans l’architecture Iptables et Netfilter

firewalls 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 la structure 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 stratégies de pare-feu fiables peut être décourageante, non seulement en raison d’une syntaxe difficile, mais également en raison du nombre de parties interdépendantes présentes dans la structure.

Dans ce guide, nous allons nous plonger dans l’architecture + iptables + dans le but de la rendre plus compréhensible pour les utilisateurs ayant besoin de créer leurs propres stratégies de pare-feu. Nous discuterons de la manière dont + iptables + interagit avec + netfilter + et de la manière dont les divers composants s’intègrent pour fournir un système complet de filtrage et de filtrage.

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 crochets de filtrage de paquets de la pile réseau du noyau Linux. Ces hooks de noyau sont connus sous le nom de framework + netfilter +.

Chaque paquet qui entre dans le système de réseau (entrant ou sortant) déclenchera ces points d’ancrage à mesure qu’il progressera dans la pile, permettant ainsi aux programmes qui s’enregistrent avec ces points d’interagir avec le trafic aux points clés. Les modules du noyau associés à + ​​iptables + s’enregistrent à ces points d’ancrage afin de garantir la conformité du trafic aux conditions définies par les règles du pare-feu.

Il existe cinq points d’ancrage + netfilter + auxquels les programmes peuvent s’inscrire. Au fur et à mesure que les paquets progressent dans la pile, ils déclencheront les modules du noyau qui se sont inscrits avec ces points d’ancrage. Les raccords qu’un paquet va déclencher 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 moment précédent.

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

Les modules du noyau souhaitant s’inscrire à ces points d’ancrage doivent fournir un numéro de priorité pour aider à déterminer l’ordre dans lequel ils seront appelés lors du déclenchement du point d’ancrage. Cela permet de connecter plusieurs modules (ou plusieurs instances du même module) à chacun des points d’ancrage 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 qui doit être fait avec le paquet.

Le pare-feu + iptables + utilise des tables pour organiser ses règles. Ces tableaux classent les règles en fonction du type de décisions qu’elles prennent. 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 si le paquet doit continuer jusqu’à sa destination, il sera probablement ajouté à la table + filter +.

Dans chaque table + iptables +, les règles sont ensuite organisées dans des «chaînes» séparées. 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 hooks + netfilter + qui les déclenchent. Les chaînes déterminent fondamentalement les règles when qui seront évaluées.

Comme vous pouvez le constater, les noms des chaînes intégrées reflètent les noms des hooks + netfilter + auxquels ils sont associés:

Les chaînes permettent à l’administrateur de contrôler où une règle sera évaluée dans le chemin de livraison d’un paquet. Chaque table ayant plusieurs chaînes, l’influence d’une table peut être exercée à différents moments du traitement. Certains types de décisions n’ayant de sens qu’à certains endroits de la pile réseau, aucune chaîne ne sera enregistrée dans une table avec chaque hook du noyau.

Il n’y a que cinq hooks + netfilter + dans le noyau, donc les chaînes de plusieurs tables sont enregistrées sur chacun des hooks. 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 détermine l’ordre dans lequel la chaîne " PREROUTING " de chaque table est appelée. Chacune des règles de la chaîne ` PREROUTING ` de priorité la plus élevée est évaluée séquentiellement avant de passer à la chaîne ` PREROUTING +` suivante. Nous allons examiner l’ordre spécifique de chaque chaîne dans un moment.

Revenons un instant en arrière et jetons un coup d’œil aux différentes tables fournies par + iptables +. Celles-ci représentent des ensembles distincts de règles, organisées par domaine de préoccupation, pour évaluer les paquets.

Nous avons parlé des tables et des chaînes séparément. Voyons quelles chaînes sont disponibles dans chaque tableau. Cette discussion implique une autre discussion sur l’ordre d’évaluation des chaînes enregistrées dans 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 + lors de la lecture de gauche à droite. Par exemple, nous pouvons dire que la table + raw + a à la fois les chaînes + PREROUTING + et + + OUTPUT +. Lorsqu’elle est lue de haut en bas, elle affiche également l’ordre dans lequel chaque chaîne est appelée lorsque le hook + netfilter + associé est déclenché.

Quelques choses devraient être notées. 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 leur commander plus clairement. Nous avons également inclus des lignes qui représentent des points où les décisions de routage sont prises et où le suivi de connexion est activé afin de donner une vue plus globale des processus en cours:

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) qu’un paquet va déclencher dépendent du type de paquet entrant ou sortant, des décisions de routage prises et du critère de filtrage appliqué.

Certains événements feront en sorte que la chaîne d’une table soit 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 suivants de la connexion sans évaluation supplémentaire. Dans les réponses aux connexions NAT, les règles NAT inversées seront automatiquement appliquées pour acheminer correctement.

Les règles sont placées dans une chaîne spécifique d’une table spécifique. Chaque paquet étant appelé, le paquet en question sera comparé dans l’ordre à chaque règle de la chaîne. Chaque règle a un composant correspondant et un composant d’action.

Il convient de mentionner une classe spéciale de cibles non terminantes: la cible de saut. Les cibles de saut sont des actions qui entraînent le passage de l’évaluation à 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 enregistrées avec un hook + 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 sera renvoyée à la chaîne d’appel 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 accéder à d’autres chaînes définies par l’utilisateur.

Cette construction permet une plus grande organisation et fournit le cadre nécessaire à une création de branche plus robuste.

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

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 table + raw + et certaines vérifications de base sont la seule logique exécutée sur les paquets avant de les associer à 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 si nécessaire. Les paquets marqués avec la cible + NOTRACK + dans l’une des chaînes + raw + contourneront les routines de suivi des connexions.

La structure de filtrage de paquets + netfilter + et le pare-feu + iptables + constituent la base de la plupart des solutions de pare-feu sur les serveurs Linux. Les hooks du noyau + netfilter + sont suffisamment proches de la pile réseau pour permettre un contrôle puissant des paquets traités par le système. Le pare-feu + iptables + exploite ces fonctionnalités pour fournir une méthode flexible et extensible de communication des exigences de règles au noyau. En apprenant comment ces éléments s’assemblent, vous pouvez mieux les utiliser pour contrôler et sécuriser vos environnements de serveur.

Si vous souhaitez en savoir plus sur la manière de choisir des règles efficaces + iptables +, visitez https://www.digitalocean.com/community/tutorials/how-to-choose-an-effective-firewall-policy-to- secure-your-servers [ce guide].

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