Pablo Neira et les conntrack-tools

1. Introduction

1.1 Quelques mots sur le suivi de connexions

Le suivi de connexions de Netfilter ou conntrack est l'une des parties les plus importantes de Netfilter, puisqu'elle est responsable du filtrage à état (Voir [intro]). Ce sous-système de Netfilter a été introduit en même temps que le système dans le noyau 2.4.0. Le principe de fonctionnement du conntrack est le suivant : le noyau maintient une table contenant la liste de tous les flux passant à travers le pare-feu. Comme les paquets peuvent être modifiés lors des opérations de traduction d'adresses (NAT), le paquet arrivant sur le pare-feu peut être différent du paquet sortant de la machine. Il est donc nécessaire de stocker les deux valeurs. Ceci nous donne des entrées dans le suivi de connexions qui ressemblent à ceci :

Cette entrée indique que une connexion TCP de 192.168.3.176 vers 1.2.3.4 vers le port 4129 (port source 33974) a été translatée et est vue depuis l'extérieur comme une connexion TCP de 1.2.3.4 vers 2.4.5.6 vers le port 45944 (port source 4129). Cela peut sembler absurde, mais tout s'explique logiquement :

1. Les IP sont inversés : les deuxièmes coordonnées sont celles vues lors de la réception des paquets depuis l'extérieur. Cela est donc comparable à ce qui peut être vu dans un tcpdump.

2. Les ports, même inversés, ne correspondent pas : en effet, on a port destination 45944 et port source 33974 de l'autre côté. Il s'agit d'une contrainte technique : deux clients peuvent ouvrir des connexions depuis des ports égaux à destination du même service. Si l'on change seulement l'IP source, le serveur (ici à l'IP 1.2.3.4) recevra deux connexions avec les mêmes coordonnées. C'est impossible et il est donc nécessaire de décaler un des ports si nécessaire. Cette non-concordance peut aussi être liée à l'utilisation de la fonction de randomisation des ports qui empêche des logiciels comme Skype d'établir des connexions directes entre des machines translatées (voir [random]).

Malgré son importance fonctionnel et l'importance des données contenues, le système de suivi de connexions ne bénéficiait que d'une interaction limitée avec l'espace utilisateur.

1.2 Présentations des conntrack-tools

Pablo Neira Ayuso a donc initié un travail d'enrichissement des interactions avec le suivi de connexion au moment où une refonte globale des communications avec l'espace utilisateur était en œuvre (Voir [GLMF 86]). Ce travail a mené à une suite d'outils, les conntrack-tools, transformant complètement la façon d'envisager le suivi de connexions. Ce projet comporte deux logiciels, conntrack qui interroge et modifie le suivi de connexions et conntrackd capable de répliquer le suivi de connexions entre plusieurs machines.

L'utilitaire conntrack

Le programme conntrack est en charge d'interroger, de modifier ou de détruire des entrées du suivi de connexions. C'est un outil en ligne de commande qui peut, par exemple, remplacer la commande

en le lançant avec l'option -L :

J'entend d'ici les grincheux, mais c'est pareil, le résultat est le même. Sur le dernier point, ils n'auront pas tort, mais les mécanismes mis en œuvre sont bien différents. Lorsque l'on lit le fichier ip_conntrack, on interroge directement le module de suivi de connexions et on bloque tout trafic jusqu'à ce que l'on ait lu les données. Avec l'utilitaire conntrack, on envoie un message au noyau demandant un dump des connexions. Le noyau génère un message et l'envoie au processus appelant. Il n'y a donc pas ou très peu de blocage.

Là où conntrack devient intéressant, c'est lorsque l'on décide d'agir sur le conntrack. Prenons par exemple, la deuxième connexion listée lors de la commande précédente. Elle a un timeout de 431960 (soit environ 5 jours). Ceci signifie que, en l'absence de paquets reçus sur cette connexion, elle sera détruite après ce timeout. Par contre, si un paquet passe et est attribué à cette connexion, le timeout est repassé à 5 jours. Supposons que l'on désire que la connexion soit détruite au bout d'un temps fixe (pour interrompre un téléchargement juste avant la fin par exemple). Pour ce faire, il suffit d'utiliser l'option -U :

D'autres opérations sont possibles comme le changement de la marque de connexion. Cette modification est intéressante, puisqu'elle peut entraîner un changement de file de qualité de service pour les paquets de la connexion. Il est donc ainsi possible de modifier la qualité de service d'un flux au cours de son existence.

Vous me répondrez qu’une mort rapide et sans douleur est bien plus directe. Pour cela, il faut utiliser l'option -D :

Attention, ici, il s'agit d'une mort dans le suivi de connexions. Si le jeu de règle autorise la reprise à chaud de connexions, il est possible que la connexion soit recrée et donc que le flux ne soit pas interrompu. Pour interdire toute reprise de connexion sur TCP, il faut être strict sur l'ouverture des connexions dans le jeu de règles et n'autoriser comme nouvelle connexion que des sessions commençant par un paquet SYN.

Le démon conntrackd

Conntrackd est un démon de réplication du suivi de connexions. C'est un outil essentiel dans la construction de pare-feu résistant aux pannes. En répliquant le suivi de connexions, il est en effet possible de réaliser des pare-feu redondants sans perte de connexions lors d'une bascule.

Lorsque l'on passe d'un pare-feu actif à un autre, les flux routés par une machine sont alors brusquement routés par l'autre machine. Le filtrage avec suivi d'état du nouveau pare-feu actif reçoit donc des paquets issus de connexions déjà existantes. N'ayant jamais rien vu passer, le suivi de connexion du pare-feu perçoit donc les paquets comme des tentatives d'initialisation de connexion. Mais, ceux-ci n'ont pas les caractéristiques de paquets d'initialisation et ils sont donc bloqués par le pare-feu. Les utilisateurs perdent donc les sessions qui étaient en cours (et leurs données). Pour éviter ce problème, il y a deux solutions. Soit, on abandonne le filtrage à état, soit on réplique le suivi de connexion d'un pare-feu vers l'autre de manière à ce que, au moment de la bascule, le pare-feu nouvellement actif ait les informations nécessaires à une poursuite du service sans interruption.

Conntrack est une application qui utilise les mêmes mécanismes que l'utilitaire conntrack pour répliquer le suivi de connexion. Il utilise notamment un mécanisme d'écoute des événements qui lui permet de recevoir un message à chaque événement majeur (changement d'état, destruction) dans la vie de chaque connexion. Il établit alors un cache en local des informations du suivi de connexions et il les synchronise avec un pare-feu utilisant lui aussi le démon. L'utilisation de conntrackd ne nécessite pas beaucoup de configuration et la principale contrainte est le besoin d'utiliser pour des raisons de performances et de confidentialité un (ou plusieurs) lien dédié entre les pare-feu.

Conntrackd ne prend en charge que la réplication du suivi de connexion et il faut donc utiliser un logiciel classique de gestion de la redondance comme Keepalived ou Heartbeat pour assurer la détection des pannes et la bascule.

2. L'interview

J'ai commencé des études en Informatique en 1998, mais ce n'était pas mon premier contact avec le monde des ordinateurs. À l'age de 11 ans, en 1991, mon père avait acheté un Sinclair Spectrum 48k d'occasion pour ma mère (elle est physicienne et mon père a toujours pensé qu'une « personne intelligente » comme ma mère devait être en contact avec l'informatique).

Heureusement pour moi, ma mère n'a jamais trouvé l'informatique intéressante. Cela m'a donné de passer de longues heures devant notre petit télé à programmer en BASIC sur cet ordinateur.

En 2002, un peu après l'écroulement de la bulle internet, j'ai commencé à travailler – tout en continuant mes études, ce qui est très difficile ! – pour quelques petites sociétés informatiques de ma région. J'étais consultant sécurité, développeur et administrateur système à temps partiel. Malgré cela, j'ai réussi à finir mes études d'informatiques. En 2005, j'étais sur le point de partir en France pour y faire une thèse pendant 3 ans quand j'ai eu la possibilité de rejoindre l'Université de Séville, ce que j'ai fait finalement. Depuis lors, j'y travaille comme professeur et chercheur.

 

 

Pablo Neira Ayuso

Je suis arrivé relativement sur le tard dans le monde de Linux. En 2001, un très bon ami m'a poussé à installer Linux et m'a motivé à passer des heures et des heures en face de l'écran. La disponibilité complète du code source, et donc la chance de savoir, de première main, comment les choses sont réellement faites, a occupé tout mon temps libre, et probablement aussi une grande partie du temps que j'étais supposé passer à étudier.

Il y avait un patch qui ajoutait une interface Netlink au suivi de connexions. L'interface texte dans /proc était très limitée et ajouter de nouvelles fonctionnalités aurait été une bien piètre conception. J'ai donc décidé de récupérer le vieux patch et de le proposer au projet. Je pense que la principale raison pour laquelle j'ai décidé de travailler sur ce sujet était, si je me souviens bien, que je pensais que la place pour réaliser la synchronisation d'état était en espace utilisateur et non en espace noyau, en utilisant un système de message comme netlink, et donc en suivant une conception de type micro-noyau.

 

 

Représentation du travail sur les conntrack-tools

Pour ceux qui ne sont pas familiers avec Netlink, il s'agit d'un protocole de communication entre les sous-systèmes du noyau et leurs contre-parties en espace utilisateur en utilisant une sémantique proche des sockets.

3. Conclusion

Grâce au travail de Pablo Neira Ayuso sur les conntrack-tools, Linux et Netfilter comblent l'un de leurs retards les plus importants sur la concurrence. Netfilter gagne là une fonctionnalité qui lui manquait pour s'imposer sereinement dans le monde de l'entreprise. Les récents travaux de Pablo portent sur les outils, modules noyau et modifications d'iptables et arptables, nécessaires à l'établissement facile de systèmes de pare-feu actif-actif performants. Les patchs sont en cours de validation et Netfilter devrait donc bientôt (vraisemblablement dans 2.6.30) avoir tous les outils nécessaires pour une redondance performante et simple à mettre en œuvre.

Références

Page des conntrack-tools : http://conntrack-tools.netfilter.org/

[intro] Introduction à Netfilter, voir page 20 dans ce numéro.

[random] http://software.inl.fr/trac/wiki/contribs/RandomSkype

[GLMF 86] Interaction avec l'espace utilisateur