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.
