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.

Les derniers articles Premiums

Les derniers articles Premium

Petit guide d’outils open source pour le télétravail

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

Ah le Covid ! Si en cette période de nombreux cas resurgissent, ce n’est rien comparé aux vagues que nous avons connues en 2020 et 2021. Ce fléau a contraint une large partie de la population à faire ce que tout le monde connaît sous le nom de télétravail. Nous avons dû changer nos habitudes et avons dû apprendre à utiliser de nombreux outils collaboratifs, de visioconférence, etc., dont tout le monde n’était pas habitué. Dans cet article, nous passons en revue quelques outils open source utiles pour le travail à la maison. En effet, pour les adeptes du costume en haut et du pyjama en bas, la communauté open source s’est démenée pour proposer des alternatives aux outils propriétaires et payants.

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

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

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Bash des temps modernes

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

Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

Présentation de Kafka Connect

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

Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

Les listes de lecture

9 article(s) - ajoutée le 01/07/2020
Vous désirez apprendre le langage Python, mais ne savez pas trop par où commencer ? Cette liste de lecture vous permettra de faire vos premiers pas en découvrant l'écosystème de Python et en écrivant de petits scripts.
11 article(s) - ajoutée le 01/07/2020
La base de tout programme effectuant une tâche un tant soit peu complexe est un algorithme, une méthode permettant de manipuler des données pour obtenir un résultat attendu. Dans cette liste, vous pourrez découvrir quelques spécimens d'algorithmes.
10 article(s) - ajoutée le 01/07/2020
À quoi bon se targuer de posséder des pétaoctets de données si l'on est incapable d'analyser ces dernières ? Cette liste vous aidera à "faire parler" vos données.
Voir les 132 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous