iptables
Un article de Wikipédia, l'encyclopédie libre.
 |
L’orthographe ou la grammaire de cet article est à vérifier.
Vous pouvez corriger ou créer la discussion.
|
| Iptables | |
 |
|
iptables est un programme de l'espace utilisateur linux grâce auquel l'administrateur système peut configurer les tableaux du pare-feu du kernel Linux (celui-ci est composé de modules Netfilter) ainsi que les chaînes et règles que le pare-feu emploie. 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 [1][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 kernel, 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).
Sommaire |
[modifier] 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 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éfini pour chaque paquet (Cette information était auparavant liée au NAT). Cette fonctionnalité rend iptables supérieur à ipchains, ayant 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” versus 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.
[modifier] Explication succinte du fonctionnement
Xtables permet à l'administrateur système de créer des “tableaux”, lesquels contiennent des “chaînes”, elles mêmes ensembles de “règles” de traitement des paquets. Chaque tableau est associé à un type de traitement des paquets. 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 (avoir zéro 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.: Livraison sur place ne dépend pas d'un processus ayant un socket ouvert; 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, veut parcourent la chaîne.
- "OUTPUT": les paquets sont envoyés à partir de la machine elle-même se rendra à cette chaîne.
- "POSTROUTING": La décision de routage a été prise. Paquets entrent cette chaîne, juste avant de les transmettre vers le matériel.
Chaque règle d'une chaîne contient la spécification (anglais: matches) des paquets qui lui correspond. Il peut également contenir un action (en anglais: target) (utilisé pour les extensions) ou jugement (une de plusieurs décisions intégrées). Comme 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 le paquet, elle prend les mesures indiquées par l'action/le jugement, que peut résulter dans autoriser le paquet à continuer dans la chaîne, ou pas. Les spéficiations constituent la grande partie les règles, car ils contiennent les conditions que les paquets sont testés contre/avec. Ceux-ci (ces specs) peuvent fournir pour toute couche du modèle OSI, comme par exemple les --mac-source et -p tcp --dport paramètres, et il y a aussi des specs indépendants du protocole, par ex. -m time.
Le paquet continue à parcourir la chaîne jusqu'à (1) une règle correspond au paquet et décide le sort ultimate du paquet (par exemple en appelant l'un des jugements ACCEPT ou DROP) ou (2) une règle appelle le jugement RETURN, dans ce cas, le traitement revient à la chaîne d'appel, ou (3) la fin de la chaîne est atteint. Actions aussi rendre un verdict comme ACCEPT (NAT modules ce faire) ou DROP (par exemple le module “REJECT”), mais aussi peut impliquer CONTINUE (nom interne) pour continuer avec la règle suivante, comme si aucune action/jugement a été précisé du tout.
[modifier] Exemple
Cet exemple montre un pare-feu déjà configuré de travail. La commande “iptables -L” est exécuté par l'utilisateur root pour afficher une version abrégée de la configuration de pare-feu. (L'état complet peut être obtenu avec iptables-save -c, et doit être utilisé quand on lance des déclarations de problèmes.)
# iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- localhost.localdomain localhost.localdomain ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED REJECT all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
The RELATED/ESTABLISHED rule uses statefullness so that most client programs (web browser, ssh...) “just work”.
$ w3m http://en.wikipedia.org/wiki/Main_Page
(The main Wikipedia web page opens)
Computer does not respond to ping and no services are offered. Connections are rejected (REJECT) or timeout (with DROP) when ports are being scanned.
$ ping -c 1 10.0.0.1 PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data. --- 62.78.243.6 ping statistics --- 1 packets transmitted, 0 received, 100% packet loss, time 0ms
Trying to connect to HTTP port (TCP 80)
$ telnet 10.0.0.1 80 Trying 10.0.0.1... telnet: connect to address 10.0.0.1: Connection refused
[modifier] Redirection example
This simple example of its use illustrates how to redirect all traffic on the default HTTP port, port 80, to port 8080, allowing the HTTP daemon to run as a non-privileged user, unable to listen on port numbers below 1024.
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
Note: if you launch this command on your computer it will only work for external IP addresses connecting to your machine. Connections from localhost do not traverse the PREROUTING chain in the "nat" table. If you also want this feature to work, use the following rule:
iptables -t nat -A OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080
which reroutes packets on the loopback (lo) interface from port 80 to port 8080.
[modifier] Front-ends and scripts
Il existe de nombreux logiciels tiers pour iptables, qui cherchent à faciliter la mise en place de règles. Front-ends à base de texte ou mode graphique permettant aux utilisateurs de générer les règles simples d'un simple clic. Scripts habituellement référence aux scripts de shell d'unix (mais d'autres langages de script est possible aussi). Celles notamment appellées 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. 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 oui ce modèle permis 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 pare-feu à effet au détrimnent de l'utilisateur qui le souhaite, car cela augmenterait probablement les coûts d'entretien pour le développeur. Les utilisateurs qui ont raisonnablement su comprendre iptables et qui veulent en outre que leur jeux de règles soient optimisés sont invités à construire leurs propres règles.
[modifier] External links
- The netfilter/iptables project Web page
- iptables sur freshmeat
- The netfilter/iptables documentation page (outdated)
[modifier] Other tools
- NuFW, an authenticating firewall extension to Netfilter
- FWSnort, Translates a Snort IDS ruleset into an IPTables ruleset.
- psad, Automated iptables log analysis to detect suspicious activity (port scans and probes for backdoors), and passively fingerprint remote TCP stacks.
- Programming Netfilter/iptables modules in "Rope"
[modifier] Diagrams
To better understand how a packet traverses the kernel Xtables tables/chains you may find the following diagrams useful:
