Luc Stepniewski <[EMAIL PROTECTED]> writes: > > Deja apprendre a lire, c'est pas mal... > > mais bon, je vais repondre ici. > > Je te remercie :-) Desole, je n'aime pas le ton agressif que tu as pris dans ton commentaire. > > 1- Prelude est en developpement depuis plus de 2 ans, > > le developpement est sponsorise par Mandrake depuis > > quelques mois. > > Quelle est la signification du mot "sponsorisé" pour > MandrakeSoft ? Cela veut dire qu'il me paye entre autre pour bosser dessus. > > 2 - je ne connaissais pas Snort; donc je viens d'aller jeter un > > rapide coup d'oeil : > > C'est quand meme bizarre de ne pas connaitre Snort, etant donné > que c'est la référence en la matière de détection d'intrusion > sous Linux ! All people out there, do you ever heard about the Snort project ? > Sans parler des nombreuses conférences qui ont été > faites par Martin Roesch à différentes Expos (LinuxWorld, etc.). pas vu. > > effectivement, nous faisons la meme chose sur pas > > mal de point, > > Oui, c'est aussi ce que j'avais remarqué ! > > > maintenant, snort est incapable de gerer > > certaines choses complexe comme la fragmentation IP. > > Comme tu le dis, tu as juste jeté un coup d'oeil... Dans sa > version de développement, Snort supporte les paquets fragmentés. > Il était meme question, pendant un moment, d'utiliser libNIDS > pour la reconstruction des paquets. Mauvaise idee. Pour linux & bsd l'utilisation de netfilter est largement plus recommande, cela te branche *ou tu veux* dans la stack tcp ip. Cela evite notamment de dupliquer le travail du kernel. > Je suppose que tu ne connais pas non plus libNIDS, qui est un > "émulateur" de stack IP Linux. Tu peux avoir plus d'infos dessus > à l'URL suivante: http://www.packetfactory.net/, si ca t'intéresse. pas repertorie sur freshmeat, mais de toute facon, je ne l'utiliserais pas. J'utilise du code kernel pour ce genre de tache senssible... Et ce code sera toujours plus sure que d'utiliser des librairies qui n'ont pas ete autant teste que le kernel :) ( tu as lu la doc ? ) > Je te recommande de t'abonner à la mailing list de Snort, si > tu veux savoir vraiment où en est Snort. ok. > > je lis lightweight. > > je lis aussi designe pour monitorer de petit reseaux tcp / ip, > > Oui, tout à fait. C'est le texte qui a été ecrit aux débuts > de la conception de Snort. pas actualise ? > Mais il a été optimisé et fonctionne > très bien sur des réseaux dits 'moyens'. j'ai dit backbone. > Je peux te le dire, car > en tant qu'Ingénieur Sécurité et responsable sécurité de plusieurs > gros ISP français, pareil. > je l'ai installé pas mal de fois; et cela fonctionne > parfaitement. Oui, tu vas me dire qu'un réseau d'ISP ce n'est pas > un backbone, mais franchement, je crois que c'est plutot utopique > de faire tourner un soft de détection d'intrusion sur un backbone ! Bertrand ? :) ( je pense que tu peux repondre a celle ci ) non cela ne l'est pas. > Si un soft de détection marche sur une ligne ATM à 155 Mbits/s, > je serais VRAIMENT étonné ! il a ete concu pour cela; et fonctionne sur de simple celeron (+- 333Mhz 128 Mo ram ) floode avec des packets invalide ( erreur de fragmentations, erreur cksum, erreur d'options etc etc, chaque paquet spoofe avec une ip source differente (don tres dur pour les tables de cnx)). sur un reseau ether 100 Mo / s. > Et puis je ne vois pas trop l'intéret d'utiliser un logiciel de > détection d'intrusion sur un backbone. C'est pour protéger de > quoi ??? Des attaques... et oui, prelude sera capable de proteger dinamyquement les destinations de *certaines* ( celle dont il est sure ) attaques. > > ce qui n'est pas le cas de prelude ( prelude est designe pour > > tourner *aussi* sur des backbones et pour gerer d'autres > > protocoles que le tcp / ip. ) > > J'ai examiné ton code (récupéré de l'arborescence CVS), et > actuellement, il n'y a pas grand chose qui fait qu'il soit > "designé pour des backbones". Designe pour les backbones veut dire : - code extremement rapide. - Table / Arbre rapide de recherche de connection. - Stack memoire pour certaine parties du code. > En fait je comprend pourquoi tu > prévois ton code pour plusieurs machines: > En gros, d'après ce que j'ai compris, tu as une liste de modules > (en C, pas très pratique) Non, j'ai pas dit pratique. J'ai dit *performance*. Ensuite, un plugins va etre cree, qui parsera un fichier de description de quelque paquet ( fichier en Xml ), et qui analisera chaque packet pour voir s'il "matche". > qui sont exécutés les uns après les > autres, en linéaire (pas de threads ?). Surement pas, les threads apporte une surcouche de scheduling... scheduling qui est tres bien fait par le kernel. Il est prevu a terme que chaque plugins puisse etre executer independamment sur une machine d'un cluster. > Donc, pour un paquet, > tu exécutes tout un ensemble de modules, ce qui veut dire que > tu seras très vite limité dans le nombre de modules ajoutable, > puisque à chaque module que tu rajoutes, cela provoque un > ralentissement supplémentaire. Non. Cela ajoute un tour de boucle suplementaire + un appel de fonction. Donc cela n'est pas tres couteux. Pour le future, j'aimerais faire une reecriture dynamique du code executable dans la heap, et de mettre tout le code des functions des plugins au meme endroit. Cela donnera un seul tour de boucle. > Oui, j'ai vu que tu as un cache pour certaines fonctions, mais pas uniquement un cache, une base de donnee de connections accessible pour certains plugins. Ce type de base, est extremement complexe dans le sens ou cela peut prendre enormement de memoire sur des backbones / reseaux avec beaucoup de connections a la secondes Actuellement on commence a etre oblige de suprimer des connections au bout d'une minutes avec 2000 connections a la seconde. Au final le fonctionnement sera dans le meme style qu'une LRU ( least recently used ), avec une recherche dans un arbre AVL, ou une table de hash ( besoin de benchmark pour etre sur ). > cela ne servira à rien dans les cas de recherches de chaines, ce > qui est le cas le plus courant (regardes sur la base de données > d'intrusions de Snort sur http://dev.whitehats.com/ids/ids.html). Euh, rien a voir avec la stack. Les recherches de chaines seront faites avec un seul & meme module, qui aurra probablement de nombreuses optimisation pour la recherche de ces chaines. > La plupart des détections d'intrusion consistent à rechercher > des chaines de caractères caractérisant des attaques. Snort Non. Cela depend completement du type d'attaques que tu veux trouver. > utilise un arbre ce qui permet d'avoir plus de 600 patterns quel type d'arbre ? O(n) || O(1) ? > sans avoir quasiment aucun raletissement. C'est pas un probleme et comme je le dis, c'est prevus dans le cadre des opts. > > > Bon, etc etc. > > Si tu veux plus de detail, tu prend les 2 sources, > > tu les lis, et apres tu te permet de critiquer. > > C'est ce que j'ai fait. Je trouve que ta réaction est un peu > violente. Elle n'est absolument pas violente, ne t'attend pas a recevoir des fleurs quand tu balance une flame. > Si tu ne peux pas accepter les critiques, tu ne vas > pas aller vraiment loin... Je les acceptes depuis le debut du projet. A la difference que je n'accepte *que* les critiques intelligente, pas les critiques genre : "c'est de la merde & ca existe deja". > Concernant le fait que j'ai dit que Prelude est du vaporware, > c'était par rapport à l'annonce de MandrakeSoft. Je ne pense > pas que Prelude corresponde à l'annonce faite. Prelude n'a pas encore ete annonce, l'annonce etait pour libsafe. <quote> Yoann is a Security Specialist on the Mandrake team and is also spearheading the Prelude project. </quote> > Il n'y a pas > grand chose pour l'instant (un compteur de connexions et de > NOPs, une fonction de recherche de quatre chaines, conçue de > façon totalement inutilisable en production réelle, et une ^^^^^^^^^^^^^^^^^^^^^^^ Tout a fait daccord, les plugins actuels sont temporaire, c'est du test. > détection d'un DoS). Faudrais que tu comprennes que l'ont travail actuellement sur le 'core' de prelude, et sur la librarie... pas sur les plugins, De maniere a creer une API de fonctions ultra optimise & suffisament generique pour la detection de tous type d'attaque. > Si tu penses vraiment que Prelude est différent et a des buts > différents, continue à le développer, et j'espère que un jour > ce sera un superbe soft. merci :) > Sinon, pourquoi tout refaire de zéro, > alors qu'il existe déjà un meme soft. Ne pourrais-tu pas > participer au développement de Snort, comme je le fais ? Vu ce que tu me dis, ce n'est pas le cas. Nous n'utilisons pas le meme style de shema a un bas niveau, et personnellement, je prefere le miens. Ensuite, il n'y a pas que moi sur le developpement de prelude. > Il y a une différence entre le monde Linux vs le monde Micro$oft, > c'est que chez M$, il n'y a qu'un logiciel pour une fonction > donnée et meme s'il est nul au début, il se perfectionne au > fur et à mesure du temps. Dans le monde Linux, les gens ont > l'habitude de vouloir tout refaire à partir de zéro, ce qui > fait que l'on avance pas vraiment (ou très lentement), sauf > quand le gars qui fait le logiciel est un petit génie. Le > problème, c'est qu'il n'y en a pas beaucoup... Bon, je pense que tu te trompe. Ce qui fait la puissance / flexibilite d'un systeme unix est la puissance de chaque outil qu'il propose dans un contexte donne ( exemple simple : cat, sed, grep ) etc etc. > Regarde combien il y a de window managers (je ne dis pas que > ce n'est pas bien) identiques, avec plus ou moins les memes > fonctions. Chacun de ces développeurs s'est dit la meme chose, > qu'il ferait mieux, mais plutot que de prendre un peu de temps > pour participer à ce qui existe déjà (principe de base de > l'Open Source), ils ont préféré recommencer tout de zéro... Huuu, la majorite des windows manager sont different. Personnellement je trouve que ne pas reutiliser du code existant *&* concut dans le meme but est une connerie ( a part s'il y a une tres bonne raison ). > Bien sur, tu réponds si tu veux. bien sur que je repond :) -- -- Yoann http://prelude.sourceforge.net It is well known that M$ product don't make a free() after a malloc(), the unix community wish them good luck for their future developement.
