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 ?
Il fait comment ? (C'est une vrai question, pas une façon de dire qu'il ne peut pas.)
Je serais tenté de répondre "le flaire". Il y a de nombreuses façon d'avoir des doutes, dont par exemple le temps de latence de la connexion, et il y a aussi plusieurs moyens de savoir qu'il y a un proxy dans la chaîne (adresse IP source dans les paquets de réponse, TTL des requêtes ajusté en fonction du nombre de saut jusqu'à la cible, et ainsi de suite), mais il n'y a en fait aucun moyen d'avoir la certitude qu'il n'y a pas de proxy. Du coup, oui, il n'y a que l'être humain qui puisse le savoir, parce qu'il est le seul maillon de la chaîne qui puisse avoir "l'impression que".
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... :-)
Tu contactes l'admin du réseau, et tu croises les doigts pour qu'il te dise que c'est lui ;)
mpg devait dire quelque chose comme ceci :
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.)
Je serais tenté de répondre "le flaire". Il y a de nombreuses façon
d'avoir des doutes, dont par exemple le temps de latence de la
connexion, et il y a aussi plusieurs moyens de savoir qu'il y a un
proxy dans la chaîne (adresse IP source dans les paquets de réponse,
TTL des requêtes ajusté en fonction du nombre de saut jusqu'à la cible,
et ainsi de suite), mais il n'y a en fait aucun moyen d'avoir la
certitude qu'il n'y a pas de proxy.
Du coup, oui, il n'y a que l'être humain qui puisse le savoir, parce
qu'il est le seul maillon de la chaîne qui puisse avoir "l'impression
que".
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... :-)
Tu contactes l'admin du réseau, et tu croises les doigts pour qu'il te
dise que c'est lui ;)
Il fait comment ? (C'est une vrai question, pas une façon de dire qu'il ne peut pas.)
Je serais tenté de répondre "le flaire". Il y a de nombreuses façon d'avoir des doutes, dont par exemple le temps de latence de la connexion, et il y a aussi plusieurs moyens de savoir qu'il y a un proxy dans la chaîne (adresse IP source dans les paquets de réponse, TTL des requêtes ajusté en fonction du nombre de saut jusqu'à la cible, et ainsi de suite), mais il n'y a en fait aucun moyen d'avoir la certitude qu'il n'y a pas de proxy. Du coup, oui, il n'y a que l'être humain qui puisse le savoir, parce qu'il est le seul maillon de la chaîne qui puisse avoir "l'impression que".
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... :-)
Tu contactes l'admin du réseau, et tu croises les doigts pour qu'il te dise que c'est lui ;)
DAPL
Stephane Catteau a écrit :
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.
Si on parle des programmes que j'ai cité au départ, la solution n'est pas là. Il suffit de bloquer l'accès aux serveurs relais qui sont faciles à trouver. Ce n'est pas une communication directe entre la machine cible et celle de celui qui veut la contrôler, mais cela passe par des serveurs publics HTTP(S) qui font relais. Bloquer les adresses publiques correspondantes au niveau du réseau où se trouve la machine cible permet de contrôler le phénomène sans gêner le reste du trafic HTTP(S).
Stephane Catteau a écrit :
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.
Si on parle des programmes que j'ai cité au départ, la solution n'est
pas là.
Il suffit de bloquer l'accès aux serveurs relais qui sont faciles à
trouver. Ce n'est pas une communication directe entre la machine cible
et celle de celui qui veut la contrôler, mais cela passe par des
serveurs publics HTTP(S) qui font relais. Bloquer les adresses publiques
correspondantes au niveau du réseau où se trouve la machine cible permet
de contrôler le phénomène sans gêner le reste du trafic HTTP(S).
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.
Si on parle des programmes que j'ai cité au départ, la solution n'est pas là. Il suffit de bloquer l'accès aux serveurs relais qui sont faciles à trouver. Ce n'est pas une communication directe entre la machine cible et celle de celui qui veut la contrôler, mais cela passe par des serveurs publics HTTP(S) qui font relais. Bloquer les adresses publiques correspondantes au niveau du réseau où se trouve la machine cible permet de contrôler le phénomène sans gêner le reste du trafic HTTP(S).
Stephane Catteau
Thomas n'était pas loin de dire :
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 ?
Non, un peu trop respectueux de la charte du forum parce que c'est moi qui l'ait écrite ;)
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
Disons que je me situe entre les deux. Le full disclosure ne me dérange pas, mais pour certains points, comme celui-ci, je préfère rester évasif. Un vilain qui connait SSH sait déjà ce que je ne dis pas, mais les script-kiddies (et autres wanabe hackers) qui trouvent proxy SSH sur la toile ne savent pas qu'il existe des moyens de le détecter et je préfère que ça reste en l'état puisque cela me permettra justement de le détecter. Je reconnais que pour le coup ce n'est pas très instructif pour le lecteur, mais ta réponse initiale démontre qu'il suffit de s'intéresser un peu au protocole pour trouver les différents points qui peuvent permettre de détecter le proxy.
Thomas n'était pas loin de dire :
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 ?
Non, un peu trop respectueux de la charte du forum parce que c'est moi
qui l'ait écrite ;)
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
Disons que je me situe entre les deux. Le full disclosure ne me
dérange pas, mais pour certains points, comme celui-ci, je préfère
rester évasif. Un vilain qui connait SSH sait déjà ce que je ne dis
pas, mais les script-kiddies (et autres wanabe hackers) qui trouvent
proxy SSH sur la toile ne savent pas qu'il existe des moyens de le
détecter et je préfère que ça reste en l'état puisque cela me permettra
justement de le détecter.
Je reconnais que pour le coup ce n'est pas très instructif pour le
lecteur, mais ta réponse initiale démontre qu'il suffit de s'intéresser
un peu au protocole pour trouver les différents points qui peuvent
permettre de détecter le proxy.
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 ?
Non, un peu trop respectueux de la charte du forum parce que c'est moi qui l'ait écrite ;)
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
Disons que je me situe entre les deux. Le full disclosure ne me dérange pas, mais pour certains points, comme celui-ci, je préfère rester évasif. Un vilain qui connait SSH sait déjà ce que je ne dis pas, mais les script-kiddies (et autres wanabe hackers) qui trouvent proxy SSH sur la toile ne savent pas qu'il existe des moyens de le détecter et je préfère que ça reste en l'état puisque cela me permettra justement de le détecter. Je reconnais que pour le coup ce n'est pas très instructif pour le lecteur, mais ta réponse initiale démontre qu'il suffit de s'intéresser un peu au protocole pour trouver les différents points qui peuvent permettre de détecter le proxy.
Stephane Catteau
DAPL devait dire quelque chose comme ceci :
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.
Si on parle des programmes que j'ai cité au départ, la solution n'est pas là. Il suffit de bloquer l'accès aux serveurs relais qui sont faciles à trouver. Ce n'est pas une communication directe entre la machine cible et celle de celui qui veut la contrôler, mais cela passe par des serveurs publics HTTP(S) qui font relais. Bloquer les adresses publiques correspondantes au niveau du réseau où se trouve la machine cible permet de contrôler le phénomène sans gêner le reste du trafic HTTP(S).
Oui, mais non. Tu limites un peu plus le risque, mais c'est tout. Non seulement tu n'es pas à l'abris d'un rajout de serveur relais, mais en plus tu n'es pas à l'abris d'une réelle volontée de nuire, de la part d'un futur ex-employé, par exemple, qui installerait la machine et qui aurait dans le même temps créé son propre relais[1] sur une machine tierce.
[1] Ce qui n'est pas à la portée de tout le monde mais n'est pas impossible.
DAPL devait dire quelque chose comme ceci :
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.
Si on parle des programmes que j'ai cité au départ, la solution n'est
pas là.
Il suffit de bloquer l'accès aux serveurs relais qui sont faciles à
trouver. Ce n'est pas une communication directe entre la machine cible
et celle de celui qui veut la contrôler, mais cela passe par des
serveurs publics HTTP(S) qui font relais. Bloquer les adresses publiques
correspondantes au niveau du réseau où se trouve la machine cible permet
de contrôler le phénomène sans gêner le reste du trafic HTTP(S).
Oui, mais non. Tu limites un peu plus le risque, mais c'est tout. Non
seulement tu n'es pas à l'abris d'un rajout de serveur relais, mais en
plus tu n'es pas à l'abris d'une réelle volontée de nuire, de la part
d'un futur ex-employé, par exemple, qui installerait la machine et qui
aurait dans le même temps créé son propre relais[1] sur une machine
tierce.
[1]
Ce qui n'est pas à la portée de tout le monde mais n'est pas
impossible.
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.
Si on parle des programmes que j'ai cité au départ, la solution n'est pas là. Il suffit de bloquer l'accès aux serveurs relais qui sont faciles à trouver. Ce n'est pas une communication directe entre la machine cible et celle de celui qui veut la contrôler, mais cela passe par des serveurs publics HTTP(S) qui font relais. Bloquer les adresses publiques correspondantes au niveau du réseau où se trouve la machine cible permet de contrôler le phénomène sans gêner le reste du trafic HTTP(S).
Oui, mais non. Tu limites un peu plus le risque, mais c'est tout. Non seulement tu n'es pas à l'abris d'un rajout de serveur relais, mais en plus tu n'es pas à l'abris d'une réelle volontée de nuire, de la part d'un futur ex-employé, par exemple, qui installerait la machine et qui aurait dans le même temps créé son propre relais[1] sur une machine tierce.
[1] Ce qui n'est pas à la portée de tout le monde mais n'est pas impossible.
