Vanhu a écrit 447 commentaires

A mon sens le NAT est une bonne mesure de sécurité (il faut quand même que je router/firewall soit bien protégé)



Le NAT n'esp pas une mesure de sécurité, mais de camouflage.



S'il y a une bonne sécurité avant/après, alors c'est un plus intéressant (etre protégé ET caché est mieux qu'etre simplement protégé).



Mais il y a trop de réseaux qui sont "sécurisés" par un routeur de base qui ne fait que du NAT......

Donc, pour faire tourner RTCW sous Linux, faut acheter la version Windows.



Et après ca, les éditeurs nous diront encore "ah, mais on ferait une version Linux de tous nos jeux si y'avait un marché, mais pour ceux qui tournent sous Linux actuellement, on fait tout notre chiffre sur la version Windows !".



A quand les jeux vendus soit en version Linux, soit en version Windows, soit en "pack" comportant les 2 ?

La question est de savoir si le produit est vraiment censé etre sécurisé...



Si ca n'est pas le cas (ou plutot si on estime que ca n'est pas le cas), alors on peut considérer les méchanismes de sécurité comme un plus, et l'éditeur peut dire "oui, mais c'est pas censé etre un produit sécurisé non plus".



La, une telle loi (assez idiote quand meme par ailleurs, je trouve) préciserait bien que tout logiciel *doit* etre sécurisé (ou au moins ne pas etre un gouffre de sécurité).

Il a dit "améliorait", pas rendait incrackable...

Et je maintiens que c'est inexact !!!

Un programme qui résiste avec les sources ouvertes est probablement plus robuste que le même avec les sources fermées.

La, on est d'accord (quoique, Outlook et IIS ont prouvé qu'il n'est pas du tout nécessaire d'avoir les sources pour trouver les failles...), mais ca veut pas dire la meme chose.

Pour le temps de réaction aux patches, comme tu le dis, c'est généralement.

En résumé, ouvrir les sources ne crée pas (à terme) de faille de sécurité pour un projet correctement maintenu, voire crée un contexte qui peut favoriser la sécurisation du projet, mais je maintiens que la phrase "ouvrir les sources améliorait la sécurité....(à moyen terme)" est fausse !

En théorie, à terme, la solution libre est (amha) *toujours* la plus intéressante (sauf pour l'éditeur de solutions non-libres, bien sur ...), mais ca n'est pas toujours faisable en pratique:

Toujours en gardant cet exemple, si demain je me rends compte que j'ai besoin d'un outil de ce type, je ne pourrai pas forcément me permettre d'attendre que le développement d'un équivalent libre soit fini (ou au moins assez avancé pour mon utilisation).

Le problème est justement que les utilisateurs ne peuvent pas anticiper autant qu'il le faudrait dans certains cas !!

MD5 sert à faire une empreinte sur 128 bits, qui sera toujours la meme pour la meme donnée source.

En pratique, ca peut servir a faire des CRC de fichiers, mais aussi à générer des images de mots de passes, à authentifier des données (pour un tunnel VPN, par ex), et surement à plein d'autres choses qui ne viennent pas à mon cerveau en phase de digestion actuellement...

Mais bon, en tant que encryption tool, euh.... je vois pas, la .....

5 ans après que plus personne n'ai touché a une ligne de code de ce logiciel, le trou a été bouché...

Donc le trou est resté pendant pas mal de temps, je suppose.... jusqu'a ce que quelqu'un se décide à le faire. Je suis d'accord que ca n'aurait pas été faisable en Closed Source.


Dans ce cas aucun pirate non plus ne cherchera a exploiter ce trou de sécurité !

Ca dépend de qui est intéressé.
S'il s'agit de personnes pas du tout informaticiens mais qui manipulent des données qui ont une forte valeur, ca peut attirer des pirates !!!

Et ne me dis pas que dans ce cas, les responsables vont sécuriser le bordel, c'est trop rarement vrai !!!


Non, mais ca aide.

C'est la que je voulais en venir: ca n'entrave pas (sauf si on considère la sécurité par l'obscurité comme une bonne solution, mais il y a tellement de contre-exemples....), et ca peut avoir tendance à favoriser.

Tu conviendras que c'est quand meme très différent de "ouvrir les sources améliore la sécurité".....

Merci Aurélien :-)

Bon, quelques précisions s'imposent sur ce doc:

1) Le squelette est à peu près fini (il est encore succeptible de bouger un peu, mais presque tout est la, presque toujours à sa place définitive), mais le contenu ne l'est pas du tout.
Certaines sections n'ont d'ailleurs que les titres.

2) L'objectif n'est pas d'expliquer pas à pas quelle valeur mettre dans quel fichier pour avoir une config sécurisée de tel outil, des documents plus spécifiques existent pour ca, et ce doc en donne les liens quand je les connais.

3) Ca n'est pas un pompage ou une traduction d'un autre doc, mais vous trouverez probablement des similitudes, voire des inspirations (citées quand je m'en rends compte): le monde de la sécurité informatique n'est pas si grand que ca, et les "bonnes" facons de faire pas si nombreuses...

4) En fait, lisez l'intro, ca donne un peu plus de détails sur tout ca ......

5) Ok, je fais une croix sur ma nuit et je mets en ligne la prochaine version demain :-)

6) «Toute contribution est la bienvenue.»
Ca inclut des conseils/explications/résumés sur des points sur lesquels je ne suis pas expert, des sections/chapitres complets à intégrer directement (me contacter d'abord pour ca, j'essaie de garder une certaine cohérence, et ca évite de faire le boulot en double...), mais aussi des relectures, des remarques de débutants pour savoir si c'est compréhensible, etc....


A +

VANHU.

Bon, je pensais attendre encore un peu avant de l'annoncer au monde, mais la, j'ai plus le choix :-)

L'idée de ce document (dont je suis l'auteur, pour ceux qui auraient pas suivi) est de servir de référence de base à une sécurisation globale: si un document technique explique (bien) comment configurer un Apache de facon sécurisée (l'exemple n'est pas anodin, je cherche un tel document !), mon doc ne repompera pas, mais donnera un lien vers ce doc.


De toutes facons, faire un document technique unique qui couvre tout est a mon avis pratiquement infaisable, et serait trop dur à maintenir.

Je redonne plus d'infos sur ce doc directement en réponse à Aurélien....

Bref s'il y a des volontaires ou des gens prêts à payer pour, un autocad libre, c'est faisable aussi.

Bien sur que c'est théoriquement faisable, la question est: est-ce intéressant ?

Si acheter plein de licences Autocad coute, admettons 1 Million (d'euros, de patates, de carambars, etc...), et que redévelopper un autre produit du meme genre coute 1 Milliard, et que tout ca, c'est juste pour que 10 personnes s'en servent un peu, ben la première solution est probablement la meilleure en pratique !

Les exemples que tu cites "coutent cher", mais intéressent beaucoup de monde, donc c'est faisable.

Ca n'est pas forcément le cas de tous les softs.

En informatique, les "méchants" ne sont pas moins "salauds" qu'ailleurs, ils le sont simplement sur des domaines qui ne sont pas vitaux pour les "clients"....

il a déjà été démontré qu'ouvrir les sources améliorait la sécurité....(à moyen terme)

Pardon ????

J'aimerais bien voir la preuve de cette affirmation !!!

Un programme OpenSource suivi par des gens compétents en sécurité informatique est probablement ce en quoi j'ai le plus confiance, mais dire que "ouvrir les sources améliore la sécurité", c'est n'importe quoi !!!

1) Tu peux coder comme un gros dégueulasse, ce qui laissera des bugs/backdoors pratiquement indécelables.

2) Tu peux avoir un énoooorme trou de sécurité sur un programme OpenSource qui n'est plus maintenu, ou en tout cas plus par quelqu'un d'assez compétent pour boucher ce trou.

3) Tu peux avoir un programme OpenSource qui intéresse tellement peu de monde que personne ne va voir s'il y a des failles dedans.


Alors forcément, dans ces cas la, tu peux le détecter, et décider de ne pas/plus utiliser le programme en question, bien sur ...


Mais le fait de passer un programme en OpenSource ne va pas le rendre plus sécurisé comme par magie !!!

En théorie, c'est bien beau et je suis d'accord, mais en pratique, il y a des cas ou c'est infaisable.

L'un des plus souvent cités est Autocad, si je ne me trompe pas, qui est vraiment (parait-il, je connais pas vraiment) un truc enorme a développer, et que ca couterait une fortune de refaire la meme chose a coté.

Mais ca serait effectivement bien que l'argent public ne soit "cramé" dans des licences de logiciels propriétaires que si aucune des autres solution "classiques" (OpenSource et/ou développement interne rendu OpenSource) n'est faisable.

<i>le code reste toujours libre, librement modifiable et diffusable.<i>

Euh, avec la licence BSD aussi....
Sauf que n'importe qui peut reprendre le code sous licence BSD, l'utiliser dans des projets closed-source et meme faire croire que ca vient de lui dans certaisn cas....

Je me disais que c'est peut-être de cette façon qu'ils arrivaient à s'en sortir.

Ben eux et moi, on doit pas avoir la meme notion de "limité dans le temps", alors !!!

Par expérience, je sais que si on dit "oui, mais la loi dit que .....", l'effet est moyen.

Par contre, si on arrive en disant "je vous rapelle que l'article 2^254+2 du code de moulage vous oblige a ....", la, c'est plus efficace...


Alors si qqun pouvait nous sortir l'article exact et sa référence, ca serait top !!!

En théorie, c'est bien....

En pratique, il vaut mieux agir AVANT d'acheter: une fois que tu as payé, ils peuvent faire trainer les choses, et tu finis par abandonner....

Pas tant que ca:

1) Le mail n'est pas le seul vecteur de propagation d'un virus, c'est simplement le plus a la mode en ce moment.

2) Tous les virus actuels ne se propagent pas automatiquement, certains profitent de la crédulité des utilisateurs.

3) Les buffers overflows, ca existe, et ca peut permettre dans certains cas d'executer du code arbitraire.


Mais bon, comme j'ai déjà dit dans d'autres posts, l'antivirus est généralement la mauvaise solution....

Disons qu'un Unix bien configuré et mis à jour est peu propice à la propagation de virus, mais quand je vois le nombre d'utilisateurs qui installent une distrib "grand public", qui passent leur temps sous KDE en root et qui mettent rien a jour, je me dis qu'un antivirus serait mieux que rien dans certains cas....

Déjà, l'un des avantages de Linux, c'est d'être interopérable.

Donc, de causer et d'échanger avec des postes Win, par exemple (par SMB, en tant que relais SMTP, etc...).

Donc, rien que pour ca, le principe d'un antivirus qui tourne sous Linux peut être intéressant.


Maintenant, c'est vrai que dans un monde idéal, l'antivirus ne sert a rien...

Ce n'est certes pas de la sécurité
Ben si, c'est les principes de base de la sécurité: la méfiance et la segmentation.

Mais bon, meme ca, c'est rarement appliqué....

Je connais le patch en question, mais il y a encore pas longtemps, ca disait "utilisez précisément la version 1.3.xx pour le patch". La, déjà, ca a l'air de suivre l'évolution, si c'est assez vite intégré a un mutt 1.4.x, ca sera top ! Par contre, j'avais supposé qu'il y avait moyen de feinter pour au moins vérifier les signatures des mails en réception (en faisant des appels a OpenSSL), mais ca a pas l'air si évident que ca, en fait....

Bon, j'ai tenté ma chance un peu partout, alors j'assaie ici: est-ce que Mutt 1.4 supportera les signatures SMime ?

Est-ce que qqun connait une feinte de moule pour faire ca avec Mutt 1.2.x ?

Franchement, a part a troller, quel est l'intérer de cette niouze ici, franchement ????

Ok, elle aurait pu etre en page principale, ca aurait été pire, mais bon, déjà la.....

"Mais que font les modérateurs ?????"

Moi aussi, je vote pour un vote blanc (ok, j'ai repompé sur le post d'au dessus).

Serait-il possible de faire bouger les choses par une pétition ou quelquechose dans le genre ???

Après tout, c'est une autre facon de faire entendre son opinion !!!

Toi aussi, votes pour|contre|blanc a la proposition suivante:

"Les votes blancs devraient clairement exister pout tout vote en france, et être clairement montrés dans les résultats".

Dans l'idéal, tout vote ayant dépassé un certain nombre de votes blancs devrait etre annulé.