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 ?
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.
On 18 Jun 2008 16:09:35 GMT, DAPL :
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.
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
Fabien LE LEZ a écrit :
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.
Fabien LE LEZ a écrit :
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.
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
DAPL n'était pas loin de dire :
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 n'était pas loin de dire :
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.
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
Stephane Catteau a écrit :
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 a écrit :
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.
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
DAPL n'était pas loin de dire :
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 n'était pas loin de dire :
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é.
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
Stephane Catteau a écrit :
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.
Stephane Catteau a écrit :
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.
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
On 19 Jun 2008 07:46:20 GMT, DAPL :
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.
On 19 Jun 2008 07:46:20 GMT, DAPL <nospam@free.fr>:
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.
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
mdnews a écrit :
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.
mdnews a écrit :
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.
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
mdnews a écrit :
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.
mdnews a écrit :
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.
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
DAPL devait dire quelque chose comme ceci :
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 devait dire quelque chose comme ceci :
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.
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.
