Résumé Netfilter Workshop

Supports des présentations de la journée utilisateur

Les supports des présentations de la première journée sont à présent disponibles. Par ordre chronologique :

• Stephen-Hemminger_CLI-QoS.pdf
• David-Miller_Linux-Multiqueue-Networking.pdf
• Jesper-Brouer_Large-iptables-rulesets.pdf
• Pierre-Chifflier_NFQUEUE-Bindings.pdf
• Luc-Bourdot_Presentation-Eole.pdf
• Eric-Leblond_Ulogd2.pdf
• Jozsef-Kadlecsik_IPset.pdf

Eric Leblond et Pierre Chifflier: avancement d’Ulogd2

J’ai [Eric Leblond] fait un point sur le travail réalisé sur Ulogd2 durant l’année écoulée.

La quasi totalité des plugins est utilisable. Conntrack et les plugins de journalisation d’entrée sont désormais complétement supportés par les plugins de sortie. Et des choses importantes, comme la décision de NAT, peuvent être stockées pour interrogation ultérieure.

Les derniers plugins non fonctionnels sont :

• IPFIX
• SQLite

Pierre m’a rejoint après cet exposé pour expliquer comment il a défini les schémas de la base de données, afin d’utiliser les fonctionnalités avancées proposées par les bases de données.

J’ai completé ma présentation avec une démonstration de nf3d, un outil de visualisation qui permet d’afficher les connexions et les paquets journalisés dans une base de données PostgreSQL, avec ulogd2.

Nf3d screenshot

NFWS 2008 : photo de groupe

Here’s 6th Netfilter workshop group photo:

Group photos

De gauche à droite, en commençant par le haut :

• Stephen Hemminger, Henrik Nordström, Harald Welte, Holger Eitzenberger, Sanjay Rao, Samir Bellabes, Pablo Neira Ayuso
• Nishit Shah, Jimit Mahadevia, Balazs Scheidler, Jesper Dangaard Brouer, Jozsef Kadlecsik, Pierre Chifflier, Jan Engelhart
• David Miller, Krisztián Kovács, Patrick McHardy, Moritz Grimm, Eric Leblond

Tproxy arrive dans net-next-2.6

Suite aux discussions sur Tproxy, Krisztián Kovács à envoyé ses patches à la liste de diffusion Netfilter et netdev. La réponse de Davem a été rapide, quelques minutes après l’envoi du mail :

Applied to net-next-2.6

Tproxy sera donc distribué dans la branche principale pour 2.6.28.

Pablo Neira, bibliothèque Userspace

libnfnetlink

On a deux APIs

• l’ancienne, basée sur libnetlink (outils iproute)
• la nouvelle, qui présente une meilleure gestion des erreurs

Eric Leblond a contribué à ifindex2ifname sur la base du travail de Harald Welte. Ceci permet la résolution du nom des interfaces.

libnetfilter_queue

Peu de changements depuis le dernier workshop. La bibliothèque utilise l’ancienne API libnfnetlink et il lui manque des fonctions helper, principalement pour gérer la modification de paquets (packet mangling).

libnetfilter_log

Pas de changement. Utilise l’ancienne API.

Pablo Neira

libnetfilter_conntrack

Libnetfilter_conntrack présente deux APIs. L’ancienne est complétement désuette. La nouvelle est basée sur une logique d’envoi/réception et propose un nombre appréciable de fonctions helper (afficher, comparer, copier).

La dernière version introduit un filtre BSF qui peut être utilisé pour filtrer les entrées avant qu’elles ne quittent le noyau. Avec un filtre BSF, on peut par exemple éviter de récupérer un évenement de connexion pour localhost.

Pablo Neira, avancement des conntrack-tools

Les Conntrack-tools

La dernière version est sortie en mai et la prochaine devrait arriver dès la semaine prochaine.

Outil Conntrack en ligne de commande

• Même syntaxe que pour iptables
• Propose des options de filtrage
• Peut lister, modifier et détruire les connexions
• Supporte l’attente d’événements

Conntrackd

Il s’agit du démon, construit pour la synchronisation des tables de suivi de connexions Netfilter. Pour l’instant, seul un backup primaire est supporté, mais l’architecture permet de disposer de plusieurs primaires. Il utilise des messages basés sur TLV (76 à 100 octets).

Le protocole propose plusieurs types de messages :

• NOTRACK: envoie simplement un message sans accusé
• ALARM:
• FT-FW: accusé de réception des paquets

État d’avancement de conntrackd

Depuis 2.6.22, plus besoin de désactiver le suivi des fenêtres TCP. Depuis 2.6.25, le support du filtrage Netfilter en espace noyau est disponible (on peut choisir de répliquer uniquement les connexions TCP).

Le support IPv6 est complet, mais aurait besoin de plus de tests.

la TODO

• Canaux netlink redondants dédiés
• Support de plusieurs primaires

Pablo Neira, filtres de Bloom

Principes

Bloom a inventé le filtre qui porte son nom dans les années 70. Ce filtre donne une représentation compacte d’éléments.

Il permet également les faux positifs : un élément peut être vu dans un élément alors qu’il n’y est pas. Si on efface un élément du filtre, l’effet inverse peut se produire. Il faut donc gérer cette étape avec précautions.

Pablo Neira

Quels usages au filtrage réseau approximatif ?

Ça peut être utile pour maintenir de grands ensembles, comme le spam. Comme on aura des faux positifs, est-ce réellement utilisable pour une solution de filtrage réseau ?

Krisztián Kovács, avancement de tproxy

Les développements de Tproxy ont atteint l’objectif fixé l’an dernier.

Krisztián Kovács

Chaque champ, de la partie Netfilter à la partie concernant le routage, est prêt pour être inclus, et les patches demandant l’inclusion dans la branche principale seront envoyés bientôt.

Jozsef Kadlecsik, statut d’IPSET

Derniers développements

Les derniers développements apportent un nouveau type ipportiphash, utilisable pour stocket une adresse IP, un numéro de port arbitraire et setlist qui est une union d’ensembles.

Jozsef Kadlecsik

Ce qui va suivre

Ipset 2.4 devrait être publié dans le courant du mois d’octobre et inclure les nouveaux modules. Vers la fin de l’année 2008, ipset 3.0 devrait également sortir. Il proposera un nouveau protocole compatible netlink et rétro compatible avec les anciennes versions. Si tout va bien, ipset sera renommé en nfset et l’ancien protocole sera supprimé (mi 2009). Après le renommage en nfset le travail se concentrera sur le support IPv6 et les efforts vers l’inclusion dans la distribution officielle de Netfilter.

Yasuyuki Kosakai, MIPv6

Le filtrage de flux IPv6 sous Linux est à présent complet. Le travail qui reste est MIPV6.

Yasuyuki Kosakai

Introduction de MIPV6

2 modes existent :

• tunneling bidirectionnel : tous les flux passent par Home
• optimisation du routage

Définition des tuples du Conntrack

Le conntrack doit être construit pour gérer ce choix possible :

• nf_conntrack_ipv6 construit les tuples par adresse Home
• nf_conntrack_ipv6 gère les tuples comme tunnelés

Le premier choix est le meilleur car il correspond au fonctionnement interne. Par ailleurs, c’est bien l’adresse finale qui sera prise en compte.

Il est facile d’envoyer des paquets comportant une fause adresse Home. Ainsi, le filtre à états peut laisser passer le paquet forgé si HAO et RT2 ne sont pas vérifiés.

Proposition

Le nouveau helper inspecte la signalisation MIPv6 (proto = 135) et garde une liste des passerelles Home. En faisant cela, on peut rejeter les paquets qui proviennent de passerelles non enregistrées.

Comme d’habitude, le chiffrement des données suffit à tout casser. Le draft-irtf-mip6-cn-ipsec-05 introduit le chiffrement des mises à jours et accusés de réceptions, et il n’existe alors aucun moyen de filtrer sur ces données.