====== Bastion Apache Guacamole : architecture et accès ======

**Formation :** BTS SIO — Option SISR

{{ :wiki:logo.png?120 |Logo PLC-SIO}}

===== 1. Rôle et fonctionnement =====

Apache Guacamole fournit un accès distant depuis un navigateur. L'application Web dialogue avec **guacd**, qui établit une session vers la cible en SSH, RDP ou VNC. Le navigateur ne reçoit pas nécessairement un accès réseau direct à cette cible.

<mermaid>
flowchart LR
    A[Navigateur administrateur] -->|HTTPS| B[Application Guacamole]
    B -->|Protocole Guacamole| C[guacd]
    C -->|SSH ou RDP| D[Serveurs cibles]
</mermaid>

Le cloisonnement dépend aussi des règles réseau. La présence d'un bastion ne bloque pas automatiquement une connexion directe depuis un poste vers un serveur.

===== 2. Exemple de déploiement =====

Le bastion documenté est ''192.168.3.209/29'', dans le VLAN 51, avec la passerelle ''.214''. L'URL de la maquette utilise HTTPS sur le port 8443. Ces valeurs décrivent cet exemple, pas une configuration par défaut du logiciel.

La procédure pédagogique utilise Debian 12 et un script Tomcat 9. Vérifier la compatibilité des versions Java, Tomcat et Guacamole avant toute réutilisation ; ne pas remplacer arbitrairement l'une de ces versions.

===== 3. Gestion des accès =====

Créer des comptes nominatifs et attribuer uniquement les connexions nécessaires. Distinguer administration de l'application, utilisation des connexions et consultation des traces. La séparation des rôles doit être testée avec les permissions réellement offertes par la version et le mécanisme d'authentification installés.

Retirer les accès initiaux après validation d'un compte d'administration. Les enregistrements de sessions et leur stockage doivent être configurés explicitement ; leur présence n'est pas automatique.

===== 4. Vérification et dépannage =====

Tester HTTPS, l'authentification, puis une connexion SSH et une connexion RDP autorisées. Vérifier aussi qu'un compte limité ne voit pas les autres cibles. Si le portail fonctionne mais pas la session, examiner guacd, les paramètres de connexion et le filtrage vers la cible.

Prévoir sauvegarde de la configuration, des comptes et de la base éventuelle, ainsi qu'un accès de secours contrôlé.


===== 5. Installation et portée de l'exemple =====

Le déploiement initial utilise Debian 12 et un script de préparation Tomcat 9 transmis en SCP. Ce script n'est pas fourni dans les sources ; il ne constitue donc pas ici une procédure reproductible complète. Les étapes suivantes portent sur une installation Guacamole déjà fonctionnelle.

===== 6. Comptes et séparation des rôles =====

Un compte adminbastion est créé et testé avant le retrait du compte initial guacadmin. Les groupes ServeursLinux et ServeursWindows regroupent les accès ; adminlinux et adminwindows reçoivent les connexions adaptées à leur rôle.

{{:cyber:guacamole:guacamole-droits-administrateur.png?800|Droits du compte d’administration du bastion.}}

//Droits du compte d’administration du bastion.//

{{:cyber:guacamole:guacamole-droits-auditeur.png?800|Séparation du droit d’audit.}}

//Séparation du droit d’audit.//

{{:cyber:guacamole:guacamole-compte-utilisateur.png?800|Compte utilisateur et affectation au groupe.}}

//Compte utilisateur et affectation au groupe.//

{{:cyber:guacamole:guacamole-permissions-utilisateur.png?800|Permissions attribuées au compte de connexion.}}

//Permissions attribuées au compte de connexion.//


===== 7. Sessions SSH et RDP =====

La connexion SSH vise dns0, 192.168.3.10:22, depuis le bastion 192.168.3.209. La session RDP vise Windows à 192.168.3.5:3389. Elle est distincte de l'accès Web WAC sur 10443.

{{:cyber:guacamole:capture_decran_2026-10-07_a_09.35.17.png?800|Session SSH vers le serveur Linux à travers Guacamole.}}

//Session SSH vers le serveur Linux à travers Guacamole.//

{{:cyber:guacamole:pasted_image_20261007110441.png?800|Capture du flux RDP entre le bastion et le serveur Windows.}}

//Capture du flux RDP entre le bastion et le serveur Windows.//

Le navigateur échange avec le portail HTTPS ; guacd établit une autre session vers la cible. La capture côté cible montre le second segment. Elle ne prouve pas à elle seule qu'aucun accès direct n'est possible : les règles réseau doivent imposer le passage par le bastion.

===== 8. Dépannage RDP : environnement de guacd =====

==== Problème rencontré ====

Lors de nos premières tentatives, la connexion échoue. Le journal du service ''guacd'' affiche notamment :

<code>
RDP server closed/refused connection: Connection failed (server unreachable?)
</code>

Nous rencontrons également le message suivant :

<code>
RDP server closed/refused connection: Security negotiation failed (wrong security type?)
</code>

==== Vérification de l'accès réseau ====

Depuis le serveur ''bastion0'', nous vérifions que le port RDP de la cible est accessible :

<code bash>
nc -vz -w 5 192.168.3.5 3389
</code>

Le résultat indique :

<code>
192.168.3.5: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.3.5] 3389 (ms-wbt-server) open
</code>

La mention ''open'' confirme que la connexion TCP est possible depuis le bastion. L'avertissement concernant la résolution inverse signifie seulement que le nom associé à l'adresse IP n'a pas été trouvé. Il n'empêche pas l'accès au port RDP.

Le ping ne reçoit aucune réponse, mais cela ne suffit pas à conclure que le serveur est inaccessible : les requêtes ICMP peuvent être filtrées indépendamment du trafic RDP.

Nous vérifions également le chemin réseau :

<code bash>
ip route get 192.168.3.5
</code>

<code>
192.168.3.5 via 192.168.3.214 dev ens18 src 192.168.3.209
</code>

Le trafic utilise donc l'interface ''ens18'', l'adresse source du bastion ''192.168.3.209'' et la passerelle ''192.168.3.214''.

==== Analyse des journaux et de la capture réseau ====

Nous consultons les journaux du service :

<code bash>
sudo journalctl -u guacd -f
</code>

Un avertissement attire notre attention :

<code>
FreeRDP initialization may fail: The current user's home directory ("/usr/sbin") is not writable, but FreeRDP generally requires a writable home directory for storage of configuration files and certificates.
</code>

Nous identifions le compte utilisé par le service :

<code bash>
ps -eo user,group,pid,args | grep '[g]uacd'
sudo systemctl cat guacd
</code>

Le service est exécuté avec le compte ''daemon'' :

<code ini>
[Service]
User=daemon
ExecStart=/usr/local/sbin/guacd -f
Restart=on-abnormal
</code>

Nous réalisons ensuite une capture pendant une nouvelle tentative RDP :

<code bash>
sudo tcpdump -i any -nn -s 0 -X 'host 192.168.3.5 and tcp port 3389'
</code>

La capture montre l'établissement de la connexion TCP (''SYN'', ''SYN-ACK'', ''ACK''), puis l'envoi de 50 octets par le bastion et une réponse de 19 octets par Windows. Le bastion initie ensuite la fermeture avec un paquet ''FIN''.

Ces observations confirment que la cible répond, mais que la connexion s'interrompt au début de la négociation. La capture seule ne permet pas d'attribuer cet échec aux permissions du compte de service.

==== Correction appliquée : compte dédié au service guacd ====

Dans notre installation, le problème est résolu en exécutant ''guacd'' avec un compte dédié, disposant d'un répertoire personnel accessible en écriture pour FreeRDP.

Le problème ne vient pas du nom ''daemon'' en lui-même, mais de l'environnement et des permissions du compte de service. Le message « Security negotiation failed » peut avoir d'autres causes ; cette correction correspond au problème rencontré ici.

Nous créons le compte système ''guacd'', sans connexion interactive, puis son répertoire personnel :

<code bash>
sudo useradd -M -d /var/lib/guacd -r -s /usr/sbin/nologin -c "Guacd User" guacd
sudo install -d -o guacd -g "$(id -gn guacd)" -m 700 /var/lib/guacd
</code>

Si le compte existe déjà, il ne faut pas relancer sa création. Nous pouvons vérifier ses propriétés avec :

<code bash>
getent passwd guacd
</code>

Si ''/var/lib/guacd'' contient déjà des fichiers créés lors d'un précédent essai, nous transférons leur propriété au compte dédié :

<code bash>
sudo chown -R guacd: /var/lib/guacd
</code>

Nous modifions ensuite le service :

<code bash>
sudo nano /etc/systemd/system/guacd.service
</code>

Dans la section ''[Service]'', nous remplaçons uniquement :

<code ini>
User=daemon
</code>

par :

<code ini>
User=guacd
</code>

Si une configuration complémentaire a été ajoutée avec ''systemctl edit guacd'' pendant le diagnostic, il faut aussi la vérifier avec ''systemctl cat guacd''. Un éventuel ''HOME=/var/lib/guacd'' peut être conservé. Si le mode debug a été activé, retirer uniquement ''-L debug'' de la commande ''ExecStart'' correspondante une fois le diagnostic terminé.

Nous rechargeons la configuration et redémarrons le service depuis une session SSH directe vers le bastion. Ce redémarrage interrompt les sessions Guacamole actives.

<code bash>
sudo systemctl daemon-reload
sudo systemctl restart guacd
sudo systemctl status guacd --no-pager
</code>

==== Vérification après correction ====

Nous contrôlons que le processus s'exécute désormais avec le compte ''guacd'' :

<code bash>
ps -eo user,group,pid,args | grep '[g]uacd'
</code>

Nous vérifions également les droits sur le répertoire :

<code bash>
sudo -u guacd test -w /var/lib/guacd && echo "Répertoire accessible en écriture"
</code>

Après cette correction, la connexion RDP depuis Guacamole vers le serveur Windows fonctionne.

==== Points à retenir si le problème se reproduit ====

  * Tester le port TCP ''3389'' depuis le serveur qui exécute ''guacd'', plutôt que de se limiter au ping.
  * Vérifier la destination enregistrée dans la connexion Guacamole, ainsi que le compte Windows et son domaine.
  * Consulter les journaux pour distinguer un problème réseau d'un échec de négociation ou d'authentification.
  * Vérifier le compte de service et son accès en écriture à son répertoire personnel.
  * Ne pas modifier les permissions de ''/usr/sbin'' pour contourner cet avertissement.


===== 9. Historique et enregistrement des sessions =====

Les historiques et les vidéos sont deux fonctions distinctes. L'enregistrement exige une configuration de stockage et l'extension de lecture adaptée ; le processus guacd doit pouvoir écrire les fichiers et l'application doit pouvoir les lire.

{{:cyber:guacamole:capture_decran_2026-10-07_a_11.37.06.png?800|Historique de connexion consulté dans le laboratoire.}}

//Historique de connexion consulté dans le laboratoire.//

{{:cyber:guacamole:capture_decran_2026-10-07_a_12.02.18.png?800|Session enregistrée disponible depuis l’historique.}}

//Session enregistrée disponible depuis l’historique.//

Dans cette installation, des droits d'administration ont été accordés au compte auditeur pour accéder aux vidéos. Ce constat dépend de la version et de l'extension : ne pas en déduire qu'un auditeur doit toujours être administrateur. Vérifier les permissions réellement nécessaires avant de reproduire ce choix.

===== 10. Authentification TOTP =====

Le compte rendu indique un enrôlement TOTP et une connexion multifacteur réussie. La procédure d'installation de l'extension n'est pas détaillée dans les sources. Vérifier la compatibilité de l'extension avec la version de Guacamole et la synchronisation horaire.

Les QR codes d'enrôlement, secrets TOTP et codes de secours ne sont pas publiés dans cette documentation.

===== 11. Documentation complémentaire =====

  * [[https://guacamole.apache.org/doc/gug/recording-playback.html|Apache — enregistrement et lecture des sessions]]
  * [[https://guacamole.apache.org/doc/gug/totp-auth.html|Apache — extension TOTP]]


===== 12. Références =====

  * [[https://guacamole.apache.org/doc/gug/guacamole-architecture.html|Apache — architecture Guacamole]]
  * [[https://guacamole.apache.org/doc/gug/configuring-guacamole.html|Apache — configuration Guacamole]]