1. Introduction

Salut,

Ce document est un périple; quelques parties vous aiderons bien, alors que dans d'autres vous serez presque seuls. Le meilleur conseil que je puisse vous donner est d'attraper une grande bonne tasse de café, ou de chocolat chaud, de vous prendre une chaise confortable, et de lire le contenu de ce document avant de vous aventurer tout seul dans le dangereux monde du "network hacking".

Pour comprendre mieux l'usage de l'infrastructure au dessus de netfilter, je vous recommande la lecture du "Packet Filtering HOWTO" et du "NAT HOWTO". Pour plus d'informations sur la programmation kernel, je vous suggère le "Rusty's Unreliable Guide to Kernel Hacking" et le "Rusty's Ureliable Guide to Kernel Locking".

(C) 2000 Paul `Rusty' Russell. Sous licence GNU GPL.

1.1 Qu'est ce qu'est Netfilter ?

Premièrement, Netfilter est un canevas pour modifier les paquets réseaux, en dehors de l'interface de sockets Berkeley. Il est composé de 4 parties. D'abord, chaque protocole définit des "hooks" (accroches) (IPv4 en définit 5) qui sont des points bien déterminés dans le trajet du paquet dans la pile de protocole. A chacun de ces points, le protocole va appeler le canevas de Netfilter et lui passer le paquet et le numéro de "hook".

Deuxièmement, des parties du kernel peuvent s'enregistrer pour écouter à diffèrents "hooks" pour chacun des protocoles. Donc quand un paquet est passé au canevas Netfilter, ce dernier va vérifier si quelqu'un s'est enregistré pour ce protocole et ce "hook". Si c'est le cas, ils vont tous avoir une chance d'examiner (et aussi modifier) le paquet dans l'ordre, et ensuite de : se débarrasser du paquet (NF_DROP), de l'autoriser à passer (NF_ACCEPT), de dire à netfilter d'oublier le paquet (NF_STOLEN), ou de dire à Netfilter de queuter le paquet en userspace (NF_QUEUE).

Troisièmement, les paquets qui ont été queues, sont récupérés (par le driver ip_queue) pour les envoyer en userspace. Ces paquets sont gérés asynchronement.

La partie finale consiste en commentaires cools dans le code et de la documentation. C'est très important dans tous projets expérimentaux. Le moto de netfilter est (volé sans aucune honte de Cort Dougan) :

        ``So... how is this better than KDE?''  (``Alors ... en quoi c'est mieux que KDE ?'')

(Ce moto a presque réussi sont chemin : `Whip me, beat me, make me use ipchains' (`Fouettez moi, battez moi, faites moi utiliser ipchains'))

Additionnellement à ce canevas nu, des modules divers ont été écrits, pour fournir les mêmes fonctionnalités que les anciens (pre-netfilter) kernels, et en particulier un système NAT extensible, et un système de filtrage de paquets extensible lui aussi (iptables).

1.2 Qu'est ce qui n'allait pas avec ce qu'on avait dans les 2.0 et les 2.2 ?

1. Pas d'infrastructure établie pour passer des paquets au userspace:
   • La programmation kernel est difficile.
   • La programmation kernel doit être faite en C/C++
   • Les polices de filtrage dynamiques n'ont pas de place justifiée dans le kernel.
   • 2.2 a introduit la possibilité de copier des paquets vers le userspace via netlink, mais re-injecter des paquets était lent, et sujet aux vérifications de `sanité'. ex: la re-injection d'un paquet se disant provenir d'une interface existante n'était pas possible.
2. Le proxy transparent était bordellique :
   • On vérifie tous les paquets pour voir si il y une socket attachée à cette adresse.
   • root a le droit d'attacher une socket à une adresse étrangère.
   • Impossible de rediriger les paquets générés localement.
   • REDIRECT ne gère pas les réponses UDP : rediriger les paquets UDP de named vers le port 1153 ne marche pas parce que quelques clients n'aiment pas que la réponse arrive avec un port source diffèrent de 53.
   • REDIRECT ne se synchronise pas avec l'allocation de port TCP/UDP : un utilisateur peut avoir un port masqué par une règle REDIRECT.
   • A été cassé au moins 2 fois pendant la série des 2.1.
   • Le code est extrêmement intrusif. Considérez les stats sur le nombre de `#ifdef CONFIG_IP_TRANSPARENT_PROXY' dans le 2.2.1 : 34 occurrences dans 11 fichiers. Comparez cela à `CONFIG_IP_FIREWALL', qui a 10 occurrences dans 5 fichiers.
3. Créer une règle de filtrage de paquets indépendamment de l'adresse de l'interface n'est pas possible:
   • Obligation de savoir l'adresse de l'interface locale pour distinguer les paquets générés localement ou les paquet terminant en local, des paquets qui traversent seulement.
   • Même cela n'est pas suffisant dans les cas de redirection ou de masquerading.
   • La chaîne FORWARD seule a les informations sur le paquet qui sortent, ce qui veut dire que vous avez à deviner d'où le paquet est venu, ou vous avez besoin d'une bonne connaissance de la topologie du réseau que vous utilisez.
4. Le masquerading est cloué sur le filtrage de paquets:

   Les interactions entre le masquerading et le filtrage de paquets rendent le firewalling complexe.

   • Lors du filtrage dans INPUT, les paquets semblent être destinés à la machine elle même.
   • Lors du filtrage dans FORWARD, les paquets démasqueradés ne sont pas vu du tout.
   • Lors du filtrage dans OUTPUT, les paquets semblent venir de la machine locale

5. La manipulation du TOS, redirection, ``ICMP unreachable'' et le marquage de paquets (qui peu affecter le port-forwarding, le routage, et le QoS) sont cloués sur le code de filtrage de paquets aussi.
6. Le code d'ipchains n'est ni modulaire, ni extensible (par exemple: le filtrage basé sur la adresse MAC, le filtrage des options, etc).
7. Le manque d'infrastructure suffisante a mené à la profusion de différentes techniques :
   • Masquerading, plus des modules pour certains protocoles.
   • La NAT rapide par le code de routage (n'a pas de module qui gère certains protocoles).
   • Le port-forwarding, la redirection, et le auto-forwarding
8. Incompatibilité entre CONFIG_NET_FASTROUTE et le filtrage de paquets:
   • Les paquets qui ne font que nous traverser doivent passer par trois chaînes de toutes façons.
   • Impossible de dire si ces chaînes peuvent être évitées.
9. L'inspection de paquets détruits est impossible à cause d'une protection de routage (par exemple: la vérification d'adresse source).
10. Impossible de lire automatiquement les compteurs sur les règle de filtrage de paquets.
11. CONFIG_IP_ALWAYS_DEFRAG est une option à la compilation seulement, rendant la vie difficile pour les distributions qui veulent un kernel général.

1.3 Qui êtes vous ?

Je suis le seul à être assez fou pour faire ça. En tant que co-auteur de ipchains et maintenant mainteneur du Linux Kernel IP Firewall, je vois beaucoup des problèmes que les gens ont avec le système actuel, en même temps d'avoir des informations sur ce qu'ils tentent de faire.

1.4 Pourquoi ça plante ?

Ah bon ?! Bah fallait voir comment c'était la semaine dernière !

Parce que je ne suis pas un aussi bon programmeur que ce que tout le monde espère, et je n'ai certainement pas testé tous les scénarios, parce que je manque de temps/équipement et/ou d'inspiration. J'ai effectivement une ``test-suite'', que je vous encourage à améliorer.