Salut,
Je viens de passer en XP home, sous ADSL
Mon vendeur m'a certifié qu'un logiciel spécialisé (p ex Zone Alarm) n'était
plus indispensable compte tenu d'un FireWall intégré à XP.
Quel est le test à faire pour vérifier si mon PC est une passoire ?
NB Il n'y a pas de secret d'Etat sur ma bécane, ni même commerciaux.
Bonsoir et merci d'un petit coup de pouce.
Je pensais que ZA fermait tout mais la manipe renvoit :
ZA ne *ferme* pas, il *filtre* : les applications continuent de tourner, et n'ont pas même conscience d'être filtrées. netstat peut donc renvoyer ce qu'il veut, peu importe. Il faut faire scanner ta machine pour savoir ce qui est accessible à l'extérieur.
pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
Je pensais que ZA fermait tout mais la manipe renvoit :
ZA ne *ferme* pas, il *filtre* : les applications continuent de tourner,
et n'ont pas même conscience d'être filtrées. netstat peut donc renvoyer
ce qu'il veut, peu importe. Il faut faire scanner ta machine pour savoir
ce qui est accessible à l'extérieur.
pierre
--
Pierre LALET
lalet@enseirb.fr -- http://www.enseirb.fr/~lalet
Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc
Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
Je pensais que ZA fermait tout mais la manipe renvoit :
ZA ne *ferme* pas, il *filtre* : les applications continuent de tourner, et n'ont pas même conscience d'être filtrées. netstat peut donc renvoyer ce qu'il veut, peu importe. Il faut faire scanner ta machine pour savoir ce qui est accessible à l'extérieur.
pierre
-- Pierre LALET -- http://www.enseirb.fr/~lalet Clé publique PGP : http://www.enseirb.fr/~lalet/pierre_lalet.asc Empreinte de la clé : B6B8 0F89 2220 DF8B 0F3B C0C0 773E 15E6 A878 FC7E
bruno
netstat -an et j'ai 8 ports ouverts .
re bonjour , et que donne un teste avec : https://grc.com/x/ne.dll?bh0bkyd2 ???
netstat -an
et j'ai 8 ports ouverts .
re bonjour ,
et que donne un teste avec :
https://grc.com/x/ne.dll?bh0bkyd2
???
re bonjour , et que donne un teste avec : https://grc.com/x/ne.dll?bh0bkyd2 ???
Fabien LE LEZ
On 29 Sep 2003 10:11:44 GMT, Nicob wrote:
Deux personnes du NG (Cédric et moi) ont montré à certaines conférences récentes comment contourner efficacement les firewalls personels sous Windows. Cédric passait par en dessous (couche drivers/NDIS)
et moi au dessus (manipulation d'Internet Explorer via les objets OLE).
Est-ce que le trou existe toujours une fois qu'on a mis en place la première précaution à prendre de toutes façons, i.e. interdire tout accès vers Internet à IE ?
On 29 Sep 2003 10:11:44 GMT, Nicob <usenet@nicob.net> wrote:
Deux personnes du NG (Cédric et moi) ont montré à certaines
conférences récentes comment contourner efficacement les firewalls
personels sous Windows. Cédric passait par en dessous (couche
drivers/NDIS)
et moi au dessus (manipulation d'Internet Explorer via les
objets OLE).
Est-ce que le trou existe toujours une fois qu'on a mis en place la
première précaution à prendre de toutes façons, i.e. interdire tout
accès vers Internet à IE ?
Deux personnes du NG (Cédric et moi) ont montré à certaines conférences récentes comment contourner efficacement les firewalls personels sous Windows. Cédric passait par en dessous (couche drivers/NDIS)
et moi au dessus (manipulation d'Internet Explorer via les objets OLE).
Est-ce que le trou existe toujours une fois qu'on a mis en place la première précaution à prendre de toutes façons, i.e. interdire tout accès vers Internet à IE ?
Cedric Blancher
Dans sa prose, Fabien LE LEZ nous ecrivait :
et moi au dessus (manipulation d'Internet Explorer via les objets OLE). Est-ce que le trou existe toujours une fois qu'on a mis en place la
première précaution à prendre de toutes façons, i.e. interdire tout accès vers Internet à IE ?
Il reste encore une attaque via les interfaces de debugging qui permet d'injecter du code dans un process en cours d'exécution, façon plugin. Mais il faut avoir les droits de debug (on les a par défaut), et c'est un peu technique.
-- BOFH excuse #77:
Typo in the code
Dans sa prose, Fabien LE LEZ nous ecrivait :
et moi au dessus (manipulation d'Internet Explorer via les objets OLE).
Est-ce que le trou existe toujours une fois qu'on a mis en place la
première précaution à prendre de toutes façons, i.e. interdire tout
accès vers Internet à IE ?
Il reste encore une attaque via les interfaces de debugging qui permet
d'injecter du code dans un process en cours d'exécution, façon plugin.
Mais il faut avoir les droits de debug (on les a par défaut), et c'est un
peu technique.
et moi au dessus (manipulation d'Internet Explorer via les objets OLE). Est-ce que le trou existe toujours une fois qu'on a mis en place la
première précaution à prendre de toutes façons, i.e. interdire tout accès vers Internet à IE ?
Il reste encore une attaque via les interfaces de debugging qui permet d'injecter du code dans un process en cours d'exécution, façon plugin. Mais il faut avoir les droits de debug (on les a par défaut), et c'est un peu technique.
-- BOFH excuse #77:
Typo in the code
Nicob
On Tue, 30 Sep 2003 05:44:16 +0000, Fabien LE LEZ wrote:
et moi au dessus (manipulation d'Internet Explorer via les objets OLE).
Est-ce que le trou existe toujours une fois qu'on a mis en place la première précaution à prendre de toutes façons, i.e. interdire tout accès vers Internet à IE ?
Non. C'est le process d'IE qui est vu par les fw personnels come accédant au Net. Si ce process est privé de sortie, JAB ne sortira pas.
Nicob
On Tue, 30 Sep 2003 05:44:16 +0000, Fabien LE LEZ wrote:
et moi au dessus (manipulation d'Internet Explorer via les
objets OLE).
Est-ce que le trou existe toujours une fois qu'on a mis en place la
première précaution à prendre de toutes façons, i.e. interdire tout
accès vers Internet à IE ?
Non. C'est le process d'IE qui est vu par les fw personnels come accédant
au Net. Si ce process est privé de sortie, JAB ne sortira pas.
On Tue, 30 Sep 2003 05:44:16 +0000, Fabien LE LEZ wrote:
et moi au dessus (manipulation d'Internet Explorer via les objets OLE).
Est-ce que le trou existe toujours une fois qu'on a mis en place la première précaution à prendre de toutes façons, i.e. interdire tout accès vers Internet à IE ?
Non. C'est le process d'IE qui est vu par les fw personnels come accédant au Net. Si ce process est privé de sortie, JAB ne sortira pas.
Nicob
bruno
"Nicob" a écrit dans le message de news:
Non. C'est le process d'IE qui est vu par les fw personnels come accédant au Net. Si ce process est privé de sortie, JAB ne sortira pas.
Nicob
bonjour , j'ai pas tous compris , mais pour le firewall kerion y a une vérification de md5 pour chaque logiciels qui veux sortir : comme ie oe etc .... donc si tu injecte un cheval dans ie la signature md5 change ??? @suivre
"Nicob" <usenet@nicob.net> a écrit dans le message de news:
pan.2003.09.30.07.28.40.739099@nicob.net...
Non. C'est le process d'IE qui est vu par les fw personnels come accédant
au Net. Si ce process est privé de sortie, JAB ne sortira pas.
Nicob
bonjour , j'ai pas tous compris , mais
pour le firewall kerion y a une vérification de md5 pour chaque
logiciels qui veux sortir : comme ie oe etc ....
donc si tu injecte un cheval dans ie la signature md5 change ???
@suivre
Non. C'est le process d'IE qui est vu par les fw personnels come accédant au Net. Si ce process est privé de sortie, JAB ne sortira pas.
Nicob
bonjour , j'ai pas tous compris , mais pour le firewall kerion y a une vérification de md5 pour chaque logiciels qui veux sortir : comme ie oe etc .... donc si tu injecte un cheval dans ie la signature md5 change ??? @suivre
Nicob
On Tue, 30 Sep 2003 13:12:24 +0000, bruno wrote:
pour le firewall kerion y a une vérification de md5 pour chaque logiciels qui veux sortir : comme ie oe etc ....
OK. Un grand classique des pare-feux personnels.
donc si tu injecte un cheval dans ie la signature md5 change ???
Non. Le binaire "iexplore.exe" reste le même, c'st juste qu'il est manipulé (ie. commandé) via un programme plutôt que via le clavier et la souris. JAB simule une utilisation classique d'IE, donc pour le pare-feu, c'est pareil que quand l'utilisateur habituel ouvre une fenêtre, tape une URL puis sur [Entrée].
Nicob
On Tue, 30 Sep 2003 13:12:24 +0000, bruno wrote:
pour le firewall kerion y a une vérification de md5 pour chaque
logiciels qui veux sortir : comme ie oe etc ....
OK.
Un grand classique des pare-feux personnels.
donc si tu injecte un cheval dans ie la signature md5 change ???
Non. Le binaire "iexplore.exe" reste le même, c'st juste qu'il est
manipulé (ie. commandé) via un programme plutôt que via le clavier et
la souris. JAB simule une utilisation classique d'IE, donc pour le
pare-feu, c'est pareil que quand l'utilisateur habituel ouvre une
fenêtre, tape une URL puis sur [Entrée].
pour le firewall kerion y a une vérification de md5 pour chaque logiciels qui veux sortir : comme ie oe etc ....
OK. Un grand classique des pare-feux personnels.
donc si tu injecte un cheval dans ie la signature md5 change ???
Non. Le binaire "iexplore.exe" reste le même, c'st juste qu'il est manipulé (ie. commandé) via un programme plutôt que via le clavier et la souris. JAB simule une utilisation classique d'IE, donc pour le pare-feu, c'est pareil que quand l'utilisateur habituel ouvre une fenêtre, tape une URL puis sur [Entrée].
Nicob
bruno
"Nicob" a écrit dans le message de news:
Le binaire "iexplore.exe" reste le même Nicob re bonjour
le md5 change pas , alors question : comment détecter ce truc , c'est un cheval de troie ? un java exploie ?
"Nicob" <usenet@nicob.net> a écrit dans le message de news:
pan.2003.09.30.13.29.41.478188@nicob.net...
Le binaire "iexplore.exe" reste le même
Nicob
re bonjour
le md5 change pas , alors question :
comment détecter ce truc ,
c'est un cheval de troie ?
un java exploie ?
Hum ... Chercher un binaire nommé jab.exe sur le disque (mais il peut être renommé) ou utiliser "System Safety Monitor" et détecter les appels à IE
c'est un cheval de troie ?
Non, une backdoor initiant elle-même la connexion vers le "méchant". [Promis, je vais écrire une doc afin d'éviter ces longs threads]
Nicob
francoisj_59
Cedric Blancher wrote in message :
Dans sa prose, Fabien LE LEZ nous ecrivait :
et moi au dessus (manipulation d'Internet Explorer via les objets OLE). Est-ce que le trou existe toujours une fois qu'on a mis en place la
première précaution à prendre de toutes façons, i.e. interdire tout accès vers Internet à IE ?
Il reste encore une attaque via les interfaces de debugging qui permet d'injecter du code dans un process en cours d'exécution, façon plugin. Mais il faut avoir les droits de debug (on les a par défaut), et c'est un peu technique.
-- BOFH excuse #77:
Typo in the code
As-tu une reference sur cette attaque ? Il me semble qu'elle serait la bienvenue...
Cedric Blancher wrote in message :
Dans sa prose, Fabien LE LEZ nous ecrivait :
et moi au dessus (manipulation d'Internet Explorer via les objets OLE).
Est-ce que le trou existe toujours une fois qu'on a mis en place la
première précaution à prendre de toutes façons, i.e. interdire tout
accès vers Internet à IE ?
Il reste encore une attaque via les interfaces de debugging qui permet
d'injecter du code dans un process en cours d'exécution, façon plugin.
Mais il faut avoir les droits de debug (on les a par défaut), et c'est un
peu technique.
--
BOFH excuse #77:
Typo in the code
As-tu une reference sur cette attaque ?
Il me semble qu'elle serait la bienvenue...
et moi au dessus (manipulation d'Internet Explorer via les objets OLE). Est-ce que le trou existe toujours une fois qu'on a mis en place la
première précaution à prendre de toutes façons, i.e. interdire tout accès vers Internet à IE ?
Il reste encore une attaque via les interfaces de debugging qui permet d'injecter du code dans un process en cours d'exécution, façon plugin. Mais il faut avoir les droits de debug (on les a par défaut), et c'est un peu technique.
-- BOFH excuse #77:
Typo in the code
As-tu une reference sur cette attaque ? Il me semble qu'elle serait la bienvenue...
