La solution Apache Guacamole™ permet de se connecter à distance sur des équipements à travers un portail web. Il supporte les protocoles VNC, RDP, SSH, Telnet, ainsi que l’accès aux consoles de pods Kubernetes. D’un point de vue client il s’agit d’une interface web HTML5, qui ne nécessite donc pas d’installation de logiciel supplémentaire ou de plugin sur le navigateur.

A travers cet article Zenetys propose quelques conseils pour vos déploiements Guacamole.

Préambule

Guacamole est un logiciel open-source distribué sous licence Apache 2.0 et composé de deux briques :

• guacamole-client — Fournit une interface web pour l’accès distant aux machines, la gestion des connexions, des utilisateurs et des permissions. La partie serveur de l’application web a été écrite avec des servlets Java et doit donc être servie par un servlet container comme Tomcat.
• guacamole-server — Fournit principalement le démon guacd écrit en C qui effectue les connexions vers les machines cibles, sur ordre du client Guacamole. Le côté serveur du client Guacamole communique avec le démon guacd par le protocole Guacamole. La prise en charge des connexions RDP, VNC, SSH, … par guacd s’effectue par l’intermédiaire de modules chargés dynamiquement par le démon.

Déploiement classique

Dans une installation de base (voir aussi §Packaging), tous les composants sont installés sur le même serveur, le démon guacd n’est pas exposé sur le réseau et écoute seulement sur l’interface locale (127.0.0.1).

L’interface web doit quant à elle être accessible par le réseau. C’est par le biais de cette interface que les clients (navigateurs web) se connecteront aux machines cibles. Il est acquis que le servlet container (Tomcat) ne doit pas être exposé directement aux clients, il écoute donc sur 127.0.0.1, et met à disposition Guacamole aux clients sous le chemin /guacamole/. Un reverse proxy doit être utilisé comme intermédiaire entre les clients et Tomcat, par exemple HAProxy®.

Tomcat doit être sécurisé : utilisateur non-root, permissions des fichiers, suppression des webapps autres que Guacamole, en particulier le manager, masquage des backtraces, de la version du serveur, etc. Il existe beaucoup d’articles sur le sujet, par exemple :

• Wiki OWASP — Securing tomcat (pas très à jour mais constitue un bon point de départ)
• Apache Tomcat 9 — Security Considerations (documentation Tomcat)

Le reverse proxy doit permettre l’accès des clients au serveur en HTTPS uniquement. Le choix d’utiliser HAProxy en front permet d’ajouter facilement des protections avant d’atteindre l’application Guacamole : IP access list, pré-authentification par certificat client, rate limit des clients effectuant trop de requêtes en erreurs, etc. Nous conseillons très fortement la mise en place d’un WAF type mod_security si l’application est exposée sur internet ; l’agent SPOE mod_security disponible dans les contributions HAProxy pourrait être utilisé pour cela.

Exemple de configuration minimale HAProxy :

frontend ft_main
    bind 0.0.0.0:80
    bind 0.0.0.0:443 ssl crt guacamole.zenetys.loc.pem
    option forwardfor except 127.0.0.0/8
    http-request redirect code 301 scheme https if ! { ssl_fc }
    http-request redirect code 302 location /guacamole/ if ! { path_beg /guacamole/ }
    default_backend bk_guacamole

backend bk_guacamole
    balance source
    default-server inter 3s fall 3 rise 2
    server tomcat 127.0.0.1:8080 check

Côté authentification, Guacamole supporte différents backends, ainsi qu’une extension TOTP, encore peu configurable mais fonctionnelle, pour faire du 2FA.

Déploiement avec rebond guacd

Une fonctionnalité intéressante de Guacamole est qu’il a la possibilité de se connecter à des démons guacd distants, autres que l’instance qui écoute habituellement sur 127.0.0.1. Cela permet à l’application (Tomcat) d’accéder à des machines cibles qui ne sont pas routées sur le réseau local, mais qui seraient accessibles depuis un guacd distant.

Cas d’utilisation :

• on souhaite permettre aux utilisateurs Guacamole d’accéder à des machines d’un site distant
• ces machines ne sont pas accessibles depuis le réseau du serveur Guacamole principal (routage, fw)

Evidemment ce mode de fonctionnement nécessite que le démon guacd d’un site distant soit accessible depuis le serveur Guacamole. Ce point sort du périmètre de cet article, mais si le routage vers la machine de rebond n’est pas réalisable, un tunnel OpenVPN ou Wireguard peut être utilisé par exemple.

Le démon guacd sert de rebond vers le réseau du site distant :

Au niveau de l’interface d’administration Guacamole, il suffit d’indiquer l’adresse du serveur guacd à utiliser comme rebond dans la configuration de la connexion :

En terme de filtrage un seul flux TCP est requis entre le serveur Guacamole (client) et le démon guacd distant (rebond), ici le tcp/4822. La connexion entre les deux doit être sécurisée : chiffrement, certificat. Pour activer le transport TLS, le démon guacd doit être lancé avec les options permettant de spécifier le chemin du certificat x509 serveur et de la clé associée.

Exemple pour indiquer adresse et port d’écoute, certificat et clé du démon guacd :

[root@rebond-site-01 ~]# cat /etc/sysconfig/guacd 
OPTS="-b 10.42.21.73 -l 4822 -C /etc/pki/tls/certs/guacd-site-01.crt -K /etc/pki/tls/private/guacd-site-01.key

Côté serveur Guacamole, le certificat du guacd distant (s’il est autosigné) ou de son émetteur (CA) doit être dans le magasin des autorités de confiance. C’est l’application Java (Tomcat), client du serveur guacd, qui effectue la connexion et valide le certificat envoyé par le serveur.

[root@guacamole ~]# ls /etc/pki/ca-trust/source/anchors
GUAC-CA.pem
[root@guacamole ~]# update-ca-trust

Packaging

Actuellement il n’existe pas de package guacamole-server (guacd) pour CentOS 8, que ce soit dans les dépôts officiels ou dans EPEL8. Afin de faciliter le déploiement de Guacamole sous CentOS 8, Zenetys met à disposition de la communauté les éléments permettant de fabriquer facilement un paquet RPM guacamole-server 1.1.0.

Disponible sur GitHub : https://github.com/zenetys/rpm-guacamole-server/

Le fichier SPEC de ce paquet est compatible CentOS 6, 7 et 8, avec une dépendance sur le dépôt EPEL. Le script rpmbuild-docker fourni dans le repo Git permet de fabriquer le package dans un docker CentOS de la version choisie. Ce paquet supporte les connexions RDP, VNC, SSH et Telnet ; le support de Kubernetes n’est disponible que dans le paquet CentOS 7.

Exemple pour fabriquer le RPM CentOS 8 :

$ git clone https://github.com/zenetys/rpm-guacamole-server.git
$ cd rpm-guacamole-server
$ ./rpmbuild-docker -d el8

Ressources et références

Apache Guacamole™ — Clientless remote desktop gateway
Apache Tomcat^® — Java servlet container
HAProxy® — The Reliable, High Performance TCP/HTTP Load Balancer
Packaging CentOS pour guacamole-server — Github zenetys/rpm-guacamole-server