Architecture

NetFilter avec IPtables n'a pas du tout la même architecture, le fonctionnement est différent, même si la syntaxe d'IPtables peut paraître proche de celle d'IPchains.

En particulier, les chaînes INPUT et OUTPUT ne contrôlent pas tout ce qui entre et sort de la passerelle, routage compris, mais uniquement ce qui entre en direction de la passerelle elle même et sort de la passerelle elle même. Entendez par là que tout le trafic entre le réseau privé masqué par le NAT et l'Internet ne sera aucunement influencé par ces deux chaînes. Nous verrons en détail plus loin pourquoi et comment.

Finalement, le meilleur conseil à donner aux utilisateurs d'IPchains, c'est d'oublier purement et simplement tout ce qu'ils savent sur le sujet…

Avec les versions 2.2.x, nous avions l'excellent outil gfcc qui permettait de faire à peu près tout ce qu'il était possible de faire avec IPchains. Malheureusement, avec IPtables, je n'ai pas encore trouvé d'outil équivalent à l'heure où j'écris ces lignes. Essayez de voir avec knetfilter, mais ce n'est pas du tout la même chose.

Comme d'habitude sur ce site, l'exposé s'appuie sur une passerelle Linux mettant en relation un réseau privé avec le Net, au moyen d'une liaison haut débit et permanente de type câble ou ADSL. Si vous ne savez pas faire, voyez le chapitre « Partage de connexion ».

La machine Linux dispose de deux interfaces Ethernet. Ici:

• Eth0 sur le réseau local (privé)
• Eth1 sur l'Internet via le modem câble du fournisseur d'accès. Cette interface, le plus souvent, sert de support à PPPoE.

Il faut bien comprendre qu'à priori, il peut entrer et sortir des données de chaque interface.

• Il peut entrer et sortir des données par Eth0, parce qu'un client du réseau local établit une connexion avec un service installé sur la passerelle, Samba par exemple, pour le partage de fichiers avec Windows.
• Il peut entrer et sortir des données par Eth1 (ou la connexion ppp qui y est associée) parce qu'un client situé sur le Net établit une connexion avec un service installé sur la passerelle, une session ssh ou telnet par exemple (ssh, c'est mieux…). Il peut se faire aussi que cette connexion s'établisse à votre insu, parce qu'un pirate est en train de prendre possession de votre machine (mais ceci est une autre histoire, développée au chapitre de la sécurité).
• Il peut se faire également qu'une connexion s'établisse entre un poste du réseau privé et un serveur situé sur le Net. Dans ce cas, les paquets entreront par une interface et sortiront par l'autre.
• En toute rigueur, il est également possible qu'une connexion s'établisse entre un client situé sur le Net et un serveur situé sur votre réseau privé (si si, c'est possible aussi, bien que dans le cadre d'un réseau domestique, ce ne soit pas nécessaire, ni même souhaitable). Là aussi, les paquets qui entrent par une interface sortiront par l'autre.

Quel que soit le cas de figure vu plus haut, dans ce qui suit, nous ne ferons pas de ségrégation sur l'interface par laquelle les paquets entrent ni l'interface par laquelle les paquets sortent. Cette ségrégation interviendra éventuellement dans les règles que nous écrirons avec IPtables.

En tout état de cause, dans l'explication qui suit, quelles que soient l'origine et la destination des paquets, ils vont entrer dans la pile de protocoles IP par le même point et en sortir par le même autre point.  Netfilter se présente comme une série de 5 “hooks” (points d'accrochage), sur lesquels des modules de traitement des paquets vont se greffer. Ces points sont:

• NF_IP_PRE_ROUTING ;
• NF_IP_LOCAL_IN ;
• NF_IP_FORWARD ;
• NF_IP_POSTROUTING ;
• NF_IP_LOCAL_OUT.

La branche gauche représente le trajet des paquets qui entrent et qui sortent vers et depuis un processus local (SMB, FTP, HTTP etc.) La branche de droite représente le trajet des paquets qui  traversent notre passerelle dans sa fonction de routeur.

Attention toutefois, ces diagrammes sont faux, dans la mesure où ils sont largement simplifiés. Leur but est uniquement de montrer où Netfilter vient interagir avec la pile IP, en aucun cas il ne représente l'architecture complète de la pile IP.

A travers ces cinq points d'insertion, Netfilter va être capable :

• D'effectuer des filtrages de paquets, principalement pour assurer des fonctions de Firewall. On pourra par exemple interdire à tous les paquets venant de l'Internet et s'adressant au port 80 (HTTP) de passer. Notre serveur APACHE est un serveur Intranet et ne doit pas être accessible depuis l'extérieur.
• D'effectuer des opérations de NAT (Network Address Translation) Ces fonctions sont particulièrement utiles lorsque l'on veut faire communiquer tout ou partie d'un réseau privé, monté avec des adresses IP privées (192.168.x.x par exemple) avec l'Internet.
• D'effectuer des opérations de marquage des paquets, pour leur appliquer un traitement spécial. Ces fonctionnalités sont particulièrement intéressantes sur une passerelle de réseau d'entreprise,  un peu moins pour notre cas de réseau domestique.

Netfilter dispose d'une commande à tout faire : IPtables. Cette commande va permettre, entre autres, d'écrire des chaînes de règles dans des tables. Il y a dans Netfilter trois tables qui correspondent aux trois principales fonctions vues plus haut:

Il existe trois tables qui vont servir à contenir des règles de filtrage:

Cette table va contenir toutes les règles qui permettront de filtrer les paquets. Cette table contient trois chaînes :

• la chaîne INPUT.
  Cette chaîne décidera du sort des paquets entrant localement sur l'hôte ;
• la chaîne OUTPUT.
  Ici, ce ne sont que les paquets émis par l'hôte local qui seront filtrés ;
• la chaîne FORWARD.
  Enfin, les paquets qui traversent l'hôte, suivant les routes implantées, seront filtrés ici.

Cette table permet d'effectuer toutes les translations d'adresses nécessaires.

• La chaîne PREROUTING.
  Permet de faire de la translation d'adresse de destination. Cette méthode est intéressante si l'on veut faire croire au monde extérieur, par exemple, qu'il y a un serveur WEB sur le port 80 de la passerelle, alors que celui-ci est hébergé par un hôte du réseau privé, sur le port 8080.
• La chaîne POSTROUTING.
  Elle permet de faire de la translation d'adresse de la source, comme du masquage d'adresse, la méthode classique pour connecter un réseau privé comme client de l'Internet, avec une seule adresse IP publique.
• La chaîne OUTPUT.
  Celle-ci va permettre de modifier la destination de paquets générés localement (par la passerelle elle-même).

Cette table permet le marquage des paquets entrants (PREROUTING) et générés localement (OUTPUT). Le marquage de paquets va permettre un traitement spécifique des paquets marqués dans les tables de routage avec IPROUTE 2. Ceci nous mènerait trop loin. Si vous êtes intéressé par cette question, voyez à ce sujet le document: Linux 2.4 Advanced Routing HOWTO.

Depuis la version 2.4.18 du noyau, d'autres tables ont été rajoutées sur tous les hooks. Nous avons ainsi à notre disposition les tables supplémentaires INPUT, POSTROUTING et FORWARD

Les chaînes sont des ensembles de règles que nous allons écrire dans chaque table. Ces chaînes vont permettre d'identifier des paquets qui correspondent à certains critères.

Les cibles enfin sont des sortes d'aiguillage qui dirigeront les paquets satisfaisant aux critères . Les cibles préconstruites sont :

• ACCEPT
  Les paquets qui satisfont aux critères sont acceptés, ils continuent leur chemin dans la pile,
• DROP
  Les paquets qui satisfont aux critères sont rejetés, on les oublie, on n'envoie même pas de message ICMP . Un trou noir, quoi.
• LOG
  C'est une cible particulière qui permet de tracer au moyen de syslog les paquets qui satisfont aux critères.

Suivant les contextes, d'autres cibles deviennent accessibles, comme REJECT (similaire à DROP, mais avec envoi d'un message d'erreur ICMP à la source du paquet rejeté), RETURN, REDIRECT, SNAT, DNAT, MASQUERADE…

En français, nous pourrons faire des choses de ce genre :

• Par défaut, tous les paquets qui entrent sont rejetés (DROP)
• Les paquets qui entrent par le port 80 sur l'interface eth0 sont acceptés
• Les paquets qui sortent par le port 80 sur l'interface eth0 sont acceptés
• etc.

Nous verrons cela plus en détail dans les divers exemples.

IPtables est en quelques sortes l'interface utilisateur de Netfilter. Dans sa partie visible, tout ceci ressemble au bonnes vieilles IPchains (noyaux 2.2), mais ici, ce n'est qu'une interface de commande de Netfilter. La syntaxe est plus complète et plus rigoureuse.