====== 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. {{ :netfilter:mangle.gif |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 : * Nous disposons de deux liens sur le Net : * l'un, très rapide et très fiable, mais très cher et facturé au volume de données ; * l'autre, classique, comme une connexion ADSL, avec les limites que nous leurs connaissons. * Nous souhaitons exploiter au mieux ces deux connexions, par exemple de la façon suivante : * Nous devons mettre à jour le contenu d'un serveur distant. Il faut le faire de façon rapide et sûre. Il n'y a pas forcément beaucoup de données à transmettre, mais il est impératif que ce soit fait le plus rapidement et le plus sûrement possible. * Nous devons assurer un accès au Net pour les utilisateurs du réseau local, mais avec une qualité de service plus faible. 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. * Nous disposons d'une connexion ADSL et il arrive très souvent que certains utilisateurs fassent du téléchargement FTP sur des serveurs rapides. Chaque fois qu'un téléchargement est lancé, toute la bande passante Download est utilisée et les autres utilisateurs ne peuvent plus surfer dans de bonnes conditions. * En exploitant le marquage de paquets associé aux fonctions de QoS, nous pourrons restreindre la bande passante exploitée par le download FTP afin de laisser un peu d'espace pour les autres activités. * Ceci peut aussi être appliqué aux transferts « peer-to-peer », qui ont l'inconvénient de monopoliser le peu de bande passante upload dont on dispose sur des connexions asymétriques comme ADSL ou câble. ==== 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.