On y retrouvera les habituels arguments, à savoir d'une part la qualité des logiciels Open Source face aux logiciels propriétaires, et d'autre part, le manque d'intégration et d'interface centralisée entre les composants Open Source.
On y trouve aussi des exemples de sociétés ayant fait le choix des solutions ouvertes.
Aller plus loin
- Le dossier sur 01net (6 clics)
# Hé hé
Posté par logie tom . Évalué à 10.
L'article est plutot bien, mais reste ... disons .... assez basique. Ok, le développement libre ne garantit pas l'intégration des composants, mais le fait que les sources soient dispo permet à qui le veut de réaliser les adaptations nécessaires (et de les redistribuer, n'oublions pas). La, peut-être que certains ne jouent pas le jeu en prenant ce qui existe, et en oubliant qu'on peut l'adapter à ses besoins (ou en ne faisant pas l'effort de le faire), d'où ces critiques...
# En entreprise
Posté par DAGAN Alexandre (site web personnel) . Évalué à 10.
Encore une fois, L'OpenSource fait mieux que se défendre. Mais encore une fois, les entreprises sont trop souvent frileuses et optent pour des solutions de constructeurs.
Il faut dire que même si les solutions OpenSource ont un coût financier intéressant, beaucoup pensent que les compétences nécessaires à leur mise en oeuvre sont chère. Pas faux. Mais si on fait le bilan je reste persuadé que cela revient moins cher sur le moyen/long terme...
Quelqu'un aurait-il une étude permettant d'étayer/infirmer mes propos (Ca pourra me servir pour argumenter face aux décideurs pressés)...
[^] # Re: En entreprise
Posté par Guillaume Morin . Évalué à 10.
Comparaison de TCO entre Windows et GNU/Linux en PDF :
http://www.cyber.com.au/cyber/about/linux_vs_windows_tco_comparison(...)
Comparaison de prix entre Windows et GNU/Linux en PDF :
http://www.cyber.com.au/cyber/about/linux_vs_windows_pricing_compar(...)
[^] # Re: En entreprise
Posté par pasBill pasGates . Évalué à -1.
1) Aucune societe n'achete 250 copies de Windows XP et Office XP au prix magasin, il y a de gros rabais.
2) Je vois mal comment on peut prendre Office XP et OpenOffice et les mettre sur le meme pied. Office XP offre bien plus que OpenOffice et facilite le travail dans nombre de domaines, de meme Gimp et Photoshop(en passant, ils auraient pu prendre Gimp pour Windows si ils avaient voulu faire une comparaison equivalente...)
3) Ils ne prennent pas en compte les couts de formation, car c'est con pour Linux, mais l'enorme majorite des gens est habitue a Windows et Office, pas a Linux et OpenOffice, et c'est a prendre en compte aussi meme si Linux n'y peut rien.
4) Exchange / Outlook ont des fonctions calendrier/meeting/... tres evoluees qu'il est possible de realiser sous Linux au prix d'un certain boulot, et ce boulot n'est pas comptabilise ici, sans cela, il suffit de prendre le serveur SMTP livre avec Windows 2000, il peut faire le boulot.
Bref, ca vaut pas grand-chose cette etude.
[^] # Re: En entreprise
Posté par Toufou (site web personnel) . Évalué à 10.
2) Office qui facilite, c'est une affirmation de completement subjective et gratuite. Quand les gens sont passés à Word à mon boulot actuel (et a celui d'avant), ils ont râlé (ils râlent encore) que c'était moins bien que Wordperfect. Ce n'est qu'une question d'habitude. Pour GIMP sous windows, clair qu'il reste encore beaucoup à faire.
3) N'importe quoi, les gens sont habitués à ce qu'ils avaient avant. Ici nous avons des problèmes d'adaptation avec les passages de Office 97 à Office 2000. Je n'ose pas imaginer le délire que ce serait si on passait sous Win/Office XP. Et je ne parle même pas des problèmes de migrations des applis office. Alors pour ce qui concerne la formation: c'est la même pour passer d'une version à une autre de MS Office que pour passer de MS Office à OpenOffice.
4) Exchange je ne sais pas mais les fonctions de calendrier / netmeeting et autres, je n'ai jamais vu personne les utiliser (à mon boulot et dans mes anciens boulots). Pour cela on utilise des soft Web de workgroup et ça marche quelque soit l'OS. De plus, le SI nous demande de ne pas utiliser outlook pour des raisons de sécurité.
Il y a deux utilisateurs d'informatique pour moi:
- les utilisateurs de logiciels non tournés vers l'informatique: pour eux, windows macos ou linux, c'est du pareil au même, ce qu'ils veulent c'est que ça réponde à leurs besoins. Unix propose à l'utilisateur une abstraction des concepts informatiques (pas de notion bizarre de lecteur, pas de voisinage réseau, etc...) qui correspond à ce que ce type d'utilisateur recherche. Il reste du travail au niveau des applications 'non informatiques' mais ce qu'on a déjà convient à 90% de ces utilisateurs.
- les autres utilisateurs qui sont les informaticiens en général: dans ce cas, j'espere pour eux qu'ils ont (ou qu'ils acquerissent) les connaissances nécessaires à la réalisation de leurs projets et qu'ils ne cliquent pas sans comprendre.
[^] # Re: En entreprise
Posté par Guillaume Morin . Évalué à 5.
Ce que tu dis m'intéresse au plus haut point. Nous devons opter pour une solution sécurisée et fiable en ce qui concerne la messagerie de notre société, et j'hésite en ce moment entre trois possibilités :
Je n'ai pas le temps de développer la dernière solution, et m'orientais donc vers la deuxième, mais ce que tu dis a attisé ma curiosité. Pourrais- tu me donner de plus amples renseignements en ce qui concerne votre système de messagerie?
A-t-il les mêmes fonctionnalités (emplois du temps par ex) qu'exchange ou lotus? Y a-t-il un système anti virus ? Fait-il le café? etc.
[^] # Re: En entreprise
Posté par Sébastien Munch . Évalué à 3.
[^] # Re: En entreprise
Posté par Olivier . Évalué à 2.
Quant à l'antivirus, il existe plusieurs solutions, mais je ne connais sous Linux que Viruswall de Trendmicro (dont les labs font preuve d'une bonne réactivité pour ce qui est des mises à jour des signatures)
[^] # Re: En entreprise
Posté par pasBill pasGates . Évalué à -2.
Les templates/macros qui sont possibles dans Office, l'integration avec Outlook et autres,... facilitent la vie des gens et rendent le travail plus rapide. Dans une boite de 10 personnes personne n'utilise ces trucs car c'est plus efficace que faire 3 pas dans le bureau d'a cote, mais quand t'as 250 personnes ca devient tres vite tres tres utile. D'autre part Office ca comprend aussi Access, Project,... softs qui n'ont pas d'equivalent avec OpenOffice.
Les habitudes, c'est un fait tres clair. Les gens sont TOUS habitues a Windows car ils ont ca chez eux, l'ont vu a l'ecole,... Tu leur mets Linux, ils sont perdus et ils ont peur, meme si c'est pas forcement plus complique a la base, tout simplement car c'est tres different.
Passer de Office 97 a 2000 ca cree des emmerdements pour certains, donc imagine si tu mets Linux a des gens habitues a Windows.
Si les fonctions calendrier/meeting/... sont inutiles, donc il n'y a aucune raison d'acheter Exchange, ils n'ont qu'a utiliser le serveur SMTP livre avec Windows 2000 --> encore une fois ils faussent le prix.
Sinon, nous on n'utilise que ca chez MS pour organiser les meetings, c'est 20x plus rapide que telephoner aux gens et leur demander quand ils sont libres, choisir la salle, etc...
[^] # Office...
Posté par Benoît Michaux . Évalué à 5.
apportent surtout plein de virus !
Pas grand monde sait les utiliser ici, sinon...
"D'autre part Office ca comprend aussi Access, Project,... softs qui n'ont pas d'equivalent avec OpenOffice."
Ya d'autres trucs en Open Source pour ça.
Je connais pas bien, mais j'ai entendu parler de:
"MrProject" et "Toutdoux" pour remplacer Project.
Et, euh... Ca sert à quoi Access ?
C'est pas un truc pour faire des requetes basiques?
"Les gens sont TOUS habitues a Windows"
Le nombre de fois que j'ai entendu des personnes se plaindre qu'il ne s'y habitueront jamais... :-)
Les gens connaissent Windows(en général 9x) et Word(une seule version), mais pas Access, Project et les autres. Pour ce genre de logiciels, une formation est obligatoire.
Je ne pense pas que le passage à Linux soit plus douloureux que de passer à Office XP.
En passant, les fonctions calendrier/meeting/ est la principal utilisation d'Outlook ici.
Ya quoi comme alternative cote Linux et Open source?
Yelf
[^] # Re: Office...
Posté par Toufou (site web personnel) . Évalué à 1.
C'est pas un truc pour faire des requetes basiques?
Non, ironies mises à part et pour l'avoir pas mal utilisé, je te dirais que c'est nickel pour des bases de données monopostes, avec un schéma simple (2/3 tables) et pour lesquelles tu as besoin d'une interface graphique simple et vite faite.
En libre, on a les moteurs de BD qui remplacent avantageusement celui pourri d'access (plein de fonctionnalités buggées). Par contre je serais heureux de savoir ce qui pourrait être l'équivalent libre (si possible portable) de la partie VBA / formulaires. Ca me permettrait de migrer des applications d'acces 97 vers un truc plus pérenne et stable.
[^] # Re: En entreprise
Posté par Toufou (site web personnel) . Évalué à 1.
Pour les templates, pourquoi pas... Mais les macro c'est du développement et ce n'est pas l'utilisateur lambda qui va les faire (d'ailleurs heureusement pour lui).
l'integration avec Outlook et autres
Je n'ai jamais vu quelqu'un utiliser Word et Outlook simultanément. Au mieux j'ai vu les gens taper un mail sous Word (pour le correcteur orthographique alors qu'il est dans Outlook je crois) et copier / coller dans le client mail.
Dans une boite de 10 personnes ...
Là ou je bosse le service fait 100/150 personnes (dont une dizaine d'informaticiens ou apparentés) et la boite fait 2000 personnes.
Les gens sont TOUS habitues a Windows...
Oui et non. Hier soir j'ai installé un windows à un utilisateur de windows depuis win 3.11. Il ne sait toujours pas se servir des 'intégrations' dans MS Office (qu'il utilise depuis la version 4.2). Crois moi, ce n'est pas un cas isolé: je connais plein de gens (jeunes / vieux) qui ne savent pas qu'on peut faire tourner plusieurs applis en même temps sur leur ordi, alors un glisser déplacer d'Excel à Word... Les gens sont certes habitués à utiliser Windows / MS Office mais ils ne savent certainement pas s'en servir pour autant.
Donc quand tu dis que ça leur fait peur de passer à autre chose: oui, tout autant que de changer de version de MS Office (chat échaudé craint l'eau froide) mais dire que c'est plus rapide, plus facile etc... c'est ressortir le discourt de la brochure commerciale.
Passer de Office 97 a 2000 ca cree des emmerdements pour certains, donc imagine si tu mets Linux a des gens habitues à Windows.
A mon avis les mêmes problèmes pas plus ni moins: dans les deux cas les utilisateurs sont perdus et râlent parce qu'on leur change leurs habitudes.
Sinon, nous on n'utilise que ca chez MS pour organiser les meetings
Pour répondre aussi à HaraKn, à mon boulot on utilise un truc qui s'appelle QuickPlace. Ce n'est pas un soft de messagerie mais de workgroup et ça nous suffit largement pour organiser les réunions (ce n'est pas son role principal). Je n'en sais pas plus, je suis juste utilisateur épisodique du bidule :).
[^] # Re: En entreprise
Posté par Toufou (site web personnel) . Évalué à 4.
Le prob etant que cette etude ne vaut pas grand chose.
beh, c'est une étude sur la rentabilité des systèmes informatiques, faut pas s'attendre à de la valeur :)
# faire gaffe aux sources !!
Posté par PLuG . Évalué à 10.
le dernier en date: sendmail 8.12.6
ca va pas faire de la bonne pub a force, peuvent pas blinder un peu leurs serveurs FTP ou quoi ??
http://www.cert.org/advisories/CA-2002-28.html(...)
http://www.sendmail.org(...)
VERIFIEZ BIEN AVEC PGP TOUT CE QUE VOUS TELECHARGEZ ...
[^] # Re: faire gaffe aux sources !!
Posté par ewasx . Évalué à 3.
[^] # Re: faire gaffe aux sources !!
Posté par PLuG . Évalué à 5.
les checksum MD5 ne sont pas suffisants puisque faciles a "mettre a jour" pour le pirate.
[^] # Re: faire gaffe aux sources !!
Posté par David Pradier . Évalué à 1.
Evidemment, ce n'est pas suffisant, et ça peut se contourner, mais c'est un filtre supplémentaire.
Mes .02 euros
# Sécurité en Open Source
Posté par Gilles . Évalué à 1.
Aussi pour les IDS, NetProwler permet également de définir ses propres signatures, tout comme SNORT.
[^] # Re: Sécurité en Open Source
Posté par PLuG . Évalué à 5.
-je ne comprends pas le "cas particulier" qui est fait sur les ICMP. Je m'explique: impossible de faire une regle de NAT sur les ICMP, et les autres regles (filtrage) gèrent les ICMP au petit bonheur la chance. Pour un produit phare c'est mal (tm).
Après tout ICMP est "over IP" et devrait etre traité comme TCP et UDP.
-les VPN: la moitié des settings sont sur l'objet FW (ou l'objet cluster FW) et l'autre moitié sur l'objet "encrypt" de la regle de filtrage ... c'est penible quand on veut faire des VPN avec pleins de partenaires differents qui ont des equipement differents (on est tot ou tard oblige de modifier les parametres "globaux" et donc revalider tous les VPNs ...).
-les licenses, outre le fait qu'elles sont chères, sont compliquées à gerer et liées à une adresse IP (pouquoi ??)
-le "management station" c'est un truc que tu peux approcher simplement avec des scripts si tu utilises iptables. C'est vrai que le clustering est bien etudié, cependant, a mon avis bien en dessous de celui des PIX cisco.
-le log: FW1 c'est plein de truc proprio difficiles a integrer dans une architecture ouverte. le log est dans un format bidon, pas simple a exporter en syslog...
-l'interface graphique SUX de temps en temps. J'aimerai mieux comprendre ce qu'il y a en dessous. Comment sauvegarder la conf et la re-installer facilement sur un autre firewall ? c'est tres simple en iptable, de meme avec les PIX cisco. C'est non documente et quasi infaisable avec FW1.
-la mise a jour. avec FW1 c'est le cirque pour recuperer les patchs et mettre a jour la machine. C'est encore pire avec Cisco cependant. Alors qu'avec linux c'est hyper simple.
bref il manque surtout le clustering a Iptables (partager les tables de connexions entre deux machines iptables pour pouvoir basculer sans perdre les connexions en cours ...).
Ce que j'apprecie justement avec iptable c'est le mode de gestion "scriptée" qui est adaptable et automatisable comme JE l'entends.
# Non, non et non !
Posté par Alan_T . É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: Non, non et non !
Posté par PLuG . Évalué à 9.
[^] # Re: Non, non et non !
Posté par Alan_T . É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. :-)
[^] # Re: Non, non et non !
Posté par PLuG . Évalué à 2.
non non ne passes pas au tricot tout de suite.
la plupart des faits de ton premier post sont évident. Par exemple le statefull firewall et les attaques DoS.
par contre sur netfilter et le connection tracking. il me semble que je n'ai plus qu'a aller lire le code. Si ce que tu dis est vrai c'est purement et simplement un bug.
le NEW ne devrait accepter que les paquets avec SYN sans ACK et la table des connections ne devrait etre mise a jour que lorsque la reponse ACK+SYN est renvoyée.
Si pas de reponse, pas de "connexion" dans la table, cela me parait logique .?.
Pour ce qui est du DoS, le probleme c'est que si ton firewall est blindé, il est toujours possible de faire du DoS sur le routeur juste avant ... ou de "simplement" remplir la bande passante du site...
le DoS c'est vraiment la plaie, mais c'est un autre domaine de sécurité: la disponibilité. Dans un premier temps assurer la confidentialité/
[^] # Re: Non, non et non !
Posté par Alan_T . É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).
[^] # --state NEW et Syn
Posté par Vanhu . Évalué à 2.
Pour être précis, c'est une feature dangereuse:
Cela permet effectivement de ne pas couper des connexions quand il y a reboot (voire commutation sur un éventuel firewall de backup), ou d'autoriser en toute connaissance de causes certains paquets "anormaux", pour pouvoir par exemple scanner de l'intérieur vers l'extérieur, etc....
Mais si c'est mal compris, plein de gens croient (à tort, donc) que le fait de vérifier le --state NEW garantit que le paquet est bien un début de connexion (pour du TCP, bien sur), alors que ca garantit surtout qu'il ne fait pas partie d'une connexion en cours....
Par contre, en y réfléchissant, c'est l'état INVALID que je comprends pas trop, du coup, faudra que j'aille voir ca (probablement dans les sources, effectivement....).
[^] # Re: --state NEW et Syn
Posté par Alan_T . É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: --state NEW et Syn
Posté par Cédric Blancher . Évalué à 2.
Ce qu'on rencontre le plus souvent, ce sont les ICMPs d'erreurs qui ne peuvent etre lies a une connexion en cours. Sinon, ensuite, ce sont des choses comme le manque de RAM ou la table des etats pleines.
Pour en revenir a la feature, elle est dangereuse quand elle n'est pas comprise, et il est vrai que le doc reste ambigue sur ce point. Maintenant, rien ne vous empeche d'ajouter un --syn avec toutes vos regles TCP en etat NEW.
Mais bon, si vous voulez de la doc precise sur Netfilter :
http://iptables-tutorial.frozentux.net/(...)
Un excellent document qui presente aussi bien l'architecture que l'outil iptables.
[^] # Re: --state NEW et Syn
Posté par Alan_T . Évalué à 1.
Oui, mais il est difficile de documenter une telle fonctionalité. Plutôt que de dire que c'est un bug, je préfère dire que c'est une erreur de design.
[^] # Re: --state NEW et Syn
Posté par Cédric Blancher . Évalué à 2.
Pas vraiment. Si tu commences par expliquer que la gestion d'etats est un concept plus general que TCP et ce que ca implique. Je suis en train de finir un article sur Netfilter, j'espere que ce sera clair ;)
> Plutôt que de dire que c'est un bug, je préfère dire que c'est une erreur de design.
Une erreur de design, non, pas plus qu'un bug d'ailleurs.
De mon point de vue, c'est une option dont la valeur par defaut serait mal positionnee. Je m'explique.
Le fait de pouvoir flaguer un paquet ACK en NEW est utile (pour moi en tout cas). Mais il est certain que le patch no-pickup devrait etre applique par defaut et que les utilisateurs devraient avoir a le desactiver pour passer au fonctionnement actuel. La dessus on est OK.
Sur l'erreur de design, que je comprends comme l'affirmation qu'un tel comportement ne devrait pas etre possible, je ne suis pas d'accord, dans la mesure ou il se justifie parfaitement, non pas par une histoire fumeuse de reboot, mais par le fait qu'un etat est un concept qui, pour etre applique a l'ensemble des flux qu'on peut etre amene a traite (TCP, UDP, GRE, ESP, etc.) doit amha etre dans une certaine mesure decorrelable du concept de connexion TCP. La encore je m'explique.
L'usage courant de la gestion des etats des connexions TCP est de suivre une connexion TCP dans son ensemble, du SYN/SYN-ACK/ACK au FIN/double FIN-ACK/ACK de fin. Mais on peut aussi vouloir traiter l'etat de flux _IP_, dont la charge serait des paquet TCP particuliers. Par exemple reperer un ACK scan en matchant justement les paquet TCP ACK en etat NEW.
Bref, il me semble une bonne chose de garder cette lattitude. Par contre, en faire le comportement par defaut, c'est autre chose. En tout cas, je te trouve bien severe avec Netfilter.
Sinon, j'ai lu ton papier, mais je te fais suivre mes commentaires/questions par email, ce n'est pas trop le lieu pour cela ;)
[^] # Re: --state NEW et Syn
Posté par Alan_T . Évalué à -1.
Oui, cette feature semble utile, et oui, cela ne devrait pas faire partie de la configuration par défaut.
De plus, je suis impatient de lire ton papier à propos de Netfilter.
Hop --> -1, parceque cela sent le <aol>me2</aol>
[^] # Re: Non, non et non !
Posté par Alan_T . É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).
[^] # Benchs et filtrage.....
Posté par Vanhu . Évalué à 2.
Ils disent chairement qu'ils génèrent un "worst case".
Or, avec Netfilter/iptables, la notion de chaines permet d'énormément limiter ce cas de figure si les règles sont construites de facon intelligente: si on a des tests lourds à faire (de nombreuses règles) sur certains paquets, ben on fait d'abord un <critères communs> -j TABLE_SPECIFIQUE, et on fait tous les tests dans la table en question: les paquets non concernés ne "subiront" pas ces tests.
[^] # Re: Benchs et filtrage.....
Posté par Alan_T . É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: Benchs et filtrage.....
Posté par Vanhu . Évalué à 2.
S'il n'y a qu'une règle qui correspond, pas (trop) de problèmes, on peut s'en sortir avec une fonction de hash ou autre chose du genre....
Seulement, dans la réalité vraie du monde de la vie, ben on met en place des règles de filtrage, qui correspondent souvent à différents traffics, avec éventuellement des règles communes à pas mal de paquets suivies de règles spécifiques.
Donc non seulement il faut que tu retrouves des règles associées à un paquet, mais en plus, il faut les retrouver (et les évaluer) dans le bon ordre !!
Il n'y a donc pas vraiment le choix: il faut parser l'ensemble des règles !
Après, il y a différentes facons d'optimiser, toutes (celles que je connais) plus ou moins basées sur un principe: être capable de repérer des ensembles de règles qu'il n'est pas nécessaire d'évaluer.
Ca peut être un système de filtrage "non linéaire" (genre Netfilter qui permet de faire des sauts d'une table vers une autre en fonction de certains critères), un système de "critères cummuns" qui permet de savoir que, si un paquet ne correspond pas à un certain profil, ca n'est pas la peine de le confronter aux <x> règles suivantes (pf, si je me souviens bien, et .... je peux faire ma pub ? :-), etc...
Mais l'algorithme reste en O(n), et on reste de toutes facons en O(n) dans le pire des cas à l'évaluation, et même en O(n) pour le cas "moyen", mais en gagnant du temps quand même....
Après, dans certains cas spécifiques, on peut avoir une évaluation en mieux que O(n) (mais bon, une évaluation systématique en O(1), ca doit vraiment être des cas particuliers...), mais c'est autre chose...
Ou alors, il faut complètement revoir la facon de décrire une politique de filtrage....
Bon courage, mais je suis intéressé par d'éventuels résultats :-)
[^] # Re: Benchs et filtrage.....
Posté par Alan_T . Évalué à 1.
Non, et c'est là l'astuce ! ;-)
Le problème fondamental que l'on traite dans les firewalls c'est la classification de paquets basé sur leur header.
En gros, si tu considères chaque champs du header comme une variable entière qui a un domaine fixé (entre 0 et 255 par exemple), tu peux traduire chaque règle de ta configuration comme autant de formules logiques. Ensuite, tu peux 'compiler' ces formules logiques en une seule (en faisant attention de conserver l'ordre de précedence sur les règles).
Le fait de 'compiler' ces formules en une seule est un problème NP-complet. Cependant, tu peux très bien compiler tout ça en dehors du noyau. Une fois que tu as ta formule logique, tu la met dans le noyau et tu n'auras pas à évaluer chaque champs du header plus d'une fois (au plus), ce qui fait que c'est en temps constant puisque tu as un nombre de champs fixé (du moins sur ipv4).
Mais, on explique tout ça mieux dans: http://www.cs.auc.dk/~fleury/papers/CF-infocom2003-submitted.ps.gz(...)
En gros, on retire du noyau toutes les opérations qui ne sont pas nécessaires. Et cela donne une accéleration assez intéressantes (du moins sur les prototypes que l'on a fait jusqu'à présent).
De plus, sur des fichiers de configuration réalistes, on s'en tire à quelques secondes de compilation (il y a une table dans le papier à ce propos). Et on a quelques idées pour encore optimiser le compilateur.
# Erreur dans l'article
Posté par falbala . Évalué à 1.
Je connais au moins un autre : http://pyca.de/(...)
Bon y'en a un en perl et l'autre en python ...
Par contre si vous avez des comparatifs (de ces deux là ou d'un autre) ...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.