Iptables

iptables

iptables
Développeur	Netfilter Core Team
Dernière version	1.4.5 (le 14 septembre 2009) [+/-]
Environnement	Linux
Type	Filtrage de paquets
Licence	GNU General Public License
Site Web	http://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 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^[1]et ip6tables^[2], 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

Article détaillé : Histoire de Netfilter.

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 BSDs.

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 à ce 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, 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.

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.

La source 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 chaînes prédéfinies sont les suivantes :

• "PREROUTING" : Les paquets vont entrer dans cette chaîne avant qu'une décision de routage 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 soient transmis vers le matériel.

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 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 specs 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 possibles aussi). 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 comprise Iptables et qui veulent en outre que leur jeux de règles soient optimisés sont invités à construire leurs propres règles.

La commande iptables -L permet de voir quelles règles sont définies.

Notes et références

1. ↑ (en) man iptables
2. ↑ (en) man ip6tables

Liens externes

• (en) Page web du projet Netfilter/Iptables
• (en) Iptables sur freshmeat

Autres outils

• NuFW, un pare-feu, extension de Netfilter
• 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"

Diagrammes

Pour mieux comprendre comment un paquet IP est traité par le noyau:

• http://jengelh.medozas.de/images/nf-packet-flow.png

Tutoriels

• Tutoriel IP Tables
• Documentation concernant le firewall (IP Tables) et le routage Linux avancé

Ce document provient de « Iptables ».