Iptables

iptables

Informations

Créateur	Rusty Russell (en)
Développé par	Projet Netfilter
Première version	1998
Dernière version	1.8.11 (8 novembre 2024)
Dépôt	git.netfilter.org/iptables, git.netfilter.org/iptables et git://git.netfilter.org/iptables
Écrit en	C
Système d'exploitation	GNU/Linux
Environnement	Linux
Type	Filtrage de paquets
Licence	GNU GPL
Site web	www.netfilter.org

iptables est un logiciel libre de l'espace utilisateur Linux grâce auquel l'administrateur système peut configurer les chaînes et règles dans le pare-feu en espace noyau (et qui est composé par des modules Netfilter).

Différents programmes sont utilisés selon le protocole employé : iptables est utilisé pour le protocole IPv4, Ip6tables pour IPv6, Arptables pour ARP (Address Resolution Protocol) ou encore Ebtables, spécifique aux trames Ethernet.

Ce type de modifications doit être réservé à un administrateur du système. Par conséquent, son utilisation nécessite l'utilisation du compte root. L'utilisation du programme est refusée aux autres utilisateurs.

Sur la plupart des distributions Linux, iptables est lancé par la commande /usr/sbin/iptables et documenté par sa page de manuel iptables et ip6tables, laquelle peut être visualisée via la commande « man iptables ».

iptables est également fréquemment utilisé pour faire référence aux composants de bas niveau (niveau kernel). x_tables est le nom du module noyau, plus générique, qui contient le code partagé pour les quatre protocoles. C'est aussi le module qui fournit l'API des extensions. Par conséquent, Xtables désigne usuellement le pare-feu complet (IPv4, IPv6, arp, eb).

Histoire

Netfilter et iptables ont été initialement conçus ensemble, leurs histoires sont donc confondues dans les premiers temps.

Avant iptables, les principaux logiciels de création de pare-feu sur Linux étaient Ipchains (noyau linux 2.2) et Ipfwadm (noyau Linux 2.0), basé sur Ipfw, un programme initialement conçu sous BSD.

iptables conserve les principes de base introduits sous Linux par Ipfwadm : des listes de règles qui spécifient ce qu'il faut tester dans chaque paquet et ce qu'il faut faire d'un tel paquet.

Ipchains a ensuite introduit le concept de chaîne de règles et enfin iptables a étendu ce concept aux tableaux : un tableau est consulté au moment de décider s'il faut utiliser NAT ou pas et un autre est consulté au moment de décider comment filtrer un paquet.

En outre, les trois instants auxquels le filtrage est effectué pendant le transfert d'un paquet ont été modifiés de manière qu'un paquet passe par exactement un point de filtrage.

Cette séparation permet à iptables, à son tour, d'utiliser les informations que la couche de suivi de connexion a définies pour chaque paquet (cette information était auparavant liée au NAT). Cette fonctionnalité rend iptables supérieur à Ipchains, puisque le premier a la capacité de suivre l'état d'une connexion et de réorienter, de modifier ou d'arrêter les paquets de données en se basant sur l'état de la connexion, et plus seulement sur la source, la destination ou le contenu des données du paquet. Un pare-feu utilisant iptables de cette façon est considéré comme un pare-feu stateful (pare-feu à états), au contraire d'Ipchains, qui ne peut créer qu'un pare-feu stateless (sauf dans de rares cas). Pour simplifier, Ipchains n'utilise pas le contexte lié à la transmission d'un paquet, tandis qu'iptables le fait. Par conséquent, iptables est à même de faire de meilleurs choix pour la transmission de paquets ou l'établissement de connexions.

La possibilité de filtrer par processus à l'aide des options --pid-owner --cmd-owner a été retirée du module ipt_owner à l'occasion de la sortie du noyau 2.6.14.

Fonctionnement

Xtables permet à l'administrateur système de créer des tableaux, lesquels contiennent des « chaînes », elles-mêmes composées d'un ensemble de règles de traitement des paquets. Chaque tableau est associé à un type de traitement des paquets (cf. Netfilter). Les paquets suivent séquentiellement chaque règle des chaînes. Une règle dans une chaîne peut provoquer un saut à une autre chaîne (goto ou jump), et ce processus peut être renouvelé autant qu'il le faut, quel que soit le niveau d'imbrication atteint.

Chaque paquet réseau, entrant ou sortant, traverse donc au moins une chaîne.

L'origine du paquet détermine la première chaîne qu'il traverse. Il existe cinq chaînes prédéfinies (associées aux cinq hooks de Netfilter), cependant leur utilisation n'est pas obligatoire dans chaque tableau. Les chaînes prédéfinies ont une politique (par exemple DROP), qui est appliquée au paquet s'il arrive à la fin de la chaîne. L'administrateur système peut créer autant d'autres chaînes qu'il le souhaite. Ces chaînes n'ont pas de politique : si un paquet arrive à la fin de la chaîne, il est renvoyé à la chaîne qui a appelé. Une chaîne peut même être vide (n'avoir aucune règle).

Les cinq types de chaînes prédéfinies sont les suivants :

• "PREROUTING" : Les paquets vont entrer dans cette chaîne avant qu'une décision de routage ne soit prise.
• "INPUT" : Le paquet va être livré sur place (N.B. : la livraison sur place ne dépend pas d'un processus ayant un socket ouvert ; la livraison est contrôlée par le tableau « local » de routage : ip route show table local).
• "FORWARD" : Tous les paquets qui ont été acheminés et ne sont pas livrés sur place parcourent la chaîne.
• "OUTPUT" : Les paquets envoyés à partir de la machine elle-même se rendront à cette chaîne.
• "POSTROUTING" : La décision de routage a été prise. Les paquets entrent dans cette chaîne, juste avant qu'ils ne soient transmis vers le matériel.

Une chaîne (qui est une liste de règles) n'existe pas de façon indépendante : toute chaîne appartient nécessairement à une table. Iptables comprend quatre tables nommées : mangle, filter, nat, raw. Cet aspect est souvent mal expliqué (ou peu mis en exergue) dans les tutoriels qui de ce fait laissent penser qu'il existe des chaînes en dehors des tables. Cette confusion vient du fait que la table filter est la table par défaut. Ainsi elle est souvent implicite dans les commandes et le discours. Par exemple lorsqu'un tutoriel parle de la chaîne INPUT sans autre précision il s'agit donc de la chaîne INPUT de la table filter. Ci-dessous nous indiquons des commandes pour lister les chaînes définies dans les différentes tables.

Chaque règle d'une chaîne contient la spécification (en anglais : matches) des paquets qui lui correspondent. Elle peut également contenir une action (en anglais : target) (utilisée pour les extensions) ou un jugement (une de plusieurs décisions intégrées). Quand un paquet traverse une chaîne, chaque règle, à son tour, est examinée. Si une règle ne correspond pas au paquet, le paquet est passé à la règle suivante. Si une règle correspond au paquet, elle prend les mesures indiquées par l'action/le jugement, ce qui peut conduire à autoriser le paquet à continuer dans la chaîne ou, à l'inverse, à l'exclure. Les spécifications constituent la grande partie des règles, car elles contiennent les conditions selon lesquelles les paquets sont testés. Ces spécifications peuvent fournir pour toute couche du modèle OSI, comme par exemple les paramètres --mac-source et -p tcp --dport, et il y a aussi des spécifications indépendantes du protocole, par exemple -m time.

Le paquet continue à parcourir la chaîne jusqu'à ce que :

• soit une règle corresponde au paquet et décide du sort ultime du paquet (par exemple en appelant l'un des jugements ACCEPT ou DROP) ;
• soit une règle appelle le jugement RETURN et, dans ce cas, le traitement revient à la chaîne d'appel ;
• soit la fin de la chaîne est atteinte. Actions aussi rend un verdict comme ACCEPT (les modules NAT feront cela) ou DROP (en général le module REJECT), mais aussi peut impliquer CONTINUE (nom interne) pour continuer avec la règle suivante, comme si aucun action/jugement n'avait été précisé.

Front-ends et scripts

Il existe de nombreux logiciels tiers pour iptables, qui cherchent à faciliter la mise en place de règles. Les front-ends à base de texte ou en mode graphique permettent aux utilisateurs de générer les règles simples d'un simple clic. Firestarter est une interface graphique disponible pour les distributions Linux qui utilisent l'environnement Gnome. Les scripts font habituellement référence aux scripts de Shell de Unix (mais d'autres langages de script sont également possibles). Ils appellent iptables ou (le plus rapide) « iptables-restore » avec un ensemble de règles prédéfinies, ou de règles à partir d'un modèle développé avec l'aide d'un simple fichier de configuration. Les distributions de Linux utilisent le dernier système de l'aide de modèles. Une telle approche fondée sur le modèle est presque une forme limitée d'un générateur des règles, et il existe aussi des générateurs en mode autonome, par exemple, en fichiers PHP.

Les front-ends, les générateurs et les scripts sont souvent limités par leur système de modèle, et où ce modèle permet la substitution de règles définies par l'utilisateur. En outre, les règles générées ne sont généralement pas optimisées pour les effets que l'utilisateur souhaite sur le pare-feu, car cela augmenterait probablement les coûts d'entretien pour le développeur. Les utilisateurs qui ont raisonnablement compris iptables et qui veulent en outre que leurs jeux de règles soient optimisés sont invités à construire leurs propres règles.

La commande iptables -L -v -n permet de voir quelles règles sont définies pour la table filter qui est la table par défaut lorsque non spécifiée (ainsi la commande iptables -t filter -L -v -n retourne le même résultat que iptables -L -v -n). Pour visualiser les règles des chaînes de la table nat on utilisera la commande: iptables -t nat -L -v -n

Notes et références

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « iptables » (voir la liste des auteurs).

Articles connexes

Autres outils

• NuFW, un pare-feu, extension de Netfilter
• nftables, projet Netfilter voulant remplacer iptables
• FWSnort traduit des règles Snort en iptables.
• psad Analyse automatique de logs pour détecter des attaques (scan de ports et recherche de backdoors).
• Programmation de modules Netfilter/iptables en "Rope"