Discussion :

[Philippe Dpt35]

Bonjour,

Dans le cadre de la recherche de mise en place d'une distribution Linux adaptée pour les personnes âgées ignorantes en informatique, j'étudie les solutions de prise de contrôle à distance.
L'idée est que la distribution lance au démarrage les différents serveurs permettant la prise de contrôle de façon à ce que celle-ci puisse se faire sans intervention de la personne à dépanner (lancer une application, communiquer un mot de passe, etc.)

Se posent donc des questions de sécurité pour une prise de contrôle à distance par Internet.
Pour SSH, pas de soucis.

Pour la prise de contrôle graphique, je m'interroge sur la sécurité de VNC, notamment lorsqu'il est utilisé seul (sans passer par un tunnel SSH).
En cherchant des informations sur la sécurité du protocole VNC, je lis des informations contradictoires: on lit que les données et le mot de passe transitent en clair, mais aussi que ce serait crypté. Un spécialiste peut-il me dire ce qu'il en est précisément ?

Je teste le serveur VNC x11VNC. Celui-ci propose une option "Enable SSL". Lorsque celle-ci est activée, le mot de passe et les données transitent-elles vraiment de façon sécurisée ? Lorsque je teste (mais pour l'instant je n'ai testé qu'en réseau local) aucun authentification autre que le mot de passe ne m'est demandée. Est-ce normal (pas de demande de certificat ou de clé) ?

Peut-on considérer qu'une prise de contrôle par VNC peut-être de nos jours suffisamment sécurisée, ou bien est-il indispensable de passer par un tunnel SSH ?
Une solution sans tunnel SSH serait un plus, car la mise en oeuvre par tunnel SSH est plus complexe. Or le but serait de permettre l'installation de cette solution par des personnes qui, si elles devront forcément avoir des connaissances informatiques, ne seront pas forcément des spécialistes.

Toute information complémentaire concernant cette problématique est la bienvenue.

Merci d'avance pour vos éclairages.

[chrtophe]

Salut Philippe,

Pour moi pas très secure.

Cela t'oblige en plus à ouvrir des ports en NAT sur les BOX (comme pour ssh d’ailleurs).

Regardes du coté de Teamviewer, il y a une version Linux. Si tu créé un compte, tu peux prendre la main quand tu veux sur le poste. Tu peux aussi opter pour demander à l'utilisateur de te communiquer son id et son mot de passe, c'est alors lui qui a le contrôle. C'est mieux je trouve.

[Philippe Dpt35]

Bonsoir Chrtophe,

J'ai envisagé TeamViewer que j'utilise déjà pour dépanner des personnes de mon entourage. Mais là je recherche une solution pouvant s'intégrer à la construction d'une distribution libre, et Teamviewer ne rentre pas dans les clous pour ça.
De plus il nécessite que l'utilisateur du poste serveur lance l'application et communique un mot de passe. Or je souhaiterais une solution où la prise de contrôle puisse se faire sans intervention.

[Philippe Dpt35]

P.S.: la question intéressera aussi ceux qui souhaitent pouvoir accéder de façon sécurisée à leur réseau local à l'extérieur de leur domicile.

[LittleWhite]

Bonjour,

Pourquoi ne pas passer par un VPN ?

[Philippe Dpt35]

Bonjour,

Pourquoi ne pas passer par un VPN ?

Cela sera-t-il plus simple que de passer par un tunnel SSH ?

[chrtophe]

Un VPN créé un réseau virtuel entre 2 ou plusieurs postes, avec une carte réseau virtuelle sur chaque poste, ceci de façon transparente. Ce réseau transite sur Internet en crypté. Après connexion en VPN, 2 postes distants seront vus comme 2 postes sur le même réseau local. Un VPN peut être créé entre 2 routeurs ayant cette fonctionnalité, entre un routeur fournissant un logiciel client, entre 2 postes avec une solution logicielle telle que openVPN

SSH est un Secure Shell et a donc comme but de se connecter sur un shell à distance, donc connexion entre 2 postes uniquement, avec une couche de cryptage. Par extension, tu peux ouvrir un tunnel SSH :

SSH peut également être utilisé pour transférer des ports TCP d'une machine vers une autre, créant ainsi un tunnel. Cette méthode est couramment utilisée afin de sécuriser une connexion qui ne l'est pas (par exemple le protocole de récupérations de courrier électronique POP3) en la faisant transférer par le biais du tunnel chiffré SSH.

source Wikipédia.

Pour ces deux solutions, il faut que :
- le ou les ports utilisés soi(en)t ouvert(s) et donc règles de NAT sur les box
- l'initiateur de la connexion connaisse l'adresse IP du poste avec lequel il veut se connecter, problématique pour faire une connexion avec un abonné ADSL, ou la plupart du temps les adresses IP sont dynamiques.

Les solutions comme TeamViewer évitent ces contraintes, car tu passes par un serveur intermédiaire. Mais ce n'est effectivement pas une solution libre. Il est gratuit pour un usage personnel.

Dans ta situation, tu peux envisager un script qui créé un tunnel SSH entre un poste client et ton poste par exemple. Les pré-requis seront :
- que tu fasses les règles NAT nécessaires sur ta box avec le ou le sports utilisés
- que ton ip soit fixe ou que ton script puisses t'atteindre avec une entrée DNS liée à ton IP dynamique, avec un service tel que DynDNS ou NoIP.
- que tu puisses inverser le sens de la connexion, pour que VNC ne prenne pas la main sur ton poste mais que ce soit l'inverse.

Ceci peut être interessant également (à tester) :
http://www.karlrunge.com/x11vnc/ssvnc.html

[Philippe Dpt35]

Dans ta situation, tu peux envisager un script qui créé un tunnel SSH entre un poste client et ton poste par exemple.

C'est ce que j'envisageais, une fenêtre d'accueil après installation de la distribution permettant de faciliter les opérations.
Mais il reste un certain nombre d'opérations à faire côté client qui ne sont pas d'une grande simplicité dans le cadre d'un tunnel SSH. Je peux aussi réfléchir à des scripts à copier et lancer sur le client. Il faut aussi envisager le fait que le client puisse être aussi bien sous Windows que sous Linux.
J'ai déjà mis en œuvre VNC par tunnel SSH, je n'ai pas encore eu l'occasion de le faire par VPN comme le suggère LittleWhite. Il faut que je teste pour voir si c'est plus simple.

Il serait intéressant que des spécialistes donnent leur avis sur la sécurité comparée de ces différentes solutions:
- VNC seul
- VNC par tunnel SSH
- VNC par VPN

Ceci peut être interessant également (à tester) :
http://www.karlrunge.com/x11vnc/ssvnc.html

ça a effectivement l'air intéressant. Je vais tester.

[Philippe Dpt35]

En installant une version récente de Raspbian, j'ai vu que par défaut est installé RealVNC server.

RealVNC offre une option d'accès à distance par un service de cloud, après création d'un compte. La solution est présentée comme sécurisée, et permet également de travailler avec des IP dynamiques, tous les FAI ne proposant pas d'IP statique.

Quelqu'un ayant une expérience d'utilisation de cette solution peut-il en préciser les avantages et inconvénients ? Cette solution est-elle aussi fiable qu'en passant par un tunnel SSH ou par VPN ?

[Philippe Dpt35]

Après vérification, pour ce qui m'intéresse, RealVNC ne conviendra pas.
En effet, RealVNC, comme tightvncserver, ouvrent des sessions X séparées lors d'une connexion à distance. Autrement dit, ce qui s'affiche sur le client VNC n'est pas ce qui apparaît sur l'écran du serveur. Or, dans le cadre d'une aide à distance à des personnes ignorantes en informatique, il est nécessaire que l'on puisse intervenir sur l'écran réel de la personne dépannée afin que l'on puisse lui montrer des opérations à faire. Pour cela il faut utiliser x11vnc.

[Philippe Dpt35]

Pourquoi ne pas passer par un VPN ?

Une chose m'échappe: si j'établis une connexion VNC en passant par un VPN, ce sera crypté entre mon PC et le serveur VPN, mais entre le serveur VPN et le PC hôte, ça transitera en clair ?

[chrtophe]

Tout le trafic d'un VPN est crypté.

[Philippe Dpt35]

Dans mes recherches, je suis tombé là-dessus: http://guacamole.incubator.apache.org/
L'installation et le paramétrage sont beaucoup plus simples que ce que l'on trouve dans les tutos sur Internet, compte-tenu du fait que c'est maintenant dans les dépôts Debian. Une fois installé, les différents fichiers de configuration sont en place et faciles à modifier.

Ensuite, aucune configuration à faire sur les postes clients ni aucun logiciel à installer: un simple navigateur Internet suffit. Et a priori pas de port à rediriger sur la box puisqu'on passe par le navigateur !

[chrtophe]

Interessant,

T'as testé ?

Le retour m’intéresse.

[Philippe Dpt35]

Oui,
ça m'apparaît même plus fluide qu'en VNC par tunnel SSH. Il n'y a en tout cas pas d'effet de défilement de l'affichage. Mais je n'ai testé qu'en réseau local.
Au niveau sécurité, il existe plusieurs plugins pour une authentification complémentaire par base de données, LDAP, Duo... voire même personnalisée.
Voir la doc ici: http://guacamole.incubator.apache.org/doc/gug/

Je pense que c'est la solution que je vais adopter.

[chrtophe]

Quand t'auras testé entre plusieurs sites,fais-moi un feedback stp.

[Philippe Dpt35]

En conditions réelles (nécessité d'un serveur Linux sur lequel installer la solution), je n'aurai pas l'occasion de tester avant longtemps. Si tu veux un retour à court ou moyen terme, je pense qu'il serait préférable que tu trouves des retours par d'autres voies, désolé !

[chrtophe]

Je pense que ça fonctionne en réseau local, pas entre 2 sites. C'est juste du RDP via navigateur. Il faut donc ouvrir le port 3389 vers l’extérieur.

[Philippe Dpt35]

Je viens de tester chez moi en utilisant un PC pour me connecter à travers mon smartphone utilisé comme point d'accès WiFi. Comme j'ai une IP fixe, j'ai pu tester et accéder à ma VM avec Guacamole en serveur en redirigeant le port 8080 vers cette VM sur ma box Internet.
L'adresse d'accès à sa machine est d'ailleurs du type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

http://IPdistante:8080/guacamole

En revanche, dans ce type de configuration, je pense que l'authentification proposée par défaut (login et mot de passe) est trop légère (pas meilleure que VNC direct, le seul avantage semble être que les données sont cryptées)et qu'il conviendrait d'ajouter une seconde authentification avec les extensions proposées.

Là c'est quasiment inutilisable au niveau fluidité, mais je ne suis pas en 4G et mon débit doit être très lent. Il faudra tester avec de l'ADSL ou de la fibre.
Ce n'est pas un affichage X déporté comme dans certains cas: j'ai bien la même chose sur les 2 écrans.

[revedelle]

Je pense que au lieu de choisir entre VPN et tunnel SSH tu peux faire les deux.
Un VPN IPsec dans lequel tu fait passer un tunnel SSH comme ça en cas de défaillance de l'un des deux tu à quand même un "backup" c'est toujours bien de sécuriser chaque couche autant que possible cela permet d'avoir une solution vraiment sûre