Je pense qu'à ce niveau là de la documentation, les utilisateurs du monde Windows® (y en a t'ils qui lisent cette documentation ?) doivent se demander dans quel monde de fous ils sont tombés ... Et bien oui, sous Windows® c'est beaucoup plus simple d'installer un firewall de type ZoneAlarm®, Tiny Firewall®, ou autre... Un double clique sur le "setup.exe", et hop cela marche du premier coup. Cela marche, oui, mais est-ce que c'est fiable ? Parce qu'à la porte de votre PC, il y a un bon nombre de virus-vers qui n'attendent qu'une erreur de votre part pour désactiver vos firewall, anti-virus et autres programmes de ce protection.
En fait, on ne peut pas comparer le mode de fonctionnement des firewalls sous Windows® et sous Linux tellement ils sont différents.
- Sous Windows®, c'est l'OS qui met à disposition les paquets IP qu'il désire(*) dans l'espace utilisateur ("user space"), où un programme externe ("ZoneAlarm®", "Tiny Firewall®", etc...) décide si oui ou non ce paquet doit être accepter pas le système. Tout cela est bien joli, mais que se passe t'il si un autre programme de la machine, un virus par exemple, attaque le firewall et le force à s'éteindre ? La machine perd tout simplement sa protection... Ne souriez pas, ce type d'attaque est très en vogue à l'heure où j'écris ces lignes. En effet c'est parfaitement faisable, car la plus grande partie des utilisateurs de Windows® utilisent leur machine avec les droits administrateurs (même si ils ne sont pas connectés spécifiquement sous ce nom). Ou pire encore, ils utilisent les versions 95, 98, ou Millenium, qui n'ont aucune notion de restriction de droits. Enfin, si c'est le même utilisateur qui utilise la machine et qui a démarré le firewall, alors tout programme lancé, par inadvertance ou non, par cet utilisateur pourra arrêter le firewall...
Quand au fonctionnement du firewall intégré dans la version XP de Windows®, même si il *semble* intégré dans l'OS, il est similaire aux logiciels de Firewall dont nous venons de parler. Donc c'est un produit insuffisant et à éviter...
- Sous Linux par contre, tout reste au niveau de l'espace kernel ("kernel space"), c'est à dire qu'à l'exception d'"iptables", aucun programme ne peut interférer avec Netfilter. Comme il faut impérativement avoir les droits de root pour lancer "iptables", et que bien entendu vous n'utilisez que rarement les droits root, vous pouvez être tranquilles.
(*) : C'est juste une petite remarque auquel j'invite l'utilisateur de Windows® à réfléchir quelques secondes. Qu'est-ce qui vous prouve que toutes les trames IP qui rentrent ou qui sortent de votre Windows® passent bien par la validation du firewall que vous avez installé ? Le code source de Windows® ? Vous l'avez vu ? La belle affaire : Même si c'est le cas, je vous rappelle que vous avez un accord de non divulgation qui vous interdit de parler de ce que vous avez pu y trouver...
Il existe plusieurs manières d'aborder l'explication de "Nerfilter" : Soit rentrer dans les détails de sa structure interne, et dans ce cas là il vaut mieux prévoir quelques boîtes d'aspirines. Soit, et c'est ce que je vais tenter de faire, expliquer les principaux composants dont l'utilisateur a besoin, puis aborder au fur et à mesure les aspects plus techniques. Pour ceux qui veulent en savoir un peu plus sur le fonctionnement de Netfilter, je les invite à consulter la documentation du développeur de Netfilter (traduite en français).
Bien, êtes vous prêt pour la grande explication de Netfilter ? Oui ? OK, allons y alors.
Netfilter peut intervenir en 5 endroits du système de gestion de la pile IP. Pour chacune de ces étapes (que l'on appelle des "hook", pour "crochet" en français), Netfilter peut :
- Imposer au kernel de supprimer le paquet ("drop" en anglais). Auquel cas, il est jeté aux oubliettes, et c'est comme si le paquet n'avait jamais existé.
- Indiquer au kernel que le paquet est accepté. Dans ce cas là, le kernel peut continuer à travailler dessus.
- Modifier le paquet, puis le rendre au kernel.
Pour un programmeur, il est facile de comprendre ce qu'est un "hook". C'est l'équivalent dans la couche IP d'une interruption (matérielle ou logicielle) : Lorsque qu'un événement arrive, le système d'exploitation arrête les tâches en cours, et exécute un morceau de code particulier. Une fois que ce code est fini, le système continue son travail comme si rien ne s'était passé.
Pour un non-informaticien, le hook peut s'expliquer comme suit : Lorsque vous roulez en voiture, et qu'il y a par exemple un accident sur la route, les gendarmes vont bloquer le passage, et vous faire dévier sur un itinéraire de secours. A la sortie de cet itinéraire, et si tout se passe bien, vous réintégrerez votre route initiale. Et vous aurez effectué ce que l'on appelle vulgairement "faire un crochet". 
Pour chacun de ces "hook", Netfilter associe une chaîne. Mais qu'est-ce qu'une chaîne ? Une chaîne est un ensemble de règles (du type "si quelque chose alors je fais ceci") concernant les paquets IP : leur origine, leur destination, leur taille, etc... En fonction des différentes règles de la chaîne, Netfilter pourra décider quoi fait du paquet IP : Le laisser passer, le supprimer ou le modifier.
Reprenons notre analogie avec la route : Les paquets IP sont des voitures, qui circulent sur des routes. Si Netfilter n'est pas configuré spécialement, les voitures se déplacerons à travers les différentes routes de la pile IP, emprunteront les ronds-points de routage, puis finirons par sortir de la route IP. Par contre, si Netfilter est activé, il y aura des barrages de police en certains endroits du trajet des paquets (les fameux "hook"). En fonction des règles contenus dans ces "hook" (les fameuses chaînes, c'est à dire les signes "STOP"), le barrage décidera ou non de laisser passer le véhicule IP, voir de le modifier... D'ailleurs, c'est un peu ce qui se passe sur nos routes à nous. Il y a parfois des contrôles de police ou de gendarmerie : En fonctions de certaines règles (contrôle des papiers, de l'alcoolémie, de l'état du véhicule, du délit de "sale gueule", ...) l'officier pourra ou non décider de laisser passer le véhicule...
|
Hooks et chaînes
|
Voyons maintenant les 5 "hook" et les 5 chaînes qui y sont associées :
| Hook | Chaîne | Description |
| NF_IP_PRE_ROUTING | PREROUTING |
A ce stade, le paquet est "brut de forme", c'est à dire qu'il n'a subit aucune modification par rapport à ce que l'interface réseau a reçu. On reparlera de ce hook un peu plus tard, donc ce n'est pas la peine de s'y intéresser tout de suite. |
| NF_IP_LOCAL_IN | INPUT |
Ce "hook" est très intéressant, car à ce stade, le paquet est prêt à être envoyé aux couches applicatives, c'est à dire aux serveurs et aux clients qui tournent sur la machine. C'est un des points principaux sur lequel nous allons travailler. |
| NF_IP_FORWARD | FORWARD |
"Forward" ("faire suivre" en français) est assez particulier. Ce "hook" voit passer des paquets IP qui vont transiter d'une interface réseau à une autre, sans passer par la couche applicative. Pourquoi diantre faire suivre un paquet entre 2 interfaces réseaux, comme par exemple entre "eth0" et "ppp0" ? En fait, c'est afin de permettre à Linux de se transformer en passerelle : Vous vous souvenez, c'est l'histoire du garde-barrière que nous avons vu dans le 1er chapitre. Comme pour "NF_IP_PRE_ROUTING", nous n'en reparlerons que plus tard. |
| NF_IP_LOCAL_OUT | OUPUT |
Ce "hook" est l'équivalent du "NF_IP_LOCAL_IN", sauf qu'il est exécuté après que les couches applicatives aient traités, ou générés, un paquet IP. Tout comme "NF_IP_LOCAL_IN", c'est un point que nous allons voir en détail. |
| NF_IP_POSTROUTING | POSTROUTING |
C'est l'équivalent du "NF_IP_PRE_ROUTING" pour les paquets IP sortants de la couche IP. A ce stade, les paquets sont prêt à être envoyés sur l'interface réseau. Comme pour "NF_IP_PRE_ROUTING" et "NF_IP_FORWARD", nous en parlerons plus tard. |
Le graphique ci-dessus nous montre l'implantation des différents hooks. Le sujet de ce document étant la sécurité réseau, ce qui nous intéresse le plus est la possibilité de contrôler les paquets arrivant et sortant des différents logiciels de notre machine. C'est donc au niveau des "hooks" "NF_IP_LOCAL_IN" et "NF_IP_LOCAL_OUT" que nous allons nous pencher plus précisément, via la notion de filtrage ("filter" ou "filtering" en anglais).
La partie que nous venons de voir ici est une des plus technique de ce document. J'espère que vous êtes toujours là, frais et dispo pour le paragraphe suivant...
|
