Prise de controle et securite
DAPL
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 ?
Fabien LE LEZ
>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 ?
Il me semble que ces logiciels ne représentent pas en soi un problème.
Pour qu'un tel logiciel pose un problème de sécurité, il y a deux
prérequis :
1- Les utilisateurs peuvent installer n'importe quoi sur leurs PC.
2- Une connexion directe est possible depuis une machine hostile
vers un poste de travail.
Chacun de ces prérequis revèle un problème majeur :
1- Si les utilisateurs installent n'importe quoi sans ton
autorisation, VNC (ou autre) est un problème mineur comparé aux
malwares qui risquent d'être installés. Il faut cadenasser les
machines et/ou former les utilisateurs.
2- S'il n'y a pas de firewall pour protéger les machines et ne
laisser passer que ce que tu as décidé d'autoriser, ben c'est le
moment d'en installer.
DAPL
> 2- S'il n'y a pas de firewall pour protéger les machines et ne
> laisser passer que ce que tu as décidé d'autoriser, ben c'est le
> moment d'en installer.
Il y a bien sûr des équipements de sécurité performants, mais qui ne
servent à rien puisque ces softs utilisent les ports HTTP ou HTTPS. On
peut donc se retrouver avec une connexion directe sur des machines, qui
sont elle-même sur un LAN.
Mais l'idée de vérrouiller les machines est évidemment séduisante, si
tant est qu'elle soit réaliste.
Stephane Catteau
> 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 ?
Que les admins de l'entreprise sont des feignasses ? ;)
> 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 ?
Tout dépend de la façon dont le réseau est protégé et de l'autonomie
qui est réellement donnée à ces logiciels.
S'ils ne doivent être accessibles que depuis le LAN de l'entreprise,
le filtre IP en bordure du réseau suffira. Certes, ces logiciels
fonctionnent selon toi sur HTTP/HTTPS, mais les connexions entrantes
sur ces ports n'ayant à se faire que vers la DMZ, les postes présents
sur le réseau ne peuvent pas être atteint de l'extérieur.
S'ils sont au sein d'un WAN et doivent rester accessibles au sein de
celui-ci, en configurant le filtre IP en bordure pour que, en plus du
filtrage pré-cité, il limite l'accès à une ou deux adresses IP données
(celles des machines des admins), les risques sont à peine plus grands.
Enfin, s'il doivent être accessibles depuis le vaste monde, par
exemple pour qu'un admin puisse intervenir de chez lui, à l'entreprise
de faire un effort et offrir un abonnement chez un FAI fournissant une
vraie adresse IP fixe, pour pouvoir en revenir au point précédent.
Cela étant dit, mettre les postes du LAN/WAN sur un netblock non
routable (avec un VPN pour relier les différents réseau en cas de WAN)
couplé à une vraie DMZ reste la meilleure protection contre les
attaques distantes, et donc la meilleure dans le cas présent.
DAPL
> Cela étant dit, mettre les postes du LAN/WAN sur un netblock non
> routable (avec un VPN pour relier les différents réseau en cas de WAN)
> couplé à une vraie DMZ reste la meilleure protection contre les
> attaques distantes, et donc la meilleure dans le cas présent.
C'est évidemment le cas, mais pour recentrer le débat, ces outils (je ne
sais pas si vous les connaissez) s'affranchissent parfaitement des
équipements de filtrages + NAT/PAT.
Hormis empêcher l'utilisateur de pouvoir les installer (non admin du
PC), je ne vois pas de parade orientée réseau contre ça.
En clair, ma question ne porte absolument pas sur la façon de construire
un réseau d'entreprise, mais sur ce que vous pensez de ces outils et les
problèmes éventuels qui peuvent être liés.
Stephane Catteau
>> Cela étant dit, mettre les postes du LAN/WAN sur un netblock non
>> routable (avec un VPN pour relier les différents réseau en cas de WAN)
>> couplé à une vraie DMZ reste la meilleure protection contre les
>> attaques distantes, et donc la meilleure dans le cas présent.
>
> C'est évidemment le cas, mais pour recentrer le débat, ces outils (je ne
> sais pas si vous les connaissez) s'affranchissent parfaitement des
> équipements de filtrages + NAT/PAT.
Ce qui n'a guère de rapport dans le cas présent. C'est le routeur en
bordure du réseau qui se charge de faire la NAT. Pour que les postes du
réseau soient atteints, il faudrait que le-dit routeur ait une règle
NAT pointant sur chacun des postes du LAN en fonction du port adressé.
La cause de la vulnérabilité serait donc les règles définies par
l'admin et non les logiciels utilisés.
> Hormis empêcher l'utilisateur de pouvoir les installer (non admin du
> PC), je ne vois pas de parade orientée réseau contre ça.
L'éducation des utilisateurs[1].
> En clair, ma question ne porte absolument pas sur la façon de construire
> un réseau d'entreprise, mais sur ce que vous pensez de ces outils et les
> problèmes éventuels qui peuvent être liés.
Ce que l'on en pense, Fabien et moi venons de le dire. Les problèmes
n'existent que si l'admin en charge du réseau définie des règles
abhérantes, que ce soit au niveau du filtre IP en bordure ou au niveau
du routeur en bordure. Dans tous les autres cas que je visualise (mais
peut-être en oublié-je), les postes ne sont pas joignables de
l'extérieur, et le risque n'est donc pas plus grand que lorsqu'un
employé laisse son ordinateur allumée pendant qu'il va à la machine à
café.
[1]
Ok, je sors.
DAPL
> Ce qui n'a guère de rapport dans le cas présent. C'est le routeur en
> bordure du réseau qui se charge de faire la NAT. Pour que les postes du
> réseau soient atteints, il faudrait que le-dit routeur ait une règle
> NAT pointant sur chacun des postes du LAN en fonction du port adressé.
> La cause de la vulnérabilité serait donc les règles définies par
> l'admin et non les logiciels utilisés.
Mais non...
A vérifier, mais il me semble que, via un ActiveX, le poste du LAN
établi une connection *HTTP* avec des serveurs intermédiaires sur le
Net. Le poste qui veux prendre la main n'a donc qu'à se connecter sur le
serveur intermédiaire pour accéder au poste cible. Comme MSN, en
quelques sortes.
Remarques, on peux toujours couper l'accès aux serveurs relais, ça sera
le plus efficace.
Fabien LE LEZ
>Il y a bien sûr des équipements de sécurité performants, mais qui ne
>servent à rien puisque ces softs utilisent les ports HTTP ou HTTPS.
Pour HTTP, forcer le passage par un proxy permet de régler le
problème.
Pour HTTPs, je ne sais pas trop ce qui existe. Je suppose qu'on
pourrait déchiffrer puis rechiffrer sur le proxy, en réglant le
navigateur pour accepter le certificat local.
DAPL
> Un relais ne sert d'ailleurs qu'à initialiser la connexion si on ne dispose
> pas d'IP fixe ou de nom DNS. Une fois le socket établi entre les deux
> machines, le relai n'intervient plus.
Oui mais on peut tjs jouer sur les plages d'ip utilisées par ces softs
(toujours comme msn d'ailleurs).
Enfin, pb réglé pour moi en tout cas.
Merci.
DAPL
> L'idée est intéressante, mais ce n'est pas ouvert comme MSN. Une fois que
> l'élève a initialisé la connexion il attend le maître sur une IP et un port
> précis et ce dernier doit en plus lui présenter la clé.
Je viens de "jouer" avec ces trois softs, et le fonctionnement est
vraiment identique a MSN. A chaque fois, le logiciel client sur la
machine cible initie une connexion http ou https sur des serveurs publics.
Pour celui qui veut contrôler cette machine cible, il ne reste qu'a se
connecter à un portail web et démarrer la session.
On peut donc agir sur le moment où la machine monte sa session http(s)
sur les serveurs publics, puisque les plages utilisées sont connues.
En bloquant ces IP, la machine cible devient inaccessible.
Stephane Catteau
>> L'idée est intéressante, mais ce n'est pas ouvert comme MSN. Une fois que
>> l'élève a initialisé la connexion il attend le maître sur une IP et un port
>> précis et ce dernier doit en plus lui présenter la clé.
>
> Je viens de "jouer" avec ces trois softs, et le fonctionnement est
> vraiment identique a MSN.
Peut-être devrais-tu arrêter un instant de jouer et te renseigner sur
ce qu'à précédement dit mdnews. Teamviewer, et c'est probablement le
cas pour les autres que tu as cité[1], à un fonctionnement pleinement
sécurisé. En fait, ce n'est au bout du compte rien d'autre qu'une
adaptation (dans l'esprit) de SSH, qui est le protocole
d'administration qui tourne sur la quasi totalité des serveurs *nix que
tu peux atteindre depuis ton ordinateur.
Alors oui, il y est toujours possible de trouver une faille un jour,
mais ce sera la faille qui permettra d'entrer, et elle n'a rien à voir
avec le fait que le serveur puisse être envoyé dans le vaste monde
grâce à un activeX et utiliser je ne sais quelle machine comme rebond
pour permettre la connexion.
[1]
M'apprendra à rester sur un plan théorique et à ne pas lire la doc
avant.
DAPL
> Peut-être devrais-tu arrêter un instant de jouer et te renseigner sur
> ce qu'à précédement dit mdnews. Teamviewer, et c'est probablement le
> cas pour les autres que tu as cité[1], à un fonctionnement pleinement
> sécurisé.
Certainement, mais si tu lisais les réponses, tu verrais que je n'ai
jamais dis le contraire. Le problème n'est pas l'outil mais son
utilisation (en douce) dans un cadre qui peut être un peu trop libre,
sur des machines appartenant à un réseau local.
Nul doute que ces outils sont bien conçus et très pratique, mais je
souhaitais avoir des avis ou retours d'expérience sur l'impact
positif/négatif que cela pourrait avoir (toujours en rapport au cadre
cité au-dessus). Sur ce plan, je n'ai pas appris grand-chose car vous
n'avez pas compris ma démarche, mais entre-temps je me suis fait mon
idée des ces outils et défini un plan d'action, et c'est là l'essentiel.
Bonne soirée.
DAPL
> DAPL >
>
>> En bloquant ces IP, la machine cible devient inaccessible.
>
Si on propose différents modes d'accès au réseau validés et sécurisés,
ce n'est pas pour voir des utilisateurs accéder à leurs machines de
l'extérieur par d'autres moyens...
Mais c'est un autre débat qui n'aura pas lieu ici !
> De plus, pour bloquer en même les X adresses IP du (des) relais
> multiplié par les Y (milliers de) ports possibles utilisés, il va
> falloir du monde.
>
?? On ne doit pas parler de la même chose.
Je parle de bloquer l'accès sortant http(s) aux serveurs relais depuis
les machines du réseau, c'est tout.
Stephane Catteau
>> Peut-être devrais-tu arrêter un instant de jouer et te renseigner sur
>> ce qu'à précédement dit mdnews. Teamviewer, et c'est probablement le
>> cas pour les autres que tu as cité[1], à un fonctionnement pleinement
>> sécurisé.
>
> Certainement, mais si tu lisais les réponses, tu verrais que je n'ai
> jamais dis le contraire. Le problème n'est pas l'outil mais son
> utilisation (en douce) dans un cadre qui peut être un peu trop libre,
> sur des machines appartenant à un réseau local.
Il n'y a que deux intérêts à l'utilisation en douce d'un tel logiciel
:
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, et là c'est stupide.
Il est plus simple de le faire directement du poste de travail, et ce
n'est ni plus anonyme, ni plus discrêt[1], de le faire par le biais
d'une prise à distance.
La seule chose qui puisse poser problème, c'est une utilisation à
l'insue de la personne l'ayant installée. Mais comme il faut la bonne
clé RSA pour pouvoir se connecter, c'est un faux problème.
> Nul doute que ces outils sont bien conçus et très pratique, mais je
> souhaitais avoir des avis ou retours d'expérience sur l'impact
> positif/négatif que cela pourrait avoir (toujours en rapport au cadre
> cité au-dessus).
Tu as demandé quel était l'impact du point de vue de la sécurité,
quelle était l'intérêt et comment s'en prémunir, toutes ces questions
ont reçu une réponse.
[1]
C'est même au contraire moins discrêt puisque ça laisse des traces sur
les machines en bordure du réseau.
Stephane Catteau
> De plus, pour bloquer en même les X adresses IP du (des) relais
> multiplié par les Y (milliers de) ports possibles utilisés, il va
> falloir du monde.
>
> Tout ça pour le plaisir(?) de bloquer quelques pauvres utilisateurs
> perdus qui demandent simplement assistance à d'autres, pas sûr que
> même le plus méchant des crakers adhère à l'idée.
Accessoirement ça focalise l'attention de l'admin sur un faux
problème, et le détourne donc des vrais failles qu'utiliseraient les
méchants crackers. Une fois la moitié du globe bloqué, pas facile de
repérer les vraies alertes avec toutes les lumières rouges qui
s'allumeront à chaque instant.
Stephane Catteau
>>> En bloquant ces IP, la machine cible devient inaccessible.
>> Oui, mais quel est l'intérêt ?
>
> Si on propose différents modes d'accès au réseau validés et sécurisés,
> ce n'est pas pour voir des utilisateurs accéder à leurs machines de
> l'extérieur par d'autres moyens...
Si on propose différents modes d'accès réellement validés et
sécurisés, les logiciels de prise de contrôle auront énormément de mal
à passer[1]. Et s'ils peuvent passer, c'est que l'on souhaite forcer
les employés à travailler et non blinder le réseau.
[1]
Voir la réponse de Fabien Le Lez à propos des proxies.
Ludovic
>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 ?
C'est couramment utiliser sur des réseaux sécurisés au
plus au niveau, c'est que c'est donc fiable.
Ce genre d'applicatif est indispensable pour la gestion
de parcs informatiques dépassant la centaine de poste.
Sinon, au niveau des utilisateurs, on ne les forme
pas seulement, on leur fait peser des sanctions telles
qu'ils n'ont pas envie de s'amuser à l'apprenti pirate
informatique... C'est très efficace.
@+
Ludovic.
DAPL
> Il n'y a que deux intérêts à l'utilisation en douce d'un tel logiciel
> :
> 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, et là c'est stupide.
> Il est plus simple de le faire directement du poste de travail, et ce
> n'est ni plus anonyme, ni plus discrêt[1], de le faire par le biais
> d'une prise à distance.
>
Le minimum pour le gestionnaire du réseau, c'est au moins de savoir
quels sont les flux qui y transitent et pourquoi.
Surtout si le catalogue de l'entreprise offre déjà des solutions
valables pour le télé-travail.
> Tu as demandé quel était l'impact du point de vue de la sécurité,
> quelle était l'intérêt et comment s'en prémunir, toutes ces questions
> ont reçu une réponse.
Sur les derniers posts uniquement, les autres ressemblant plus à un
cours magistral sur lequel je n'avais posé aucune question, puisque j'en
connais les principes de base.
Fabien LE LEZ
> 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".
>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.
Kevin Denis
>> 2- S'il n'y a pas de firewall pour protéger les machines et ne
>> laisser passer que ce que tu as décidé d'autoriser, ben c'est le
>> moment d'en installer.
>
> Il y a bien sûr des équipements de sécurité performants, mais qui ne
> servent à rien puisque ces softs utilisent les ports HTTP ou HTTPS.
Donc ils ne sont pas performants. Un firewall est capable de différencier
un flux HTTP sur le port 80 d'un flux autre (comme du VNC) sur le port 80.
Pour l'HTTPS, il existe des équipements qui cassent le flux SSL pour
l'analyser (en fait c'est le proxy qui négocie l'échange avec le serveur
distant et qui rechiffre en SSL avec un certificat valide vers le client).
Si ton problème est uniquement technique, il existe surement une
solution permettant de bloquer ces flux. Ce dont tu disposes à l'heure
actuelle ne le permet peut etre pas, donc si tu veux une reponse
technique, c'est: change de matériel.
> On
> peut donc se retrouver avec une connexion directe sur des machines, qui
> sont elle-même sur un LAN.
>
Oui. Mais dans ton schéma de sécurité, je pense que tu ne fais de toute
façon pas une confiance aveugle aux machines situées sur le LAN?
Donc que l'utilisateur soit derrière son clavier dans son bureau, ou
bien de l'autre bout de l'internet et pilotant sa machine, quelle
différence?
Une autre question est: _qui_ a accès aux machines, une fois les
mécanismes dont tu parlais mis en place?
Car imaginer un utilisateur pilotant sa machine n'a rien a voir avec
imaginer une machine du LAN accessible a tous. Bien évidemment, ton cas
ajoute des chainages: l'utilisateur chez lui, donc un poste non maitrisé,
donc potentiellement compromis, ce qui par boule de neige permet à un
tiers de se connecter sur une machine d'entreprise.
> Mais l'idée de vérrouiller les machines est évidemment séduisante, si
> tant est qu'elle soit réaliste.
>
Et pourquoi pas?
--
Kevin
DAPL
> Pour l'HTTPS, il existe des équipements qui cassent le flux SSL pour
> l'analyser (en fait c'est le proxy qui négocie l'échange avec le serveur
> distant et qui rechiffre en SSL avec un certificat valide vers le client).
OK, je vais me renseigner.
En attendant, tu as des références de matériel à donner ?
> Une autre question est: _qui_ a accès aux machines, une fois les
> mécanismes dont tu parlais mis en place?
> Car imaginer un utilisateur pilotant sa machine n'a rien a voir avec
> imaginer une machine du LAN accessible a tous.
A priori, c'est l'utilisateur qui pilote sa machine a distance.
Mais si son login sur le serveur relais est bidon, ça change bcp la donne.
>> Mais l'idée de vérrouiller les machines est évidemment séduisante, si
>> tant est qu'elle soit réaliste.
>>
> Et pourquoi pas?
C'est clair qu'il faut creuser dans cette voie également.
Stephane Catteau
> 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
>> 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
> 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
'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 -+-
Thomas
Stephane Catteau <steph....@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 !
gerbier
> In article <mn.a3ec7d86d...@sc4x.org>,
> Stephane Catteau <steph....@sc4x.net> wrote:
>
>> Il en existe pour tout ou presque.
>
> pour tout ?
> par ex, pour ssh ?
sshproxy ( http://sshproxy-project.org/ )
Stephane Catteau
>> 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.
mpg
> [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
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
>> 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...
Stephane Catteau
Seul l'être humain le peut, et encore, uniquement s'il sait qu'il y a
un proxy dans la chaîne.
Stephane Catteau
>>> 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
> 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
Stephane Catteau <steph....@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
--
Téléassistance / Télémaintenance
http://www.portparallele.com/ThomasDECONTES/
Thomas
Stephane Catteau <steph....@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
mpg
>> 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
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é :-)
Thomas
Stephane Catteau <steph....@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
Stephane Catteau
>>> 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
>>> 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.
Stephane Catteau
>>> 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 ;)
DAPL
> 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
>> 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
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.