Discussion :

[Pizza Royale]

Bonjour,

J'ai une application Windows de filtrage qui intercepte le trafic de la session en cours en utilisant un LSP (Layered Service Provider). Ca a l'avantage d'être performant (tout reste en user) et simple. J'ai regardé pour adapter le soft sur Linux, et à première vue là je suis obligé de passer par un module kernel NetFilter/LSM, ce qui pose un problème de performance et surtout de licence : les modules noyaux sont obligatoirement GPL et mon appli est commerciale.
Une suggestion ?

[adamo901]

Pourquoi ne pas jeter un coup d'oeil sur www.wireshark.org.
Il fonctionne très bien sous linux et offre sur son site un guide pour les développeurs.

Bonne chance

[bizulk]

J'ai plusieurs remarques :
_ Tout l'espace kernel linux est en license GPL. Mais ton application tourne en espace user donc tu n'as pas de problème de license tant que tu ne 'link' pas statiquement ton application avec une librairie de licence GPL.
_ D'après ce que j'ai lu (rapidement) ici http://www.linuxjournal.com/article/6451 NetFilter/LSM est une API de cryptographie qui n'a rien a voir avec ce que tu cherches.
_ Wireshark est un sniffer réseau comme apparament ton application. WireShark utilise la très connue libraire libpcap disponible sous Linux comme sous Windows. Jette un œil ici http://www.tcpdump.org/ tu as même un tutoriel pour développer avec cette librairie.
_ Heureusement que tu ne développes pas dans l'espace kernel de Windows

++

[tamiel]

Netfilter n'est pas une API de cryptographie ni LSM d'ailleurs.

[Pizza Royale]

libpcap à ma connaissance ne permet que la capture et non pas à proprement parler le filtrage. En plus c'est une api de très (trop) bas niveau.
L'idéal pour moi serait LSM, et en particulier les parties spécifiques aux sockets. J'y retrouve un peu de la souplesse des LSP sous Windows. N'empêche qu'un module qui exploite LSM doit obligatoirement être un module noyau, avec les contraintes propres à la GPL. avec le LSP, on intercepte les sockets juste *avant* le passage au kernel. Avec LSM, on est *déjà* dans le Kernel.

La moins mauvaise solution consiste sans doute à écrire un module LSM minimal en GPL qui re-balance tout ou presque en user qui fera l'essentiel du travail, mais ce n'est ni élégant ni efficace.

[thierry.chich]

Pourquoi n'utilises-tu pas les iptables, qui sont dans l'userspace ?

[Pizza Royale]

Pourquoi n'utilises-tu pas les iptables, qui sont dans l'userspace ?

Sauf erreur de ma part, les iptables sont dans le kernel (et donc également les modules d'extension), à part les outils d'administration qui sont eux dans le userspace.

[bizulk]

Autant pour moi je me suis trompé sur Netfilter et LSM, bien que je n'ai toujours pas cerné leur usage (pas de résultat google satisfaisant). cependant je reste convaincu que leur utilisation n'est pas la meilleure solution.
Tu dis que libpcap est une appli de trop bas niveau, mais développer en mode kernel reste à mon avis une tache hardue. Quelle est la distance entre ce que propose la libpcap et ce que tu souhaites ?

Non libpcap fais aussi du filtrage avec le 'Berkeley Packet filter' , tu peux le vérifier avec tcpdump qui passe ta chaine de filtrage à la lib.

Voir ce site http://www.linuxjournal.com/article/4659

[nicolas.sitbon]

Non libpcap fais aussi du filtrage avec le 'Berkeley Packet filter' , tu peux le vérifier avec tcpdump qui passe ta chaine de filtrage à la lib.

Non tu confonds, la chaîne de filtrage que tu passes n'est là que pour filtrer ce que tu analyses, et non pour filtrer les paquets qui remonte en user space (i.e ça n'est pas un firewall mais un simple analiseur réseau).

[bizulk]

Si tu entends par 'paquets analysé' = "paquets qui ont passé le filtres de la capture' alors je ne suis pas d'accord, au vu de l'article donnée en lien.

La libpcap permet de traduire une expression logique en langage BSP (Berkeley Packet filter) utilisé par une machine a état placée dans la chaine de traitement du paquet juste au dessus de sa réception (traitement de l'interruption par le pilote réseau de la carte), bien avant de passer le paquet dans l'espace utilisateur.

Je peux me tromper mais c bien ce que decrit l'article a mon avis.

[nicolas.sitbon]

Si tu entends par 'paquets analysé' = "paquets qui ont passé le filtres de la capture' alors je ne suis pas d'accord, au vu de l'article donnée en lien.

La libpcap permet de traduire une expression logique en langage BSP (Berkeley Packet filter) utilisé par une machine a état placée dans la chaine de traitement du paquet juste au dessus de sa réception (traitement de l'interruption par le pilote réseau de la carte), bien avant de passer le paquet dans l'espace utilisateur.

Je peux me tromper mais c bien ce que decrit l'article a mon avis.

Je crois qu'on pense tous les deux la même chose mais qu'on ne parle pas la même langue :
le filtrage dans libpcap, permet de filtrer (comme son nom l'indique) les informations à analyser et de dropper le reste, mais en aucun cas, le filtrage ne s'applique au kernel, c'est à dire qu'on ne peut empêcher des paquets de remonter avec libpcap, encore une fois, ça n'est pas un firewall.

[bizulk]

on ne peut empêcher des paquets de remonter avec libpcap, encore une fois, ça n'est pas un firewall.

OK

C'est sur avec libpcap on ne pourra maîtriser le flux des données comme on le ferait avec un firewall.
Cela explique pourquoi l'auteur de ce post trouvait cette librairie de "trop bas niveau" .

Je ne saurais quoi conseiller sans restriction de license.