Vanhu a écrit 447 commentaires

Curieux que personne n'ait pensé à taper le mot le plus utilisé dans les moteurs de recherche (si ma mémoire est bonne):

http://www.koders.com/?s=sex&_%3Abtn=Search&_%3Ala=*&_%(...)

Qui fait quand meme un honorable score de presque 800 !!!


"Totalement inutile, donc rigoureusement indispensable"....

A +

VANHU.

Y'a pas la licence BSD dans la liste des licences possibles....

"Attention chérie, a va troller"....

On va encore le dire autrement: ca me fait clairement penser à la réaction des devs d'OpenBSD quand le fameux et très controversé bench sur les performances des différents noyaux sur certains appels systèmes a montré qu'OpenBSD avait une implémentation complètement pourrie sur certains appels.

Y'a ceux qui ont dit "OpenBSD c'est secure, c'est pas censé etre performant, on a fait ca pour des raisons de sécurité", alors que très clairement, sur certains points, c'était une argumentation pipeau, et y'a ceux qui se sont dit "ok, y'a effectivement un truc louche, on va aller vérifier nos implémentations et voire ce qu'on peut améliorer sans commencer a faire des magouilles dangereuses".

La, c'est un peu pareil, si on dit bien "on fait une première version simple pour pas s'emmeler les pinceaux et etre fiable, et on affinera plus tard", ca me va.

Par contre, si on dit "on fait un big kernel lock parceque c'est que comme ca que ca peut etre secure", la c'est du pipeau....

Et en lisant la phrase telle qu'elle est dans la news, j'hésite entre les deux interprétations.....

Bah si on présente ca comme "un bon début", effectivement, c'est pas mal.

Par contre, présenté comme "fait comme ca pour des raisons de simplicité, et donc de sécurité", ca fait vraiment foutage de gueule a la OpenBSD, je trouve.....

C'est moi qui ai dormi trop longtemps, ou cette "qualité" est justement ce que beaucoup de gens (ici meme) reprochent à un autre OS, certes pas OpenSource, mais "pour clients" aussi ?????

Bientot, on aura une version de Syllable avec un navigateur tellement bien intégré qu'on ne pourra pas faire démarrer l'OS sans ?

Ouais, et puis les gars qui valident les CC, c'est des gens cools, pas chieurs pour 2 balles, ca les dérange pas de faire une évaluation juste après un cvs update -dPA .....

Et puis pour information, pour passer les CC, il ne suffit pas de faire un code prétendument "secure", parait-il super audité, avec plein de méchanismes a 2 balles pour portéger des buffers overflow.

Il faut aussi pondre une doc clean, des explications détaillées sur les modules, les procédures de développement (et un "bah Theo s'en occupe" va pas suffire, je pense....), et a partir de EAL5, un code plutot clean et bien commenté !!!

Et puis pour marcher dedans moi aussi a fond, c'est bien beau de détecter un 2nd processeur, mais ca suffit pas pour avoir des performances raisonnables, faut encore avoir des algos qui ne sont pas trop pourris, au moins dans les endroits critiques.........

Ma question etait dans l'autre sens: je me doute bien que les sociétés qui vendent ces firewalls (mais ca marche avec d'autres produits basés sur du Linux, remarquez) autorisent les utilisateurs a linker leur module avec un noyau sous GPL, ma question est "est-ce que ces gens ont le droit de diffuser un ensemble kernel Linux + module non GPL ?".

De la meme facon que quand on linke un programme GPL avec une librairie non GPL (ou l'inverse), meme si l'auteur de la partie non GPL nous y autorise, la GPL l'interdit en général.....

Y'a aussi un autre cas de figure, qui est réellement "dans la nature" a l'heure actuelle:

Les firewalls qui utilisent un moteur de filtrage propriétaire (et non GPL), qui est un module noyau..... donc "linké" au kernel, qui est sous GPL.

Je comprends pas trop comment ils auraient le droit de faire ca, j'ai l'impression que c'est pareil que le problème des drivers NVidia, ou c'etait loin d'etre évident pour les distribs de le diffuser....

Un expert pour expliquer ?

Il y a en fait 2 problèmes (enfin, je shématise un peu....):

D'abord, la facon "logique" de faire, a savoir passer par des proxies (ce que font la plupart des solutions, ca permet parfois de reprendre des proxies existants, donc on y gagne en dev, mais c'est lent....) ou faire de l'inspection "a la volée" (souvent en inspectant les paquets sans vraiment les "décapsuler", coté perfs, c'est nettement meilleur, mais c'est plus lourd a développer...).

Ensuite vient la grande problématique des ASICs. Les commerciaux des solutions basées sur des ASICs diront qu'un ASIC, c'est top, ca va super vite (et faut reconnaitre que c'est vrai), ils oublient juste de préciser qu'un ASIC va super vite, mais uniquement pour faire ce pourquoi il a été prévu, et que comme c'est un composant matériel cablé, pas question de le mettre à jour quand la technologie évolue.

Et actuellement, (a peu pres ?) toutes les boites qui font des solutions basées sur ASIC mettent en avant leurs perfs "filtrage pur", et recommandent meme de désactiver l'IPS sur des "coeurs de réseaux", parceque les perfs s'effondrent quand on l'active. Peut etre qu'ils "résoudront" le problème avec une future version de leur ASIC qui inclue une partie des routines d'IPS....

Maintenant, les solutions basées sur du processeur "générique" mais avec une techno a base de proxies ont le meme genre de problèmes.....


Et pour l'instant, les seuls qui tirent leur épingle du jeu dans ce domaine, c'est ceux qui sont sur un processeur "générique" ET qui ont une implémentation "kernel" de l'IPS (en clair, c'est de l'inspection, pas du proxy). Et y'en a pas beaucoup....

C'est la forces des solutions basées sur des ASICs...

Mouais.....

C'est pour ca que des "gros" du marché basés sur des ASICs ont des performances qui s'écroulent dès qu'on active leurs options d'IPS ? :-)

Plus sérieusement, les ASICs, ca peut etre bien dans certains cas, mais faudrait que les équipes marketing se calment un peu a ce sujet, ca a au moins autant d'inconvénients que d'avantages (surtout pour ceux qui ont une ancienne version du hard, t'as beau faire toutes les updates du firmware que tu veux, t'as quand meme un ASIC qui sait pas faire, donc des performances pourraves....).....

Enfin, je dis ca, je dois pas etre tout a fait impartial non plus, mais bon, :-)

Et les sources sont dispos?

Euh..... Non, en tout cas, pas pour le moteur de filtrage (apres, ca n'empeche pas de contribuer a des projets externes utilisés).

-pourquoi choisir une solution proprio plutôt qu'une autre?

Bah ca, c'est a chacun de voir en fonction de ses critères:
- Efficacité (en termes de sécurité)
- Performances
- Prix
- Ergonomie de l'interface (souvent, la simplicité d'utilisation est un critère important quand on prend une "appliance")
- Produits proposés (matos, perfs, nombre d'interfaces, etc...)
- Fonctionnalités proposées (maintenant, une appliance doit aussi pouvoir faire du VPN, du DHCP, du LDAP, de l'antivirus, etc... et doit IMPERATIVEMENT pouvoir activer la cafetière quand elle détecte un problème qui va occuper l'adminsys toute la nuit....)
- Notoriété (souvent prisé par les "décideurs" qui veulent avant tout etre surs de ne pas pouvoir se faire reprocher leur "choix".....)
- Efficacité du support du constructeur
- etc......

Maintenant, faut etre lucide, des clients qui ont réellement les compétences techniques pour vérifier l'efficacité de plein de firewalls, et de choisir celui qui fait le mieux son boulot de protection plutot que celui qui a la plus belle plaquette, ca court pas les rues.....



PS: je ne peux pas vraiment affirmer la meme indépendance vis a vis des différentes marques citées :-)

C'est pas moi qui ai cité la société en premier ! :-)

FreeBSD, oui (enfin, une "base" FreeBSD).

IPFilter non, plus depuis quelques années, le filtrage/IPS/etc est maintenant fait 100% "maison".

Tres peu de coupe-feu, remonte au-dessus de TCP ou d'UDP ou alors via des relais applicatifs (relais de messagerie SMTP, proxy et reverse proxy HTTP)

Eh non, le "bete par feu Stateful", c'est dépassé, n'importe quel technico commercial qui bosse dans la sécurité le confirmera !!

Maintenant, les firewalls "de grands" sont capables de vérifier la cohérence jusqu'a la couche 7 (en totu cas pour les protocoles qu'ils connaissent), et donc par exemple de jeter du traffic SSH qui essaierait de passer via un port http (parceque bon, le http, on l'accepte, souvent).

Alors apres, effectivement, la plupart des produits font ca via des proxies, et pour peu que ca soit une appliance basée sur un ASIC "pas tout a fait de la derniere version qui sort des la semaine prochaine", les performances ont un peu tendance a s'effondrer lamentablement....

Mais il y a quelques produits qui font ca "proprement", rapidement, et qui ont en plus (au moins pour certains) le bon gout d'etre développés en France et d'etre basés sur des OS libres.....

Par ailleurs, une bonne pratique consiste a ne pas autoriser les postes de travail de tout usager a sortir en direct sur le grand 'ternet. Seuls des machines précises (placées si possible en zone de sécurité) ont le droit d'envoyer (et/ou de recevoir) du trafic vers Internet sur des ports/protocoles particuliers.

Ouais, alors en théorie, effectivement, c'est bien (mais ca ne résoud pas tout pour autant), mais en pratique, a part certains endroits sensibles administres par des paranos (ministeres ? armee ? societes de gestions de PKIs ou d'autres données sensibles du meme genre ? mon réseau local ? :-), j'aimerais bien voir ou on arrive a imposer ce genre de "bonnes pratiques".

Si j'ai bien compris, la nouvelle pile IPSec du noyau Linux est "autre chose", qui a peut etre éventuellement récupéré une partie du code de KAME, mais qui n'est pas un "portage supplémentaire".

Par contre, comme cette pile utilise PFKeyV2 pour causer entre le noyau et le userland, ils peuvent utiliser n'importe quel demon isakmp qui utilise cette norme, et en pratique, ils utilisent Racoon (le demon Isakmp "officiel" de KAME).

A priori, la taille d'un int va aussi passer a 8 (me semble que la coutume veut qu'un int représente un mot machine, avec un minimum garanti).

Quel est l'intérêt d'être compatible 32 bits pour les processeurs 64 bits ? Acheter une architecture 64 bits pour faire tourner un OS 32 bits n'a strictement aucun intérêt.

Bah quand tu as des applis 32 bits, que tu ne veux/peux pas les recompiler, la compatibilité 32 bits est carrément importante !!

Bien sur, si des gens avaient eu l'idée de faire des OS et des outils dont ils auraient distribué les sources avec le droit de les triturer, et si d'autres personnes avaient bien vu l'avantage de cette possibilité, bah on aurait pas trop besoin de cette compatibilité 32 bits..............

Oui, ils ont (mal) pompé au moins du code réseau des BSDs sur leurs versions 9x, c'est connu....

40 Go de sources......

Plus j'y pense, et plus je me dis que c'est énorme, meme si on compte Win + Office + plein d'autres trucs !!

Ou alors ils comptent tout le repository de leur CVS (enfin, de l'équivalent), dans lequel ils ont mis tous les bitmaps d'images de fond d'ecran et tous les waves de démarrage depuis Windows 3.1 !!!

Ou alors ils se la pètent à mort style genre "eh, on est pas des fiottes qui ont a peine quelques MOs de sources, hein, on a 40 Go, nous !".......

Bah c'est de la sécurité quand meme :-)

Et comme je disais, ca dépend du niveau de sécurité désiré et des moyens qu'on est pret à mettre pour y parvenir.

La, en l'occurence, ca répond relativement bien a la demande (quoique je sais pas combien ca a couté), parceque le technicien moyen, il va pas commencer a s'amuser a faire un moulage de son empreinte digitale pour le filer a un pote en meme temps que la carte magnétique et la clé...

Comme ils le disent sur leur site, c'est surtout pour vérifier que le bon technicien est bien venu au moment prévu.....

Mais si les responsables de la meme boite estiment que leurs batiments sont bien protégés contre les tentatives d'intrusions de personnes vraiment motivées et un minimum compétentes, bah ils ont tord !

Après, ca dépend de ce qu'il y a dans les batiments en question, bien sur, des "pros" ne vont surement pas s'embeter pour voler un stock de stylos et de trombonnes.....

Bah, les capteurs évolués, y'a 2 cas:

- On se sert de la biométrie comme "login", et ca sert donc pas a grand chose de réussir a gruger un capteur biométrique (faut toujours autre chose comme "mot de passe").

- On se sert de la biométrie comme mot de passe. Comme je l'ai dit au dessus, c'est un mauvais choix, puisqu'on a alors un mot de passe non répudiable (perso, je change pas de pouce et d'empreinte toutes les semaines !). En plus, ca sera probablement une longue course entre les évolutions des capteurs et les évolutions des techniques pour gruger les capteurs.....


Et pour ce qui est de "la biométrie est un outil supplémentaire pour renforcer la sécurité", je reste pas convaincu, c'est bien juste un "gadget" pour que les gens n'aient pas a retenir un login.

Le seul niveau ou ca peut apporter de la "sécurité", c'est si on met des capteurs super évolués a des endroits ou y'a que ma petite soeur et ma belle mere qui vont essayer de gruger (et effectivement, elles n'ont pas les compétences pour forcer ces "sécurités").

Combien de fois faudra-t-il le dire: la biométrie n'est pas un facteur majeur de sécurité !!!

Utiliser des paramètres biométriques comme mots de passes, c'est déclarer un mot de passe qu'on ne pourra pas changer le jour ou il sera compromis !!!

Donc une empreinte digitale, une identification rétinienne, une reconnaissance vocale, une empreinte ADN, ou tout autre "truc biométrique" ne devrait en aucun cas servir de mot de passe, mais uniquement de login !!!

Et il faut donc toujours avoir un mot de passe en plus !!!

En résumé, la biométrie n'est pas un élément de sécurité, mais un gadget qui simplifie un peu la vie des utilisateurs (ils ont toujours leur "login" sur eux, donc ils n'ont plus que leur mot de passe a retenir).

Pour info, il y a au moins Rainbow qui a des tokens "bien" (avec du matos crypto et une "carte a puce" dedans), qui sont censes etre geres par opensc, mais opensc marche pas (encore ?) avec les cles USB sous FreeBSD, alors je retesterai plus tard sous un Linux :-)

Mais effectivement, ca ne concerne pas toute leur gamme.

Le problème suivant est souvent de sécuriser les données de la clé USB

C'est la qu'interviennent d'autres tokens USB, spécifiques crypto, qui font eux memes les opérations de chiffrement, donc qui gardent la clé privée, et ne la filent pas a l'OS.

Ca permet d'avoir un niveau supplémentaire de sécurité, puisque la clé privée ne sort plus du token USB, mais....... mais j'ai trouvé de support Linux / BSD pour aucun des tokens du marché, et vu le prix de ces trucs (et le fait qu'ils font QUE ca), ca se limite au marché pro....

Pas besoin de faille:

Tu es neuneu, on t'ai dit "Linxu c'est sécurisé", tu as installé une distrib quelconque (meme une Debian ou une Slackware !!), tu te logues tout le temps en root, tu recois un mail dans ton kmail/evolution/autre qui contient un binaire en attachement, tu l'executes betement, et hop, le binaire fait ce qu'il veut !


La sécurité, c'est une chaine complète de bonne philosophie.
Une partie des logiciels OpenSource peuvent apporter un maillon a cette chaine (alors que la plupart des outils du monde de Bill ne le sont pas), mais ca ne suffit pas, et en ce sens, ils ont raison !

Et en règle générale, quand tu te sens assez en sécurité pour t'endormir, tu redeviens tout de suite vulnérable !!!

C'est malin de fanfaronner sur la doc LDAP: maintenant, on va *vraiment* devoir trouver du temps pour la faire !!!!