9.4. Firewalls et partages de connexion à Internet

9.4.1. Mécanismes de filtrage du noyau

Linux est capable de filtrer les paquets circulant sur le réseau et d'effectuer des translations d'adresses depuis la version 2.0. Cependant, les techniques utilisées ont été profondément remaniées à chaque version. À partir de la version 2.4.0, une architecture extensible a été mise en place et semble répondre à tous les besoins de manière simple : Netfilter.

Netfilter est simplement une série de points d'entrées dans les couches réseau du noyau au niveau desquels des modules peuvent s'enregistrer afin d'effectuer des contrôles ou des traitements particuliers sur les paquets. Il existe une entrée en chaque point clé du trajet suivi par les paquets dans les couches réseau du noyau, ce qui permet d'intervenir de manière souple et à n'importe quel niveau. Un certain nombre de modules permettant d'effectuer les traitements les plus courants sont fournis directement dans le noyau, mais l'architecture Netfilter est suffisamment souple pour permettre le développement et l'ajout des modules complémentaires qui pourraient être développés par la suite.

Les fonctionnalités fournies par ces modules sont regroupées par domaines fonctionnels. Ainsi, les modules permettant de réaliser des Firewalls se chargent spécifiquement de donner les moyens de filtrer les paquets selon des critères bien définis, et les modules permettant d'effectuer des translations d'adresses ne prennent en charge que la modification des adresses source et destination des paquets à la volée. Afin de bien les identifier, ces fonctionnalités sont regroupées dans ce que l'on appelle des tables. Une table n'est en fait rien d'autre qu'un ensemble cohérent de règles permettant de manipuler les paquets circulant dans les couches réseau du noyau. Les tables les plus couramment utilisées sont les tables « filter » et « nat », qui permettent respectivement de réaliser des Firewall et d'effectuer des translations d'adresses.

Chaque table utilise ses propres points d'entrée de Netfilter. Pour chacun de ces points d'entrée, des listes de règles de gestion des paquets peuvent être définies. Ces listes sont communément appelées des chaînes. Il y a donc toujours une chaîne de règles prédéfinie pour chaque point d'entrée. L'utilisateur peut bien entendu définir de nouvelles chaînes et les utiliser dans les chaînes prédéfinies.

Les règles permettent de spécifier les paquets qui les vérifient, selon des critères précis, comme par exemple leur adresse source ou le type de protocole qu'ils transportent. Les règles indiquent également les traitements qui seront appliqués à ces paquets. Par exemple, il est possible de détruire purement et simplement tous les paquets provenant d'une machine considérée comme non sure si l'on veut faire un Firewall. On pourra aussi envoyer ces paquets dans une autre chaîne, qui peuvent indiquer d'autres règles et d'autres traitements.

Les critères de sélection de paquets des règles de filtrage se basent sur les informations de l'en-tête de ces paquets. Rappelez-vous que chaque paquet de données émis sur le réseau transporte avec lui des informations nécessaires au fonctionnement dudit réseau, entre autres les adresses source et destination du paquet. Ce sont sur ces informations que la sélection des paquets est effectuée dans Netfilter. Dans le cas d'un protocole encapsulé dans un autre protocole, comme par exemple un paquet TCP dans un paquet IP, les informations du protocole encapsulé peuvent également être utilisées, si l'on a chargé des modules complémentaires dans NetFilter. Par exemple, le numéro de port TCP peut faire partie des critères de sélection d'une règle.

Les traitements que l'on peut appliquer à un paquet sont également fournis par des modules de Netfilter. Les traitements les plus simples sont bien entendus fournis en standard avec le noyau. En général, on peut chercher à réaliser les opérations suivantes sur un paquet :

• l'enregistrer, pour analyse ultérieure ;

• le rediriger vers un port local, pour traitement par un programme dédié (par exemple, par un serveur proxy) ;

• l'accepter, l'abandonner ou le rejeter directement (le rejet se distingue de l'abandon par l'émission d'une notification « hôte inaccessible » à la machine ayant émis le paquet) ;

• le modifier et, en particulier, effectuer une translation d'adresse ou le marquer pour le reconnaître dans un traitement ultérieur ;

• l'envoyer dans une autre chaîne pour effectuer des vérifications complémentaires ;

• le faire sortir immédiatement de la chaîne courante.

Lorsqu'un paquet arrive à la fin d'une chaîne (soit parce qu'il n'a pas été rejeté ou détruit par une règle de Firewalling, soit parce qu'il ne correspond aux critères d'aucune règle, ou soit parce qu'il est arrivé à ce stade après avoir subi des modifications), le noyau revient dans la chaîne appelante et poursuit le traitement du paquet. Si la chaîne au bout de laquelle le paquet arrive est une chaîne prédéfinie, il n'y a plus de chaîne appelante, et le sort du paquet est déterminé par ce qu'on appelle la politique de la chaîne prédéfinie. La politique (« policy » en anglais) des chaînes prédéfinies indique donc ce que l'on doit faire avec les paquets qui arrivent en fin de chaîne. En général, on utilise une politique relativement stricte lorsqu'on réalise un Firewall, qui rejette par défaut tous les paquets qui n'ont pas été acceptés explicitement par une règle de la chaîne.

9.4.2. Translations d'adresses et masquerading

Nous avons vu que grâce aux mécanismes de filtrage du noyau, il est possible de modifier les paquets à la volée. Il peut être intéressant de modifier un paquet pour diverses raisons, les trois plus intéressantes étant sans doute de le marquer à l'aide d'un champ spécial dans son en-tête afin de le reconnaître ultérieurement, de modifier sa priorité pour permettre un traitement privilégié ou au contraire en arrière plan de ce type de paquet (libérant ainsi les ressources réseau pour d'autres types de connexion), et de modifier ses adresses source et destination, pour effectuer une translation d'adresse. Nous allons nous intéresser plus particulièrement aux différentes formes de translations d'adresses dans la suite de cette section.

Une translation d'adresse n'est en fait rien d'autre qu'un remplacement contrôlé des adresses source ou destination de tous les paquets d'une connexion. En général, cela permet de détourner les connexions réseau ou de simuler une provenance unique pour plusieurs connexions. Par exemple, les connexions à Internet peuvent être détournées vers un proxy fonctionnant sur la passerelle de manière transparente, en modifiant les adresses destination des paquets émis par les clients. De même, il est possible de simuler un seul serveur en remplaçant à la volée les adresses source des paquets que la passerelle envoie sur Internet.

On distingue donc deux principaux types de translations d'adresses : les translations d'adresse source et les translations d'adresse destination. Parmi les translations d'adresse source se trouve un cas particulier particulièrement intéressant : le « masquerading ». Cette technique permet de remplacer toutes les adresses source des paquets provenant des machines d'un réseau local par l'adresse de l'interface de la passerelle connectée à Internet, tout en conservant une trace des connexions réseau afin d'acheminer vers leur véritable destinataire les paquets de réponse. Ainsi, une seule connexion à Internet peut être utilisée par plusieurs machines distinctes, même si elles ne disposent pas d'adresses IP fournies par l'IANA.

Lorsqu'une machine du réseau local envoie un paquet à destination d'Internet, ce paquet est acheminé vers la passerelle, qui est la route par défaut. Celle-ci commence par modifier l'adresse source de ce paquet et mettre sa propre adresse à la place, puis le transfère vers la machine du fournisseur d'accès. Tous les paquets émis par les machines du réseau local semblent donc provenir de cette passerelle, et seront acheminés normalement à destination. En fait, la complication provient des paquets de réponse, puisque les machines situées sur Internet croient que la machine avec laquelle elles communiquent est la passerelle. Ces paquets sont donc tous envoyés à la passerelle directement, et celle-ci doit retrouver la machine du réseau local à laquelle ils sont destinés. Cette opération est réalisée de différentes manières selon les protocoles utilisés, et elle suppose que la passerelle conserve en permanence une trace des connexions réseau effectuées par les machines du réseau local.

Pour TCP, ce suivi de connexion est réalisé en modifiant également le port source des paquets provenant des machines locales. La passerelle utilise un port unique pour chaque connexion, qui va lui permettre de retrouver la machine à laquelle un paquet est destiné lorsqu'elle en reçoit un provenant d'Internet. Par exemple, si une machine locale fait une connexion à Internet, la passerelle alloue un nouveau numéro de port pour cette connexion et modifie tous les paquets sortants comme ayant été émis par la passerelle elle-même, sur ce port. Lorsque l'autre machine prenant part à la connexion, située sur Internet, envoie un paquet de réponse, celui-ci sera à destination de la passerelle, avec comme port destination le port alloué à cette connexion. La passerelle peut donc retrouver, à partir de ce port, l'adresse de la machine destination réelle, ainsi que le port source que cette machine utilisait initialement. La passerelle modifie donc ces deux champs du paquet, et le renvoie sur le réseau local. Finalement, la machine destination reçoit le paquet sur son port, et ce paquet semble provenir directement d'Internet, comme si la connexion avait été directe. Notez bien que la passerelle ne modifie pas les adresses source des paquets provenant d'Internet, elle ne fait que les réacheminer vers la bonne destination.

Ainsi, le masquerading est un mécanisme complètement transparent pour les machines du réseau local. En revanche, pour les machines de l'Internet, il ne semble y avoir qu'un seul interlocuteur : la passerelle. Celle-ci utilise des numéros de ports variés, mais cela ne les regarde pas. Les machines du réseau local sont donc complètement « masquées » par la passerelle, d'où le nom de masquerading.

Tout ce travail effectué par la passerelle nécessite un traitement spécifique sur chaque paquet qu'elle achemine, et consomme bien entendu des ressources système. Cependant, les débits utilisés pour les connexions à Internet, même les plus rapides, sont très loin de mettre à genoux une passerelle sous Linux, même sur les plus petites machines (386 et 486). Vous voilà rassurés, et peut-être aurez-vous trouvé d'ici peu une utilité à l'un de ces dinosaures qui traînent encore dans votre garage...

9.4.3. Trajet des paquets

Il existe cinq points d'entrée au total pour les modules de Netfilter dans le code des couches réseau IP de Linux. À ces cinq points d'entrée correspondent cinq chaînes prédéfinies, qui peuvent être accédées par l'intermédiaire des diverses tables de Netfilter. Les paragraphes suivants décrivent ces cinq chaînes, ainsi que l'ordre dans lequel les paquets les traversent.

Les paquets réseau provenant de l'extérieur sont d'abord contrôlés par le noyau afin de détecter les erreurs les plus simples. Les paquets mal formés ou corrompus sont systématiquement éliminés à ce niveau, avant même d'atteindre le code de Netfilter. Les autres paquets commencent alors leur trajet dans les couches de plus haut niveau. C'est à ce moment là qu'ils rencontrent la chaîne PREROUTING, qui est la première chaîne prise en compte. Cette chaîne précède le code de routage, qui est en charge de déterminer le trajet que le paquet devra suivre par la suite à partir de l'adresse destination des paquets. C'est donc dans cette chaîne que l'on pourra modifier l'adresse destination des paquets, si l'on veut faire une translation d'adresse destination. Cette chaîne est donc utilisable dans la table nat.

Les paquets qui traversent la chaîne PREROUTING sont ensuite orientés par le code de routage de Linux. S'ils sont à destination de la machine locale, ils rencontrent une autre chaîne prédéfinie : la chaîne INPUT. C'est à ce niveau que l'on peut empêcher un paquet d'entrer dans le système, aussi cette chaîne est-elle naturellement disponible dans la table filter.

Les autres paquets doivent être transférés vers une autre machine, souvent par une autre interface réseau. Ils traversent alors la chaîne FORWARD. Cette chaîne permet de contrôler les paquets qui transitent au travers d'une passerelle, et fait donc partie de la table filter.

Les paquets qui sont acceptés par la chaîne FORWARD retournent ensuite dans le code de routage du noyau, afin de déterminer l'interface réseau par laquelle ils doivent être réémis. Une fois cela réalisé, ils sont prêts à être réémis, mais ils doivent auparavant traverser la chaîne POSTROUTING. C'est dans cette dernière chaîne que se font les translations d'adresse source, aussi est-elle accessible dans la table nat.

Enfin, les paquets émis par la machine locale à destination de l'extérieur doivent impérativement traverser la chaîne OUTPUT, dans laquelle on pourra filtrer les informations sortantes. Cette chaîne est donc accessible dans la table filter. Les paquets qui se révèlent avoir le droit de sortir traversent alors de code de routing, puis, tout comme les paquets qui ont été transférés, entrent dans la chaîne POSTROUTING. La chaîne OUTPUT est également accessible au travers de la table nat, afin de permettre la modification des adresses destination des paquets avant leur routage.

9.4.4. Configuration du noyau et installation des outils

Les fonctionnalités de Netfilter sont toutes fournies par le noyau lui-même, aussi leur configuration doit-elle se faire au niveau du noyau. La manière de procéder pour configurer le noyau a été indiquée dans le paragraphe traitant de la compilation du noyau. Les options à activer pour mettre en place les fonctionnalités de filtrage des paquets et de translation d'adresse sont les suivantes :

• « Network packet filtering (replace ipchains) », pour activer les fonctionnalités de filtrage des paquets en général ;

• « Network packet filtering debugging », pour obtenir les messages de débogage du noyau. Ces messages peuvent être très utiles pour mettre au point les règles de filtrage ;

• « Connection tracking (required for masq/NAT) » (menu « IP: Netfilter Configuration »), pour permettre le suivi des connexions auxquelles appartiennent les paquets IP reçus par la passerelle. Cette option est nécessaire pour réaliser un partage de connexion à Internet ;

• « FTP protocol support », pour permettre la gestion des connexions FTP, qui exigent un traitement particulier pour les translations d'adresses ;

• « IP tables support (required for filtering/masq/NAT) », pour permettre la gestion des tables de Netfilter ;

• « Packet filtering », pour inclure le support de la table « filter ». Cette option est nécessaire pour réaliser un Firewall ;

• « REJECT target support », pour permettre le rejet des paquets (par défaut, seul l'abandon des paquets est fourni dans le code de filtrage) ;

• « Full NAT », pour inclure la table « nat » de Netfilter. Cette option est nécessaire pour réaliser un partage de connexion à Internet ;

• « MASQUERADE target support », pour permettre le masquerading afin de réaliser un partage de connexion à Internet.

Vous devrez ensuite compiler le noyau et les modules, et les installer comme indiqué dans la partie traitant de la compilation du noyau.

La manipulation des chaînes et la manipulation des règles de Netfilter se fait grâce à l'outil iptables. Cette commande doit normalement avoir été installée par votre distribution. Toutefois, si ce n'est pas le cas, vous pouvez la compiler manuellement. Pour cela, il vous faudra récupérer l'archive des sources d'iptables. Cette archive peut être trouvée sur Internet. La version courante est la 1.2.6a, aussi l'archive se nomme-t-elle iptables-1.2.6a.tar.bz2.

L'installation d'iptables ne pose pas de problème particulier en soi. Vous devrez d'abord décomprimer l'archive avec les deux commandes suivantes :

bunzip2 iptables-1.2.6a.tar.bz2
tar xf iptables-1.2.6a.tar

9.4.5. Utilisation d'iptables

Il est possible, grâce à iptables, d'effectuer toutes les opérations d'administration désirées sur les tables de Netfilter. Vous pourrez donc créer des nouvelles chaînes, les détruire, définir les politiques par défaut, ainsi que manipuler les règles de ces chaînes (en ajouter, en supprimer ou en remplacer une). En fait, iptables dispose d'un grand nombre d'options, et seules les options les plus importantes seront présentées ici. Vous pouvez lire la page de manuel iptables si vous désirez plus de renseignements sur la manipulation des chaînes et des règles de filtrage du noyau.

iptables [-t table] -N chaîne

iptables [-t table] -X chaîne

iptables [-t table] -L chaîne

iptables [-t table] -F chaîne

iptables [-t table] -A chaîne [-s source] [-d destination] [-p protocole]
    [-i itfsource] [-o itfdest] [-j cible]

iptables -D chaîne numéro

iptables -P chaîne cible

9.4.6. Exemple de règles

Ce paragraphe a pour but de présenter quelques-unes des règles les plus classiques. Le but est ici de présenter les principales fonctionnalités d'iptables et non de réaliser un Firewall fiable. Reportez-vous à des documents plus spécialisés pour cela.

iptables -P INPUT -j DROP
iptables -P FORWARD -j DROP
iptables -P OUTPUT -j DROP

iptables -A INPUT -s 192.168.0.0/24 -i eth0 -j ACCEPT
iptables -A OUTPUT -s 127.0.0.0/8 -o eth0 -j ACCEPT

iptables -A OUTPUT -s 127.0.0.0/8 -o lo -j ACCEPT
iptables -A INPUT -d 127.0.0.0/8 -i lo -j ACCEPT

iptables -t nat -A POSTROUTING -s réseau/24 -o ppp0 -j MASQUERADE

9.4.7. Configuration des clients

La configuration des autres machines du réseau est très simple. Vous devrez tout d'abord définir la machine possédant la connexion à Internet comme passerelle par défaut de tous vos postes clients. Cette opération peut se réaliser de différentes manière selon le système d'exploitation utilisé par ces machines. Sous Linux, il suffit d'utiliser la commande suivante :

route add default gw passerelle eth0

La deuxième étape est ensuite de donner accès aux postes clients au DNS de votre fournisseur d'accès. Cela permettra en effet d'utiliser les noms de machines autres que ceux de votre réseau local. Encore une fois, la manière de procéder dépend du système utilisé. Sous Linux, il suffit d'ajouter les adresses IP des serveurs de noms de domaine de votre fournisseur d'accès dans le fichier de configuration /etc/resolv.conf.