Pablo Neira et les conntrack-tools

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
41
Mois de parution
avril 2009
Spécialité(s)


Résumé

Pablo Neira Ayuso est l'initiateur des logiciels conntrack-tools et membre de la coreteam Netfilter depuis 2007. Il évoque dans cette interview par mail son travail et ses motivations.


Body

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 :

tcp      6 431978 ESTABLISHED src=192.168.3.176 dst=1.2.3.4 port=33974 dport=4129 packets=3889 bytes=623952 src=1.2.3.4 dst=2.4.5.6 sport=4129 dport=45944 packets=3887 bytes=339242 [ASSURED] mark=0 secmark=0 use=1

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

# cat /proc/net/ip_conntrack

tcp      6 431989 ESTABLISHED src=192.168.1.129 dst=80.248.214.47 sport=56532 dport=5222 packets=115 bytes=16982 src=80.248.214.47 dst=192.168.1.129 sport=5222 dport=56532 packets=122 bytes=36045 [ASSURED] mark=0 secmark=0 use=1

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

# conntrack -L

udp      17 28 src=192.168.1.129 dst=212.27.40.241 sport=39502 dport=53 packets=1 bytes=65 src=212.27.40.241 dst=192.168.1.129 sport=53 dport=39502 packets=1 bytes=125 mark=0 secmark=0 use=1

tcp      6 431960 ESTABLISHED src=192.168.1.129 dst=80.248.214.47 sport=56532 dport=5222 packets=113 bytes=16730 src=80.248.214.47 dst=192.168.1.129 sport=5222 dport=56532 packets=120 bytes=35941 [ASSURED] mark=0 secmark=0 use=1

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 :

conntrack -U -s 192.168.1.129 -d 212.27.40.241 -p tcp --dport 5222 --sport 56532 -t 20 -u FIXED_TIMEOUT

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 :

conntrack -D -s 192.168.1.129 -d 212.27.40.241 -p tcp --dport 5222 --sport 56532

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

Pouvez-vous vous présenter et nous dire comment vous avez découvert Linux ?

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

 

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.

Quand avez-vous connu Netfilter ? Quand avez-vous décidé de vous investir dans ce projet ?

J'ai commencé à utiliser les logiciels libres du projet Netfilter lors de ma carrière dans le privé. Lorsque, en 2003, j'ai commencé à envoyer des petites contributions et des hacks, cela a été intéressant d'avoir des retours des autres, et ce, même lorsque le hack initial était très expérimental. J'ai été invité à rejoindre la Coreteam Netfilter en 2007. Depuis lors, je passe une partie de mon temps libre à la maintenance, la publication de nouvelles versions et à coder sur le projet.

Quelle question vous énerve-t-elle le plus sur une liste de discussions ?

Aucune en fait. Les questions ne sont pas un problème pour moi. Je pense que ce qui m'ennuie vraiment ce sont les attitudes inflexibles et non coopératives.

Vous êtes l'initiateur des conntrack-tools. Comment avez-vous décidé de démarrer le projet ?

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.

 

conntrack-tools-full

 

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.

Quel est l'état actuel du projet ?

La dernière version (0.9.10 au moment de l'interview) est en bon état. Les fonctionnalités souhaitées sont développées et il est maintenant temps de recevoir des retours et d'attendre quelques rapports de réussite avant de pouvoir sortir la 1.0.

Pouvez-vous nous en dire plus sur le mode actif-actif ?

La configuration active-active est indépendante des conntrack-tools. Elle se paramètre en utilisant iptables.

Mon environnement de test, qui est composé de deux pare-feu en cluster haute-disponibilité utilisant un réseau Gigabit, est capable dans la configuration actif/passif de filtrer jusqu'à 21000 connexions TCP par seconde (sur du matériel limité et peu coûteux) en réalisant du filtrage à état et de la translation d'adresse. Avec le filtre « cluster » et d'autres accessoires, la configuration actif/actif peut filtrer jusque 30000 connexions TCP par seconde, ce qui signifie un gain de 45% en termes de performance. La chose la plus importante ici est qu'il n'y a pas de perte de ressources comme dans une configuration actif/passif, puisque les deux pare-feu filtrent. Basiquement, l'approche est un partage de charge basé sur une table de hachage, ce qui est différent d'un partage de charge, puisque le partage n'est pas nécessairement équilibré.

45% de performance en plus, c'est exceptionnel !

C'est probablement plus en choisissant bien le matériel et le jeu de règles, mais je préfère être prudent avec les nombres. Je ne sais d'ailleurs rien des limites de passage à l'échelle en termes de nombre maximal de pare-feu.

Comment se positionne les conntrack-tools par rapport à pf-sync ou nf-sync ?

Bon, il me faut un tableau. Je pense tout de même que je devrais enquêter un peu plus pour être certain de toutes les informations :

 

 

pf-sync

nf-sync

conntrackd

Support de liens dédiés multiples

Oui*

Non

Oui

Réplication des états garantie

Non

Oui**

Oui

Implémentation

Noyau

Noyau

Espace utilisateur

Réplication sélective***

Non

Non

Oui

(*) Je ne suis pas sûr de l'approche suivie par pf-sync, car je pense que si on paramètre un ensemble de liens pour propager les changements d'états, ils envoient tous les changements d'états. Conntrackd envoie seulement les mise à jour à un périphérique à la fois, même s’il y a plusieurs liens dédiés dans l'installation. Si un lien a des problèmes, il bascule alors sur un autre.

(**) nf-sync est censé utilisé un système d'acquittement, mais il souffre de limitations sévères.

(***) nf-sync et pf-sync autorisent seulement la réplication d'état en temps réel souple (il me semble pour pf-sync). Conntrackd supporte un mode batch et un mode temps réel depuis la version 0.9.10.

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

 



Article rédigé par

Par le(s) même(s) auteur(s)

10 ans de Suricata

Magazine
Marque
MISC
Numéro
100
Mois de parution
novembre 2018
Spécialité(s)
Résumé

Pas besoin d’avoir fait des lettres LA Teen pour savoir que 10 ans est une étape importante. Le projet commencé en 2008 par Victor Julien sous le nom de VIPS pour Victor’s IPS a bien changé. Son évolution fonctionnelle témoigne de la transformation des menaces et les techniques de sécurisation du développement utilisées sont la preuve des progrès réalisés dans ce domaine.

Nftables, une révolution dans le pare-feu Linux

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
76
Mois de parution
janvier 2015
Spécialité(s)
Résumé

Après 10 ans d'une domination implacable sur le monde des pare-feu open source, iptables est sur le point d'être remplacé par nftables. Les développeurs de Netfilter ont choisi de revoir leur copie et proposent un nouveau système de filtrage en rupture avec l'existant. Quelles sont leurs motivations et qu'apporte nftables par rapport à son vénérable ancêtre ?

Les derniers articles Premiums

Les derniers articles Premium

Quarkus : applications Java pour conteneurs

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Initié par Red Hat, il y a quelques années le projet Quarkus a pris son envol et en est désormais à sa troisième version majeure. Il propose un cadre d’exécution pour une application de Java radicalement différente, où son exécution ultra optimisée en fait un parfait candidat pour le déploiement sur des conteneurs tels que ceux de Docker ou Podman. Quarkus va même encore plus loin, en permettant de transformer l’application Java en un exécutable natif ! Voici une rapide introduction, par la pratique, à cet incroyable framework, qui nous offrira l’opportunité d’illustrer également sa facilité de prise en main.

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 66 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous