|
L’utilisation d’un outil de télémaintenance, quel qu’il soit, risque de faire apparaître des failles potentielles dans la sécurité de l’entreprise. Dans le cas de VNC, les principaux reproches constatés sont :
- Stockage du mot de passe de connexion en clair dans la base de registres ( anciennes versions de VNC ),
- Connexions "possibles" à tout moment lorsque le module VNC installé sur le client tourne en tant que service,
- Transmission des données en clair entre le poste d’administration et le poste administré.
Par conséquent, en fonction de la sécurité mise en place, les risques encourus vis à vis d’un « utilisateur » mal intentionné – encore appelé pirate – sont :
- Récupération du mot de passe de connexion stocké en clair dans la base de registres,
- Tentative de découverte en "brut force" du mot de passe de connexion,
- Analyse des trames circulant entre le poste d’administration et le poste administré et donc récupération possible des données confidentielles saisies au clavier.
Dès lors, n’importe qui en possession de ce mot de passe serait alors capable de prendre le contrôle du poste client et d’accéder à toutes ses données, y compris confidentielles.
Afin de remédier à ce premier problème, IDEAL Administration et IDEAL Remote utilisent dorénavant TightVNC qui est une version "améliorée" de VNC. Améliorée dans le sens où le mot de passe stocké dans la base de registres est crypté mais aussi au niveau vitesse d'affichage sur des réseaux à faible débit ( prise de contrôle via modem, ligne numéris, WAN, etc... ). De même, au niveau du paramétrage des options, TightVNC est beaucoup plus souple que VNC ( plus besoin de modifier la base de registres via regedit ou autre ).
Il est à noter que TightVNC ( mais aussi VNC ) utilise le mode « challenge response » pour l’authentification. Le principe est du genre : un des postes tire un nombre au hasard, l’envoie à l’autre, le codifie en utilisant le mot de passe, récupère le résultat du même codage par l’autre poste et compare les deux résultats. S’ils sont identiques, le mot de passe est donc correct, sinon, il ne l’est pas ! Dès lors, le mot de passe ne circule jamais sur le réseau.
Pour remédier au second problème potentiel de sécurité, Pointdev a modifié le fonctionnement standard de TightVNC, à savoir que vous avez la possibilité de paramétrer IA de façon à ce que le service "VNC Server" soit stoppé lorsque votre prise de contrôle à distance est terminée. Dès lors, pour que la prise de contrôle à distance soit possible, il faut d'abord démarrer le service "VNC Server" sur le poste distant. Cette opération est effectué automatiquement par IA/IR.
Remarque : Ceci ne s'applique qu'aux postes NT/W2K/XP Pro/Windows 7/10.
Enfin, au niveau des connexions réseau, les communications entre le poste d’administration et le poste administré peuvent dorénavant transiter par un tunnel crypté. Dès lors, toute trame circulant entre ces deux postes est virtuellement indécodable !
Le principe du « tunneling » est le suivant :
- Il s’agit de créer un circuit virtuel – aussi appelé tunnel – entre 2 ou plusieurs hôtes. Dès que ce circuit virtuel est établi, toute donnée transitant à l’intérieur est codée.
- Pour qu’une application située sur ces hôtes utilise ce circuit virtuel, il suffit de rediriger, de translater les ports de communication qu’elle utilise habituellement vers les ports utilisés par ce circuit.
Le schéma 1 illustre ces propos.
Dans le cas « habituel », VNC Viewer ( sur le poste d’administration ) discute avec VNC Server ( sur le poste administré ) via un port TCP local ( disons 2373 ) et un port TCP distant ( 5900 par défaut ). Les données circulant entre les deux postes ( double flèche rouge ) sont alors en « clair ».
Dans le cas de l’utilisation d’un tunnel ( double flèche verte ), le port TCP local 2373 va être redirigé – par exemple – vers le port TCP local 11965 ( entrée du tunnel ) et le port TCP distant 5900 va être redirigé – par exemple – vers le port TCP distant 11965 ( sortie du tunnel ). Le tunnel étant crypté, le tour est joué !
Dans les faits, voici ce qu’il faut faire :
- Sur chacun des postes, mise en place d’un logiciel de « tunneling »,
- Sur le poste à administrer, le logiciel de « tunneling » fonctionne en mode serveur – accepte les connexions entrantes – avec re-direction du port TCP local 5900 vers le port TCP local 11965,
- Sur le poste d’administration, le logiciel fonctionne en mode client – accepte les connexions sortantes – avec re-direction du port TCP local 2373 vers le port TCP local 11965,
- Enfin, il suffit de lancer VNC Viewer avec les paramètres qui vont bien !
Le logiciel de « tunneling » retenu par Pointdev est « Zebedee » (https://www.winton.org.uk/zebedee/)
Comme TightVNC (https://www.tightvnc.com/), c’est un logiciel libre distribué sous licence GPL.
Vous trouverez les sources de la version de TightVNC modifiée par Pointdev ainsi qu'un lien vers les sources de Zebedee, le texte de la licence GPL et les autres outils gratuits mis à disposition par Pointdev sur https://www.pointdev.com/fr/free
Remarques :
- Les trames transitant dans le tunnel sont non seulement cryptées mais en plus elles sont « comprimées ». Par conséquent, dans le cas de l’utilisation de VNC via un réseau à faible débit ( connexions RTC, RNIS, WAN, ADSL, etc.… ) une amélioration des temps de réponse devrait être observée.
Cependant, étant donné que TightVNC utilise également des algorithmes de compression, nous vous déconseillons fortement de fixer la compression de Zebedee à sa valeur maximale ( 9 ). Suite aux nombreux tests effectués par nos soins, la valeur par défaut ( 6 ) convient tout à fait !
- Au niveau de l’analyse des trames circulant sur le réseau, il ne faut pas oublier que ceci est possible – de façon assez simple – à condition que tout le réseau soit basé sur des hubs. Dès qu’il y a des switchs sur le réseau – ce qui est quand même de plus en plus souvent le cas – les analyses ne sont plus possibles, sauf sur un seul et même brin encore géré par un – ou plusieurs – hub(s).
- Pour une sécurité maximale, vous pouvez :
- Stopper le service VNC Server à la fin des sessions de télémaintenance,
- Changer le port d'écoute par défaut de VNC Server sur les postes clients,
- Utiliser Zebedee sur les postes clients et les postes d'administration,
- Utiliser des clés personnelles pour l'authentification Zebedee ( ce n'est pas la configuration mise en place par défaut par notre installateur ). Pour ce, veuillez vous référer directement à la documentation de Zebedee ( document zebedee.htm dans le répertoire C:\Program Files\Pointdev\Zebedee ),
- N'autoriser, au niveau de VNC Server ( sur les postes clients donc ), que les connexions de type Loopback. Dès lors, toute tentative de prise de contrôle en direct ( c'est à dire sans passer par le Zebedee du poste client ) est purement et simplement refusée !
Pour ce, lorsque le service VNC Server est actif : Démarrer / Programmes / Pointdev / GPL / TightVNC / Administration / Show Default Settings puis bouton"Advanced" et cocher la case "Allow ONLY Loopback". Ce paramètre correspond à la clé suivante : KHLM\SOFTWARE\ORL\WinVNC3\LoopBackOnly:DWORD=1
- Un des nombreux intérêts de Zebedee, est la possibilité de faire passer les sessions de télémaintenance à travers un firewall. En effet, étant donné que ses ports d'écoute sont paramétrables, vous pouvez très bien paramétrer celui-ci afin qu'il utilise - par exemple - le port 23189 et ouvrir ce dernier sur votre firewall. Ce port n'étant pas attribué à une application spécifique ( voir Liste des ports TCP et UDP assignés ), celui-ci attire moins l'attention des "pirates" que la série des 5900 ( ou 5800 ), série "réservée" aux outils de la famille VNC.
Remarque : Le port TCP par défaut de Zebedee ( 11965 ) n'est pas référencé par l'IANA. Ceci dit, une rapide recherche sur Google ou autre nous renvoie très vite l'information...
- Enfin, un autre intérêt de Zebedee - qui découle du précédent - est la faculté de permettre la prise de contrôle à distance de plusieurs postes situés derrière un firewall ( ou un routeur filtrant ) en ouvrant un seul et unique port sur ce dernier.
Le principe à mettre en oeuvre est le suivant : ouvrir - par exemple - le port 23189 du firewall et le translater - par exemple - vers le port 23073 d'un poste interne, poste sur lequel est installé Zebedee et servant de relais. Au niveau de la configuration de Zebedee sur ce poste, il va falloir définir - au moins - serverport, target et redirect comme suit :
serverport 23073
redirect 5900
target 192.168.1.0/24
Ceci aura pour effet d'écouter sur le port local 23073 et d'autoriser les redirections - des requêtes clientes - vers le port 5900 de tout poste du réseau 192.168.1.0/24
Enfin, depuis le poste d'administration : zebedee -T 23189 adresse-ip-externe-du-firewall 23000:192.168.1.1:5900 aura pour effet de créer un tunnel entre le poste d'administration et le poste relais distant via le firewall. Ce tunnel aura comme port de départ ( sur le poste d'administration ) le 23000 et comme port de fin ( sur le poste relais, derrière le firewall ) le 23073. Enfin, ayant demandé le port 5900 de la machine 192.168.1.1, le poste relais va donc "transférer" notre demande vers le port d'écoute standard de VNC Server...
Dès lors, la ligne suivante : vncviewer localhost:23000 sur le poste d'administration aura pour effet de faire apparaître l'écran du poste situé derrière le firewall, poste dont l'IP est 192.168.1.1...
Remarque : Cette configuration n'est pas la plus simple ni la plus courante, veuillez donc ne pas vous inquiéter si vous n'avez pas tout compris !
|
Français 
Anglais
Espagnol
Allemand
Italien
Russe
