Page suivante Page précédente Table des matières

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:
  2. Le proxy transparent était bordellique :
  3. Créer une règle de filtrage de paquets indépendamment de l'adresse de l'interface n'est pas possible:
  4. Le masquerading est cloué sur le filtrage de paquets:

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

  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 :
  8. Incompatibilité entre CONFIG_NET_FASTROUTE et le filtrage de paquets:
  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.


Page suivante Page précédente Table des matières