Convention 2008 des développeurs Netfilter

1. Une semaine intense

Comme presque tous les ans depuis 2001, la convention Netfilter (ou Workshop) a de nouveau réuni les principaux développeurs Netfilter. La réunion était organisée cette année par la société INL, éditrice de NuFW et de l'appliance EdenWall.

Réitérant l'expérience de Séville en 2005, la convention a commencé par une journée ouverte aux utilisateurs. Cette journée ainsi que les suivantes se sont déroulées dans les locaux de l'ESIEA, qui propose, entre autres, le Mastère Spécialisé Sécurité de l'Information et des Systèmes. L'assistance, de bon niveau technique, a pu assister à des présentations réalisées tant par des développeurs que par des utilisateurs intensifs de Netfilter. Les deux jours suivants ont été deux jours de présentations entre développeurs où le travail de l'année et les prospectives ont été évoqués. Enfin, la semaine s'est terminée par deux jours de développement en commun où chacun a pu profiter de la présence des autres pour initier certains codes et obtenir des réponses rapides à des questions pointues.

2. Les journées utilisateurs

La journée a commencé par une présentation par Stephen Hemminger de l'interface en ligne de commande (CLI) de Vyatta. Assez peu liée à Netfilter, elle a néanmoins mis en lumière l'approche de Vyatta dans la réalisation d'une CLI pour routeur. L'intérêt de leur approche est principalement d'utiliser les capacités de bash pour en transformer complètement son comportement jusqu'à ce qu'il ressemble à une interface de routeur typique (semblable à celle de certains routeurs propriétaires).

L'exposé suivant était d'un niveau technique assez intense. David Miller, mainteneur de la couche réseau et du port sparc de Linux, nous a en effet présenté ses travaux sur les périphériques réseau multiqueues. Ces nouvelles cartes réseau offrent la possibilité de gérer de multiples files d'émissions parallèles. Avec la multiplication des cœurs des CPU, cette fonctionnalité devrait entraîner des améliorations notables de performance, puisque la file unique d'émission d'une carte réseau ne sera plus le goulot d'étranglement devant lequel les CPU viennent entasser leurs données. En termes de sécurité, ce système est également intéressant puisqu'il est possible d'aiguiller les flux suivant certaines propriétés réseau (typiquement des filtres). Facile alors d'imaginer des systèmes d'accélération matérielle de certains flux.

Pour terminer la matinée, Jesper Dangaard Brouer est venu présenter son travail chez l'opérateur Danois ComX. Ce dernier est un opérateur grand public qui propose un système de filtrage IP paramétrable à ses clients. À l'inverse de certains opérateurs français, le filtrage n'est pas réalisé sur les routeurs à domicile, mais plutôt sur les points de collectes locaux. Cela a pour conséquence des pare-feu gérant quelques centaines voire quelques milliers de domiciles. Chaque personne pouvant avoir des règles spécifiques, le nombre de règles iptables sur chaque pare-feu est donc extrêmement important (souvent supérieur à 50000). Comme Netfilter vérifie séquentiellement les règles, le nombre de tests pour chaque paquet est bien trop élevé et il provoque un ralentissement important du système. Jesper a donc travaillé à l'optimisation de Netfilter et d'iptables pour ce type de jeu de règles. Les structures de données utilisées dans iptables n'étaient pas performantes lors de l'insertion de nouvelles règles sur des jeux de règles massifs et ses modifications de code se sont principalement portées sur l'utilisation de structures adaptées à ce genre d'environnement.

Le problème de la vitesse de décision a été réglé en classant les règles. Au lieu de parcourir linéairement l'ensemble des règles, le jeu de règles est construit de manière à envoyer des morceaux de réseaux arbitraires dans une sous-chaîne qui est elle-même ensuite découpée en prenant des réseaux plus petits. En utilisant ce genre de découpage arborescent (voir Figure 1.), on passe d'une complexité proportionnelle au nombre de règles total à une complexité proportionnelle au nombre de règles par client, auquel on ajoute la profondeur de l'arbre.

La représentation du résultat global est visible Figure 2. Au vu de la complexité du graphe, on comprend que Jesper est développé un module perl (Iptables::SubnetSkeleton) pour générer automatiquement les règles iptables construisant l'arbre.

Après la pause repas, Pierre Chifflier d'INL nous a présenté ses travaux sur le pare-feu météo, grande avancée en termes de sécurité. Grâce à ses développements autour des bibliothèques de Netfilter, il a pu écrire en quelques lignes une application codée en Perl qui autorise ou non la connexion réseau en fonction de la météorologie de la destination dudit paquet... Comme un article est consacré à ses travaux dans ce hors-série, je ne m'étends pas davantage sur ce sujet.

Luc Bourdot du ministère de l'Éducation nationale nous a ensuite présenté le projet Eole dont il est le responsable depuis 2000. De plus en plus connu par le grand public, ce projet financé et réalisé par le ministère de l'Éducation nationale développe des appliances logicielles, appelées « modules » (serveur éducatif basé sur Samba, client léger, pare-feu IP ou authentifiant avec NuFW, serveur VPN, console d'administration) qui sont déployés massivement dans les écoles, collèges et les lycées français. On compte ainsi par exemple plus de 6000 installations du pare-feu Amon basé sur Netfilter. Les modules d'Eole ont pour particularité d'être facilement installables (0 question) ce qui permet leur déploiement sans connaissance informatique. Grâce à un mécanisme d'enregistrement sur un serveur central (module Sphinx) ou un questionnaire pour le mode autonome, il est possible d'instancier le serveur et de le rendre opérationnel facilement. La configuration et les règles du pare-feu sont générées à partir d'un modèle propre à chaque académie (dérivé lui-même d'un des modèles nationaux) au moment de l'instanciation. Un professeur, responsable de l'informatique dans un établissement, n'a donc pas besoin de connaissances spécifiques pour mettre en place la solution. L'édition des modèles de règle de filtrage se fait grâce à une interface graphique (ERA). Ainsi, même le responsable académique n'a nul besoin d'une connaissance approfondie de Netfilter.

J'ai ensuite présenté le logiciel Ulogd2 sur lequel je travaille maintenant depuis plus d'un an. Ce successeur de Ulogd enrichit les capacités de ce dernier en offrant une modularité accrue et un support des événements venant du suivi de connexions. C'est donc une solution de journalisation pour pare-feu complète. Un article étant consacré à ce logiciel dans ce hors-série, je vous laisse vous y référer.

Jozsef Kadlecsik a clôturé la journée en parlant de son projet ipset. Ce logiciel ajoute à iptables le support d'ensembles complexes (blocs d'adresses IP, blocs de réseaux, ensemble IP:port) tout en garantissant un filtrage rapide et efficace. Un des nombreux exemples d'utilisation est la constitution de listes d'adresses de spammeurs. En constituant de telles listes, il est alors possibles de ralentir leur trafic en leur appliquant la cible TARPIT qui amène la bande passante d'une connexion TCP à 0 :

Les objectifs de Jozsef pour ipset sont de passer les échanges userspace noyau dans un mode nfnetlink. Utilisant les mêmes fondements que les autres sous-systèmes de Netfilter, il pourra alors prétendre à l'inclusion dans la distribution officielle de Netfilter et donc dans celle du noyau. Selon toute vraisemblance, cela devrait se produire avant la deuxième moitié de l'année 2009.

Cette journée d'un bon niveau technique a rassemblé développeurs et utilisateurs dans une ambiance positive et détendue. Des échanges informels entre utilisateurs et développeurs ont eu lieu tout au long de l'événement.

3. Les journées développeurs

Les journées développeurs ont réuni une vingtaine de personnes venant d'un peu partout. Parmi les nations les plus représentées, c'est l'Allemagne qui arrive en tête avec 5 développeurs. La France est dans la moyenne avec 3 développeurs à égalité avec la Hongrie ou les États-Unis.

3.1 Évolution de Netfilter de septembre 2007 à 2008 (Patrick McHardy)

La première journée développeurs a commencé par une présentation de Patrick sur les évolutions de Netfilter au cours de l'année écoulée. Il nous a décrit dans le détail les changements majeurs intervenus.

3.1.1 2.6.24

Le noyau Linux 2.6.24 a apporté quelques fonctionnalités intéressantes comme l'inclusion du module de filtrage time qui fait ce que son nom indique. Déjà disponible comme extension depuis longtemps, il fait maintenant partie de la branche officielle.

La couche ctnetlink responsable des interactions entre le suivi de connexion et l'espace utilisateur a connu des évolutions intéressantes. En premier lieu, il est devenu possible de créer des connexions relatives à la volée. Plus anecdotique, mais bon à savoir, l'identifiant numérique unique d'une connexion a été supprimé. Cela peut toutefois poser des soucis pour identifier une connexion, mais un entier moins strict (boucle possible) a été mis en place.

Le suivi de connexions se voit lui ajouter du code pour supporter la défragmentation en IPv6. Ceci achève le support d'IPv6 au niveau de Netfilter.

3.1.2 2.6.25

Ce noyau apporte bon nombre de changements. On notera principalement un accroissement des performances au niveau du conntrack grâce notamment à l'utilisation de RCU au lieu d'utiliser de simples lock. Le gain de performance est notable, Jesper Dangaard a ainsi observé une baisse de 25% de la charge CPU sur ses pare-feu. Parmi les autres modifications, on peut citer la réécriture du module de suivi de connexion pour SIP qui semble maintenant ne plus avoir de défauts majeurs ou l'ajout du module RATEEST qui réalise des filtres sur les débits (en paquets ou bytes par seconde). Ce dernier module est particulièrement utile pour le partage de charge.

Du côté de ctnelink, 2.6.25 apporte le support du filtrage des événements de connexions en espace noyau. On peut ainsi choisir de transmettre (et donc répliquer avec conntrackd) uniquement les connexions TCP.

3.1.3 2.6.26

L'amélioration principale de ce noyau concerne le support de la traduction d'adresse pour des protocoles rares comme UDP-LITE, SCTP, DCCP.

3.1.4 2.6.27

L'ajout principal de ce noyau est une nouvelle table dédiée à SELinux. Elle permet de gérer le contexte de sécurité des paquets de manière indépendante des outils de filtrage standard. L'utilisation de SECMARK et CONNSECMARK supposait en effet d'ajouter des règles iptables dans la table mangle, règles iptables qui pouvaient entrer en conflit avec les règles posées par d'autres outils.

Le suivi de connexions TCP se voit amélioré par l'incorporation d'un patch permettant de terminer de manière plus rapide (5 min) une connexion où des paquets n'ont pas été confirmés par le pair. Ceci permet de passer outre le délai de destruction standard (au bout de 5 jours) des connexions TCP. La dernière nouveauté concerne le support de SCTP par ctnetlink.

L'impression globale de Patrick McHardy est que le développement s'est focalisé sur des détails au lieu de porter sur des modifications du cœur de Netfilter comme l'an dernier. Les choses semblent donc en meilleur état.

3.2 Nftables (Patrick McHardy)

Le morceau de bravoure de cette sixième convention Netfilter a indéniablement été la présentation de Nftables par Patrick McHardy. Iptables et Netfilter souffrent de limitations que Patrick McHardy a voulu dépasser. Il a donc engagé le travail énorme de réécrire Netfilter. La durée de la présentation a été à la hauteur du travail, puisqu'elle a duré toute une après-midi.

3.2.1 Les problèmes Iptables et Netfilter

Iptables souffre de certains problèmes. Le point le plus critique concerne la gestion des modifications de règles où un dump complet du jeu de règles est réalisé à chaque appel d'iptables. Ceci entraîne évidemment un coût important. Moins critique, mais gênant pour l'utilisateur, le code de balayage des options d'iptables n'est pas dans le cœur du programme, et introduit des incohérences dans le fonctionnement de l'outil en ligne de commande. Une autre limitation fréquemment citée est l'existence d'une seule cible par règle : cela suppose une copie des règles et des changements dupliqués (par exemple, utilisation de LOG + DROP ou MARK + ACCEPT).

Au niveau de Netfilter, certaines parties ont un trop faible niveau d'abstraction. Par exemple, les gestions des filtres sur les ports TCP et UDP ne partagent pas de code. Le paramétrage statique des modules cibles entraîne des multiplications de code, comme l'option de la cible qui est toujours propagée sous forme de constante. Il n'est pas possible d'utiliser la variable de manière plus souple. Cela a conduit à la construction de modules spécifiques comme IPMARK, IPCLASSIFY, et pourrait amener à un module TCPPORTCONNTRACK. S’il avait été possible d'indiquer dynamiquement quel champ modifier et avec quelle méthode, un seul module aurait suffit.

3.2.2 Un peu de bien sur Iptables

Iptables dispose d'un grand nombre de critères et d'une classification très flexible. Il s'interface parfaitement avec les fonctionnalités connexes au filtrage comme le partage de charge, le routage multipath, la manipulation de paquets réseau. Les opérations internes sont rapides comparées à celles de TC et il est aisé d'ajouter de nouvelles extensions. Cependant, ces extensions sont à la source de la mauvaise qualité des modules externes. Iptables a ses propres classificateurs et n'est pas capable, à l'inverse de tc, d'utiliser u32 qui est très puissant, mais difficile à utiliser. Iptables ne supporte pas non plus BPF (Berkeley Packet Filter utilisé par tcpdump et libpcap) qui est totalement programmable. Il pourrait donc être intéressant de disposer d'une syntaxe similaire à celle des classificateurs de Linux et BPF.

3.2.3 Principes et aperçu de Nftables

Pour fixer le problème du coût de modification du jeu de règles, il est souhaitable d'utiliser Netlink pour réaliser des changements incrémentaux du jeu de règles, et une remontée des modifications. En mettant en place un système de multicibles, les extensions pourraient renvoyer un verdict arbitraire pour orienter les flux dans des sous-chaînes. Les cibles devraient être paramétrables à la volée et durant leur fonctionnement.

Nftables est découpé en trois composants, une implémentation noyau, un frontal nftables en espace utilisateur, une bibliothèque libnl chargée des interactions bas-niveau avec le noyau.

La syntaxe du frontal utilisateur ressemble à celle de BPF. Un exemple basique est par exemple :

La syntaxe est flexible, puisque l'on peut aussi écrire :

La puissance de Nftables s'exprime sur la définition et l'utilisation d'objets composés :

Les impressions de l'auditoire à la suite de cette présentation marathon de Patrick McHardy ont été unanimes. Comme énoncé par David Miller, la qualité du code produit tant du côté architecture que du coté réalisation est exceptionnelle (alors que le projet est très jeune). En termes de fonctionnalités et d'utilisation, les changements entraînés seront importants. Cependant, compte tenu de l'ampleur de la tâche, une date pour l'abandon de la couche actuelle n'est pas encore prévue.

3.3 Xtables-addons (Jan Engelhart)

3.3.1 Les problèmes de Patch-o-matic

Patch-o-matic est un système qui gère l'ajout d'un ensemble de fonctionnalités pour Netfilter et pour iptables. Il présente des problèmes de qualité, car le code est souvent centré sur une architecture (les contributions sont souvent des réponses à des problèmes individuels). Patch-o-matic contient en fait des patchs pour le noyau et pour iptables. Il s'appuie donc directement sur les sources du noyau. Les extensions doivent être mises à jour à chaque changement dans l'API. La pire chose est que, le code devant supporter plusieurs versions du noyau, il y a un usage massif des compilations conditionnelles de gcc (#ifdef) dans le code.

3.3.2 Principe et apport de Xtables-addons

Xtables-addons ne s'appuie sur aucun patch et n'a besoin que des en-têtes du noyau pour compiler. Une couche d'API supplémentaire a été ajoutée pour s'abstraire des dépendances sur les versions du noyau, et le code spaghetti. Le code des fonctionnalités supplémentaires est alors développé au-dessus de l'API de Xtables-addons et n'a pas besoin d'être modifié suivant la version du noyau.

Xtables-addons contient quelques-unes des extensions les plus intéressantes qui existent dans patch-o-matic :

- condition : filtre selon un drapeau modifiable en espace utilisateur. En écrivant dans une entrée dans /proc, on décide si une condition est vérifiée ou non.

- geoip : filtre de correspondance sur les pays.

- TEE : « reroute » une copie du paquet.

- TARPIT : fait tendre le débit d'une connexion vers 0, ce qui peut-être utile pour compliquer la vie de certaines personnes (lire par exemple spammeurs).

- DELUDE : réalise la négociation de sessions TCP et ferme la connexion. Il est par exemple utilisable pour faire croire aux scanners que tous les ports sont ouverts.

Dans la discussion suivant la présentation, il a été décidé de supprimer patch-o-matic de l'arbre subversion. Xtables-addons va devenir le dépôt officiel pour les fonctionnalités non officielles du projet.

3.4 MIPv6 (Yasuyuki Kosakai)

Yasuyuki Kosakai est à l'origine du support d'IPv6 dans Netfilter. C'est ce travail qui lui a valu d'être nommé dans la coreteam du projet. Son œuvre est maintenant quasiment complète et le seul travail restant est sur Mobile IPv6 ou MIPV6.

MIPv6 est la couche d'IPv6 gérant la mobilité. Il s'agit d'un mécanisme extrêmement complexe qui permet à une machine de garder son IP alors qu'elle passe d'un réseau à un autre. Une redirection des flux est assurée de manière transparente en utilisant 2 modes. La première possibilité repose sur un tunnel IPSEC bidirectionnel. Tous les flux passent par le réseau d'origine (appelé « Home »). La deuxième solution est basée sur une optimisation du routage vers cette IP.

Dans les deux cas, cela conduit à une problématique de définition des tuples (couple IP:port) du conntrack. Le conntrack doit en effet être construit pour gérer ce problème. Deux choix sont possibles. Ou nf_conntrack_ipv6 construit les tuples par adresse Home ou 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 cependant facile d'envoyer des paquets comportant une fausse adresse Home (c'est un simple champ IP supplémentaire). Ainsi, le filtre à états peut laisser passer le paquet forgé si les paramètres de contrôle ne sont pas inspectés.

La proposition de développement est la suivante. Le nouveau module de suivi de connexion 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, puisque l'on ne peut plus parser la signalisation. Or, 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.

3.5 Panorama de bibliothèques et d’outils (Pablo Neira)

Pablo Neira a réalisé un panorama de l'état des bibliothèques et des outils en espace utilisateur. La moitié des bibliothèques présentent deux API (libnfnetlink, libnetfilter_conntrack). La nouvelle API permet une meilleure gestion des erreurs. Les bibliothèques libnetfilter_queue et libnetfilter_log n'ont presque pas évoluées en un an.

L'évolution principale est celle de libnetfilter_conntrack. La nouvelle API est basée sur une logique d'envoi/réception et propose un nombre appréciable de fonctions helper (afficher, comparer, copier). L'évolution principale en termes fonctionnels est arrivée avec la dernière version. Elle introduit un filtre BSF (Berkeley Socket Filter) 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 événement de connexion pour localhost. Il est ainsi possible de limiter le nombre d'événements envoyés depuis le noyau vers l'espace utilisateur. Il s'en suit un accroissement des performances des logiciels utilisant la bibliothèque, puisqu'ils ne traitent plus de messages inutiles.

3.6 Ulogd2 (Éric Leblond et Pierre Chifflier)

Lors du précédent workshop en septembre 2007, j'avais indiqué mon souhait de reprendre le développement de ulogd2 qui avait été abandonné par Harald Welte. Un travail tant d'enrichissements fonctionnels que de stabilisation a été mené au cours de l'année 2008. Il a notamment conduit à l'introduction de nouveaux schémas de bases de données qui ont été présentés à l'assemblée par Pierre Chifflier (voir article sur ulogd2 pour une description).

Les buts fonctionnels ont presque tous été atteints et le seul module dans un état instable est IPFIX (export Netflow des données). La coreteam décide donc que moyennant conclusion sur le sujet IPFIX, une sortie d'une nouvelle version stable de ulogd2 est envisageable après une période de stabilisation et d'observation du code.

4. Résultats

En dehors des quelques présentations détaillées ici, la courte présentation de Tproxy a été une des plus importantes. Après quatre ans d'efforts, l'inclusion de tproxy dans Netfilter et dans Linux a enfin été réalisée. Elle l'a d'ailleurs été en direct, puisque David Miller, présent dans la salle, a intégré les patchs dans son arborescence git 10 minutes après la fin de la présentation.

La sixième convention Netfilter aura été très dense sur le point technique. Mais l'organisation avait néanmoins aménagé des moments de détentes. Ce fût notamment le cas lors d'une croisière dînatoire sur un bateau mouche privatisé pour le groupe. À cette occasion, des goodies dont un tablier « Netfilter hackers like to cook fish » ont été offerts par INL aux participants.

Références

- Présentations de la journée utilisateur : http://nfws.inl.fr/?p=83.

- Description de nftables par Patrick McHardy : http://people.netfilter.org/kaber/weblog/2008/08/20/.

- Xtables-addons : http://jengelh.medozas.de/projects/xtables/.

- Draft IETF mip6 ipsec : http://tools.ietf.org/html/draft-ietf-mip6-cn-ipsec-05.