Table des matières

Et le reste...

Ce n'est pas tout...

Netfilter permet encore d'autres choses, qui sortent plus ou moins du cadre de cet exposé (peut-être un jour ?).

Mangle

Nous n'avons pas parlé de la table Mangle. Cette table permet d'effectuer un marquage des paquets.

La table « angle »

Nous pouvions, avec les premières versions de Netfilter,  marquer les paquets en PREROUTING ou en OUTPUT pour les sorties d'un processus local (en rouge sur l'illustration). Notez que depuis la version 2.4.18 du noyau, le système a été étendu à tous les « hooks » (en bleu sur l'illustration).

L'intérêt de ce marquage, qui n'est visible que dans la pile de la machine, est de pouvoir être relu par d'autres fonctions comme iproute ou la gestion de la qualité de service (QoS).

Ainsi, nous pouvons disposer de toute la puissance de Netfilter pour la sélection de divers types de paquets, et utiliser ensuite ce marquage pour le routage ou les priorités de passage.

Donner ici des exemples précis nous mènerait trop loin parce qu'il faudrait étudier en détail IProute2 et les fonctions de QoS des noyaux 2.6 et la vie est courte.

Voici tout de même un cas de figure qui serait gérable par ce système :

Avec le marquage de paquets associé à IProute, nous pourrons arriver à faire passer les mises à jour du serveur sur le lien rapide mais cher et tout le reste sur le lien ADSL.

Les logs

Netfilter propose un système de log puissant. Il ne s'agit pas ici d'une table, mais d'une cible.  Nous verrons plus en détail dans la suite ce que sont les cibles, disons pour le moment qu'il en existe deux qui sont particulières.

La cible LOG

Elle permet de remonter vers le démon syslog, avec, par défaut, le niveau « warning », des messages décrivant les paquets qui satisfont à la règle qui pointe vers LOG. Dans une distribution Debian, nous retrouverons donc leur trace dans /var/log/syslog.

Juste un exemple trivial, pour voir ce que ça donne :

iptables -A INPUT -i eth0 -p icmp -j LOG

Ce qui veut dire en français :

Ajouter à la chaîne INPUT la règle suivante : envoyer vers la cible LOG tout paquet ICMP qui entre par eth0

La machine dont l'IP de eth0 est 192.168.0.253 envoie un ping sur la machine192.168.0.251.

ping -n 1 192.168.0.251

Nous allons tracer la réponse au ping (INPUT). Nous récupérons cette trace dans /var/log/syslog  :

Dec  1 22:40:11 linux kernel: 
  IN=eth0
  OUT= MAC=00:00:b4:bb:5d:ee:00:20:18:29:11:31:08:00 
  SRC=192.168.0.251
  DST=192.168.0.253
  LEN=84 TOS=0x00 
  PREC=0x00 
  TTL=255 ID=4938 
  PROTO=ICMP TYPE=0
  CODE=0 
  ID=53771 
  SEQ=256

Ce qui est surligné en jaune correspond à la machine qui trace, c'est à dire celle qui envoie le ping et attend la réponse (qui est tracée). Ce qui est surligné en vert correspond à la cible du ping qui répond.

Comme vous le voyez, c'est un bon moyen pour se faire de la lecture facile, propre à vous aider en cas d'insomnie. Si la commande ping est écrite de la façon suivante :

ping -n 100 192.168.0.251

Nous génèrerons 100 fois une trace similaire à celle que nous venons de voir. Compter les moutons qui sautent la barrière est sans doute bien moins efficace.

Pour éviter que les logs n'arrivent à remplir votre disque dur, il existe la directive « limit » qui permet, comme son nom l'indique, de limiter l'envoi vers la cible de paquets satisfaisant à la règle. Cette directive à elle seule mériterait toute une page d'explications.

La cible ULOG

Plutôt que d'utiliser syslog, cette cible permet d'envoyer les paquets à un démon spécialisé : ulogd. Ce démon permet d'obtenir des logs plus présentables, voire stockés dans une base de données comme MySQL.