En fait, l'état INVALID est un état par défaut dans lequel tout ce qui n'a pas été attrapé avant va.
Mais, comme tu le dis, on ne peut plus vraiment faire confiance à la documentation à ce niveau (elle est tout simplement fausse), cela nous oblige à lire le code. Et, comme le dit lui-même Linus:
Rusty? Help me out, and I won't ever call "netfilter"
a heap of stinking dung again. Do we have a deal?
-- Linus Torvalds
Ils génèrent un 'worst case' pour leur algorithme, de codage des regles pas pour iptables.
Mais, cela fait ressortir l'impact qu'a le nombre de regles sur le firewall lui-même. La façon dont tout le monde résoud ce problème est avec un algorithme linéaire suivant le nombre de règles O(n), alors que l'on pourrait considérer un algorithme qui est en temps constant O(1).
Pour le DOS tu as raison, cependant le fait d'ajouter le fait d'avoir à enregistrer toutes les connections rajoute un usage de la mémoire (qui est présente en nombre limité dans le noyau), ce qui affaiblit d'autant plus le firewall. Si, à cela tu rajoute le fait que tu dois attendre une minute avant de retirer une connection qui s'est terminée normalement de la table des connections (bah oui, c'est ce que j'appelle le problème du 'man in the middle'. Comme le firewall est au milieu et qu'il ne doit rien assumer, il est possible que le dernier paquet se soit perdu et qu'il y ai une retransmission, donc on reste dans un état d'attente de time out de fin de connexion. Ce problème est inhérent à TOUTES les implémentations des stateful firewall).
Le fait que hi-pack puisse traiter un nombre de regles très important, n'est pas vraiment intéressant. Comme tu le dis très justement, c'est une abérration ... du moins dans l'environnement où ils ont testé leur outils (le nombre de regles sur les backbones est par contre très important, mais leur tests n'est pas cohérent avec cet environnement).
Non, ce qui m'intéressait de montrer c'est que Netfilter a des faiblesses étonnantes même sur un réseau si petit et avec une machine aussi puissante.
(qui plus est, je leur ai demandé quelques indications sur leur usage de la mémoire car je suspecte qu'ils en abusent un peu, à cause de l'algorithme qu'ils utilisent, mais je n'ai pas eu de réponse précise de leur part jusqu'à présent).
Lorsque tu regardes, par exemple, l'implémentation du 'connection tracking', le code de chaque module est très petit. De plus, ils implémentent une seule feature dispatchée sur plusieurs modules à la fois, ce qui est dangereux et rend le code plus difficilement lisible. Sans compter les problèmes de performance.
Pour la doc.
Je suis d'accord que la doc est toujours difficile à maintenir. Mais, le problème ici est qu'il n'est tout simplement pas possible de décrire ce qu'ils font sans entrer dans des détails techniques de programmation dont l'utilisateur ne devrait pas avoir à entendre parler. Je vais esquiver la question, mais disons que si ton paquet IP ne fait pas parti d'une connection déjà existante et qu'il a le flag ACK à '1', et que tu acceptes les paquets NEW sans autre rêgle, il va non seulement passer à travers ton firewall mais en plus, il va créer une entrée dans ta table de connection. Ce qui, en passant, détruit tout l'intéret d'avoir un stateful firewall, car si aucune précaution supplémentaire n'est prise, on peut toujours se faire scanner son réseau avec un ACK scanning.
Pour ce qui est de la taille du code...
Tu me dis de proposer une implémentation plus belle et plus sûre. Et bien, j'y travaille. J'ai déjà soumis un papier pour la partie "packet filtering" (voir: http://www.cs.auc.dk/~fleury/papers/CF-infocom2003-submitted.ps.gz(...)) et j'ai trois étudiants actuellement en projet qui implémentent une extension de l'idée originale qui pourra traiter aussi les 'stateful firewalls' de la même façon. Mais, implémenter un firewall n'est pas une mince affaire et cela prend du temps. Ils ont jusqu'à cet été pour finir leur projet et je compte bien les aider.
Ensuite, en ce qui concerne les attaques DOS. Comme je l'ai dit plus haut, l'implémentation de Netfilter du 'connection tracking' est biaisée et ne permet de toute façon pas de faire du stateful sans avoir à corriger le problème avec des regles supplémentaires.
Pour ce qui est d'une alternative au 'stateful', j'ai pas mal travaillé dessus. J'ai quelques idées pour améliorer l'existant (par exemple, l'évaluation du 'round-trip time' afin de minimiser l'effet du timeout), mais, hélas, rien qui permette d'espérer s'affranchir totalement des attaques DOS. :-/
Peut-être as-tu une idée géniale ? Si c'est le cas, cela m'intéresse. :-)
Quant tu dis que ces faits sont "évidents", cela me fait un peu tiquer. Nous avons, après un an de travail, formalisé la plupart des problèmes qui touchent les firewalls actuels, nous avons aussi apporté pas mal de solutions et nous avons quelques pistes supplémentaires qui sont prometteuses. Mais, cela m'a pris du temps et pas mal de travail, alors si tu trouves cela 'facile', il va falloir que je me reconvertisse au tricot. :-)
Il a visiblement été écrit par des gens qui n'entendent rien à la sécurité et qui n'ont pas été chercher dans les détails (or c'est dans les détails que se cachent les problèmes).
Tout d'abord, j'aimerai préciser un point.
Oui, je pense que les logiciels Open Source offrent une meilleurs garantie de sécurité.
Oui, je pense que la plupart des logiciels Open Source sont de bonne qualité.
MAIS, le fait qu'un logiciel soit Open Source ne garanti en rien, ni la sécurité, ni la qualité. Le fait que ces zozos de journalistes encensent les logiciels Open Source, ne me fera certainement pas perdre mon esprit critique et surtout lorsque cela concerne Netfilter!
Netfilter est mauvais, Netfilter est mal implémenté, Netfilter a un code illisible, Netfilter n'est PAS SUR ! Je fais beaucoup plus confiance à la famille BSD en ce qui concerne les firewalls qu'a Netfilter.
Trouvez vous normal que les simples fonctions de base d'un firewall imposent de charger une dizaine de modules ?
Trouvez-vous normal que leur implémentation du "Connection tracking" soit si mal faite qu'aucun utilisateur qui n'a pas connaissance du code ne sait ce qui se passe réelement lorsqu'on accepte les paquets 'NEW' ? (les docs ne sont d'ailleurs toujours pas à jour à ce sujet).
Trouvez-vous normal qu'un code qui se doit d'être minimum pour assurer une lisibilité parfaite pour en renforcer la sécurité dépasse allègrement les 20000 lignes ?
Et puis, finalement, j'en ai assez d'entendre que les firewalls dynamiques sont 'bons'. Les 'stateful' firewalls sont dangereux car ils rendent votre firewall sensible à une attaque DOS. Comme votre firewall est, par définition, votre seul point d'entrée de votre réseau. On peut aisément bloquer tout votre réseau, rien qu'en remplissant votre table de connections. J'ai fait des expériences en laboratoire de la tenue en charge de Netfilter, et je peux vous dire que c'est mauvais. Très mauvais. Qui plus est, même sans 'stateful' et dû à l'obésité du code, Netfilter est très lourd et prend beaucoup de ressource du noyau (voir les expériences proposées ici: http://www.hipac.org/(...)).
Bref, bref, bref, Open Source n'implique pas automatiquement Sécurité. Et plus précisemment en parlant de Netfilter...
Les actes prévus aux l° et 2° de l'article L. 122-6 ne sont pas soumis à l'autorisation de l'auteur lorsqu'ils sont nécessaires pour permettre l'utilisation du logiciel, conformément à sa destination, par la personne ayant le droit de l'utiliser, y compris pour corriger des erreurs. Toutefois, l'auteur est habilité à se réserver par contrat le droit de corriger les erreurs et de déterminer les modalités particulières auxquelles seront soumis les actes prévus aux l° et 2° de l'article L. 122-6, nécessaires pour permettre une utilisation du logiciel, conformément à sa destination, par la personne ayant le droit de l'utiliser.
II. - La personne ayant le droit d'utiliser le logiciel peut faire une copie de sauvegarde lorsque celle-ci est nécessaire pour préserver l'utilisation du logiciel.
III. - La personne ayant le droit d'utiliser le logiciel peut sans l'autorisation de l'auteur observer, étudier ou tester le fonctionnement de ce logiciel afin de déterminer les idées et principes qui sont à la base de n'importe quel élément du logiciel lorsqu'elle effectue toute opération de chargement, d'affichage, d'exécution, de transmission ou de stockage du logiciel qu'elle est en droit d'effectuer.
IV. - La reproduction du code du logiciel ou la traduction de la forme de ce code n'est pas soumise à l'autorisation de l'auteur lorsque la reproduction ou la traduction au sens du 1° ou du 2° de l'article L. 122-6 est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un logiciel créé de façon indépendante avec d'autres logiciels, sous réserve que soient réunies les conditions suivantes:
1° - Les actes sont accomplis par la personne ayant le droit d'utiliser un exemplaire du logiciel ou pour son compte par une personne habilitée à cette fin;
2° - Les informations nécessaires à l'interopérabilité n'ont pas déjà été rendues facilement et rapidement accessibles aux personnes mentionnées au l° ci-dessus;
3° - Et ces actes sont limités aux parties du logiciel d'origine nécessaires à cette interopérabilité.
Les informations ainsi obtenues ne peuvent être :
1° - Ni utilisées à des fins autres que la réalisation de 1' interopérabilité du logiciel créé de façon indépendante ;
2° - Ni communiquées à des tiers sauf si cela est nécessaire à l'interopérabilité du logiciel créé de façon indépendante;
3° - Ni utilisées pour la mise au point, la production ou la commercialisation d'un logiciel dont l'expression est substantiellement similaire ou pour tout autre acte portant atteinte au droit d'auteur.
V. - Le présent article ne saurait être interprété comme permettant de porter atteinte à l'exploitation normale du logiciel ou de causer un préjudice injustifié aux intérêts légitimes de l'auteur. Toute stipulation contraire aux dispositions prévues aux II, II et IV du présent article sont nulles et non avenues.
"M*rde, maintenant on (sous entendu nous autres les l33tz qui utilisont OpenBSD) va se taper des débutants qui ne vont pas lire les docs".
Je me souvient d'avoir vu exactement les mêmes réactions lorsque RedHat a introduit les premières interfaces graphiques pour l'installation de sa distribution...
Donc, pour les gars de Gobie: Continuez ! N'écoutez pas ces gens qui crient au scandale !!! :-)
Heu, j'était pas agressif quand j'ai écrit ma réponse! Je suis assez d'accord avec toi pour la sécurité d'un OS. Ce n'est pas l'OS qui fait la sécurité, mais le soin qu'on a à le rendre sûr. :-)
Et puis, tu as raison, le sens critique, il doit aussi s'appliquer ailleurs que sur Internet (les jounaux TV sont un excellent exemple, surtout si tu regardes CNN. :-).
Hop -> -1 parceque ce n'est pas très intéressant.
Je crois que tu comprends mal ma démarche. Il ne s'agit pas ici de "se rassurer". Il s'agit de séparer l'information objective de l'information imaginée (en gros, on refait le travail du "journaliste" qui a pondu cet article).
Sur Internet nous sommes soumis tous les jours à des quantités importantes d'informations, certaines sont vraies d'autres fausses. Ce que je cherche à démontrer ici, c'est que si quelqu'un qui se prétend journaliste pond un article sur Internet, il est possible de vérifier ses dires et de les corroborer avec d'autres sources.
Aller sur Internet et n'avoir aucun sens critique est dangereux. Et en disant cela, j'accuse autant ceux qui croient ce genre d'articles que ceux qui disent que c'est un tissu de mensonges parceque cela va à l'encontre de leurs "croyances", sans jamais prendre le temps de vérifier.
Bref, le problème de savoir si Linux est mieux que Windows au niveau de la sécurité n'est pas mon problème ici. Je voudrais juste pouvoir exhiber le fait que:
1) Le journaliste a menti, au moins par omission, en donnant un nombre de bugs sorti de nulle part.
2) N'importe qui, qui se donne la peine de chercher 5 minutes, peut le découvrir.
La morale de l'histoire étant que vous ne devez jamais quitter votre sens critique lorsque vous voyez des informations sur Internet. Que ce soit des informations qui vont dans le sens de ce que vous pensez ou qui contredisent vos croyances. Surtout, si les "journalistes" ne font plus leur travail correctement, en oubliant l'objectivité qui devrait être de rigueur.
Qui plus est, lorsqu'on accède à leur base de données (voir: http://www.iss.net/security_center/(...)) et qu'on tape "Linux", on obtient 2070 réponses. Alors que si on tapes "Microsoft", on obtient 2174 réponses (le mot clef "Windows" donne 3946 réponses, mais je n'ai pas le temps de vérifier qu'il n'y a pas de X-Windows dedans).
Donc, je me pose une question !
Où est ce rapport avec ces bugs/trojan, peut-on accèder à cette liste ? J'ai donc envoyé un mail à la branche commerciale de X-Force (sales@iss.net) pour savoir si je pouvais avoir accès à cette liste:
«X-Force, the US-based monitoring group of security software firm
Internet Security Systems, has been tracking the number of security
holes in software.
Last year the centre found 149 bugs in Microsoft software compared to
309 for Linux. This year the situation was worse, with 485 Linux bugs
this year compared to Microsoft's 202.
"Considering we're not yet in the fourth quarter this rate indicates
that 2002 will have twice as many Linux security bugs as 2001," said
Chris Rouland, director of X-Force.»
I would like to know if this list of bugs is accessible. I just tried
to look for these bugs through your database
(see: http://www.iss.net/security_center/(...)), but it doesn't match at all
with the article from Vnunet.com.
Thanks in advance for your reply.
=====
On verra bien ce que cela va donner. Mais je suis curieux de connaitre le résultat. ;-)
AMHA un "vrai" hacker ne se présente pas comme tel, qualifier un informaticien de hacker est un compliment, tout du moins c'est comme ça que je l'entends. Je ne dis JAMAIS que je suis un hacker, mais il est vrai que je ne peux m'empêcher d'avoir un petit sourire d'orgueil quand on me le dit. :p
Pour moi, ta phrase résume la définition que j'ai d'un hacker. Quelqu'un qui est considéré comme tel par ses pairs mais qui ne s'autoproclame pas 'hacker' comme le font les gens de "Hackerz Voice".
Je crois que le fait que les gens de Hackerz Voice soient des rigolos et le fait que les sites bancaires ne sont pas si sur que cela sont deux problèmes différents qui ne sont pas incompatibles.
Je suis assez d'accord avec toi, les banques se doivent de donner des garanties minimums lorsqu'elles ouvrent un service internet. De leur point de vue, mais aussi du point de vue de l'utilisateur.
Il serait d'ailleurs intéressant de savoir quels sont les devoirs de banques envers les usagers en matière de sécurité (je suis sûr qu'elles en ont).
Je me base seulement sur les articles qui sont sur leur site et ce que j'ai lu sur la description des cours.
J'extrapole surement un peu trop pour pouvoir en parler sérieusement, mais on est dans la tribune (et tu remarqueras que ma news est restée très soft par rapport à ce que j'en pense. :-).
C'est donc une nouvelle facile à trouver, relativement cadrée avec les sujets abordés ici, et avec une dose d'humour dedans (quand on connait les bestioles).
Je crois que l'humour est vraiment nécessaire pour aborder ce sujet, car l'humour seul t'empêche de basculer dans le dénigrement systématique de ces wanabe hackers.
Rien que sur leur page qui liste les cours, on trouve des choses ahurissante. Comme:
"Cryptanalyse : Le carré de vigenère"
Il faut savoir que le code de Vigenère est basé sur des substitutions/permutations qui fut introduite au 16me siècle. Rien qui ne puisse résister à une analyse statistique de base (la plus simple des cryptanalyse qui soit).
Personellement, je fais débuter la *vraie* cryptographie et cryptanalyse au code d'Énigma pendant la seconde guerre mondiale. Lorsqu'Alan Turing aidait le gouvernement britanique à casser ce code. Dans ce cas, la cryptanalyse commence à être intéressante, pas avant...
Le reste du niveau débutant semble revenir à utiliser des outils classiques de piratage. On apprends pas grand chose en utilisant des outils. On apprends en connaissant des protocoles et en les analysants... mais bon.
La formation Linux est à mourir de rire. Seul, le niveau débutant est détaillé et se borne (à nouveau) a faire un tour des logiciels courants. Ce n'est pas vraiment ce que j'attendrais d'une formation Linux pour des "hackers". Les bases de la programmation système aurait été un programme intéressant, mais bon l'hackademie semble avoir décidé que débutants = simple utilisateur (et pas programmeur).
Pour les autres niveaux, c'est pareil. On se diriger vers une formation d'ingénieur système classique (sans qu'ils ne rentrent dans les détails). Pas de programmation système !!!
Pour le reste, je dirais que si vous avez envie de prendre des cours d'info de seconde main auprès d'étudiants qui ont mal assimilé les bases, c'est là qu'il faut aller...
Non, sérieusement, on trouve de meilleurs formations au "hacking" dans les universités ou les IUT. La seule différence, c'est qu'elles ne portent pas l'étiquette "HACKERS" écrit en gros et en rouge et avec le <blink> en prime...
Je crois qu'ils développent le coté "hacker" par pur marketing. Le pire c'est que cela semble marcher.
Ce que je ne comprends pas, c'est qui achète ce magazine ? Qui va aux cours ?
J'avoue avoir une idée, mais franchement, cela me fait un peu peur...
En gros, je présage que les "consommateurs" d'une telle organisation sont des gamins en mal de sensations fortes qui veulent passer pour des rebelles face à la société...
À vrai dire, cette Hackademy me ferait bien rire, si cela ne donnait pas une images des vrais informaticiens (ceux que les gens appelent des "hackers" mais qui se disent eux-même "informaticiens") qui soit à des années lumières de la réalité.
Certe, l'image fait très "héro romantique", auto-formé, auquel rien ne résiste, qui sait ce que le grand publique ignore, qui se sent au-dessus des lois, solitaire, etc, etc. Mais, c'est néammoins très loin de la réalité.
La plupart des experts en sécurité, ou des programmeurs système que je connais ont fait l'université, ils respectent les lois, ne sont certainement pas solitaires et ont leurs limites.
Autant, lorsqu'il s'agit d'un film d'hollywood, je me dit: "Bon, ce n'est qu'un film." Autant, là, c'est pour de "vrai".
Bref, je suis partagé entre le "laissez les vivre", et le "enfonçons les un grand coup" pour éviter qu'ils n'entachent encore plus l'image des informaticiens. Dire qu'a un moment, ils s'appelaient eux-même "l'équivalent Français du CCC (Chaos Computer Club)".
D'après ce que dit Linus, la changement de numéro majeur se justifie lorsqu'on introduit une incompatibilité sur les binaires précédents.
Un peu comme lorsqu'on est passé de la libc à la glibc, ou encore comme pour gcc 2.x -> 3.x (car le code qui compilait avec le 2.x ne compilait plus avec le 3.x... remarquez, sans vouloir lancer de Troll, c'était aussi vrai d'une version à une autre, d'autant plus vrai en C++, mais bon...).
Ma question, c'est qu'est-ce qui a justifié le passage de 0.x vers 1.x et aussi de 1.x vers 2.x ?
ipchains et iptables sont en user-space, ils n'ont rien a voir avec le noyau. Ce sont juste des interfaces utilisateurs pour configurer son firewall.
Le seul truc qui change entre les deux, c'est que l'implémentation du firewall sous Linux a changé et est devenue Netfilter (ce qui n'est pas forcément une bonne chose, mais bon, ne lançons pas le débat!).
est-ce que les gars d'avant programmaient avec leur pied ?
La qualité du code transparait sur la stabilité et le nombre de bugs. Après tout, un programmeur ne fait qu'implémenter un algorithme. Il se trouve que les dernières avancées du kernel sont algorithmiques. De nouveaux algorithmes sont testés et marchent avec plus ou moins de succès.
L'implémentation, elle, reste toujours de la même qualité (je pense). Il est d'ailleurs très intéressant de noter que le grand nombre d'améliorations sur le noyau Linux est la conséquence directe du fait que Linux est Open-Source ! En effet, Linux est une sorte de "laboratoire" pour informaticiens qui peuvent tester leurs idées. Des fois bonnes, des fois mauvaises. Mais la plupart du temps, Linus filtre celles qui sont bonnes de celles qui sont mauvaises (excepté pour les problèmes avec la mémoire virtuelle).
Au passage, on peut remarquer que bon nombre de ces innovation viennent directement d'idées piochées chez les universitaires en 'computer science' ou en mathématiques.
Bref, ces dernières 'accélérations' est le fait de nouveaux algorithmes ou méthodes et comme l'a dit justement quelqu'un d'autre sur le forum, tout n'a pas encore été exploré... :-)
Il est d'ailleurs amusant de repenser à ce qu'avait dit Microsoft à un moment, les porte-paroles de cette firme prétendaient que l'Open-Source tuait l'innovation (à mon humble avis, c'est plutôt le contraire).
[^] # Re: --state NEW et Syn
Posté par Alan_T . En réponse à la dépêche La sécurité en Open Source. Évalué à 1.
Mais, comme tu le dis, on ne peut plus vraiment faire confiance à la documentation à ce niveau (elle est tout simplement fausse), cela nous oblige à lire le code. Et, comme le dit lui-même Linus:
Rusty? Help me out, and I won't ever call "netfilter"
a heap of stinking dung again. Do we have a deal?
-- Linus Torvalds
[^] # Re: Benchs et filtrage.....
Posté par Alan_T . En réponse à la dépêche La sécurité en Open Source. Évalué à 0.
Mais, cela fait ressortir l'impact qu'a le nombre de regles sur le firewall lui-même. La façon dont tout le monde résoud ce problème est avec un algorithme linéaire suivant le nombre de règles O(n), alors que l'on pourrait considérer un algorithme qui est en temps constant O(1).
[^] # Re: Non, non et non !
Posté par Alan_T . En réponse à la dépêche La sécurité en Open Source. Évalué à 1.
J'ai eu une discussion avec l'equipe de Netfilter sur la Netfilter devel mailing-list. Et, ils considèrent cela comme une 'feature'. Il parait que cela permet de rattraper les connexions pendantes après un reboot du firewall. Pour ma part, j'ai clairement dit que je trouvais cela dangereux, mais bon... (voir le thread:
http://lists.netfilter.org/pipermail/netfilter-devel/2002-June/thre(...)
Message Initial: http://lists.netfilter.org/pipermail/netfilter-devel/2002-June/0080(...)).
Pour le DOS tu as raison, cependant le fait d'ajouter le fait d'avoir à enregistrer toutes les connections rajoute un usage de la mémoire (qui est présente en nombre limité dans le noyau), ce qui affaiblit d'autant plus le firewall. Si, à cela tu rajoute le fait que tu dois attendre une minute avant de retirer une connection qui s'est terminée normalement de la table des connections (bah oui, c'est ce que j'appelle le problème du 'man in the middle'. Comme le firewall est au milieu et qu'il ne doit rien assumer, il est possible que le dernier paquet se soit perdu et qu'il y ai une retransmission, donc on reste dans un état d'attente de time out de fin de connexion. Ce problème est inhérent à TOUTES les implémentations des stateful firewall).
[^] # Re: Non, non et non !
Posté par Alan_T . En réponse à la dépêche La sécurité en Open Source. Évalué à 1.
Le fait que hi-pack puisse traiter un nombre de regles très important, n'est pas vraiment intéressant. Comme tu le dis très justement, c'est une abérration ... du moins dans l'environnement où ils ont testé leur outils (le nombre de regles sur les backbones est par contre très important, mais leur tests n'est pas cohérent avec cet environnement).
Non, ce qui m'intéressait de montrer c'est que Netfilter a des faiblesses étonnantes même sur un réseau si petit et avec une machine aussi puissante.
(qui plus est, je leur ai demandé quelques indications sur leur usage de la mémoire car je suspecte qu'ils en abusent un peu, à cause de l'algorithme qu'ils utilisent, mais je n'ai pas eu de réponse précise de leur part jusqu'à présent).
[^] # Re: Non, non et non !
Posté par Alan_T . En réponse à la dépêche La sécurité en Open Source. Évalué à 3.
D'abord, le nombre de modules.
Lorsque tu regardes, par exemple, l'implémentation du 'connection tracking', le code de chaque module est très petit. De plus, ils implémentent une seule feature dispatchée sur plusieurs modules à la fois, ce qui est dangereux et rend le code plus difficilement lisible. Sans compter les problèmes de performance.
Pour la doc.
Je suis d'accord que la doc est toujours difficile à maintenir. Mais, le problème ici est qu'il n'est tout simplement pas possible de décrire ce qu'ils font sans entrer dans des détails techniques de programmation dont l'utilisateur ne devrait pas avoir à entendre parler. Je vais esquiver la question, mais disons que si ton paquet IP ne fait pas parti d'une connection déjà existante et qu'il a le flag ACK à '1', et que tu acceptes les paquets NEW sans autre rêgle, il va non seulement passer à travers ton firewall mais en plus, il va créer une entrée dans ta table de connection. Ce qui, en passant, détruit tout l'intéret d'avoir un stateful firewall, car si aucune précaution supplémentaire n'est prise, on peut toujours se faire scanner son réseau avec un ACK scanning.
Pour ce qui est de la taille du code...
Tu me dis de proposer une implémentation plus belle et plus sûre. Et bien, j'y travaille. J'ai déjà soumis un papier pour la partie "packet filtering" (voir: http://www.cs.auc.dk/~fleury/papers/CF-infocom2003-submitted.ps.gz(...)) et j'ai trois étudiants actuellement en projet qui implémentent une extension de l'idée originale qui pourra traiter aussi les 'stateful firewalls' de la même façon. Mais, implémenter un firewall n'est pas une mince affaire et cela prend du temps. Ils ont jusqu'à cet été pour finir leur projet et je compte bien les aider.
Ensuite, en ce qui concerne les attaques DOS. Comme je l'ai dit plus haut, l'implémentation de Netfilter du 'connection tracking' est biaisée et ne permet de toute façon pas de faire du stateful sans avoir à corriger le problème avec des regles supplémentaires.
Pour ce qui est d'une alternative au 'stateful', j'ai pas mal travaillé dessus. J'ai quelques idées pour améliorer l'existant (par exemple, l'évaluation du 'round-trip time' afin de minimiser l'effet du timeout), mais, hélas, rien qui permette d'espérer s'affranchir totalement des attaques DOS. :-/
Peut-être as-tu une idée géniale ? Si c'est le cas, cela m'intéresse. :-)
Quant tu dis que ces faits sont "évidents", cela me fait un peu tiquer. Nous avons, après un an de travail, formalisé la plupart des problèmes qui touchent les firewalls actuels, nous avons aussi apporté pas mal de solutions et nous avons quelques pistes supplémentaires qui sont prometteuses. Mais, cela m'a pris du temps et pas mal de travail, alors si tu trouves cela 'facile', il va falloir que je me reconvertisse au tricot. :-)
# Non, non et non !
Posté par Alan_T . En réponse à la dépêche La sécurité en Open Source. Évalué à 10.
Il a visiblement été écrit par des gens qui n'entendent rien à la sécurité et qui n'ont pas été chercher dans les détails (or c'est dans les détails que se cachent les problèmes).
Tout d'abord, j'aimerai préciser un point.
Oui, je pense que les logiciels Open Source offrent une meilleurs garantie de sécurité.
Oui, je pense que la plupart des logiciels Open Source sont de bonne qualité.
MAIS, le fait qu'un logiciel soit Open Source ne garanti en rien, ni la sécurité, ni la qualité. Le fait que ces zozos de journalistes encensent les logiciels Open Source, ne me fera certainement pas perdre mon esprit critique et surtout lorsque cela concerne Netfilter!
Netfilter est mauvais, Netfilter est mal implémenté, Netfilter a un code illisible, Netfilter n'est PAS SUR ! Je fais beaucoup plus confiance à la famille BSD en ce qui concerne les firewalls qu'a Netfilter.
Trouvez vous normal que les simples fonctions de base d'un firewall imposent de charger une dizaine de modules ?
Trouvez-vous normal que leur implémentation du "Connection tracking" soit si mal faite qu'aucun utilisateur qui n'a pas connaissance du code ne sait ce qui se passe réelement lorsqu'on accepte les paquets 'NEW' ? (les docs ne sont d'ailleurs toujours pas à jour à ce sujet).
Trouvez-vous normal qu'un code qui se doit d'être minimum pour assurer une lisibilité parfaite pour en renforcer la sécurité dépasse allègrement les 20000 lignes ?
Et puis, finalement, j'en ai assez d'entendre que les firewalls dynamiques sont 'bons'. Les 'stateful' firewalls sont dangereux car ils rendent votre firewall sensible à une attaque DOS. Comme votre firewall est, par définition, votre seul point d'entrée de votre réseau. On peut aisément bloquer tout votre réseau, rien qu'en remplissant votre table de connections. J'ai fait des expériences en laboratoire de la tenue en charge de Netfilter, et je peux vous dire que c'est mauvais. Très mauvais. Qui plus est, même sans 'stateful' et dû à l'obésité du code, Netfilter est très lourd et prend beaucoup de ressource du noyau (voir les expériences proposées ici: http://www.hipac.org/(...)).
Bref, bref, bref, Open Source n'implique pas automatiquement Sécurité. Et plus précisemment en parlant de Netfilter...
Voila, mon coup de gueule du jour.
[^] # Re: Ben dis donc !!
Posté par Alan_T . En réponse à la dépêche Palladium, déjà dans vos assiettes. Évalué à 10.
I - (Loi. 94-361 , 10 mai 1994, art)
Les actes prévus aux l° et 2° de l'article L. 122-6 ne sont pas soumis à l'autorisation de l'auteur lorsqu'ils sont nécessaires pour permettre l'utilisation du logiciel, conformément à sa destination, par la personne ayant le droit de l'utiliser, y compris pour corriger des erreurs. Toutefois, l'auteur est habilité à se réserver par contrat le droit de corriger les erreurs et de déterminer les modalités particulières auxquelles seront soumis les actes prévus aux l° et 2° de l'article L. 122-6, nécessaires pour permettre une utilisation du logiciel, conformément à sa destination, par la personne ayant le droit de l'utiliser.
II. - La personne ayant le droit d'utiliser le logiciel peut faire une copie de sauvegarde lorsque celle-ci est nécessaire pour préserver l'utilisation du logiciel.
III. - La personne ayant le droit d'utiliser le logiciel peut sans l'autorisation de l'auteur observer, étudier ou tester le fonctionnement de ce logiciel afin de déterminer les idées et principes qui sont à la base de n'importe quel élément du logiciel lorsqu'elle effectue toute opération de chargement, d'affichage, d'exécution, de transmission ou de stockage du logiciel qu'elle est en droit d'effectuer.
IV. - La reproduction du code du logiciel ou la traduction de la forme de ce code n'est pas soumise à l'autorisation de l'auteur lorsque la reproduction ou la traduction au sens du 1° ou du 2° de l'article L. 122-6 est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un logiciel créé de façon indépendante avec d'autres logiciels, sous réserve que soient réunies les conditions suivantes:
1° - Les actes sont accomplis par la personne ayant le droit d'utiliser un exemplaire du logiciel ou pour son compte par une personne habilitée à cette fin;
2° - Les informations nécessaires à l'interopérabilité n'ont pas déjà été rendues facilement et rapidement accessibles aux personnes mentionnées au l° ci-dessus;
3° - Et ces actes sont limités aux parties du logiciel d'origine nécessaires à cette interopérabilité.
Les informations ainsi obtenues ne peuvent être :
1° - Ni utilisées à des fins autres que la réalisation de 1' interopérabilité du logiciel créé de façon indépendante ;
2° - Ni communiquées à des tiers sauf si cela est nécessaire à l'interopérabilité du logiciel créé de façon indépendante;
3° - Ni utilisées pour la mise au point, la production ou la commercialisation d'un logiciel dont l'expression est substantiellement similaire ou pour tout autre acte portant atteinte au droit d'auteur.
V. - Le présent article ne saurait être interprété comme permettant de porter atteinte à l'exploitation normale du logiciel ou de causer un préjudice injustifié aux intérêts légitimes de l'auteur. Toute stipulation contraire aux dispositions prévues aux II, II et IV du présent article sont nulles et non avenues.
Lu sur: http://www.alexander.tm.fr/newtech/An2000/Lex1.html(...)
Je ne sais pas si cette loi est encore valable. :-/
[^] # Re: Commentaires de GOBIE sur Deadly
Posté par Alan_T . En réponse à la dépêche GOBIE, un (potentiel) installateur graphique pour OpenBSD. Évalué à 10.
Je me souvient d'avoir vu exactement les mêmes réactions lorsque RedHat a introduit les premières interfaces graphiques pour l'installation de sa distribution...
Donc, pour les gars de Gobie: Continuez ! N'écoutez pas ces gens qui crient au scandale !!! :-)
[^] # Re: Creusons un peu...
Posté par Alan_T . En réponse à la dépêche 170 virus et chevaux de Troie pour Linux. Évalué à -1.
[^] # Re: Mon dieu je suis infecté !
Posté par Alan_T . En réponse à la dépêche 170 virus et chevaux de Troie pour Linux. Évalué à -1.
Hop -> -1
[^] # Re: Creusons un peu...
Posté par Alan_T . En réponse à la dépêche 170 virus et chevaux de Troie pour Linux. Évalué à 10.
Sur Internet nous sommes soumis tous les jours à des quantités importantes d'informations, certaines sont vraies d'autres fausses. Ce que je cherche à démontrer ici, c'est que si quelqu'un qui se prétend journaliste pond un article sur Internet, il est possible de vérifier ses dires et de les corroborer avec d'autres sources.
Aller sur Internet et n'avoir aucun sens critique est dangereux. Et en disant cela, j'accuse autant ceux qui croient ce genre d'articles que ceux qui disent que c'est un tissu de mensonges parceque cela va à l'encontre de leurs "croyances", sans jamais prendre le temps de vérifier.
Bref, le problème de savoir si Linux est mieux que Windows au niveau de la sécurité n'est pas mon problème ici. Je voudrais juste pouvoir exhiber le fait que:
1) Le journaliste a menti, au moins par omission, en donnant un nombre de bugs sorti de nulle part.
2) N'importe qui, qui se donne la peine de chercher 5 minutes, peut le découvrir.
La morale de l'histoire étant que vous ne devez jamais quitter votre sens critique lorsque vous voyez des informations sur Internet. Que ce soit des informations qui vont dans le sens de ce que vous pensez ou qui contredisent vos croyances. Surtout, si les "journalistes" ne font plus leur travail correctement, en oubliant l'objectivité qui devrait être de rigueur.
# Creusons un peu...
Posté par Alan_T . En réponse à la dépêche 170 virus et chevaux de Troie pour Linux. Évalué à 10.
D'abord X-Force existe bien:
http://xforce.iss.net/index.php(...)
Par contre, pas de trace de ce rapport qui mentionne les bug de Linux comparé à Windows:
http://bvlive01.iss.net/issEn/delivery/xforce/alerts.jsp(...)
Qui plus est, lorsqu'on accède à leur base de données (voir: http://www.iss.net/security_center/(...)) et qu'on tape "Linux", on obtient 2070 réponses. Alors que si on tapes "Microsoft", on obtient 2174 réponses (le mot clef "Windows" donne 3946 réponses, mais je n'ai pas le temps de vérifier qu'il n'y a pas de X-Windows dedans).
Donc, je me pose une question !
Où est ce rapport avec ces bugs/trojan, peut-on accèder à cette liste ? J'ai donc envoyé un mail à la branche commerciale de X-Force (sales@iss.net) pour savoir si je pouvais avoir accès à cette liste:
Hi,
I just read an article on Vnunet.com about Linux security
(see: http://www.vnunet.com/News/1135481(...))
I just quote from this article:
«X-Force, the US-based monitoring group of security software firm
Internet Security Systems, has been tracking the number of security
holes in software.
Last year the centre found 149 bugs in Microsoft software compared to
309 for Linux. This year the situation was worse, with 485 Linux bugs
this year compared to Microsoft's 202.
"Considering we're not yet in the fourth quarter this rate indicates
that 2002 will have twice as many Linux security bugs as 2001," said
Chris Rouland, director of X-Force.»
I would like to know if this list of bugs is accessible. I just tried
to look for these bugs through your database
(see: http://www.iss.net/security_center/(...)), but it doesn't match at all
with the article from Vnunet.com.
Thanks in advance for your reply.
=====
On verra bien ce que cela va donner. Mais je suis curieux de connaitre le résultat. ;-)
[^] # Re: Juste pour les enconcer un peu plus...
Posté par Alan_T . En réponse à la dépêche Hackerz Voice is back!. Évalué à -2.
Pour moi, ta phrase résume la définition que j'ai d'un hacker. Quelqu'un qui est considéré comme tel par ses pairs mais qui ne s'autoproclame pas 'hacker' comme le font les gens de "Hackerz Voice".
Commentaire personnel -> -1
[^] # Re: on y vient ...
Posté par Alan_T . En réponse à la dépêche "Passer a Linux" dans SVM. Évalué à 10.
La bonne nouvelle, c'est que des tas d'étudiants vont découvrir l'informatique sur Linux et plus sur Windows. :-)
[^] # Re: Savoir de quoi on parle
Posté par Alan_T . En réponse à la dépêche Hackerz Voice is back!. Évalué à 1.
Je suis assez d'accord avec toi, les banques se doivent de donner des garanties minimums lorsqu'elles ouvrent un service internet. De leur point de vue, mais aussi du point de vue de l'utilisateur.
Il serait d'ailleurs intéressant de savoir quels sont les devoirs de banques envers les usagers en matière de sécurité (je suis sûr qu'elles en ont).
[^] # Re: Intérêt ?
Posté par Alan_T . En réponse à la dépêche Hackerz Voice is back!. Évalué à 1.
J'extrapole surement un peu trop pour pouvoir en parler sérieusement, mais on est dans la tribune (et tu remarqueras que ma news est restée très soft par rapport à ce que j'en pense. :-).
[^] # Re: Intérêt ?
Posté par Alan_T . En réponse à la dépêche Hackerz Voice is back!. Évalué à 7.
Je crois que l'humour est vraiment nécessaire pour aborder ce sujet, car l'humour seul t'empêche de basculer dans le dénigrement systématique de ces wanabe hackers.
Rien que sur leur page qui liste les cours, on trouve des choses ahurissante. Comme:
"Cryptanalyse : Le carré de vigenère"
Il faut savoir que le code de Vigenère est basé sur des substitutions/permutations qui fut introduite au 16me siècle. Rien qui ne puisse résister à une analyse statistique de base (la plus simple des cryptanalyse qui soit).
Personellement, je fais débuter la *vraie* cryptographie et cryptanalyse au code d'Énigma pendant la seconde guerre mondiale. Lorsqu'Alan Turing aidait le gouvernement britanique à casser ce code. Dans ce cas, la cryptanalyse commence à être intéressante, pas avant...
Le reste du niveau débutant semble revenir à utiliser des outils classiques de piratage. On apprends pas grand chose en utilisant des outils. On apprends en connaissant des protocoles et en les analysants... mais bon.
La formation Linux est à mourir de rire. Seul, le niveau débutant est détaillé et se borne (à nouveau) a faire un tour des logiciels courants. Ce n'est pas vraiment ce que j'attendrais d'une formation Linux pour des "hackers". Les bases de la programmation système aurait été un programme intéressant, mais bon l'hackademie semble avoir décidé que débutants = simple utilisateur (et pas programmeur).
Pour les autres niveaux, c'est pareil. On se diriger vers une formation d'ingénieur système classique (sans qu'ils ne rentrent dans les détails). Pas de programmation système !!!
Pour le reste, je dirais que si vous avez envie de prendre des cours d'info de seconde main auprès d'étudiants qui ont mal assimilé les bases, c'est là qu'il faut aller...
Non, sérieusement, on trouve de meilleurs formations au "hacking" dans les universités ou les IUT. La seule différence, c'est qu'elles ne portent pas l'étiquette "HACKERS" écrit en gros et en rouge et avec le <blink> en prime...
Je crois qu'ils développent le coté "hacker" par pur marketing. Le pire c'est que cela semble marcher.
Ce que je ne comprends pas, c'est qui achète ce magazine ? Qui va aux cours ?
J'avoue avoir une idée, mais franchement, cela me fait un peu peur...
Il y a quelques photos sur leur site:
http://www.dmpfrance.com/visio.php(...)
En gros, je présage que les "consommateurs" d'une telle organisation sont des gamins en mal de sensations fortes qui veulent passer pour des rebelles face à la société...
À vrai dire, cette Hackademy me ferait bien rire, si cela ne donnait pas une images des vrais informaticiens (ceux que les gens appelent des "hackers" mais qui se disent eux-même "informaticiens") qui soit à des années lumières de la réalité.
Certe, l'image fait très "héro romantique", auto-formé, auquel rien ne résiste, qui sait ce que le grand publique ignore, qui se sent au-dessus des lois, solitaire, etc, etc. Mais, c'est néammoins très loin de la réalité.
La plupart des experts en sécurité, ou des programmeurs système que je connais ont fait l'université, ils respectent les lois, ne sont certainement pas solitaires et ont leurs limites.
Autant, lorsqu'il s'agit d'un film d'hollywood, je me dit: "Bon, ce n'est qu'un film." Autant, là, c'est pour de "vrai".
Bref, je suis partagé entre le "laissez les vivre", et le "enfonçons les un grand coup" pour éviter qu'ils n'entachent encore plus l'image des informaticiens. Dire qu'a un moment, ils s'appelaient eux-même "l'équivalent Français du CCC (Chaos Computer Club)".
# Hé, ho, c'est pas bientot fini, non ?
Posté par Alan_T . En réponse à la dépêche SuSE 8.1 officiellement sortie !. Évalué à 10.
Il y a une saison pour ça, ou quoi ?
[^] # Re: Linus est content
Posté par Alan_T . En réponse à la dépêche Bientôt le noyau Linux 3.0 ?. Évalué à 2.
D'après ce que dit Linus, la changement de numéro majeur se justifie lorsqu'on introduit une incompatibilité sur les binaires précédents.
Un peu comme lorsqu'on est passé de la libc à la glibc, ou encore comme pour gcc 2.x -> 3.x (car le code qui compilait avec le 2.x ne compilait plus avec le 3.x... remarquez, sans vouloir lancer de Troll, c'était aussi vrai d'une version à une autre, d'autant plus vrai en C++, mais bon...).
Ma question, c'est qu'est-ce qui a justifié le passage de 0.x vers 1.x et aussi de 1.x vers 2.x ?
Juste un peu d'histoire, quoi ! :-)
[^] # Re: C'est quoi une VM ?
Posté par Alan_T . En réponse à la dépêche Bientôt le noyau Linux 3.0 ?. Évalué à -1.
Cela veut dire : Vil Modéro :-)
Allez, hop -> -1
[^] # Re: Linus est content
Posté par Alan_T . En réponse à la dépêche Bientôt le noyau Linux 3.0 ?. Évalué à 2.
Le seul truc qui change entre les deux, c'est que l'implémentation du firewall sous Linux a changé et est devenue Netfilter (ce qui n'est pas forcément une bonne chose, mais bon, ne lançons pas le débat!).
[^] # Re: Génial !
Posté par Alan_T . En réponse à la dépêche Jouer à Quake dans son jardin ?. Évalué à -5.
Comment on fait pour effacer un message ?
[^] # Re: Génial !
Posté par Alan_T . En réponse à la dépêche Jouer à Quake dans son jardin ?. Évalué à -6.
Moi, je dis c'est possible ! Mais, seulement pour des vendeurs de la FNAC du rayon informatique, alors. :-)
[^] # Re: Génial !
Posté par Alan_T . En réponse à la dépêche Jouer à Quake dans son jardin ?. Évalué à 10.
Moi, je dis c'est possible ! Mais, seulement pour des vendeurs de la FNAC alors. :-)
[^] # Re: Ben dis donc !
Posté par Alan_T . En réponse à la dépêche Gestion de la mémoire virtuelle du noyau 2.5.x. Évalué à 10.
La qualité du code transparait sur la stabilité et le nombre de bugs. Après tout, un programmeur ne fait qu'implémenter un algorithme. Il se trouve que les dernières avancées du kernel sont algorithmiques. De nouveaux algorithmes sont testés et marchent avec plus ou moins de succès.
L'implémentation, elle, reste toujours de la même qualité (je pense). Il est d'ailleurs très intéressant de noter que le grand nombre d'améliorations sur le noyau Linux est la conséquence directe du fait que Linux est Open-Source ! En effet, Linux est une sorte de "laboratoire" pour informaticiens qui peuvent tester leurs idées. Des fois bonnes, des fois mauvaises. Mais la plupart du temps, Linus filtre celles qui sont bonnes de celles qui sont mauvaises (excepté pour les problèmes avec la mémoire virtuelle).
Au passage, on peut remarquer que bon nombre de ces innovation viennent directement d'idées piochées chez les universitaires en 'computer science' ou en mathématiques.
Par exemple pour le cas du scheduler, son inventeur a fait des études en math:
http://kerneltrap.com/node.php?id=336(...)
Bref, ces dernières 'accélérations' est le fait de nouveaux algorithmes ou méthodes et comme l'a dit justement quelqu'un d'autre sur le forum, tout n'a pas encore été exploré... :-)
Il est d'ailleurs amusant de repenser à ce qu'avait dit Microsoft à un moment, les porte-paroles de cette firme prétendaient que l'Open-Source tuait l'innovation (à mon humble avis, c'est plutôt le contraire).
http://people.redhat.com/drepper/(...)