Déployer Apache Guacamole : accès distant par navigateur, sans agent.

Apache Guacamole donne accès à des bureaux distants et à des serveurs depuis un simple navigateur : pas de client RDP à installer, pas de VPN à déployer sur le poste, pas d'agent sur la machine cible. Le navigateur affiche l'écran, la passerelle parle RDP, VNC ou SSH à sa place.

C'est très pratique - et c'est exactement pour cela qu'il faut le déployer avec soin : vous êtes en train de publier sur le web une porte d'entrée vers l'intérieur de votre réseau.

Ce qu'il vous faut

• Un serveur Linux dédié, à jour, avec un accès administrateur.
• Une base de données PostgreSQL ou MariaDB - sur une autre machine de préférence.
• Un nom de domaine et un certificat TLS valide : cette passerelle ne se publie pas en clair.
• De quoi tester : une machine Windows joignable en RDP et un serveur Linux en SSH.

1. Trois pièces, et pourquoi ça compte

Guacamole n'est pas un logiciel mais un assemblage de trois composants, et confondre leurs rôles est la première source d'erreurs de déploiement :

• guacd - le démon proxy, écrit en C. C'est lui qui parle réellement RDP, VNC et SSH aux machines cibles, et qui traduit tout cela dans le protocole propre à Guacamole. Il fait partie de guacamole-server, qui fournit aussi la bibliothèque commune libguac et une bibliothèque par protocole supporté. Ce composant doit être compilé depuis les sources - il n'existe pas de binaire officiel.
• Le client web - une application Java (guacamole.war) déployée dans un conteneur de servlets, en pratique Apache Tomcat. Celui-là est distribué sous forme binaire. C'est lui que voit l'utilisateur.
• GUACAMOLE_HOME - le répertoire de configuration, en général /etc/guacamole. Il contient guacamole.properties, un sous-répertoire extensions/ et un sous-répertoire lib/. Tout ce qui suit - authentification, annuaire, double facteur - se joue ici.

2. Construire guacamole-server

Les paquets de distribution sont souvent en retard de plusieurs versions. Pour un composant qui expose des protocoles réseau, ce retard est un problème : compilez la version courante.

a. Les dépendances de compilation. Chaque protocole a les siennes, et une dépendance absente ne provoque pas d'erreur : le protocole correspondant est simplement ignoré à la compilation. C'est le piège n°1 de ce déploiement.

b. Compiler et installer :

tar -xzf guacamole-server-1.6.0.tar.gz
cd guacamole-server-1.6.0
./configure --with-init-dir=/etc/init.d
make
sudo make install

c. Lire ce qu'affiche ./configure. À la fin, un récapitulatif indique quels protocoles seront construits. Une ligne no en face de RDP signifie que la dépendance manque - et la compilation réussira quand même. Ne passez pas cette étape :

   Protocol support:

      Kubernetes .... yes
      RDP ........... yes
      SSH ........... yes
      Telnet ........ yes
      VNC ........... yes

d. Rafraîchir le cache des bibliothèques. C'est l'oubli le plus fréquent, et son symptôme est déroutant :

sudo ldconfig

Sans cette commande, guacd refuse de démarrer parce qu'il ne trouve pas libguac.so - qui vient pourtant d'être installée. L'erreur ne parle pas de compilation, on cherche donc ailleurs.

e. Démarrer et vérifier :

sudo systemctl enable --now guacd
systemctl status guacd
ss -lntp | grep 4822

guacd doit écouter sur 127.0.0.1:4822, et uniquement là. Nous y revenons dans la section durcissement, parce que ce point n'est pas négociable.

3. Déployer le client web

Le client est un fichier .war à déposer dans le répertoire des applications de Tomcat :

sudo apt install tomcat10 tomcat10-common
sudo cp guacamole-1.6.0.war /var/lib/tomcat10/webapps/guacamole.war
sudo systemctl restart tomcat10

Le nom du fichier détermine le chemin d'accès : guacamole.war donne /guacamole/. Pour servir l'application à la racine, nommez-le ROOT.war.

Créez ensuite le répertoire de configuration et indiquez à Tomcat où le trouver :

sudo mkdir -p /etc/guacamole/{extensions,lib}
echo 'GUACAMOLE_HOME=/etc/guacamole' | sudo tee -a /etc/default/tomcat10

/etc/guacamole/guacamole.properties

guacd-hostname: 127.0.0.1
guacd-port:     4822

4. L'authentification par base de données

Sans extension, Guacamole lit ses utilisateurs dans un fichier XML statique. C'est utilisable pour un test, pas pour une mise en service : pas de mot de passe modifiable par l'utilisateur, pas d'historique des connexions, pas de gestion fine des permissions.

a. Créer la base et l'utilisateur applicatif :

sudo -u postgres createdb guacamole_db
sudo -u postgres psql -c "CREATE USER guacamole_user WITH PASSWORD '<secret>';"

b. Initialiser le schéma. Les scripts sont dans l'archive guacamole-auth-jdbc-1.6.0.tar.gz, sous postgresql/schema/ :

cat postgresql/schema/*.sql | sudo -u postgres psql -d guacamole_db

Puis n'accordez à l'utilisateur applicatif que ce dont il a besoin - il n'a aucune raison d'être propriétaire du schéma :

sudo -u postgres psql -d guacamole_db -c \
  "GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN SCHEMA public TO guacamole_user;
   GRANT USAGE,SELECT ON ALL SEQUENCES IN SCHEMA public TO guacamole_user;"

c. Installer l'extension et le pilote :

sudo cp guacamole-auth-jdbc-postgresql-1.6.0.jar /etc/guacamole/extensions/
sudo cp postgresql-42.7.x.jar                     /etc/guacamole/lib/

L'extension va dans extensions/, le pilote JDBC dans lib/. Les inverser produit une application qui démarre sans erreur visible et refuse toutes les connexions.

d. Compléter la configuration :

/etc/guacamole/guacamole.properties

postgresql-hostname: 10.0.0.20
postgresql-port:     5432
postgresql-database: guacamole_db
postgresql-username: guacamole_user
postgresql-password: <secret>

Redémarrez Tomcat, puis connectez-vous avec le compte créé par le schéma : guacadmin / guacadmin.

5. Brancher l'annuaire

Faire vivre des comptes en double est une dette qui se paie au premier départ non répercuté. L'extension LDAP branche Guacamole sur Active Directory ou sur un annuaire ouvert.

sudo cp guacamole-auth-ldap-1.6.0.jar /etc/guacamole/extensions/

/etc/guacamole/guacamole.properties

ldap-hostname:            dc01.exemple.local
ldap-port:                636
ldap-encryption-method:   ssl
ldap-user-base-dn:        OU=Utilisateurs,DC=exemple,DC=local
ldap-username-attribute:  sAMAccountName
ldap-search-bind-dn:      CN=svc-guacamole,OU=Services,DC=exemple,DC=local
ldap-search-bind-password: <secret>
ldap-user-search-filter:  (&(objectClass=user)(memberOf=CN=Guacamole,OU=Groupes,DC=exemple,DC=local))

Trois points qui font la différence entre une intégration propre et une intégration approximative :

• Chiffrez la liaison (ssl sur 636, ou starttls). Une liaison LDAP en clair transporte les identifiants de vos utilisateurs sur le réseau - et c'est exactement ce que la signature LDAP et le channel binding cherchent à empêcher côté annuaire.
• Filtrez sur un groupe. Sans ldap-user-search-filter, tout compte de l'annuaire peut se présenter à la passerelle. Le filtre transforme une liste d'interdits en liste d'autorisés.
• Le compte de service n'a besoin que de lire. C'est un compte de service classique : mot de passe long, aucun privilège d'administration, et idéalement un compte géré de groupe pour ne pas avoir à gérer sa rotation.

L'extension LDAP et l'extension base de données cohabitent : l'annuaire authentifie, la base porte les connexions et les permissions. C'est la combinaison la plus courante, et la plus maintenable.

6. Le second facteur

Une passerelle d'accès distant publiée sur Internet et protégée par un simple mot de passe est une invitation. L'extension TOTP ajoute un code à usage unique, compatible avec les applications d'authentification courantes :

sudo cp guacamole-auth-totp-1.6.0.jar /etc/guacamole/extensions/

/etc/guacamole/guacamole.properties

totp-issuer: Guacamole - Exemple
totp-digits: 6
totp-period: 30
totp-mode:   sha1

À la première connexion, chaque utilisateur se voit présenter un QR code à enrôler. Un point d'exploitation à anticiper : prévoyez la procédure de réinitialisation - un téléphone perdu bloque un utilisateur, et l'administrateur doit pouvoir effacer son enrôlement. Cela se fait en base ; écrivez la procédure avant d'en avoir besoin.

Sur le choix du facteur, la même hiérarchie qu'ailleurs s'applique : un code TOTP protège contre le mot de passe volé, pas contre une page de connexion contrefaite. Pour les accès les plus sensibles, une authentification résistante à l'hameçonnage reste supérieure.

7. Publier derrière un reverse proxy

Tomcat ne doit jamais être exposé directement. Un reverse proxy termine le TLS, filtre, journalise, et limite le débit. Mais la configuration par défaut d'un proxy casse Guacamole, pour une raison précise : le tunnel repose sur une connexion maintenue ouverte, et la plupart des proxys mettent les données en tampon par défaut.

/etc/nginx/sites-available/guacamole

server {
    listen 443 ssl;
    http2 on;
    server_name guacamole.exemple.com;

    ssl_certificate     /etc/letsencrypt/live/guacamole.exemple.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/guacamole.exemple.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:8080/guacamole/;

        # Sans ceci, les sessions se figent : le tunnel a besoin d'un flux continu
        proxy_buffering off;

        # WebSocket : la voie rapide du tunnel
        proxy_http_version 1.1;
        proxy_set_header Upgrade    $http_upgrade;
        proxy_set_header Connection $http_connection;

        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

Deux lignes méritent une explication, parce que leur absence produit des symptômes qu'on impute à tort au réseau ou à la machine cible :

• proxy_buffering off - le tunnel HTTP de Guacamole diffuse des données sur une connexion ouverte. Un proxy qui met en tampon bloque la session : l'utilisateur voit un écran figé, sans erreur.
• Les en-têtes Upgrade et Connection - sans eux, la négociation WebSocket échoue et Guacamole retombe sur le tunnel HTTP. Ça fonctionne, en moins fluide : le défaut ne se signale que par une impression de lenteur, ce qui le rend difficile à attribuer.

Enfin, pour que les journaux de Guacamole enregistrent la vraie adresse du client et non celle du proxy - ce qui vide de sens la journalisation et le blocage sur adresse - activez la valve correspondante côté Tomcat :

/etc/tomcat10/server.xml

<Valve className="org.apache.catalina.valves.RemoteIpValve"
       internalProxies="127\.0\.0\.1"
       remoteIpHeader="x-forwarded-for"
       protocolHeader="x-forwarded-proto" />

8. Durcir

• guacd reste sur la boucle locale. Son protocole n'a ni chiffrement ni authentification : qui l'atteint peut ouvrir une session vers n'importe quelle cible configurée, sans identifiant. Si le démon doit être séparé de l'application web, il faut un tunnel chiffré entre les deux, pas une exposition réseau.
• Tomcat n'écoute que sur 127.0.0.1:8080 (attribut address du connecteur), pour qu'aucun chemin ne contourne le proxy.
• Segmentez vers les cibles. La passerelle a besoin de joindre le 3389 et le 22 de ses cibles, et rien d'autre. Compromise, elle devient un point de rebond vers tout ce qu'elle peut atteindre : restreignez-la au strict nécessaire.
• Limitez le débit sur la page de connexion au niveau du proxy. Une passerelle publiée subit du bourrage d'identifiants en continu, et l'extension de blocage par force brute de Guacamole gagne à être complétée en amont.
• Enregistrez les sessions si votre contexte l'exige - Guacamole sait le faire nativement. Attention alors au volume de stockage et à la conservation : un enregistrement de session est une donnée sensible, qui contient tout ce qui s'est affiché à l'écran.
• Suivez les avis de sécurité du projet. Guacamole a connu des vulnérabilités sérieuses, dont une dans l'émulateur de terminal affectant les versions 1.5.5 et antérieures, corrigée en 1.6.0. Le composant est en frontal : il se met à jour vite.
• Une seule source de comptes. Une fois l'annuaire branché, désactivez la création de comptes locaux hors administration - deux sources d'identités, c'est un départ non répercuté qui garde son accès.

9. Ce que Guacamole n'est pas

C'est une passerelle d'accès distant, pas un bastion d'accès à privilèges. La distinction n'est pas académique, et elle décide de la pertinence de l'outil pour votre besoin :

Concrètement : dans Guacamole, les identifiants des machines cibles sont stockés dans la configuration des connexions. L'administrateur ne les tape pas, mais ils existent, et ils ne tournent pas tout seuls. Si votre besoin est de ne plus jamais divulguer le mot de passe d'un compte à privilèges et d'en imposer la rotation, c'est un bastion PAM qu'il vous faut. Si votre besoin est de donner un accès distant simple, tracé et sans installation de client, Guacamole le fait très bien - et gratuitement.

Vérifier que c'est en place

1. Les protocoles sont réellement construits : le récapitulatif de ./configure annonçait yes pour RDP et SSH, et une connexion de test aboutit sur chacun.
2. guacd n'est pas exposé : ss -lntp | grep 4822 montre une écoute sur 127.0.0.1 uniquement. Depuis une autre machine, le port ne répond pas.
3. Tomcat non plus : curl http://<ip-publique>:8080/ depuis l'extérieur ne renvoie rien.
4. Le WebSocket est bien utilisé : dans l'onglet réseau du navigateur, la session apparaît comme une connexion WebSocket (code 101), pas comme une suite de requêtes HTTP. Sinon, revoyez les en-têtes du proxy.
5. Les journaux voient la vraie adresse : une connexion depuis l'extérieur apparaît avec son adresse publique, pas avec 127.0.0.1.
6. guacadmin est neutralisé, et le second facteur est exigé pour tous les comptes.
7. Le redémarrage : après un reboot, guacd et Tomcat remontent seuls et une session s'ouvre sans intervention.

Sources

• Apache Guacamole - manuel officiel (installation, extensions, reverse proxy)
• Apache Guacamole - avis de sécurité
• Dépôt guacamole-server (guacd, libguac, bibliothèques de protocole)
• Kenawek - Déployer WALLIX Bastion : de l'image au premier accès tracé
• Kenawek - Durcir un accès SSH exposé
• Kenawek - MFA : pourquoi l'authentification multifacteur n'est plus optionnelle