Du point de vue de la sécurité, que pensez-vous de l'utilisation
d'outils tels que Teamviewer, logmein ou ntrconnect au sein d'une
entreprise ?
Si j'en comprends l'intérêt, je trouve inquiétant d'avoir ce genre de
softs autonome sur des machines du réseau, mais qu'en pensez-vous ?
Hormis lister régulièrement les exécutables des postes fournis par les
logiciels d'inventaires, quelle méthode utiliser pour s'en prémunir ?
Le (on) mardi 24 juin 2008 17:29, Stephane Catteau a écrit (wrote) :
[1] Il ne suffit pas d'intercepter la connexion, il faut aussi se faire passer pour la machine à l'origine de celle-ci. Mais bon, il n'est pas nécessaire de donner des idées à ceux qui ne les ont pas encore eu.
Il se trouve que c'est une des premières idées que j'ai eu justement : comment on fait la différence niveau client entre la présence du proxy et une attaque man-in-the-middle en cours ?
Seul l'être humain le peut, et encore, uniquement s'il sait qu'il y a un proxy dans la chaîne.
mpg n'était pas loin de dire :
Le (on) mardi 24 juin 2008 17:29, Stephane Catteau a écrit (wrote) :
[1]
Il ne suffit pas d'intercepter la connexion, il faut aussi se faire
passer pour la machine à l'origine de celle-ci. Mais bon, il n'est pas
nécessaire de donner des idées à ceux qui ne les ont pas encore eu.
Il se trouve que c'est une des premières idées que j'ai eu justement :
comment on fait la différence niveau client entre la présence du proxy et
une attaque man-in-the-middle en cours ?
Seul l'être humain le peut, et encore, uniquement s'il sait qu'il y a
un proxy dans la chaîne.
Le (on) mardi 24 juin 2008 17:29, Stephane Catteau a écrit (wrote) :
[1] Il ne suffit pas d'intercepter la connexion, il faut aussi se faire passer pour la machine à l'origine de celle-ci. Mais bon, il n'est pas nécessaire de donner des idées à ceux qui ne les ont pas encore eu.
Il se trouve que c'est une des premières idées que j'ai eu justement : comment on fait la différence niveau client entre la présence du proxy et une attaque man-in-the-middle en cours ?
Seul l'être humain le peut, et encore, uniquement s'il sait qu'il y a un proxy dans la chaîne.
Stephane Catteau
Eric Razny devait dire quelque chose comme ceci :
Le minimum pour le gestionnaire du réseau, c'est au moins de savoir quels sont les flux qui y transitent et pourquoi.
Oui, et ? Le filtre IP lui dira d'où ils viennent, où ils vont et quel est le protocole applicatif le plus probablement utilisé. Le proxy[1], quant à lui, confirmera que le protocole applicatif est le bon.
Et? Si tu me mets un "vrai" proxy sur un flux qui est en principe chiffré (https, ssh etc) ça veut dire que le proprio du proxy est en position de MiM et qu'il vaut mieux ne pas utiliser le système (du point de vue utilisateur).
Ce qui au bout du compte est l'effet désiré, non ? L'admin a mis un proxy pour s'assurer qu'il n'y a pas d'utilisation frauduleuse de son réseau. Si l'utilisateur évite ces protocoles à cause du proxy, il a atteint son objectif.
Amha si on doit controler l'utilisateur à ce point (ce qui n'est pas nécessairement un mal :) ) on lui interdit le net non chiffré -et on lui met un proxy- et pour le reste ça passe par un vpn jusqu'aux serveurs de l'entreprise (plus précisement sur l'intranet, avec les contrôles qui vont bien) uniquement avec les applis spécifiées.
[OUI].
Eric Razny devait dire quelque chose comme ceci :
Le minimum pour le gestionnaire du réseau, c'est au moins de savoir
quels sont les flux qui y transitent et pourquoi.
Oui, et ? Le filtre IP lui dira d'où ils viennent, où ils vont et quel
est le protocole applicatif le plus probablement utilisé. Le proxy[1],
quant à lui, confirmera que le protocole applicatif est le bon.
Et?
Si tu me mets un "vrai" proxy sur un flux qui est en principe chiffré
(https, ssh etc) ça veut dire que le proprio du proxy est en position de
MiM et qu'il vaut mieux ne pas utiliser le système (du point de vue
utilisateur).
Ce qui au bout du compte est l'effet désiré, non ? L'admin a mis un
proxy pour s'assurer qu'il n'y a pas d'utilisation frauduleuse de son
réseau. Si l'utilisateur évite ces protocoles à cause du proxy, il a
atteint son objectif.
Amha si on doit controler l'utilisateur à ce point (ce qui n'est pas
nécessairement un mal :) ) on lui interdit le net non chiffré -et on lui
met un proxy- et pour le reste ça passe par un vpn jusqu'aux serveurs de
l'entreprise (plus précisement sur l'intranet, avec les contrôles qui
vont bien) uniquement avec les applis spécifiées.
Le minimum pour le gestionnaire du réseau, c'est au moins de savoir quels sont les flux qui y transitent et pourquoi.
Oui, et ? Le filtre IP lui dira d'où ils viennent, où ils vont et quel est le protocole applicatif le plus probablement utilisé. Le proxy[1], quant à lui, confirmera que le protocole applicatif est le bon.
Et? Si tu me mets un "vrai" proxy sur un flux qui est en principe chiffré (https, ssh etc) ça veut dire que le proprio du proxy est en position de MiM et qu'il vaut mieux ne pas utiliser le système (du point de vue utilisateur).
Ce qui au bout du compte est l'effet désiré, non ? L'admin a mis un proxy pour s'assurer qu'il n'y a pas d'utilisation frauduleuse de son réseau. Si l'utilisateur évite ces protocoles à cause du proxy, il a atteint son objectif.
Amha si on doit controler l'utilisateur à ce point (ce qui n'est pas nécessairement un mal :) ) on lui interdit le net non chiffré -et on lui met un proxy- et pour le reste ça passe par un vpn jusqu'aux serveurs de l'entreprise (plus précisement sur l'intranet, avec les contrôles qui vont bien) uniquement avec les applis spécifiées.
[OUI].
Stephane Catteau
Eric Razny n'était pas loin de dire :
Tu peux aussi avoir une attaque non ciblée (on va prendre le contrôle des machines de ceux qui finissent par installer le malware -peut importe la façon-) et, ô surprise, quand on est sur la machine de madame michu (via internet "classique") elle a un jouli tunnel tout fraichement ouvert vers la machine de sa boite...
Statistiquement, les risques ne sont-ils pas à considéré comme nuls ? Non seulement il faut tomber sur l'ordinateur de madame michu, mais en plus il faut le faire au bon moment. Selon moi, ça fait parti du 1% magique, celui qui fait qu'un réseau ne peut jamais être sûr qu'à 99% au maximum. Tout les admins vivent avec, et puis ça leur permet de justifier l'achat d'une machine pour mettre snort ou n'importe quel autre IDS de leur choix.
Eric Razny n'était pas loin de dire :
Tu peux aussi avoir une attaque non ciblée (on va prendre le contrôle
des machines de ceux qui finissent par installer le malware -peut importe
la façon-) et, ô surprise, quand on est sur la machine de madame michu
(via internet "classique") elle a un jouli tunnel tout fraichement ouvert
vers la machine de sa boite...
Statistiquement, les risques ne sont-ils pas à considéré comme nuls ?
Non seulement il faut tomber sur l'ordinateur de madame michu, mais en
plus il faut le faire au bon moment.
Selon moi, ça fait parti du 1% magique, celui qui fait qu'un réseau ne
peut jamais être sûr qu'à 99% au maximum. Tout les admins vivent avec,
et puis ça leur permet de justifier l'achat d'une machine pour mettre
snort ou n'importe quel autre IDS de leur choix.
Tu peux aussi avoir une attaque non ciblée (on va prendre le contrôle des machines de ceux qui finissent par installer le malware -peut importe la façon-) et, ô surprise, quand on est sur la machine de madame michu (via internet "classique") elle a un jouli tunnel tout fraichement ouvert vers la machine de sa boite...
Statistiquement, les risques ne sont-ils pas à considéré comme nuls ? Non seulement il faut tomber sur l'ordinateur de madame michu, mais en plus il faut le faire au bon moment. Selon moi, ça fait parti du 1% magique, celui qui fait qu'un réseau ne peut jamais être sûr qu'à 99% au maximum. Tout les admins vivent avec, et puis ça leur permet de justifier l'achat d'une machine pour mettre snort ou n'importe quel autre IDS de leur choix.
Thomas
In article , Stephane Catteau wrote:
Eric Razny n'était pas loin de dire :
> Tu peux aussi avoir une attaque non ciblée (on va prendre le contrôle > des machines de ceux qui finissent par installer le malware -peut importe > la façon-) et, ô surprise, quand on est sur la machine de madame michu > (via internet "classique") elle a un jouli tunnel tout fraichement ouvert > vers la machine de sa boite...
Statistiquement, les risques ne sont-ils pas à considéré comme nuls ?
t'es sur ?
Non seulement il faut tomber sur l'ordinateur de madame michu, mais en plus il faut le faire au bon moment. Selon moi, ça fait parti du 1% magique, celui qui fait qu'un réseau ne peut jamais être sûr qu'à 99% au maximum.
perso, je préfères que cette porte ne soit pas ouverte si j'en ai connaissance peu importe que ça soit pas la seule porte d'entrée possible
In article <mn.f4557d8614eb18c7.30736@sc4x.org>,
Stephane Catteau <steph.nospam@sc4x.net> wrote:
Eric Razny n'était pas loin de dire :
> Tu peux aussi avoir une attaque non ciblée (on va prendre le contrôle
> des machines de ceux qui finissent par installer le malware -peut importe
> la façon-) et, ô surprise, quand on est sur la machine de madame michu
> (via internet "classique") elle a un jouli tunnel tout fraichement ouvert
> vers la machine de sa boite...
Statistiquement, les risques ne sont-ils pas à considéré comme nuls ?
t'es sur ?
Non seulement il faut tomber sur l'ordinateur de madame michu, mais en
plus il faut le faire au bon moment.
Selon moi, ça fait parti du 1% magique, celui qui fait qu'un réseau ne
peut jamais être sûr qu'à 99% au maximum.
perso, je préfères que cette porte ne soit pas ouverte si j'en ai
connaissance
peu importe que ça soit pas la seule porte d'entrée possible
> Tu peux aussi avoir une attaque non ciblée (on va prendre le contrôle > des machines de ceux qui finissent par installer le malware -peut importe > la façon-) et, ô surprise, quand on est sur la machine de madame michu > (via internet "classique") elle a un jouli tunnel tout fraichement ouvert > vers la machine de sa boite...
Statistiquement, les risques ne sont-ils pas à considéré comme nuls ?
t'es sur ?
Non seulement il faut tomber sur l'ordinateur de madame michu, mais en plus il faut le faire au bon moment. Selon moi, ça fait parti du 1% magique, celui qui fait qu'un réseau ne peut jamais être sûr qu'à 99% au maximum.
perso, je préfères que cette porte ne soit pas ouverte si j'en ai connaissance peu importe que ça soit pas la seule porte d'entrée possible
> Le (on) mardi 24 juin 2008 17:29, Stephane Catteau a écrit (wrote) : > >> [1] >> Il ne suffit pas d'intercepter la connexion, il faut aussi se faire >> passer pour la machine à l'origine de celle-ci. Mais bon, il n'est pas >> nécessaire de donner des idées à ceux qui ne les ont pas encore eu. > > Il se trouve que c'est une des premières idées que j'ai eu justement : > comment on fait la différence niveau client entre la présence du proxy et > une attaque man-in-the-middle en cours ?
Seul l'être humain le peut,
je dirais que deja si on a plusieurs serveurs ssh, on peut vérifier qu'ils ont tous une "clé" différente si ils ont tous la même "clé", c'est qu'il y a un proxy (à moins que le proxy ait la possibilité de se faire une "clé" différente par serveur de destination ?)
mais même si on n'a qu'un seul serveur ssh, je crois qu'on a la possibilité une fois connecté de regarder quelle est la "clé" du serveur, et on peut regarder si c'est la même que celle qui a été indiquée à notre client ssh
je me trompe ?
et encore, uniquement s'il sait qu'il y a un proxy dans la chaîne.
c'est vrai qu'il faut avoir l'idée d'aller regarder ça
ce que j'appelle "clé" c'est ce qu'on nous demande de valider la 1ere fois qu'on se connecte à un serveur, et qu'on doit effacer manuellement parce que le client nous fait un msg bloquant quand le serveur change de matériel je sais pas bien comment on appelle ça, en fait
In article <mn.f44b7d86fe818fdc.30736@sc4x.org>,
Stephane Catteau <steph.nospam@sc4x.net> wrote:
mpg n'était pas loin de dire :
> Le (on) mardi 24 juin 2008 17:29, Stephane Catteau a écrit (wrote) :
>
>> [1]
>> Il ne suffit pas d'intercepter la connexion, il faut aussi se faire
>> passer pour la machine à l'origine de celle-ci. Mais bon, il n'est pas
>> nécessaire de donner des idées à ceux qui ne les ont pas encore eu.
>
> Il se trouve que c'est une des premières idées que j'ai eu justement :
> comment on fait la différence niveau client entre la présence du proxy et
> une attaque man-in-the-middle en cours ?
Seul l'être humain le peut,
je dirais que deja si on a plusieurs serveurs ssh, on peut vérifier
qu'ils ont tous une "clé" différente
si ils ont tous la même "clé", c'est qu'il y a un proxy
(à moins que le proxy ait la possibilité de se faire une "clé"
différente par serveur de destination ?)
mais même si on n'a qu'un seul serveur ssh, je crois qu'on a la
possibilité une fois connecté de regarder quelle est la "clé" du
serveur, et on peut regarder si c'est la même que celle qui a été
indiquée à notre client ssh
je me trompe ?
et encore, uniquement s'il sait qu'il y a
un proxy dans la chaîne.
c'est vrai qu'il faut avoir l'idée d'aller regarder ça
ce que j'appelle "clé" c'est
ce qu'on nous demande de valider la 1ere fois qu'on se connecte à un
serveur,
et qu'on doit effacer manuellement parce que le client nous fait un msg
bloquant quand le serveur change de matériel
je sais pas bien comment on appelle ça, en fait
> Le (on) mardi 24 juin 2008 17:29, Stephane Catteau a écrit (wrote) : > >> [1] >> Il ne suffit pas d'intercepter la connexion, il faut aussi se faire >> passer pour la machine à l'origine de celle-ci. Mais bon, il n'est pas >> nécessaire de donner des idées à ceux qui ne les ont pas encore eu. > > Il se trouve que c'est une des premières idées que j'ai eu justement : > comment on fait la différence niveau client entre la présence du proxy et > une attaque man-in-the-middle en cours ?
Seul l'être humain le peut,
je dirais que deja si on a plusieurs serveurs ssh, on peut vérifier qu'ils ont tous une "clé" différente si ils ont tous la même "clé", c'est qu'il y a un proxy (à moins que le proxy ait la possibilité de se faire une "clé" différente par serveur de destination ?)
mais même si on n'a qu'un seul serveur ssh, je crois qu'on a la possibilité une fois connecté de regarder quelle est la "clé" du serveur, et on peut regarder si c'est la même que celle qui a été indiquée à notre client ssh
je me trompe ?
et encore, uniquement s'il sait qu'il y a un proxy dans la chaîne.
c'est vrai qu'il faut avoir l'idée d'aller regarder ça
ce que j'appelle "clé" c'est ce qu'on nous demande de valider la 1ere fois qu'on se connecte à un serveur, et qu'on doit effacer manuellement parce que le client nous fait un msg bloquant quand le serveur change de matériel je sais pas bien comment on appelle ça, en fait
Le (on) samedi 05 juillet 2008 15:37, Thomas a écrit (wrote) :
Seul l'être humain le peut,
Il fait comment ? (C'est une vrai question, pas une façon de dire qu'il ne peut pas.)
mais même si on n'a qu'un seul serveur ssh, je crois qu'on a la possibilité une fois connecté de regarder quelle est la "clé" du serveur, et on peut regarder si c'est la même que celle qui a été indiquée à notre client ssh
je me trompe ?
Je crois pas, mais une fois que tu as fait ça, comment tu fais pour savoir si la machine qui a intercepté la communication est un gentil proxy ou un méchant agresseur ? Parce que mine de rien, ça fait une différence... :-)
Manuel.
Le (on) samedi 05 juillet 2008 15:37, Thomas a écrit (wrote) :
Seul l'être humain le peut,
Il fait comment ? (C'est une vrai question, pas une façon de dire qu'il ne
peut pas.)
mais même si on n'a qu'un seul serveur ssh, je crois qu'on a la
possibilité une fois connecté de regarder quelle est la "clé" du
serveur, et on peut regarder si c'est la même que celle qui a été
indiquée à notre client ssh
je me trompe ?
Je crois pas, mais une fois que tu as fait ça, comment tu fais pour savoir
si la machine qui a intercepté la communication est un gentil proxy ou un
méchant agresseur ? Parce que mine de rien, ça fait une différence... :-)
Le (on) samedi 05 juillet 2008 15:37, Thomas a écrit (wrote) :
Seul l'être humain le peut,
Il fait comment ? (C'est une vrai question, pas une façon de dire qu'il ne peut pas.)
mais même si on n'a qu'un seul serveur ssh, je crois qu'on a la possibilité une fois connecté de regarder quelle est la "clé" du serveur, et on peut regarder si c'est la même que celle qui a été indiquée à notre client ssh
je me trompe ?
Je crois pas, mais une fois que tu as fait ça, comment tu fais pour savoir si la machine qui a intercepté la communication est un gentil proxy ou un méchant agresseur ? Parce que mine de rien, ça fait une différence... :-)
Manuel.
Thomas
In article <g4o89v$2jls$, mpg wrote:
Le (on) samedi 05 juillet 2008 15:37, Thomas a écrit (wrote) :
>> Seul l'être humain le peut, > Il fait comment ? (C'est une vrai question, pas une façon de dire qu'il ne peut pas.)
heu oui, effectivement :-) c'est une question :-)
> mais même si on n'a qu'un seul serveur ssh, je crois qu'on a la > possibilité une fois connecté de regarder quelle est la "clé" du > serveur, et on peut regarder si c'est la même que celle qui a été > indiquée à notre client ssh > > je me trompe ? > Je crois pas, mais une fois que tu as fait ça, comment tu fais pour savoir si la machine qui a intercepté la communication est un gentil proxy ou un méchant agresseur ? Parce que mine de rien, ça fait une différence... :-)
effectivement, j'ai répondu complètement à coté :-D désolé :-)
In article <g4o89v$2jls$3@talisker.lacave.net>, mpg <mpg@elzevir.fr>
wrote:
Le (on) samedi 05 juillet 2008 15:37, Thomas a écrit (wrote) :
>> Seul l'être humain le peut,
>
Il fait comment ? (C'est une vrai question, pas une façon de dire qu'il ne
peut pas.)
heu oui, effectivement :-) c'est une question :-)
> mais même si on n'a qu'un seul serveur ssh, je crois qu'on a la
> possibilité une fois connecté de regarder quelle est la "clé" du
> serveur, et on peut regarder si c'est la même que celle qui a été
> indiquée à notre client ssh
>
> je me trompe ?
>
Je crois pas, mais une fois que tu as fait ça, comment tu fais pour savoir
si la machine qui a intercepté la communication est un gentil proxy ou un
méchant agresseur ? Parce que mine de rien, ça fait une différence... :-)
effectivement, j'ai répondu complètement à coté :-D
désolé :-)
Le (on) samedi 05 juillet 2008 15:37, Thomas a écrit (wrote) :
>> Seul l'être humain le peut, > Il fait comment ? (C'est une vrai question, pas une façon de dire qu'il ne peut pas.)
heu oui, effectivement :-) c'est une question :-)
> mais même si on n'a qu'un seul serveur ssh, je crois qu'on a la > possibilité une fois connecté de regarder quelle est la "clé" du > serveur, et on peut regarder si c'est la même que celle qui a été > indiquée à notre client ssh > > je me trompe ? > Je crois pas, mais une fois que tu as fait ça, comment tu fais pour savoir si la machine qui a intercepté la communication est un gentil proxy ou un méchant agresseur ? Parce que mine de rien, ça fait une différence... :-)
effectivement, j'ai répondu complètement à coté :-D désolé :-)
Bon, évidement, c'est une simplification. N'importe qui n'est pas à même de faire cela, et certains détails sont à régler[1], mais le fait est là, s'il n'existe pas, et on espère tous que ce soit le cas, un proxy SSH n'est pas une chose impossible.
[1] Il ne suffit pas d'intercepter la connexion, il faut aussi se faire passer pour la machine à l'origine de celle-ci. Mais bon, il n'est pas nécessaire de donner des idées à ceux qui ne les ont pas encore eu.
t'es partisan de la sécurité façon MS ?
perso, je préfère savoir quel est l'état des choses, le niveau de risque, ... le plus précisément possible, et que ça soit "le plus public" possible (sachant que si y en a qui essayent de faire des choses pas bien dans ce domaine, ça sera sûrement des gens qui connaissent la chose très très bien de toutes façons)
comme ça on connaît au mieux les outils qu'on utilise
In article <mn.c4137d86e6168cce.30736@sc4x.org>,
Stephane Catteau <steph.nospam@sc4x.net> wrote:
Bon, évidement, c'est une simplification. N'importe qui n'est pas à
même de faire cela, et certains détails sont à régler[1], mais le fait
est là, s'il n'existe pas, et on espère tous que ce soit le cas, un
proxy SSH n'est pas une chose impossible.
[1]
Il ne suffit pas d'intercepter la connexion, il faut aussi se faire
passer pour la machine à l'origine de celle-ci. Mais bon, il n'est pas
nécessaire de donner des idées à ceux qui ne les ont pas encore eu.
t'es partisan de la sécurité façon MS ?
perso, je préfère savoir quel est l'état des choses, le niveau de
risque, ... le plus précisément possible, et que ça soit "le plus
public" possible
(sachant que si y en a qui essayent de faire des choses pas bien dans ce
domaine, ça sera sûrement des gens qui connaissent la chose très très
bien de toutes façons)
comme ça on connaît au mieux les outils qu'on utilise
Bon, évidement, c'est une simplification. N'importe qui n'est pas à même de faire cela, et certains détails sont à régler[1], mais le fait est là, s'il n'existe pas, et on espère tous que ce soit le cas, un proxy SSH n'est pas une chose impossible.
[1] Il ne suffit pas d'intercepter la connexion, il faut aussi se faire passer pour la machine à l'origine de celle-ci. Mais bon, il n'est pas nécessaire de donner des idées à ceux qui ne les ont pas encore eu.
t'es partisan de la sécurité façon MS ?
perso, je préfère savoir quel est l'état des choses, le niveau de risque, ... le plus précisément possible, et que ça soit "le plus public" possible (sachant que si y en a qui essayent de faire des choses pas bien dans ce domaine, ça sera sûrement des gens qui connaissent la chose très très bien de toutes façons)
comme ça on connaît au mieux les outils qu'on utilise
Tu peux aussi avoir une attaque non ciblée (on va prendre le contrôle des machines de ceux qui finissent par installer le malware -peut importe la façon-) et, ô surprise, quand on est sur la machine de madame michu (via internet "classique") elle a un jouli tunnel tout fraichement ouvert vers la machine de sa boite...
Statistiquement, les risques ne sont-ils pas à considéré comme nuls ?
t'es sur ?
Il y a plusieurs dizaine de millions d'adresses IP donnant sur un ordinateur personnel et disons une heure par jour où l'une d'entre elle permet d'avoir accès au tunnel. On doit atteindre le une chance sur un milliard ou quelque chose comme ça.
Non seulement il faut tomber sur l'ordinateur de madame michu, mais en plus il faut le faire au bon moment. Selon moi, ça fait parti du 1% magique, celui qui fait qu'un réseau ne peut jamais être sûr qu'à 99% au maximum.
perso, je préfères que cette porte ne soit pas ouverte si j'en ai connaissance peu importe que ça soit pas la seule porte d'entrée possible
Oui, moi aussi je préfèrerais, mais les utilisateurs de ton réseau préfèrent probablement pouvoir se servir de celui-ci. C'est avant tout une question de compromis entre ce que tu veux bloquer et ce dont les utilisateurs on besoin. Ici, pour bloquer à coup sûr les programmes cités initialement, il faut bloquer le port 80, ce qui limite significativement l'utilité d'être raccordé au vaste monde. Cela ne veut pas dire qu'il faille ignorer le problème, mais il fait partie de ceux qu'il faut combattre autrement (proxy, surveillance des logs et compagnie).
Thomas devait dire quelque chose comme ceci :
Tu peux aussi avoir une attaque non ciblée (on va prendre le contrôle
des machines de ceux qui finissent par installer le malware -peut importe
la façon-) et, ô surprise, quand on est sur la machine de madame michu
(via internet "classique") elle a un jouli tunnel tout fraichement ouvert
vers la machine de sa boite...
Statistiquement, les risques ne sont-ils pas à considéré comme nuls ?
t'es sur ?
Il y a plusieurs dizaine de millions d'adresses IP donnant sur un
ordinateur personnel et disons une heure par jour où l'une d'entre elle
permet d'avoir accès au tunnel. On doit atteindre le une chance sur un
milliard ou quelque chose comme ça.
Non seulement il faut tomber sur l'ordinateur de madame michu, mais en
plus il faut le faire au bon moment.
Selon moi, ça fait parti du 1% magique, celui qui fait qu'un réseau ne
peut jamais être sûr qu'à 99% au maximum.
perso, je préfères que cette porte ne soit pas ouverte si j'en ai
connaissance
peu importe que ça soit pas la seule porte d'entrée possible
Oui, moi aussi je préfèrerais, mais les utilisateurs de ton réseau
préfèrent probablement pouvoir se servir de celui-ci. C'est avant tout
une question de compromis entre ce que tu veux bloquer et ce dont les
utilisateurs on besoin. Ici, pour bloquer à coup sûr les programmes
cités initialement, il faut bloquer le port 80, ce qui limite
significativement l'utilité d'être raccordé au vaste monde.
Cela ne veut pas dire qu'il faille ignorer le problème, mais il fait
partie de ceux qu'il faut combattre autrement (proxy, surveillance des
logs et compagnie).
Tu peux aussi avoir une attaque non ciblée (on va prendre le contrôle des machines de ceux qui finissent par installer le malware -peut importe la façon-) et, ô surprise, quand on est sur la machine de madame michu (via internet "classique") elle a un jouli tunnel tout fraichement ouvert vers la machine de sa boite...
Statistiquement, les risques ne sont-ils pas à considéré comme nuls ?
t'es sur ?
Il y a plusieurs dizaine de millions d'adresses IP donnant sur un ordinateur personnel et disons une heure par jour où l'une d'entre elle permet d'avoir accès au tunnel. On doit atteindre le une chance sur un milliard ou quelque chose comme ça.
Non seulement il faut tomber sur l'ordinateur de madame michu, mais en plus il faut le faire au bon moment. Selon moi, ça fait parti du 1% magique, celui qui fait qu'un réseau ne peut jamais être sûr qu'à 99% au maximum.
perso, je préfères que cette porte ne soit pas ouverte si j'en ai connaissance peu importe que ça soit pas la seule porte d'entrée possible
Oui, moi aussi je préfèrerais, mais les utilisateurs de ton réseau préfèrent probablement pouvoir se servir de celui-ci. C'est avant tout une question de compromis entre ce que tu veux bloquer et ce dont les utilisateurs on besoin. Ici, pour bloquer à coup sûr les programmes cités initialement, il faut bloquer le port 80, ce qui limite significativement l'utilité d'être raccordé au vaste monde. Cela ne veut pas dire qu'il faille ignorer le problème, mais il fait partie de ceux qu'il faut combattre autrement (proxy, surveillance des logs et compagnie).
Stephane Catteau
Thomas n'était pas loin de dire :
Il se trouve que c'est une des premières idées que j'ai eu justement : comment on fait la différence niveau client entre la présence du proxy et une attaque man-in-the-middle en cours ?
Seul l'être humain le peut,
je dirais que deja si on a plusieurs serveurs ssh, on peut vérifier qu'ils ont tous une "clé" différente si ils ont tous la même "clé", c'est qu'il y a un proxy (à moins que le proxy ait la possibilité de se faire une "clé" différente par serveur de destination ?)
mais même si on n'a qu'un seul serveur ssh, je crois qu'on a la possibilité une fois connecté de regarder quelle est la "clé" du serveur, et on peut regarder si c'est la même que celle qui a été indiquée à notre client ssh
je me trompe ?
Tu ne te trompes pas, mais tu oublies que le proxy n'est pas obligé de répondre lui-même à la question. Rien ne l'empèche de transmettre la demande jusqu'au serveur légitime, et de donner au client la réponse qu'il aura lui-même obtenu.
ce que j'appelle "clé" c'est ce qu'on nous demande de valider la 1ere fois qu'on se connecte à un serveur, et qu'on doit effacer manuellement parce que le client nous fait un msg bloquant quand le serveur change de matériel je sais pas bien comment on appelle ça, en fait
On l'appelle comme ça, c'est la clé propre au serveur.
Thomas n'était pas loin de dire :
Il se trouve que c'est une des premières idées que j'ai eu justement :
comment on fait la différence niveau client entre la présence du proxy et
une attaque man-in-the-middle en cours ?
Seul l'être humain le peut,
je dirais que deja si on a plusieurs serveurs ssh, on peut vérifier
qu'ils ont tous une "clé" différente
si ils ont tous la même "clé", c'est qu'il y a un proxy
(à moins que le proxy ait la possibilité de se faire une "clé"
différente par serveur de destination ?)
mais même si on n'a qu'un seul serveur ssh, je crois qu'on a la
possibilité une fois connecté de regarder quelle est la "clé" du
serveur, et on peut regarder si c'est la même que celle qui a été
indiquée à notre client ssh
je me trompe ?
Tu ne te trompes pas, mais tu oublies que le proxy n'est pas obligé de
répondre lui-même à la question. Rien ne l'empèche de transmettre la
demande jusqu'au serveur légitime, et de donner au client la réponse
qu'il aura lui-même obtenu.
ce que j'appelle "clé" c'est
ce qu'on nous demande de valider la 1ere fois qu'on se connecte à un
serveur,
et qu'on doit effacer manuellement parce que le client nous fait un msg
bloquant quand le serveur change de matériel
je sais pas bien comment on appelle ça, en fait
On l'appelle comme ça, c'est la clé propre au serveur.
Il se trouve que c'est une des premières idées que j'ai eu justement : comment on fait la différence niveau client entre la présence du proxy et une attaque man-in-the-middle en cours ?
Seul l'être humain le peut,
je dirais que deja si on a plusieurs serveurs ssh, on peut vérifier qu'ils ont tous une "clé" différente si ils ont tous la même "clé", c'est qu'il y a un proxy (à moins que le proxy ait la possibilité de se faire une "clé" différente par serveur de destination ?)
mais même si on n'a qu'un seul serveur ssh, je crois qu'on a la possibilité une fois connecté de regarder quelle est la "clé" du serveur, et on peut regarder si c'est la même que celle qui a été indiquée à notre client ssh
je me trompe ?
Tu ne te trompes pas, mais tu oublies que le proxy n'est pas obligé de répondre lui-même à la question. Rien ne l'empèche de transmettre la demande jusqu'au serveur légitime, et de donner au client la réponse qu'il aura lui-même obtenu.
ce que j'appelle "clé" c'est ce qu'on nous demande de valider la 1ere fois qu'on se connecte à un serveur, et qu'on doit effacer manuellement parce que le client nous fait un msg bloquant quand le serveur change de matériel je sais pas bien comment on appelle ça, en fait
On l'appelle comme ça, c'est la clé propre au serveur.
