dominiqd

Réaction compréhensible bien-sûr mais n'occultons pas la possibilité d'étude du code à fins nocives. Que je me souvienne les chinois sont déjà "entrés" jusqu'au coeur de la NASA, des forces armée et de la CIA et quand ça ne fonctionne pas ils s'arrangent pour vendre des routeurs de très bonne réputation préalablement truffés, qui ne voudrait pas d'un linksys à moitié prix aux états-unis...?

Mouais si tu veux... dans ce cas d'espèce-ci le fait de "mélanger des pommes et de poires" n'a pas de conséquence négative sur la sécurité des utilisateurs. Je parlerais plutôt de "vocabulaire" plutôt que de "méthodologie" car Matousec effectue bien des test de résistance et de fuites sur "un produit qu'il nomme pare-feu" alors qu'il faudrait le nommer "pare-feu combiné à un IDS ou à un HIPS". Les anglo-saxons ne disposent pas des mêmes subtilités que celles présentes au sein de la langue française, ne l'oublions pas. d.

Qui sait ? Mais je crois que la question mérite d'être posée et "réfléchie" car après tout il s'agit peut-être d'un avertissement "indirect" de MBAM à ses clients...

Mais oui je sais bien... et c'est principalement la raison pour laquelle les utilisateurs qui répondent n'importe quoi aux invites ou qui désactivent cette protection supplémentaire utilisent le pare-feu par défaut livré avec leur système. Ceci n'indique en rien, me semble-t-il, la pertinence des test évoqués ici par rapport à ceux de Matousec. Je précise que je ne suis ni client de Matousec ni utilisateur d'aucun produit recommandé par ce site puisque j'utilise un os peu courant.

Parce que la société chinoise qui a piraté les bases de données de MBAM s'est intéressée au code en premier lieu, dans le cas contraire leur "démarche" n'a aucun intérêt, ce code va inévitablement circuler et quelques jours après (dans le meilleur des cas) ceux qui l'ont étudié seront en mesure de bypasser les défenses MBAM sans que celui-ci réagisse. Ceux qui conçoivent du code pour contourner les A-V ou les pare-feu/IDS se procurent d'abord le système de défense puis l'étudient jusqu'à ce qu'ils soient en mesure de le transpercer sans le faire couiner. C'est la procédure standard non ?

D'accord mais cela revient seulement à distinguer les mérites du pare-feu et du HIPS de manière séparée. Etant donné que les meilleurs produits combinent un pare-feu et un HIPS ou iDS et que la meilleure protection est offerte en activant les deux quel intérêt cela a-t-il de distinguer les performances de chacun des composants sachant que toute personne "raisonnablement raisonnable" ne désactivera pas un des deux composants ?

Inutile de préciser qu'après ceci tout internaute protégé par MBAM ne le sera plus...

Bonsoir, Une seule question : en vertu de quoi faudrait-il accorder plus de crédibilité à ces tests plutôt qu'à ceux de Matousec ? Parce qu'on peut en télécharger une partie...?

D'où l'utilité d'utiliser un os très sécurisé (et fort peu employé), cqfd !

Salut Nerva, Le principal est que tu aies désactivé l'autorun par le biais de la base de registre, le reste entre moins en considération puisque tu utilises un os très faillible du point de vue de la sécurité.

Le problème de l'autorun sous Windows c'est que ça ressemble à une usine à gaz et qu'en plus personne ne peut contrôler ce que "autorun.inf" fait. Pour ma part je dirais que coupler Truecrypt à l'autorun ou même à faire ouvrir le dossier sur la clé à l'aide de l'explorateur est un non-sens (puisqu'on ne peut pas savoir ce qu'autorun fait) et que ce fichier peut être bidouillé très facilement en dissimulant une instruction cachée qui conservera identiquement la même apparence que le texte ou l'icône habituels. N'aurais tu pas seulement désactivé l'autorun relative à la boîte de dialogue ? Si c'est le cas la manoeuvre ne suffit pas et il faut aller modifier le paramètre dans la base de registre. (Et si tu veux réellement contrôler tous les paramètres de sécurité sans que des programmes cachés n'agissent à ton insu sans savoir ce qu'ils font tu ferais mieux de passer à un autre Os nativement "plus sécurisé" que Windows. Là au moins tu auras la main sur tout ce que tu fais et en toute connaissance de cause.

Merci à tous deux pour ces précisions. Oui, je préfère être un peu trop attentif que pas assez. En ce qui me concerne je fais tourner ces outils chaque jour depuis près de deux ans et c'est bien la 1ère fois que je vois ce message. Et comme je venais d'installer "unhide" pour que Rkh fasse un boulot plus étendu je me suis dit qu'il y avait peut-être quelque chose de pas clean. d.

Sorry je me suis mal exprimé, d'habitude le résultat du check est : "Checking `lkm'... chkproc: nothing detected" D'où mon inquiétude... J'ai refait plusieurs run de chkrootkit et rien, le résultat est invariablement : "Checking `lkm'... chkproc: nothing detected" Mon raisonnement me dit que si chkrootkit a signalé un processus (une seule fois) identifié comme étant le 10385 mais que celui-ci est un "truc" inconnu puisque "aucun fichier ou répertoire de ce type" qu'est-ce que ça peut signifier d'autre ? une erreur d'adressage mémoire, un bug temporaire, une saloperie...? A moins que mon raisonnement soit inexact mais là je compte sur un expert en la matière. d.

Bonjour à tous, Suite à un scan ./chkrootkit ce matin je vois qu'il me signale : "Checking `lkm'... find: /proc/10385: Aucun fichier ou répertoire de ce type" C'est la première fois que je vois ce message, d'habitude l'analyse donne : "chkproc - Not found" En faisant un "./chkrootkit -x lkm" je ne retrouve pas le processus, je ne le retrouve pas non-plus dans la table des processus... Quelqu'un sait-il à quoi se rapporte ce processus ou a déjà vu le même message...? merci par avance, d.

Bonsoir, Je me demande la raison qui vous pousse à utiliser TuxGuardian ? Rassurés par l'interface graphique qui ressemble à celle d'un fw sous Windows ? Ou Shorewall n'est pas assez efficace à votre goût ? Ou vous n'êtes pas au courant de ce qu'il peut faire...? Un peu de lecture peut-être...? http://www.shorewall.net/shorewall_setup_guide_fr.htm d.