09h07 du mat, un café près de moi et une clope au bec, je m'attaque a une réponse au post de notre ami le Barbier celui-ci étant dans une veine littéraire
Cela a au moins le mérite d'étoffer le débat
La machine virtuelle? Personnellement j'en doute, VMWARE n'as plus a démontré sa stabilité comparé a Virtualbox, il suffit de demander a Manzai les différents soucis qu'il a rencontré avec cette plateforme, et moi aussi avec Kaspersky par exemple.
Par rapport à Virtualbox, c'est sûr qu'il n'y aura pas photo. Mais sur une installation "physique" dédiée, il devrait y avoir des améliorations ? Sinon, je ne vois pas comment Matousec a réussi à tester DrWeb. A -t-il fait des paramétrages spéciaux non explicités ? Peut-être, et ça serait un très mauvais point pour lui.
Sur une installation physique dédiée, oui je pense que cela fonctionne beaucoup mieux..Il suffit de voir le test de Manzai qui n'as pas réussi a installer le pare-feu sous virtualbox, c'est vrai que DrWeb est assez tatillon au niveau des sous couches réseau, expliquant certainement les écrans bleus que Manzai a rencontrer.
La version 7 de security space possédant un nouveau hook d'interception du traffic (drivers, applis, service) il doit etre certainement ralentis en virtualisation...Sans compter l'api anti-rootkit qui fonctionne de manière autonome et parallèle a windows (et non pas de concert comme certains produits).
1- Oui j'avais bien compris
Mais comme nous le disions, l'amputation des fonctions, meme si c'est dans un soucis de logique de test, le protocole de test en lui meme, le règlage des logiciels au max (connais t'on beaucoup d'utilisateurs de Comodo par exemple, utilisant le mode parano?? Ou d'utilisateur d'Eset avec le hips en interactif?) ne permet pas, selon moi, de montrer la protection de logiciels de manière fiable, surtout quand l'on vois que notre ami EboO et d'autres d'ailleurs, n'obtiennent meme pas le meme résultat^^.
Concernant le détection de fuite en elle meme, il est stupide de ne pas inclure les "modules de prévention", meme si j'ai bien compris la démarche.
Je trouve que de tester un seul "pan" (comme tu le dis si justement), est un non sens, pour des logiciels qui sont developper/conçus pour fonctionner de concert avec l'intégralité de leur modules.
Je prend un exemple rapide avec Kaspersky (il faut bien changer
).
Exemple d'un rootkit, qui, on es d'accord, peut etre vecteur de fuite de données.
Premier exemple KSN hors service:
Admettons que le rootkit ne soit pas connus de la base virale et possède une fausse signature numérique (ce qui est loin d'etre utopique), il va s'installer tranquillement avec le maximum de droit, sans vraiment d'alerte comme l'affectionne Matousec. Et on noteras alors un echec.
Deuxième exemple KSN en service:
Ce rootkit s'installe, les fichiers sont "envoyés" sur le KSN, celui-ci détecte le fichier malveillant, l'appli est mise en quarantaine et une restauration du systeme a l'état antérieur te seras proposé par KIS.
Donc ce petit exemple, qu'il vaut ce qu'il vaut, peux démontré que tester simplement l'action de blocage du logiciel, sans les modules de prévention, donne un résultat faussé.
Si le but de ce test est de mettre en avant les HIPS je n'en vois pas l'interet, car comme je le disais plus haut, c'est bien d'avoir une pop-up, mais savoir y répondre c'est encore mieux.
Ce qui serais adéquat c'est de donné le niveau de compétences requise en parallèle (débutant, moyen, "expert")
2- "Que le produit intègre un AV ou pas ne me semble pas poser problème si l'on suit cette logique. Les mécanismes de défense des AVs relèvent surtout de la détection par fichier (signatures, heuristiques, réputation, sandboxing...) et non par comportement."
Là, je ne suis pas d'accord, un Norton ou un Bitdefender possèdent des "règles comportementales" dans des modules spécifiques ne dépendant pas du pare-feu, tous cela par mesure d'économie, car il est moins "couteux" et plus efficace (meme si les risques de FP peuvent etre plus élever) de créer une règle comportementale pour un panel de menace, qu'une signature dédié.
D'ailleurs de plus en plus d'éditeur ce tourne vers cette option.
Autre exemple DrWeb avec sa protection du registre, la partie AV pourras bloqué une tentative de modif de clé importante sans pop-up d'alerte pour l'utilisateur, et là c'est bien la partie av qui bosse, puisque quand cette fonction est cochée, le résident applique une serie de règles bloquant l'accès a certaines clé sensible du registre.
"Mais pour Matousec, ce blocage n'a pas à être "intelligent", il faut juste qu'il soit basé sur le comportement des applications." Alors pourquoi ne plus faire des tests de pare-feu, comme il le faisait avant? Puisque leur protocole test plus ces modules spécifiques, et non l'intégralité des fonctions.
3- Oui mais si la logique et de ne pas en avoir...^^ Concernant virusbuster j'ai pas compris en effet.
En tous cas merci de ce "débat" qui éclaireras certainement les passants qui passe
Ce message a été modifié par vigen - 17 août 2012 - 09:37 .