RustDesk

Au fil des ans TeamViewer s’est imposé dans l'IT. Au départ pseudo gratuit ce produit offre maintenant de plus en plus de fonctionnalités (souvent inutiles) et son cout augmente d’années en années. On pourrait imaginer le remplacer par AnyDesk, mais hélas leur politique est quasiment identique et ce serait reculer pour mieux sauter.

Pendant le confinement certains en ont eu assez de se faire “raquetter”. Si le mot vous parait fort, constatez simplement les augmentations successives dont la dernière de 20% que rien ne justifie à mes yeux, l'éditeur se justifiant quant à lui par l'ajout de fonctionnalités qui me sont inutiles. Entendons nous bien, tout a un prix et tout travail ou service mérite une rémunération, mais tout doit rester dans la nuance, même quand on se retrouve dans une position de domination, ce qui est d'ailleurs le cas pour d'autres, comme Microsoft et ses dernières augmentations au niveau 365 ou Azure...

Bref, c'est donc ainsi qu'une petite équipe de développeurs a créé RustDesk. RustDesk offre les mêmes fonctionnalités de base dans le cadre de l’open source. Je teste Rustdesk depuis près d’un an et j’estime que l’heure est venue de franchir le pas.

RustDesk est disponible sous différentes distributions Linux, MacOS, Windows, Android et IOS.

Il existe plusieurs façons d’utiliser RustDesk :

Version isolée sans serveur

La plus simple et totalement gratuite, mais qui présente quelques inconvénients :

  • Pas de chiffrement, cela veut dire que toutes les infos circulent en clair (pas sécure pour les clients, mauvaise pratique).
  • Lenteurs possibles car ça utilise les serveurs publics, ce qui reste limité.
  • Pas de carnet d’adresse synchronisé entre les devices clients. Et là ça bloque car comme beaucoup de monde j'utilise un PC fixe au bureau et un laptop quand je me déplace, sur lequel je souhaite retrouver mon environnement de travail. Ils auraient pu envisager une synchronisation de type "drive", mais cela aurait posé des questions de sécurité car en plus de synchroniser les identifiants il faut stocker des mots de passe.

Version gratuite avec serveur

Toujours gratuit (en dehors du cout d'un serveur VPS (qui peut être mutualisé)), et on résous la question du chiffrement :

  • Le serveur sert de relais (amélioration de la vitesse) et de serveur de chiffrement afin de sécuriser les liens.

Version payante avec serveur privé

La totale qui va couter quelques euros (10 € / mois pour deux utilisateurs, ou 20 € /mois pour 20 utilisateurs + le serveur), mais à mon sens indispensable dans un cadre professionnel

  • Le serveur offre une console qui permet de lister les clients installés et éventuellement les partager
    • Seul l’admin peut activer les partages à ce stade. Partager fait remonter les ID pour un autre utilisateur, mais le mot de passe associé au device reste nécessaire.
  • Avoir des logs, qui se connecte à quoi (dispo pour chaque utilisateur), transferts de fichiers.
  • Changer l’ID d’un client
  • Utiliser un carnet d’adresse qui sera synchronisé entre les clients de chaque utilisateur, mais non accessible à l’admin.
  • Appliquer des stratégies
  • Et d'autres fonctionnalités à venir car le projet est en constante évolution....

Il n'existe pour l'instant pas de version Cloud et je n'ai pas le sentiment que ce soit dans l'ordre des priorités de l'équipe.

Installation

Je me place ici dans le cadre de la version serveur après avoir acquis une licence.

L'installation du serveur se fait sous Linux ou dans un container Docker. La procédure est décrite ici et je ne vais pas la reprendre. J'ai choisit Docker pour la facilité d'un Compose...

Coté client, contrairement à TeamViewer qui fonctionne uniquement avec une infrastructure cloud, RustDesk fonctionne avec une infrastructure privée si l’on veut disposer de toutes ses fonctionnalités. Quand on installe le client il va donc falloir configurer les informations liées au serveur. Ce device sera alors uniquement accessible par des clients également configurés pour ce serveur (tout au moins pour l’instant car il y a des évolutions en cours).

Pour configurer le client afin qu’il soit reconnu par le serveur on a plusieurs solutions :

  • Soit on installe l’exe normalement et on copie la config dans ID / Relay server
Qfi0TWlxGWrUdfqdsfVENxxxxxxxxxxxxxxxxxxxxxxxqfsqdfN3boJye

  • Soit on renomme l’exe d’installation afin d’y intégrer la clé, ce qui va donner quelque chose du genre:
rustdesk-licensed-Qfi0TWlxGWrUkR5Vxxxxxxxdfsdfsdfsdfye.exe
  • Soit on crée un script de déploiement et ainsi appliquer la configuration après l’installation dans le cadre d’un script PowerShell, on dispose alors de ces trois commandes, et on verra plus bas ce à quoi peut ressembler un script de déploiement  :

Se connecter

En général quand on utilise ce genre de produit, souvent pour de l'assistance client ou de la gestion de serveurs, il y a deux types d'installations :

  • Le device client, le mien, sur lequel après avoir configuré le serveur (chapitre précédent), je vais me connecter avec l'identifiant fournit par l'administrateur du serveur : 
  • Le device distant auquel on va affecter (ou pas) un utilisateur

Affecter un device à un utilisateur

Si on affecte un device à un utilisateur, cet utilisateur (et uniquement lui) verra ce device distant monter dans son logiciel client. Il pourra également l’ajouter à son carnet d’adresse personnel. Si on ne l'affecte pas, tous les utilisateurs le verront, pourront l'ajouter à leur carnet d'adresse et s'y connecter (sous réserve de disposer du mot de passe préalablement défini).

Des fonctionnalités de groupe et de partage de groupe sont également prévues. Il est ainsi possible de partager les devises affectés à un groupe à un autre utilisateur. A noter que pour l'instant groupe = utilisateur et que l'on ne peut pas directement affecter des devices à un groupe isolé. La solution consiste donc à créer un utilisateur virtuel qui partagera ses devices avec d'autres utilisateurs. Par exemple j'ai créé un utilisateur virtuel Société A qui partage ses devices avec les deux personnes chargés de la maintenance de Société A. Ca consomme une licence utilisateur mais je n'ai pas trouvé mieux pour l'instant.

Il existe plusieurs façons pour y parvenir :

  • En se connectant avec son user/password (mais c’est une très mauvaise idée que de faire ça sur le PC d’un client)
  • En l’associant dans l’interface d’administrateur (mais seul l’admin peut le faire)
  • En utilisant l’API sur le client dans le cadre d’un déploiement vie un script

Pour ça il faut un token. Les tokens qui permettent l’accès à l’API sont délivrés par l’admin.

PS C:\Program Files\RustDesk>.\RustDesk.exe  –assign –token "rapi_xxxxxxxxdyw==" –user_name “admin” | more

La console

Chaque utilisateur peut voir la liste de ses devices, l’état de la connexion ainsi que diverses infos (par exemple :

ip: 82.65.xxx.xxx;
version: 1.2.3;
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz, 2.53GHz, 4/4 cores; mem: 8GB

Un log est également disponible tant pour les connections que pour les transferts de fichiers. Cette console est destinée à évoluer pour plus de fonctionnalités.

L'administrateur peut quant à lui, outre gérer utilisateurs et devices, affecter des stratégies aux utilisateurs et devices :

Script PowerShell d’installation

On ne dispose pour l'instant pas de .msi et ce script est un peu simpliste (il en existe pour d'autres O/S ici). Pour faire simple je conseille d’ouvrir une session PS en mode admin. Mais il est également possible de faire une élévation dans le script (voir à la fin). Pour l’instant attention à indiquer la version de l'exe sur la bonne ligne…

Version client isolé

$rustdesk_pw="mot_de_passe_permanent"
$ErrorActionPreference= 'silentlycontinue'

################################### Please Do Not Edit Below This Line #########################################

If (!(Test-Path C:\Temp))
{
    New-Item -ItemType Directory -Force -Path C:\Temp > null
}

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

cd C:\Temp
Invoke-WebRequest "https://github.com/rustdesk/rustdesk/releases/download/1.2.3/rustdesk-1.2.3-x86_64.exe" -Outfile "rustdesk.exe"
Start-Process .\rustdesk.exe --silent-install # -wait
$ServiceName = 'Rustdesk'
$arrService = Get-Service -Name $ServiceName -ErrorAction SilentlyContinue
if ($arrService -eq $null)
{
    Start-Sleep -seconds 20
}
cd $env:ProgramFiles\RustDesk\
$rustdesk_id = (.\RustDesk.exe --get-id | out-host)

.\RustDesk.exe --password $rustdesk_pw | out-host

Version "mes machines"

################################# VARIABLES #######################################
$rustdesk_pw="PasswordPermanent"  # Celui du device distant
$rustdesk_token="MonTocken"
$rustdesk_cfg="Qfi0TWlxxxxxxxxxxxxxxxxxxxxxxxxxxN3boJye" # Clé de configuration
$ErrorActionPreference= 'silentlycontinue'
################################### SCRIPT ########################################

If (!(Test-Path C:\Temp))
{
    New-Item -ItemType Directory -Force -Path C:\Temp > null
}
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
cd C:\Temp
Invoke-WebRequest "https://github.com/rustdesk/rustdesk/releases/download/1.2.3/rustdesk-1.2.3-x86_64.exe" -Outfile "rustdesk.exe" # Changer la version le cas échéant

Start-Process .\rustdesk.exe --silent-install # -wait
$ServiceName = 'Rustdesk'
$arrService = Get-Service -Name $ServiceName -ErrorAction SilentlyContinue

if ($arrService -eq $null)
{
    Start-Sleep -seconds 20
}
cd $env:ProgramFiles\RustDesk\
$rustdesk_id = (.\RustDesk.exe --get-id | out-host)

.\RustDesk.exe --config $rustdesk_cfg | out-host
.\RustDesk.exe --password $rustdesk_pw | out-host
Start-Sleep -Seconds 5
.\RustDesk.exe --assign --token $rustdesk_token --user_name manu | out-host

Elévation (le cas échéant à ajouter au début du script)

if (-Not ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
    if ([int](Get-CimInstance -Class Win32_OperatingSystem | Select-Object -ExpandProperty BuildNumber) -ge 6000) {
        Start-Process PowerShell -Verb RunAs -ArgumentList "-NoProfile -ExecutionPolicy Bypass -Command `"cd '$pwd'; & '$PSCommandPath';`"";
        Exit;
    }
}

Le cas des serveurs Windows et du RDP

Si on installe RustDesk sur un serveur Windows va se retrouver face à deux possibilités, activer ou pas le partage de session RDP (une problématique identique existe avec TeamViewer qui a choisit de fournir deux ID, cela concerne principalement les administrateurs de serveurs, qu’ils soient premise ou cloud) :

  • Non activé : RustDesk va proposer une ouverture de session, il est possible d’enregistrer le mot de passe dans le client, et cette ouverture de session déconnectera l’éventuel utilisateur connecté en RDP.
  • Activé : Dans ce cas RustDesk partage la connexion RDP active et si on déconnecte la session RDP ça déconnecte la session RustDesk (qui peut toutefois se reconnecter s’il dispose des identifiants Windows.
    • Il existe toutefois un problème, dans ce mode rien ne permet actuellement de choisir la session sur laquelle va s’opérer le partage, il y a donc un risque de se concerter sur la session d’un utilisateur actif dans le cas d’un serveur de bureaux virtuels. (ticket ouvert en cours).

Conclusion

RustDesk est constante évolution et j'y reviendrait certainement ici. En attendant j'ai déployé une trentaine de devices sans observer de problèmes particulier si je compare à mon classique TeamViewer.

EDIT 10/12/2023

J'avais demandé une option afin de simplifier la mise en œuvre et ne pas associer des installations distantes et non contrôlées de façon permanentent à mon serveur. Sur le client on installe simplement Rustdesk de façon interactive, ou on l'installer avec le script simplifié qui permet seulement de définir un mot de passe permanent.

Il est maintenait possible, dans une infrastructure avec un serveur Pro de se connecter à un client isolé tout en bénéficiant du chiffrage du serveur en saisissant son ID@public :

Ainsi la machine sera contrôlée et chiffrée de façon temporaire par le serveur, sans pour autant l'enregistrer de faon permanente dans celui ci. Il sera toutefois possible de l'ajouter à son carnet d'adresse et de lui affecter une étiquette, mais pas de la partager avec d'autres utilisateurs du serveur. Autre avantage, s'autres intervenant pourront se connecter à cette machine, même s'ils ne fort pas partie du périmètre du serveur.

 

 

RDP & Guacamole

Et non, je ne suis hélas pas parti en vacances au Mexique déguster du guacamole arrosé de téquila ! Mais j'ai trouvé la solution que je cherchait depuis longtemps pour sécuriser les accès RDP. Comme chacun le sait il n'est vraiment pas conseillé de laisser ouvert sur internet le port RDP qui est plutôt vulnérable. Hélas pensant le confinement beaucoup de clients ont du mettre en place des solutions dans l'urgence et dans bien des cas il était impossible de verrouiller au minimum ce port sur une IP fixe....

Bien sur Microsoft a une solution (RDP Gateway), couteuse et complexe, donc pas adaptée à de petites entreprises dont les couts IT explosent déjà. Je restait donc en éveil à la recherche d'une solution quand je suis tombé sur le projet open-source Guacamole en HTML5. Et surprise, celui ci fonctionne vraiment bien ! Le principe est simple et reprends celui des autres projets, une machine va servir de proxy afin d'exposer le RDP (mais aussi SSH, Telnet et VNC).

Installation

S'il est possible d'installer Guacamole en natif comme c'est très bien expliqué ici, après avoir testé différentes options, par facilité je vais faire ça sous Docker en utilisant ce projet.

Je vais donc monter une VM Linux Ubuntu et y configurer Docker et Docker Compose. Pour cette partie je vous laisse chercher, d'autres expliquent mieux que moi.

Pour déployer Guacamole on a besoin de 3 services :

  • GUACD : Le cœur de Guacamole qui va servir à connecter les différents services (RDP, SSH, etc...)
  • PostgreSQL : Une base de donnée (qui peut être également MySQL ou encore l'utilisation d'une base externe)
  • Guacamole : Le composant FrontEnd qui va gérer les connections, les services et les utilisateurs.

Docker Compose

L'auteur de l'intégration a eu la bonne idée de nous fournir un script d'installation. On va donc l'utiliser et on se servira de Docker Compose plus tard afin d'ajuster la configuration.

sudo git clone "https://github.com/boschkundendienst/guacamole-docker-compose.git"
cd guacamole-docker-compose
./prepare.sh
sudo docker-compose up -d

Si tout se passe bien on peut se connecter sur https://ip_serveur:8443/guacamole. Le nom d'utilisateur par défaut est guacadmin avec mot de passe guacadmin. La première chose à faire est bien sur de le changer.

On pourra facilement configurer un serveur RDP et s'y connecter pour avoir les premières impressions. Je trouve que le rendu RDP en HTML5 est fluide, même en regardant des vidéos sur YouTube à une bonne résolution. Attention à ne pas perdre de vue que c'est le serveur Guacamole qui doit encaisser le trafic entrant et sortant. Selon l'usage et le nombre de clients il faudra donc le dimensionner correctement.

Je ne vais pas m'étendre sur les différentes options, l'interface et claire, la documentation également et d'autres en parlent très bien.

Sécurisation

Il n'est bien sur pas question d'exposer ce serveur directement sur internet et je vais tester deux solutions de reverse proxy, je commence par éditer le fichier docker-compose.yml afin de supprimer le proxy Nginx préinstallé histoire de ne pas empiler les proxys. J'ajuste également en 8080:8080 pour une utilisation en direct et REMOTE_IP_VALVE_ENABLED: 'true'  pour activer le proxy externe et WEBAPP_CONTEXT: 'ROOT' afin que Guacamole soit accessible en racine :

version: '2.0'
networks:
  guacnetwork_compose:
    driver: bridge

services:
  # guacd
  guacd:
    container_name: guacd_compose
    image: guacamole/guacd
    networks:
      guacnetwork_compose:
    restart: always
    volumes:
    - ./drive:/drive:rw
    - ./record:/record:rw
  # postgres
  postgres:
    container_name: postgres_guacamole_compose
    environment:
      PGDATA: /var/lib/postgresql/data/guacamole
      POSTGRES_DB: guacamole_db
      POSTGRES_PASSWORD: 'ChooseYourOwnPasswordHere1234'
      POSTGRES_USER: guacamole_user
    image: postgres:15.2-alpine
    networks:
      guacnetwork_compose:
    restart: always
    volumes:
    - ./init:/docker-entrypoint-initdb.d:z
    - ./data:/var/lib/postgresql/data:Z

  guacamole:
    container_name: guacamole_compose
    depends_on:
    - guacd
    - postgres
    environment:
      REMOTE_IP_VALVE_ENABLED: 'true'   # On active ici l'utilisation via un proxy externe
      WEBAPP_CONTEXT: 'ROOT'
      GUACD_HOSTNAME: guacd
      POSTGRES_DATABASE: guacamole_db
      POSTGRES_HOSTNAME: postgres
      POSTGRES_PASSWORD: 'ChooseYourOwnPasswordHere1234'
      POSTGRES_USER: guacamole_user
    image: guacamole/guacamole
    volumes:
    - ./custom/server.xml:/home/administrator/guacamole-docker-compose/server.xml
    links:
    - guacd
    networks:
      guacnetwork_compose:
    ports:
    - 8080:8080
    restart: always

Je relance docker :

administrator@guacamole:~/guacamole-docker-compose$ sudo docker-compose up -d

En local je me connecte maintenant en http://ip_serveur:8080 sans SSL car le SSL sera géré par le proxy.

Option 1 : pfsense

J'ai un pfsense installé avec HAProxy et Acme pour gérer les certificats Lets'Encrypt, je vais donc me servir de ca pour publier le service. Sur HAProxy on configure le BackEnd et le FronteEnd qui lui utilisera le certificat préalablement créé avec Acme. Dans ma configuration je partage l'IP avec plusieurs sites et ce qui est important c'est d'activer l'option forwardfor qui permettra de transférer les adresses sources à Guacamole.

Je mets ici le code de configuration qui sera utile à ceux qui n'utilisent pas HAProxy sous pfsense qui lui dispose d'une interface graphique. Comme on peut le constater le HTTP to HTTPS se fait au niveau du HAProxy et c'est lui également qui redirigera les requetés HTTTP vers HTTPS et mon serveur sera accessible sur https://guacamole.mondomaine.tld :

global
  maxconn     10000
  stats socket /tmp/haproxy.socket level admin  expose-fd listeners
  uid     80
  gid     80
  nbproc      1
  nbthread      1
  hard-stop-after   15m
  chroot        /tmp/haproxy_chroot
  daemon
  tune.ssl.default-dh-param 1024
  server-state-file /tmp/haproxy_server_state

listen HAProxyLocalStats
  bind 127.0.0.1:2200 name localstats
  mode http
  stats enable
  stats admin if TRUE
  stats show-legends
  stats uri /haproxy/haproxy_stats.php?haproxystats=1
  timeout client 5000
  timeout connect 5000
  timeout server 5000

frontend Shared_WAN-merged
  bind      x.x.x.x:443 (IP WAN) name x.x.x.x:443 (IP WAN)   ssl crt-list /var/etc/haproxy/Shared_WAN.crt_list  
  mode      http
  log       global
  option    http-keep-alive
  option    forwardfor
  acl https ssl_fc
  http-request set-header   X-Forwarded-Proto http if !https
  http-request set-header   X-Forwarded-Proto https if https
  timeout client    30000
  acl     Admin var(txn.txnhost)      -m str -i admin.domain.tld
  acl     guacamole var(txn.txnhost)  -m str -i guacamole.domain.tld
  http-request set-var(txn.txnhost) hdr(host)
  use_backend Admin_ipvANY  if  Admin 
  use_backend Guacamole_8443_ipvANY  if  guacamole 

frontend http-to-https
  bind            x.x.x.x:80 (IP WAN) name x.x.x.x:80 (IP WAN)
  mode            http
  log             global
  option          http-keep-alive
  timeout client  30000
  http-request redirect code 301 location https://%[hdr(host)]%[path]  

backend Admin_ipvANY
  mode     http
  id       100
  log      global
  timeout  connect   30000
  timeout  server    30000
  retries  3
  server   admin 192.168.55.44:80 id 101  

backend Guacamole_8443_ipvANY
  mode     http
  id       102
  log      global
  timeout  connect   30000
  timeout  server    30000
  retries  3
  server   guacamole 192.168.66.55:8080 id 101

Option 2 : CloudFlared

Cette option est encore plus simple pour ceux qui disposent d'un domaine chez Cloudflare. On va utiliser les possibilités offertes gratuitement par Cloudflared et ajouter une couche de sécurité supplémentaire.

On commence par créer un tunnel CloudFlared avec une instance Docker supplémentaire (le code est fournit par le site de configuration Zero Trust de Cloudflare)

docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token eyJhIjoiZjk0YjdkZTBiMzFmYWNkNjZlshhsgfhsfghsgfhgfhssgfhsfgzRiMC00MmNlLWJjMghsfghsghsgfhsgfhsgfhsgmpaR00tyyretu(-yenebybvewWXpGaUxUazVNell0TnpRek56WXhNMlkxWXpFeiJ9

Ensuite une fois que le tunnel est monté

On va publier et pointant sur l'ip privée et le port de notre serveur, cela va automatiquement créer l'entrée DNS dans CloudFlare et gérer la problématique du certificat. Ll sera accessible en SSL. :

Ensuite on va ajouter une couche de sécurité supplémentaire en créant une application de type SelfHosted à laquelle on affecte une policie qui impose un code supplémentaire lors d'une connexion. Ce code sera envoyé sur le mail de l'utilisateur sur une adresse individuelle ou un domaine spécifique. Ce n'est pas tout à fait du MFA, mais on considère que si l'utilisateur reçoit bien le code sur son mail professionnel, il s'agit bien de lui et on peut lui permettre de saisir son login / password pour accéder au service :

C'est la méthode la plus simple et de nombreuses option sont exploitables, de même qu'il est possible d'utiliser de nombreux providers externes d'authentification :

Lorsqu'il souhaite se connecter, l'utilisateur tombe sur un portail que l'on peu personnaliser aux couleurs de l'entreprise.

Voilà, et surtout maintenant on retrouve bien les IP publiques dans le log de Guacamole :

Il n'y a plus qu'a ajuster les différentes options de Guacamole et pour ça la documentation est très bien faite. Et bien sur si on se sert de Guacamole pour exposer des serveurs RDP accessibles sur l'internet on prendra soin de restreindre leur usage à l'IP publique du serveur Guacamole, ou mieux de faire transiter ce flux par un tunnel (Wireguard, Tailscale ou Zerotier par exemple que l'on peu facilement installer sur les deux serveurs).

Télétravail, RDP & VPN

Par les temps qui courent, le télétravail est de mise, mais tout le monde n’est pas placé à la même enseigne. Il y a les grandes entreprises ou les cadres sont équipées d’ordinateurs portables et ou les infrastructures de sécurité existent et ou il suffit juste d’extrapoler pour les salariés qui ne sont pas équipés. Et puis il y a les petites entreprises, voire très petites ou rien n’existe et ou bien souvent le salarié sera contraint dans l'urgence de travailler sur son ordinateur personnel.

Et dans ce cas on peu se retrouver dans des situations très précaires, en termes de sécurité ou de praticité, car l’ordinateur familial est généralement utilisé par d’autres personnes, souvent les enfants, ce qui peut rapidement poser des problèmes. On pourrait bien sur isoler une session, mais c’est ingérable et par définition l’intervention sur le PC personnel que l'on réalise en avec une prise de contrôle à distance doit se limiter au strict minimum.

La solution bien souvent utilisée conste à permettre au télétravailleur de travailler distance en se connectant à son ordinateur de bureau, et ainsi conserver son environnement habituel. Pour ce faire on pense d’abord aux solutions de type AnyDesk, TeamViewer, voire VNC, solutions simples à mettre en œuvre mais qui offrent peu de confort à l’usage. La seule vraie solution confortable est d'utiliser le bureau à distance qui fonctionne avec le protocole RDP. Le problème du RDP c’est sa sécurisation car ce protocole directement exposé sur internet est une véritable passoire dont les méchants hackers sont friands si on se content de simples redirections de port. Microsoft ne s’est jamais occupé de ce problème pour cet usage, la seule solution proposée est RDS (Remote Desktop Services), une usine à gaz certes efficace mais totalement inadaptée aux TPE. Royal TS Gateway peut constituer une alternative (il y en a d’autres), mais pas pour de très petites entreprises qui n'ont que peux d'infra et généralement pas d'IT.

L’autre alternative reste l’utilisation d’un VPN en équipant les postes clients. Il y a plusieurs façons de faire, mais je voulais quelque chose de transparent, facilement administrable, ne m’imposant pas d’intervention ultérieure sur le poste client et ne nécessitant pas l’installation d’un serveur. Je vais donc une fois de plus utiliser Zerotier qui répond à mon besoin et qui est gratuit jusqu'à 50 clients.

  • Pas de serveur à déployer
  • Installation minimale sur le poste client
  • Gestion des ACL centralisée

Ce n’est pas la façon de faire la plus sécurisée (le port RDP est ouvert entre le client et son PC de bureau), mais on va limiter le risque avec un bon équilibre risque / coût / praticité.

Zerotier

Je vais faire l’impasse sur la mise en œuvre, j’en ai déjà parlé. Ici on va installer le client sur les deux postes à associer et leur figer une IP sur la console d’admin (Zerotier supporte Windows, MacOS, Linux et même Android et IOS). Ensuite on va s’assurer que seul le trafic RDP du poste client soit autorisé à se connecter au PC de bureau en utilisant les règles dans la console.

# Allow only IPv4, IPv4 ARP, and IPv6 Ethernet frames.
drop
	not ethertype ipv4
	and not ethertype arp
	and not ethertype ipv6
;
accept ipprotocol tcp and dport 443 or dport 80;

accept dport 3389 and ipsrc 10.147.1.20/32 and ipdest 10.147.1.30/32; # André
accept dport 3389 and ipsrc 10.147.1.21/32 and ipdest 10.147.1.31/32; # Carole
accept dport 3389 and ipsrc 10.147.1.23/32 and ipdest 10.147.1.33/32; # Bernard

drop chr tcp_syn and not chr tcp_ack; # No new TCP connections
;
# Drop TCP SYN,!ACK packets (new connections) not explicitly whitelisted above
break                     # break can be overridden by a capability
  chr tcp_syn             # TCP SYN (TCP flags will never match non-TCP packets)
  and not chr tcp_ack     # AND not TCP ACK
;
cap superuser
  id 2000 accept;
accept; # Accept what's left, returning RDP traffic

Coté poste au bureau on s'assure que le PC ne se met pas en veille (veille et verrouillage de l'écran uniquement) et on autorise RDP (le bureau à distance) sur le poste. Pour ça il faut un Windows Pro (mise à niveau à envisager parfois car les TPE qui vont acheter leur PC à la Fnac ou sur Amazon se retrouvent souvent avec une édition Famille de Windows).

Le client RDP

Do coté du poste client, après s'être assurée que la machine est à jour (on ne fait pas ça sur un vieux PC sous XP) et pas vérolée, il va nous falloir un client RDP et surtout interdire la mémorisation du mot de passe afin que n'importe qui ne puisse pas se connecter. Pour ça il y a une stratégie (Policie) à configurer ou une modification de registry, sauf que le PC personnel est une édition familiale il faudra ruser pour avoir accès aux stratégies...

Registry Hive HKEY_CURRENT_USER
Registry Path SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
Value Name DisablePasswordSaving
Value Type REG_DWORD
Enabled Value 1
Disabled Value 0

Tant sur Windows que sur Mac il existe plusieurs clients RDP proposés par Microsoft avec des possibilités inégales.

  • Client RDP de base Windows : Il supporte les redirections d'imprimantes, mais visiblement il est impossible malgré la stratégie d'interdire la mémorisation du mot de passe de session.
  • Client RDP enrichi que l'on peut télécharger sur le Windows Store pour Windows ou Apple Store MacOS : Il ne supporte pas la redirection des imprimantes, par contre il prend bien en compte la stratégie d'interdiction de mémorisation du mot de passe.

Tout ça se passe plutôt bien bien si le PC personnel est sous Windows, par contre si c'est un Mac vous imaginez bien que Microsoft ne s'est pas préoccupé du mappage du clavier qui est différent sur chez Apple. Et ça c'est juste insupportable à l'usage. Me voici contraint de chercher une alternative, alternative que je vais finalement utiliser sous Windows également car elle est plus sécurisée et bien plus fonctionnelle.

Royal TS/TSX

Royal TS (ou TSX sur Mac) est un client multi protocoles que j'utilise depuis des années pour gérer des douzaines de serveurs. Il inclus bien sur le RDP et une multitude d'options dont le mappage du clavier entre un Mac et un PC, la gestion des imprimantes et la possibilité de lancer des commandes avant et après une session. Et autre avantage il va être possible de chiffrer toutes les informations contenue dans ce client. De plus le fichier de configuration peut être partagé entre un PC et un Mac via un drive.

Royal TS/TSX n'est pas gratuit pour gérer une multitude de serveurs, mais cerise sur le gâteau il existe une version gratuite limitée à 10 connections. Juste ce dont on a besoin ici.

On installe sur le PC du salarié, on crée le profil (que l'on peut créer à l'avance) correspondant à son poste de travail avec l'option plein écran, on redirige les imprimantes et sur un Mac on gère le mappage. On n'hésite pas à enregistrer les identifiants car ici c'est le mot de passe de chiffrage de l'application qui sécurisera toutes les connections enregistrées.

A partir de là le salarié lance Royal TS/TSX, saisit le mot de passe de l'application et a accès à son PC de bureau. A noter qu'il est également possible de lui donner accès dans cette même application à d'autres environnements (RDP, VNC, SSH, PS, Terminal, ou des web apps sois IE ou Chromium). Et comme on peut batcher des process avant et après une ouverture de session on peut même imaginer de lancer et désactiver Zerotier avant et après.

Autre avantage de cette solution, il est possible de créer des fichiers de configuration chiffrés et facilement déployables (envoi par mail par exemple).

Voilà, ce n'est pas parfait, mais dans le contexte actuel rien n'est parfait. Et cette solution permettra le télétravail à peu de frais avec un minimum de sécurité et de confort.
 

Gérer ses VM Azure...

Ceci est un Notepad en évolution... Revenez...

Start / Stop

Un des intérêts d'une VM dans le cloud, c’est de n'en payer que l'usage. Pour la faire courte et pour donner suite à mon article sur les Bureaux à distance, je me suis retrouvé pour ce client avec VM qui n'était pas assez puissante. Sous Azure, c’est facile, en deux clics on change la taille de la VM, on choisit une instance avec plus de CPU, RAM, IO et bien sur le tarif augmente... Et si Azure est fonctionnellement remarquable, les tarifs sont purement stratosphériques si on les compare à une VM sur un serveur dédié chez Scaleway ou OVH (qu'il faudra bien sur géré, ce qui a aussi un coût et n’est pas faisable facilement par tout le monde). Bien sur ont peut facilement imaginer que les grand comptes obtiennent des remises tout aussi conséquents, sauf que pour une PME ça reste bien souvent inaccessible.

Vu que cette VM ne va être utilisée qu'aux heures de bureau, une façon de faire quelques économies va consister à programmer une heure de démarrage et une heure d'arrêt. Pour l’arrêt c’est facile, il suffit de configurer ça dans les paramètres de la VM. Mais allez donc savoir pourquoi il n'y a pas la même facilité pour la démarrer ? Chez Microsoft il appellent ça By Design. Il doit bien y avoir une raison puisque qu'il semblerait que ce soit à peu près le même fonctionnement chez les autres fournisseurs d'instances cloud et même chez OVH ou Scaleway. Bref, ce serait trop facile.

Il y plusieurs solution pour palier à ça !

Azure CLI

On peu bricoler quelque chose avec Azure CLI (Linux, Mac, Windows) et ainsi lancer un script qui va lancer ou stopper a VM. Pas très sexy ni trop sécurisé. 

Attention : Il ne faut pas se contenter d’arrêter la VM depuis l'O/S car si cela arrêtera bien la VM, elle continuera à être facturée, simple, mais sans intérêt. Pour qu'elle ne soit plus facturé il faut la désallouer (Deallocate) et ainsi seul le stockage continuera à être facturée.

Démarrer la VM

az vm start --name MyVM --resource-group MyVMGroup

Arrêter et désallouer

az vm stop --name MyVM --resource-group MyVMGroup
az vm deallocate --name MyVM --resource-group MyVMGroup

Il est également possible de faire ça en utilisant directement les ID des VM

az start --ids "/subscriptions/a35d316a-2a2a-48e2-8834-55481f7bbb48/resourceGroups/WIN16VM/providers/Microsoft.Compute/virtualMachines/Win16VM"
az stop --ids "/subscriptions/a35d316a-2a2a-48e2-8834-55481f7bbb48/resourceGroups/WIN16VM/providers/Microsoft.Compute/virtualMachines/Win16VM"
az deallocate --ids "/subscriptions/a35d316a-2a2a-48e2-8834-55481f7bbb48/resourceGroups/WIN16VM/providers/Microsoft.Compute/virtualMachines/Win16VM"

Azure Automation

Tout ça n'est pas très sexy ni user friendly. Une autre façon de faire va consister pour l'administrateur de programmer le démarrage de la VM et son arrêt en considérant que l'utilisateur s'en servira à heures fixes. Pour l’arrêt on va se servir de la fonction intégrée car elle est capable de base d'envoyer un mail à l’utilisateur lui proposant d'outrepasser l’arrêt programmé sans avoir à se connecter. Pratique.

Pour le démarrage par contre ça va être un peu plus compliqué. On va commencer par créer un compte Automation, simplement en cherchant dans la barre de recherche. Comme tout sur Azure, ce service est également payant, mais dans sa grande bonté Microsoft nous offre (jusqu'à quand ?) un petit forfait gratuit tous les mois qui sera amplement suffisant pour ce qu'on va faire.

Une fois dans notre compte Automation on va créer un Runbook, on lui donne un nom et on choisit un Flux de travail PowerShell (PowerShell Workflow) et on le crée. Une fois créé on va aller l'éditer

workflow Start-Ma-VM
{
# Association to the Azure subscribtion
$Conn = Get-AutomationConnection -Name AzureRunAsConnection
Add-AzureRMAccount -ServicePrincipal -Tenant $Conn.TenantID -ApplicationId $Conn.ApplicationID -CertificateThumbprint $Conn.CertificateThumbprint

# Start the virtual machine
Start-AzureRMVM -ResourceGroupName "MonGroupeDeRessources" -Name "MaVM"
}

Il ne reste plus qu'à aller dans le menu Planifications et d'en ajouter une en configurant l'heure de démarrage et la récurrence, sans oublier de choisir le bon fuseau horaire. Si on veut envoyer une notification par un mail ou faire autre chose il est bien sur possible de le faire dans le script.

A ce stade ça reste toutefois limité, la VM va démarrer tous les jours, même quand personne ne travaille.

Heureusement il est également possible de créer un WebHook et ainsi démarrer la VM depuis une URL. Ici depuis PowerShell mais on peut tout à fait imaginer intégrer ça dans un portail intranet ou un simple raccourcis sur le poste de l'utilisateur... Ou mieux utiliser un planificateur évolué tenant compte des jours fériés et des week-ends, voire interagir avec un agenda Google ou Microsoft 365...

PS C:\Users\Lionel> Invoke-WebRequest -Uri https://6bc1fsdfs-aesdf4c2f-8d31dsfsdf7fsd5f.webhook.we.azure-automation.net/webhooks?token=ZHuMYFqgqgfqsqgdgB%2qsdgfqsdgjc%3d -Method POST

Alternatives

Si la lecture de la documentation n'est pas toujours très lisibles, il faut bien admettre qu'Azure est très complet. Et si cela ne vous suffit pas il existe des fournisseurs de service qui se sont spécialisés dans la planification des VM et plus globalement vous aideront à réduire les coûts du cloud, que ce soit sur Azure, AWS ou GoogleCloud. Je pense par exemple à ParkMyCloud ou MyCloudToolbox, mais il y en d'autres. Se posera alors la question de la confiance que vous accorderez à ces services.

L'accès des clients aux VM

Comme on l'a vu le plus simple consiste à utiliser le client d'accès à distance. Le protocole RDP n'étant pas franchement des plus sur. Sécuriser RDP imposerait de passer par des certificats et une passerelle complexe et coûteuse ou par une alternative non Microsoft du genre Royal TS Server. La logique impose de passer par un VPN. Azure propose bien entendu tout une panoplie de solutions de sécurité, n'ayant ni envie de passer à la caisse ni celle de me compliquer la vie pour ce type d'utilisation, je vais simplement utiliser ZeroTier. C'est plus un SDN qu'un VPN, c'est OpenSource et gratuit et ça fait parfaitement le travail (j'en avais déjà parlé et on trouve maintenant une multitude d'articles).

On donnera une IP fixe au serveur et tous les clients autorisés pourront accéder au serveur RDP. Ensuite on prendra soin de ne plus autoriser l'accès via l'IP externe Azure ou de forcer un ACL sur une IP cliente sure. Easy, d'autant plus que mon client utilise déja cette solution pour sécuriser l'accès à des ressources SMB distantes.

Scénario pratique....

Sur le poste de on prépare un script PowerShell qui va lancer le WebHook pour démarrer la VM Azure, attendre que le serveur soit lancé, tester le port RDP et lancer le Bureau à distance, et au passage notifier un IT si quelque chose se passe mal. S'il doit y revenir dans la journée il ne lancera que le client RDP (Bureau à distance), en fin de journée le serveur sera programmé pour s’arrêter tout seul et si l’utilisateur veut faire des heures supplémentaires il n'aura qu'à cliquer dans le mail reçu pour reprogrammer l’arrêt...

On commence par brouiller à minima le mot de passe du mail...

"P4ssww0rd!" | Convertto-SecureString -AsPlainText -Force | ConvertFrom-SecureString | Out-file C:\Users\User1\admin.txt

Et ensuite on prépare un petit script qui se lancera depuis un raccourcis sur le bureau...

$password = Get-Content C:\Users\User1\admin.txt | Convertto-SecureString # On récupère le mot de passe encrypté dans un fichier...
$username = "[email protected]"
$From = "[email protected]"
$To = "user@prestataire"
$SMTPServer = "mail.gandi.net"
$SMTPPort = 587
$subject = "Client : Utilisateur (Machine)"
$Credential = New-Object System.Management.Automation.PSCredential ($username, $password)

try {
    $response = Invoke-WebRequest -Uri https://6bcghgdfh-afgh-4ghgfdf-8ghfgdh5f.webhook.we.azure-automation.net/webhooks?token=ZHuMYFshghshhh5+fgshs+f5h5+65sh -Method POST
    if($response.StatusCode -eq 202) {
        Write-Host "waiting..."
        sleep 60   # Temps d’attente estimé pour le démarrage de la VM
        if (Test-NetConnection 10.17.22.15 -Port 3389 | ? { $_.TcpTestSucceeded } ) {
            C:\Users\User1\vm.rdp  # On lance le client RDP
        } else {
            cls
	    Write-Output "RDP 1" # Si test NetConnection échoue (pas de réponse)
            Send-MailMessage -To $To -From $From -Subject $subject -SmtpServer $SMTPServer -Body 'Erreur NetConnection Fail' -Credential $Credential  -Port $SMTPPort -UseSsl
	    sleep 15
        }
    } else {
        cls
	Write-Output "Erreur RDP (l'administrateur a recu un mail d'avertissement et va intervenir !)" # Si NetConnection code autre que 202
        Send-MailMessage -To $To -From $From -Subject $subject -SmtpServer $SMTPServer -Body 'Erreur NetConnection 40x ou 500x' -Credential $Credential  -Port $SMTPPort -UseSsl
	sleep 15
    }
} catch {
    cls
    Write-Output "Erreur VM (l'administrateur a recu un mail d'avertissement et va intervenir !)" # Erreur NetConnection code 40x ou 50x
    Send-MailMessage -To $To -From $From -Subject $subject -SmtpServer $SMTPServer -Body 'Erreur au lancement de la VM' -Credential $Credential  -Port $SMTPPort -UseSsl
    sleep 15
}

Ainsi, contrairement à une planification en début de journée, la VM ne sera lancée que quand l'utilisateur en a l'usage afin d'économiser sur la facture Azure. Au besoin on peut également faire un petit script pour l'éteindre.

Migration

Dans un autre contexte je dois migrer une VM Azure vers ESXi. Expérience à venir.

Sources

 

Bureau à distance Windows et imprimantes

En ces temps ou les télétravail s'impose, l'IT doit s'adapter et proposer des solutions à chaque cas. Beaucoup de salariés se sont retrouvés à bosser sur le PC familial au détriment des règles de sécurité les plus élémentaires. Sachant par ailleurs que le télétravail comporte un cadre réglementaire  qui impose la fourniture des équipement nécessaires par l'employeur ainsi qu'un défraiement pour les frais occasionnés.

Au delà de ces considérations, s'il est facile de travailler à distance sur des applications web ou sur des fichiers gérés dans le cloud avec des applications classiques du genre Office, la chose se complexifie dès lors que l'on travaille sur des applications lourdes qui nécessitent une installation spécifiques sur le poste de travail. Je pense ici par exemple à des application de compta ou de paie (Sage pour ne pas les citer, mais ils sont loin d'être les seuls) ou le simple fait de déplacer l'application d'un poste à un autre nécessite l'intervention d'un partenaire agréé pendant plusieurs heures, je ne pense pas trop me tromper en affirmant que la complexité est ici orchestrée dans le seul but de générer du revenu... Un vaste débat, un autre débat que je n'aborderais pas ici ou je vais me contenter de contourner le problème.

Au départ j'avais j'avais naïvement pensé mettre les fichiers de données sur un cloud synchronisé. Impossible car au fil du temps ces solutions reposent souvent sur du SQL même en local. Les éditeurs proposent eux de configurer un serveur, solution coûteuse et surdimensionnée dans les TPE ou il n'y a bien souvent qu'un seul utilisateur. Installer ce genre de solutions sur un laptop que le salarié risque de perdre ou de se faire voler n'est pas non plus une solution.

L'alternative consiste à se servir un d'un logiciel de prise de main à distance, genre TeamViewer ou AnyDesk, ou carrément d'une session RDP (Bureau à distance) qui offre un bien meilleur confort. Reste à s'affranchir de la lenteur possible du poste de travail distant et de sa connectivité pas toujours à la hauteur.

Il existe une alternative plus durable et plus fonctionnelle. Isoler nos logiciels lourds sur un serveur dans une session RDP. L'avantage est que cette session sera accessible par la ou le(s) personne(s) qui en ont besoin, ou qu'elle soient et tout en se basant sur une application mono poste (donc une seule licence et donc une seule utilisation concurrente). Cela permet également à des salariés disposant d'un Mac d'utiliser des applications Windows.

Dans la pratique ce serveur, qui peut être un Windows 10 ou un Windows Serveur, sera de préférence installé dans un espace sécurisé (data center, Azure, AWS, un VPS ou encore un serveur dédié). Sécurisé en terme d'accès, sécurisé physiquement (vol, incendie, etc...), mais également au niveau de sauvegardes.

On a deux choix possibles, soit on installe un Windows 10 Pro, soit un Windows Serveur. L'avantage du Windows Serveur étant qu'il permettra de base une session RDP pour l'administrateur et une autre pour le client. Les coûts ne sont pas identiques. De plus selon la taille de l'entreprise une solution Windows Serveur pourra évoluer avec RDS (et les licences qui vont avec) vers une solution multi-utilisateurs distants.

La pratique

Installer une instance Windows, une VM, sur une infrastructure se fait en quelques clics. Ensuite on crée une session pour le client avec des droits utilisateur, on lui permet l'accès distant et le tour est joué. Il n'y a plus qu'à lancer le client Bureau à distance sur le PC ou le Mac de utilisateur et ça fonctionne, en mode fenêtré ou plein écran selon la taille des on écran. De plus RDP est bien pus confortable au quotidien qu'une prise de main à distance. A partir de là on demande au prestataire Sage (ou autre) de venir y transférer ses logiciels dont lui seul possède le savoir faire nécessaire et le tour est joué.

Sauf que...

Les utilisateurs de ce genre de logiciels génèrent beaucoup d’impressions. C'est prévu, le client Bureau à distance (Windows et Mac, mais pas celui que l'on trouve sur le Windows Store) permet d'utiliser ses imprimantes locales qu'il redirige dans la session RDP. Si dans la pratique si ça peut fonctionner de façon transparente pour quelques imprimantes qui utilisent des pilotes standards fournis par Windows, dans la majorité des cas il faudra installer les pilotes des imprimantes du poste client sur le serveur, (sauf peut être si on installe RDS avec EasyPrint, ça reste à vérifier et je n'ai pas pris cette peine). Hélas il sera impossible d’installer directement certains pilotes sur le serveur, soit leur module d’installation ne peux fonctionner que sur Windows 10, soit parce qu’il nécessitent que l'imprimante soit en ligne. Il va donc falloir ruser un peu pour disposer des pilotes correspondant aux imprimantes de nos clients sur le serveur.

Il existe sous Windows (sauf la version Home) un outil de migration qui va permettre d'exporter les files d'impression d'un client ou serveur et de les réimporter en réinstallant les pilotes et les imprimantes sur la cible. On va donc lancer PrintBrmUi.exe sur le poste des clients et réimporter le fichier obtenu sur le serveur avec le même outil. Cette opération permettra également l’importation de pilotes 32 bits si ce genre de poste client existe toujours...

Attention cet outil n’est pas fait pour ça mais pour migrer des serveurs d’impression… donc il exporte / importe des files d’impression avec les drivers. Il faudra donc prendre soin de ne pas écraser les pilotes existants et ensuite d’aller faire le ménage dans les imprimantes déclarées sur le serveur mais inutiles car seule nous importe la présence des pilotes. Le plus simple étant bien sur de tout faire avec la console printmanagement.msc qui va nous permettre de visualiser les pilotes installés et de retirer les imprimantes inutiles tout en conservant les pilotes.

Sources