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 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.
[1] Il en existe pour tout ou presque.
DAPL 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.
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.
[1] Il en existe pour tout ou presque.
Stephane Catteau
Fabien LE LEZ n'était pas loin de dire :
Il n'y a que deux intérêts à l'utilisation en douce d'un tel logiciel
Dans le cas où l'utilisateur est raisonnable, oui. Mais l'utilisateur peut très bien avoir installé le logiciel sans savoir ce qu'il fait, par le principe du "virus belge".
Si l'on en reste dans les logiciels cités, le risque n'en est pas un, puisqu'il faudra présenter la bonne clé pour pouvoir entrer. Même en considérant que l'utilisateur ait été jusqu'à générer une clé sans savoir ce qu'il faisait, cela ne la donne pas au futur attaquant.
1) Travailler de chez soi, ce qui est tout bénef' pour l'entreprise 2) Pirater le réseau de l'entreprise de chez soi
Il n'y a pas forcément de différence entre les deux. Si Mme Michu accède à son PC professionnel via son PC personnel rempli à ras-bord de cochonneries diverses, je n'ose même pas imaginer le résultat.
S'infiltrer dans un tunnel crypté n'est pas à la portée du premier malware venu, non ? Du coup il s'agit d'une attaque ciblée, et le logiciel de prise de contrôle à distance n'est probablement pas la seule entrée possible.
Fabien LE LEZ n'était pas loin de dire :
Il n'y a que deux intérêts à l'utilisation en douce d'un tel logiciel
Dans le cas où l'utilisateur est raisonnable, oui.
Mais l'utilisateur peut très bien avoir installé le logiciel sans
savoir ce qu'il fait, par le principe du "virus belge".
Si l'on en reste dans les logiciels cités, le risque n'en est pas un,
puisqu'il faudra présenter la bonne clé pour pouvoir entrer. Même en
considérant que l'utilisateur ait été jusqu'à générer une clé sans
savoir ce qu'il faisait, cela ne la donne pas au futur attaquant.
1) Travailler de chez soi, ce qui est tout bénef' pour l'entreprise
2) Pirater le réseau de l'entreprise de chez soi
Il n'y a pas forcément de différence entre les deux. Si Mme Michu
accède à son PC professionnel via son PC personnel rempli à ras-bord
de cochonneries diverses, je n'ose même pas imaginer le résultat.
S'infiltrer dans un tunnel crypté n'est pas à la portée du premier
malware venu, non ? Du coup il s'agit d'une attaque ciblée, et le
logiciel de prise de contrôle à distance n'est probablement pas la
seule entrée possible.
Il n'y a que deux intérêts à l'utilisation en douce d'un tel logiciel
Dans le cas où l'utilisateur est raisonnable, oui. Mais l'utilisateur peut très bien avoir installé le logiciel sans savoir ce qu'il fait, par le principe du "virus belge".
Si l'on en reste dans les logiciels cités, le risque n'en est pas un, puisqu'il faudra présenter la bonne clé pour pouvoir entrer. Même en considérant que l'utilisateur ait été jusqu'à générer une clé sans savoir ce qu'il faisait, cela ne la donne pas au futur attaquant.
1) Travailler de chez soi, ce qui est tout bénef' pour l'entreprise 2) Pirater le réseau de l'entreprise de chez soi
Il n'y a pas forcément de différence entre les deux. Si Mme Michu accède à son PC professionnel via son PC personnel rempli à ras-bord de cochonneries diverses, je n'ose même pas imaginer le résultat.
S'infiltrer dans un tunnel crypté n'est pas à la portée du premier malware venu, non ? Du coup il s'agit d'une attaque ciblée, et le logiciel de prise de contrôle à distance n'est probablement pas la seule entrée possible.
DAPL
Stephane Catteau a écrit :
Si l'on en reste dans les logiciels cités, le risque n'en est pas un, puisqu'il faudra présenter la bonne clé pour pouvoir entrer. Même en considérant que l'utilisateur ait été jusqu'à générer une clé sans savoir ce qu'il faisait, cela ne la donne pas au futur attaquant.
Ca c'est valable pour TeamViewer, pas pour les autres. Un compte créé avec un password "a la con" donnera un accès sur la machine (peut-être pas en contrôle à distance, puisqu'il faudra pouvoir ouvrir une session locale ou domaine - moins facile, déjà -, mais en copie de fichier par exemple)
Stephane Catteau a écrit :
Si l'on en reste dans les logiciels cités, le risque n'en est pas un,
puisqu'il faudra présenter la bonne clé pour pouvoir entrer. Même en
considérant que l'utilisateur ait été jusqu'à générer une clé sans
savoir ce qu'il faisait, cela ne la donne pas au futur attaquant.
Ca c'est valable pour TeamViewer, pas pour les autres.
Un compte créé avec un password "a la con" donnera un accès sur la
machine (peut-être pas en contrôle à distance, puisqu'il faudra pouvoir
ouvrir une session locale ou domaine - moins facile, déjà -, mais en
copie de fichier par exemple)
Si l'on en reste dans les logiciels cités, le risque n'en est pas un, puisqu'il faudra présenter la bonne clé pour pouvoir entrer. Même en considérant que l'utilisateur ait été jusqu'à générer une clé sans savoir ce qu'il faisait, cela ne la donne pas au futur attaquant.
Ca c'est valable pour TeamViewer, pas pour les autres. Un compte créé avec un password "a la con" donnera un accès sur la machine (peut-être pas en contrôle à distance, puisqu'il faudra pouvoir ouvrir une session locale ou domaine - moins facile, déjà -, mais en copie de fichier par exemple)
Eric Masson
Stephane Catteau writes:
'Lut,
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.
Dans le cas du https, comme mentionné ailleurs dans le fil, si le proxy ne fait pas un MITM pour la négotiation ssl, la seule chose qu'il verra est un CONNECT.
Il semble que des outils comme Delegate, SSL-mitm, Charlesproxy en soient capables.
Pour ma part, face à un proxy ayant ce type de fonctionnement, je n'utilise plus le https :)
-- > Je cherche à calculer la distance de deux points sur une sphère. J'aurais peut-être çà, mais il faut absolument que les points soient à la même distance l'un de l'autre. -+- DC in GNU: Savoir sphère le point -+-
Stephane Catteau <steph.nospam@sc4x.net> writes:
'Lut,
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.
Dans le cas du https, comme mentionné ailleurs dans le fil, si le proxy
ne fait pas un MITM pour la négotiation ssl, la seule chose qu'il verra
est un CONNECT.
Il semble que des outils comme Delegate, SSL-mitm, Charlesproxy en
soient capables.
Pour ma part, face à un proxy ayant ce type de fonctionnement, je
n'utilise plus le https :)
--
> Je cherche à calculer la distance de deux points sur une sphère.
J'aurais peut-être çà, mais il faut absolument que les points
soient à la même distance l'un de l'autre.
-+- DC in GNU: Savoir sphère le point -+-
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.
Dans le cas du https, comme mentionné ailleurs dans le fil, si le proxy ne fait pas un MITM pour la négotiation ssl, la seule chose qu'il verra est un CONNECT.
Il semble que des outils comme Delegate, SSL-mitm, Charlesproxy en soient capables.
Pour ma part, face à un proxy ayant ce type de fonctionnement, je n'utilise plus le https :)
-- > Je cherche à calculer la distance de deux points sur une sphère. J'aurais peut-être çà, mais il faut absolument que les points soient à la même distance l'un de l'autre. -+- DC in GNU: Savoir sphère le point -+-
Thomas
In article , Stephane Catteau wrote:
Il en existe pour tout ou presque.
pour tout ? par ex, pour ssh ?
-- j'agis contre l'assistanat, je travaille dans une SCOP !
In article <mn.a3ec7d86d51090e5.30736@sc4x.org>,
Stephane Catteau <steph.nospam@sc4x.net> wrote:
Il en existe pour tout ou presque.
pour tout ?
par ex, pour ssh ?
--
j'agis contre l'assistanat, je travaille dans une SCOP !
En soi rien n'empèche de faire un proxy SSH transparent. Relativement parlant, il suffit qu'il fonctionne dans un sens comme un client et dans l'autre sens comme s'il n'existait pas. Lorsqu'un client cherche à se connecter à un serveur, le proxy reprend la demande à son compte, ce qui fait que pour le serveur, la connexion sera effective entre lui et le proxy. Dans le même temps, le proxy relai sans modification, mais après les avoir appliqué à lui-même, toutes les réponses du serveur, ce qui fait que du point de vue du client, la connexion est directe avec le serveur. Et voilà un beau proxy SSH à même de comprendre tout ce qui se dit. 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.
Thomas n'était pas loin de dire :
Il en existe pour tout ou presque.
pour tout ?
"ou presque".
par ex, pour ssh ?
En soi rien n'empèche de faire un proxy SSH transparent. Relativement
parlant, il suffit qu'il fonctionne dans un sens comme un client et
dans l'autre sens comme s'il n'existait pas. Lorsqu'un client cherche à
se connecter à un serveur, le proxy reprend la demande à son compte, ce
qui fait que pour le serveur, la connexion sera effective entre lui et
le proxy. Dans le même temps, le proxy relai sans modification, mais
après les avoir appliqué à lui-même, toutes les réponses du serveur, ce
qui fait que du point de vue du client, la connexion est directe avec
le serveur. Et voilà un beau proxy SSH à même de comprendre tout ce qui
se dit.
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.
En soi rien n'empèche de faire un proxy SSH transparent. Relativement parlant, il suffit qu'il fonctionne dans un sens comme un client et dans l'autre sens comme s'il n'existait pas. Lorsqu'un client cherche à se connecter à un serveur, le proxy reprend la demande à son compte, ce qui fait que pour le serveur, la connexion sera effective entre lui et le proxy. Dans le même temps, le proxy relai sans modification, mais après les avoir appliqué à lui-même, toutes les réponses du serveur, ce qui fait que du point de vue du client, la connexion est directe avec le serveur. Et voilà un beau proxy SSH à même de comprendre tout ce qui se dit. 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.
mpg
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 ?
Manuel.
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 ?
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 ?
Manuel.
Eric Razny
Le Fri, 20 Jun 2008 14:50:00 +0000, Stephane Catteau a écrit :
DAPL 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).
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.
Eric
Le Fri, 20 Jun 2008 14:50:00 +0000, Stephane Catteau a écrit :
DAPL 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).
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 Fri, 20 Jun 2008 14:50:00 +0000, Stephane Catteau a écrit :
DAPL 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).
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.
Eric
Eric Razny
Le Fri, 20 Jun 2008 14:55:36 +0000, Stephane Catteau a écrit :
Il n'y a pas forcément de différence entre les deux. Si Mme Michu accède à son PC professionnel via son PC personnel rempli à ras-bord de cochonneries diverses, je n'ose même pas imaginer le résultat.
S'infiltrer dans un tunnel crypté n'est pas à la portée du premier malware venu, non ? Du coup il s'agit d'une attaque ciblée, et le logiciel de prise de contrôle à distance n'est probablement pas la seule entrée possible.
Salut 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...
Le Fri, 20 Jun 2008 14:55:36 +0000, Stephane Catteau a écrit :
Il n'y a pas forcément de différence entre les deux. Si Mme Michu
accède à son PC professionnel via son PC personnel rempli à ras-bord
de cochonneries diverses, je n'ose même pas imaginer le résultat.
S'infiltrer dans un tunnel crypté n'est pas à la portée du premier
malware venu, non ? Du coup il s'agit d'une attaque ciblée, et le
logiciel de prise de contrôle à distance n'est probablement pas la
seule entrée possible.
Salut
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...
Le Fri, 20 Jun 2008 14:55:36 +0000, Stephane Catteau a écrit :
Il n'y a pas forcément de différence entre les deux. Si Mme Michu accède à son PC professionnel via son PC personnel rempli à ras-bord de cochonneries diverses, je n'ose même pas imaginer le résultat.
S'infiltrer dans un tunnel crypté n'est pas à la portée du premier malware venu, non ? Du coup il s'agit d'une attaque ciblée, et le logiciel de prise de contrôle à distance n'est probablement pas la seule entrée possible.
Salut 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...
