Au vu de nombreuses remarques, mais sans vouloir lancer une polémique...
Je suis utilisateur de Viguard et en ce qui me concerne, je n'ai pas
grand chose à lui reprocher. Ceci dit je suis à peu près ignorant en
matière de virus, et de sécurité.
Donc je ne peu juger du fonctionnement interne du programme.
Toutefois, il me semble quand - même que la logique du logiciel me
semble valable : si un virus est un programme qui doit s'installer sur
la machine pour foncitonner et que l'antivirus surveille l'installation
d'exécutable, à priori ça devrait empêcher pas mal de virus de
s'infiltrer non ?
Je répête, je n'ai pas les bases suffisante pour pouvoir affirmer cela à
fond, mais c'est pour cela que je poste ce message, aux fins de
comprendre un peu mieux !
Par ailleurs, je serais intéressé de savoir commment d'autres
utilisateurs de Viguard paramètrent leur logiciel...et pourquoi !
Merci d'avance
--
Tof...qui ne désespère pas de voir un 2ème neurone lui pousser un jour !
On Mon, 14 Feb 2005 19:34:30 +0100, Frederic Bonroy wrote:
Il est bloqué pour la raison très simple que ce code n'emploie pas la méthode #6. Vous comprenez?
Pas seulement. Son plus gros travers est de vouloir écrire sur le filesystem. Prenons Slammer (où tout se déroule en RAM), je suis prêt à parier qu'il infecte sans peine un poste protégé par Viguard si la faille expoitée est présente.
Nicob
On Mon, 14 Feb 2005 19:34:30 +0100, Frederic Bonroy wrote:
Il est bloqué pour la raison très simple que ce code n'emploie pas la
méthode #6. Vous comprenez?
Pas seulement. Son plus gros travers est de vouloir écrire sur le
filesystem. Prenons Slammer (où tout se déroule en RAM), je suis prêt à
parier qu'il infecte sans peine un poste protégé par Viguard si la
faille expoitée est présente.
On Mon, 14 Feb 2005 19:34:30 +0100, Frederic Bonroy wrote:
Il est bloqué pour la raison très simple que ce code n'emploie pas la méthode #6. Vous comprenez?
Pas seulement. Son plus gros travers est de vouloir écrire sur le filesystem. Prenons Slammer (où tout se déroule en RAM), je suis prêt à parier qu'il infecte sans peine un poste protégé par Viguard si la faille expoitée est présente.
Nicob
Guillermito
In article <4210fd59$0$6606$, says...
je ne parlais pas de vous avec cette "expression" mais de la généralité de ce newsgroup
Mais vous avez souvent parlé de moi et de mes analyses. Toujours à charge. Quant à ce newsgroup, il est ouvert à tous.
-- Guillermito http://www.guillermito2.net
In article <4210fd59$0$6606$8fcfb975@news.wanadoo.fr>, pepe84@infonie.fr
says...
je ne parlais pas de vous avec cette "expression" mais de la généralité de
ce newsgroup
Mais vous avez souvent parlé de moi et de mes analyses. Toujours à charge.
Quant à ce newsgroup, il est ouvert à tous.
Ben le seul que je me souvienne etait pepe84 comme cette adresse mail
Pour le peu que je poste sur ce newsgroup .... faudra m'expliquer ce : "souvent"
?
"Cyrius" a écrit dans le message de news:
Le Mon, 14 Feb 2005 20:34:28 +0100, "Vincent" écrivait :
non , pas du tout
seulement que depuis le temps j'ai refais un nouvo PC est je n'ai pas repris
les meme pseudo/identifiant
Et quels étaient vos anciens pseudos/identifiants ? Qu'on puisse aller se marrer un peu :-)
EOT
Frederic Bonroy
Pas seulement. Son plus gros travers est de vouloir écrire sur le filesystem. Prenons Slammer (où tout se déroule en RAM), je suis prêt à parier qu'il infecte sans peine un poste protégé par Viguard si la faille expoitée est présente.
Sans doute, puisqu'il ne se passerait rien que Viguard puisse intercepter.
Pas seulement. Son plus gros travers est de vouloir écrire sur le
filesystem. Prenons Slammer (où tout se déroule en RAM), je suis prêt à
parier qu'il infecte sans peine un poste protégé par Viguard si la
faille expoitée est présente.
Sans doute, puisqu'il ne se passerait rien que Viguard puisse intercepter.
Pas seulement. Son plus gros travers est de vouloir écrire sur le filesystem. Prenons Slammer (où tout se déroule en RAM), je suis prêt à parier qu'il infecte sans peine un poste protégé par Viguard si la faille expoitée est présente.
Sans doute, puisqu'il ne se passerait rien que Viguard puisse intercepter.
Guillermito
In article <42110c54$0$6617$, says...
Ben le seul que je me souvienne etait pepe84 comme cette adresse mail
Ah, la mémoire, hein.
Pour le peu que je poste sur ce newsgroup .... faudra m'expliquer ce : "souvent"
J'ai bien précisé plus haut "sur les forums web". Pas sur usenet.
-- Guillermito http://www.guillermito2.net
In article <42110c54$0$6617$8fcfb975@news.wanadoo.fr>, pepe84@infonie.fr
says...
Ben le seul que je me souvienne etait pepe84 comme cette adresse mail
Ah, la mémoire, hein.
Pour le peu que je poste sur ce newsgroup .... faudra m'expliquer ce :
"souvent"
J'ai bien précisé plus haut "sur les forums web". Pas sur usenet.
Ben le seul que je me souvienne etait pepe84 comme cette adresse mail
Ah, la mémoire, hein.
Pour le peu que je poste sur ce newsgroup .... faudra m'expliquer ce : "souvent"
J'ai bien précisé plus haut "sur les forums web". Pas sur usenet.
-- Guillermito http://www.guillermito2.net
Pierre Vandevenne
Tof wrote in news:MPG.1c7a955d606feaa9896f1 @nntpserver.tele2.fr:
Toutefois, il me semble quand - même que la logique du logiciel me semble valable : si un virus est un programme qui doit s'installer sur la machine pour foncitonner et que l'antivirus surveille l'installation
d'exécutable, à priori ça devrait empêcher pas mal de virus de s'infiltrer non ?
On peut bloquer tous les programmes, toute exécution sous n'importe quelle forme. Cela bloque tous les virus, mais ce n'est pas très pratique pour les autre programmes.
De plus, dans un contexte, c'est-à-dire sorti de l'absolu, ce n'est même pas parfait car on se sait pas vraiment ce qui est exécutable ou pas à un moment donné parce que, sans entrer dans les détails, le contexte est constitué de programmes qui peuvent être exploités.
Admettons que cela soit quand même suffisant et essayons d'améliorer la méthode. Il faut distinguer les exécutions bénignes, souhaitées ou indispensables de celle qui sont néfastes. Cela devient équivalent à détecter au mieux la potentialité hostile d'un programme ou, au pire, l'_intention_ de ce programme.
C'est un sujet de recherche qui passione des centaines de PhD dans le monde entier, dans le cadre de programmes financés par leur département de la défense respectif. Dans cette recherche, il est largement fait appel à des mathématiques complexes, la théorie des graphes, etc... Je pense que le problème est insoluble, mais comme me le faisaient remarquer les gens qui travaillent avec moi, ce sont précisément les projets insolubles en un moment donné qui offrent les opportunités de progrès.
Un bloqueur de comportement ne peut qu'approximer la discrimination. A 99.999% de faux positifs, il bloque tout, y compris les exécutions légitime. A 99.999% de faux négatifs, il laisse tout passer. Les bloqueurs de comportement sont donc un compromis entre ces deux extrêmes. Le hic, c'est qu'en théorie et en pratique
1) la détection ne peut être à 100%, sans bloquer 100% des applications légitimes.
2) les comportements légitimes et illégitimes varient d'une époque à l'autre. Il faut s'adapter de temps en temps.
3) des comportements illégitimes nouveaux apparaissent au gré de l'inspiration de leurs auteurs. Il faut s'adapter de temps en temps, parfois de façon fondamentale.
Il est parfaitement légitime et raisonnable de se protéger avec un bloqueur de comportement si on est conscient de ses limites.
Plus efficaces il sera, plus il produira de fausses alertes.
Il n'offrira pas une protection à 100%
Il devra être mis-à-jour, non seulement au niveau de ses heuristiques (qui, mathématiquement, ne sont rien d'autre que des signatures très floues) mais aussi au niveau de son fonctionnement profond, par exemple pour controler de nouveaux apis, de nouvelles situations dangereuses ou de nouvelles méthodes d'exploitation de failles connues.
Cette plate vérité, généralement admise par toutes les personnes qui dépensent en recherche fondamentale sur le problème des centaines de fois plus d'argent que le chiffre d'affaire de certaines sociétés de sécurité, parait être en contradiction avec la réclame de certaines sociétés de sécurité.
Ce n'est guère étonnant: réclame et publicité ne doivent jamais être considérés comme la vérité absolue.
Etonnant, non?
-- Pierre Vandevenne - DataRescue sa/nv - www.datarescue.com The IDA Pro Disassembler & Debugger - world leader in hostile code analysis PhotoRescue - advanced data recovery for digital photographic media latest review: http://www.pcmag.com/article2/0,1759,1590497,00.asp
Tof <fourtou@tele2.fr> wrote in news:MPG.1c7a955d606feaa9896f1
@nntpserver.tele2.fr:
Toutefois, il me semble quand - même que la logique du logiciel me
semble valable : si un virus est un programme qui doit s'installer sur
la machine pour foncitonner et que l'antivirus surveille
l'installation
d'exécutable, à priori ça devrait empêcher pas mal de virus de
s'infiltrer non ?
On peut bloquer tous les programmes, toute exécution sous n'importe
quelle forme. Cela bloque tous les virus, mais ce n'est pas très
pratique pour les autre programmes.
De plus, dans un contexte, c'est-à-dire sorti de l'absolu, ce n'est même
pas parfait car on se sait pas vraiment ce qui est exécutable ou pas à
un moment donné parce que, sans entrer dans les détails, le contexte est
constitué de programmes qui peuvent être exploités.
Admettons que cela soit quand même suffisant et essayons d'améliorer la
méthode. Il faut distinguer les exécutions bénignes, souhaitées ou
indispensables de celle qui sont néfastes. Cela devient équivalent à
détecter au mieux la potentialité hostile d'un programme ou, au pire,
l'_intention_ de ce programme.
C'est un sujet de recherche qui passione des centaines de PhD dans le
monde entier, dans le cadre de programmes financés par leur département
de la défense respectif. Dans cette recherche, il est largement fait
appel à des mathématiques complexes, la théorie des graphes, etc... Je
pense que le problème est insoluble, mais comme me le faisaient
remarquer les gens qui travaillent avec moi, ce sont précisément les
projets insolubles en un moment donné qui offrent les opportunités de
progrès.
Un bloqueur de comportement ne peut qu'approximer la discrimination. A
99.999% de faux positifs, il bloque tout, y compris les exécutions
légitime. A 99.999% de faux négatifs, il laisse tout passer. Les
bloqueurs de comportement sont donc un compromis entre ces deux
extrêmes. Le hic, c'est qu'en théorie et en pratique
1) la détection ne peut être à 100%, sans bloquer 100% des applications
légitimes.
2) les comportements légitimes et illégitimes varient d'une époque à
l'autre. Il faut s'adapter de temps en temps.
3) des comportements illégitimes nouveaux apparaissent au gré de
l'inspiration de leurs auteurs. Il faut s'adapter de temps en temps,
parfois de façon fondamentale.
Il est parfaitement légitime et raisonnable de se protéger avec un
bloqueur de comportement si on est conscient de ses limites.
Plus efficaces il sera, plus il produira de fausses alertes.
Il n'offrira pas une protection à 100%
Il devra être mis-à-jour, non seulement au niveau de ses heuristiques
(qui, mathématiquement, ne sont rien d'autre que des signatures très
floues) mais aussi au niveau de son fonctionnement profond, par exemple
pour controler de nouveaux apis, de nouvelles situations dangereuses ou
de nouvelles méthodes d'exploitation de failles connues.
Cette plate vérité, généralement admise par toutes les personnes qui
dépensent en recherche fondamentale sur le problème des centaines de
fois plus d'argent que le chiffre d'affaire de certaines sociétés de
sécurité, parait être en contradiction avec la réclame de certaines
sociétés de sécurité.
Ce n'est guère étonnant: réclame et publicité ne doivent jamais être
considérés comme la vérité absolue.
Etonnant, non?
--
Pierre Vandevenne - DataRescue sa/nv - www.datarescue.com
The IDA Pro Disassembler & Debugger - world leader in hostile code
analysis
PhotoRescue - advanced data recovery for digital photographic media
latest review: http://www.pcmag.com/article2/0,1759,1590497,00.asp
Tof wrote in news:MPG.1c7a955d606feaa9896f1 @nntpserver.tele2.fr:
Toutefois, il me semble quand - même que la logique du logiciel me semble valable : si un virus est un programme qui doit s'installer sur la machine pour foncitonner et que l'antivirus surveille l'installation
d'exécutable, à priori ça devrait empêcher pas mal de virus de s'infiltrer non ?
On peut bloquer tous les programmes, toute exécution sous n'importe quelle forme. Cela bloque tous les virus, mais ce n'est pas très pratique pour les autre programmes.
De plus, dans un contexte, c'est-à-dire sorti de l'absolu, ce n'est même pas parfait car on se sait pas vraiment ce qui est exécutable ou pas à un moment donné parce que, sans entrer dans les détails, le contexte est constitué de programmes qui peuvent être exploités.
Admettons que cela soit quand même suffisant et essayons d'améliorer la méthode. Il faut distinguer les exécutions bénignes, souhaitées ou indispensables de celle qui sont néfastes. Cela devient équivalent à détecter au mieux la potentialité hostile d'un programme ou, au pire, l'_intention_ de ce programme.
C'est un sujet de recherche qui passione des centaines de PhD dans le monde entier, dans le cadre de programmes financés par leur département de la défense respectif. Dans cette recherche, il est largement fait appel à des mathématiques complexes, la théorie des graphes, etc... Je pense que le problème est insoluble, mais comme me le faisaient remarquer les gens qui travaillent avec moi, ce sont précisément les projets insolubles en un moment donné qui offrent les opportunités de progrès.
Un bloqueur de comportement ne peut qu'approximer la discrimination. A 99.999% de faux positifs, il bloque tout, y compris les exécutions légitime. A 99.999% de faux négatifs, il laisse tout passer. Les bloqueurs de comportement sont donc un compromis entre ces deux extrêmes. Le hic, c'est qu'en théorie et en pratique
1) la détection ne peut être à 100%, sans bloquer 100% des applications légitimes.
2) les comportements légitimes et illégitimes varient d'une époque à l'autre. Il faut s'adapter de temps en temps.
3) des comportements illégitimes nouveaux apparaissent au gré de l'inspiration de leurs auteurs. Il faut s'adapter de temps en temps, parfois de façon fondamentale.
Il est parfaitement légitime et raisonnable de se protéger avec un bloqueur de comportement si on est conscient de ses limites.
Plus efficaces il sera, plus il produira de fausses alertes.
Il n'offrira pas une protection à 100%
Il devra être mis-à-jour, non seulement au niveau de ses heuristiques (qui, mathématiquement, ne sont rien d'autre que des signatures très floues) mais aussi au niveau de son fonctionnement profond, par exemple pour controler de nouveaux apis, de nouvelles situations dangereuses ou de nouvelles méthodes d'exploitation de failles connues.
Cette plate vérité, généralement admise par toutes les personnes qui dépensent en recherche fondamentale sur le problème des centaines de fois plus d'argent que le chiffre d'affaire de certaines sociétés de sécurité, parait être en contradiction avec la réclame de certaines sociétés de sécurité.
Ce n'est guère étonnant: réclame et publicité ne doivent jamais être considérés comme la vérité absolue.
Etonnant, non?
-- Pierre Vandevenne - DataRescue sa/nv - www.datarescue.com The IDA Pro Disassembler & Debugger - world leader in hostile code analysis PhotoRescue - advanced data recovery for digital photographic media latest review: http://www.pcmag.com/article2/0,1759,1590497,00.asp
Pierre Vandevenne
Frederic Bonroy wrote in news::
Si ces programmes étaient livrés sous forme de fichier .zip tout bête, on pourrait le décompresser, passer tous les fichiers à l'antivirus,
Hmmm, quand on est un as du marteau, on a tendance à voir le clou partout.
-- Pierre Vandevenne - DataRescue sa/nv - www.datarescue.com The IDA Pro Disassembler & Debugger - world leader in hostile code analysis PhotoRescue - advanced data recovery for digital photographic media latest review: http://www.pcmag.com/article2/0,1759,1590497,00.asp
Frederic Bonroy <bidonavirus@yahoo.fr> wrote in
news:37bir1F5babe4U1@individual.net:
Si ces programmes étaient livrés sous forme de fichier .zip tout bête,
on pourrait le décompresser, passer tous les fichiers à l'antivirus,
Hmmm, quand on est un as du marteau, on a tendance à voir le clou partout.
--
Pierre Vandevenne - DataRescue sa/nv - www.datarescue.com
The IDA Pro Disassembler & Debugger - world leader in hostile code analysis
PhotoRescue - advanced data recovery for digital photographic media
latest review: http://www.pcmag.com/article2/0,1759,1590497,00.asp
Si ces programmes étaient livrés sous forme de fichier .zip tout bête, on pourrait le décompresser, passer tous les fichiers à l'antivirus,
Hmmm, quand on est un as du marteau, on a tendance à voir le clou partout.
-- Pierre Vandevenne - DataRescue sa/nv - www.datarescue.com The IDA Pro Disassembler & Debugger - world leader in hostile code analysis PhotoRescue - advanced data recovery for digital photographic media latest review: http://www.pcmag.com/article2/0,1759,1590497,00.asp
Frederic Bonroy
Hmmm, quand on est un as du marteau, on a tendance à voir le clou partout.
Là je plane...?
Hmmm, quand on est un as du marteau, on a tendance à voir le clou partout.
