Fragroute est l'implémentation des techniques d'évasion d'IDS décrites dans "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection", un document que je conseille à toutes les personnes interressées par les IDS de lire...
Aller plus loin
- fragroute (46 clics)
- le whitepaper (15 clics)
- la reponse sur bugtraq de Dragos (6 clics)
# Allez plus haut
Posté par nemerid . Évalué à 10.
En tout cas, je suis toujours extrêmement impressionné par ces hackers qui trouvent toujours des méthodes pour contourner les défenses. C'est vraiment le jeu du chat et de la souris.
[^] # Re: Allez plus haut
Posté par Denis Rampnoux . Évalué à 10.
Il est clair qu'un exploit demande toujours une mise à jour des softs de sécurités, sur ce point là, je suis d'accord.
Toutefois, concernant la 2e phrase, je pense qu'il faut moins être impressionné par les gens qui trouvent des failles dans des systèmes que par ceux qui concoivent des systèmes difficiles à pirater : programmer de manière fiable (par de débordement de buffer / architecture évolutive du code / ...) me semble beaucoup plus difficile que de trouver une faile sur un soft. Attention, je ne dis pas que trouver une faille est toujours trivial, qu'on ne me fasse pase dire ce que je n'ai pas dit.
[^] # Re: Allez plus haut
Posté par Dugland Bob . Évalué à -3.
[^] # Re: Allez plus haut
Posté par Denis Rampnoux . Évalué à 10.
Il est vrai que certains langages possèdent de nombreux atouts pour écrire des programmes corrects par construction
entre autres arrêter d'enseigner le C et le C++.Là, c'est peut-être un peu radical, ces deux langages sont à mon avis indispensables mais pas forcément là où on les utilisent aujourd'hui. Personnellement, je pense que sur des parties où la vitesse est critique, ces deux langages sont très bon mais ils n'apportent pas la fiabilité lors du développement, je pense qu'il ne faut pas être radical mais seulement utiliser les instruments là où ils sont efficaces
[^] # Re: Allez plus haut
Posté par gc (site web personnel) . Évalué à 5.
[^] # Re: Allez plus haut
Posté par Vivi (site web personnel) . Évalué à 1.
parce que le perl, bof bof
[^] # Re: Allez plus haut
Posté par toonsy . Évalué à 7.
[^] # Toujours plus haut
Posté par Moby-Dik . Évalué à 6.
On a déjà un environnement de développement, de loisirs et de communication tout intégré, qui est presque un OS à lui tout seul et auquel il ne manque plus qu'un noyau : Emacs !
Il suffit donc de réécrire le noyau Linux en Lisp :)
[^] # Re: Allez plus haut
Posté par kesako . Évalué à 10.
Exactement comme on demande a un etudiant en maitrise de math de trouver un theoreme.
Ou bien pour un ingenieur mecanicien, de concevoir sur le papier un moteur thermique complet.
Rappele toi bien que l'on a envoyé des hommes sur la lune en 1969. A cette epoque, on faisait 99% des calculs a la regle a calculer...
Il n'y a pas de limite a ce que peuvent faire des types intelligents pour peu qu'ils ne fasse que ca.
[^] # Re: Allez plus haut
Posté par Anne Onimousse . Évalué à 2.
Je crois t'exagère un peu là.
Ne le prends pas mal, mais dès fois je me demande si LinuxFr n'est pas un peu un repaire de gens qui répètent des clichés d'un ton assuré sur des sujets qu'il ne maitrisent pas. (Moi non plus je maitrise rien mais je le dis)
C'est vrai que pour les failles mathématiques dans le domaine de la cryptologie, ça demande effectivement en général pas mal de travail, et ça semble pouvoir être du niveau d'une thèse. J'avais lu un papier sur une attaque concernant SSH suivant une technique dite de l'oracle Breichenbacher, j'avais pas tout compris mais ça avait l'air impossible à appliquer en pratique cae il aurait fallu générer des millions de connexion sur le serveur. Par contre le gars qui a trouvé cela à probablement (car j'y connais rien) du mérite sur le plan mathématique.
Mais pour des failles comme les buffer overflow et les format string, remarquer qu'un programme plante quand j'entre un "AAAAAA..." ou un "%n%n%n%n..." quelque part ne fait pas de moi un Albert Einstein en puissance. Et ce genre de faille est bien plus fréquente que la précedente.
Pareil pour les failles de CGI qui nécessitent juste une connaissance basique des langages associés (Php, Perl, ...). Cela me donne parfois plus l'impression d'un lycéen qui essaye de se faire mousser sur BugTraq avec sa faille minable, que de l' "étudiant de haut niveau" dont tu parlais.
etudiant en maitrise de math de trouver un theoreme
Ou est-ce que tu a lu ça ? Et qu'est-ce que tu entends par un "thérorème", les maths consiste à faire des démonstrations, donc tout travail de matheux est un théorème.
Maintenant si tu parle d'un théorème suffisament intéressant pour être enseigné je crois que tu rève.
un ingenieur mecanicien, de concevoir sur le papier un moteur thermique complet
Dans mon école il y a avait pas de filière méca, mais ça me semble bien irréaliste comme projet de dernière année ton truc.
Je sais que la filière instru (Physique) faisait des petits compteurs, que la filière éléctronique avais fait un GBF=Générateur Basse Fréquence (comme ceux que l'on voit en TP d'éléc au lycée)
Rien d'aussi délirant que ce que tu raconte.
[^] # Re: Allez plus haut
Posté par kesako . Évalué à 0.
oh non ! c'est tres courant ! enfin c'etait,
parceque maintenant on prefere faire des etudes
tres poussees sur des parties des moteurs.
Va faire un tour dans les archives des grandes
ecoles ( art et metiers , pont, mines, centrale...)
un sujet d'examen d'agregation de mecanique c'esr de caluler
tous les engrenages d'une boite de vitesse en 8heures
A la main bien sur...
[^] # Re: Allez plus haut
Posté par Bruno Muller . Évalué à -5.
Sous des airs ou des faux semblants
J'ai cru que d'autres pas de danses
Me cacheraient aux yeux des gens
Je n'ai jamais suivi vos routes
J'ai voulu tracer mon chemin
Pour aller plus haut, aller plus haut
Ou l'on oublie ses souvenirs
Aller plus haut, aller plus haut
Se rapprocher de l'avenir
J'ai perdu tant de fois la trace
Des rêves pour lesquels je vivais
Je n'ai pas su te dire je t'aime
Seulement te garder
Il faut aussi dire ses doutes
Et les poser dans d'autres mains
Pour aller plus haut, aller plus haut
Et dessiner des souvenirs
Aller plus haut, aller plus haut
Et croire encore à l'avenir
Pour aller plus haut, aller plus haut
Et dessiner des souvenirs
Aller plus haut, aller plus haut
Et croire encore à l'avenir
Aller plus haut, aller plus haut
Se rapprocher de l'avenir.
--
Arena. Tina Arena.
# le chat et la souris
Posté par DAGAN Alexandre (site web personnel) . Évalué à 10.
Quelque par c'est normal, mais c'est à donner des cheveux blancs au responsables de la sécurité des différents réseaux informatiques...
La lutte est continue, mais c'est comme ça aussi que l'on s'améliore...
[^] # Re: le chat et la souris
Posté par Victor Vuillard . Évalué à 10.
Ce qui est dommage c'est plutot que les choses bougent vraiment qu'une fois que le probleme est vraiment la !
[^] # Re: le chat et la souris
Posté par Damien Raude-Morvan (site web personnel) . Évalué à 5.
Je ne veut pas généraliser mais il faut quand même être réaliste : tant qu'un problème n'est pas découvert par des petits futés, la société ne va pas investir pour résorber la faille. Ce serait contre toute logique : dire aux actionnaires que l'on va employé des geeks en + pour améliorer le prog alors que l'on ne peut même pas communiquer (marketing) la dessus...
[^] # Re: le chat et la souris
Posté par Annah C. Hue (site web personnel) . Évalué à 5.
Au contraire, une boite qui se veut sérieuse aurait tout intérêt à communiquer sur le sujet, genre "nous nous réagissons rapidement, en y mettant les moyens, pour que le client soit toujours protégé de manière optimale...".
# Free software vs Logiciel propriétaire
Posté par Amaury . Évalué à 10.
si ce problème touche effectivement plein d'IDS commerciaux, on va peut-être avoir une idée du temps de réaction de différents developpeurs d'IDS... et , au hasard, je dirais que les IDS Open Source vont réagir beaucoup plus vite que leurs "concurrents" commerciaux...
Ca serait bien d'avoir des stats concernant les délais de réaction, suivant le type de license. Dans le domaine des IDS, ne pas réagir à temps est extremmement grave. Et vu que pas mal de constructeur de boite noires (souvent à plusieurs centaines de KF) cassent du Snort à tout va, un soft comme fragroute permet d'avoir des arguments vérifiables pour mesurer l'efficacité d'un IDS...
[^] # Re: Free software vs Logiciel propriétaire
Posté par vjm . Évalué à 10.
Cependant ça m'étonne qu'on fasse tout une histoire de fragroute puisqu'il reprend des techniques datant de 98 qui avait justement introduit dans le monde des IDS et firewalls les termes stateful inspection ou tcp stream reassembly et ip defragmentation. Le tout refait (jusque dans le nom) ce que faisait l'outil de test fragrouter en y ajoutant des fonctions de proxy. Bref on dirait plus une réponse "hacker" aux méthodes de normalization de Vern Paxson qu'on retrouve dans pf d'openbsd, plutôt qu'une véritable évolution (je dis ça notamment à cause du "evade passive OS fingerprinting techniques"). En théorie, stream4, frag2 et les plugins applicatifs de snort resolvent ces problèmes depuis longtemps. Et c'est pareil pour tous les IDS. Si des issues n'ont pas été corrigé, elles seront surtout de l'ordre des overlaps ou des timeouts dont les valeurs et comportements sont spécifiques à chaque OS. Or l'IDS tout perfectionné qu'il soit ne peut pas prévoir le comportement des 2 extrêmités d'une transmission. Tout ce qu'on peut faire dans ce cas c'est demander à chaque administrateur de selectionner ses propres valeurs (comme ce sera ou est déjà le cas pour Prelude [1]).
Petit point personnel : en terme de qualité je prefère encore IP360 ou Dragon à Snort, et si je veux de l'open source en plus je vais voir chez Prelude...
[1] http://www.prelude-ids.org(...)
[^] # Re: Free software vs Logiciel propriétaire
Posté par Anne Onimousse . Évalué à 2.
Objectivement, je ne pense que pas que les softs Open-Source soit forcément à l'abris de ce genre de comportement càd cacher des failles ou prendre son temps pour corriger les bugs.
Ainsi, dans la réponse du développeur de Snort il explique qu'on lui avait envoyé la faille depuis plusieurs mois, mais qu'il ne s'étais pas pressé pour commiter le fix dans le CVS car il pensait qu'il ne serait dévoiler qu'à la prochaine conférence de sécu.
Sauf erreur de ma part, lors du bug d'openSSH, le bug à été fixé <i>en douce<i> dans le CVS longtemps avant que la faille ne soit annoncée.
Enfin, lorsque je lisais Bugtraq, j'avais parfois l'impression que les patchs des distribs étaient tout le temps à la bourre par rapport à l'annonce de la faille et que la Debian était souvent encore plus à la bourre que les autres (j'ai pas de statistiques mais c'est l'impression sincère que ça me donnais).
Je suppose que celà s'explique par le fait que la Debian a des ressource limitée (car elle ne repose sur des bénovoles), et que patcher des bugs n'est pas vraiment excitant donc ils ne doivent pas se bousculer au portillon.
Avec de l'argent on arrive toujours à motiver des gens pour faire un tel travail.
Enfin, toute chose étant égale par ailleurs, avoir le source est forçément une bonne chose, car celà peut te permettre de te faire une meilleure idée de la qualité du soft que tu veux acheter (si tu es capable de le lire, car lire le code d'un programme que tu n'as pas écrit est difficile à moins qu'il soit très propre).
[^] # Re: Free software vs Logiciel propriétaire
Posté par ceituna (site web personnel) . Évalué à 1.
un exemple ? La revue spécialisée "Télécoms & Réseaux"... Chaque mois, ils publient une "étudee sécurité" su les sytèmes de sécu... et leur conclusion est que Windows est beacoup plus sur qu'une GNU/Débian, car le premier n'a que 2 alertes sécu par mois, alors que Débian en a en moyenne 12-15 par mois...
Quand on pense que des décideurs prennent ensuite ces paroles pour évagnile...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.