Pablo Neira et les conntrack-tools

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
41
Mois de parution
avril 2009
Domaines


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

 



Articles qui pourraient vous intéresser...

Monter son lab virtuel avec Kali Linux et VulnHub sous VirtualBox

Magazine
Marque
Linux Pratique
HS n°
Numéro
50
Mois de parution
février 2021
Domaines
Résumé

Dans cet article, nous allons mettre en place un virtual lab, un environnement de travail virtuel. Cet environnement vous permettra de créer, exécuter et détruire à volonté des VM vulnérables. Tout ceci sera fait dans un réseau virtuel, que nous allons créer, afin que ces machines vulnérables ne soient pas exposées sur Internet ni même sur votre réseau LAN, et éviter qu’un pirate puisse les retourner contre vous. Votre machine d’attaque sera également une machine virtuelle, sous Kali Linux, afin de ne pas utiliser votre machine de tous les jours pour vous connecter aux machines vulnérables, pour les mêmes raisons de sécurité. Kali Linux sera dans le réseau virtuel protégé pour pouvoir communiquer avec les VM vulnérables, et aura une carte réseau supplémentaire pour pouvoir accéder à Internet, être mise à jour, etc.

Netcat, l’histoire d’un couteau suisse pour le réseau

Magazine
Marque
Linux Pratique
Numéro
123
Mois de parution
janvier 2021
Domaines
Résumé

Lier le monde de l’administration système et celui du réseau n’est pas chose aisée, ni donné à tout le monde. De nombreux outils présents issus du monde de l’open source essaient désespérément d’y trouver une place. L’un d’entre eux a par ailleurs une longueur d’avance. Permettant de jouer avec la création de socket sur la couche transport du modèle OSI, Netcat rayonne dans le monde underground depuis déjà de nombreuses années. Rien de tel qu’une petite histoire pour parler de ce programme légendaire...