Apps – GUACAMOLE Partie 3 : Sécurisation

La sécurité, encore et toujours un enjeu des organisations et des mecs paumés comme moi. Certains passent leurs routes d’autres se penchent sur le rebord du monde pour en admirer la poésie. C’est du moins là que je pense être.

Je n’ai pas la prétention de me penser au dessus des autres et encore moins de mes pairs, croyez-moi. Dans l’fond je ne suis qu’un type qui se grille les neurones à vouloir faire bien en me soulant de la complexité des informations mathématiques. 🙂

L’objectif de cette partie est de sécuriser l’ensemble de notre système GUACAMOLE et de finir en beauté tel l’illustre taureau épargné par cette tauromachie de rigueur, de beauté. Venga Venga cher lecteur !

Réseaux

La première question que je me suis posé est, comment rendre notre service sécurisé si nous le publions ? Pour l’instant, notre service est publié via le protocole HTTP¹ sur le port 8080 par défaut.

La réponse à tous les maux reste de passer par un reverse proxy. Donc par NGINX. Toutefois cela ne résout pas le problème du certificat. Publier un service avec un certificat autosigné revient à s’enchainer les téquilas frappées et s’étonner d’être malade à cause du citron…

Pour se faire j’ai fait le choix en l’absence de fond pour acquérir un certificat wildcard de passer par un certificat Let’s Encrypt. Toutefois, j’ai été embêté Je n’ai qu’une IP publique à la maison qui n’est pas statique…

Erwanadoo, où le SysAdmin qui aime se faire du mal…

(Vous avez le jeu de mot avec feu l’opérateur Wanadoo ? 🙂 #enfonceuneporteouverte )

Bref, plus sérieusement, j’ai plusieurs dilemmes :

IP publique dynamique
LiveBox non brigeable (merci mon FAI²)
Publication du port 443 déjà utilisé

Le premier point, je vais répondre à ce dernier en passant par un DynDNS³ facile comme tout et pas besoin de faire un article.

Pour le second point il suffit de faire un double NAT⁴/PAT⁵. Dans l’idée, je vais publier le port 8443 (HTTPS⁶) puis faire un NAT vers mon UTM⁷ qui réalisera un PAT vers mon daemon nginx en 443 qui finalement via son reverse proxy redirigera le flux vers le protocole HTTP sur le port 8080. Vous avez suivi ? Non ? Bon alors je vous fais un petit schéma… 🙂

Pour le dernier point, c’est plus pénible… Effectivement, je publie déjà quelques choses sur le port 443. Pour générer un certificat Let’s Encrypt il faut impérativement que les ports 80 (HTTP) et 443 (HTTPS) soient disponibles. En cherchant un peu, j’ai vu qu’il était possible de passer par l’API⁸ de mon NDD (OVH en l’occurrence) et de réaliser le challenge DCV⁹ et générer ainsi le certificat pour mon bastion.

Certificats

L’installation du package python3-certbot-nginx n’est pour le coup pas obligatoire si vous utilisez le port 443.

$ sudo dnf install certbot python3-certbot-nginx python3-certbot-dns-ovh

Toujours dans mon cas pratique, il me faut maintenant définir mon couple de clé/secret API sur mon registrar. Pour comprendre le fonctionnement, lors de la génération du certificat, nous allons générer un enregistrement TXT¹⁰ qui va être inscrit automatiquement par le certbot sur notre nom de domaine à travers le jeu de clé/secret de l’API généré.

Sur OVH, c’est par là que ça se passe => Lien

Une fois notre clé d’API générée direction notre serveur. Nous allons générer un fichier de configuration ini avec des droits strict 600. Il est important de respecter ce droit pour la bonne et simple raison que nous allons stocker en clair les informations de notre clé d’API et donc la possibilité de réaliser, supprimer, lire et écrire des entrées DNS¹¹ sur notre domaine.

$ sudo vim /etc/.ovh.ini
$ sudo chmod 600 /etc/.ovh.ini

dns_ovh_endpoint = ovh-eu
dns_ovh_application_key = XXXXXXXXXXXXXXXXXXXXXX
dns_ovh_application_secret = XXXXXXXXXXXXXXXXXXXXXX
dns_ovh_consumer_key = XXXXXXXXXXXXXXXXXXXXXX

Une explication rapide, nous spécifions l’emplacement de notre serveur, dans mon cas OVH Europe. Puis les informations que nous avons générée plus tôt soit :

La clé d’application
La clé secréte
La clé d’usage

Il ne nous reste alors qu’à demander la génération de notre certificat en fournissant en paramètre notre fichier INI¹².

$ sudo certbot certonly --dns-ovh --dns-ovh-credentials /root/.ovh.ini -d securebastion.erwanguillemard.com

Ci-dessous, nous pouvons constater que nous avons bien un enregistrement TXT qui a été généré du côté de notre registrar et la génération de notre certificat a été réalisé avec succès 🙂

Grâce au protocole ACME¹³, le certificat va être renouvelé automatiquement donc no stress 🙂 Mais il convient encore une fois comme Saint Thomas de ne croire que ce que l’on voit n’est ce pas ? Alors vérifions.

$ sudo systemctl list-timers
$ sudo systemctl status certbot-renew.timer

Le service est bien actif, nous avons la date de dernière vérification ainsi que le temps d’exécution et la prochaine vérification. Donc tout est ok. Nous pouvons passer à l’installation de NGINX. 🙂

Nginx

Bon, encore une fois, l’installation et l’activation des services NGINX ça devient un peu relou… Je me questionne à faire un article dédié, mais j’ai du mal à voir l’utilité. C’est de mon point de vue trop court pour faire un article, mais trop long pour le mettre dans un billet.

Je vais donc m’arrêter uniquement sur la configuration.

$ sudo dnf install nginx
$ sudo systemctl enable nginx
$ sudo systemctl start nginx

Une fois tout le toutim réalisé, nous allons générer un fichier de configuration dans notre reverse proxy pour notre service guacamole.

$ vim /etc/nginx/conf.d/guacamole.conf

server {
    listen 80;
    server_name securebastion.erwanguillemard.com;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name securebastion.erwanguillemard.com;

    ssl_certificate /etc/letsencrypt/live/securebastion.erwanguillemard.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/securebastion.erwanguillemard.com/privkey.pem;

    # TLS sécurisé
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;

    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:10m;

    # sécurité headers
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "no-referrer" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

   location /guacamole/ {
        proxy_pass http://egapl-guacamole-01:8080/;
        proxy_buffering off;

        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Timeouts (for RDP)
        proxy_read_timeout 3600;
        proxy_send_timeout 3600;
    }
}

Commençons déjà par rediriger le port 80 vers le port 443. Dans notre cas pas trop de soucis puisque ce dernier n’est pas autorisé dans nos flux Inbound de notre UTM. Mais dans le doute, je dirai que c’est un réflexe à avoir. Nous ne sommes jamais assez prudents avec les temps qui court, il serait facile de s’enrhumer.

Dans la seconde partie, dédiée au port d’écoute 443/tcp, nous définissons le nom de notre serveur, l’emplacement de notre certificat et l’emplacement de notre clé privée. Nous ne tolérons que les versions 1.2 et 1.3 du protocole SSL ¹⁴en donnant la priorité aux algorithmes de notre serveur. Pour enfoncer le clou, nous ajoutons les classiques mécanismes de sécurité :

Empêcher le site d’être affiché dans un iframe d’un autre domaine, ce qui évite le clickjacking. L’usage du SAMEORIGIN autorise seulement le site à ouvrir une iframe vers le site
Empêche le navigateur de deviner le type MIME¹⁵ d’un fichier ce qui protège, prévient ainsi l’exécution de script malveillant ou des failles XSS¹⁶
Activation du filtre XSS pour bloquer la page en cas d’attaque XSS. Bien qu’obsolète, j’ai pour habitude de le garder au cas où. Une faille reste une faille possible, même si le risque est faible
Contrôle des informations présentes dans les en-têtes, la présence du no-referrer indique qu’aucune source n’est présente. Ce qui va évité les fuite d’URLs internes, les fuites de tokens dans l’URL et le tracking
L’obligation du navigateur a utiliser le protocole HTTPS. L’objectif et de se prémunir du SSL stripping, du downgrade HTTP et des attaques MITM¹⁷

En complément, lors de la redirection des flux par notre reverse proxy, nous renseignons les options suivantes :

Transmission uniquement du nom de domaine original demandé par le client
Envoie de l’IP¹⁸ réel du client, ce qui permet de connaitre l’identité du client
La construction de la chaine complète des IPs qui sont transmises afin de garder un historique
Sécurisation des cookies
Autorise les websockets

J’avais prévenu, je passe vite tel Speedy Gonzales ! L’un des points que je ne connaissais pas était la possibilité de tester la configuration avant de redémarrer le service. C’est une fonctionnalité qui peut paraitre bidon, mais je trouve ça super avant de relancer le service de savoir que notre configuration est bonne et de ne pas se retrouver avec un service en carafe… 🙂 Oui c’est du vécu.

Tu vois ce que je veux dire ? Alors non pas du tout. Je ne partage pas du tout votre vision. #bisous

$ sudo nginx -t
$ sudo systemctl restart nginx

Le WebSocket, NGINX et GUACAMOLE ça peut poser problème. De ce fait, il est nécessaire de modifier une nouvelle fois le fichier de propriété de guacamole éditer plus tôt dans la partie précédente et d’ajouter la partie NGINX. Sans cela, les flux de passerons pas. Egalement, nous précisons les langages disponible.

$ sudo vim /etc/guacamole/guacamole.properties

# Nginx WebSocket
enable-websocket: true
allowed-languages: fr,en

Nous arrivons au bout ! Enfin. Je pars du principe que nous avons ouvert les flux sur notre UTM et que l’ensemble des NATs / PATs sont ouverts et sécurisé.

Sur notre VM¹⁹ GUACAMOLE, il sera nécessaire d’autoriser le port 443/tcp de manière permanente. Si vous aviez autorisé plus tôt le port 8080/tcp, vous pouvez dégager ce dernier. Et c’est parti pour le reload !

$ sudo firewall-cmd --permanent --add-port=443/tcp
$ sudo firewall-cmd --reload

Dans notre navigateur, nous nous empressons de saisir notre url avec le port 8443 et là c’est comme un coup de piñata en plein dans les chicots !

Mais alors pourquoi autant de violence dans ce bas monde ? Laisse tomber, c’est encore un coup du SELinux… Hé oui, encore lui et il signe d’un Getenforce son nom de la pointe de son Z (ou un truc dans le genre). Bref, autorisons nginx à communiquer sur le réseau.

$ sudo setsebool -P httpd_can_network_connect 1

Retournons faire un petit F5 dans notre navigateur internet et surprise cela fonctionne, et plutôt bien même (le gars qui est fier de lui).

Système

Nginx Protect

$ sudo dnf install httpd-tools

Nous allons créer le fichier qui va contenir les utilisateurs habilités à se connecter à Nginx.

-C : Permet de générer le fichier lors de la première instanciation
/etc/nginx/.guacamole.htpasswd : Le nom du fichier qui va contenir nos utilisateurs
admin : Le nom de l’utilisateur

A la suite de cette commande, un mot de passe sera demandé pour être lié à l’utilisateur.

$ sudo htpasswd -c /etc/nginx/.guacamole.htpasswd admin

Il faut alors se rendre de nouveau dans le fichier de configuration nginx et indiquer dans la section location /guacamole/ les lignes suivantes :

$ vim /etc/nginx/conf.d/guacamole.conf

auth_basic "Restricted Access";
auth_basic_user_file /etc/nginx/.guacamole.htpasswd;

Après un petit reboot des familles du service NGINX, si nous nous rendons sur l’URL²⁰ nous serons invités à nous authentifier au niveau NGINX. Toutefois j’arrive dans un cas où la page n’est pas redirigé. Du moins, pas toute à fait car après une petite action sur la touche F5 le portail réapparait.

Il apparait dans certains cas que des WebSockets s’échangent mal entre NGINX et le serveur tomcat. Donc, je prends cela pour un échec car non fonctionnel. Encore une fois, trop de sécurité tue la sécurité. Je préfère donc ne pas complexifier plus l’infrastructure. J’aurai la possibilité de palier à ce point plus tard car j’ai un autre projet en tête. 🙂

Application

Du côte de l’application, il y a la possibilité de renforcer la sécurité et j’avoue que c’est plutôt plaisant et rassurant de savoir que Apache Guacamole propose des modules, plugins ou addons complémentaires.

Ainsi il est possible de gérer :

Les sources d’authentifications (AD²¹, SAML²² via SSO²³)
L’authentification renforcée par l’usage de MFA²⁴
La mise en place d’un lock sur de l’authentification brute force
La granularité d’accès à une ressource dans le temps
L’enregistrement des sessions vidéos et des événements

Nous retrouvons ainsi les principes de bases de la sécurité, Authentification, Sécurisation des accès, Contrôle et Journalisation des accès. J’ai décidé d’implémenter uniquement les points 2 à 5. Je me garde pour l’instant de côté l’interconnexion à une source d’authentification (est-ce que je m’achète un tenant O365 ? Telle est la question…)

Il est à noter que le mode de déploiement des plugins suit le même mode opératoire. Ne pas s’affoler sur ma santé mentale si vous trouvez que je radote, non je ne branle pas encore de la cafetière #MidnightExpress.

RBAC et Granularité des droits

Cela faisait une éternité que je n’avais pas claqué un RBAC²⁵ comme ça. Bref bien que de plus en plus présent dans les applications, il subsiste malheureusement des applications qui ne permettent pas de définir des droits et permissions de manière granulaire. Heureusement l’application GUACAMOLE n’est pas de ce type là 🙂

En terme de permission, nous pouvons 7 rôles différents :

Droits	Descriptions	Profils
Administration du système	Permet d’accéder à l’administration globale de Apache Guacamole : configuration générale, gestion des extensions, paramètres de sécurité, authentification et supervision complète de la plateforme.	Responsable IT AdminSys
Audit system	Autorise la consultation des journaux d’audit et des historiques d’activité : connexions utilisateurs, actions administratives, accès aux ressources et événements de sécurité.	Responsable IT RSSI²⁶
Créer de nouveaux utilisateurs	Permet de créer et gérer des comptes utilisateurs individuels dans Guacamole. Inclut généralement l’attribution de permissions et de groupes.	Administrateur IAM²⁷ Responsable IT
Créer de nouveaux groupes d’utilisateurs	Autorise la création et la gestion de groupes d’utilisateurs afin de simplifier l’attribution des droits et des accès.	Responsable IT AdminSys
Créer de nouvelles connexions	Permet de créer des connexions vers des ressources distantes (RDP, SSH, VNC, etc.) accessibles via Guacamole.	Administrateur IAM Responsable IT AdminSys
Créer de nouveaux groupes de connexion	Autorise la création de groupes de connexions pour organiser les ressources par environnement, service ou client.	AdminSys
Créer de nouveaux profils de partage	Permet de créer des profils de partage de session afin de définir comment les sessions peuvent être partagées entre utilisateurs (collaboration, support, supervision).	Centre de service, Superviseur Support

MFA

La MFA va nous permettre de renforcer la sécurité quant à l’authentification. C’est maintenant un classique que nous retrouvons dans la majorité des applications. Soyons toutefois pragmatique il ne s’agit pas là d’un moyen infaillible pour verrouiller l’accès à un individu malveillant.

Téléchargeons le plugin depuis le site officiel.

$ sudo curl -L --output-dir /tmp -O https://apache.org/dyn/closer.lua/guacamole/1.6.0/binary/guacamole-auth-totp-1.6.0.tar.gz?action=download

Décompressons l’archive pour manipuler le .jar²⁸.

$ sudo tar -xzf guacamole-auth-totp-1.6.0.tar.gz

Une fois décompressé, il faudra déplacer le plugins dans le répertoire extension de guacamole /etc/guacamole/extensions/. Néanmoins, il sera nécessaire d’appliquer les permissions tomcat sur le fichier. Par flemme, j’ai choisie d’appliquer les droits directement au niveau du répertoire extensions.

$ sudo cp /tmp/guacamole-auth-totp-1.6.0/guacamole-auth-totp-1.6.0.jar /etc/guacamole/extensions/
$ sudo chown -R tomcat:tomcat /etc/guacamole/extensions

Je n’aime pas rester avec les paramètres par défaut. Et donc en parcourant la documentation, j’ai découvert qu’il était possible de sérieusement durcir le token. Cela va se passer dans le fichier guacamole.properties.

$ vim /etc/guacamole/guacamole.properties

# Paramètre TOTP
totp-issuer: Guacamole R-One
totp-digits: 8
totp-period: 30
totp-mode: sha512

J’ai choisi de nommer mon totp Guacamole R-One et d’avoir 8 digits en lieu et place de 6 digits. La durée de renouvellement est de 30 secondes et l’algorithme de génération du totp sera en sha512. Un petit reload des services tomcat et guacamole et hop Let’s Go !

Naturellement, il est possible de désactiver le TOTP, mais je ne le recommande pas. Cela me parait évident.

Lock Brut Force

La lock brut force est sensiblement les mêmes technologies que Faillock ou Fail2ban, mais orienté application et non système. Cela va nous permettre de renforcer la sécurité en limitant le nombre de tentative d’authentification infructueuse à notre bastion GUACAMOLE. L’objectif ici est de retarder un maximum l’individu malveillant à se connecter à notre système.

Téléchargeons le plugin depuis le site officiel.

$ sudo curl -L --output-dir /tmp -O https://apache.org/dyn/closer.lua/guacamole/1.6.0/binary/guacamole-auth-ban-1.6.0.tar.gz?action=download

Décompressons l’archive pour manipuler le.jar.

$ sudo tar -xfz /tmp/guacamole-auth-ban-1.6.0.tar.gz

$ sudo cp /tmp/guacamole-auth-ban-1.6.0/guacamole-auth-ban-1.6.0.jar /etc/guacamole/extensions/
$ sudo chown -R tomcat:tomcat /etc/guacamole/extensions

Encore une fois, les paramètres par défaut ce n’est pas mon truc. Toujours en parcourant la documentation, j’ai limité le nombre de tentatives à 3 est bloqué le compte pour une durée de 1900000 secondes. Cela va se passer dans le fichier guacamole.properties.

$ vim /etc/guacamole/guacamole.properties

# Paramètres Ban
ban-max-invalid-attempts: 3
ban-address-duration: 1900000

Après relance des services tomcat et guacd.

Restriction de connexion améliorée

Une partie que j’affectionne particulièrement puisque ce module permet de pousser plus loin les paramètres de connexion d’un utilisateur. Par exemple de limiter ce dernier à se connecter uniquement durant les heures et jours ouvrés, depuis un site particulier et ou d’interdire l’accès sur un plage horaire etc.

Cela devient alors d’une vraie utilité lorsque l’on souhaite restreindre un prestataire à se connecter à des ressources et de contraindre celui-ci à ne pas faire ce qu’il veut.

Téléchargeons le plugin depuis le site officiel.

$ sudo curl -L --output-dir /tmp -O https://apache.org/dyn/closer.lua/guacamole/1.6.0/binary/guacamole-auth-restrict-1.6.0.tar.gz?action=download

Décompressons l’archive pour manipuler le.jar.

$ sudo tar -xzf guacamole-auth-restrict-1.6.0.tar.gz

$ sudo cp /tmp/guacamole-auth-restrict-1.6.0/guacamole-auth-restrict-1.6.0.jar /etc/guacamole/extensions/
$ sudo chown -R tomcat:tomcat /etc/guacamole/extensions

Etonnant non ?

Recording video

L’un des modules de sécurité les plus important, intéressant et sur lequel je me suis bien cassé les dents. Ce qui me plaît avec GUACAMOLE (et surtout que j’ai détourné sur la solution de bastion Systancia), c’est de pouvoir enregistrer les flux https de connexion à distance peut importe le protocole utilisé.

D’avoir l’enregistrement de la session vidéo permet de suivre au delà d’une journalisation classique les actions effectuées par l’utilisateur. Là où l’application va plus loin (comme Systancia) c’est de proposer l’enregistrement des frapes claviers. Ce qui fait qu’en temps réel sur la vidéo, j’ai également la possibilité de relier une action physique à un évènement logique.

Toutefois, il est à noter que cela va nécessiter un peu de ressource notamment point de vu stockage car les vidéos, ça prend vite de la place…

Téléchargeons le plugin depuis le site officiel.

$ sudo curl -L --output-dir /tmp -O https://apache.org/dyn/closer.lua/guacamole/1.6.0/binary/guacamole-history-recording-storage-1.6.0.tar.gz?action=download

Décompressons l’archive pour manipuler le.jar.

$ sudo tar -xzf guacamole-history-recording-storage-1.6.0.tar.gz

$ sudo cp /tmp/guacamole-history-recording-storage-1.6.0/guacamole-history-recording-storage-1.6.0.jar /etc/guacamole/extensions/
$ sudo chown -R tomcat:tomcat /etc/guacamole/extensions

Il va être nécessaire de modifier le fichier de configuration de notre application Guacamole. Afin de ne pas saturer le système quant au stockage des sessions vidéos, j’ai décidé de modifier l’emplacement par défaut. Naturellement, j’ai dédié un disque ainsi qu’un point de montage sécurisé pour stocker les enregistrements.

$ vim /etc/guacamole/guacamole.properties

# Paramètre Recording
recording-search-path: /mnt/guac_records/recordings

Notre point de montage étant montée, créons le répertoire recordings et attribuons les droits à l’utilisateur qui exécute notre daemon guacd et au groupe utilisateur tomcat. Tomcat n’aura besoin que des droits en lecture.

$ sudo mkdir /mnt/guac_records/recordings
$ sudo chown guacamole:tomcat -R /mnt/guac_records/
$ sudo chmod 2750 /mnt/guac_records/recordings/

Toutefois si nous lançons une session distante cette dernière va s’ouvrir mais nous n’aurons pas d’enregistrement. Mais pourquoi ? Et c’est là que je me suis cassé les dents à deux doigt d’être Borracho Hombre !

Un petit tour dans les logs guacamole est nécessaire.

$ sudo journalctl -u guacd -f

Le daemon guacamole n’a pas le droit d’écriture sur notre répertoire, uniquement les droits en lecture seule. Pourtant les droits défini précédemment sont correct. Qu’est que c’est que ce joyeux bord*l ?!

Revenons sur notre service guacd généré dans la partie précédente. Il y a en sécurité un scope qui définit là où le daemon peut interargir avec le système 🙂 Le hardening c’est diabolique hein ?

$ sudo vim /etc/systemd/system/guacd.service

Ajoutons donc notre path.

#Limiter accès filesystem
ReadWritePaths=/var/lib/guacd /mnt/guac_record

Rechargeons nos service tomcat et guacd.

Par défaut, l’enregistrement vidéo n’est pas activé sur les ressources sur lesquels nous allons nous connecter. L’ajout précédemment du plugin vient ajouter une section supplémentaire.

Si nous faisons un tour dans notre fichier de log et que nous relançons la connexion à une ressource, nous devrions voir maintenant le message suivant :

(Oui je travaille le 01 Mai, mais ce que vous appelez travail, j’appelle cela plaisir 🙂 )

Et si nous regardons alors dans le répertoire où sont stockés les enregistrements vidéo nous retrouvons notre fichier avec l’extension .guac (comme on peut le voir sur la capture ci-dessous, l’enregistrement est là mais ne sera pas exploitable du fait de la mauvaise extension…). Ca, c’est un autre sujet que j’aborderai dans un prochain article.

J’ai parlé en début de cette partie que j’avais utilisé l’outil au delà de son but initial et c’est vrai. L’enregistrement des sessions vidéos me permet de réaliser simplement mes supports de formation professionnels comme personnels. Cela va largement mieux que le classique Win+G chez Microsoft 🙂

Je conçois que c’est une partie plutôt longue et que j’ai encore une fois fait de multiples digressions. Cependant, l’aspect sécurité sur un sujet tel que celui-là joue un rôle primordiale. Cette partie doit être considéré comme une base de référence et non comme une source bête et méchante d’implémentation.

La partie qui va suivre sera plus courte et vise à créer les premières ressources sur notre environnement GUACAMOLE.

Sources

Guacamole : Pratique
<-

Apps Guacamole

Guacamole : Configuration
->

HTTP : HyperText Transfert Protocol ↩︎
FAI : Fournisseur d’Accès Internet ↩︎
DynDNS : DNS Dynamique ↩︎
NAT : Network Area Translation ↩︎
PAT : Port Area Translation ↩︎
HTTPS : HyperText Transfert Protocol Secure ↩︎
UTM : Unified Thread Management ↩︎
API : Application Programming Interface ↩︎
DCV : Domain Control Validation ↩︎
TXT : Texte ↩︎
DNS : Domain Name Server ↩︎
INI : INItialization ↩︎
ACME : Automated Certificate Management Environment (et non A Company Making Everything 🙂 ) ↩︎
SSL : Secure Sockets Layer ↩︎
MIME : Multipurpose Internet Mail Extensions ↩︎
XSS : Cross-Site Scripting ↩︎
MITM : Man In The Middle ↩︎
IP : Internet Protocol ↩︎
VM : Virtual Machine ↩︎
URL : Uniform Resource Locator ↩︎
AD : Active Directory ↩︎
SAML : Security Assertion Markup Language ↩︎
SSO : Single Sign-On ↩︎
MFA : Multi Factors Authentication ↩︎
RBAC : Roles Based Access ↩︎
RSSI : Responsable Sécurité des Systèmes d’Information ↩︎
IAM : Identity Access Management ↩︎
JAR : Java ARchive ↩︎