Paramètres

Une fois authentifié avec un compte super-utilisateur rendons nous dans les paramètres.

Nous pouvons constater qu’il y a 6 catégories distinctes : Session Actives : Affichage qui permet à un auditeur, administrateur de vérifier les connexions en cours. Historiques : Qui regroupe l’ensemble des connexions qui ont eu lieu ainsi que les enregistrements vidéo si le plugins a été déployé. Utilisateurs : Onglet qui permet d’administrer et créé les comptes utilisateurs. C’est également ici que nous pourrons choisir un utilisateur dans le cas d’une jonction avec en source un AAD2 ou AD3. Groupes : Permet de définir des groupes avec des droits particuliers selon les profils des utilisateurs. Connexions : Permet de créer et d’organiser les connexions aux ressources via les protocoles (Kubernets, VNC4, SSH5, RDP6). Préférences : Définie les paramètres communs comme le temps, la nature des clics souris, du clavier etc.

Je rentrerai dans le détail uniquement pour les onglets Utilisateurs, Groupes, Connexions.

Je choisie ici d’afficher la langue d’affichage en Français, le fuseau horaire étant basé sur Paris. Cela a son importance pour les logs et le suivie des connexions aux ressources. Concernant l’apparence, il est possible d’afficher les connexions récentes ainsi que le nombre des dernières ressources consulté. Il faut voir cela comme une zone de favoris. En enfin, la possibilité de modifier son mot de passe. Plus bas dans la section, il est possible de choisir le comportement du clavier et de la souris. La prise en compte de tous les éléments se fait par l’action du bouton Enregistrez en bas de la section.

Utilisateurs

Si nous cliquons sur l’onglet Utilisateurs, nous avons une visibilité sur l’ensemble des utilisateurs présents ainsi que les utilisateurs désactivés.

Cliquez sur Nouvel Utilisateur. Il est important de noter que les droits utilisateurs prévaux sur les droits du groupes. Ce qui nous permet alors de définir un standard pour un groupe puis s’il y a besoin de faire une surcharge au niveau du profil de l’utilisateur. Regardons ensemble les différentes sections de création d’un compte utilisateur.

Il est également à noter que certaines sections sont liées aux divers addons que j’ai implémentés.

Définissions l’identifiant de connexion de notre utilisateur et son mot de passe. Il est possible de désactiver le compte.
	Plus en détail, il est nécessaire de saisir le nom et prénom de l’utilisateur. Question de traçabilité. Il est important de définir le rôle en adéquation avec la matrice RACI7.
Cette partie présente par défaut permet de restreindre le compte de l’utilisateur dans le temps. Par exemple, il est possible de définir une date de début et de fin de connexion. Plus bas, il sera possible d’aller plus loin dans la restriction du compte grâce à l’addon déployé plus tôt.
	Une section présente par l’ajout de la MFA8. Nous pouvons choisir de ne pas appliquer de MFA pour le compte utilisateur. A l’inverse, il est possible d’activer la MFA pour un utilisateur. Cette dernière sera demandé lors de la première connexion de l’utilisateur. Je vous renvoi à la partie sécurité qui traite de l’implémentation du plugin MFA.
Comme énoncée précédemment, l’ajout du plugin de restriction avancée permettra une meilleure granularité dans l’accès aux ressources.
	J’ai l’impression de me répeter et cela m’agace. Peut-être un peu de fatigue de ma part je pense et j’avoue vouloir passer à autre chose. Cela fait un moment que je traite ce sujet. Bref, nous retrouvons ici les droits listés dans notre matrice RACI. Personnellement, je ne définie pas de rôle sur le profil utilisateur mais directement sur le groupe. A l’exception du compte bris de glace. Il est a noter qu’un profil utilisateur standard ne doit pas avoir de permission.
Cette dernière section permet de donner l’accès aux ressources à l’utilisateurs. Comme dit précédemment, les droits peuvent être définie au niveau du groupe. Pour ma part, je définie les permissions à des connexions uniquement dans le cas de surcharge. Comprendre dans cette dernière phrase, réaliser un exception.

Groupes

L’onglet groupe est assez pratique. L’usage de groupe utilisateur permet de définir et d’appliquer un ensemble de politique de connexion aux membres appartenant à ce groupe.

Amazing Capt’ain Obvious… T’en as d’autres des comme ça ?

C’est toujours bon d’enfoncer des portes ouvertes. Là où nous pourrons tirer pleine puissance des groupes ce trouve dans la gestion des éditeurs et autres prestataires externes. Mais également pour ne donner un accès qu’à un service à une ressource. Dans les deux cas, nous nous assurerons que le niveau de sécurité est le même pour tout le monde. Si nous avons besoin de faire une exception, il faudra alors faire une surcharge dans le profil de l’utilisateur.

Pour commencer, définissons un nom de groupe parlant. Il ne faudrait se rajouter du travail avec quelque chose qui doit nous faire gagner du temp…
	Comme énoncé précédemment pour la partie utilisateur, l’ajout du plugin de restriction avancée permettra une meilleure granularité dans l’accès aux ressources. Dans notre cas, cela appliqué à l’ensemble de tous les membres.
Par défaut l’authentification MFA est activée. Toutefois, nous pouvons la désactiver pour l’ensemble des membres.
	[BIS REPETITA] Oui ça me soule 🙂 J’ai l’impression de me répéter et cela m’agace. Peut-être un peu de fatigue de ma part je pense et j’avoue vouloir passer à autre chose. Cela fait un moment que je traite ce sujet. Bref, nous retrouvons ici les droits listés dans notre matrice RACI. Personnellement, je ne définie pas de rôle sur le profil utilisateur mais directement sur le groupe. A l’exception du compte bris de glace. Il est a noter qu’un profil utilisateur standard ne doit pas avoir de permission.
Nous ajoutons nos utilisateurs et nous les voyons comme membres.
	Nous choisissons les ressources auxquelles le groupe doit avoir accès.

Connexions

Cette partie est de loin l’une des plus intéressante et des plus complexes. Je ne détaillerai que les connexions de type SSH et RDP.

L’une des premières choses à réaliser est l’arborescence de notre système. Pour faire simple je vais reprendre partiellement mon infrastructure définie dans ma VCSA9 et l’adapter en conséquence. Il est également possible de définir quelques paramètres au niveau des groupes comme l’extension de restriction d’accès et le nombre de connexion maximum et de connexion maximum par utilisateur. Nous retrouverons ces paramètres dans la création d’une ressources.

Attention, le tableau ci-dessous peut entrainer des nausées ainsi que des risques fatals d’indigestions. Nous demandons aux lecteurs qui ne seraient pas près de ne courir aucun risque et au besoin de se faire accompagner 🙂

Donnez un nom parlant à votre ressource. Généralement le nom de la machine. Définissez l’emplacement où va être stocker la ressource, puis le type de Protocole (Kubernetes, RDP, SSH, Telnet, VNC).
	Vous pouvez dans cette section définir le nombre maximum de connexion sur la ressource ainsi que le nombre de connexion par utilisateur. Là, j’ai déjà définie cela au niveau du groupe. Je ne viens à surcharger et définir celui ci que dans le cas des ressources sensibles.
Si nous avions montée une infrastructure HA Guacamole, nous aurions pu définir une répartition de charge entre les serveurs Guacamole. Perso, ce n’est pas mon cas…
	[BIS REPETITA] … Nan, mais je pense que c’est bon là. On a compris à quoi sert cette partie ?
Si nous avons implémenter la partie PROXY Guacamole, c’est ici qu’il faudra renseigner les paramètres. Toutefois est dans le cadre de mon projet et de l’architecture présentée et en place, je peux me passer de la fonctionnalité.
	La partie qui nous intéresse vraiment 🙂 Renseignons l’IP ou le nom de notre ressource puis le port de connexion en adéquation avec le protocole de connexion saisie plus haut. Il est également possible de renseigner directement les identifiants et mot de passe sur la ressource. Vous vous en doutez niveau sécurité, il est indispensable de compléter les champs #MDR. Toutefois, vous pouvez saisir le nom de domaine. Ne modifier le mode de sécurité que si vous l’avez modifié côté serveur. Et dans le cas de certificat autosigné, cochez la cas pour ignorer le certificat serveur. Si vous utilisez une TS GW10, renseigner les champs intelligemment. Moi, je n’en ai pas. Du moins pour l’instant. Dans les paramètres de base, vous pouvez faire la demande d’exécution de programme au démarrage, de définir le nom du client, le type de clavier et la zone de temps.
Nous retrouvons ici les caractéristiques présent dans la configuration d’un raccourcie RDP classique, l’affichage, le presse papier et la gestion des périphériques externes. Je passerai vite sur cette partie. Ce qui pour moi doit être activer au minima est de forcer la compression sans perte pour l’affichage, et de désactiver la copie si l’usage est pour des utilisateurs et ce afin que nous admin ayons la main sur l’activité des prestataires. En dernier lieux de ne pas faire de redirection des périphériques. Nous ne devons pas avoir confiance ni ne faire confiance aux postes clients. Gardons le principe tel Greg House que tout le monde ment !
	Là nous pouvons encore améliorer notre expérience sur la prise en main à distance sur notre ressource. Il est à noter qu’il y a une notion de curseur entre le confort et la performance utilisateur. Une option avec laquelle je souhaiterai jouer et l’option RemoteApp. J’ai pour idée de me faire un petit projet prochainement et Guacamole pourrait bien m’aider. 🙂 Le reste, à vous de vous pencher dessus si cela vous intéresse (ou autrement dit, démer*ez vous 🙂 )
La partie SFTP11, pas besoin je passe mon tour. Pour moi cela se fait via le rebond et pas autrement. Mais la partie Enregistrement Ecran ça c’est intéressant. Guacamole (comme Systancia) offre la possibilité de tracer l’ensemble des actions réalisés par un utilisateur lors d’une ouverture de session. C’est à dire enregistrer les frapes claviers et la session vidéo. Cela sera enregistré sous le format vidéo .guac sur le serveur. Il nous suffit sur la ressource de renseigner dans le chemin et dans le nom de l’enregistrement les valeurs : /mnt/guac_records/recordings/${HISTORY_UUID} ${GUAC_USERNAME}-RDP_${GUAC_DATE}-${GUAC_TIME}.guac Et de cocher la case créér automatique un chemin d’enregistrement. A ce jour je ne note qu’un dysfonctionnement entre la saisie des évènements clavier et vidéo qui nécessite un peu de temps de ma part. Un point qui nécessitera un article annexe, bonus sera la conversion des fichiers vidéos .guac en .mp4.
	Enfin, nous voilà au bout de notre configuration de notre ressource. J’avoue que l’interface n’est pas si sexy que ça, mais est-cela que nous attendons ? Je ne pense pas 🙂 Bref, encore une fonctionnalités avec laquelle je n’ai pas joué, le WOL12. Ce dernier peut s’avérer pratique pour redémarrer un serveur éteint. Je suis partagé sur l’usage car j’ai souvenir dans une ancienne vie professionnelle de dérive lié à l’absence de patiente et amateurisme de certain collaborateur. Je préfère donc me garder un accès de secours si besoin et gérer l’état d’une ressource virtualisée par l’interface de virtualisation peut importe son nom. Pour finir, l’historique de connexion à la ressource.

Je passe la notion de partage de profil. Pour moi, il ne devrait pas être possible à un simple utilisateur de réaliser ce type d’action.

Un point remonté qui suscite de la frustration, j’avais déjà remonté ce point au support Systancia à l’époque et me voilà de nouveau confronté à celui-ci. Lorsque l’on utilise la MFA sur un système GNU/Linux pour s’authentifier, ce module PAM¹³ rentre en conflit avec la solution de bastion qui ne pouvant et ne sachant interpréter le retour crash et retourne un TimeOut. La seule solution est que j’ai trouvé pour l’instant et soit de désactiver la MFA ou rendre cette dernière facultatif. A voir si j’arrive à palier à ce problème.

Voilà, nous arrivons à la fin de notre périple. Je vais réaliser une courte démonstration vidéo qui comme d’habitude fera une synthèse de l’article et permettra de voir le fonctionnement de l’appliance Guacamole.

Sources

1. RTFM : Read The Fuc**ng Manual ↩︎
2. AAD : Azure Active Directory ↩︎
3. AD : Active Directory ↩︎
4. VNC : Virtual Network Computing ↩︎
5. SSH : Secure SHell ↩︎
6. RDP : Remote Desktop Protocol ↩︎
7. Matrice RACI : ↩︎
8. MFA : Multi Factors Authentification ↩︎
9. VCSA : VCenter Server Appliance ↩︎
10. TS GW : Terminal Server GateWay ↩︎
11. SFTP : Secure File Transfert Protocol ↩︎
12. WOL : Wake On Lan ↩︎
13. PAM : Pluggable Authentication Modules ↩︎

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 :

Il ne nous reste alors qu’à créer les différents type de groupe utilisateur de peupler ces derniers selon le rôle de chacun. Dans le contexte d’usage (j’entends par là utilisateur), il revient de faire des groupes selon l’organisation des groupes de connexions.

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 !

Lors de la première authentification, il nous sera demandé de scanner le QRCode pour générer le totp. Le reste c’est toujours la même chose, on entre le totp et hop c’est paramètré.
Il est possible de désactiver l’authentification ou de réinitialiser la MFA pour un compte. Il faut pour cela avoir les droits de gestion des utilisateurs et d’éditer le profil.

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

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. (J’avais prévenu du copié, collé M’sieurs, Dames les lecteurs).

$ 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

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-restrict-1.6.0/guacamole-auth-restrict-1.6.0.jar /etc/guacamole/extensions/
$ sudo chown -R tomcat:tomcat /etc/guacamole/extensions

Ici, nous n’aurons pas besoin de modifier notre fichier de configuration Guacamole. Nous retrouverons dans la création de ressources ou dans la création d’un compte utilisateur les paramètres suivants.

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

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-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.

Il y a 3 éléments important pour réaliser l’enregistrement. Avoir un nom de fichier et un chemin valide et d’activer la création automatique vers le chemin spécifier. Sans cela, vous êtes marron comme le disait un de mes anciens employeurs. Chemin d’enregistrement : Je renseigne le chemin absolu d’enregistrement des session vidéo. Afin de garantir l’unicité des enregistrements, je rajoute l’UUID de connexion à la ressource. /mnt/guac_records/recordings/${HISTORY_UUID} Nom de l’enregistrement : Le nom du fichier. Il est important de préciser l’extension .guacamole à la fin. J’ai décidé d’afficher en premier le nom de l’utilisateur qui est authentifié puis le protocole et enfin la date de la session. ${GUAC_USERNAME}-RDP_${GUAC_DATE}-${GUAC_TIME}.guac On note ici que je n’ai pas coché la case concernant les événements clavier. Effectivement, lorsque j’active cette dernière, je ne peux plus lire mes vidéos. Je dois encore investiguer la chose…

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

• Let’s Encrypt : API OVH
• Let’s Encrypt : Challenge
• GUACAMOLE : MFA TOTP
• GUACAMOLE : Lock Brut Force
• GUACAMOLE : Login & Connexion Restriction
• GUACAMOLE : Record Vidéo

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

Pourquoi c’est vraiment si compliqué que ça d’installer Guacamole ?

Non pas compliqué du tout, mais j’ai voulu faire les choses « simples » pour changer. Je n’ai pas souhaité installer Tomcat depuis le gestionnaire de package mais installer ce dernier depuis les sources et donc il ne faut pas suivre bêtement le guide Guacamole.

J’ai tellement fumé des méninges que Tezcatlipoca n’était pas loin de me couper les ailes et de me pousser à l’exil… (Oui je pars en délire sur le monde amérindien et la culture mexicaine).

Mais bon le sacrifice en vaut largement la chandelle car c’est au bout de tout cela que je vais trouver mon El Dorado à l’inverse de Cortés.

Normalement, si vous suivez ce guide et l’ensemble des références vous devriez avoir un système bien durci. J’aimerais d’ailleurs bien trouver quelqu’un pour pentester mon système.

Place à l’action !

Dépendances

Pour les dépendances, j’ai décidé de ne pas mélanger les sujets. Après réflexion, ayant déjà réalisé un article sur MariaDB, je me suis dit que j’allais faire de même pour Tomcat et faire tout simplement une référence à ces derniers dans ce billet. Cela devrait rendre plus digeste le déploiement.

SGBD : MariaDB

Pour la procédure, c’est par là que ça se passe : Lien

Concernant la configuration de la BDD¹ et des Users nous aborderons ce point dans la partie configuration.

Tomcat

Pour la procédure, c’est par là que ça se passe : Lien (Que d’originalité… Merci, je sais).

Guacamole

L’installation se déroulera en deux temps. Un temps pour le serveur Guacamole et un second pour l’application.

Guacamole – Server

Toujours pour faire simple, je vais installer l’application nativement et donc compiler cette dernière. Pour rester cohérent, je vais installer Guacamole à côté de Tomcat sous /opt.

Qui dit installation par compilation dit ? Création d’un groupe et utilisateur dédié à notre daemon Guacamole. Les SysAdmin qui font tout tourner en tant que root, je ne sais pas comment vous faites niveau sécu et diag de vos logs…

Créons le groupe et l’utilisateur de service guacamole

$ sudo groupadd --system guacamole
$ sudo useradd --system --gid guacamole --shell /sbin/nologin \
--home-dir /var/lib/guacd guacamole

$sudo mkdir -p /var/lib/guacd
$sudo chown -R guacamole:guacamole /var/lib/guacd
$sudo chmod 750 /var/lib/guacd

Je vais plus loin en définissant le home du compte de service dans /var/lib/guacd. Il convient également de définir les bonnes permissions sur le répertoire home.

Comme dit plus haut, nous allons installer notre daemon guacamole sous /opt, donc nous devons créer le répertoire adéquat.

$ sudo mkdir /opt/guacamole
$ cd /opt/guacamole

Nous sommes maintenant parés pour l’installation.

Dépendances

Le daemon Guacamole (que nous appellerons guacd) nécessite des dépendances dont certaines se trouvent dans le répo en développement. Il faut ajouter ou plutôt autoriser les packages en développement CRB². En règle générale, si nous sommes amenés à réaliser des compilations, il est préférable d’activer le repository.

$ sudo crb enable

Le repository est bien présent. Il nous faut maintenant installer les dépendances en cours de développement (le fameux *-devel dans les noms des paquets). Il est possible selon les distributions que les noms changent.

$ sudo dnf install cairo-devel libjpeg-turbo-devel libpng-devel libtool libuuid-devel

Niveau dépendance pour la compilation nous sommes au poil. Reste toutefois les dépendances propres à Guacamole pour se connecter aux ressources ainsi que pour l’usage de certaines fonctionnalités. Pour ce faire, il va falloir ajouter un repo pour les packages vidéo (mpeg), rdp, ssh etc.

$ sudo dnf install --nogpgcheck https://mirrors.rpmfusion.org/free/el/rpmfusion-free-release-$(rpm -E %rhel).noarch.rpm https://mirrors.rpmfusion.org/nonfree/el/rpmfusion-nonfree-release-$(rpm -E %rhel).noarch.rpm

Nous ne sommes pas obligés d’installer toutes les fonctionnalités présentes dans Guacamole. Pour ma part je ne souhaite utiliser Guacamole que pour établir des connexions RDP³ et SSH⁴. J’ai également besoin des dépendances pour enregistrer les flux vidéo. Je n’ai nullement besoin de VNC⁵, les websockets pour Kubernetes ou de telnet.

$ sudo dnf install ffmpeg-devel freerdp-devel pango-devel libssh2-devel openssl-devel libwebp-devel

Et voilà, c’est tout. Nous avons déjà passé pas mal de temps ensemble déjà non ? Et bien il faut savoir que nous n’avons pas encore réellement commencé à jouer avec Guacamole. Nous avons juste tourné autour.

Là s’arrêtent les dépendances, Ici commence Guacamole !

Installation

L’installation se passe par le téléchargement du package guacamole-server-1.6.0.tar.gz dans sa dernière version.

1 – Téléchargement

J’ai pour habitude d’utiliser curl et non wget, wget n’étant pas nativement déployé sur RockyLinux. Bref, nous retrouverons cette commande tout au long de ce billet. C’est pourquoi j’expliquerai qu’une seule fois les arguments de cette commande.

• -L : Permet d’autoriser les liens annexes lors du téléchargement
• –output-dir : Définir le répertoire où doit être stocké le fichier téléchargé
• -O : Préciser l’URL⁶ de l’élément que nous voulons télécharger

$ sudo curl -L --output-dir /opt/guacamole -O https://apache.org/dyn/closer.lua/guacamole/1.6.0/source/guacamole-server-1.6.0.tar.gz?action=download

Idem que pour l’explication de la commande, j’ai pour habitude de toujours vérifier les empreintes des éléments téléchargés.

Pour deux raisons :

• Vérifier que la ressource n’a pas été altérée
• Vérifier que la ressource est complète

Je ne mettrai pas à chaque fois cette commande dans les multiples téléchargements qui vont être réalisés. Toutefois vous avez les éléments et savez comment faire, si vous l’ignoriez 🙂

$ sha256sum /opt/guacamole/guacamole-server-1.6.0.tar.gz

2 – Extraction

Le hash est conforme. Hourra. Hourra ?! Nous pouvons donc extraire l’archive tar.gz. Attention où vous êtes, vous devez être pour plus de simplicité dans /opt/guacamole 🙂

$ tar -xzf guacamole-server-1.6.0.tar.gz

3 – Compilation, Installation

Déplacez-vous dans le répertoire que nous venons d’extraire, puis lancez la configuration pour vérifier que tout est conforme et qu’il ne manque pas une dépendance, la compilation afin que le MakeFile soit généré puis l’installation de Guacamole.

La dernière commande va mettre à jour les bibliothèques système et va mettre à jour le cache des liens symboliques. Sinon, nos programmes ne trouveront pas les bonnes bibliothèques.

$ cd guacamole-server-1.6.0
$ ./configure

Nous avons donc le résultat que nous souhaitons et pas d’erreur. La petite synthèse en fin de notre commande nous rassure quant à ce que nous allons réaliser comme opération. Certains SysAdmin vous diront que la compilation c’est ce qu’il y a de plus safe. C’est la mentalité de la branche Slackware. J’avais une ancienne connaissance de cette école et je pense que je vais m’y mettre également.

$ make
$ make install
$ ldconfig

4 – Guacamole & Systemd

L’un des points négatifs de compiler ces applications c’est que rien n’est fait automatiquement comme lors de l’usage de commandes dnf install par exemple. Et donc là il va falloir enregistrer notre service dans systemd afin que celui-ci puisse être démarré, arrêté, redémarré manuellement ou automatiquement.

Pour cela, rien de plus simple, il suffit de créer le fichier sous /etc/systemd/system/

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

Puis de renseigner ce dernier comme suit :

[Unit]
Description=Guacamole proxy daemon (guacd)
After=network.target

[Service]
Type=simple
User=guacamole
Group=guacamole

ExecStart=/usr/local/sbin/guacd -f -b 127.0.0.1 -l 4822

Restart=on-failure

#Hardening
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
MemoryDenyWriteExecute=true
LockPersonality=true

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

[Install]
WantedBy=multi-user.target

Il faut garder ce fichier en tête. Car comme vous pouvez le constater, il y a une part de hardening sur laquelle, je reviendrai plus tard.

Il ne reste plus qu’à recharger le gestionnaire systemd puis à lancer notre daemon Guacamole. Si ce dernier est démarré, nous pouvons le configurer pour démarrer automatiquement.

$ sudo systemctl daemon-reload
$ sudo systemctl enable guacd
$ sudo systemctl start guacd

Le plus gros du chemin a été fait. Notre daemon Guacamole est fonctionnel et opérationnel.

Guacamole – Client

Là encore une fois, j’ai voulu faire bien et je me suis tellement compliqué la vie que j’ai décidé d’abandonner.

Donc tu nous lâches à la moitié du chemin ? Tu aurais pu nous informer avant non tu crois pas ? Espèce d’enf**ré !

Je comprends que dit comme ça, cela peut porter à confusion. En réalité, je vais mettre deux méthodes pour utiliser Guacamole. L’une via la compilation du client (qui m’a frustré) et le téléchargement de l’application directement. Comme ça libre à vous de reprendre mes travaux là où je les ai stoppés.

Installation

J’ai dans un premier temps voulu compiler mon client Guacamole comme j’ai compilé mon serveur Guacamole. Jusque-là, logique non ? Puis lors de la compilation ça fail sur une librairie java… Je me farcis donc les logs de compilation et me rend compte que cela est dû à la génération de la javadoc… Après investigation, il est possible de bypass cette erreur en excluant la partie documentation.

J’ai lâché l’affaire à ce moment-là. Frustré. J’aurais pu persévérer mais voyez-vous, je sais que le mieux est l’ennemi du bien. Donc, pour ne pas tomber dans le piège du perfectionniste qui aura un paquet fonctionnel mais possiblement avec des dysfonctionnements à moyen ou longs termes, j’ai décidé de changer mon fusil d’épaule et d’appeler Zorro.

J’ai donc pris la dure décision de télécharger directement l’application au point .war depuis le site officiel.

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

$ sha256sum /guacamole/guacamole-1.6.0.war

Une fois télécharger, il convient alors de déplacer le fichier directement dans le répertoire webapps de tomcat. Vous noterez que j’ai renommé le guacamole-1.6.0.war en guacamole.war. Cela aura son importance dans notre URL d’accès. Il est nécessaire de définir la propriété a l’utilisateur de service tomcat sur notre application. Sinon elle ne pourra pas être lancé par Tomcat.

$ cp /tmp/guacamole-1.6.0.war /opt/tomcat/webapps/guacamole.war
$ chown tomcat:tomcat /opt/tomcat/webapps/guacamole.war

Et maintenant c’est terminée pour Guacamole. Le reste sera que de la configuration…

Configuration

Il va falloir être rigoureux car la configuration à la moindre erreur peut devenir aussi punitive qu’un mauvais pattern dans un fromsoftware… Oui je suis de ce genre de type à prendre du plaisir sur les Souls Like, à la limite du masochisme… 🙂

Le commencement sera donc de créer le répertoire de notre service guacamole. Ce répertoire contiendra le fichier de configuration ainsi que le répertoire propre aux extensions ainsi que le répertoire pour les bibliothèques.

$ sudo mkdir /etc/guacamole
$ sudo mkdir /etc/guacamole/{extensions,lib}

SGBD – MariaDB

Il subsiste un petite putass**ie pour le connecteur MariaDB avec Guacamole. Je me suis dit et en suivant le guide officiel qu’utilisant MariaDB il me faudrait uniquement le connecteur Java MariaDB… Erreur Grave dirait Coluche…

Bref, j’ai installé le paquet depuis le repo puis j’ai déplacer le .jar dans le répertoire /etc/guacamole/lib (avec les bons droits).

$ sudo dnf install mariadb-java-client

#Où est installé le paquet
$ sudo rpm -ql mariadb-java-client | grep jar

$ sudo ln -s /usr/lib/java/mariadb-java-client.jar /etc/guacamole/lib/
$ sudo chown tomcat:tomcat -R /etc/guacamole/lib/

Pourtant si je regarde les logs catalina.out il nous sera retourné que l’application Guacamole n’arrive pas a établir de connexion avec la base de données. Et là croyez-moi, j’ai pas mal cherché si c’était côté hardening de mon côté ou si c’était sur la couche 7. Et donc conclusion ? Il nous faut le connecteur java pour mysql également…

Bref, on télécharge le connecteur sur le site officiel mysql, on check le hash, on décompresse et l’on déplace le .jar sous /etc/guacamole/lib.

$ sudo curl -L --output-dir /tmp -O https://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-j-9.7.0.tar.gz
$ sudo tar -xzf /tmp/mysql-connector-j-9.7.0.tar.gz
$ sudo cp /tmp/mysql-connector-j-9.7.0/mysql-connector-j-9.7.0.jar /etc/guacamole/lib/
$ sudo chown tomcat:tomcat -R /etc/guacamole/lib/

Nous allons préparer et configurer notre base de données Mariadb. Connectons nous directement à notre BDD en root.

$ sudo mysql -u root -p

A partir de maintenant toutes les commandes seront des commandes SQLs⁷. Je vais créer la base de données (vide naturellement) et définir notre utilisateurs et les permissions de ce dernier sur la base.

> CREATE DATABASE guacamole_db;

> CREATE USER 'guacamole_user'@'localhost' IDENTIFIED BY 'some_password';

> GRANT SELECT,INSERT,UPDATE,DELETE ON guacamole_db.* TO 'guacamole_user'@'localhost';

> FLUSH PRIVILEGES;

Naturellement, libre à vous de changer le nom de la BDD ou de l’utilisateur ainsi que du mot de passe. Une fois les privilèges flush, quittez le terminal et vérifiez que vous pouvez vous connecter à la base de données guacamole avec notre utilisateur fraichement créé. (Oui la capture d’écran n’est pas le reflet exact des commandes tapées :)).

$ mysql -u guacamole_r-one -p -b guacamole_db

Maintenant que notre instance est prête, allons chercher la structure ainsi que le connecteur JDBC⁸ guacamole. Pour se faire téléchargeons le connecteur depuis le site officiel Guacamole :

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

Vérifions son empreinte puis réalisons l’extraction. Attention où vous vous situez 🙂

$ tar -xzf guacamole-auth-jdbc-1.6.0.tar.gz

Déplacez vous dans le répertoire fraichement extrait /tmp/guacamole-auth-jdbc-1.6.0/mysql. Naturellement si vous avez choisi en SGBD⁹ PostgreSQL ou MSSQL¹⁰ vous n’allez pas dans ce répertoire. Il ne faut pas suivre le guide aveuglément… A l’intérieur du répertoire nous avons deux fichier *.sql. Un fichier qui va créer la structure de notre BDD et le second fichier pour créer l’utilisateur guacadmin. Exécutons les deux fichiers.

$ cd /tmp/guacamole-auth-jdbc-1.6.0/mysql
$ cat schema/*.sql | mysql -u root -p guacamole_db

Nous pouvons vérifier que tout est fonctionnel en affichant par exemple les tables de la BDD guacamole.

Dernière étape pour en finir avec la configuration de la base de données, il nous faut déplacer le connecteur jdbc pour guacamole dans le répertoire /etc/guacamole/extensions.

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

Normalement nous avons fait le plus gros du travail. Le reste sera une parti de plaisir à côté de ça.

Serveur Web – Tomcat

Maintenant il va falloir dire avec tact et diplomatie à notre serveur Tomcat les variables d’environnement liées à Guacamole et où ce dernier doit aller chercher les ressources.

Pour ce faire, nous allons créer un fichier setenv.sh sous le répertoire binaire de tomcat /opt/tomcat/bin.

$ sudo vim /opt/tomcat/bin/setenv.sh

Nous précisons où pointe la variable GUACAMOLE_HOME puis nous allons mettre à jour sans écraser le contenu de la variable JAVA_OPTS pour définir la propriété système guacamole.home soit initialisé à /etc/guacamole.

GUACAMOLE_HOME=/etc/guacamole
export JAVA_OPTS="$JAVA_OPTS -Dguacamole.home=/etc/guacamole"

Nous ajustons les permissions pour que tomcat puisse exécuter le fichier.

$ sudo chgrp tomcat /opt/tomcat/bin/setenv.sh
$ sudo chmod 750 /opt/tomcat/bin/setenv.sh

Firewall

Il nous faut autoriser notre application Guacamole a être accessible sur notre firewall. Il va donc falloir autoriser notre bon vieux protocole http sur le port 8080/tcp.

T’es sérieux là ?

Oui bah c’est comme ça que ça vous plaise ou non. Il n’y a pas de possibilité avec Guacamole de faire du HTTPS¹¹ nativement. Mais soyez certains que je vais remédier à cela dans la partie sécurité. Pour le moment nous nous suffirons de ça.

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

Guacamole

Dernière arrêt, Acapulco les enfants, terminus de notre voyage. Nous pourrons admirer les anges volants tout en admirant l’animosité pacifique de l’océan.

Nous allons créer le fichier de propriété de guacamole pour que ce dernier puisse se connecter aux différentes ressources (bdd, serveur guacamole). Ce fichier évoluera dans la partie suivante.

$ vim /etc/guacamole/guacamole.properties

# Paramètres MariaDB
mysql-driver: mysql
mysql-hostname: 127.0.0.1
mysql-port: 3306
mysql-database: guacamole_db
mysql-username: guacamole_user
mysql-password: VotreMotDePasseFort

# Paramètres guacd
guacd-hostname: localhost
guacd-port: 4822

Il nous faut alors définir les droits et s’assurer du bon niveau de sécurité.

$ sudo chmod 640 /etc/guacamole/guacamole.properties
$ sudo chmod 755 /etc/guacamole
$ sudo chown -R tomcat:tomcat /etc/guacamole
$ sudo systemctl restart tomcat guacd

C’est maintenant l’heure de se servir une cerveza bien fraiche avec quelques nachos et de taper dans notre Guacamole pour voir quel gout il a !

Test

Il ne faut pas oublier de passer sur notre UTM¹² en amont pour autoriser dans un premier temps notre rebond à communiquer avec notre VM¹³ Guacamole sur le port 8080/tcp.

Dans notre navigateur web, rendons-nous à l’URL http://ip-srv:8080/guacamole. Si tout va bien, nous devrions voir s’afficher la page d’authentification de notre serveur Guacamole.

Authentifions nous avec le login et mot de passe par défaut guacadmin/guacadmin.

Il ne nous reste alors qu’à créer un nouvel super administrateur et désactiver/supprimer le compte guacadmin par sécurité. Dans l’état, notre bastion est opérationnel. Il faut tout de même sécuriser et renforcer la sécurité de ce dernier.

Je ne pense pas utile de me poser sur la configuration de création et de connexion à une ressource. Je ferai cela dans une partie 4 dans une vidéo de démo.

Place à l’assaisonnement de notre serveur Guacamole, pardon à sa sécurisation 🙂

Sources

• Erwan GUILLEMARD : Billet MariaDB
• Erwan GUILLEMARD : Billet Tomcat

1. BDD : Base De Données ↩︎
2. CRB : CodeReady Builder ↩︎
3. RDP : Remote Desktop Protocol ↩︎
4. SSH : Secure SHell ↩︎
5. VNC : Virtual Network Computing ↩︎
6. URL : Uniform Resource Locator ↩︎
7. SQL : Structured Query Language ↩︎
8. JDBC : Java DataBase Connectivity ↩︎
9. SGBD : Système de Gestion de Base de Données ↩︎
10. MSSQL : Microsoft Server SQL ↩︎
11. HTTPS : HyperText Transfer Protocol Secure ↩︎
12. UTM : Unified Thread Management ↩︎
13. VM : Virtual Machine ↩︎

Bastion (nom masculin) : Ouvrage polygonal à deux faces et deux flancs en saillie sur une enceinte ; Point fort d’une ligne de défense ; Ce qui forme une défense solide, un soutien inébranlable de quelque chose

Dictionnaire Larousse

La solution Guacamole se pose donc comme une solution qui doit servir de défense solide et soutien inébranlable à notre SI¹. Il doit être avec notre UTM² le point fort de notre ligne de j’ose l’écrire cyberdéfense (que c’est beau) !

Son objectif ? Contrôler les flux d’entrée et les accès à notre SI.

Et le comment Monsieur ? Ca nous allons voir la théorie dans cette partie ainsi que l’architecture

Qué es el Guacamole?

Le premier qui me dit que c’est un plat culinaire, je lui balance mon avocat commis d’office ! En plus je ne sais pas ce que j’ai écrit en titre de partie, je n’ai pas appris l’espagnol. Toutefois cela ne me semble pas faux…

Bref, après cette entrée en matière plus que discutable, Guacamole est né de Michael Jumper en 2010 (sous le nom RealMint) dont l’objectif principal est de mettre en place une passerelle d’accès sans client pour se connecter à des ressources via les protocoles RDP³, VNC⁴, SSH⁵ à travers un navigateur internet. C’est en 2016 que le projet est donné à la Fondation Apache qui reprend le projet top level en incubation . C’est alors en 2017 naît Guacamole sous licence Apache voit le jour.

Guacamole étant utilisé à des fins internes et étant issu du monde libre (opensource), il est difficile de définir l’utilisation de la solution dans le monde de l’IT. Pour autant, cela reste une bonne solution pour se passer d’outils de prise en main à distance.

Cependant, il est nécessaire de garder à l’esprit qu’un outil opensource n’est pas gratuit. Ah bon ? Tu as sorti la CB ? Ce que je veux dire par là et pour l’avoir expliqué maintes et maintes fois à des clients, DGs⁶ et autres DSIs⁷ la solution est gratuite, mais le temps ETP⁸ ne l’est pas. Certaines fois il est préférable de lâcher un petit billet et avoir un support que ne rien lâcher et subir une indisponibilité de service qui dure, qui dure…

Architecture & Best Practices

Pour cette partie, je pense qu’il va falloir préciser une nouvelle fois que la petite infrastructure que j’ai ne me permet pas de respecter les règles de bonnes pratiques. Mais encore une fois, je ne passerai pas outre et je propose de voir l’architecture de mes rêves et l’architecture du moindre mal que je vais mettre en place 🙂

Guacamole est une application que se décompose en deux parties, une partie application web et une partie serveur.

Donc qui dit application et serveur dit d’office un front et un back end. De plus ai-je écrit web ?

Effectivement, l’application guacamole est un .jar. Un servlet dans notre jargon, soit une application web sous java. Il nous faudra donc un serveur tomcat et java.

Les données guacamole sont stockées dans un SGBD⁹. Là dessus, Guacamole est sympa, le choix nous est laissé de choisir entre PostgreSQL, MySQL/Mariadb et MSSQL¹⁰.

Donc cela nous donnerait, un serveur en DMZ pour la partie Web avec l’application Guacamole et un serveur Guacamole isolé avec la base de données.

Le schéma ci-haut, serait applicable si c’était en entreprise et encore, je dédierai un serveur pour la partie SQL pour éviter toutes corruptions de données éventuelles. Mais voilà, je n’ai pas de ressources (ou du moins, il ne m’en reste plus des masses avec les VMs qui poussent dans tous les sens… J’ose même claquer un LOL des familles 🙂 #vieuxmec).

Donc ma cible sera plutôt ce type d’infrastructure All-In-One.

Oui niveau sécurité, je mise tout sur mon firewall et son proxy et le hardening de mon OS¹¹ Linux. Par contre je reviendrai en détail sur certains mécanismes de sécurité que j’ai mis en place.

Performances et Recommandations

Côté performances tout va dépendre de notre environnement et de notre usage. Si c’est juste pour une personne pour intervenir sur un serveur, autant ne pas trop se prendre la tête. A l’inverse, si c’est pour faire de la grosse production avec de la charge, une architecture avec répartition de charge sera nécessaire (LoadBalancing pour les intimes).

Sympa les ressources hein ? Vous comprendrez qu’entre deux petites tequilas frappées, je préfère la petite infra all in one ? 🙂

[Dans le cadre de la loi Evin, l’abus d’alcool est dangereux pour la santé et doit être consommé avec modération]

Je n’aborde pas le sujet du stockage car ce dernier incombe à chacun de savoir ce qu’il doit faire. Mais s’il vous plaît éviter la mono partition et des tailles de disque ridicules. En d’autres termes, ne soyez pas radin mais ne tombez pas non plus dans le surprovisionning.

Les choix du gringo

C’est autour d’une petite cerveza des familles que j’écris ces lignes (la San José ce n’est pas ce que je préfère le plus au monde… Par contre j’ai le souvenir d’une petite mezcal direct du Mexique. Un délice), le gringo que je suis doit prendre des décisions.

Il existe deux grands moyens d’installer Guacamole… La version docker et la version application native. Je sais clairement que je ne vais pas me faire des amigos avec cet article. Je ne CROIS PAS en DOCKER.

Oui, bah je vous laisse râler et pester contre moi. Quitte à me balancer à Machete, je ne changerai pas d’avis !

Pourquoi je ne crois pas en docker ? Docker et pour moi utile pour les environnements de développement. La conteneurisation est quelque chose qui a révolutionné le monde de l’informatique mais je ne vois pas sa valeur ajoutée dans le monde de l’infrastructure. Egalement et de ce que j’ai pu constaté, rares sont les SysAdmins qui configurent et sécurisent proprement leurs environnements GNU/Linux alors imaginez la sécurisation en surcouche des conteneurs ? A maintenir dans le temps ce n’est pas selon moi une solution viable. Alors oui c’est rapide à déployer, mais personnellement cela ne m’intéresse pas de réaliser ce genre de chose.

J’ai donc décidé de me casser les dents sur une installation native. Et là je peux vous dire que des choses j’en ai apprises et des Stacks Traces Java dans les journaux j’en ai mangé autant que je mange de quesadillas. Si Senor !

Côté SGBD, j’ai décidé de repartir sur mon premier amour MariaDB. J’avoue avoir longtemps hésité avec PostgreSQL ne pouvant me décider, j’ai fait un plouf plouf avec ma fille. L’otarie a gagné contre l’éléphant.

Donc résumons :

• Serveur Guacamole :
  • Système : RockyLinux 10
    • Durcissement ANSSI¹² de l’OS
    • Disque dédié à l’OS
    • Disque dédié à la BDD¹³
    • Disque dédié aux enregistrements vidéos (chutttt sinon c’est vous spoiler…)
  • Guacamole : version 1.6 [dernière en date]
  • SGBD : MariaDB 15.X [dernière sous version en date]
  • Tomcat : version 9.X [dernière sous version en date]
    • La version 10 n’est pas compatible…
  • JAVA : version 21

Maintenant que nous avons tout ce qu’il nous faut en guise d’informations, il est temps de se lancer dans l’aventure du déploiement de Guacamole et laissons nous pousser des ailes comme Quetzalcóatl et en route pour la partie suivante <3

Oui, je ne parle pas de sécurité dans cette partie contrairement à certains de mes précédents billets. Le sujet étant assez important, j’ai pris le parti de faire une partie complètement dédiée. C’est pour vous montrer une fois encore que je ne veux pas prendre le sujet à la légère et qu’il y a matière à dire et à faire.

Modèle RACI

Je ne suis pas un grand habitué des matrices RACI. J’ai toujours vu ces dernières comme un casse tête à rédiger (ce que j’adore honnêtement) mais surtout comme une horreur à faire appliquer. Néanmoins au vu de la criticité de notre application et de ce que je chercher à implémenter, il me parait opportun et surtout cruciale de définir cette dernière.

Je suis d’accord, cela devrait être dans la partie sécurisation, mais personnellement mettre ce dernier en début de document/billet me parait plus important et de se donner la ligne à suivre.

Ce qui me permet de définir la matrice suivante dans un monde idéal où l’ensemble des services IT¹⁴ sont présents au sein d’une organisation.

Source

• Larousse : définition bastion
• Wikipédia : Guacamole

1. SI : Système d’Information ↩︎
2. UTM : Unified Threat Management ↩︎
3. RDP : Remote Desktop Protocol ↩︎
4. VNC : Virtual Network Computing ↩︎
5. SSH : Secure SHell ↩︎
6. DG : Directeur Général ↩︎
7. DSI : Directeur des Systèmes d’Informations ↩︎
8. ETP : Employé Temps Plein ↩︎
9. SGBD : Système de Gestion de Base de Données ↩︎
10. MSSQL : Microsoft Server SQL ↩︎
11. OS : Operating System ↩︎
12. ANSSI : Agence National de la Sécurité des Systèmes d’Informations ↩︎
13. BDD : Base De Données ↩︎
14. IT : Information Technologie ↩︎

C’est ainsi qu’un certain nombres d’équipes informatiques utilisent :

• VPN SSL²
• RDS³ via TSGW⁴
• Solution de prise en main à distance (TeamViewer, LogMeIn, NinjaRMM et j’en passe)

Je vois cela d’un autre regard et sous un autre angle. Je veux parler du regard du contrôle, de l’audit et de la non-répudiation ! Du respect du RGPD⁵ et des données stockées. Oui, je fais partie de ces SysAdmins là, ceux qui croient en l’ISO27001 et HDS⁶, ceux qui croient au BASTION <3

Je ne vais pas cracher sur TeamViewer car je l’ai longtemps utilisé à des fins personnelles pour me connecter à mon lab, mais bon niveau sécurité c’est loin d’être fou et encore une fois, où sont mes données ? Et il est toujours borderline dans son utilisation commerciale ou non…

Dans le monde professionnel, j’ai eu le loisir d’utiliser et d’implémenter une solution française de BASTION. Cette solution est super (je n’ai pas d’action chez eux mais c’est avec grand plaisir que je réaliserais de nouveau l’implémentation de cette solution) et les équipes support et commercial sont très compétentes.

Quoi ? Le nom de la solution ? Cleanroom/Cyberelement par SYSTANCIA

Mais voilà. Bien qu’une super solution, moi pauvre petit AdminSys je ne peux pas me payer la solution voyez vous et bonjour l’usage pour du lab. C’est alors que j’ai dû me tourner vers le monde de l’open source…

J’ai fait fumer mes méninges et avec la grosse Adrienne de mon talant (où Montalant ? 🙂 ) je me suis lancé dans l’implémentation d’un bastion GUACAMOLE ! OLE !

En réalité, ce n’est pas ma première tentative d’implémentation du bastion Guacamole, mais je n’ai jamais aimé l’approche Docker et je n’ai jamais eu le temps de vraiment étudier la solution. Pis là bah, je me suis dit c’est le moment de réaliser ce que je n’ai jamais réussi à concrétiser 🙂

Avant-Propos

Cet article va être plutôt conséquent. Donc il est préférable de se prendre un petit pack de cerveza (pourquoi petit ?) pour ne pas se déshydrater pendant ce billet.

Pour rendre ce dernier plus digeste, j’ai pris le parti de scinder quelques fonctionnalités dans des billets dédiés et de couper l’article en plusieurs sous-articles. L’implémentation d’un bastion nécessite un certain nombre de composants tiers et surtout une grande réflexion quant à l’architecture et aux fonctionnalités.

Bref, j’ai fait le choix encore une fois de partir sur un environnement LINUX, RHEL⁷ comme OS⁸ et d’appliquer comme d’accoutumée le durcissement de l’ANSSI⁹ pour les systèmes GNU/LINUX. Le bastion doit être le seul point d’entrée de notre SI pour accéder à nos ressources. C’est pourquoi je veux qu’il soit le plus sécurisé possible. Je vais donc aller relativement loin dans la sécurisation et il n’est donc pas impossible de se perdre en route. C’est toutefois comme ça qu’on apprend ! Il faut pour se trouver savoir se perdre sur des chemins de traverse 🙂

J’ai beaucoup appris et ainsi, je souhaite vous partager mon expérience.

Señor, Señora, Ándale Ándale Arriba !

Prérequis

• SE :
  • GNU/Linux RHEL
• Apps :
  • Guacamole 1.6
  • Tomcat 9.X
  • MariaDB 15.X
  • Nginx
• Autres :
  • Certificats

Guide

• Partie 1 : Théorie
  • Définir ce qu’est un bastion
  • Réflexion sur l’architecture
• Partie 2 : Installation
  • Guide de déploiement
• Partie 3: Sécurisation
  • Réseau
  • Système
  • Application
• Partie 4 : Configuration
  • Paramètres
  • Utilisateurs
  • Groupes
  • Ressources
• Partie 5 : Démonstration
  • Présentation de la solution

Conclusion

Il n’est pas évident aujourd’hui de garder la main sur nos environnements de manière sécurisée, comme il n’est pas aisé de contrôler l’ensemble des activités d’un fournisseur ou prestataire sur notre SI. Même si la connexion est éphémère, nous nous devons de contrôler cette dernière. J’ai repris la lecture des poèmes d’Omar KHAYYÂM, et je suis tombé sur celui-ci que je trouve à la fois beau et adapté à la thématique de mon billet. (Je ne parle pas de politique et je lis depuis très longtemps cet ouvrage).

Considère ce vieux caravansérail qu’on nomme le monde,
dont les portes sont le Jour et la Nuit ;
des souverains y passent avec leur faste,
y demeurent une heure ou deux… puis s’en vont

Omar KHAYYÂM – Robâiyât

Nous pouvons alors facilement considérer que le caravansérail est notre bastion, les voyageurs nos sessions, les gardiens de la porte les administrateurs systèmes et réseaux…

Les solutions de BASTION bien qu’onéreuses viennent pallier à tous cela. Toutefois et c’est souvent l’argument le coût de la solution est difficilement supportable ce qui justifie l’usage à tort et pour tout des VPN SSL, TS GW ou des outils de prise en main à distance. A l’inverse GUACAMOLE répond à l’ensemble des problématiques financières et technologiques. J’ai un bastion gratuit et souverain sur mon SI que demander de mieux ? Ce n’est malheureusement pas gratuit. Regardons de plus près le coût ETP¹⁰ lié à la solution. Il faut installer, maintenir la solution au-delà de son contexte infrastructure mais également applicative. Et comme vous pouvez le constater, c’est loin d’une mince affaire pour qui souhaite bien faire les choses.

Le choix de ne pas passer par la technologie docker m’est propre. Je ne vois pas l’utilité d’une telle solution pour un projet de ce type. Docker reste pour moi un usage de développement et non de production. Je ne dis pas que c’est mauvais, je dis que cela ne m’est pas adapté. Un jour peut-être je changerai d’avis, pour l’instant la tête de cochon que je suis continuera de réaliser ces infrastructures en environnement non containerisé ! (GUILLEMARD ça rime avec tête de lard pour ne pas dire co**ard 🙂 )

Je suis content d’arriver au bout de cet article et de cet outil magnifique qu’est GUACAMOLE. J’aurai appris énormément de choses encore et cela faisait longtemps que je n’avais pas passé des nuits blanches à cogiter sur des débugs et analyses. Je pense toutefois que la solution doit être sauvegardé au cas où et ce peu importe la solution utilisée. Si le bastion reste indisponible pour de bonnes et mauvaise raisons, il nous faut alors passer par la poterne de notre SI pour voir ce qu’il se passe. Son usage doit être restreint au maximum et doit se faire qu’en cas d’extrême nécessité.

La morale de ce billet se résumera à si j’avais un budget je passerai sans hésiter par SYSTANCIA (non je n’ai pas d’action), solution française, support humain et sympathique et une analyse forte en cas d’incident et de correctif applicatif de l’ensemble de leurs solutions (Cleanroom devenu CyberElements). Malheureusement, je n’ai pas le sou et donc je me rabat sur Apache GUACAMOLE et cela n’est pas sans regrets 🙂

Le mot de la fin :

J’initie une connexion guacamole sur fond de paddle. Votre avocat fait appel et vous informe que la balle est au centre. UN-DEUX-TROIS, on ne se bat pas ici ! Superbe relance de l’ami Kaouette, une teq paf pour la 12.

Erwan GUILLEMARD

Sources

• GUACAMOLE : Download page
• GUACAMOLE : Native Installation Guide
• SYSTANCIA

1. SI : Système d’Information ↩︎
2. VPN SSL : Virtual Private Network Secure Socket Layer ↩︎
3. RDS : Remote Desktop Server ↩︎
4. TSGW : Terminal Server GateWay ↩︎
5. RGPD : Règlement Général de Protection des Données ↩︎
6. HDS : Hébergement de Données de Santé ↩︎
7. RHEL : RedHat Entreprise Linux ↩︎
8. OS : Operating System ↩︎
9. ANSSI : Agence National de Sécurité des Systèmes d’Information ↩︎
10. ETP : Employé(e) Temps Plein ↩︎

Mais alors pourquoi faire un article sur Tomcat ?

Parce que premièrement cela aurait rendu l’article indigeste déjà qu’en temps normal ce n’est pas ouf et que deuxièmement en creusant un peu le sujet cela ne se résume pas à juste un dnf install tomcat…

Bref, ce billet sera technique car j’ai hâte de revenir à mon article initial. Mais cela vaut le coup car j’ai appris encore énormément de chose 🙂

Tommy the Cat is my name and I say unto thee

Avant-Propos

L’étude de Tomcat vient simplement de l’implémentation d’un billet qui sera publié prochainement qui nécessite la présence d’un serveur d’applet Java. Je garde volontairement une part de mystère, sinon ce n’est pas marrant non ? 🙂

De mon passé, d’étudiant, j’ai appris la POO¹ lors de mes études en BTS² d’info industrielle sur C++. J’avoue que je n’ai pas bien saisie la pratique… C’est lors de ma licence en sécu logicielle que j’ai unlock et appliqué tous les pratiques de la POO sur le langage JAVA.

Cool ta life mon gars, ça aurait mérité un post Facebook en 2012 avec en premier commentaire « Ba moi hier j’ai mangé une pomme »

Ouai peut-être mais cela a été pour moi une révélation. J’ai trouvé ce langage magnifique et je pensais avoir trouvé ma voie. Et pourtant JAVA est loin d’être un langage des plus fiable et ergonomique. Des IDEs³ NetBeans, Eclipse, Android Studio sans oublier le serveur d’applet web GlassFish je trouvais ça top. Et puis je me suis rendu compte que les applets c’étaient lourds, les applications Java difficilement ergonomique, des failles de sécurités qui doivent être patché avec des updates de la JDK⁴ côté développeur de la JVM⁵, JRE⁶ côté client, le code qui ne devient plus compatible…

Voilà, les raisons de pourquoi j’ai délaissé mon amour de JAVA par dépit à la suite de ces frustrations. L’une des autres raisons et la difficulté de jongler entre la sécurité des versions clients et les progicielles. Accepter de mettre à jour et ne plus travailler car au lancement de l’application ou de fonctionnalité ça crash ou retourne des erreurs de stack traces dans tous les sens ou accepter d’avoir des failles de sécurité partout et pouvoir travailler ?

Bref, encore une fois, un article pour installer un service au premier abord simple mais qui nécessite d’être bien sécurisé.

Prérequis

• SE :
  • Rocky Linux 9.4 et versions ultérieures
• Apps : 
  • Tomcat 10.1.54
• Autres :
  • Hardenned Linux

Théorie

Un peu d’histoire

Il était une fois, un meunier ne laissa pour tous biens, à trois enfants qu’il avait, que son moulin, son âne et son chat...

Bien joué Charles 😉 Je ne vais pas vous compter le conte du Chat Botté de Perrault mais bien celle de Tomcat, je vous rassure, mais la tentation était trop grande <3

L’objectif principal était de fournir une implémentation de référence pour JAVA Web (servlets et JSP7). C’est ainsi que James Duncan DAVIDSON créa Tomcat en 1998 sans lui donner encore de nom. Le projet sera donné à la fondation Apache en 1999 qui le baptisera Tomcat et passera ce dernier sous licence OpenSource Apache. Au cours des années 1999 à 2001, la première version stable de Tomcat est disponible pour principalement être utilisé comme moteur de servlet et est fortement lié au server web Apache. Au fil des années, le projet Tomcat continuera d’évoluer avec l’âge d’or d’internet. A ce jour, la version la plus récente est la version 11 qui comme nous pouvons en douter à une optimisation pour le cloud et les micro services. (Il faut bien vivre avec son temps 🙂 ).

Ce qu’il est important de retenir, c’est que ce dernier reste un projet OpenSource maintenu par une communauté très active. Tomcat reste également un serveur d’application léger très populaire et de base (et c’est pourquoi il est fortement lié à JAVA) la référence de l’implémentation JAVA.

Structure

Il est important comme pour toutes applications de savoir comment cette dernière est structurée et comment elle fonctionne.

Ainsi, nous pouvons différencier 9 répertoires distincts au sein du daemon Tomcat :

• bin : L’ensemble des scripts et exécutables propre au daemon pour démarrer ou arrêter le serveur.
• common : Nous pourrions dire que ce répertoire contient le code (classes et méthodes) commun utilisé par le service Catalina et certaines applications web.
• conf : Le répertoire qui stocke les fichiers de configuration du server.
• lib : Répertoire qui stocke l’ensembles des bibliothèques (les .jar)
• logs : Dossier qui va stocker l’ensemble des journaux d’événement. Attention à ce que ce dernier ne prenne pas trop de place sinon BOUM plus de service. Le mieux serait de le déplacer sur un disque dédié.
• server : Code contenant les méthodes et classes systèmes utilisés uniquement de Catalina.
• shared : Les classes partagées utilisées par toutes les applications
• webapps : Répertoire qui va contenir les applications web (le fichier .war)
• work : Répertoire qui va contenir les répertoires et fichiers temporaires (le cache)

Chacun des répertoires joue un rôle clé et donc selon le contexte doit être sécurisé.

Fonctionnement

Le fonctionnement de Tomcat peut paraitre complexe au premier abord. Toutefois avec un bon schéma, cela devient aussi divin que les croquettes Ultima Saumon pour chat stérilisé (« Sale Histoire » que mon avocat garde sous silence en reprenant la citation d’un membre de la famille).

/!\ Attention : Cette architecture reste valable, mais Tomcat 10 a migré vers Jakarta EE en rendant incompatible les applications basées sur javax.servlet. Donc si usage des Servlets c’est Tomcat 9…

Pour faire simple, si lors du lancement de votre application ne se lance pas et que dans les logs localhost ou catalina vient fleurir l’erreur ClassNotFoundException: javax.servlet, et bien c’est que vous l’avez dans l’OS bien profond et que vous êtes marron… Votre application n’est pas compatible Tomcat 10. Vous êtes bon pour un downgrade <3 Ca fait du bien de temps en temps de se prendre un bon coup de nerf de bœuf sur l’arrière train, ça fait circuler le sang !

Cette structure modulaire d’encapsulation, permet de garantir une certaine souplesse sans avoir à changer la logique des applications.

Je pense qu’il n’y a pas besoin d’en savoir plus pour installer le service sur notre serveur. Passe à la pratique.

Pratique

J’ai pris le parti de sortir pour une nouvelle fois des sentiers battu et de ne pas me limiter à l’installation de Tomcat depuis le repo source. J’ai choisi de déployer ce dernier depuis le site officiel.

Ce choix est motivé par les versions spécifiques nécessaire à certaines applications. De ce fait, l’installation depuis le repo n’est pas d’une grande utilité. Et une nouvelle fois de par mon expérience, il est plus probable de passer par le site officiel.

Dépendances

En termes de dépendance, ce n’est pas bien compliqué, il nous faut la JDK pour faire tourner notre serveur Tomcat. Donc ?

On installe la JDK 🙂

#Install Java
$ sudo dnf install java-21-openjdk-headless

Je passe encore et toujours mon tour sur cette étape qui devient un incontournable des billets que je rédige sous GNU/Linux.

Installation

Bien. Maintenant que notre dépendance est installée, commençons par le début.

Créons notre groupe tomcat et notre utilisateur de service tomcat. Pour répondre au bonne pratique, un service = un compte applicatif. Cela permet de faciliter le debug et surtout en termes de sécurité c’est bien mieux que de tout faire tourner avec le compte root.

$ sudo groupadd tomcat
$ sudo useradd -s /bin/false -g tomcat -d /opt/tomcat tomcat

Naturellement, l’utilisateur tomcat est membre du groupe tomcat…

L’installation se fait de deux manières. Soit par la commande curl qui est nativement présente sur notre SE⁹. Soit par wget qui devra être installé. Il conviendra d’adapter l’URL¹⁰ selon la version recherchée. J’ai décidé de télécharger le .tar.gz directement dans le répertoire /tmp.

Créons-le répertoire /opt/tomcat puis décompressons notre archive stocké sous /tmp dans le répertoire fraichement créé.

$ curl -L --output-dir /tmp -O  https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.54/bin/apache-tomcat-10.1.54.tar.gz
$ mkdir /opt/tomcat
$ tar -xf /tmp/apache-tomcat-10.1.54.tar.gz -C /opt/tomcat --strip-components=1

Bon, si on regarde du côté de l’ANSSI¹¹, ces derniers nous recommandent que notre compte de service tomcat ne doit pas propriétaire des binaires (exécutables). Pourquoi ? Admettons qu’il y est compromission, le compte ne sera pas en possibilité de s’altérer lui-même. Ainsi, nous pouvons voir une sorte de silotage.

$ sudo chgrp -R tomcat /opt/tomcat
$ sudo chmod -R g+r /opt/tomcat/conf
$ sudo chmod g+x /opt/tomcat/conf
$ sudo chown -R tomcat /opt/tomcat/{webapps,work,temp,logs}

Le groupe utilisateur tomcat a donc les droits de lecture et d’exécution sur l’ensemble des sous éléments du répertoire /opt/tomcat. L’utilisateur tomcat sera propriétaire uniquement des sous répertoires et leurs contenus :

• webapps : Répertoire qui va contenir les applications web (le fichier .war)
• work : Répertoire qui va contenir les répertoires et fichiers temporaires (le cache) persistant. C’est à dire utiliser par les servlets.
• temp : Le répertoire va stocker les fichiers à déplacer. Il joue le rôle de passe plat. Les fichiers qui viendraient à persister sont automatiquement supprimés à chaque redémarrage du service.
• logs : Les journaux d’événements, il faut bien que le service puisse écrire ce qui se passe non ?

Sécurité

Niveau sécurité, les actions vont se concentrer et se définir dans le fichier server.xml ainsi que dans le fichier web.xml.

L’objectif sera de se prémunir des attaques classiques MIM¹², Clickjacking, XSS¹³ et de masquer l’identité de notre serveur le plus possible. Parce qu’on ne dévoile pas tout le premier soir 😉

Audit et divulgation d’identité

Commençons par éditer le fichier server.xml.

$ sudo vim /opt/tomcat/conf/server.xml

Un truc qui pourrait être tout bête, appliquons le principe :

Vivons heureux, Vivons cachés !

C’est à dire outre mon langage (car peu parle le Erwan première langue), masquons la version de notre serveur tomcat dans les trames d’entêtes (le header…) HTTP. Ainsi il est possible de savoir que je suis un serveur tomcat, mais de connaitre ma version. 🙂

Malinx le Lynx. D’un autre côté c’est Tomcat… Voilà voilà, il est content de sa vanne…

Dans le connecteur HTTP, ajouter server= » « 

Avant	Après

Tiens, tu ajoutes un secure= »true ». C’est cool, du coup tu forces les connexions chiffrées ? 🙂 Et bien pas du tout ! Je me suis fait k*n aussi. Je suis allé regarder la documentation pour mieux comprendre. Par défaut, secure est à false. Nos applications par le biais de notre server peuvent refuser de délivrer les cookies sensibles ou vouloir rediriger les utilisateurs vers le protocole HTTPS¹⁴. Dans le meilleur des cas ça créé des lenteurs au pire c’est l’infinity loop… Alors que si nous le forçons à true, Tomcat va confirmer auprès de l’application que la requête vient d’un canal sécurisé (ce qui n’est pas le cas. Où le vilain menteur !) même s’il vient d’un canal non sécurisé.

De toute façon, nous allons passer par un reverse proxy nginx et en frontal nous aurons une publication avec une règle de proxy.

Toutefois cela ne suffit pas. Quand est-il des pages d’erreurs ? En creusant un peu il va falloir fermer les valves… 🙂

L’objectif est de supprimer la mention « Apache Tomcat/<version> » dans les pages d’erreurs ainsi que la description des erreurs (la stacktrace. Que de nostalgie…). L’objectif est de donner le moins d’information possible à un potentiel attaquant qui souhaiterai exploiter une CVE¹⁵ en relation avec la version de notre produit. L’objectif est de rendre aveugle l’attaquant le temps que les mécanismes en place ce déclenche ou nous alertes.

Niveau Audit, nous pouvons également renforcer la verbosité si nous suivons les recommandations de l’ANSSI.

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
               prefix="localhost_access_log" suffix=".txt"
               pattern="%h %l %u %t &quot;%r&quot; %s %b %D &quot;%{User-Agent}i&quot;" />

• %h : l’adresse IP distante
• %l : Identifiant logique
• %u : Utilisateur authentifié
• %t : horodatage
• %r : Ligne de requête (la méthode et l’URL appelé)
• %s : Code de retour du protocole HTTP
• %b : Taille de la réponse en octet
• %D : Le temps de traitement en ms
• %i : Le User-Agent pour repérer les outils automatisés (nmap et autres) et surtout les navigateurs « chelou » comme diraient mes enfants…

Par exemple :

/!\ Attention : L’activation de l’audit n’est pas anodine en termes d’espace. Il faut penser à mettre en place une rotation des logs. Sinon… BOUM !!!

Toutes les applications par défaut, ça dégage ! Pourquoi garder les éléments de bases qui sont d’autant plus des vecteurs d’attaque et des points de vulnérabilité ?

$ sudo rm -Rf /opt/tomcat/webapps/*

Un truc que je ne connaissais pas et que j’ai trouvé en étudiant Tomcat, c’est le cas de « Protection du Shutdown ». Au premier abord, je me suis demandé qu’est-ce que c’est que ce truc. Le paramètre shutdown est explicite. Et bien voyez-vous c’est marrant, c’est une commande qui permet d’éteindre le daemon. Alors certes, par défaut il est sur le port 8005/tcp et normalement accessible qu’en local. Mais tapons shutdown et pouf ! Notre daemon il va à la niche.

Donc, on change le port et pour le mot de passe on utilise le bon vieux Soleil123! . Vous m’avez compris non ? 🙂

<Server port="-1" shutdown="y2Fxg@kLx4:If2L0_MD1Ccz">

Prévention des attaques

Ouvrons le fichier web.xml.

$ sudo vim /opt/tomcat/conf/web.xml

A la fin de la section <filter>, ajoutons les lignes suivantes :

<!-- Begin R-ONE Modification -->
        <filter>
                <filter-name>httpHeaderSecurity</filter-name>
                <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class>
                <async-supported>true</async-supported>

                <init-param>
                        <param-name>hstsMaxAgeSeconds</param-name>
                        <param-value>31536000</param-value>
                </init-param>

                <init-param>
                        <param-name>antiClickJackingOption</param-name>
                        <param-value>DENY</param-value>
                </init-param>

                <init-param>
                        <param-name>blockContentTypeSniffingEnabled</param-name>
                        <param-value>true</param-value>
                </init-param>
        </filter>
<!-- End Modification -->

Parcourons en détails chaque ligne pour comprendre ce que nous sécurisons avec les filtres. (Normal c’est du café de Java… Franchement, il ne mérite pas d’aller jouer sur l’autoroute à contre sens pour bien voir le danger ? L’auteur de ce billet est bof, il fait triste à voir.)

L’usage du filtre de sécurité « HttpHeaderSecurityFilter » permet d’ajouter des réponses dans le header des requetes HTTP pour protéger les utilisateurs et les applications des attaques mentionnées ci haut. Ainsi pour une défense en profondeur l’activation de ces options sont primordiales. hstsMaxAgeSeconds indique que le site ne peut être consulté uniquement via le protocole HTTPS et force ainsi le navigateur à chiffrer les requêtes. Cela permet donc de prévenir des attaques d’interception SSL (SSL stripping). antiClickJackingOption aussi connu sous le nom de X-Frame-Options. Cela permet au site de ne pas intégrer l’application dans une balise html iframe et donc de faire une superposition d’interface invisible et valider une action non voulue. blockContentTypeSniffingEnabled ou X-Content-Type-Options: nosniff permet de blague censurée de forcer le navigateur à respecter le type MIME envoyé par le serveur. L’objectif et de se prémunir des attaques XSS.

Il nous reste un dernier point, les cookies. Afin que ces derniers ne soient pas volés par Cookie Monster par exemple, il est primordial d’interdire l’accès au cookie via JavaScript (d’où la présence du http-only à true. Nous bloquons ainsi le vol de session via XSS. L’usage de secure va faire en sorte que le cookie n’est envoyé si et seulement si la connexion est sécurisée.

<!-- Modification R-ONE -->
        <filter-mapping>
                <filter-name>httpHeaderSecurity</filter-name>
                <url-pattern>/*</url-pattern>
        </filter-mapping>
<!-- End Modification -->

Un truc c*n qui m’a fait perdre une nuit de sommeil. J’avais cette put**n d’erreur… A devenir fou !

Après pas mal de recherche, c’est un truc simple. Franchement je suis vraiment un c*n… Mon nouveau fichier de conf, avait pour owner root:root et non tomcat:tomcat. La haine, vraiment. Pensez donc à bien set de nouveau les bons droits…

$ sudo chown tomcat:tomcat -R /opt/tomcat/conf/

Un petit test avant, après ?

Avant	Après

Daemon Firewall

Côté firewall il faut publier le port 8080/tcp

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

Toutefois ça ne fonctionnera pas NANANANERE ! Et pourquoi ? Hein, pourquoi ? A cause du SELinux ventrebleu !

Par défaut le port 8080 n’est pas autorisé dans le SELinux pour la communication HTTP. Il est donc nécessaire de lui dire qu’il en fait partie.

$ sudo semanage port -a -t http_port_t -p tcp 8080

Configuration

Logrotate

Créons et éditons le fichier de rotation propre à tomcat sous /etc/logrotate.d.

$ sudo vim /etc/logrotate.d/tomcat

Nous allons spécifier dans notre fichier que nous souhaitons effectuer la rotation du fichier catalina.out, les fichiers localhost_access_log*.txt ainsi que l’ensemble des fichiers d’extensions .log.

C’est dernier afin de ne pas impacter la production seront vidé à chaud (copytruncate) de manière journalière en gardant 30 jours de rétention (histoire de faciliter les investigations en cas de suspicion). Nous compresserons les points de rétentions si pas de fichier nous ne faisons rien ni si les fichiers sont vides. Nous recréerons les fichiers avec les droits 0640 avec en groupe et propriétaire le compte de service tomcat.

/opt/tomcat/logs/catalina.out
/opt/tomcat/logs/localhost_access_log*.txt
/opt/tomcat/logs/*.log {
    copytruncate
    daily
    rotate 30
    compress
    missingok
    notifempty
    create 0640 tomcat tomcat
}

Une commande que je ne connaissais pas. C’est en me replongeant dans la documentation de logrotate que j’ai découvert qu’il existait un mode debug qui vient simuler notre fichier de rotation. C’est vraiment cool.

$ sudo logrotate -d /etc/logrotate.d/tomcat

Bon ba fonctionne pas. Que pasa ? Ca ne serait pas encore un coup du SELinux ? Mais si, Mais si j’ai cru voir un SELinux !

$ ls -Zd /opt/tomcat/logs
$ sudo semanage fcontext -a -t var_log_t "/opt/tomcat/logs(/.*)?"
$ sudo restorecon -Rv /opt/tomcat/logs

Après vérification du contexte de sécurité, il s’avère que logrotate est bloqué par le SELinux lorsqu’il essai d’écrire dans le répertoire /opt/tomcat/logs. Il convient donc alors d’ajouter le contexte et de restaurer le contexte de sécurité sur le répertoire /opt/tomcat/logs. 🙂

Tu vois Monsieur CHAPPINION, je ne laisse pas la sécurité au hasard et des backdoors partout comme tu aimes le crier haut et fort en te pavanant. Continu de cracher ton VENIN avec ta clic… #bisous #gratuit #faitdubien 🙂

Services

Comme j’ai choisi l’installation depuis le package et non depuis le repo, il faut se farcir à la main le fichier de service. Cela dit, c’est plutôt intéressant de se pencher sur le cas. Encore une fois et c’est mon point de vue, c’est agréable de savoir cuisiner que d’acheter des produits transformés tous les jours.

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

[Unit]
Description=Apache Tomcat Web Application Container
After=network.target

[Service]
Type=forking

User=tomcat
Group=tomcat

Environment="JAVA_HOME=/usr/lib/jvm/jre"
Environment="CATALINA_PID=/opt/tomcat/temp/tomcat.pid"
Environment="CATALINA_HOME=/opt/tomcat"
Environment="CATALINA_BASE=/opt/tomcat"

ExecStart=/opt/tomcat/bin/startup.sh
ExecStop=/opt/tomcat/bin/shutdown.sh

# Sécurité Systemd (Sandboxing)
ProtectSystem=full
ProtectHome=true
PrivateTmp=true
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Normalement maintenant c’est le moment de vérité… Démarrons notre service. Si tout va bien, pas d’erreur. Sinon c’est parti pour du début et avec Java ça peut vite devenir pénible et encore le paroxysme est loin. Mais je ne veux pas vous décourager…

$ sudo systemctl start tomcat
$ sudo systemctl status tomcat

Si c’est ok, le service peut être actif au démarrage du système. Ce dernier se lancera après le service réseau (cf la conf du service).

$ systemctl enable tomcat

Test

Pour vérifier que tout est fonctionnel, il est nécessaire comme nous avons supprimé l’intégralité du contenu de notre répertoire /webapps/ de générer un fichier de test :

$ sudo mkdir /opt/tomcat/webapps/ROOT
$ sudo echo "OK FINAL ROOT" > /opt/tomcat/webapps/ROOT/index.html
$ chown tomcat:tomcat -R /opt/tomcat/webapps/ROOT
$ sudo systemctl restart tomcat

Maintenant depuis un navigateur web, sous réserve d’avoir créé la règle sur votre UTM¹⁶ si vous n’êtes pas dans le même subnet rendez-vous sur l’URL http://<SERVER>:8080 ou depuis directement depuis votre server curl http://127.0.0.1:8080 vous devriez avoir en retour :

Remote	Local

Je pense que nous avons clôt ce billet. Nous voilà avec un server Tomcat sécurisé et fonctionnel… 🙂

Conclusion

Je me suis arraché les cheveux sur ce billet.

Ecoute ma bonne Catalina, tu un engine modèle, mais si tu n’as que des qualités et en termes de verbosité tu es resté comme je l’espérai, c’est le bonheur rangé dans une armoire. Tu vois si c’était à refaire, je t’installerai de nouveau mais tu m’emmerdes !

Erwan Guillemard, revisite d’Un singe en hiver d’Henri VERNEUIL

Mais alors pourquoi je tiens ces propos ? Je me suis une nouvelle fois aventuré dans la stacktrace et dans les logs à la suite d’un 404 Not Found. D’erreur dans le fichier de configuration car sensible à la case sur UN caractère. L’absence de log par moment… Tout ce que j’aime avec JAVA, ou du moins j’aimais… Imaginons maintenant une montée de version ? J’espère que votre formulaire de CAB¹⁷ est à jour et que vous avez un environnement de production iso à votre production.

JAVA et Tomcat c’est un peu comme regardez notre bonne vieille boite de Schrödinger. Le service est démarré, mais cela ne fonctionne. Le chat, c’est notre Tomcat numérique (C’est surtout la faute du mec entre le clavier et la chaise qui est dans un état quantique oui !).

Enfin passons, si j’ai fait un billet sur Tomcat, c’est que je vais surtout en avoir besoin dans l’article prochain et qu’il était vraiment important d’étudier en profondeur ce produit de la gamme Apache. Il faut reconnaitre tout de même qu’en terme de serveur web il y a bien pire 🙂

Rien que les notions de sécurité, nous revenons une nouvelle fois autour des mêmes notions conceptuelles, moindre privilège, réduction de la surface d’attaque, audit, chiffrement et isolation. Ces points sont primordiaux pour Tomcat.

Pourquoi me direz-vous ? Parce que nous publions un service Web qui exécute du code JAVA qui si mal isolé, croyez-moi peut faire énormément de dégât dans un système d’information. Il serait bien de porter si vous utiliser ce dernier renforcer la vigilance sur ce dernier avec votre SIEM¹⁸ (c’est marrant, je n’en ai pas 🙂 )…

Le mot de la fin :

Le chat botté chevauche Tomcat pendant que Charles Perrault configure du HSTS dans une cafetière. Arabica mon chers Watson, je danse la JAVA de Broadway. A non, il y a Catalina en travers sur une requête HTTP, le firewall vous fait chapeau bas !

Erwan GUILLEMARD

Sources

• ANSSI : Standards de sécurité côté navigateur
• Logrotate : Man
• Curl : Man
• Wikipédia : Apache Tomcat
• Tomcat : Documentation

1. POO : Programmation Orientée Objet ↩︎
2. BTS : Brevet de Technicien Supérieur ↩︎
3. IDE : Integrated Environment Development ↩︎
4. JDK : JAVA Development Tools ↩︎
5. JVM : JAVA Virtual Machine ↩︎
6. JRE : JAVA Runtime Environment ↩︎
7. JSP : JAVA Server Pages ↩︎
8. HTTP : HyperText Transfert Protocol ↩︎
9. SE : Système d’Exploitation ↩︎
10. URL : Uniform Resource Locator ↩︎
11. ANSSI : Agence National de Sécurité des Systèmes d’Information ↩︎
12. MIM : Man In the Middle ↩︎
13. XSS : Cross Site Scripting ↩︎
14. HTTPS : Secure HyperText Transfert Protocol  ↩︎
15. CVE : Common Vulnerabilities and Exposures ↩︎
16. UTM : Unified Threat Management ↩︎
17. CAB : Change Advisory Board ↩︎
18. SIEM : Security Information and Event Management ↩︎

Comme pour les autres gros projets d’envergure, il s’agit là d’un ReadMe dans un format personnel qui jure avec les .txt ou traditionnel wiki.

Prérequis

Avant de rentrer dans le vif du sujet, le déploiement étant multiplateforme, je traiterai les deux sujets de par l’application GUI¹ ou CLI² sur les environnements Windows et GNU/Linux. Il est toutefois primordial d’avoir au minimum la version Powershell.

A ce jour, dans les versions 1.0.1 et 1.0.2, il reste des optimisations de code (refactorisation) à effectuer. Ces versions sont considérées comme stable et non en version Béta :). Néanmoins, je n’ai pas automatisé le déploiement par le biais de package .exe ou .msi.

Pour terminer, il n’y a pas besoin des PRIVILEGES ADMINISTRATEURS pour utiliser l’application.

Configuration

Ayant développé une application client, il n’y a pas de notion FrontEnd ou Backend.

Avant de démarrer le script ou l’application, il est nécessaire de faire un détour par le fichier de configuration présent dans le répertoire config à la racine du projet. Comme pour les autres projets, je vais prendre le temps de décrire chacune des parties de ce fichier.

Le fichier se découpe en 1 partie de 2 sous-parties.

* Une sous-partie globale qui définit les paramètres du script et de son fonctionnement * Une sous-partie dédiée à l’application Ollama permettant d’établir la connexion à l’API3 * Une sous-partie concernant l’envoie de notification SMTP4

Le fichier de configuration sera amené à évoluer en fonction des suggestions et améliorations à apporter.

Le choix de segmenter les parties ? Faciliter le maintien et l’évolutivité du fichier foutrebleu !

Allez, disséquons le fichier 🙂

J’ai pris en compte la possibilité d’éditer directement le fichier de configuration que ce soit depuis l’interface graphique ou depuis l’interface console. Par sécurité et comme toujours j’ai repris ma fonction de régénération automatique du fichier de configuration en cas de suppression ou de corruption de ce dernier. Encore une fois, j’en ai eu marre de me repalucher le fichier de conf à la mano… Comme ça nous sommes pénards !

Il n’y a en aucun cas besoin d’installer ou d’ajouter des dépendances. L’application a été pensé pour être native (en dehors de Linux naturellement, mais je reviendrai sur ce point dans la sous partie à venir).

Je pense que nous avons maintenant une pleine compréhension du fichier de configuration, nous pouvons passer à l’installation de l’application.

Installation

L’installation sera dissociée en deux parties. Une partie Windows et une partie Linux.

Dans les deux cas, si le serveur OLLAMA n’est pas joignable ou disponible, l’application sera fermée ou l’utilisateur sera invité à réaliser cette opération. Point important que je me devais de souligner.

Réaliser un copier-coller de l’ensemble de l’architecture dans un répertoire. Au pif, ZelenZajac #mainsurlecoeur

Pour des raisons de contrainte lié à la bibliothèque WindowsForms, l’application GUI ainsi que son installation se fera sous Windows. Et par logique, l’application et son installation CLI se fera sous Linux, même si vous êtes libre d’utiliser et d’installer l’application CLI sous Windows (je ne suis pas psychorigide hein ?).

Windows

J’ai pour habitude sur les environnements Windows Server de dédier un répertoire scripts sur un disque dédié avec des privilèges strict.

Dans ce cas précis, nous sommes dans un usage utilisateur. Donc il faut s’attendre à ce que celui-ci soit utilisé par un utilisateur (C’est d’une logique déconcertante, je me surprends moi-même). Le script peut être stockées sur le bureau ou dans les documents. Autrement dit dans le profil de l’utilisateur. Un partage réseau pourrait être intéressant, mais dans le cas d’un usage multiple cela pourrait générer des dysfonctionnements (et surtout je n’ai pas testé et envisagé ce mode de fonctionnement).

Lancer le script SS_045_1.0.2_Ollama-GUI_Main.ps1 pour réaliser les opérations d’initialisation et vérification des dépendances.

Linux

Une question qui je dirai jusqu’à présent ne faisait plus trop débat. Linux ou Windows ? La guerre ! reprend de plus belle avec la hausse du cout des licences 365, le côté gourmand de Windows 11 et l’obsolescence matériel…

Toutefois, Windows offre depuis Windows 10 (je ne suis pas sûr pour W7 ou W8) la possibilité d’émuler un système UNIX dans son OS⁸. Il s’avère également qu’il est possible sous UNIX d’utiliser les commandes powershell CORE. Et ça je trouve ça cool de voir qu’officiellement les deux familles se rapprochent <3

Donc pour commencer il va falloir installer powershell sur notre environnement linux.

#Enregistrement de la clé CPG de Microsoft
$ sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc 

#Ajout du dépot MS RHEL 9
$ curl https://packages.microsoft.com/config/rhel/9/prod.repo | sudo tee /etc/yum.repos.d/microsoft.repo

Puis nous installons le package powershell.

$ sudo dnf update
$ sudo dnf install powershell 

Naturellement et ça va de soi, si votre version est RHEL⁹ 8 ou 10 vous ajouter la bonne version de votre répo… Vous adaptez l’url en conséquence. Non parce que je vois déjà certains lecteurs hurler au scandale.

« Ca fonctionne pas, c’est de la merde… [Autres noms d’oiseaux]« 

Pour démarrer powershell, il suffira de taper la commande pwsh.

Mais revenons à notre projet. De manière sécurisé, nous allons déposer notre répertoire projet dans notre /home/john.doe/ via un client sftp¹⁰ (pour ma part WinSCP).

Il va être nécessaire d’installer un petit paquet pour convertir nos scripts qui sont au format dos en au format unix (et oui, j’ai développé sur windows…).

$ sudo dnf install dos2unix
$ dos2unix -R /path/SS_045_APP_Ollama-API/*
$ dos2unix -R /path/SS_045_APP_Ollama-API/config/*
$ dos2unix -R /path/SS_045_APP_Ollama-API/modules/*

Maintenant, nous sommes parés pour lancer le script.

$ pwsh /home/r-one/SS_045_APP_Ollama-API/SS_045_1.0.2_Ollama-API_Main.ps1

Simple non ? C’est maintenant l’heure de vous présenter en détail les interfaces 🙂

Présentation

Dans les deux cas, je vais présenter l’ensemble des options.

Il sera plus facile de suivre la description du mode CLI de par son côté procédurale. La présentation du mode GUI lui sera présenté comme suit, d’abord l’interface générale puis les différentes fenêtres et boutons.

GUI sous Windows

Interface Principale

Au lancement de l’application, un test de communication au serveur OLLAMA est réalisé. L’interface graphique va être adapté selon le résultat retourné.

Server Unreachable	Server Reachable

Dans la colonne de gauche, nous sommes dans le cas où le serveur OLLAMA n’est pas disponible (peu importe la raison. Il n’est pas là, T’es là ou T’es pas là ?). L’application se lancera tout de même mais avec aucune possibilité d’action. Contactez votre administrateur <3

Dans la colonne de droite, l’application se lance sans problème. Ce qui signifie que la connexion au server Ollama a été effectué et que les LLMs¹¹ déployés ont pu être récupérés et ce de manière automatique et dynamique. Ces derniers sont chargés dans la liste déroulante. Il est nécessaire de choisir un modèle pour soumettre un prompt.

Il est important de comprendre et pour rappel de la partie théorique que nous avons 3 types d’appel API selon le prompt que nous allons soumettre à OLLAMA.

• Standard : C’est le mode par défaut. Une fois l’application démarrée et un modèle choisi, vous pouvez soumettre un prompt à OLLAMA.

• Image : Ce mode nécessite de fournir une image. Cette même image va être converti en base64 afin d’être soumis à OLLAMA. Il est recommandé d’utiliser le modèle llava pour traiter les flux numériques. Naturellement, si le chemin d’une image est renseigné, il n’est pas possible de choisir un fichier.

• File : Ce mode nécessite de fournir un fichier. Il est alors nécessaire de lire le contenu de cet élément et d’ajouter ce dernier à la suite du prompt. Le point de difficulté réside dans le traitement des fichiers .pdf qui doivent être converti en amont. Fonctionnalité que je n’ai pas traité pour l’instant. Comme pour le mode image, si le chemin d’un fichier est renseigné, il n’est pas possible de choisir une image.

Dans les deux cas afin de faciliter la saisie des chemins d’accès aux items (image ou document) j’ai mis en place l’ouverture de l’explorateur de fichier.

Pictures	Files

Il suffira alors de saisir notre prompt dans le champ prévu à cet effet.

Pour soumettre la requête à notre serveur OLLAMA nous allons devoir passer par les triggers, autrement dit par des événements sur des boutons 🙂

Ollama GO

L’action sur ce bouton a pour effet de soumettre la requête saisie par vos soins au serveur OLLAMA en prenant en compte l’ensemble des options et paramètres défini précédemment.

Toutefois, il y a un certain nombre de contrôle :

• Le TextBox spécifique au prompt ne doit pas être vide
• Les CheckBoxs spécifique aux choix avancés d’analyse d’image ou de fichier ont elles été cochées ?
  • Les chemins ont-ils une valeurs
• Le modèle d’IA a-t-il été défini

Bref, autant de contrôle pour s’assurer de ne pas fournir une requête vide au serveur OLLAMA et faire travailler ce dernier inutilement.

Personnellement vous aimez travailler pour des noix sur une décision absurde de votre N+1 ? Je crois que personne n’aime bien ça hein <3

Une fois l’action sur le bouton effectué, un petit message discret « Searching » apparait et vous fait savoir que le travail est en cours.

Avec GPU	Sans GPU
Vous n’avez pas trop a attendre	Va falloir être patient et ne pas être trop pressé

Bref, au final vous arriverez à ça… C’est cool non ? 🙂

Save

L’action sur ce bouton a pour effet de sauvegarder votre requête au format .txt.

Il y a aussi des conditions sur ce bouton. Il faut que les TextBoxs dédiés à OLLAMA (prompt et answer) ne soient pas vide ou null. Sinon nous sauvegarderions du vent…

N’étant pas sadique, cela va ouvrir une nouvelle fenêtre d’explorateur windows pour sauvegarder votre fichier. Ce dernier contiendra l’heure de l’exécution de votre requête, votre prompt ainsi que la réponse retourner par le modèle présent dans OLLAMA.

• 

• 

• 

Send Mail

L’action sur ce bouton a pour effet d’envoyer par mail le résultat de requête.

Comme pour le bouton de sauvegarde précédent, les conditions sur ce bouton sont les mêmes. Il faut que les TextBoxs dédiés à OLLAMA (prompt et answer) ne soient pas vide ou null. Sinon cette fois ci, nous enverrons du vent…

Un axe d’amélioration serait de prendre en compte des adresses mails multiples. Je garde ça sous la main 🙂

Settings

L’action sur ce bouton est soumise à une seule condition de contrôle. Le fichier de configuration doit exister sous le chemin par défaut.

Je me suis dit que ça serait bien de permettre à l’usager de pouvoir modifier le fichier de configuration directement depuis l’application. Attention, car cela ne modifie pas la configuration du code en cas de régénération du dit fichier.

Peux être qu’une fonctionnalité d’export du fichier de configuration pourrait être sympa 🙂

Debug

Le bouton debug sert au debug et pour cela je laisse la parole à la sous parti suivante 🙂

Interface Debug

Cette interface permet de lister les interfaces et les services de notre serveur OLLAMA. Naturellement, j’ai poussé le vice un peu plus loin. Si je test le port OLLAMA et le port du server SMTP, j’ai ajouté un petit bonus en plus. En lien avec l’article OpenWeBUI, je test les ports 8080 et 443 en dur.

Je verrai plus tard s’il y a un intérêt à ajouter ou non ces paramètres dans le fichier de configuration.

Bref, cela permet de vérifier les communications et les interfaces de nos différents serveurs.

Unavailable	Available

Interface About

Que serait-ce une application sans un petit About ? Histoire de laisser son nom à la postérité ? D’un côté c’est de l’orgueil, de l’autre, il me parait normal comme un artiste de signer son art non ?

D’ailleurs, est ce que développeur n’est-il pas un métier de création et donc d’art ? Voyez-vous, je suis une b*te en dessin, un musicien médiocre. Par contre, j’ai des idées de dev et je trouve que ce que je faisais et fais commence à avoir de la gueule non ? Une question qui selon moi ouvre au débat.

Bref, depuis la barre de menu, Help > About et vous retrouverez les informations de notre application. D’ailleurs cela me fait penser que je n’ai pas mis/caché d’Easter egg…

CLI sous Linux (et Windows)

Après réflexion, je vais afficher les captures sous les deux environnements à des fins de comparaison. Mais je mets l’accent sous l’environnement UNIX.

La présentation se fera menu par sous-menu. Je vous renvoie à la partie théorique quant au cycle de vie, algorithme et pseudo code.

Interface Principale

Hormis la banner gigantesque pour marquer les esprits, nous retrouvons un choix de navigation de 6 parties.

Pourtant moi j’en compte 5. Tu sais compter ?

Oui, je vous remercie de vous inquiéter de mon niveau mathématique. Je sais compter et le 6eme choix n’apparait que sur une condition spécifique. 🙂

Linux	Windows

Regardons ce que nous offres les possibilités de navigation :

• [1] Select LLM : Permet de sélectionner un modèle de moteur IA installé préalablement sur le serveur OLLAMA
• [2] Prompt Type : Permet de choisir le type de requête que nous souhaitons soumettre Image, Fichier ou simple prompt
• [3] Settings : Permet d’éditer le fichier de configuration directement depuis la console CLI
• [4] Tropubleshooting : Permet de lancer un mode debug
• [5] About Zelen Zajac : Permet d’afficher les informations de l’application
• [6] Launch Ollama Request : Permet de soumettre un prompt au serveur OLLAMA si et uniquement si un LLM a été préalablement sélectionné.
• [0] Quit : Pour sortir de l’application proprement et non à la hussard à grand coup de Ctrl+C…

Sélection du LLM

Comme pour l’application GUI, si la connexion au serveur OLLAMA est établi, l’ensemble des modèles présents sur le serveur sont automatiquement listés. Il suffit alors à l’utilisateur de choisir le modèle qui correspond à prompt qu’il souhaite soumettre.

Linux	Windows

Il est important qu’il ne soit pas possible de revenir en arrière. Le dernier choix et le choix qui fait foi. Une fois le moteur sélectionné, cela affichera l’option 6 pour soumettre une requête au serveur OLLAMA.

Sélection du type de prompt

Par défaut et pour éviter toutes erreurs, le type de prompt est défini sur Standard. Toutefois et comme pour l’interface GUI, il sera nécessaire dans la sélection des modes Image ou Document de préciser le chemin des dits éléments à soumettre au serveur.

Standard

Linux	Windows

Image

Linux	Windows

Document

Linux	Windows

Si dans le mode GUI j’assiste l’utilisateur avec un explorateur de fichiers pour trouver l’élément, il faudra connaitre ici le chemin de tête. Cela pourra je pense faire office d’une fonctionnalité futur.

En toutes circonstances, il y aura un contrôle des chemins par la suite afin de s’assurer de ne pas charger un élément existant.

Settings

Selon la nature de l’OS, la modification du fichier de configuration ne se fait pas de la même manière.

Linux	Windows

Depuis un terminal (donc pour Linux), il est nécessaire de forcer l’interactivité depuis un client SSH. Sans quoi nous sortons du script, ça plante et nous générons un fichier temporaire. Utilisateur de vim et donc de vi j’ai choisi cet éditeur de texte. Toutefois, je pourrais implémenter la possibilité de choisir entre nano et vi dans le fichier de configuration.

Côté Windows, nous sortons comme pour Linux de ce côté agnostique. Powershell Core, gère dans un processus à part et hors terminal l’application notepad.exe. Nous aurons donc une interface graphique qui s’offre à nous.

Il faudra alors jouer des combinaisons :

• Linux
  • vim : esc puis :x!
  • vi : esc puis :x!
  • nano : Ctrl+x
• Windows
  • notepad : Ctrl+s

/!\ Attention : Comme pour le mode GUI je ne modifie pas la configuration dans le code dans le cas de la régénération du fichier de configuration en cas d’altération de ce dernier.

Troubleshooting

Cette sous-interface permet de vérifier si l’interface ou les interfaces de notre serveur OLLAMA et autres serveurs sont bien accessible.

Linux	Windows

Il est important de comprendre qu’il peut y avoir de multiples pour qu’un protocole ou une ressource ne soient pas joignables. Cela peut résulter :

• Firewall interne au serveur
• Firewall externe si segmentation des LANs
• Mauvais paramétrage du SELinux
• Résolution DNS impossible
• etc.

Je vous recommande de contacter votre administrateur. Si l’administrateur c’est vous, je vous recommande de vous retrousser les manches ou de changer de métier. Elever des chèvres en Ardèche c’est pas mal aussi 🙂

Pour le fun, j’ai ajouté en dur dans le code, le contrôle des ports 8080/tcp et 443/tcp qui sont les ports de mon daemon OpenWebUI. A voir si cela doit être amélioré ou non.

About

Ce sous menu n’est présent que pour afficher mon nom et laisser ce dernier à la postérité. Et aussi et surtout pour afficher la date de dernière publication de la version.

Linux	Windows

C’est peut-être un détails pour vous, mais pour moi ça veux dire beaucoup !

Launch Ollama

Nous voilà enfin dans le vif du sujet. Bon, je ne vais pas trop m’étendre sur le sujet car cela sera présenté dans la Partie 3 Démonstration. Je présenterai que de manière succincte les étapes du mode standard comme j’ai pu le faire plus haut pour le mode graphique.

Naturellement il faut au préalable avoir sélectionner un modèle de moteur IA et selon le besoin le type de prompt que nous souhaitons soumettre.

1 – Rédaction du prompt

Lors de la soumission de la requête, j’ai décidé d’exécuter la tache en dehors du programme principale afin de ne pas bloquer ce dernier durant la soumission de notre requête au serveur OLLAMA.

Linux	Windows

J’ai également ajouté une barre de progression afin d’informer l’utilisateur que le travail est en cours. Pas bête hein ?

2 – Retour du serveur OLLAMA

Après un moment d’attente toujours pour les mêmes raisons d’absence de GPU, la réponse s’affiche dans le plus beau moment anthropique <3

Linux	Windows

3 – Sauvegarder la requête ?

Cela peut étonner, mais l’ensemble des fonctionnalités proposées dans l’application graphique sont présentes dans l’application CLI.

La seule nuance, il n’est pas possible pour l’instant de modifier l’emplacement de sauvegarde des requêtes en mode CLI. Ces dernières se retrouveront dans le répertoire export à la racine du répertoire.

Linux	Windows

Nous retrouvons naturellement le modèle LLM, la date, le prompt, la réponse.

4 – Envoi par mail ?

Voilà que je viens me contredire avec mes écrits précédents. Il y a pour l’instant une fonctionnalité qui m’échappe. L’envoi de mail.

Déjà et même si j’ai modernisé ma fonction d’envoi en prenant compte de l’obsolescence Microsoft, l’usage de la bibliothèque [System.Net.Mail.MailMessage] et [System.Net.Mail.SMTPClient] ne fonctionnent pas sur Linux.

Je pourrais développer et utiliser mon script bash pour passer par MUTT. Mais voilà je souhaite garder et aboutir à un script 100% agnostique Linux <-> Windows en powershell donc il est urgent de ne rien faire.

Tout ça pour dire qu’il n’est pas possible d’envoyer un mail sous Linux…

Linux	Windows

Toutefois, rien ne vous empêche de faire un bash avec un cron sur présence d’un fichier dans le répertoire pour faire un envoi automatique. Cela reste de la bidouille, mais dans certains cas cela peut être vu comme une méthode de contournement.

Donc, si je résume sous Linux cela nous donne avec toutes les étapes :

Pour se faire une idée, je vous renvoie à la partie 3 démonstration. Dans une vidéo, je vais traiter des deux modes de mon application.

GitHub

Miaou

(Uniquement sur contact LinkedIn)

Je souhaite vraiment échanger avec vous et vous fournir le lien privé du projet. Ainsi je pense que recueillir vos avis, retours peuvent me permettre de faire évoluer l’application dans le bon sens.

1. GUI : Graphical User Interface ↩︎
2. CLI : Command Line Interface ↩︎
3. API : Application Programming Interface ↩︎
4. SMTP : Simple Mail Transfert Protocol ↩︎
5. LD : Distribution List ↩︎
6. BAL : Boite Aux Lettres ↩︎
7. FQDN : Fully Qualified Domain Name ↩︎
8. OS : Operating System ↩︎
9. RHEL : RedHat Entreprise Linux ↩︎
10. SFTP : Secure File Transfert Protocol ↩︎
11. LLM : Large Language Models ↩︎

Comme nous avons pu le constater et l’étudier dans le précédent article, il existe des solutions qui s’interfacent très bien avec OLLAMA, par exemple la solution OpenWebUI qui propose une interface web depuis un navigateur.

Toutefois, si je souhaite ne pas utiliser de solution orienté serveur pour des raisons de ressources restreintes et ou de cout financier, la présence d’une API¹ sur OLLAMA change la donne.

Je souhaiterai donc mettre en place une solution agnostique simple d’utilisateur qui permettrait à un ou plusieurs utilisateurs de soumettre des requêtes à notre service interne OLLAMA le tout de façon sécurisé. Si possible cette même solution doit être compatible pour les environnements Windows et Linux.

Pourquoi d’ailleurs ?

Les couts d’usage et d’acquisition des produits Microsoft s’oriente de plus en plus vers un modèle rental et non plus permanent ce qui sur le moyen et long terme peut vite devenir insupportable sur le plan financier. De plus la consommation des ressources de calcul des ordinateurs à usage professionnelle souffre d’obsolescence matérielle difficilement justifiable. Certaines organisations ont fait le choix de se tourner vers des distributions GNU/Linux professionnel. Donc cela justifie je pense l’argument d’une solution agnostique Windows et Linux 🙂

Bref, au-delà de ça, il faudrait avoir une solution qui puisse être évolu’tif (tiens, cela pourrait être un excellent nom pour un salon de coiffure) dans le temps et qui assurerait un minimum de fonctionnalité que nous pouvons retrouver dans des solutions qui ont pignons sur rue :

• Export des résultats
• Envoi des résultats par mail
• etc (comprendre à détailler)

Surtout et encore une fois avoir une solution simple et sexy. Sinon les utilisateurs ne l’utiliseront pas.

Vous avez dit Sexy ?

Cahier des Charges

Bien, maintenant que nous avons les plans en main, passons à notre checklist pour construire tout cela.

Attention, toujours sans se laisser entrainer par se bon vieux White Rabbit un peu trop adeptes des Jeffersons Airplaine, sinon c’est le bad trip assuré et notre application va pas bien ressembler à grand-chose.

Et bien sachez que pour une fois, j’ai été discipliné. J’ai ces derniers mois eu le temps de reposer mes petites cellules grises et de prendre du recul 🙂

Quel langage vais-je utiliser ? Pour rappel, il faut que ce dernier soit agnostique au SE² Windows et Linux pour faciliter la gestion de l’application. Je propose d’utiliser Powershell dans sa version 5.

• Ce choix est motivé par la présence par défaut de cette version sur tous les postes utilisateurs Windows (à ce moment de rédaction de ce billet) et ce dernier est compatible avec Powershell 7
• Il est possible d’exécuter du code Powershell sous Linux sans à avoir à faire de la bidouille car cela est officiellement supporté, maintenu et mise à disposition par Microsoft
• Nous pouvons faire des interfaces graphiques et CLI³ donc il y a la possibilité de faire quelques choses de sexy <3. Attention à vérifier la compatibilité de certaines bibliothèques .Net et propre au SE Windows

Comme nous utilisons OLLAMA, je reste sur mon serveur préalablement en production ainsi que les modèles déployés précédemment. Toutefois, il serait bien de pouvoir prendre en compte les nouveaux modèles qui peuvent être amener à être déployer ou mis à jour de manière dynamique.

Pour l’instant, il n’est pas prévu dans l’expression du besoin de mode service donc pas d’utilité de développer un mode ou script dans ce sens. Toutefois, en termes de configuration il serait utile d’avoir un fichier que l’utilisateur puisse modifier ou au mieux l’équipe IT⁴.

L’exploitation des résultats se fera visuellement dans la console ou l’interface graphique. Nous offrons la possibilité à l’utilisateur d’exporter, sauvegarder le résultat du prompt qu’il a soumis au format TXT⁵ ou HTML⁶. Naturellement, il pourra également envoyer ce même résultat par mail.

Concernant l’aspect sécurité, l’application ne nécessitera pas d’élévation de droits d’administration quant à son utilisation. Son usage étant uniquement sur le LAN⁷, le trafic en HTTP⁸ sur le port par défaut est toléré. Toutefois, je recommande de communiquer en HTTPS⁹. La présence du mode Debug est de la possibilité de rediriger l’ensembles des transactions du script dans un fichier permette au-delà du débogage de garder une trace des exécutions.

En conclusion, notre liste de course pour notre application :

• Langage de développement & Fonctionnalités
  • .NET Framwork à travers Powershell (v5 ou plus)
  • Journalisation de l’exécution du code
  • Export des données en TXT et HTLM
  • Envoie des données par mail
  • Fichier de configuration
  • Mode GUI¹⁰ (pour Windows)
  • Mode CLI (pour Windows et GNU/Linux)
• Sécurité
  • Ne nécessite pas d’élévation de privilège
  • Connexion uniquement sur le LAN (HTTP ou HTTPS)
  • Pas d’authentification à l’API nécessaire

Il est temps de passer à la construction et définissions de nos différents niveaux de topographie d’architecture, applicative et logiciel.

Topographie – Infrastructure

Topographie – Applicative

Encore une fois, je ne suis toujours pas architecte d’application, mais je commence à bien mettre à jours mes restes. C’est bien en forgeant que l’on devient forgeron 🙂

A la racine du répertoire, nous retrouvons les deux fichiers exécutables :

• SS_045_1.0.2_Ollama-CLI_Main.ps1 : Qui est le fichier d’instanciation de la solution est qui permet également de réaliser toutes les actions en mode manuel que ce soit sur les environnements Windows ou Linux.
• SS_045_1.0.2_Ollama-GUI_Main.ps1 : Presque le même fichier que le fichier précédent mais dont l’usage est uniquement réservé aux environnements Windows de par son interface graphique.

Si nous regardons en détails les sous répertoires :

• _archives : Qui est plus ou moins la poubelle du projet dans lequel je garde l’historique des scripts et modules ayant évolués
• config : Répertoire contenant le fichier de configuration powershell. Afin de palier à toute suppression malencontreuse du fichier de configuration, j’ai développé une fonction pour regénérer ce dernier. Etant un adepte du Alt+Maj+Del, j’ai dû réécrire un certain nombre de fois mon fichier.
• export : Répertoire qui va contenir les résultats au format texte ou html. Par défaut, en mode CLI les données sont automatiques stockées dans ce répertoire. A l’inverse le mode GUI offre plus de flexibilité et il est possible de choisir dynamiquement un autre emplacement.
• log : Répertoire qui va contenir la ou les traces d’exécution du code si l’option est activée. Cela à son importance car il permet au petit gars qui à dev l’application dans sa baignoire de corriger les bugs. Le fichier ne prend pas de place et est réinitialiser à chaque lancement.
• modules : Répertoire contenant les modules powershell développé pour l’application. Aujourd’hui au nombre de trois dissociant la partie OLLAMA, System et HTML.
• sources : Répertoire qui contient les éléments et dépendances de l’application hors code. Les images, icônes etc.

Cette arborescence est valable pour la version 1.0.x pour l’instant. Cette dernière pourrait être amené à évoluer dans une version mineure ou majeure dans le cas d’implémentation de nouvelle fonctionnalité ou de refactorisation, optimisation de code.

Topographie – Logiciel

Avec cette magnifique transition, parlons peu mais parlons bien. Contrairement aux projets précédents, j’ai repris par nostalgie une approche par logigramme comme à la bonne vieille époque de mon BTS¹¹ IRIS¹².

L’approche reste classique dans la phase de développement. Une approche modulaire, unitaire puis la phase d’intégration et d’ajustement et correction.

Naturellement avant de faire de la GUI tout part de la CLI en termes de logique et de fonctionnement.

Le programme est plutôt simple. Ce dernier se décompose en une succession de vérification avant de permettre une interaction de la part de l’utilisateur. L’utilisateur aura si le serveur OLLAMA est joignable la possibilité d’exécuter l’un des 6 sous-processus suivants : * Sélectionner un modèle LLM. Sans exécution de cette option il ne sera pas possible d’exécuter de soumettre un prompt à OLLAMA. * Sélectionner le type de prompt. Par défaut, les requêtes qui seront adressé à OLLAMA ne seront que du texte. Pour interagir avec une image ou un document il faudra changer de mode. * Settings permet d’afficher le fichier de configuration et de pouvoir modifier ce dernier directement et de sauvegarder les modifications. * Debugging. Permet de vérifier les connexions avec les différents services SMTP, OLLAMA, OpenWebUI. * About affiche le numéro de version ainsi que le crédit de l’application * Start Ollama permet de saisir une requête à soumettre à notre serveur OLLAMA. Il faut préalablement avoir choisi un modèle de moteur IA. Sans cela, l’option n’apparait pas et ne peut être lancé. 13Le programme est plutôt simple. Ce dernier se décompose en une succession de vérification avant de permettre une interaction de la part de l’utilisateur. L’utilisateur aura si le serveur OLLAMA est joignable la possibilité d’exécuter l’un des 6 sous-processus suivants: * Sélectionner un modèle LLM. Sans exécution de cette option il ne sera pas possible d’exécuter de soumettre un prompt à OLLAMA. * Sélectionner le type de prompt. Par défaut, les requêtes qui seront adressé à OLLAMA ne seront que du texte. Pour interagir avec une image ou un document il faudra changer de mode. * Settings permet d’afficher le fichier de configuration et de pouvoir modifier ce dernier directement et de sauvegarder les modifications. * Debugging. Permet de vérifier les connexions avec les différents services SMTP, OLLAMA, OpenWebUI. * About affiche le numéro de version ainsi que le crédit de l’application * Start Ollama permet de saisir une requête à soumettre à notre serveur OLLAMA. Il faut prélablement avoir choisi un modèle de moteur IA. Sans cela, l’option n’apparait pas et ne peut être lancé.

Je propose de voir chacun des logigrammes des 6 sous processus.

1 – Select LLM

La récupération des différents LLMs installé sur notre serveur OLLAMA se fait par le biais d’un appel API (d’où la vérification en amont de la disponibilité du serveur -_-‘). Une fois les modèles, récupéré, nous les affichons dans une boucle. L’utilisateur est obligé de sélectionner un modèle. Il n’a pas la possibilité de quitter ce traitement. La condition pour quitter la boucle est de définir une valeur à 100. Condition qui ne peut être atteinte que si un modèle est sélectionné 🙂 Sinon c’est l’infinite loop !

2 – Prompt Type

Par défaut, le mode de prompt est défini sur Standard. Le type de prompt n’étant pas cruciale pour soumettre une requête, il n’y a pas lieu de forcer l’utilisateur à choisir un type comme pour le LLM. Si l’utilisateur choisi un type de prompt Files ou Pictures, il devra saisir le chemin complet de l’élément. Si l’utilisateur à les doigts palmés alors un message d’erreur s’affichera et le mode standard sera forcé.

3 – Settings

Normalement il n’y a pas lieu que notre fichier de configuration soit absent puisqu’il a été vérifié et au besoin regénéré. Mais admettons que quelqu’un l’ait supprimé entre temps ça serait fâcheux (je pense à un AV par exemple ou autre MDR, XDR et j’en passe). Les éditeurs de texte étant différents entre Linux et Windows, nous ne pouvons pas faire de générique. Il est donc nécessaire de déterminer la nature de l’OS et d’appeler l’éditeur de texte. Il y a toutefois quelques spécificités pour l’appel de l’éditeur de texte sous Linux et je reviendrai sur ce point dans la partie Sécurité.

4 – Debugging

Là pour le coup c’est basique de chez basique et je n’ai pas voulu expliquer ma fonction de vérification de port (cf module SS_045_1_System_Network.psm1). Je vais vérifier à partir des éléments présents dans le fichier de configuration la disponibilité du serveur OLLAMA (11434/tcp14) et du serveur SMTP (25/tcp). En bonus je vérifie en dur dans le code la disponibilité du serveur OpenWebUI (8080/tcp ou 443/tcp). OpenWebUI est purement optionnel. Son état n’a aucun impact sur le script.

5 – About Zelen Zajac

Le plus complexe des logigrammes à comprendre…

6 – Launch Ollama Request

Enfin quelque chose de plus intéressant. Attention, le logigramme commence à devenir un peu plus complexe. La présentation en tableau est totalement exclue… 🙂

Et en plus le type, ça le fait marrer… Cinglé va ! Tu dis que ça t’amuse en plus de faire ça ? Pour ceux qui vont des logigrammes par plaisir, la peine de mort !

Le logigramme se comprend plutôt bien, je ne vais donc pas décrire le début et la fin du script. Ce qui m’intéresse ici et que je vais développer dans la partie sécurité est l’usage du tache parralèle.

Sans rentrer plus en détail que ça, sans utilisation d’un ScriptBlock notre script va freezer le temps de l’exécution de la requête vers notre serveur OLLAMA. Franchement se taper dans un terminal un « Not Respond » c’est moche. D’où l’utilisation d’une barre de progression pour indiquer à l’utilisateur que le serveur travaille.

Second point important, si nous regardons plus en détail la partie dédiée à l’envoi de mail si le SE est un Linux, nous affichons un message et nous n’envoyons pas de mail. Effectivement et je dirai que c’est pour le moment la seule fonctionnalité qui n’est pas reprise.

Donc pas si agnostique que ça ton outil ?

Je pourrais passer par MUTT par exemple. Mais c’est se compliquer la vie. Le contrôle et le paramétrage des dépendances externes dans le script serait juste un travail dantesque. Toutefois vous pouvez si vous le souhaitez tester 🙂 (sous réserve, spoiler alerte de me contacter au préalable #bisou)

Tout ce cirque parce que [System.Net.Mail.MailMessage] et [System.Net.Mail.SmtpClient] sont pour l’un déprécié et mal reconnu sous Linux…

Bon pas si compliqué que ça 🙂 J’avoue que je suis un peu rouillé en logigramme, mais ça fait du bien par nostalgie de revenir aux bases. Au moins, vous avez ma logique.

Sécurité

Authentification

Admettons que nous devons nous authentifier à l’application OLLAMA où via Nginx, il va de soi que je ressortirai ma méthode devenu un standard chez moi en passant par le CLIXML.

Je garderai naturellement la possibilité de s’authentifier manuellement et également la possibilité de s’authentifier automatiquement en chiffrant le mot de passe via les algorithmes de chiffrement Windows 🙂 Toutefois reste à savoir si cette fonctionnalité est agnostique. A creuser…

Communication

Dans la version 1.0.x l’ensemble des communications entre le client et le serveur sont établies via le protocole http. C’est pas ouf hein ?

Sans surprise, les informations sont en claire dans les trames.

Dans les versions à venir en 1.1.x je pense les échanges via le protocole https. Ce qui est plus propre, néanmoins, il est nécessaire de prendre en compte le cas de figure des certificats autosignés et ça c’est un poil plus pénible en powershell version 5.

En reprenant le port 11444/tcp dédié à la publication d’OLLAMA via le protocole https, il n’y alors plus de doute quant aux tests effectués. Reste plus qu’à implémenter cela.

Parallélisation

Nous parlons beaucoup de sécurité en oubliant d’aborder la sécurité du code, la sécurité logicielle. Dans le cas d’un programme itératif (étape par étape) la sécurité se résume souvent qu’à la gestion des erreurs.

Toutefois dans des programmes qui commencent à établir des connexions ou réaliser des tâches en parallèle du déroulement du programme principal, cela fait comme je l’ai dit plus haut « tâche » de se taper un « Program Not Respond » ou un truc du genre.

Cela va être notre cas. Nous allons soumettre notre requête auprès de notre serveur OLLAMA puis attendre sa réponse. J’ai choisi de recevoir l’intégralité de la réponse et non pas de recevoir la réponse json segmenté, fragmenté.

Vous l’aurez compris, il va donc être nécessaire de réaliser une tâche parallèle. La grosse difficulté de la manipulation entre la tache mère et fille relève encore et toujours dans la portée des variables. Ce qui peut vite décourager des novices.

Pour expliquer et illustrer le principe :

• Création d’un ScriptBlock : Dans notre script nous définissons une variable qui contient des paramètres et un traitement.

• Initialisation d’un tableau de paramètre : Nous allons stocker dans une variable les valeurs correspondantes aux paramètres défini précédemment. Le fil rouge sur le bouton rouge, le fil bleu sur le bouton bleu. Sinon vous allez avoir des petites surprises.

• Appel de la tâche : Nous récupérons l’état de la tache dans une variable en fournissant en paramètre le code ainsi que les paramètres stockés dans les variables précédents. Il suffira ensuite de jouer avec les différents états de la tâche. Et surtout on n’oublie pas de faire le ménage ! Bande de salopi**d 🙂

Dans le cas du script en interface graphique, la méthode diffère légèrement, mais reste la même. Il faut juste prendre en compte les objets graphiques.

Dépendances

J’ai voulu m’affranchir d’un maximum de dépendance et d’avoir une application « Vanilla » qui puisse être exécutée depuis n’importe quel système sans à avoir à monter une usine à gaz. Donc pas de dépendances, si vous avez besoin d’un relai SMTP, il relève alors d’une problématique standard à n’importe quelles applications à ce jour.

Je pense que nous avons fait le tour de l’ensemble théorique. Et il est temps de passer à la partie pratique. Il va toutefois être difficile d’être cohérent dans le temps car la solution est amenée à évoluer et donc il faudrait que je garde à jour l’ensemble du billet. Là est ce que ça sera toujours un loisir ? Eprouverais je toujours du plaisir ?

To Be Continued… 🙂

Sources

• Ollama : API

1. API : Application Programing Interface ↩︎
2. SE : Système d’Exploitation ↩︎
3. CLI : Command Line Interface ↩︎
4. IT : Information Technology ↩︎
5. TXT : Texte ↩︎
6. HTML : HyperText Markup Language ↩︎
7. LAN : Local Area Network ↩︎
8. HTTP : HyperText Transfer Protocol ↩︎
9. HTTPS : Secure HyperText Transfer Protocol ↩︎
10. GUI : Graphic User Interface ↩︎
11. BTS : Brevet de Technicien Supérieur ↩︎
12. IRIS : Informatique et Réseaux pour l’Industrie et les Services techniques ↩︎
13. LLM : Large Language Model ↩︎
14. TCP : Transmission Control Protocol ↩︎

Dans mon cas personnel je devrais plutôt dire, Ce matin un prompt Ollama a tué mon serveur…

Toujours dans la dynamique du sujet d’étude en cours « l’IA¹ » et l’étude de la solution Ollama, je suis victime du fait de sa causalité de l’ouverture d’un projet et donc de cet article.

Pour reprendre la conclusion de l’article traitant d’Ollama et de la solution OpenWebUI, j’avais émis l’hypothèse de créer mon propre client Ollama en me passant sur l’API² de ce dernier.

Du fait de la consommation de ressource importante nécessaire au bon fonctionnement d’OpenWebUI et d’Ollama, je voyais plutôt d’un bon œil de créer son propre client. Soit pour faire simple de se passer de la solution OpenWebUI. L’un des arguments complémentaires, l’interface CLI d’Ollama n’est pas hyper user-friendly pour celui qui n’a pas l’habitude des interfaces CLIs. Ce que je souhaite c’est un usage à moyen et grande échelle. Comprendre par là un environnement familial ou pourquoi pas dans une PME ?

Avec l’ensemble de ces réflexions, je me suis dit

« Ok je me lance et si ça les tests sont concluants je fais ma petite application… »

C’est là que ça dérape. Pris d’une creative fever (sans vouloir divulgâcher la suite du billet), le projet SS_045³ va basculer en GS_045⁴ sous son nom de code Zelen Zajac ou en français Lapin Vert. Cela viendra donc concrétiser la création d’un client multiplateforme CLI⁵ et GUI⁶ pour Windows.

Comme quoi, encore une fois d’une petite idée va naitre un projet sympathique. Surement inutile, mais sympathique 🙂 Et je suis certain que le fan club de Chantal Goya sera content #coeur.

Avant-Propos

Contrairement aux projets précédents Green Ray ou Dream Nebula je vais rentrer un peu plus en détail dans la technique et ce pour des raisons simples que j’ai appris et renforcé pas mal de compétence en termes de développement.

Cet article sera donc orienté plus développement qu’infrastructure.

Mon code sera disponible sur GitHub contrairement à d’autres projets.

Pourquoi ce choix et ce revirement de position ?

Parce que je pense que cela peut être profitable à d’autres utilisateurs de la solution Ollama qui veulent se passer d’OpenWebUI. 🙂 Et je pense que là c’est rester dans le monde de l’open-source.

Bref, si votre curiosité est toujours suscitée je pense que le reste de l’article devrait vous satisfaire. Dans le cas contraire, je vous laisse exécuter la combinaison Ctrl+F4 ou Ctrl+W pour fermer cet onglet.

Prérequis

• SE :
  • Windows (Server ou Workstation)
  • GNU/Linux (RHEL⁷ ou Debian)
• Apps :
  • Ollama
• Autres :
  • PowerShell version 5 et supérieur

Guide

• Partie 1 : Théorie
  • Définir l’expression du besoin
  • Aborder le cahier des charges
  • Défendre les solutions techniques retenus
• Partie 2 : Pratique
  • Guide de déploiement de la solution
  • Paramétrage de l’application
• Partie 3 : Démonstration
  • Présentation de la solution dans les différents modes qui ont été développés

Conclusion

Ce petit projet a été source de défis pour ne pas écrire challenges et de montée en compétence sur le code. Oui moi qui ne jure que sur le CLI, je me mets à faire du GUI.

La plus belle satisfaction reste d’avoir fait mon premier code cross-plateform .Net entre les SEs⁸ Windows et Linux. Le côté agnostique permet donc d’avoir une seule version du code ce qui facilite l’évolution et le maintien du code, mais surtout d’offrir les mêmes services peu importe la nature du système de l’utilisateur. Je me sens à ce moment comme un chevalier ayant réussi ça quête… Ou pas car le démoniaque lapin est toujours là est doit être rassasié (amélioré, je voulais dire <3 ) !

Si je me réfère à l’actualité au moment de la rédaction de ce billet, la volonté du gouvernement français de se libérer des technologies américaines sur les outils informatiques aux détriments de solutions françaises et open source viennent alimenter d’eau mon moulin.

Au-delà de ces derniers points, j’ai trouvé intéressant de manipuler l’API OLLAMA dans le cadre d’un réseau local afin d’offrir une solution viable et fiable dans une PME.

Mon application reste certes à évoluer pour être réellement concurrentiel aux solutions actuellement sur le marché. Toutefois est-ce là mon objectif ? Je ne crois pas, du moins je n’ai pas cette prétention.

Ce qui me rassurer néanmoins, ce que j’ai pu faire nativement peut donc être implémenté comme plugin d’une application, voir encore être utilisé comme une passerelle applicative entre deux applications. Par exemple, j’ai la volonté de reprendre mon projet de passerelle applicative entre VEEAMOne et ITOP pour générer des tickets sur le déclenchement d’une alarme d’exploitation géré par l’IA. Ca, c’est bandant comme projet et serait super faire un pas de plus vers l’efficience !

L’IA que je voyais comme une menace est ennemie au final selon l’usage que nous voulons en faire devient un outil puissant. Certes, j’ai mis du temps à être convaincu par la chose mais il n’est jamais trop tard. Le plus important pour moi est de rester supérieur à l’IA dans l’usage que je vais en faire.

Le mot de la fin :

C’est l’histoire d’un Lama qui rencontre un Lapin, vous buvez un verre ? Puis un homme rentre dans un bar. Stop appelez Brigitte BARDOT ! J’ai mon API qui me dérange ! Je je suis agnostique, je suis un lapin !

Erwan GUILLEMARD

Sources

• Windows : Installer Powershell pour Linux
• Article : OpenWebui
• Article : Ollama

1. IA : Intelligence Artificielle ↩︎
2. API : Application Programing Interface ↩︎
3. SS_045 : SystemScript #45 ↩︎
4. GS_045 : GraphicalScript #45 ↩︎
5. CLI : Client Lign Interface ↩︎
6. GUI : Graphical User Interface ↩︎
7. RHEL : RedHat Entreprise Linux ↩︎
8. SE : Système d’Exploitation ↩︎