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 ↩︎

Difficile néanmoins de progresser vite sur cette technologie puisque je suis Candide. M’enfin comme l’écrivait Franquin, je vais essayer de décortiquer la techno et son fonctionnement et de présenter ma compréhension de la chose. L’objectif étant naturellement de prouver s’il est possible d’altérer l’inaltérable du stockage objet.

Prérequis

• SE : RHEL, UBUNTU
• Apps : VEEAM B&R 12.1
• Autres :
  • Environnement GNU LINUX Durci
  • VEEAM B&R 12.1 et versions ultérieures
  • License VEEAM Entreprise

Avant Propos

Nous allons commencer par un petit brin d’histoire sur l’interface S3.

Qu’est ce que signifie l’interface S3 ? Il signifie Amazon Simple Storage Service (et oui, Jeff BEZOS in da house !). Contrairement à ce que j’ai pu penser, l’interface n’est pas toute jeune (quoi que vous me direz, le temps c’est relatif, non ?). L’API S3 a été officiellement mis sur le marché en 2006 par Amazon.

L’objectif initial était et reste de proposer à des entreprises un service de stockage de données dans le nuage et de s’assurer de la disponibilité et de l’intégrité de ces dernières. Ouai mais bon en 2006, le cloud c’est pas trop d’actualité, c’est plus l’ère du Personal Computer ? Pour la plèbe, oui, mais nous avons toujours un train de retard avec les grands GAFAM³ et autres sociétés de la tech 🙂

Bref, certaines entreprises décident de stocker leurs données chez Amazon à travers ce nouveau service pour s’affranchir des coûts et inconvénients d’un SI local. En contrepartie, Amazon facture ces dites entreprises au stockage (Go) ainsi qu’au trafic internet à destination de ces données. Depuis, l’usage a littéralement explosé puisque nous ne parlons plus en Gigaoctet, mais de manière commune en Téraoctet voir Pétaoctet et certains plus consommateurs que d’autres en Exaoctet (1 Eo = 1 000 000 000 Go) puisque l’usage du cloud n’est plus restreint à un besoin professionnel mais orienté comme un service à destination des usagers (coucou NETFLIX, SPOTIFY, FACEBOOK, X etc).

La base de l’API S3 est donc de fournir une disponibilité de la data la plus haute possible de manière sécurisé tout en restant le plus flexible possible. L’objectif étant de stocker des quantités phénoménales de données. Dans certains cas, il n’est pas rare de parler de DataLake (Lac de données).

Oui mais alors qu’est ce qu’on stocke ? Principalement tout et rien, c’est à dire des données de sauvegarde, d’archive, des applications, sites webs, contenu multimédia, bases de données, etc. Cependant tous ces types de données pour la plupart répondent à un même usage, le WORM⁴. (C’est un super jeu avec des vers qui se tirent dessus ? Non ça c’est WORMS 🙂 )

WORM signifie Write Once Read Many. Soit dans les faits j’écris une fois les données et je les consulte énormément. Par exemple, je charge une photo sur un réseau social. Je vais l’écrire une fois sur le système puis cette dernière sera visible et accessible de tous. La donnée ne va pas vivre. Sur ce principe, il va alors être possible de définir des algorithmes de segmentation de cette donnée pour garantir un gain d’espace, d’évolutivité, la sécurité de la donnée ainsi que sa disponibilité.

Si nous regardons à la loupe les 4 critères ces derniers permettent :

• Gain d’espace : Compression de la données avec déduplication et dans certains cas de l’eraser coding
• Evolutivité : Possibilité de définir un nouveau stockage et de joindre celui ci au système existant à travers internet.
• Sécurité : Les données sont traduites en objets et stockées à plusieurs emplacements de stockage permettant de reconstruire la donnée en cas de corruption d’un ou plusieurs stockages (sur la base de la reconstruction par parité). Il sera également possible de définir une durée de vie à cette donnée (coucou immutability). J’ai vulgarisé. En réalité, l’objet étant une entité logique, ce dernier est stocké sous forme de fragment… Complexe d’un coup non ? 🙂
• Disponibilité : A partir du critère précédent, si un des serveurs où se trouve ma donnée est HS ou momentanément inaccessible, ma donnée continue d’être disponible car ces données en tant qu’objet sont fragmentées sur d’autres serveurs.

Avant d’aller plus loin, il est important de comprendre que l’interface S3 a tout son sens en tant que SaaS⁵. Néanmoins, cela implique de souscrire à ce service chez Amazon par exemple. Ce n’est pas objectif car je recherche une solution OnPremise pour construire et éventuellement proposer ce service dans mon catalogue de service. C’est pourquoi il a été compliqué de trouver une solution S3 OnPremise totalement « open ». L’une des forces du stockage objet (S3) est sa flexibilité. L’un des inconvénients (selon moi) est comment s’assurer que les données (mes datas à moi) ne sont pas utilisées par autrui, sont bien supprimées etc ? Il faut faire confiance mais aujourd’hui cela ne suffit pas…

Bref, en cherchant un petit peu mais pas trop, j’ai identifié une solution opensource MinIO. C’est avec cette dernière que je vais m’amuser avec le stockage objet.

Théorie

L’une des premières questions que nous pouvons nous poser, Linux Hardened VS S3 ?

Comme j’ai pu le présenter dans un article précédent, l’immuabilité au sens hardened du terme est portée par l’OS⁶ nativement. Toutefois, ce dernier est plus adapté pour la protection des fichiers que des données et le risque se trouve au niveau du compte système (Root). S’il y a escalade des droits et donc contournement des mécanismes de sécurité, il est possible de supprimer les données en retirant l’attribut « i« .

Dans le cas de S3, l’approche est différente car c’est le moteur S3 qui gère l’immuabilité et les données ne sont pas stockées sous forme de fichier mais d’objet. Ainsi, pas possible de supprimer la donnée peu importe que nous soyons administrateur, Trump, Gourou d’une secte ou même une divinité. Toutefois, un acte physique devrait faire y arriver…

Histoire

Comme toujours, mon côté père castor il est important de s’intéresser à l’histoire de MinIO.

MionIO a été fondé en 2014 par Arnand Badu Periasamy, Garima Kapoor et Harshavardhana. L’objectif du projet est de démocratiser le stockage cloud autour de la technologie de stockage objet dans le vaste univers de la communauté OpenSource. C’est ainsi que naît Minimal Object Storage » ou MinIO :).

Une première release ou version voit le jour courant 2017. Durant cette période un changement de licence va être réalisé suite à son essor auprès de la communauté. L’ensemble des technologies est alors protégé par la licence GNU-AGPLv3. L’objectif étant de se prémunir des géants de la tech.

Par la suite, le bras de fer et les contentieux vont commencer. MinIO avec la montée en puissance de KUBERNETES est perçu comme une licorne. MinIO ira jusqu’à révoquer les droits d’usage de NUTANIX sur son service NUTANIX Objects pour violation de licence… Quand il y a du pognon en jeu, cela devient vite le bordel, je l’ai toujours dit… M’enfin. Le pourquoi ? L’usage commercial sans paiement, ça ne passe pas…

2025, MinIO cesse la publication d’images Docker et des binaires précompilés pour les versions communautaires. MinIO devient MinIO AIStor.

Malheureusement, c’est le cas classique d’un projet formidable ouvert à tous qui avec le temps s’enferme dans la génération de profit, de protection intellectuelle. MinIO souhaite avoir comme tous les acteurs de ce monde une part du gateau CLOUD+IA.

S3 versus Linux Hardening

Dans un billet précédent, je ventais par Mont et par Vaux les mérites et robustesses du hardening linux, mais qu’en est il du hardening S3 ?

Je pense que pour répondre à cette magnifique question, il est nécessaire de passer par un tableau (oui j’aime rédiger sous la forme de tableau).

Ce que nous pouvons conclure de cette analyse, S3 est plus à même de protéger les données que le hardening LINUX. S3 permettant une meilleure immuabilité dans le temps et ce dernier est prévu pour cet usage précis. Même si cela fonctionne avec la gestion de l’immuabilité LINUX.

Vous lecteurs, ne pouvez pas savoir la souffrance que cela m’apporte d’écrire de tels mots. J’ai toujours défendu bec et ongles le hardening linux et voyez vous, force est de constater que je suis dans le déni. Tel Pierre CAMBRONNE à la bataille de WATERLOO :

La garde meurt mais ne se rend pas.

Pierre CAMBRONNE

Même si dans mon cas c’est un peu exagéré (mais juste un iota hein 🙂 )

Mécanisme S3

Maintenant que nous savons faire la différence entre le hardening et l’API S3, intéressons nous à comment l’objet est rendu immuable 🙂 Chose que j’ai mise un certain temps à assimiler personnellement et qui je le pense ne doit pas forcément être très claire pour bon nombre d’entre nous.

S3 Comment ça marche ?

Pour faire simple car je rentre dans le détail dans la sous partie suivante, lorsque nous envoyons un fichier vers un média S3, le service S3 va générer un fichier de metadata qui va contenir toutes les informations de la donnée. Puis le fichier va être découpé suivant l’algorithme d’Erasure coding paramétré afin de définir notre donnée avec des blocs de données puis de parité.

Le moteur va alors stocker les donnée en respectant les contraintes de restauration et de disponibilité de la données sur chaque disque puis retournera à l’utilisateur le succès ou non de l’opération. Le stockage des données va se faire dans des Buckets.

La durée de vie de la donnée sera stockée dans le fichier de métadonnées. Ainsi, si je souhaite supprimer une donnée pour laquelle la durée de rétention n’est pas atteinte, lors de l’appel de l’opération de suppression, le moteur va lire le fichier de donnée puis me retourner une erreur 403 Forbidden car je ne réponds pas à la condition d’altération de la donnée.

Plutôt simple non ?

Déroulé d’un appel S3

Dans un premier temps, nous l’application (interne ou externe) va émettre une requête HTTP standard conforme à l’API S3. Un PUT pour écrire, un GET pour lire, un DELETE ou LIST pour gérer les objets. Dans les headers, nous devons retrouver les valeurs suivantes (x-amz-*). L’authentification est réalisée pour chaque requête côté client à travers une clé. MinIO vérifie la signature et va consulter les politiques IAM afin de définir si oui ou non l’opération est autorisée. Dans le cas contraire, nous aurons un joli 403 Forbidden. MinIO va parser l’URL afin de router la requête vers la bonne donnée objet dans le bon bucket ainsi que le header pour identifier l’opération à réaliser : Ecriture simple ? Multipart upload ? Téléchargement ? Suppression avec versionning ? Liste des objets ? C’est au niveau du moteur objet, coeur de l’application que tout va se jouer. Pour chaque Objet, MinIO va générer un fichier de métadonnée (x.meta) qui va contenir : Le checksum Le Etag La version La carte de blocks C’est alors l’Erasor Coding qui va découper la donnée en blocs de données et de parité. Les blocs sont distribués sur les disques selon la politique d’EC défini. Si c’est un succès, MinIO retournera le code HTTP 200/204 avec l’Etag de l’objet ainsi qu’un identifiant de requête. Dans le cas contraire (une surcharge par exemple ou un bucket qui n’existe pas) nous aurons un code HTTP 4XX ou 5XX avec un message compatible S3. Le chiffrement (SSE-S3 ou TLS), le versionning, les lifecycle rules et la réplication asynchrone fonctionnent de manière transparente sur toutes les opérations.

Architecture S3

Dans la logique, l’architecture que nous devrions mettre en place est la suivante :

• Infrastructure Clustérisé pour MinIO (ring)
• Protection par un certificat si publication du service
• Mise en place de NAT ⁷+ PAT⁸
• Configuration de l’Eraser Coding

Vous comprendrez qu’il n’est pas possible chez moi d’établir un ring.

Un seul argument s’y oppose, un seul ! C’est dangereux. Bah ceux qui n’aiment pas le danger, faut qu’ils choisissent une autre activité.

Nicolas SARKOZY

En l’occurrence, le danger étant ma formidable épouse, je vais choisir une autre solution. Je lui ai déjà pris une partie de son dressing, de la buanderie, je ne suis pas venu ici pour souffrir okay ? 🙂 (Je t’aime chérie, promis je vais faire le ménage).

Donc, pas de VM que du physique. Toutefois, je vous parle d’Eraser Coding. Qu’est que cela vient faire la dedans ? Je pense qu’une sous partie va être nécessaire.

Eraser Coding

L’Eraser Coding est un moyen de protection des données par calcul mathématique plutôt que la copie des données. Cette technologie est bien plus efficace en terme de stockage que le RAID ou la réplication.

Voyons plutôt.

Une donnée est découpée par N blocs de données et M blocs de parité. La configuration EC:M définit alors le nombre de blocs de parité. Exemple : EC:2, 2 blocs de parité.

Chaque bloc de parité est une combinaison linéaire des blocs de données calculée. Ainsi, n’importe quels N blocs parmi les N+M suffisent à reconstruire l’objet entier, que ce soit des blocs de parité ou de données. Si nous avons 4 blocs de données et 2 de parité, 4 blocs sur 6 permettent de reconstruire la donnée.

Les systèmes vont alors distribuer la donnée aléatoirement sur les disques de l’erasure définit. Soit un seul bloc par disque par objet. Aucun disque ne doit contenir deux blocs du même objet, puisque en cas de panne d’un disque, les blocs restants sur les autres disques doivent permettre de recalculer le bloc manquant.

Faisons une petite comparaison avec un RAID5 et RAID6.

Là on n’y voit plus clair, pourtant, il existe une relation à bien assimiler entre le nombre de parités possibles par rapport au nombre de disques. Cette règle est fondamentale et doit être acquise.

Disques Utilisables = Disques Totaux – Blocs de Parité

Espace Utilisables = (Disques Totaux – EC:N) / Disques Totaux

Donc on ne définit pas au doigt mouillé la parité de notre EC.

Je pense (comme dans tous mes billets lorsque j’arrive à la fin de la partie théorique) que nous sommes suffisamment armés pour nous lancer dans la partie pratique. J’ai choisi d’implémenter un stockage S3 pour mon serveur VEEAM.

Pratiques

Nous considérons que nous possédons déjà un Serveur VEEAM ainsi qu’un serveur physique de préférence (mais virtuel fonctionne aussi bien) RHEL⁹ ou UBUNTU/DEBIAN durci au préalable pour notre stockage objet.

Egalement, notre futur serveur de stockage objet (compatible S3) aura une partition dédiée au stockage montée et formatée au format XFS.

Brouillon enregistré.

Naturellement, cela va être un peu short niveau ressource donc je vais adapter en conséquence les paramètres de ma VM à défaut d’avoir un serveur physique dédié pour le stockage S3.

MinIO

Installation

Serveur

1 – Download me

Il sera nécessaire d’ajouter les sources de l’éditeur en téléchargeant le package RPM puis d’installer celui-ci.

## Community Edition
# wget https://dl.min.io/server/minio/release/linux-amd64/minio-20250907161309.0.0-1.x86_64.rpm -O minio.rpm

or

## AGPL License
# wget https://dl.min.io/server/minio/release/linux-amd64/archive/minio-20240613225353.0.0-1.x86_64.rpm -O minio.rpm

/!\ Attention, ne privilégiez pas la Community Edition, sauf si vous savez ce que vous faites… Perso, nous partirons sur la version sous licence AGPL, bien plus complète.

2 – Install me

# dnf install minio.rpm

Client

Le client va nous permettre d’interagir directement avec notre daemon en ligne de commande.

# curl -L -o /usr/local/bin/mc https://dl.min.io/client/mc/release/linux-amd64/mc

# chmod +x /usr/local/bin/mc
# /usr/local/bin/mc --version

Configuration Système

J’enfonce une porte ouverte. Mais cette étape est importante car elle représente un enjeu majeur de la sécurité de notre serveur de stockage dédié à la sauvegarde et donc de notre système d’exploitation.

1 – Compte dédié

Dans le respect des bonnes pratiques ANSSI nous allons créer un compte système sans home et groupe dédié au service MinIO.

# groupadd -r minio
# useradd -M -r -g minio minio

Nous définissions les droits sur notre répertoire (point de montage naturellement) ainsi que les permissions adéquates.

# chown minio:minio /mnt/minio
# chmod 700 /mnt/minio
# ls -al /mnt/minio

2 – Setting MinIO Systemd Service File

Créons le fichier qui va nous permettre de lancer notre daemon MinIO au démarrage de notre système.

# vim /usr/lib/systemd/system/minio.service

[Unit]
Description=MinIO
Documentation=https://docs.min.io
Wants=network-online.target
After=network-online.target
AssertFileIsExecutable=/usr/local/bin/minio

[Service]
Type=notify

WorkingDirectory=/usr/local

User=minio
Group=minio
ProtectProc=invisible

EnvironmentFile=-/etc/default/minio
ExecStartPre=/bin/bash -c "if [ -z \"${MINIO_VOLUMES}\" ]; then echo \"Variable MINIO_VOLUMES not set in /etc/default/minio\"; exit 1; fi"
ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES

# Let systemd restart this service always
Restart=always

# Specifies the maximum file descriptor number that can be opened by this process
LimitNOFILE=1048576

# Turn-off memory accounting by systemd, which is buggy.
MemoryAccounting=no

# Specifies the maximum number of threads this process can create
TasksMax=infinity

# Disable timeout logic and wait until process is stopped
TimeoutSec=infinity

SendSIGKILL=no

[Install]
WantedBy=multi-user.target

# Built for ${project.name}-${project.version} (${project.name})

Attention de bien remplacer la valeur des variables User et Group par celles que nous avons créées précédemment.

3 – Variable d’environnement

Créons maintenant le fichier contenant nos variables d’environnement qui sera utilisé par notre service.

# vim /etc/default/minio

Prenez le temps de définir le nom ainsi que le mot de passe du compte super administrateur qui permettra de s’authentifier à l’interface WEBUI. L’accès à l’interface se fera sur le port 9001.

# MINIO_ROOT_USER and MINIO_ROOT_PASSWORD sets the root account for the MinIO server.
# This user has unrestricted permissions to perform S3 and administrative API operations on any resource in the deployment.
# Omit to use the default values 'minioadmin:minioadmin'.
# MinIO recommends setting non-default values as a best practice, regardless of environment

MINIO_ROOT_USER=adm.minio
MINIO_ROOT_PASSWORD=***********************

# MINIO_VOLUMES sets the storage volume or path to use for the MinIO server.

MINIO_VOLUMES="/mnt/minio"

# MINIO_OPTS sets any additional commandline options to pass to the MinIO server.
# For example, `--console-address :9001` sets the MinIO Console listen port
MINIO_OPTS="--console-address :9001"

En termes de permission sur le fichier, ces derniers sont en modification uniquement par le compte root. Donc nous sommes rassurés.

4 – Manivelle et Service au démarrage

Comme toujours, nous allons faire en sorte que notre daemon démarre lors de la mise sous tension de notre serveur.

Pour ce faire, vérifions dans un premier temps que le service se lance bien.

# systemctl start minio.service
# systemctl status minio.service

Puis comme d’accoutumé

# systemctl enable minio.service

5 -Firewall

Il y a deux choses à bien différencier quant à notre service MinIO. La partie console d’administration et la partie API pour le flux de données.

• Console WEBUI : Port 9001/tcp
• Protocol S3 : Port 9000/tcp

Il est donc nécessaire d’ouvrir les flux sur notre firewall.

# firewall-cmd --permanent --add-port=9001/tcp
# firewall-cmd --permanent --add-port=9000/tcp
# firewall-cmd --reload

Naturellement, si nous souhaitons publier notre service de stockage S3 sur le WEB, il conviendrait de faire un SPAT de IP_PUB:443 à destination de notre IP_LOCAL_MINIO:9000. Pour renforcer la sécurité, nous implémenterons IPS, Géolocalisation, Application Control et filtrage sur les IPs Publics entrantes habilitées uniquement.

Il nous reste alors à créer notre règle sur notre firewall pour accéder à notre interface web. Puis depuis notre navigateur favori d’accéder à notre interface (pour l’instant en http).

A partir de maintenant, nous allons attaquer les choses sérieuses. C’est parti pour les buckets et l’assaut du Colonel Kentucky !

Certificats

Naturellement il va falloir que l’on sécurise un minimum nos services web. Par défaut MinIO utilise le protocole HTTP¹⁰. Pour ce faire je vais me simplifier la tâche en utilisant un certificat auto-signé. J’ai la flemme monstrueuse de passer par un let’s encrypt de me taper des règles de PAT¹¹ entre ma box, mon UTM¹²…

# vim openssl.cnf

Pour ne pas me prendre la tête, je passe dorénavant par des fichiers de configuration tout prêts. Les données les plus importantes étant comme nous pouvons nous en douter les SANs¹³ (et là je ne parle pas stockage, bande de petits malins).

[req]
default_bits = 4096
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = req_ext

[dn]
C = FR
ST = France
L = MACON
O = RONELAB
CN = egapl-minio-01.ronelab.lan

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = egapl-minio-01.ronelab.lan
IP.1 = 10.127.252.250

Nous générons notre clé privée et notre certificat public avec notre bon vieux openssl des familles.

# openssl req -x509 -nodes -newkey rsa:4096 -days 3650 -keyout private.key -out public.crt -config openssl.cnf

Nous créons si ce n’est pas le cas le répertoire home de notre utilisateur de service dédié à MinIO (dans mon cas « minio »), et reste à déplacer les fichiers générés ainsi que l’attribution des permissions pour garantir un minimum de sécurité.

# mkdir -p /home/minio
# mkdir -p /home/minio/.minio
# mkdir -p /home/minio/.minio/certs

# mv public.crt /home/minio/.minio/certs/
# mv private.key /home/minio/.minio/certs/

# chown -R minio:minio /home/minio
# chown -R 700 /home/minio
# chown 600 /home/minio/.minio/certs/private.key
# chown 644 /home/minio/.minio/certs/public.crt

Ne reste alors plus qu’à restart notre daemon et avanti !

# systemctl restart minio

Une chose de plus en moins à réaliser. Passons à la suite. 🙂

Configuration Bucket

La première question est qu’est ce qu’un bucket ? Et je ne parle pas du saut de poulet spaghetti que l’on trouve à KFC M’sieurs Dames. Un peu de sérieux ! (Dixit le gars… C’est le camembert qui dit au curé qu’il est communiste ?)

Un bucket, est un conteneur logique qui va stocker des objets (fichiers et les métadatas). Si nous faisons une comparaison avec un système de fichiers classique nous aurions :

Chaque bucket a sa propre configuration comme :

• Les droits d’accès
• Le chiffrement des objets qui le compose
• Le versionning
• Les règles de cycle de vie (suppression, archivage etc)

Là où nous allons devoir être vigilants va se trouver sur la méthode de création du bucket. En GUI¹⁴ et CLI¹⁵, nous n’avons pas les mêmes options et cela va avoir un impact sur certaines applications et dans mon cas un impact sur VEEAM.
Je ne présenterai que la partie CLI. La partie GUI, il faut RTFM¹⁶… 🙂

CLI

1 – Alias ou AKA

Avant de créer notre bucket il va être nécessaire de créer un alias.

# mc alias list
# mc alias set ronelab http://127.0.0.1:9000 adm.minio 'MyPassword_define_in_file'

2 – Bucket

Une fois notre alias défini nous allons pouvoir créer notre bucket pour VEEAM. Il est important de préciser l’argument -l.

L’argument signifie que ce bucket à l’ObjectLock d’activé. Ce qui va permettre de gérer l’immuabilité des données sur une durée définie.

# /usr/local/bin/mc mb -l ronelab/veeambucket

Nous pouvons également voir les statistiques liées à notre bucket ainsi que sa configuration.

# /usr/local/bin/mc stat ronelab/veeambucket

3 – Account Keys & Policy

# mc admin user add ronelab veeamuser 'MyVeeamPassword'

Définissons la politique qui va être attachée à notre utilisateur. Dans notre cas, les droits de lecture et écriture.

# mc admin policy attach ronelab readwrite --user veeamuser

Vérifions que tout est bon.

# mc admin user info ronelab veeamuser

L’utilisateur étant créé, nous pouvons générer notre clé d’accès qui servira plus tard à l’authentification de l’application VEEAM.

# mc admin user svcacct add ronelab veeam-minio

VEEAM

L’article à la base, je l’avais commencé sur VBR¹⁷ 12.1 courant 2024. Puis ayant dû me focaliser sur ma vie professionnelle et personnelle par la suite, je me dois de refaire l’intégralité de l’intégration sur VEEAM 13.0.X, et plus particulièrement sur la VSA¹⁸ 13.0.X <3

S3-Repository

Comme toujours avant de créer un job, il est nécessaire de passer par la phase d’ajout d’un nouveau backup repository.

Dans Backup Infrastructure, sélectionnez Backup Repositories et avec votre plus beau clic droit, choisissez Add… Le type de backup sera de nature Object storage. Il est important de choisir S3 Compatible puis de choisir de nouveau ce dernier (je pense que MinIO est en capacité de prendre en charge du S3 Glacier, mais dans le doute je ne vais pas m’avancer…).

Une fois cette étape passée, nous voilà enfin dans le Wizard pour configurer notre repo S3.

Honnêtement, rien ne change vraiment de l’ajout d’un repo classique mais je trouve toujours sympa d’illustrer mes actions. Cela me donne un côté sérieux. Toujours dans les limites de mon infra, j’ai limité le nombre de tâches parallèles à 1.

Le gros du travail se situe à l’étape 2 Account. Là en tant que service point, saisissez l’url de votre serveur https://egapl-minio-01.ronelab.lan:9000 [/!\ Attention : Je me suis encore fait avoir sur la capture d’écran… Le port pour l‘API S3 est 9000 et non 9001. A bon entendeur..]. Renseignez la location et complétez les credentials. Pour cette étape, lors de notre création en ligne de commande précédemment, les informations vous ont été retournées. Ce sont ces dernières qui sont attendues. Lorsque vous cliquerez sur suivant, dans le cas de certificat SSC¹⁹, il faudra accepter comme d’accoutumé le certificat.

La partie 3, Bucket est la dernière étape qui diffère d’un ajout classique. Il faudra choisir le bucket à partir du bouton Browse. Si par pur hasard vous obtenez un message d’erreur de la part de VEEAM c’est que vous avez surement utilisé le port 9001 et non 9000 :). Choisissez également le répertoire. Si aucun n’est présent, créez en un depuis le wizard. Il est important de comprendre que l’immuabilité est portée par VEEAM et non par MinIO. C’est pourquoi c’est à vous de cocher la fonctionnalité Immutability Settings et de définir la période d’immuabilitée.

Pour les autres étapes du Wizard, c’est de la rando. Je vous laisse poursuivre.

Une fois le wizard terminé, si nous regardons notre infrastructure, nous retrouvons bien notre nouveau repo 🙂 <3

Job Configuration

Pour la création du job, cela va être exactement la même chose que la création d’un job classique. Le seul point qui va diverger (Oh il a écrit verge… Okay cool…) va être le choix du repository S3, et c’est tout…

Toujours pour des problématiques d’infrastructures j’ai volontairement restreint la planification du job. De toute façon, l’Appliance va être archivé d’ici la fin de semaine donc OSEF j’ai envie de vous dire…

Notre job étant créé, place au test 🙂

Tests

Le test est plutôt simple, je vais lancer un job et tenter de supprimer ce dernier depuis la console VEEAM.

Début	Fin

La sauvegarde s’est bien déroulée, donc cela prouve qu’avec le durcissement ANSSI²⁰ et notre configuration de MinIO je n’ai pas fait de me**e. Regardons notre chaine de sauvegarde.

Si je choisis de supprimer le point, vais je pouvoir supprimer le backup ? La réponse est évidemment non mais nous nous devons de vérifier ce point.

J’ai envie d’écrire, la messe est dite. L’immuabilité fonctionne.

Je me suis posé la question comme pour la partie hardened de supprimer les données de mon serveur standalone. La réponse est évidemment oui si j’ai les droits root. Je peux démonter le disque ou supprimer son contenu. Toutefois, et c’est là que je n’ai pas les ressources, mais si c’était un ring je n’aurais pas pu.

J’ai mentionné plus haut que même une divinité ne peut supprimer les données c’est pourquoi je nuance mes écrits. Il sera toujours possible à l’utilisateur, que dis-je administrateur qui a tous les accès de supprimer les données.

Conclusion

Cet article fait partie des premiers que j’ai commencé à écrire en 2024 et puis je l’ai abandonné. Je pense par frustration à l’époque.

J’ai toujours défendu bec et ongle l’immuabilité hardened vis à vis de l’immuabilité S3. Pourtant il convient de reconnaitre de ma part que le Storage S3 offre plus de sécurité. Néanmoins je reste convaincue qu’un repo hardened répond très bien au ESN ayant aux moins deux sites et qui veulent arrêter de s’emm***er avec des rotations de disque dur externe (même si cela reste une solution viable et qui est toujours mieux que rien).

Dans les deux cas, je trouve bien la possibilité dans ces deux cas de pouvoir recycler des équipements (serveurs) considérés comme obsolètes pour des environnements de production pour les utiliser comme repo S3 standalone ou hardened.

Si je devais faire un choix ?

Je répondrai en politicien, avec ma plus belle langue de bois. Cela dépendra du contexte. 🙂 Il faut garder à l’esprit que le Hardened protège plus facilement des ransonmware, des erreurs humaines et des compromissions VEEAM. A l’inverse, S3 est plus adapté contre la suppression logique, la conformité réglementaire, les suppressions depuis VEEAM.

Toutefois, si j’avais continué ma carrière en ESN, j’implémenterais ce type de solution avec 3 nodes « obsolètes » sur le papier en conservant une extension de garantie des équipements et intégrerais MinIO au catalogue de service. Mais ça, c’est si j’étais toujours dans une ESN.

L’une des ouvertures et projet à venir serait de monter un ring sur 3 sites différents…

Finalement, c’est beau et bien de terminer un article plus de deux ans après… 🙂

Le mot de la fin :

Je range un cadeau dans MinIO, le S3 applaudit en IPv6, le bucket éternue, et ma théière me retourne une Error 418. Très joli coup. Vous passez en case Jacob Delafonte.

Erwan GUILLEMARD

Sources

• AMAZON S3
• Apps – VEEAM Repo & Backup Hardened
• LINUX – useradd Man
• MinIO – Install Guide
• MinIO – VEEAMBucket

1. SE : Système d’Exploitation ↩︎
2. S3 : Simple Storage Service ↩︎
3. GAFAM : Google Amazon Facebook Apple Microsoft ↩︎
4. WORM : Write Once Read Many ↩︎
5. SaaS : Software As A Service ↩︎
6. OS : Operating System ↩︎
7. NAT : Network Address Translation ↩︎
8. PAT : Port Address Translation ↩︎
9. RHEL : RedHat Entreprise Linux ↩︎
10. HTTP : HyperText Transfert Protocol ↩︎
11. PAT : Port Address Translation ↩︎
12. UTM : Unified Tread Management ↩︎
13. SAN : Subject Alternative Name ↩︎
14. GUI : Graphic User Interface ↩︎
15. CLI : Command Line Interface ↩︎
16. RTFM : Read The Fucking Manual ↩︎
17. VBR : Veeam Backup et Replication ↩︎
18. VSA : Veeam Software Appliance ↩︎
19. SSC : Self-Signed Certificat ↩︎
20. ANSSI : Agence National de Sécurité des Systèmes d’Informations ↩︎

Pourquoi ?

Parce que tout ou une grande partie à déjà été dit dans l’article traitant d’Ollama. J’avais jugé trop indigeste de fondre les deux sujets. Donc ici, la partie théorie sera plutôt courte et en conséquence la partie Pratique un peu plus étoffée concernant l’implémentation et la configuration de l’application.

Bref, l’objectif de cet article sera d’implémenter une interface graphique publiée pour faciliter l’usage de notre solution Ollama plurimodales (LLM¹) aux utilisateurs. J’ai pris le parti d’utiliser la solution OpenWebUI.

Avant-Propos

Vous l’avez bien compris, dans l’introduction, je n’ai pas l’attention de m’éterniser 10 000 ans sur le sujet.

Je pars du principe que nous avons déjà déployé et configuré la solution Ollama et quelques modèles de traitement IA² sur un serveur.

J’ai une nouvelle fois pris le parti de déployer l’application sous une distribution RHEL³ afin d’avoir un niveau de sécurité optimale. Toutefois et vous pourrez le constatez par la suite dans la partie théorie, je ne respecterai pas l’architecture par faute de ressource disponible néanmoins, je recommande de suivre l’architecture qui sera à venir.

Dans le cadre d’une solution d’IA hébergée localement se pose la question de mettre en place un tel portail dans une organisation. A cela je répondrai que cela permettra de garder un certain contrôle des requêtes, prompts, effectués par l’ensemble des utilisateurs de l’organisation et d’en faciliter les usages. Dans des domaines sensibles tels que l’industrie et production cela peut aux yeux de la direction et de la DSI⁴ se révéler rassurant.

Prérequis

• SE :
  • Rocky Linux 9.x et version ultérieures (pour ma part ça sera du 10.x)
  • macOS
  • Windows
• Apps : 
  • Ollama
• Autres :
  • Minimum 4 CPU⁵
  • Minimum 4 Gio de RAM⁶
  • Stockage rapide (SSD⁷ ou Nvme)

Théorie

KesaKo OpenWebUI

Je pense comme toujours qu’il est important de se poser la traditionnelle question. Que fait l’application que nous allons utiliser, comment elle fonctionne et qui est derrière.

Qu’est-ce que c’est ?

OpenWebUI, c’est une interface web issue d’une projet open-source (#biscotto) qui permet d’utiliser des modèles d’IA depuis un navigateur WEB hébergé localement.

Le projet est né du sud-coréen Tim Jaeryang BAEK qui prône l’autonomie numérique face aux grands du monde de la tech. Le projet est développé en Python (version supérieur ou égale à 3.11) pour la partie BackEnd et HTML/CSS, Svelte, JS et TS pour la partie FrontEnd.

Personnellement, je trouve que l’interface ressemble fortement à celle de ChatGPT. Mais son mon avis personnel hein 🙂

A quoi ça sert ?

La solution va permettre comme les outils classiques en ligne (pour ne pas dire les géants du Cloud) d’effectuer des opérations (énumération en approche) :

• Discuter avec des modèles d’IA (LLM)
• Exploiter des modèles localement (LLM)
• S’Interfacer avec des sources locales et clouds (et oui nous pouvons faire de l’hybridation).
• Téléverser (waouh, tu n’as pas écrit uploader !) des fichiers pour les analyser par l’IA

Nous retrouvons donc dans l’ensemble les mêmes fonctionnalités que les outils en ligne quant à l’usage de l’IA 🙂 C’est cool non ? <3

Avantages / Inconvénients

L’utilisation d’OpenWebUI n’est pas sans conséquences vis à vis des services qu’il peut apporter.

Il suffit de regarder le constat déjà porté sur l’utilisation d’Ollama.

Bon, cela je vous dirai l’utilisateur il s’en tamponne le coquillard. Lui que ce soit technique à mettre en place, il s’en lustre l’asperge. Par contre, si la réponse est lente, c’est le Game Over.

Logique, pourquoi utiliser la solution locale qui met une plombe à répondre alors qu’un bon vieux Gémini, Copilot, ChatGPT te donne la réponse en 1/4 de seconde après une petite pression sur la touche Enter du clavier ?

Ce qui nous ramène selon moi à l’un des plus grands maux de la société actuelle. Nous ne savons ce que signifie attendre et être patient. Si dans les années 60 la compilation d’un programme pouvait prendre la nuit, aujourd’hui cela prendra quelques minutes. L’essor des nouvelles technologies, nous apportent de par les performances et leurs mobilités l’informations et l’assurance de pouvoir joindre un individu ou une ressource si quand bien même nous avons du réseau. Toutefois, force est de constaté que si comme cela s’est passé plusieurs fois au cours de l’année 2025 et 2026 l’un des maillons qui assure le fonctionnement tombe et nous coupe de nos ressources, nous nous retrouvons comme une poule qui a trouvé un couteau. Je pense et cela n’est qu’un point de vue personnel que nous devrions nous remettre en question face à cette forme de dépendance et servitude, Master & Servant, je dis STOP ! #sendkissesagain

Architecture & Best Pratices

Lors de la présentation de la solution, j’ai introduit la possibilité d’utiliser OpenWebUI en mode hybride. Ce qui implique donc une communication des flux sortants via les protocoles HTTP⁹ et HTTPS¹⁰ vers les IAs compatibles dans le cloud et autres repos propres au SE¹¹ et maintien de l’application. Afin de ne pas surcharger inutilement le schéma, j’ai totalement exclu cette partie. Néanmoins il conviendra de réaliser un filtrage strict en sortie des flux pour des raisons de sécurité. Donc de jouer avec les politiques de votre UTMs¹².

Bien, rentrons concrètement dans l’architecture. La solution applicative OpenWebUI vient se placer entre le poste client et l’application Ollama.

Il convient dans le respect des bonnes pratiques de dissocier OpenWebUI de Ollama puisque nous allons publier, ouvrir l’application en interne et pourquoi pas depuis nos WANs¹³. Cela implique de mettre OpenWebUI dans un réseau isolé (DMZ¹⁴) et Ollama dans le réseau T1, T1′ par exemple.

Par défaut, dans un fonctionnement UNIX dans un déploiement hors Docker, le port de communication de l’interface Web se fait via le protocole http sur le port 8080. Il est néanmoins possible de forcer les connexions en https sur le port 443 via nginx (je reviendrai plus en détail sur ce point).

Si nous regardons d’un peu plus près l’architecture de la VM¹⁵, nous pouvons constater que j’ai dédié un disque. Mais pourquoi ?

OpenWebUI est très très lourd. Son déploiement peut se révéler un poil pénible pour ne pas dire chiant à mourir (je reviendrai là-dessus dans la partie pratique).

Bref, pour pallier à ce problème, j’ai dédié un disque d’une capacité de 100 Gio.

Bien, on se lance dans la pratique ? Après on est bien aussi ici 🙂

Pratique

Oui j’ai dit plus haut que je ne respecterai pas cette topologie. Par manque de ressource, je vais tailler à la hussarde et tout mutualiser sur une seule machine. Il faut bien faire avec les moyens que l’on a, c’est comme ça.

Installation

OpenWebUI propose plusieurs modes de déploiement :

• Docker : Officiellement supporté et recommandé pour la plupart des utilisateurs (avec plusieurs sous-catégorie alternatives de déploiement)
• Python : Orienté pour les environnements faibles en ressources et pour une installation manuelle
  • uv
  • conda
  • venv
• Kubernetes : Idéal pour les déploiements en entreprise qui nécessite une adaptabilité et ordonnancement
  • Helm
• Third Party

Pour ma part, la seule chose qui m’intéresse et pour laquelle je suis à peu près à l’aise c’est Python. Je vois déjà les puristes de la containerisation me rétorquer sauvagement « Pourquoi pas Docker ?« . Encore une fois et je suis désolé, je ne comprends pas l’intérêt de Docker dans mon métier. Tant que je n’aurai pas pleinement assimilé ou eu le besoin de l’utilisé, je bloque. Attention, je ne dis pas que c’est de la me*de hein ? Loin de moi l’idée.

Donc je partirai sur Python en environnement virtuel (venv).

Pourquoi ce choix ? Simplement parce que RHEL utilise également Python dans une version différente et qu’à ce jour la version 3.12 n’est pas encore officiellement supporté par OpenWebUI… Rien que pour ça je déteste Python autant que Java. Pourquoi faire simple…

Création de l’environnement virtuel

Dans mon répertoire ollama, j’ai créé un second répertoire openwebui.

$ sudo mkdir -p /mnt/ollama/openwebui
$ sudo cd /mnt/ollama/openwebui/

Une fois déplacé dans le répertoire, nous créons l’environnement virtuel venv. Original comme nom n’est il pas ?

$ sudo python3 -m venv venv

Activation de l’environnement virtuel

Etant toujours dans le même répertoire créé précédemment, nous allons activer notre environnement virtuel.

$ sudo source venv/bin/activate

Installation

Maintenant que tout est bon, il est toujours dans notre environnement virtuel de démarrer l’installation. Cette dernière se déroulera en 3 temps.

• La mise à jour de pip
• La création d’un répertoire temporaire pour stocker les sources de l’installation qui sont plutôt volumineuse
• L’installation en faisant référence à notre répertoire temporaire

Simple comme bonjour, et pourtant sachez que je me suis bien cassé la tête pour trouver l’astuce du répertoire temporaire…

$ sudo pip install --upgrade pip 
$ sudo mkdir /mnt/ollama/tmp
$ sudo TMPDIR=/mnt/ollama/tmp pip install open-webui

Lors de l’installation si comme moi vous avez des ressources limitées, aucun respect des préconisations matériels. Je vous recommande de tuer le temps pendant facile une heure et de laisser tranquille votre bécanne. Tiens, je reparle de patience, comme de par hasard 🙂

Sans hésitez, la réponse D Jean-Pierre, ça sera mon dernier goulot.

Blague mise à part, 291 packages à installer avec des grosses dépendances pour certains d’entre eux (Nvidia par exemple…). Reprenez un peu de la réponse D en attendant.

Toujours pas terminé ? Bon ba comme on dit j’ai nous « On va pas la mécher [la bouteille naturellement] », terminez là et allez en chercher une nouvelle pour poursuivre la connaissance de la réponse D.

Démarrage

Si vous n’êtes pas tombé et que vous n’êtes plus très sobre, c’est bon signe. 🙂 Normalement, l’installation est terminée.

/!\Attention :L’abus des bons produits et notamment d’alcool est dangereux pour la santé. (Que l’on n’aille pas dire que je fasse de la publicité ou l’apologie de l’alcool #loievin)

Vérifions que cela fonctionne avec la première commande.

$ sudo open-webui --help

C’est rassurant de se dire que cela fonctionne. Pas de message d’erreur. Il ne nous reste maintenant plus qu’à démarrer notre service sur son interface et son port avec la commande ci-dessous.

$ sudo open-webui serve --host 10.227.250.11 --port 8080

Toutefois, il conviendra d’autoriser les flux au niveau de l’UTM local à notre serveur en amont. Pour cela, j’explique dans la partie suivante Configuration comment ouvrir les flux http sur le port 8080/tcp.

Normalement, l’ensemble des composants sont en cours de chargement et une fois l’ensemble chargé, vous devriez avoir dans votre CLI¹⁶ la chose suivante.

Il est à noter que des notes d’informations vont vite prendre le relai, ces derniers affichant l’ensemble des requêtes HTTP.

Si nous sommes à ce stade c’est que tout est bon 🙂 Avant de rentrer plus en détail de l’outil, il est nécessaire de regarder la partie Configuration.

Configuration

Cette partie pourrait je pense être amélioré. L’un des points les plus complexes et de mettre en place le mode service (j’y ai passé un temps certain…).

Utilisateur dédié

Pour des raisons de sécurité, il convient de créer un utilisateur dédié pour notre application. Nous partons sur un compte de service et non un compte utilisateur.

$ sudo useradd -r -s /bin/false openwebui
$ sudo chown -R openwebui:openwebui /mnt/ollama/openwebui

Un petit changement de propriétaire et le tour est joué.

ParFeu

Par défaut, le port qui sera utilisé pour accéder à l’interface web d’OpenWebUI est 8080/tcp en http.

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

On est d’accord que si nous souhaiterions mieux faire en termes de sécurité, il serait plus intelligent de créer la policy suivante :

$ sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.127.50.0/24" port port="8080" protocol="tcp" accept'
$ sudo firewall-cmd --reload

Ayant un UTM en amont, je me permets donc de me contenter de la première solution.

Un petit test de vérification depuis le poste source :

Mode Service

Commençons par créer notre fichier de service. La difficulté que j’ai rencontrée ici est de jouer avec l’environnement virtuel et le service OpenWebUI à démarrer. J’ai bien trouvé une solution de contournement à mon problème toutefois cela me laisse un gout amer car la solution ne me semble pas propre du tout.

C’est je pense l’un des points qui me frustre le plus dans le monde du libre, l’imbrication de solution tierce et dans un sens une non-standardisation des méthodes d’implémentations. Bien que je doive le reconnaitre c’est ce qui fait tout son charme. Je t’aime moi non plus. On se croirait dans Andromaque…

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

Regardons d’un peu plus près le contenu de ce fichier. Nous retrouvons la description de notre service ainsi que son ordre de démarrage. OpenWebUI étant intimement lié à Ollama, il convient donc de définir ce dernier comme service requis. Au niveau du service, nous sommes sur un type simple, le service étant exécuter par l’utilisateur dédié openwebui. Il peut être acceptable bien que s’est sacrément cochon d’utiliser le compte root. Mais bon nous voulons éviter de faire étalage de notre amateurisme. WorkingDirectory représente le répertoire de travail dans lequel le programme sera exécuté. Environment permet de définir les variables d’environnement. ExecStart permet d’exécuter la commande. Dans mon cas, j’en ai deux dont une qui est commentée (et qui ne fonctionne pas). Restart permet de définir le rédémarrage automatique dans le cas où le service viendrait à crash par exemple. RestartSec défini le délai de redémarrage en seconde. Et pour finir, WantedBy pour spécifier le mode de service. Ici cela équivaut au mode normal.

[Unit] Description=Open WebUI Service After=network.target ollama.service Requires=ollama.service [Service] Type=simple User=openwebui WorkingDirectory=/mnt/ollama/openwebui Environment="TMPDIR=/mnt/ollama/tmp" Environment="PATH=/mnt/ollama/openwebui/venv/bin:/usr/bin:/usr/sbin" #ExecStart=/mnt/ollama/openwebui/venv/bin/open-webui serve --host 10.227.250.11 --port 8080 ExecStart=/bin/bash -c 'source /mnt/ollama/openwebui/venv/bin/activate && open-webui serve --host 10.227.250.11 --port 8080' Restart=always RestartSec=5 [Install] WantedBy=multi-user.target

Comme nous venons de créer un nouveau service, il sera nécessaire de recharger l’ensemble du systemctl pour intégrer le nouveau service à la liste des services disponible. Après, j’ai envie de dire c’est le schéma classique d’activation, démarrage et vérification.

$ sudo systemctl daemon-reload
$ sudo systemctl enable openwebui
$ sudo systemctl start openwebui
$ sudo systemctl status openwebui

Nginx, HTTPS

Je suis partagé quant à la rédaction de cette sous partie. Oui il est important de sécuriser l’accès à l’interface Web, mais j’ai peur d’être hors sujet et d’alourdir l’article. Mais d’un autre côté, je ne veux pas non plus bâcler la chose… Encore un pu**n de choix cornélien…

Bref, je vais faire au plus simple et si besoin écrirai un billet sur Nginx.

Installation

L’installation et activation du service, je passe mon tour.

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

Certificats

Là encore une fois je rencontre un petit problème. Je n’ai pas de certificat public que je pourrais utiliser, ma topologie réseau ne me permet pas d’utiliser un certificat Let’s Encrypt et sans vouloir spoiler je n’ai pas envie de me prendre la tête. Donc ça va finir avec un bon vieux certificat autosigné 🙂

La génération n’est pas bien compliquée et si besoin, j’ai déjà rédigé un article sur le sujet.

Créons le répertoire qui va contenir nos éléments de sécurité :

$ sudo mkdir -p /etc/nginx/ssl

Générons notre certificat :

$ sudo openssl req req -x509 -nodes -days 365 \
-newkey rsa:2048 \
-keyout /etc/nginx/ssl/openwebui.key \
-out /etc/nginx/ssl/openwebui.crt

Configuration

Créons et éditons notre fichier de configuration. Je prendrai le temps d’expliquer l’intégralité du fichier de configuration.

$ sudo vim /etc/nginx/conf.d/openwebui.conf

server {
    listen 80;
    server_name 10.227.250.11;

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

server {
    listen 443 ssl http2;
    server_name 10.227.250.11;

    ssl_certificate /etc/nginx/ssl/openwebui.crt;
    ssl_certificate_key /etc/nginx/ssl/openwebui.key;

    # 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;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";

    # taille upload
    client_max_body_size 100M;

    # compression
    gzip on;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml;

    location / {

        proxy_pass http://10.227.250.11:8080;

        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;

        # WebSocket support (important OpenWebUI)
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        proxy_read_timeout 3600;
        proxy_send_timeout 3600;
    }
}

La première section permet de réaliser la redirection du protocole HTTP vers HTTPS de manière permanente. Ainsi si je contacte l’url http://10.227.250.11, je serais automatiquement redirigé vers https://10.227.254.11.
Le second bloc indique que nous écoutons sur le port 443 sur l’interface 10.227.250.11. L’emplacement des fichiers contenant la clé privée ainsi que le certificat sont spécifiés pour activer la couche de sécurité (j’ai l’impression d’enfoncer des portes ouvertes…). J’indique qu’elles sont les versions des protocoles TLS17 autorisées et laisse le serveur choisir le chiffrement le plus sûr. Côté en-tête, j’ai repris les suggestions de sécurité implémentée pour ITOP. Soit la restriction de mettre le site en iframe externe, de restreindre le navigateur à deviner le tye MIME qui est utilisé et surtout d’activer la protection anti-cross-site scripting. Niveau upload, j’ai vu large et j’ai autorisé le téléversement de fichier de 100 Mio. Côté performance, j’ai activé la compression des flux pour optimiser un peu les performances réseaux.
Le troisième bloc concerne la partie Reverse Proxy. Toutes les requêtes qui sont envoyées sur https://10.227.250.11 sont redirigées vers le port 8080. Concernant les en-têtes il est nécessaire d’utiliser les websockets car seront transmis l’ip du client, le protocole utilisé et le NDD18 ou l’IP demandé. Les deux lignes suivantes permettent de réaliser la jonction entre nginx et les websockets.

Une fois la configuration faite, il est important de réaliser un petit contrôle de notre petit fichier afin de s’assurer que ce dernier ne comporte pas d’erreur.

$ sudo nginx -t 

Il faudra penser à recharger la configuration et hop le tour est joué.

Sécurité

Nous souhaitons toujours publier notre interface web en HTTPS. Donc il va falloir jouer avec nos UTMs !

Sur le plan interne, autorisons nos flux https :

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

Nous pourrions comme énoncé plus haut pour le protocole HTTP être bien plus rigoureux dans notre règle de sécurité. Mais encore une fois ayant un UTM en amont, j’accepte le risque. Juste ne pas oublier de créer la règle sinon vous passez pour un c*n.

Si nous sommes joueurs, nous pouvons essayer de joindre directement notre interface web depuis notre navigateur. Normalement vous devez vous prendre dans les dents

Ca vous fait la b**e hein ? Je vous rassure je me suis pris la même rouste. J’ai oublié d’autoriser le contexte de mon SELinux pour autoriser les services http à accéder aux réseaux 😀

$ sudo setsebool -P httpd_can_network_connect 1

Un petit F5 et hop c’est tout bon <3

Normalement avec toutes nos actions, nous devons joindre notre interface web depuis un navigateur de manière sécurisée (hormis l’erreur liée à notre certificat autosigné). Allez, on passe à la partie démonstration ?

Démonstration

Pour le test, j’ai décidé de changer un peu de format et de passer par des formats vidéo. Surtout que dans ce cas précis, cela évitera de mon côté de blablater. Cependant, ce n’est pas pour autant que le travail est plus simple ou plus rapide.

J’ai également pris le parti de commenter mes enregistrements et vidéos en anglais (oui même avec mon anglais aussi rouillé qu’une vieille cantine de bidasse, si vous voulez trikitez mes vidéos je vous laisse ce plaisir 🙂 ).

Conclusion

La combinaison des solutions OpenWebUI et Ollama fonctionne à la perfection. Si nous associons le côté multimodèle d’Ollama et son fonctionnement hybride avec la puissance de l’interface OpenWebUI il est alors possible de fournir une solution complète à destination des utilisateurs.

Toutefois, je reste profondément frustré pour l’instant. L’ajout de la couche OpenWebUI vient rallentir et allourdir l’usage d’Ollama. D’un autre côté, est ce vraiment pertinent comme remarque à savoir que je ne réponds à aucun prérequis matériel ? C’est là où le bât blesse encore une fois. Cela fonctionne mais à quel prix ?

Il est également important de prendre en compte les couts annexes et variables (comme au hasard, la consommation électrique, refroidissement…) périphériques à l’usage de l’IA. Nous parlons du réchauffement climatique, de limiter nos émissions de carbone et j’en passe pour d’un autre côté user de l’IA à tort ou à raison. Je ne tiens pas à lancer un débat climatosceptique ou sur est-ce bien ou non d’utiliser l’IA.

Je pense simplement qu’il y a encore beaucoup à faire pour accorder en synergie la puissance et l’usage de l’IA avec les convictions écologiques et environnementales. Si nous être vivant allons avoir chaud, que dire des CPUs/GPUs ? #tousdanslemêmebateau Bref, un moratoire serait nécessaire en somme. Mais je laisse ça au pisse violon que je suis.

Je reste convaincu de la fiabilité et viabilité de la solution dans un milieu professionnel, malheureusement, pour moi je préfère me passer de l’interface Web. Donc en d’autres termes, je vais rollback mon snapshot (ou restaurer mon backup au choix). Après tout, je peux toujours utiliser l’interface CLI directement depuis une session SSH¹⁹ ? Oui mais pas que.

Pourquoi ne pas faire une petite interface qui exploite l’API Ollama ?

Ah nous y voila ! Ca sent le projet long comme un jour sans pain encore en approche. Blague mis à part, peut être que cela n’aboutira pas. Mais j’ai envie de pousser relativement loin la solution Ollama.

Pour faire vraiment simple. OpenWebUI c’est supercool mais il faut les ressources pour pouvoir l’utiliser pleinement pour ne pas souffrir d’une grande frustration. 🙂

Le mot de la fin :

Je branche OpenWebUI sur une prise RJ45 en camembert ! Je contre avec un lama qui compile une girafe. Vous ne pouvez pas, il y a Sandrine ROUSSEAU au festival de la tête de veau.

Erwan GUILLEMARD

Sources

• OpenWebUI : Quick Started

1. LLM : Large Language Models ↩︎
2. IA : Intelligence Artificielle ↩︎
3. RHEL : RedHat Entreprise Linux ↩︎
4. DSI : Direction des Services Informatiques ↩︎
5. CPU : Central Processing Unit ↩︎
6. RAM : Random Access Memory ↩︎
7. SSD : Solid State Drive ↩︎
8. GPU : Graphics Processing Unit ↩︎
9. HTTP : Hypertext Transfer Protocol ↩︎
10. HTTPS : Hypertext Transfer Protocol Secure ↩︎
11. SE : Système d’Exploitation ↩︎
12. UTM : Unified Threat Management ↩︎
13. WAN : Wide Area Network ↩︎
14. DMZ : DeMilitarized Zone ↩︎
15. VM : Virtual Machine ↩︎
16. CLI : Command Line Interface ↩︎
17. TLS : Transport Layer Security ↩︎
18. NDD : Nom De Domaine ↩︎
19. SSH : Secure SHell ↩︎

Robot : nom masculin, du tchèque robota, travail forcé, mot créé en 1920 par K. Capek.

Dans les œuvres de science-fiction, machine à l’aspect humain, capable de se mouvoir, d’exécuter des opérations, de parler.

Appareil automatique capable de manipuler des objets ou d’exécuter des opérations selon un programme fixe, modifiable ou adaptable.

Définition Larousse

Au vu du titre de cet article et de la définition posée précédemment, difficile de ne pas deviner le sujet qui va être abordé.

Hé oui, moi le puriste, je vais parler d’IA¹ et pire que cela l’utiliser de manière récurrente. Je me sens en ce moment comme le capitaine Haddock face au lama dans l’œuvre d’Hergé, Tintin et le temple du soleil.

Naturellement, au vu de mes précédents écrits, c’est vous lecteurs et l’ensemble des solutions IA qui me crachent dessus. C’est l’arroseur arrosé en somme, moi qui ne voulais pas entendre parler de ça…

Mais alors pourquoi un tel revirement de situation M’sieur GUILLEMARD ?

Je pense qu’il faut vivre avec son temps et ignorer cet outil technologique serait signer mon arrêt de mon mort d’ici quelques années et devenir un être never been à défaut d’has been…

Après tout Errare humanum est, perseverare diabolicum² non ?

Avant-Propos

J’ai pris le parti d’être méfiant vis à vis des outils d’IA en ligne gratuit ou du moins libre d’utilisation.

• ChatGPT
• Gemini
• Copilot
• Claude
• …

Je ne me mouille pas trop dans les moteurs d’IA…

Dire que je n’ai jamais utilisé l’un de ces moteurs serait me parjurer et il faut reconnaitre qu’il y a un côté pratique. Difficile une fois avoir gouter à la simplicité pour ne pas l’utiliser à tout va pour tout et rien. C’est là pour moi le piège de la pauvreté intellectuelle. Comme toutes les bonnes choses il faut savoir ne pas en abuser.

En dehors de l’aspect social et sociétal qui me préoccupe tant, se pose la question des données saisies dans le moteur de recherche ou plutôt de prompt.

• Que deviennent les données saisies ?
• Que deviennent les données retournées ?
• Combien de temps sont conservés ces données ?
• A qui profitent ces données ?
• Qui sur surveillent les données ?

Cela fait un bon nombre de question non ? Surtout qu’un grand nombre des acteurs de l’IA sont aux US, Chine etc avec une législation bien singulière. Qui de nos jours lis encore les CGUs³ (et qui les a déjà lus) ?

C’est ainsi que grâce à mon directeur j’ai découvert la solution OLLAMA. Solution open-source qui exécute des modèles d’intelligence artificielle (aussi appelé LLM⁴) localement. Tout de suite, le projet m’a séduit et je me suis demandé

Et pourquoi pas ?

Dans le pire des cas, je mourrai moins c*n ce soir comme dirait un philosophe du cercle familial.

Naturellement, j’ai choisi d’user de OLLAMA sur ma distribution favorite RockyLinux. L’environnement a été préalablement durci.

On se lance dans la théorie puis dans la pratique mes petits Lamas ?

Prérequis

• SE :
  • Rocky Linux 9.x et version ultérieures (pour ma part ça sera du 10.x)
  • macOS
  • Windows
• Apps : 
  • Ollama
• Autres :
  • GPU⁵
  • Minimum 4 CPU⁶
  • Stockage rapide (SSD⁷ ou Nvme)

Théorie

Je vais essayer d’être le moins rassoir possible. Toutefois et encore il est nécessaire d’où nous partons pour en être là maintenant avec l’IA.

Un peu d’histoire

La notion d’intelligence artificielle vient de loin dans notre histoire, puisque l’homme depuis l’antiquité rêve d’objets animés intelligents qui pourraient répondre à ces besoins.

Ce qui est fascinant ce trouve dans les différentes cultures à travers les âges. Que ce soit :

• Les automates d’Héphaïstos dans la mythologie grecque
• La tentation de créé l’Homme servi par l’alchimie aux moyen âge comme la science Talkim du grand savant islamique Jabir ibn Hayyan (Geber en latin), des homoculus par le médecin suisse de conviction chrétienne Paracelse qui s’inspirera des travaux de Zosime de Panopolis sans oublier l’un des plus connue de tous ces automates, le Golem d’argile présent dans le Talmud du judaïsme, créé par le rabbin Maharal pour protéger la communauté juive de Prague face aux multiples pogroms (j’ai d’ailleurs eu la possibilité de visiter le cimetière juif de Prague et de comprendre tout cela).
• Plus tard, nous retrouverons des œuvres telles que
  • Les Aventures de Pinocchio de Carlo Collodi avant d’être adapté en dessin animé par Disney
  • Frankenstein de Mary Shelley
  • Ou encore Deep Blue qui viendra à bout de Garry Kasparov aux échecs.

Bref, tout cela pour dire que depuis l’origine de l’humanité, nous Homme recherchons à créer des objets autonomes et intelligents à notre services. Pour de multiples raisons, défensives, assistanat etc. Le plus troublant, cette pensée de création pourtant contre religieuse et présente dans toutes les cultures et religions portées par ces savants et lettrés (et ça, voyez-vous je trouve ça beau, très beau).

Enfin, il faudra attendre le XXème siècle et l’arrivée des premiers ordinateur programmable pour que l’IA se développe pleinement.

C’est le pionnier et j’oserai dire le père de l’IA John McCarthy qui ouvre la voie, notamment par cette citation :

C’est la science et l’ingénierie de la fabrication de machines intelligentes, en particulier de programmes informatiques intelligents. Elle est liée à la tâche similaire qui consiste à utiliser des ordinateurs pour comprendre l’intelligence humaine, mais l’IA ne doit pas se limiter aux méthodes qui sont biologiquement observables.

John McCarthy – Wikipédia

Le sujet étant réellement complexe, il est difficile de concrétiser et de répondre aux attentes des investissements privés et étatiques durant la période 70 à 80. Ce qui vaudra un ralentissement dans la rechercher et la montée en puissance de l’IA que nous connaissons ce jour en 2026. Et pourtant les théories et grands principes mathématiques et logiques sont établis et adopté par la DARPA⁸. C’est ainsi que s’affronte deux grands systèmes :

Le système logiciste VS Le système neuronale

C’est en 2010, que l’IA fait réellement son entrée dans nos vies du quotidien et dans les différents secteurs d’activités.

Pour entrer davantage dans le détail je vous invite à lire la page wikipédia (cf les sources). J’ai promis de faire court. 🙂

Les modèles d’IA

Les modèles d’IA, c’est un peu comme un oignon, il y plusieurs couches.

Déjà il est important de dissocier le Machine Learning du Deep Learning.

Machine Learning

Le process pourrait se décrire de la manière suivante :

• Phase 1 : Identifier les mots clés fournit en entrée les plus pertinents afin de préparer ces derniers à être analysé. Nous parlons généralement de datasets.
• Phase 2 : Choisir le bon modèle ou algorithme qui sera le plus pertinent à être utilisé selon l’identification des datasets identifiés et analysés.
• Phase 3 : Construire le modèle d’analyse basé sur l’algorithme choisie lors de l’étape précédente.
• Phase 4 : Jouer le modèle sur un ensemble de jeux de données afin d’obtenir plusieurs jeux de données.
• Phase 5 : Utiliser le modèle pour attribuer une note à l’ensemble des jeux de données retournés et fournier des patterns pertinents adaptés aux datasets initiaux.

Deep Learning

Le process pourrait se décrire de la manière suivante :

• Phase 1 : Comprendre le contexte présenté par l’utilisateur et décider ou non si le Deep Learning est nécessaire ou non.
• Phase 2 : Identifier les mots clés fournit en entrée les plus pertinents afin de préparer ces derniers à être analysé. Nous parlons généralement de datasets.
• Phase 3 : Choisir le bon modèle ou algorithme qui sera le plus pertinent à être utilisé selon l’identification des datasets identifiés et analysés.
• Phase 4 : Jouer le modèle sur un ensemble de jeux de données afin d’obtenir plusieurs jeux de données.
• Phase 5 : Compare le modèle ainsi que ces performances face aux données existantes identifiés ou non identifiées avec notre contexte initial.

Pour le comprendre au mieux, il convient de reprendre le Diagramm de Venn pour comprendre comment s’imbriquent ces différentes notions d’apprentissage.

IA : a pour objectif de comprendre le langage humain, de réaliser les analyses prédictives offrir une IHM9 et AGI10. Machine Learning : se compose de l’apprentissage automatique, la clustérisassions, les arbres décisionnels, le SVM11, LLM et NLP12. Réseaux Neuronales : comprend les RAG13 / Finetuning ainsi que les Feed Forward. Deep Learning

Bien que rapide dans la présentation, de ce qu’est l’IA, je pense que nous avons suffisamment d’éléments pour aborder les différents types d’IA.

Toutefois, je suis loin d’être spécialiste de l’IA et mes connaissances théoriques remontent de mes cours de 2014 et de ce que j’ai pu lire et apprendre depuis ces dernières semaines. Je vous invite donc à lire plus en détails son fonctionnement en profondeur.

Bon allez ça sera tout pour l’instant. Regardons de plus prêt Ollama. 🙂

Architecture et Best-Pratices

Ollama étant cross plateform, j’ai pris le parti de déployer ce dernier sous RHEL. Donc le guide va suivre dans ce sens. Ce choix est motivé par mes soins pour garder une meilleure maitrise des ressources qui vont être consommées par le système. Pour MacOS, je ne me prononce pas car je n’utilise pas ce dernier. Sous Windows, je voyais déjà mon petite dernier faire du rodéo sur l’hyperviseur qui gambade dans le couloir au premier prompt soumis… 🙂

Comme énoncé ci-haut, il faut au minimum en ressource : * 4 vCPUs * 16 Gio de RAM * 2 Gio de GPU * Stockage Rapide Malheureusement pour moi, je n’ai pas les ressources nécessaires, mais cela ne m’empêchera pas d’aller au bout des choses. Je propose toutefois de dissocier les modèles et une partie de l’architecture OLLAMA sur un disque dédié pour des raisons de performances lors de la soumissions des prompts et ne pas saturer le disque système. L’accès à l’application se fera par des call API14 sur le port 11434/tcp.

Si nous voulions aller plus loin il serait bien de dédié un disque pour les logs et ainsi améliorer les performances.

Niveau sécurité, je suis resté sur mon durcissement classique et divulgâchage alerte ça fonctionne (Jacques TOUBON, le retour aurait été fier de moi pour ce coup-là !).

Je ne vois plus qu’un dernier point à aborder et nous pouvons passer à la pratique. Oui comme toute bonne chose, il faut faire durer le plaisir. #sendkisses

Conséquences de l’IA

L’IA est à ce jour (2025) adopté par environ 2/3 de la population mondiale que ce soit à des fins professionnels ou personnels dont environ 73% dans le contexte pro. Ainsi, difficile de nier que l’usage particulier et bien au-dessus des institutions organisationnelles.

Comme énoncé bien plus tôt dans cette partie, l’usage est principalement à destination des centres de services et à destination des utilisateurs (chatbots, service clients) 60%, l’automatisation des ventes et marketings 13%, l’optimisation des systèmes IT 9%, l’aide à la décision entre 5 et 10% et la production de contenu entre 5 et 10% également. Bien que mes chiffres date de 2023-2024.

Dans son usage concrets, l’IA est utilisée à 46% pour la recherche d’informations, 43% pour la rédaction de textes et 33% pour de l’analyse ou traduction.

Les estimations à venir d’ici 2030 seraient un usage de l’IA par 80 à 85% de la population mondiale. Cette escalade et course n’est pas sans conséquence sur le plan économique et disponibilité des ressources en termes de composants électroniques.

Qui dit plus d’usage, dit plus de ressource de calcul et donc plus de composants et plus d’énergie. Le système peine à suivre. C’est ainsi qu’en moyenne, l’évolution des couts entre 2024 et 2026 (estimé sur le plan mondial) et de :

• RAM (DDR5) : +170 à +250 %
• SSD : +60 à +100 %
• GPU : +10 à 25 %
• CPU : +0% à +10%

Cela entraine donc une hausse des offres Cloud et service SaaS/IaaS/PaaS/BaaS et j’en passe ainsi que des couts équipements embarquant ce type de composants. Difficile de faire sans IA de nos jours.

Bon c’est promis, passe à la pratique, je ferme la parenthèse que je n’ai jamais ouverte.

Pratique

Avant de se lancer dans l’installation, si je reprends les prérequis énoncés ci-haut, sachez que :

• Je n’ai pas de GPU
• Je n’ai pas de stockage rapide
• Mon hypervisieur est monoprocesseur

Tout pour bien fonctionner en somme 🙂

Installation

L’installation va se dérouler en 2 parties. Une partie pour installer Ollama, une partie pour l’installation des modèles d’intelligence artificielle.

Ollama

Installation

La documentation fournit sur le site est simple et claire. Il suffit alors de télécharger et d’exécuter le contenu du script install.sh.

Vérifier en amont que le paquet zstd est installé sur notre environnement.

$ sudo dnf install zstd

Si nous rentrons plus en détail, les arguments :

• -f : ignore les redirections en cas de retour autre que le code 200 du protocole HTTP¹⁵
• -s : supprime la barre de suppression et rend l’exécution de la commande silencieuse
• -S : indique les erreurs
• -L : permet de suivre les redirections HTTP

$ sudo curl -fsSL https://ollama.com/install.sh | sh

L’installation c’est bien passée. Toutefois, le script nous informe qu’aucun équipement GPU n’a été détecter et donc que les calculs seront effectués par notre CPU. Ce qui va donc être plutôt lent dans mon cas personnel.

Service au démarrage

Nous retrouvons une commande maintenant bien connue dans les environnements RHEL. Ainsi à chaque démarrage de notre système notre daemon ollama va être démarré.

$ sudo systemctl enable ollama

Firewalling

Encore une fois et comme toujours, il est nécessaire d’ouvrir le port 11434/tcp si nous souhaitons joindre l’API depuis l’extérieur (comprendre hors localhost).

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

On est d’accord que si nous souhaiterions mieux faire en termes de sécurité, il serait plus intelligent de créer la policy suivante :

$ sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.127.50.0/24" port port="11434" protocol="tcp" accept'
$ sudo firewall-cmd --reload

Ayant un UTM¹⁶ en amont, je me permets donc de me contenter de la première solution.

HTTP ou HTTPS ?

Un doute m’habite… Le port 11434/tcp, ça ne serait pas du http ?

Bien vu l’aveugle ! Effectivement et niveau sécurité c’est pas super, il faudrait mieux user du protocole https. Pour ça, j’ai une solution passons par un reverse proxy 🙂

Je suis partagé quant à la rédaction de cette sous partie. Oui il est important de sécuriser l’accès à l’interface Web, mais j’ai peur d’être hors sujet et d’alourdir l’article. Mais d’un autre côté, je ne veux pas non plus bâcler la chose… Encore un pu**n de choix cornélien…

Bref, je vais faire au plus simple et si besoin écrirai un billet sur Nginx.

Installation

L’installation et activation du service, je passe mon tour.

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

Certificats

Là encore une fois je rencontre un petit problème. Je n’ai pas de certificat public que je pourrais utiliser, ma topologie réseau ne me permet pas d’utiliser un certificat Let’s Encrypt et sans vouloir spoiler je n’ai pas envie de me prendre la tête. Donc ça va finir avec un bon vieux certificat autosigné 🙂

La génération n’est pas bien compliquée et si besoin, j’ai déjà rédigé un article sur le sujet.

Créons le répertoire qui va contenir nos éléments de sécurité :

$ sudo mkdir -p /etc/nginx/ssl

Générons notre certificat :

$ sudo openssl req req -x509 -nodes -days 365 \
-newkey rsa:2048 \
-keyout /etc/nginx/ssl/ollama.key \
-out /etc/nginx/ssl/ollama.crt

Configuration

Créons et éditons notre fichier de configuration. Je prendrai le temps d’expliquer l’intégralité du fichier de configuration.

$ sudo vim /etc/nginx/conf.d/ollama.conf

#server {
#    listen 80;
#    server_name 10.227.250.11;
#
#    return 301 https://$host$request_uri;
#}

server {
    listen 11444 ssl;
    http2 on;
    server_name 10.227.250.11;

    ssl_certificate /etc/nginx/ssl/ollama.crt;
    ssl_certificate_key /etc/nginx/ssl/ollama.key;

    # 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;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";

    # taille upload
    client_max_body_size 100M;

    # compression
    gzip on;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml;

    location / {

        proxy_pass http://10.227.250.11:11434;

        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_buffering off;

        proxy_read_timeout 3600;
        proxy_send_timeout 3600;
    }
}

La première section permet de réaliser la redirection du protocole HTTP vers HTTPS de manière permanente. Ainsi si je contacte l’url http://10.227.250.11, je serais automatiquement redirigé vers https://10.227.254.11. Toutefois, la section est commentée car elle entre en conflit avec une autre configuration d’un billet à venir 😉
Le second bloc indique que nous écoutons sur le port 11444 sur l’interface 10.227.250.11. L’emplacement des fichiers contenant la clé privée ainsi que le certificat sont spécifiés pour activer la couche de sécurité (j’ai l’impression d’enfoncer des portes ouvertes…). J’indique qu’elles sont les versions des protocoles TLS17 autorisées et laisse le serveur choisir le chiffrement le plus sûr. Côté en-tête, j’ai repris les suggestions de sécurité implémentée pour ITOP. Soit la restriction de mettre le site en iframe externe, de restreindre le navigateur à deviner le tye MIME qui est utilisé et surtout d’activer la protection anti-cross-site scripting. Niveau upload, j’ai vu large et j’ai autorisé le téléversement de fichier de 100 Mio. Côté performance, j’ai activé la compression des flux pour optimiser un peu les performances réseaux.
Le troisième bloc concerne la partie Reverse Proxy. Toutes les requêtes qui sont envoyées sur https://10.227.250.11 sont redirigées vers le port 11434. Concernant les en-têtes il est nécessaire d’utiliser les websockets car seront transmis l’ip du client, le protocole utilisé et le NDD18 ou l’IP demandé.

Une fois la configuration faite, il est important de réaliser un petit contrôle de notre petit fichier afin de s’assurer que ce dernier ne comporte pas d’erreur.

$ sudo nginx -t 
$ sudo systemctl restart nginx

Tiens une erreur 🙂 Regardons ça dans la partie suivante…

Sécurité

Nous souhaitons toujours publier notre interface web en HTTPS. Donc il va falloir jouer avec nos UTMs !

Sur le plan interne, autorisons nos flux https :

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

Toutefois lors de la relance du service on se tape une bonne grosse erreur. C’est lié au SELinux. Nginx n’est pas autorisé par le SELinux a écouter sur le port 11444. Donc il faut l’autoriser.

#Install semanage
$ sudo dnf install policycoreutils-python-utils

#Ajout du port comme autorisé à l'écoute
$ sudo semanage port -a -t http_port_t -p tcp 11444

#Relance du service nginx
$ sudo systemctl restart nginx

Normalement nous ne devons plus avoir d’erreur. Toutefois si nous essayons de joindre l’url https://egapl-ollama-01:11444 nous devons avoir un jolie 502 Bad Gateway dans notre navigateur 😀

Ca vous fait la b**e hein ? Je vous rassure je me suis pris la même rouste. J’ai oublié d’autoriser le contexte de mon SELinux pour autoriser les services http à accéder aux réseaux 😀

$ sudo setsebool -P httpd_can_network_connect 1

Un petit F5 et hop c’est tout bon <3

Normalement avec toutes nos actions, nous devons joindre notre interface web depuis un navigateur de manière sécurisée (hormis l’erreur liée à notre certificat autosigné).

Emplacement des modèles

Lors de ce benchmark, j’ai été confronté à un problème d’espace disque lié aux modèles. Effectivement, les modèles sont au minimum supérieur à 3 Gio. Et c’est là que c’est le drame car « pouf » je me tape un message d’erreur…

La solution est donc de déplacer le répertoire de modèle vers un autre disque. J’ai vu large, j’ai provisionné 100 Gio. Je pars du principe que le disque est monté et formaté.

$ sudo chown -R ollama:ollama /mnt/ollama

Le changement de l’emplacement du répertoire du modèle va se faire par surcharge du service qui démarre Ollama. Naturellement, on ne modifie pas le service de base car les changements ne seront pas persistants. D’où la surcharge…

$ sudo mkdir /etc/systemd/system/ollama.service.d
$ sudo vim /etc/systemd/system/ollama.service.d/override.conf

[Service]
Environment="OLLAMA_DEBUG=1"
Environment="OLLAMA_MODELS=/mnt/ollama/ollama-models"
Environment="OLLAMA_HOST=0.0.0.0"

Notons que le mode Debug est actif et que le chemin de nos modèles est défini. J’ai également défini la variable OLLAMA_HOST qui va nous permettre de joindre notre application depuis une source externe à notre machine.

Il convient alors de recharger, forcer le gestionnaire de services à recharger l’ensemble de ses configurations. Dans un second temps nous redémarrerons le daemon ollama afin de prendre en considération les changements présents dans notre fichier de surcharge. Par mesure de sécurité (car la confiance n’exclut pas le contrôle) j’aime à vérifier que le service est bien actif.

$ sudo systemctl daemon-reload
$ sudo systemctl restart ollama
$ sudo systemctl status ollama
$ sudo ls -al /mnt/ollama/ollama-models/

Dans les sources, nous pouvons constater la présence de nos variables surcharger. Néanmoins nous pouvons afficher le contenu de notre répertoire cible pour les modèles afin de vérifier que l’arborescence est bien présente.

Installer des modèles

J’ai fait le parti car c’est « un peu » l’objectif de base de ce billet d’avoir des modèles locaux qui vont être utilisés. Je ne souhaite pas utiliser des connexions avec des sources externes afin de garder un contrôle sur mes recherches et usage.

J’ai fait le choix d’étudier 4 modèles LLM :

• Llama3
• Qwen
• Mistral
• DeepSeek-Coder

Je propose dans un premier temps de faire un comparatif de ces modèles.

Avec ce tableau, je pense que nous avons un bon récapitulatif. Toutefois et pour les curieux il existe une centaine de modèles compatible avec Ollama (Lien). J’ai fait mon choix, à vous de faire le vôtre. Vous êtes des grands garçons et des grandes filles hein ? #bisous

L’installation pour les modèles choisies, suivent tous la même logique. Pas de quoi épiloguer pendant 107 ans….

Llama3

$ sudo ollama pull llama3

Qwen

$ sudo ollama pull qwen

Mistral

$ sudo ollama pull mistral

DeepSeek-Coder

$ sudo ollama pull deepseek-coder:6.7b

Pour voir l’ensemble des modèles il est possible de lister ces derniers grâce à la commande suivante :

$ sudo ollama list

Démarrage de Ollama

Maintenant que tout est fonctionnel, démarrons Ollama et c’est parti pour un périple des possibles comme Heinrich Harrer à l’assaut du Nanga Parbat (l’élévation n’étant pas celle que l’on croit 🙂 ).

$ ollama

Dans le menu qui s’offre à nous, la première option permet de démarrer, lancer un de nos modèles localement. Toutefois, en dessous de cette première option de navigation, nous retrouvons la possibilité d’établir des connexions externes vers des moteurs en ligne tel que : * Claude Code * Codex * OpenClaw * Droid * Pi * Cline Si vous possédez un compte, vous pouvez réaliser la jonction, mais alors à quoi bon avoir un moteur d’IA interne ?

Si nous cliquons sur le premier choix, il nous est alors demandé de choisir un modèle. Il est possible de télécharger un modèle directement depuis ce menu ou de choisir un modèle précédemment installé tout en bas de cette interface.

Tests

Et si on se lançais un petit benchmark de nos 4 modèles pour voir le fonctionnement ? 🙂

Amusons-nous tel un lamastico <3

Pour le test, j’ai décidé de partir sur quelque chose de simple et ISO sinon cela ne sert strictement à rien.

La question sera :

Peux-tu évaluer et me proposer une version plus robuste de cette fonction powershell s’il te plait ? [Suivie d’une petite fonction maison qui peut être amélioré]

Llama

Qwen

J’ai du tronquer la partie de la réponse en anglais car cela aurait pris énormément d’espace. Toutefois la réponse retournée est plus que satisfaisante pour celui qui sait parler la langue de Shakespeare

Mistral

DeepSeek-Coder

Je pense que cela est évident en termes de conclusions. Pour 1 prompt identique, nous avons quartes réponses différentes et un point commun. Si certains modèles mettent plus de temps de réponse il est indéniablement contestable que ça chauffe niveau calcul. Dans certains cas, j’aime même du SWAP ! Bref, côté consommation électrique, ça consomme… Mais bon je m’y attendais ce n’est pas la première fois que je fais des étincelles avec ma b*te…

Plus sérieusement, je sais quitte à me répéter ou pas ce que je dois faire pour améliorer ma fonction. Et je suis un peu déçu du résultat. Néanmoins en modifiant légèrement le prompt, en précisant :

Peux-tu évaluer et me proposer une version plus robuste, sécurisé de cette fonction powershell s’il te plait comme si tu étais un développeur sénior avec un regard plus critique et sévère ? [Suivie d’une petite fonction maison qui peut être amélioré]

Résultat Prompt initial (qwen)	Résultat Prompt plus précis (qwen)

/!\ Attention : J’ai volontairement gardé que la suggestion de la fonction et non le blabla d’en-tête qui explique tout ce qui va être appliqué.

Encore une fois pas de magie, il suffit de bien rédiger son prompt et là j’obtiens un retour plus précis à mes attentes.

Si je résume la situation sur le test à iso périmètre selon le contexte :

• RAM : 8 Go
• vCPU : 4
• Processeur Physique : Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz (Mono)
• Contexte : Coding

Durée des réponses	Qualité des réponses

En conclusion Qwen est de loin celui qui met le plus de temps à délivrer la réponse. Cela s’explique par une explication plus poussée ce qui prends un certain temps à l’affichage. Cependant la qualité de la réponse retournée est de loin supérieur aux trois autres LLMs.

Il serait intéressant de pousser la comparaison sur un prompt de réflexion pur.

De tous les tests de modèles (du moins sur les quatre déployés) c’est qwen qui me convient le mieux. Néanmoins tout dépendra encore une fois du contexte et de ce que je souhaite réaliser avec l’IA.

Conclusion

Je suis plutôt satisfait bien que sans répondre aux prérequis il faut savoir s’armer de patiente. Dans l’ensemble Ollama est une bonne solution mais cette dernière doit être utilisé avec un certain contrôle selon les LLMs que l’on pourrait être amené à utiliser. Naturellement le retour de prompt vient de la qualité de celui que l’utilisateur aura exprimé.

De ce fait, Ollama ne garantit pas une fiabilité aussi conséquente que les géants du Cloud. Toutefois il permet d’assurer la confidentialité, sécurité des données localement et de nos recherches contrairement aux outils en ligne.

Ce qui pourrait toutefois rebuter son usage serait de passer par l’interface CLI dans le terminal. Effectivement c’est loin d’être ergonomique pour un usage quotidien d’un utilisateur n’ayant pas d’expérience dans ce domaine. Mais il existe toutefois des alternatives à cette problématique par des outils intermédiaires qui viennent se placer entre l’utilisateur et Ollama. Ce sujet sera abordé dans un prochain billet.

Initialement, je souhaitais aborder le sujet dans ce billet mais cela aurait été trop indigeste. Donc j’ai CUT comme on dit dans notre milieu 🙂

Ollama fournissant une documentation riche et simple il sera alors possible de jouer avec son API. Vous me connaissez avec le temps, s’il y a une documentation, une API… Que vais-je bien pouvoir faire avec le framework .NET et Powershell ? 🙂 L’objectif serait de proposer par exemple un petit client de bureau Windows pour les utilisateurs. Il serait également possible de mettre en place des passerelles d’automatisation inter applicatives intelligente comme L’ouverture d’un incident sur un event VEEAMOne dans ITOP ou une fonction de contrôle de code depuis PowerShell ISE par exemple.

Cette étude m’ouvre un nombre de porte considérable en guise de projet et de sujet d’étude et ce malgré les contraintes matérielles. Est-ce que je vais utiliser longtemps la solution, je ne pense honnêtement pas car cette dernière est assez énergivore pour mon petit lab et je ne travaille pas chez EDF ni n’habite Versailles. Mais cela peut (pour ne pas dire m’a) réconcilié avec l’utilisation de l’IA. Comme quoi il n’y a que les cons qui ne changent pas d’avis et nous sommes tous le con d’un autre.

Le mot de la fin :

J’ai cherché votre nom sur Ollama ? Comme ça vous êtes triple champion du monde de descente de Guiness catégorie galopin ?

Vous devez faire erreur avec une autre personne, je suis un DC10 fantôme sortant d’une tempête codéinée.

Milles excuses M’sieur Ollama.

Erwan GUILLEMARD

Sources

• Définition Larousse
• Wikipédia : IA
• DataBird : Type d’IA
• Ollama : Documentation
• Ollama : Téléchargement
• Ollama : Bibliothèque de modèle
• OpenWebUI : Documentation
• OpenWebUI : Intégration Ollama
• Comparatif : Modèles performances
• Comparatif : Modèles usages
• Usage de l’IA : DAFMag
• Répartition de l’usage : BPIFrance
• Usage de l’IA : LeMonde

1. IA : Intelligence Artificielle ↩︎
2. L’erreur est humaine, persévérer diabolique ↩︎
3. CGU : Conditions Générales d’Utilisations ↩︎
4. LLM : Large Language Models ↩︎
5. GPU : Graphics Processing Unit ↩︎
6. CPU : Central Processing Unit ↩︎
7. SSD : Solid State Drive ↩︎
8. DARPA : Defense Advanced Research Projects Agency ↩︎
9. IHM : Interface Homme Machine ↩︎
10. AGI : Artificial General Intelligence ↩︎
11. SVM : Support Vector Machine ↩︎
12. NLP : Natural Language Processing ↩︎
13. RAG : Retrieval Augmented Generation ↩︎
14. API : Application Programming Interface ↩︎
15. HTTP : Hypertext Transfer Protocol ↩︎
16. UTM : Unified Threat Management ↩︎

Je rassure le lecteur qui s’est égaré ici, ce billet va être simple.

Bref, j’ai la problématique suivante, lorsque je déploie une nouvelle machine Linux (RHEL¹ ou Debian) je suis le guide d’hygiène et sécurité de l’ANSSI². Ce qui se traduit par le partitionnement strict des points de montage système et de données. Sauf que lorsque la taille de notre disque varie, difficile de définir de tête quelle volumétrie doit être provisionnée pour chaque partition…

C’est donc là que j’ai pris un coup de sang.

En voiture Simone, c’est parti !

Avant-Propos

Je ne vais pas rentrer dans le détail du code qui compose mon application, ce n’est pas l’objectif. Si l’on souhaite comprendre ce dernier, un peu de réverse engineering et le tour est joué (surtout que j’ai commenté le code).

Je n’aborderai pas non plus la partie de durcissement des systèmes GNU Linux. Pourquoi ?

1. Ce n’est pas le sujet de ce billet
2. Je traite le sujet dans un de mes premiers articles que je ne partage que sur contact et échange
3. Je pars du principe que cela sera fait après déploiement du SE³.

L’objectif est vraiment de comprendre ou du moins rappeler la structure d’un système GNU quant à son arborescence d’organisation de fichier. Et donc outre à mesure à comprendre pourquoi nous devons allouer plus ou moins d’espace de stockage.

Concernant l’application que j’ai développé, bien que je revienne sur ce point plus bas dans ce billet, cette dernière n’est pas fonctionnelle sur les environnements GNU Linux du fait de la GUI⁴.

Il est également important de souligné que cette application n’est compatible qu’avec la version 5.X de powershell.

Prérequis

• SE : Environnement Windows non obsolète
• Apps : Non Applicable
• Autres :
  • PowerShell version 5.X

Théorie

Si nous devons commencer par la base, il serait bon de se poser la question

« Comment est structurer un environnement GNU Linux ? »

Contrairement à certaines connaissances que j’ai pu fréquenter, oui c’est un point important. Cela évite de faire n’importe quoi et dans une outre mesure d’apprendre quelques choses. (Toutes ressemblances avec des personnes existantes et purement fortuite).

T’es un peu chafouin en ce moment non ? Tu ne voudrais pas ton petit suppositoire à la verveine ?

Légèrement agacé avec une pointe de colère et donc de sarcasme il est vrai. L’hypocrisie des uns fait le désespoir des autres. Mais OKLM comme disent les d’jeuns je prends un sacré recul. Cependant, je suis partant pour la verveine mais pas en suppositoire, plus en pousse café 🙂 Et puis Monsieur, Madame, Mademoiselle, je suis bien fatigué… J’en ai marre…

Regardons alors de plus près l’architecture n à n-1.

(Pas de panique je vais prendre le temps de décrire chaque répertoire).

Nous avons le répertoire parent de notre arborescence, communément appelé « la Racine » (et non rien à voir avec l’organisation de l’ombre de Konoha dans Naruto [super référence…]) ou root. C’est sous ce répertoire / que nous allons retrouver les répertoires qui organise notre SE.

J’en peux plus. C’est que c’est long comme retour aux bases… J’espère ne pas avoir oublié de répertoire.

L’une des mauvaises pratiques lors du déploiement d’un SE Linux est d’allouer l’ensemble de l’espace disponible à /, de ce fait si par exemple je viens à blinder le /var/tmp ou /var/log mon système est à genoux. Donc sur un disque il convient de partitionner les répertoires.

Oui mais quels répertoires ?

En réponse à cette question, je mets en 3/4 face et je réponds par un Uraken des familles en sortant le guide de l’ANSSI.

Cela offre également une autre possibilité concernant la sécurité. Au-delà d’assurer le fonctionnement du système quant au potentiel risque de saturation de stockage, il est possible de définir des options sur les points de montage de nos répertoires. Ainsi il est possible de limiter l’accès au device ou l’exécution de programme. Je préconise également d’ajouter le répertoire /var/log/audit. Je ne rentre volontairement pas dans le détail car j’explique ce point de recommandation (R12) dans mon billet concernant le durcissement d’un système GNU Linux.

Ok pour ce qui est de la segmentation, mais du coup, quel doit être la répartition niveau stockage ?

C’est plutôt simple. Encore une fois, il suffit de chercher un peu. Malheureusement il n’y a pas de recommandation empirique. C’est donc à nous de définir les seuils par répertoire en tenant compte des critères énoncés précédemment.

Pour ma part cela donne :

Voilà ce qui est pour la théorie. Comme ça me soule de ne pas savoir quel espace allouer pour 30 Gio, 40 Gio, 50 Gio de disque, j’ai été contraint de faire une petite application en Powershell… Pourquoi changer une équipe qui gagne ?

Application

Je reste un puriste en termes de développement et je ne peux me passer de Windows Powershell ISE⁷. Je sais qu’il existe mieux comme IDE⁸ (Visual Studio Code par exemple) mais je n’arrive pas à me faire à l’idée de quitter ISE…

Cela fait-il de moi un vieux réactionnaire ? Un dev de l’ancien temps ?

Bref, je laisse cette question existentielle en suspens.

Je me suis amusé pour une fois à réaliser une interface GUI⁹ via WindowsForm. Moi l’amoureux du CLI¹⁰ je reconnais mettre amusé. Encore une fois je sais que je ne savais rien et j’ai donc encore appris.

Réaliser une application GUI en plaçant les items au pixel c’est marrant mais vite casse gueule. Cela demande une gymnastique d’esprit qui ne me rebute pas.

Il y a toutefois un bémol non négligeable à l’utilisation de WindowsForm, cela ne permet pas l’opérabilité multiplateforme. Logique puisque WindowsForm fait partie intégrante de Windows, donc pas possible de faire fonctionner ce dernier sous Linux.

Il faudrait donc que je compose un mode de fonctionnement CLI pour assurer l’opérabilité. Cela n’est qu’au final que le développement d’une fonction d’affichage.

La première version de mon application ne se base pas pour l’instant sur un fichier de configuration ce qui implique que les seuils minimums et maximums sont défini en dur dans le code (en tant que constante global tout de même je ne suis pas un sauvage !).

J’offre également la possibilité de définir la taille minimum ou maximum à provisionner.

Pour bien comprendre (c’est un grand mot) je propose la courte vidéo de présentation de la version béta de mon app.

Démonstration

GitHub

Miaou

Conclusion

Qu’il est bon de revenir aux bases. Sans cela, je pense que je n’aurai pas eu l’idée de faire du GUI en powershell depuis mon ISE. Il est vrai que cela permet également de revenir peut-être aux prémices de ce blog qui étaient :

• L’aspect pédagogique
• Aborder les bases
• Réaliser des petits projets
• Sortir des sentiers battus

Ainsi, je renoue avec certaines valeurs laissées de côté dans le cadre des derniers gros projets que j’ai pu mener. Toutefois, je reste une tête de c*n à laisser transparaitre ma désinvolture, sarcasmes et autres tournures de phrases et expressions vitriolés 🙂 (Ce blog et mes articles restent un loisir personnel et cela m’amuse d’user de ma liberté d’expression tout en tachant de rester respectueux).

Bref, il est temps de clôturer ce billet et d’attaquer d’autres thématiques 🙂

Le mot de la fin :

J’ai évalué et calculé mon incompétence, elle est à la hauteur de vos mensonges et de votre lâcheté. Un petit partitionnement de prime et de service ? Vous méritez bien convenablement un pâté lorrain en cadeau ?

Erwan GUILLEMARD

Sources

• Debian : Recommanded Partitioning
• Ubuntu : DiskSpace

1. RHEL : RedHat Entreprise Linux ↩︎
2. ANSSI : Agence Nationale de Sécurité des Systèmes d’Informations ↩︎
3. SE : Système d’Exploitation ↩︎
4. GUI : Graphical User Interface ↩︎
5. GRUB : GRand Unifier Bootloader ↩︎
6. BDD : Base De Données ↩︎
7. ISE : Integrated Scripting Environment ↩︎
8. IDE : Integraded Development Environment ↩︎
9. GUI : Graphical User Interface ↩︎
10. CLI : Command Line Interface ↩︎

Alors non je ne vais pas abandonner MariaDB. Ce billet simple et efficace traitera de la SGBD¹ PostgreSQL. Le pourquoi de cet intérêt soudain se justifie par la rupture technologique de nombreux éditeurs du marché vers ce moteur puissant. Ne nous voilons pas la face, ce jour les grands acteurs de BDDs² proposent des versions communautaires qui sont limités en termes de volumétrie et de fonctionnalité. Pour jouir de l’ensemble des fonctionnalités il faut passer à la caisse.

$$$ Bonjour le bandit manchot $$$

Les bases de données étant de plus en plus volumineuse et l’évolution que nous utilisateurs nous en faisons facilite auprès de ces mêmes éditeurs la mise à jour de leurs tarifications. C’est de bonne guerre (ou pas). Ce « ou pas » laisse donc la voie à d’autres alternatives. Plus simple, moins complexes et parfois plus puissante en s’alignant sur le principe de la philosophie OpenSource.

Je laisse une version communautaire, tu passes à la caisse si tu veux un service d’assistance ou de maintenance.

Il y aura toujours chez certains éditeurs quelques fonctionnalités en moins. Toutefois, je pense que c’est dans cette approche et la bonne et je réfléchis à adopter le même principe dans un projet de vie d’une plus grande dimension.

Bref, après cette marche de l’éléphant (sans prendre de LSD³ ou autres acides). Je me fais un petit guide sur PostreSQL 🙂

Avant-Propos

Il me semble important une nouvelle fois de préciser que ce billet portera sur le déploiement d’un environnement PostgreSQL dans sa dernière version stable à ce jour (release 18 en ce mois de grace Octobre 2025). Sur Windows, le déploiement ne m’intéresse pas des masses. Par contre sur un système GNU/LINUX, j’écris un OUI majuscule (gras, italique, souligné rouge !).

Bien que les chiffres ne soient pas réellement suivis, PostgreSQL estime la part d’environnement de production d’environ (lien) :

• 52 % l’usage sur les systèmes GNU/LINUX
• 23% l’usage sur les systèmes Windows

La raison de mon choix est que nous retrouvons un grand nombre d’appliance qui utilise PostgreSQL dans des environnements GNU/UNIX. Donc en tant que SysAdmin il faut bien savoir se positionner 🙂 (franchement, quelle remarque de me*de…).

Je considère que l’environnement sera durci selon les recommandations de l’ANSSI⁴ concernant les systèmes GNU/LINUX et comme d’accoutumé, je pars sur ma distribution RHEL favorite RockyLinux.

Prérequis

• SE :
  • Rocky Linux 9.4 et version ultérieures
• Apps : 
  • PostgreSQL 18.4
• Autres :
  • Non applicable

Théorie

L’implémentation d’un SGBD passe forcément par une réflexion de sa topologie. Nous ne balançons pas une application 1-tiers, on essaie à minima d’adopter une architecture 2-Tiers. Soit 1 serveur Frontend et 1 serveur Backend.

Pour des raisons qui sont évidentes (enfonçage de porte ouverte) une application publiée ne doit pas héberger la BDD. L’application doit être en DMZ⁵ et la BDD dans une autres bulles avec un contrôle des flux entrants et sortants interlans.

M’sieur? Et pour l’identification des flux ? Pour l’attribution des ressources ? Comment on fait ?

Donnez moi un R, un T, un F et un M… RTFM⁶ ! Il suffit encore une fois d’avoir le courage de se palucher le wiki de l’éditeur applicatif. Un peu d’huile de coude n’a jamais fait de mal.

Une fois la topologie bien pensée, passons à l’architecture de notre serveur BDD.

Comme tout SGBD déployé il convient au minima d’implémenter la topologie ci-contre. Soit, un disque dédié au système UNIQUEMENT. Un disque dédié au stockage des données de notre SGBD et en dernier lieu un disque dédié au dump de nos BDDs avec une périodicité définie. J’ajouterai également un quatrième disque quant aux journaux de la BDDs et les journaux de transaction (les fameux transaction logs). Toutefois, ayant une petite infrastructure, je m’octroie le luxe de laisser ces derniers dans le /var/log.

Hardware Requirements

Niveau des ressources là c’est une autre histoire… Si la documentation officielle nous communique les ressources et interopérabilités avec les dépendances tierces, je n’ai malheureusement pas trouvé d’informations sur les ressources matérielles. Dans un sens logique car cela va dépendre de ce que nous souhaitons traiter comme données etc.

J’ai donc décidé d’appliquer de mon plein gré et non sous la contrainte de calquer les recommandations MariaDB (lien). Toutefois, cela fait un peu beaucoup pour moi…

Je partirai donc pour un minimum 2 vCPU et 4 Gio de RAM. Dans l’idéal, je serai je pense sur du 4 vCPU et 8 Gio de RAM. Comme écrit plus haut, tout dépendra de ce que notre application va consommer en termes de traitement. Il faudra alors raisonner en bon père de famille (spéciale dédicasse) et ajuster les ressources afin d’éviter la sur ou sous allocation.

Côté réseau, la documentation nous indique que le port 5432/tcp est le port de communication par défaut. Surprise, nous pouvons changer le port dans le fichier de configuration…

Je pense qu’avec le peu de base énoncée, nous pouvons passer à la pratique.

Pratique

Un dernier point pour faire une magnifique transition entre la théorie et cette partie. Il est à noter que les dépôts officiels des distributions contiennent une version de la solution PostgreSQL. Toutefois, il ne s’agit généralement pas de la dernière version. Il est recommandé d’ajouter le dépôt de l’éditeur et de ne pas utiliser le dépôt système pour PostgreSQL.

Installation

Franchement, je trouve là la démarche super-mega overcool de proposer un webwizard pour définir comment déployer PostgreSQL selon les différents OS⁷ et distributions (nous noterons au passage un excellent usage de la figure de style hyperbolique) (lien).

Je ne vais pas copier bêtement le script proposé. Mais reprendre chacune des lignes. Ce que je trouve admirable, c’est la simplicité du déploiement. Pas besoin d’installer 10k de dépendance en amont et de configurer ces dernières.

1 – Ajout du repo

A partir du lien fournit par le webwizard installer le nouveau repo :

$ sudo dnf install https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm

2 – Désactivation du package de la source de distribution

Comme indiqué précédemment, il convient de désactiver la version de postgreSQL contenu dans le repo par défaut. Ainsi, nous aurons une plus grande flexibilité dans le choix de version de nos composants.

A noter que mon système étant durci j’ai été contrait de réaliser l’opération en tant que root.

# dnf -qy module disable postgresql

3 – Installation du Server PostgreSQL

Rien de plus simple, il suffit de faire une petite recherche par précaution puis une installation de notre package.

# dnf search postgresql18-server
# dnf install postgresql18-server

4 – Initialisation et démarrage

Comme tous SGBDs, il convient d’initier la première installation. Puis de s’assurer que le service va être lancer automatiquement au démarrage du système en cas de reboot.

Pour conclure, le traditionnel démarrage de notre daemon.

# /usr/pgsql-18/bin/postgresql-18-setup initdb
# systemctl enable postgresql-18
# systemctl start postgresql-18

Pour le fun, une petite vérification 🙂

Notre daemon PostgreSQL étant déployé, j’arrive toujours à ce point d’application des bonnes pratiques systèmes. C’est là que ça peut être délicat si on se plante dans la configuration car cela peut mener à repartir de zéro. D’où l’importance de lire la documentation encore une fois.

C’est qu’un éléphant ça trompe énormément !

Et voilà comment on casse tout 😀

Déplacement de la BDD Location

Si nous gardons la topologie mis en place ci-haut, il sera nécessaire de déplacer le répertoire data stocké sur /var/lib/pgsql/18/data vers notre répertoire /mnt/database/postgresql/data monté sur notre disque /dev/sdb.

Je ne vais pas mentir, je me suis pris les pieds dans le tapis une fois et j’ai dû restaurer ma VM. Toutefois, les étapes ci-dessous sont bien éprouvées et valide.

1 – Arret du service

La base de la base est donc d’arrêter le service postgresql :

$ sudo systemctl stop postgresql-18.service
$ sudo systemctl status postgresql-18.service

Il est primordiale de s’assurer que le service ne tourne plus.

2 – Création de l’architecture cible

Sur notre partition /dev/sdb1 préalablement configurée et montée sur /mnt/database, nous allons créer et définir les droits et permissions pour autoriser notre compte postgres à accéder à ce dernier.

$ sudo mkdir /mnt/database/postgresql
$ sudo mkdir /mnt/database/postgresql/pg_sock
$ sudo mkdir /mnt/database/postgresql/data
$ sudo chown postgres:postgres /mnt/database/postgresql
$ sudo chmod 755 /mnt/database
$ sudo chmod 700 -R /mnt/database/postgresql

Mais alors pourquoi 700 ? La base de donnée ainsi que l’ensemble des fichiers de ressources doivent être accessible uniquement de l’application par sécurité.

3 – Déplacement des données

Comme j’ai pris l’habitude de faire comme pour MariaDB, je vais copier le contenu du répertoire data puis renommer la source afin d’éviter tous dysfonctionnements.

$ sudo rsync -av /var/lib/pgsql/18/data/ /mnt/database/postgresql/data/
$sudo mv /var/lib/pgsql/18/data /var/lib/pgsql/18/data.ori

Une erreur classique lors de l’usage de la commande rsync reste l’oublie du /. Cela entrainera la copie du répertoire et non de son contenu uniquement. En gros, ça va bégayer dans les chemins (../postgresql/data/data/…).

4 – Modification de la configuration du service

Le service est configuré pour démarrer le daemon sous /var/lib/psql/18. Pour prendre en charge le nouveau chemin, il faut modifier ce dernier. La philosophie et de surcharger la configuration.

Créer le répertoire qui va contenir la surcharge de notre daemon psql :

$ sudo mkdir -p /etc/systemd/system/postgresql-18.service.d

Créer un fichier de surcharge qui va contenir le chemin du répertoire data :

$ sudo tee /etc/systemd/system/postgresql-18.service.d/override.conf > /dev/null <<'EOF'
[Service]
Environment="PGDATA=/mnt/database/postgresql/data/"
EOF

Par acquis de conscience, j’aime vérifier que le fichier est bien présent ainsi que le contenu de ce dernier.

$ sudo cat /etc/systemd/system/postgresql-18.service.d/override.conf

Le daemon ‘system’ a été altéré (puisque j’ai ajouté une configuration) et donc ? Un petit reload des familles pour prendre en compte le changement et zou.

$ sudo systemctl daemon-reload

5 – SELinux

Un étape un peu border avec la sécurité (comme un excès de Delirium un jeudi soir pour oublier une semaine compliqué).

Toutefois, il est important de noter un petit point et non des moindres sur notre fichier /etc/fstab. Il va être nécessaire d’ajouter le contexte sur notre partition et de relabeliser notre point partition.

Editons le fichier avec VIM, VI ou NANO puis modifier la ligne comme ci-dessous en ajoutant au niveau des droits defaults,context=system_u:object_r:postgresql_db_t:s0

Ce qui veut dire en SELinux :

• Defaults : Activation des droits standards
• Context=
  • system_u : Identité SELinux, sans impact concernant notre SGBD
  • object_r : Rôle d’objet de type fichier
  • postgresql_db_t : Match avec le type de données PostgreSQL autorisé par SELinux. Ainsi, SELinux interdit à PostgreSQL d’accéder à des fichiers qui ne sont pas dans le contexte.
  • s0 : Le niveau de sécurité par défaut.

Il sera nécessaire de définir le bon contexte sur notre nouveau répertoire.

$ sudo semanage fcontext -a -t postgresql_db_t "/mnt/database/postgresql(/.*)?"
$ sudo restorecon -Rv /mnt/database/postgresql/

6 – Démarrage du service

Le moment de vérité.

Vais je vomir l’ensemble de mes bières et commander une nouvelle tournée pour noyer mon échec ou commander une nouvelle tournée pour célébrer le succès de cette opération ? 🙂

$ sudo systemctl start postgresql-18
$ sudo systemctl status postgresql-18

Il faut noter que le service fonctionne. Néanmoins, il convient de se demander si nous pouvons requêter notre BDD à la suite de ce changement.

$ sudo -u postgres psql -c "SELECT version();"

Vérifions également que le chemin du PGDATA a bien été pris en compte.

$ sudo -u postgres psql -c "SHOW data_directory;"

Ouf ça fonctionne 🙂

Place à l’étape suivante ! BA-BA-BAR POM POM POM POM

Sécurisation & Configuration

Nous revenons encore et toujours au même point. Qui dit données implique la sensibilité de ces dernières. Aujourd’hui braquer une banque ne rapporte pas grand-chose. Le rapport bénéfices/risques n’est pas bon… Mais braqué des données, utiliser ces dernières et les revendre apporte un bien meilleur rapport en termes de bénéfices / risques.

Donc, je me retrousse les manches car je ne suis pas un manche !

Si du côté MariaDB il existe le fameux mysql_secure_installation, ce n’est malheureusement pas le cas chez PostgreSQL.

Il se pose alors de dresser un inventaire rapide des points que nous souhaitons sécuriser :

1. Mot de passe du compte postgres
2. Restreindre l’accès réseaux
3. Mettre en place une stratégie d’authentification
4. Utiliser des algorithmes de chiffrement fort
5. Supprimer les BDDs inutiles
6. Droits sur les fichiers
7. SELinux
8. Firewall embarqué (même si je préfère le terme embedded)
9. Audit et Journaux d’événements

Ca fait une petite tripoté n’est-il pas ? Naturellement, certains des points ci-haut ont déjà été traité lors du déploiement et du changement d’emplacement de la base de données.

1 – Password Account DB

Comme pour MariaDB (compte root), l’utilisateur postgres ne possède pas de mot de passe. Il convient par sécurité de définir ce dernier afin qu’il ne vienne une idée à un individu malveillant (comme un RSSI ⁸lors d’un audit ou pire un SysDBA⁹) de mettre sa truffe humide dans notre BDD.

$ su - postgres
$ psql -c "alter user postgres with password 'MyP@ssw0rd'"

Il est important de faire un petit clear de l’historique de frappe. Un mot de passe en clair c’est pas cool.

2 – Network Restrictions

Ouvrons le fichier de configuration /mnt/database/postgresql/data/postgresql.conf.

Attention comme indiqué précédemment, il faudra être authentifié en tant qu’utilisateur postgres ou root.

Recherchez la section CONNECTIONS AND AUTHENTIFICATION.

Se pose alors la question, depuis où je peux consulter ma BDDs et sur quel port ? Personnellement, le port je le laisse par défaut soit 5432/tcp. Toutefois, la source, il est bien de spécifier le subnet ou les adresses IPs qui sont autorisé à se connecter à notre SGBD. Naturellement, la valeur ‘*’ est proscrite.

Ce paramétrage va de pair avec la configuration de notre UTM¹⁰ embedded (cf le point plus bas).

3 – Authentification Policies

On va changer de fichier. L’objectif est de définir qui va se connecter à quoi, comment et depuis où.

Direction /mnt/database/postgresql/data/pg_hba.conf

La logique de lecture est la suivante TYPE correspond à la nature de l’authentification (local? hôte ?) pour quelle DATABASE (all ? replication ? db_test ?) pour quel USER (all ? r-one ?) depuis quelle ADDRESS (127.0.0.1/32 ? 0.0.0.0/0 ? 10.36.16.0/24 ?) et par quel METHOD (peer ? scram-sha-256? MD5?).

Il est certain qu’il faut limiter l’usage au maximum du all comme du masque 0.0.0.0/0. Toutefois, il n’y a pas de base les paramètres « implicites » de refus des connexions. C’est donc à implémenter (dernières lignes de la capture d’écran).

On sauvegarde, puis on reload le service.

$ sudo systemctl reload postgresql-18

4 – Suite de chiffrement

Toujours dans le fichier de configuration /mnt/database/postgresql/data/postgresql.conf. Attention comme indiqué précédemment, il faudra être authentifié en tant qu’utilisateur postgres ou root.

Recherchez la section CONNECTIONS AND AUTHENTIFICATION et activez l’algorithme de chiffrement scram-sha-256. Le MD5, nous passons notre tour hein ? Autant allez aux champignons sans capotes, c’est du pareil au même.

5 – Nettoyage des BDDs inutiles

Il est important de lister les bases présentes sur notre SGBD et de supprimer les bases qui ne servent à rien.

$ su - postgres  -c "\l"
$ psql

postgres=#\l
postgres=# DROP DATABASE NAME_BDD;

Attention : Il ne faut en aucun cas supprimer les bases template0 et template1. Ces dernières permettent (pour la 1) de générer les futurs BDDs) et (pour la 0) de regénérer la BDD de modèle.

6 – Permissions et ACLs

Comme expliqué ci haut et pour des raisons évidentes. L’accès aux données doivent être accessible uniquement du compte utilisateur postgres et root. Pas de quoi foutez milles éléphants…

Je glisse toutefois les commandes.

$ sudo chown -R postgres:postgres /mnt/database/postgresql/data
$ sudo chmod 700 /mnt/database/postgresql/data

7 – SELinux <3

Nous retrouvons la commande saisie ci-haut si nous avons modifié le database location.

Ainsi nous définissons le contexte de fichier de type postgresql_db_t à l’ensemble des éléments qui sont situer sous /mnt/database/postgresql. Puis on restore le contexte.

$ sudo semanage fcontext -a -t postgresql_db_t "/mnt/database/postgresql(/.*)?"
$ sudo restorecon -Rv /mnt/database/postgresql/

8 – Firewall

Avant c’était iptables maintenant c’est firewalld ou ufw. Personnellement je reste sur la configuration de firewalld.

Il convient d’autoriser les flux 5432/tcp dans notre firewall si des connexions se font depuis un autre réseau ou une autre machine.

$ sudo firewall-cmd --permanent --add-service=postgresql
$ sudo firewall-cmd --reload

Cela étant, il serait également plus précis de filtrer les connexions entrantes sur un réseau ou une adresse ip uniquement sur le port 5432/tcp.

J’assume cette configuration du fait de mon UTM en amont qui filtre l’ensemble des flux inter-lans.

9 – Logs & Audits

Ouvrons le fichier de configuration /mnt/database/postgresql/data/postgresql.conf. Attention comme indiqué précédemment, il faudra être authentifié en tant qu’utilisateur postgres ou root.

# vim /mnt/database/postgresql/data/postgresql.conf

Se rendre ensuite dans la section REPORTING AND LOGGING. Puis vérifiez que la configuration suivante est active.

Activation de logging_collector sur on afin de récupérer les erreurs sous la forme json ou csv. L’emplacement où va être stocké les journaux. Par défaut celui-ci se trouve dans le répertoire log. Il faudra renseigner si l’emplacement est différent le chemin absolu, le chemin relatif si c’est un cluster. log_directory = ‘log’ Le nom du fichier, par défaut ce dernier est sous le format postgresql-%Y-%m-%d_%H%M%S.log. log_filename = ‘postgresql-%a.log’ Activer la journalisation pour l’ensemble des événements de connexion et de déconnexion. log_connections = on log_disconnections = on En guise de traitement des logs, nous choisirons ddl pour avoir les définitions des commandes utilisés. Attention, l’usage de all peut être dangereux vis à vis des ressources. log_statement = ‘ddl’

Une fois les modifications apportées, n’oubliez pas que notre serveur PostgreSQL à besoin d’être redémarré :

$ sudo systemctl restart postgresql-18

Pour une configuration spécifique comme la gestion de la mémoire allouée, les fonctionnalités et j’en passe. Je pense qu’il est inutile d’aborder cela dans ce billet.

Pourquoi ? Parce que cet aspect-là et intrinsèquement lié aux dépendances des applications qui nécessite le SGBD PostgreSQL.

Premiers Pas

Cette sous partie vise plus à entrevoir les commandes de bases pour instancier une BDD dans le cadre de déploiement d’une application (spoiler Odoo par exemple ?).

Je n’ai pas la prétention de réinventer la roue, il existe la documentation pour cela et je n’ai pas non plus la prétention de devenir SysDBA. J’ai juste envie de faire les choses bien et surtout en suivant la doctrine des 3S, Simple, Standard et Sécurisé (14 ans d’ESN¹¹ ça vous forge un homme !).

Création d’un user

La création d’un utilisateur suit un paradigme différent de MariaDB. La finesse de l’application du contexte d’un utilisateur se fera dans le fichier pg_hba.conf.

$ psql -U postgres

postgres=# CREATE USER user_odoo WITH PASSWORD 'MyPassw0rd';

Création d’une BDD

La création d’une BDD nécessite qu’un utilisateur (de la SGBD naturellement) ait le privilège CREATEDB ou d’utiliser un compte super utilisateur. Cela parait logique mais pas pour tout le monde. La documentation nous rappelle que la création d’une nouvelle base de données sera effectué en réalisant un clone de la BDD template1 (si, le truc qui ne fallait pas supprimer).

postgres=# CREATE DATABASE bdd_odoo;

Toutefois, nous pouvons allez plus loin en définissant le propriétaire de la BDD, le jeu de caractère de la BDD ainsi que la collation locale afin de faciliter le tri des chaines. Par exemple :

postgres=# CREATE DATABASE bdd_odoo_18
			WITH OWNER user_odoo
			ENCODING 'UTF8'
			LC_COLLATE 'fr_FR.UTF-8'
			LC_CTYPE 'fr_FR.UTF-8'
			TEMPLATE template0;

/!\ ARTUNG /!\ Bicyclette et petit vélo !

Il n’est pas impossible que vous tombiez sur une erreur de ce type « invalid LC_COLLATE locale name« . Cela signifie que tu vivras ta vie sans aucun soucis. (Tes vraiment sûre ?) En gros, il manque le fichier de mappage de caractère au niveau système. Soit il n’est pas présent, soit il n’est pas généré.

Afin de vérifier si ce dernier est présent :

$ sudo locale -a | grep fr

Si cela ne retourne rien c’est que le packet ne doit pas être installé. Alors installons le vin diou !

$ sudo dnf install glibc-langpack-fr
$ sudo locale -a | grep fr

Surprise le fichier de mappage est présent ! Si nous rejouons la requête, cela fonctionne.

Attribution des privilèges et rôles

Comme tous systèmes de base de données, un incontournable reste la notion de rôle et de privilège.

Dans la pratique, il convient et je sais que j’enfonce une porte ouverte d’adopter la bonne pratique de créer des rôles et d’affecter les rôles aux utilisateurs. Un rôle sur la BDD en modification, en lecture, superutilisateur ect.

Ainsi et c’est d’une logique implacable, si modification il doit avoir, je ne modifierai QUE le rôle et non utilisateur par utilisateur. MALINX le LYNX…

Rôles

Par défaut, nous retrouvons :

Toujours dans le spoil (parce que je suis un mec underground moi. MOUMOUNIGAN !) je vais créer un rôle pour ODOO qui permettra uniquement de se connecter, de créer une bdd avec un mot de passe.

postgres=# CREATE ROLE r_odoo LOGIN CREATEDB;

Pour attribuer le rôle à un utilisateur (en prenant toujours le cas ODOO avec notre role r_odoo et user_odoo) :

postgres=# GRANT r_odoo TO user_odoo;

Privilèges

La notion de privilèges que ce soit sur la BDD, les tables où les schémas suivent le principe de SQL. Ainsi il suffira d’user des commandes GRANT accompagner de :

• CONNECT ON
• USAGE
• SELECT ON ALL
• SELECT, INSERT, UPDATE, DELETE
• ALTER
• DROP
• …

Il est important de prendre en compte que le propriétaire de la BDD a tous les droits.

Toujours dans notre exemple ODOO, il n’y aura donc pas de privilèges à appliquer.

PostgreSQL Client

Il existe un outil que j’ai découvert à travers un case chez VEEAM pour un problème de protection O365 du nom de pgAdmin. Cette solution officielle est l’outil graphique pour administrer PostrgreSQL.

Je pense important de présenter cette dernière car dans le cas où nous ne nous serions pas SQL native language ou seconde langue. Cela nous permettrait de bien comprendre certains dysfonctionnements ou structures.

L’installation n’est pas en soi bien complexe… Ma grand-mère y arriverait sans difficulté. Toutefois, je glisse le tips…

Certains pourrait dire, oui c’est un PHPMyAdmin. Oui c’est un fait. C’est une IHM¹² en GUI¹³ pour faciliter l’expérience quotidienne.

Pour se connecter, il suffira de renseigner les informations de connexion et de s’assurer au préalable que la politique de communication est bien présente sur notre UTM concernant les flux interlans. Sans oublier de vérifier :

• La configuration du fichier pg_hba.conf est compliante
• Les adresses d’écoutes dans le fichier postgresql.conf ne sont pas restreinte cas localhost et que le bind d’interface est bien configuré. (Le bind c’est l’ip de l’interface du serveur, pas l’adresse ip du client… Je dis ça parce que je vous vois venir hein !)

Et si nous jetions un coup d’œil dans le viseur pour observer nos logs voir si on voit notre pachyderm numérique ?

$ sudo tail -f /mnt/database/postgresql/data/log/postgresql-Wed.log

Impeccable. Tout fonctionne 🙂

Conclusion

Ce billet revient aux prémices des premiers articles rédigés il y a maintenant quasiment deux ans. Quelques choses de simple qui vise à jouer les aides mémoires de ma cafetière qui commence à s’effriter.

Je ne tenais pas à me lancer dans un benchmark de « Est ce que l’otarie et plus fort que l’éléphant ? » cela ne m’intéresse pas le moindre du monde. Toutefois et comme j’ai pu l’aborder en avant propos, le tournant des éditeurs vers la solution PostgreSQL mérite de s’intéresser à cette dernière.

• VEEAM enchaine sa rupture technologique avec Windows (SE¹⁴ et/ou MSSQL) pour RHEL et PostgreSQL
• ODOO qui reste dans la philosophie du libre
• La Société Générale (faut bien renflouer les caisses après le passage de Jérôme KERVIEL… Ok, la blague est mauvaise, mais il fallait la faire. Trop tentante).
• Patrick BALKANY pour gérer son patrimoine non déclaré. Ah non autant pour moi c’est une fake news… Que je suis naïf 🙂

Au delà des deux derniers points douteux, il est bien je pense de se garder deux SGBDs relationnels sous le coude les solutions MariaDB et PostgreSQL. L’implémentation de la couche de sécurité relève d’un défi parfois mais reste nécessaire et plus qu’indispensable de nos jours.

Il manque toutefois un point que je n’ai pas développé ici. La possibilité de sauvegarder une base de manière périodique. J’avais traité le sujet pour MariaDB à la suite d’une connerie de ma part un vendredi aprem sur l’environnement de production. Je pense qu’il serait bien de reprendre ce projet et de l’adapter pour PostgreSQL 🙂

Ca fait un sujet supplémentaire à traiter d’ici la fin d’année. Mais surtout, le levé de voile ayant été fait un poil plus tôt ce billet est le tremplin pour l’implémentation d’ODOO comme mon ERP à venir.

Le mot de la fin :

Egaré dans la base de données infernale, le sysadmin se nomme R-ONE. A la recherche du datalocation, le problème s’appelle la durcification. Avec la solution VEEAM, il a pu rollback super vite. Dérivant à dos d’éléphant, R-ONE arrivera toujours dans l’étang… (faut bien se mouiller un peu qu’ils disaient les anciens)

Erwan GUILLEMARD

Sources

• PostgreSQL Secteur par OS
• PostgreSQL – Main Apps Guide
• PostgreSQL – Download
• PGAdmin – Download
• MariaDB – Hardware Requirements

1. SGBD : Système de Gestion de Base de Données ↩︎
2. BDD : Base De Données ↩︎
3. LSD :  LySergique Diéthylamide ↩︎
4. ANSSI : Agence Nationale de Sécurité des Systèmes d’Informations ↩︎
5. DMZ : Demilitarized Zone ↩︎
6. RTFM : Read The Fuck*ng Manual ↩︎
7. OS : Operating System ↩︎
8. RSSI : Responsable Sécurité des Systèmes d’Informations ↩︎
9. SysDBA : Administrateur des Systèmes de Bases de Données ↩︎
10. UTM : Unified threat management ↩︎
11. ESN : Entreprise des Services Numériques ↩︎
12. IHM : Interface Homme Machine ↩︎
13. GUI : Graphical User Interface ↩︎
14. SE : Système d’Exploitation ↩︎

Si hardened est un bien vilain mot, immuable ne vaut pas mieux. Et à chaque fois que j’ai évoqué ces termes à quelqu’un j’ai dû donner une définition.

Qui demeure inchangé, ne subit pas ou ne paraît pas subir de modification pendant un temps relativement long

Dictionnaire Larousse

Le titre de ce billet ainsi que les multiples appels du pied du précédent article technique sur VEEAM, ne laisse pas de doute quant au fil conducteur de ce feuillet technique.

Nous aborderons ici la sauvegarde dit immuable ou inaltérable pour répondre à l’un des bonnes pratiques et recommandations de la sauvegarde.

Prérequis

• SE : Ubuntu Server 20.04 LTS
• Apps : VEEAM B&R 12.1
• Autres :
  • Environnement GNU LINUX Durci
  • VEEAM B&R 12.1

Avant Propos

Le pourquoi du comment de la sauvegarde Immuable ou Hardened vient d’un constat. Avec l’évolution depuis 2015 des virus de nature cryptographique, les attaquants ne s’amusent plus à effacer toutes traces d’un SI (car c’est moins drôle de nous jours ce coup de HOCUS, POCUS) mais de chiffrer ce dernier de virer les sauvegardes et de tenir une situation de prise d’otage (sans permettre un syndrome de Stockholm) et de chantage à divulguer les données d’entreprise sur le Dark & Deep Web. Toutefois, les rançons demandées dans la grande majorité des cas sont indexées sur le CA des sociétés piègés ou de la nature critique des données extorquées…

Alors il y a bien des techniques, mécanismes pour assurer une sauvegarde hors ligne. L’une des plus vieilles à ma connaissance reste la sauvegarde sur bande (Tape). Même si cette dernière comme le langage COBOL était amené à mourir car dépassé par notre évolution technologique. Force est de constatée, que cette technologie reste l’un des mécanismes fiables pour assurer une sauvegarde hors ligne. Il y a bien la sauvegarde sur média externe (pour ne pas dire HDD) qui fonctionne très bien. Mais ce genre de solution, voyez vous, ça rentre parfaitement dans le cadre d’une PME ou d’un SI local (pour ne pas dire OnPremise) qui n’a pas un SI avec des fluctuations de stockage à la hausse. Pour résumer, comment assurer la sauvegarde déconnecté dans un datacenter ou une infrastructure qui peut être amené à grossir rapidement ?

Je vois (c’est mon point de vu. Si vous n’êtes pas d’accord, je suis prêt à échanger sur le sujet) les avantages et inconvénients suivants :

« Ouai mais qu’est ce que tu fais du Stockage Objet, des buckets toussa toussa ? C’est bien inaltérable non ? »

Oui et non. Je n’ai pas encore eu le loisir de jouer avec les stockages objets S3 ou d’autres technologies qui se base sur ce standard. Avant toutes choses, il est je pense important de se poser la question de la nature des données que nous souhaitons sauvegarder. Il y a des avantages et des inconvénients au type de sauvegarde en blocks et objets. Certains types de données sont plus favorables à l’un ou l’autre des technologies de sauvegarde. Bref, spoiler c’est un billet en réflexion et sur lequel je me dois de me motiver (à coup de grand coup de pied au c*l car je suis à l’ouest du néant en ce moment).

Bref, si nous rattrapons notre fil d’ariane, je vois dans une cloud privé un facilité à choisir la sauvegarde hardened sur un serveur dédié. Si le SI augmente et que nous devons ajouter des ressources des nœuds supplémentaires, j’ajoute un nouveau repo. Si mon SI diminue, je recycle mon serveur de repository pour un autre usage. Seul hic, cela demande de bonnes compétences en GNU/LINUX (mais cela est il vraiment un frein ? Les compétences ça s’acquiert non 🙂 ).

Pour ce billet, je vais tricher un peu. N’ayant pas de repo physique sur mon lab (et que mon lab tiens à mon poste perso), nous partirons d’un serveur virtuel qui « jouera » le rôle de notre repo physique.

Ce dernier sera sur un SE¹, Ubuntu Server 20.04 LTS² durci préalablement selon le guide de recommandation de l’ANSSI³. Un disque pour la sauvegarde est dédié, monté et formaté en XFS⁴.

Euh Question M’sieur GUIGUI ! Toi qui nous rabache du RHEL matin, midi et soir. Pourquoi d’un coup tu pars sur un Ubuntu ? Ca t’a pris comme un envie de ch**r de changer de distrib ?

A cette question, je répondrai tendrement qu’il s’agit simplement et tout bonnement des prérequis de l’éditeur VEEAM. Sinon, la question n’aurait pas eu lieu :rhel: (pour ceux qui ont connu le :noel: ).

Fin de l’avant propos, place à la lecture du menu avant de mettre un coup de fourchette.

Théorie

Attaquons donc ce menu qui nous fait tant de l’oeil. La première question que nous nous devons de poser est « Qu’est ce que l’immuabilité ? » et la seconde question, « Comment fonctionne t’elle ? »

Introduction à l’ i-mmuabilité

L’immuabilité au sens UNIX du texte existe depuis le 16 Janvier 1996. Cette commande est présente dans le paquet E2fsprogs de la release 1.02. (Si je me fourvoie, merci de me le dire car j’ai du mal à trouver l’histoire de cette dernière…).

Cette commande permet de définir des attributs complémentaires sur les systèmes de fichiers dont notamment l’immuabilité des fichiers.

Pour manipuler ces attributs, nous pouvons utiliser l’ensemble des commandes suivantes :

• chattr
• lsattr
• getattr
• setxattr

Observons ci dessous l’ensemble des commandes suivantes :

$ sudo chattr +i test.txt
$ sudo lsattr test.txt
$ sudo rm -Rf test.txt
$ sudo chattr -i test.txt
$ sudo lsattr test.txt
$ sudo rm -Rf test.txt

J’ai appliqué l’attribut d’immutabilité sur le fichier test.txt et surprise, même en élevant mes droits, je ne suis pas autorisé à supprimer le document. Cela ne sera possible qu’en retirant l’attribut. Nous tenons le début de notre mécanisme.

Ouvrez le GUILLEMARD « 

Je pense après une courte nuit de réflexion que je dédierai un article sur les attributs étendus car il y a énormément de matière sur le sujet. De plus, j’ai ouvert the PANDORAS BOX (toi aussi tu te souviens des jours anciens des LANs sur AoM ? Petit canaillou de cheater va) et je me dois de boire jusqu’à la lie ce module et l’éventail des fonctionnalités qu’il propose.

«  Fermez le GUILLEMARD

Mais alors comment cette fonctionnalité va t-elle être pilotée par notre serveur VEEAM ?

V-immutability-M

Là deux possibilités. Either you speak and read english and you can directly jump to the Veeam hardened guide. Ou alors on peut regarder ensemble ma compréhension du sujet.

Après tout, je n’ai eu que 5/20 au BAC en LV1 Anglais, ça promet d’être sympa 🙂 (Si si et j’ai même pas été au rattrapage ! Et il est content…)

Bref, nous verrons plus bas lors du déploiement que lorsque nous ajoutons notre Serveur Ubuntu en tant que Single Use Credential nous allons déployer les rôles :

• Transport : (veeamtransport) pour le service datamover (port tcp/6162)
• Installer : (veeamdeploymentsvc) pour déployer l’ensemble des composants et permettre de maintenir à jour les différents composants (ports tcp/2500

Toutefois, c’est lorsque nous déclarerons notre repository en tant que Hardened repository que cela va devenir intéressant. Car c’est à ce moment que nous allons définir les paramètres de gestion de l’immuabilité sur une période minimum de 7 jours (promis je reviendrai un jour sur la magie du nombre 7). Bref une fois configuré, voilà les services les plus importants.

• VEEAM Data Mover : Ces ce dernier qui va communiquer avec notre serveur VEEAM et récupérer les paramètres de temps quant aux datas qui doivent être inaltérables. Une fois les informations en sa possession, il réalise une passe décisive au service ci dessous VEEAM Immutability Service (veeamimmureposvc), comme la passe décisive de Djorkaeff à Thuram à la 47eme minutes du match France-Croatie en 1998 (Souviens toi du 12 Juillet 1998 !).
• VEEAM Immutability Service : Va aller mettre une patate à Jean-Pierre… Promis j’arrête, Bah Pourquoi ?… Tu vas la fermer ta grande gu***e !! Ce service va vérifier sur les chaque fichiers de backup toutes les 20 minutes les attributs immuables jusqu’à ce que le date de fin soit atteinte. Ce service est un sous service de VEEAM Data Mover.

A partir de la version 12.1.0.2131, le mécanisme change avec un control, détection sur un potentiel décalage de temps.

Lorsque le VEEAM Immutability Service démarre, un fichier timeLog va être créé sous /etc/veeam/immureposvc/. Ce fichier sera mis à jour toutes les 10 minutes.

Oui mais que se passerai t-il si la valeur du moveTime ou accelerationTime dépasse 24 heures ?

Par sécurité, les données relatifs aux opérations de rétentions seront bloqués. Un message d’avertissement remontera dans la session du job de sauvegarde. Ce qui est rassurant. Oui mais voilà, comment j’unlock la situation ? Ba en suivant le KB mon gars…

Architecture

Dans les recommandations et l’un des prérequis de l’implémentation d’un repository hardened est d’avoir un équipement dédié sans surcouche de virtualisation. Nous parlons donc de serveur et non pas d’hyperviseur.

En dehors des bonnes pratiques de configuration d’un serveur, je ne m’intéresserai qu’à la partie réseau. La configuration de la partie ILO/IDRAC/IPMI ne sera pas abordée. Pourquoi ? car je n’en ai pas envie et surtout je n’ai pas les moyens de le mettre en œuvre sur mon lab. Peut être un jour dans un autre article.

Au vu de la criticité de ce que nous souhaitons mettre en place, il nous faut dissocier la partie management de la partie sauvegarde.

Avec des équipements d’infrastructures adéquates et selon la volumétrie de datas à sauvegarder, l’agrégation d’interfaces est nécessaire. Au minima SFP+⁵, au maximum FC⁶. Assurer les performances réseaux sont un fait, toutefois si le stockage ne suit pas et génère un goulot d’étranglement (bolteneck), cela ne sert pas à grand chose.

Réseau

Bien entendu, si notre Firewall gère les liaisons supérieurs à 1 Gbits/s, il y a un intérêt de faire un VLAN dédié à l’immuabilité dissocié de la sauvegarde. Dans le cas contraire et assurer de bonne performance, il conviendra de rester dans le même subnet et de passer par commutation.

Encore une fois, si nous avons de la micro segmentation, cela facilitera grandement les choses sur un même subnet. Dans le cas contraire, il sera nécessaire de définir les règles côté repo selon les interfaces, sources et destinations avec les ports et protocoles autorisées à transiter.

Lors de la configuration du repository et donc sans restriction les flux réseaux sont les suivants :

Une fois les ressources push du serveur VEEAM vers le serveur hardened (tcp:22), le service VEEAM Installer se charge d’installer et de déployer les composants (tcp:6160). Une fois les dépendances installées, la sauvegarde se déroulera à travers le service VEEAM Data Mover (tcp:6162) ainsi que le service Mount Server (tcp:2500-3000).

Soit au final nous n’avons besoin que des flux suivants :

Ok, ça c’est pour VEEAM, mais niveau serveur physique, il n’y a pas des choses à faire ?

Bien vu l’aveugle. Il sera nécessaire d’autoriser les protocoles :

Users & Permissions

Dans l’idée, il convient d’utiliser un compte utilisateur pour la sauvegarde veeam. Ce dernier aura la charge de quelques services. Ce compte ne doit en aucun cas être membre du groupe SUDO. Il l’est uniquement lors du déploiement et lors du MCO logiciel. Ensuite les droits doivent lui être retirés.

Il en va de même que l’accès au répertoire qui va contenir les sauvegardes doivent avoir des droits restreints à notre seul et unique utilisateur VEEAM que ce soit en tant qu’utilisateur et groupe.

Les droits devant être défini sur 700.

Mouai, c’est enfoncer une porte ouverte non ? Ouai ba j’ai vu des SysAdmins faire des choses à la limite de faire voir des choses terribles à un petit garçon.

Il en va de soi, mais le sticky bit on oublie. Perso, je ne comprends qu’elle serait l’utilité du sticky bit. Mais bon, si VEEAM le précise, c’est bien que certains SysAdmins ont essayés.

Chaînes, maillons, et immutabilité

Pour assurer l’immuabilité des données de nos chaines, le mécanisme qui sera utilisé sera le même que pour la Foreward Incremental avec automatiquement une active full ou une syntetic full.

Pourquoi ? Une petit schéma s’impose.

Partons du principe que nous définissions le nombre de point d’immuabilité à 7 jours. Avec une synthétique full hebdomadaire tous les dimanches.

Sauf que voilà, il y a un problème. Le premier point immuable est une full et le dernier point avant la dernière full est une incrémental (Sunday to Saturday). L’immuabilité étant défini à 7 jours les points sont donc inaltérables tant que l’échéance du dernier point incrémental n’est pas atteint. Si la full est supprimée les incréments ne sont pas utile. Donc nous devons attendre de nouveau 7 jours pour supprimer la première chaine et la création d’une troisième full.

Nous avons pas 7 points inaltérables mais 13 points.

Une fois la full réalisée le 3 dimanches nous passons à 14 points. C’est à ce moment là, une fois la full terminée et rendu inaltérable que les 6 premières points de la chaine se verront retirés l’attribut d’immuabilité puis les maillons seront supprimés (Le principe, se base sur le Grand-Père, Père et fils).

Et puis on recommence.

Donc nous avons un minimum de 7 points de rétention et un maximum de 13 points.

Un point sur lequel je n’ai toutefois pas encore fait de test, reste le traitement de l’externalisation (backup copy). Le principe de GFS doit alors être configuré. J’essaierai plus tard.

Je pense que maintenant nous avons toutes les informations requises pour passer à la pratique. Il n’est pas impossible que certaines parties ne soient pas toutes à fait complètes. Il est difficile de tout couvrir et de ne rien oublier. Mais on peut toujours échanger pour toutes questions.

Pratique

Configuration Repository

$ sudo useradd usr.veeam
$ sudo passwd usr.veeam

$ sudo usermod -aG sudo usr.veeam

$ sudo gpasswd -d usr.veeam sudo

$ sudo gdisk /dev/sdX
   * n
   * 1
   * Paramètres par défaut
   * 8300
   * w
   * y

$ sudo mkfs.xfs /dev/sdX1

$ sudo mkdir /mnt/veeam
$ sudo mkdir /mnt/veeam/hardened_repository
$ sudo mount -o rw /dev/sdX1 /mnt/veeam/hardened_repository

$ sudo chmod 700 -R /mnt/veeam/hardened_repository
$ sudo chown usr.veeam:usr.veeam /mnt/veeam/hardened_repository

Si je n’ai rien omis, nous pouvons passer à la suite et toutes les étapes devraient bien se passer. Dans le cas contraire, je vous autorise à me donner une grande tape sur l’épaule, promis je vous dirai merci pour ne pas m’en reprendre une dizaine.

Intégration dans VEEAM

Ajout du serveur Linux

1 – Scream my Name !

Dans l’onglet Backup Infrastructure, sélectionnez ajouter un serveur. Puis ajouter un nouveau serveur Linux.

Comme ci-dessous vous avez deux possibilités. Soit vous ajoutez l’IP de votre repo (absence de serveur DNS dans mon cas et flemme d’aller faire une surcharge dans le fichier host juste pour le lab) ou d’ajouter le nom DNS. Ayant plusieurs repositories, j’aime bien mettre une petite description (surtout en l’absence de nom DNS).

2 – Linux Credential (une fois seulement)

Dans la partie SSH Connection, nous n’avons pas d’entrée dans le gestionnaire de mot de passe de notre VEEAM. Et nous ne voulons surtout pas que nos informations d’authentifications soient stockées (Sinon à quoi faire du hardened ?).

Cliquons donc sur Add et sélectionnons la dernière proposition « Single-use credentials« . Normalement vous devriez avoir l’écran ci-dessous.

Si vous avez fait les choses proprement, vous renseignez le login de votre compte utilisateur propre à VEEAM avec son petit mot de passe. Dans mon cas svc.veeam et password1234 ou azerty1234. Cochez la case d’élévation de privilège ainsi que la case « Use su if sudo fails » et là, renseigner le mot de passe du compte root.

Toujours si vous avez bien fait les choses, le compte svc.veeam est à ce moment un compte membre du groupe sudo. Donc un utilisateur à privilège le temps de l’installation. Si ce n’est pas le cas, ajoutez le :

$ sudo usermod -aG sudo svc.veeam

Pour le fun, essayer de mettre en compte utilisateur le compte root. Normalement, VEEAM devrait exprimer votre nom indien avec sa main « Dresser avec le Majeur« . 🙂

3 – Actions Review

Si vous êtes là c’est que le serveur VEEAM arrive à pu initier la connexion en SSH avec notre futur repository immuable.

Les composants transport et installer vont être déployés. Ces derniers ne sont pas déjà présent sur le serveur. Pour le moment pas un faux pas !

Passons à l’étape suivante.

4 – Jamais du premier coup 😉

Bon ba nous voilà comme un con sur un quai de gare un jour de grève à la SNCF… Ca ne fonctionne pas BORDEL ! (Pourquoi tu n’as pas censurer l’injure ? Parce que je suis frustré d’avoir durci une saloperie de système GNU/LINUX dans l’état de l’art et d’avoir des erreurs de ce type. Je suis pas une base de loisir MERDE !)

Monsieur, Calmez vous ! Oui, c’est bon. Pas de castagne. LINUX et VEEAM sont sympa car ils nous donnent gentiment le message d’insulte que l’un donne à l’autre. C’est alors qu’en bon copain nous allons arrondir les angles pour que VEEAM et notre repo LINUX puissent fleurter ensemble.

L’une des mesures de sécurité que j’applique sur mes systèmes GNU en terme de durcissement est d’interdire l’exécution sur la partition /var et /tmp. Donc un petit remove de l’argument noexec et un remount des partitions et c’est repartie comme en 40 ! (Il y a quelques choses d’autres à faire mais je le garde pour moi).

On relance un Previous, puis un Next pour relancer le déploiement. Là, à la surprise générale, l’installation se déroule sans accro.

Alors elle est pas belle la vie ?

5 – Congratulations

L’installation est terminée. Les composants ont bien été déployées nous avons ci-dessous le récapitulatif.

Toutefois, nous devons remettre en l’état les quelques points de sécurité que nous avons assouplis pour permettre l’arrimage de notre repository Hardened LINUX à notre serveur VEEAM.

• Retirer l’utilisateur svc.veeam du groupe sudo
• Rétablir les arguments noexec sur les partitions /var, /tmp
• Rétablir les paramètres que l’auteur a vraiment décider de ne pas divulger

Ajout du repository

1 – Quels types choisir ?

Choisissons le type de repository pour déclarer notre repo hardened, soit Direct Attached Storage.

2 – Linux Hardened Repository

Dans les choix, j’hésite vraiment sur l’option pour notre type de repo. Peut-être la réponse numéro 3, Linux (Hardened Repository) ?

3 – Scream my Name (Again)

On note le nom de notre repo. Tachons donc de rester logique et de choisir un nom dans le standard des repositories. Pour ma part REPO_HARDENED_01. Comme j’aurais pu avoir un REPO_SVG_01 ou REPO_EXT_01. Soignons pragmatique Père UBU par ma chandelle verte !

4 – Server Selection

Le serveur ayant été ajouté précédemment nous avons le listing de chacune des partitions présentent et montée.

Dans la liste (5ème positions) nous retrouvons bien notre partition sous /mnt/veeam/hardened_repository monté sur /dev/sdb1.

5 – Choix du repository (Path)

Sélectionnons la partition qui nous intéresse.

Activons ensuite les paramètres de clonage rapide sur les volumes XFS. Je défini la durée de l’immuabilité sur 14 jours (le minimum étant 7 jours). Je limite le nombre de tâche parallélisé à 4.

Dans les options avancées, j’ai pour habitude d’activer l’alignement des blocks pour améliorer les performances quant à la sauvegarde et à la restauration malgré une légère hausse du CPU.

J’active également le paramètre d’utiliser le paramètre per machine backup files car il améliore les performances de stockage pour les équipements qui bénéficient de flux important d’I/O. Ce qui tombe bien est notre cas.

Les deux autres options ne doivent pas être cochés, puisque nous n’avons pas de support rotatif et l’option de décompression n’est pas compatible avec la sauvegarde immuable.

6 – Where is the mount Server ?

De nouveau nous avons un petit récapitulatif des rôles à ajouter ou déjà présent sur notre repo.

• Transport
• vPower NFS
• Mount Server

Il est possible de cocher la case de recherche de chaine existante. Ce n’est pas notre cas.

7 – Applying

Nous appliquons la configuration de notre repo. Deux avertissements toutefois. Dû au durcissement de mon SE GNU/LINUX. Toutefois rien de bien méchant car on regarde l’avertissement lié au service de déploiement.

8 – Petit Résumé

Encore une fois, le petit récapitulatif nous informant que le repo a bien été créé.

Backup Job & Tests

Pour ce point, je ne vois pas de grand intérêt à décrire comme créer un jobs de backup. C’est pourquoi j’irai à l’essentiel, un en mot un seul, pour être succinct, sans détour et fioriture, bref j’irai droit au but…

Pourquoi cette entrée en matière dans cette partie ? Simplement car cela dépend de la source sur laquelle le serveur de sauvegarde se base.

• VMWare VCenter
• VMWare ESXi
• NUTANIX Prism Element
• NUTANIX Prism Central
• MICROSOFT HyperV
• VEEAM Backup Agent
• etc

La liste pourrait s’allonger comme un jour sans pain au vu du nombre de point d’entrée OnPremise et Cloud.

Dans mon cas et sur mon petit environnement de lab, ça sera sur un job de sauvegarde pour du VEEAM Backup Agent pour Windows (en Guest Processing) d’un serveur local.

Backup

Nous considérons qu’un compte d’administration est déjà présent pour la sauvegarde est durci dans les règles de l’art et que le serveur source se trouve dans la bonne configuration pour être sauvegardé.

1 – Storage

Dans la partie Storage de notre job (peut importe le type), il nous suffit de sélectionner notre repository hardened.

Le nombre de point de rétention doit être en adéquation avec la politique d’immuabilité en place comme décris dans la partie théorique. Dans mon cas 14 jours.

2 – Storage GFS

La sauvegarde hardened se base sur le principe GFS⁷. Effectivement et comme une nouvelle fois expliqué précédemment, il n’est pas possible et cela n’a pas de sens de faire de la RI⁸ mais bien FI⁹.

Je défini donc de réaliser une full backup synthétique de manière hebdomadaire, le 7 jour de la semaine, 7 jour où le Seigneur exténué (comme moi d’ailleurs) d’avoir travaillé si dure les 6 jours précédents de prendre un jour de repo. Et comme la sauvegarde est là pour nous prémunir de tout aléas

Les premiers seront les derniers, et les derniers seront les premiers

Marc 10:31

Nous pouvons faire confiance à Saint Marc. Amen.

Laissons notre job tourner et admirer les performances et actions en cours.

Tests

Une fois le job terminé avec succès. L’une de nos grandes questions que nous devons nous poser en tant que SysAdmin (et que n’importe quel client, chef d’entreprise doit se poser) est « Comment s’assurer que la chaine de sauvegarde est bien inaltérable, immuable ? »

Le plus simple, c’est de supprimer la chaine de sauvegarde ou l’une des ressources protégées. Normalement, dans la boite de dialogue se préparant à l’exécution de la suppression, vous devriez avoir un violent message d’avertissement vous informant que NON, VEEAM ne veut pas. Mais comme VEEAM n’est pas si en désaccord avec votre volonté de supprimer le backup, il vous donne toutefois la date d’échéance où il sera possible de supprimer la chaine si et seulement si le job est désactivé naturellement.

Si nous voulons allés plus loin, c’est du côté repo qu’il faudra contrôler que l’attribut d’immutabilité est bien positionné sur nos fichiers. Un petit coup de lsattr et le tour est joué.

Altérer l’inaltérable ?

Super cette sauvegarde immuable ! Avec ça, nous sommes paré à toutes éventualités contre la suppression et altération de nos chaines de sauvegarde.

Sauf que ce n’est pas tout à fait vrai. Désolé de vous mettre un stop. En haut de ce billet, j’ai insisté sur la topologie et l’architecture. Tout va reposer sur cette dernière pour ne pas altérer le contenu de votre repository hardened.

Avant de rentrer plus dans les explications, je rappel dans le contexte que le système GNU est durci. Le compte utilisateur dédié à la sauvegarde n’a pas de droit d’élévation, le daemon ssh est désactivé.

Allez, faut y aller, oui mais où ? Maintenant rentrons dans le vif du sujet.

En me connectant directement à mon repo en console ou en direct. Regardons nos différents maillons de chaines pour notre job. J’ai deux full. Pourquoi ? Parce que je suis un abruti qui lors du la configuration de mon job, j’ai oublié de chiffrer ma chaine. M’en rendant compte après coup, j’ai donc corrigé ce petit détail. Sauf que activer le chiffrement d’un job implique forcément de repartir sur un full. Merdouille non ?

Alors comment faire pour supprimer le premier maillon .vbk qui est indépendant de mon second .vbk ?

• Je suis patient et j’attends 28 jours
• Je supprime le point au niveau système et je clean ma configuration

Pour le coup je ne serai pas patient et je vais donc contourner l’immuabilité.

1. Je liste uniquement les maillons de la chaine qui sont des fulls (.vbk) afin d’identifier le point que je souhaite faire disparaitre
2. Etant en root, je retire l’attribut d’immuabilité sur le fichier
3. Je liste de nouveau les attributs des maillons de la chaine qui sont des fulls (.vbk) pour vérifier que c’est bon
4. Je supprime le fichier
5. Je liste de nouveau les attributs des maillons de la chaine qui sont des fulls (.vbk) pour vérifier que je n’ai plus qu’un fichier vbk

Nous nous déconnectons de notre console. Et regardons notre chaine côté VEEAM Ordo.

Là j’ai été un vite en besogne car j’ai déjà nettoyer la configuration. Mais notre point remontait comme inaccessible car nous l’avons supprimé (petite icone rouge et police en italique). Mais une fois nettoyé, nous avons 4 points en lieu et place de 5.

Donc il est possible d’altérer l’inaltérable sous certaines conditions.

Conclusion

La sauvegarde immuable ou hardened est vraiment une solution indispensable des organisations. Cette dernière ne doit pas être négligé. Malheureusement et c’est là un triste constat les organisations et entreprises pour des raisons de coût néglige cette protection supplémentaire.

« J’ai déjà une sauvegarde et une externalisation, je ne risque rien. Mon Service interne est parano ou Mon prestataire informatique me prend pour une vache à lait »

Ce sentiment de puissance, de confiance et d’invincibilité pourtant ne tiens qu’à un fil et c’est lorsque ça tourne mal qu’il nous reste plus qu’à pleurer en regardant comme Loth, sa femme pétrifié de sel (Genése 19:26). Attention, la facture est salée.

Toutefois, l’implémentation d’un tel système nécessite des aptitudes avancées pour les systèmes LINUX/GNU ce qui peut représenter un frein à la mise en place de ce dernier. Notamment sur la partie durcissement. A cela peut s’ajouter des budgets ainsi que des ressources limitées sur l’infrastructures ne permettant pas d’assurer cette fonctionnalité.

Il reste à moindre cout l’usage et l’implémentation d’une sauvegarde sur disque externe. Cependant je pense que cette solution est moins performante, plus espacée dans le temps, moins adapté à l’évolution du SI et soumis au risque humain (oublie, corruption, etc). Mais cela reste une solution.

Encore une fois la question de curseur se pose sur le rapport bénéfices risques. Qu’est ce que je suis prêt à accepter pour mon organisation ? Il suffit d’avoir frôlé la banque route ou d’avoir dans ces connaissances un patron qui a perdu son entreprise ou sauver de peu son business pour se sentir concerné.

Ouai mais tu nous as démontré que ce n’était pas inaltérable à 100%. Tu ne serais pas en train de nous refourguer une solution pour éviter le bug de l’an 2000 ?

Oui je conçois et l’ai démontré. Nulle solution n’est parfaite est sécurisé à 100%. Toutefois les opérations pour retirer l’immuabilité nécessite de passer plusieurs mécanismes de sécurités et le risque bien de présent est minime voir nul. Disons que si un individu malveillant s’attaque à la sauvegarde immuable, normalement l’équipe interne ou le service IT seront informés car c’est le point d’entrée le plus complexe à infiltrer. Et donc, cet individu aura pris le temps de mettre un joyeux bor**l sur l’ensemble de notre infra au préalable.

Nous pourrions également dire que 7 jours ou 14 jours d’immuabilité c’est peu. Et pourtant il faut voir cette sauvegarde comme l’as dans la manche qui nous sortira de l’échec et compromission de notre sauvegarde et externalisation. C’est une sauvegarde certes, mais la dernière carte à jouer. Sincèrement, vous SysAdmin/DSI persuadez votre DG, DAF ou PDG d’implémenter cette fonctionnalité.

Rare image d’échange entre un DAF avec un DSI/SysAdmin concernant le budget informatique

Vous DG, DAF ou PDG, écoutez votre SysAdmin/DSI et permettez lui de passer des nuits tranquilles loin des valium, tranxène, nembutal (ouai je sais ça faut beaucoup de référence à HFT, mais je suis dans ma période de vilain garnement 🙂 ).

Le mot de la fin

Consonnes, Voyelles. Je demande un 50/50 sur une garde sans. Risquez comme opération, mais ça passe et vous partez avec Maïté car votre préféré c’est le rondelé.

Erwan GUILLEMARD

Sources

• Définition Immuable
• VEEAM B&R 12.1 – Hardened Guide
• Linux – chattr
• E2fsprogs

Je remercie LLU, d’avoir su me mettre sur la voie et d’avancer sur ce sentier.

1. SE : Système d’Exploitation ↩︎
2. LTS : Long Time Support ↩︎
3. ANSSI : Agence National de Sécurité des Systèmes d’Informations ↩︎
4. XFS : X File System ↩︎
5. SFP+ : Small Form-Factor Pluggable+ (10 Gb/s) ↩︎
6. FC : Fiber Channnel ↩︎
7. GFS : Grand Father, Father, Son ↩︎
8. RI : Reverse Incremental ↩︎
9. FI : Forward Incremental ↩︎

Mon binôme et moi-même rigolions à quelques blagues potaches de ma part. Tout allait bien. J’enchainais dans notre solution ITSM¹ les requêtes SQL²/OQL³ avec des gros mots comme DROP, DROP CASCADE. (Vous le voyez le drame qui arrive ? Iceberg droit devant !

Attention spoiler, ça ne va pas se terminer avec l’anneau dans le volcan !).

Un collègue passe m’avertir qu’il ne peut plus traiter de ticket. Je me souviens lui avoir répondu avec un aplomb digne d’un politicien que c’était normal. Pourquoi s’arrêter en si bon chemin dans l’exécution de mes requêtes, il n’y a pas de message d’erreur ? Tant que je gagne je joue ! xD

J’ai un peu moins rigolé quand deux minutes montre en main le responsable du centre de service m’a indiqué que s’il y a quelques minutes nos collègues ne pouvaient plus s’assigner de ticket, cette fois si, ils n’existaient même plus et ne pouvaient plus sélectionner leur nom sur l’interface WEBUI⁴.

Pour vous résumer mon état :

Si ça en a le gout, la texture et l’odeur. C’est que s’en est !

Ce n’est pas de moi, mais l’auteur je l’espère se reconnaitra

Avant de poursuivre ce conte digne des frères GRIMM, je souhaite dans cet article vous faire part d’une situation particulière à la limite du critique, de la réflexion pour corriger cette situation et des solutions pour se prémunir d’une potentielle récidive. Chassez le naturel, il revient au goulot…

Prérequis

• SE: RHEL, DEBIAN, UBUNTU
• Apps: bash, crontab, Mariadb/Mysql
• Autres: Au moins une base de données, Apps – MUTT

(Reprise de l’histoire)

Effectivement, j’ai bien « défoncé » quelques tables et jointures. L’application ITSM colonne vertébrale de notre organisation n’est plus fonctionnel. Il est 15h00 et l’ensemble des équipes sont à l’arrêt. Paradoxalement, j’aurai dû continuer de passer des requêtes SQLs car si nous ne pouvions pas traiter les demandes et incidents des utilisateurs, ces derniers pouvaient créer des tickets.

A ce moment, nous avions bien identifié l’origine du dysfonctionnement (1m98, 85 kilos… oui mais pas que). Nous envisagions mes collègues et moi une once d’espoir pour faire machine arrière quant à mes actions sur la base de données.

C’est un peu plus difficile quand j’ai annoncé ne pas avoir noté toutes les requêtes que j’avais exécuté, et que les journaux de logs sont vides.

Pourtant, personne ne doit travailler le vendredi après midi, le vendredi après midi on est bleu. La décision est prise. Il va falloir restaurer la base de données.

Réunion de crise

Récapitulons donc la situation, la production est hors service. Nous ne pouvons pas revenir en arrière, la production continue de tourner et à cette époque nous avions un fonctionnement particulier avec l’un des nos clients pour lequel notre outil ITSM était « master » d’un seconde instance ITSM satellite « slave » avec des synchronisations. Bref, un truc super mais sensible en cas de non respect du cycle de vie des tickets.

En dehors du cas singulier précédent, il faut savoir que dans le fonctionnement de notre organisation, nous avons des engagements de résultats sur le traitements des demandes et incidents (SLA⁵, OLA⁶, SLR⁷ etc).

Revenir en arrière en restaurant la base de données, oui mais sans perdre les tickets et requêtes utilisateurs en cours.

A quelle heure pouvons nous donc restaurer la BDD ? Encore une fois c’est là où le bât blesse. Nous n’avons pas de dump de la base… (Nous voici donc au volant d’une voiture qui roule à vive allure, nous pensons que tout va bien puis que d’un coup nous découvrons que l’assurance n’est pas à jour. Que l’ensemble des témoins du tableau de bord s’allument tous comme un sapin de Noël et que les freins vont surement lâchés.)

Nous décidons de contacter l’éditeur qui malheureusement ne peut rien faire pour nous dans le contexte et arrive à la même conclusion que nous. La restauration en date de la veille et inéluctable.

Nous réalisons toutefois un export de l’ensemble de toutes les requêtes créés, modifiées entre le matin même de 06h00 à 18h00 sur l’environnement ITSM de production ainsi que sur l’environnement ITSM satellite du client, puis coupons les services. De mémoire, cela représentait un volume de 300 tickets environ.

Excès de confiance

Pourquoi cette situation ? Pourquoi ce changement n’a-t-il pas été soumis à un CAB ? Si vous avez pris un peu le temps de lire d’autres articles ou de lire ma présentation, je suis quelqu’un de malchanceux marqué du signe du chat noir ascendant Pierre RICHARD (mais je le vis bien je vous rassure). Nous avions initialement mon collègue et moi pour objectif « d’alléger » notre base de données de production. C’est pourquoi, dans le cadre du contrat de support et d’assistance avec l’éditeur, après une analyse commune, nous avions établit une liste de requête précise.

Toutefois et par prudence, il était impératif de tester sur notre environnement de test/préproduction à ISO périmètre de l’environnement de production les dites requêtes. Chose qui a été réalisé par mes soins sans rencontrer la moindre complication ou dysfonctionnement. Le résultat est positif, tous les voyants sont verts. Pourquoi ne pas appliquer les modifications sur l’environnement de production ?

C’est là, que ça ne va pas. L’environnement de préproduction ne fonctionne pas à ISO périmètre de l’environnement de production. Ce dernier est sans cesse sollicité se qui n’est pas le cas de l’environnement de préprod. (C’est diabolique). Et donc, l’application des requêtes ont générés d’autres erreurs. L’outil ITSM m’a gentiment proposé de corriger les dîtes erreurs. Je suis donc sortie allégrement du contexte de mon changement sans m’en rendre compte.

Je pensais maitriser mes actions et n’ais à aucun moment pensé qu’il s’agissait d’un changement ! Il a suffit d’un excès de confiance. Pour mettre à genoux l’organisation (rien de bien dramatique en soi quand nous voyons aujourd’hui l’impact d’un crypto, ce n’est pas du tout le même impact).

Mais vous savez même si la chat et noir, il a toujours quelques poils blancs dans son pelage 🙂 L’incident tombant un vendredi, il nous reste le week-end pour trouver une solution.

Plan d’actions

C’est incroyable de se dire que l’action d’un individu à impacté l’ensemble des services et nécessité cinq collaborateurs de trois services différents. Néanmoins, personnes n’a été malveillant à mon égard à ma grande surprise. Nous étions une équipe face, un bloc face à l’incident en cours.

Nous avions donc défini le plan d’action suivant :

• Restauration du serveur de base de donnée à la veille dans un environnement isolé
• Réalisation du dump de la base de données
• Exportation de la base de données
• Désactivation de l’appareillage entre l’ITOP master et le satellite (slave)
• Importation de la base de données sur l’environnement de production
• Réalisation des mêmes actions côté ITOP satellite
• Réactivation de l’appareillage entre les deux ITOP
• Reprise des requêtes côté satellite depuis le fichier CSV exporté plus tôt
• Reprise des requêtes côté master depuis le fichier CSV exporté plus tôt

Sur le papier cela sonnait bien. Et pourtant encore nous allions buter sur deux points bêtes. C’est toujours quand nous sommes dans l’embarras (pour ne pas dire dans la m***e) que nous nous rendons compte de la réalité des choses.

• A l’époque, dans une console VMWare (version 5.5 de mémoire) il était ardu de taper certains caractères spécifiques. Nous avons buter pendant 30 minutes pour saisir le caractère « @« .
• Lors de l’import d’un dump existant ITOP, lors de l’application d’un setup il est nécessaire de supprimer l’intégralité d’une table VIEWS. Nous ne le savions pas à l’époque… (J’ai dans mes tablettes un article en cours à ce propos). Nous ne sommes pas SysDBA, mais nous avons tout de même réalisé le STATMENT qui va bien. (Malgré tous ces péripéties, ils t’ont laissé faire du SQL ? Non je vous rassure j’étais sous tutelle 🙂 ).

Reprise des données

La diversité des tickets et les différents paramètres des ces derniers allaient rendre difficile l’automatisation de réimport des requêtes. Il ne suffit pas de reprendre les tickets, il est nécessaire de leurs appliquer un « stimulus » afin que les notifications, SLA, le cycle de vie etc s’appliquent. L’éditeur nous avait prévenu quelques heures auparavant qu’il allait falloir user d’huile de coude.

J’ai eu à cœur d’assumer ma faute et de porter la responsabilité de cet échec. Si mon binôme n’était pas disponible samedi pour m’aider il l’était dimanche. Toutefois, j’ai fait tout ce qui était possible pour qu’il n’ait rien à faire.

Sur les 300 et quelques tickets, il aura dû en traiter une vingtaine et c’est je crois toujours 20 de trop. A grand coup de copier/coller, 270 tickets il faut compter à peu près 19h. (J’ai oublié de préciser que ma femme m’a mis un savon le soir comme quoi il est interdit de faire des changements le vendredi, blablabla. J’ai encore le souvenir de la voir partir le samedi soir avec ces copines et revenir tôt le dimanche matin. Ca fait ne me rajeunit pas).

Dénouement et fin

Le lundi matin, tout était de nouveau fonctionnel. Le week-end a été long et les heures de sommeil rares. Toutefois, « la bêtise » était assumée. Un nombre incalculable de « Je suis désolé », « Veuillez accepter mes excuses » auprès de mes collègues ont eu lieu. Il me semble que cela les a plus agacé que l’incident en lui même. (Effectivement le gars qui se là joue Les 120 journées de Sodome c’est usant).

Le plus beau, restera qu’aucun de nos clients n’a remarqué l’incident et le changement des SLAs de quelques heures. Si quelques interlocuteurs clients l’ont remarqués ils n’ont pas demandés plus de compte que cela.

Un REX⁸ a eu lieu en comité et nous avons su pointer les points qui devaient être améliorer. Le plus gros étant de s’assurer au moins un dump de la base de données entre deux points de sauvegarde. Oui mais comment faire et surtout par où commencer.

Réflexion

A la suite de la petite histoire ci-haut, qui commence mal mais qui se termine plutôt bien. L’une des premières questions que je me suis posé est qu’est ce que propose ITOP ? Est ce que la solution embarque un système de sauvegarde, de dump de base de données ?

La réponse est oui ! Mais ça ne me convient pas !

Mais il est jamais content se type. Il y a des solutions mises en place par l’éditeur dans sa solution et ça ne lui convient pas. Je le vois déjà écrire « Oui je veux pas réinventer la roue, mais… ». Tu serais pas un SysAdmin frustré par hasard ? Qu’est ce qui a ?

Pour le coup le contexte est différent. Si nous reprenons l’architecture 2-tiers (Apps – iTOP), nous avons d’un côté notre serveur web et de l’autre notre serveur de BDD. Jusque là pas de problème.

Ce qui me gène dans l’outil mise à disposition pour COMBODO, c’est que le stockage des dumps se fait du côté où est exécuter la commande mysqldump. Soit côté Front et donc stocké dans le répertoire web itop (/var/www/html/portail.erwanguillemard.com/data/backups/).

En quoi ça te gène ? En réalité il y a plusieurs points.

• Espace disque : Il existe un risque de saturation de l’espace de stockage du serveur web et de la partition /var/. La saturation de la partition (ou du disque) peut (plutôt va) rendre inaccessible le portail web. (Tu connais les hardlinks ?)
• Sécurité : Stocker les dumps de la base de données de production sur le serveur front publié vers l’extérieur représente un risque en cas d’intrusion donc de vulnérabilité et de vol de données dans le pire des cas
• Granularité : Possible uniquement de ne garder que 5 points de rétentions du lundi au vendredi à partir de 23:30.
• Mécanisme : Ce dernier est propre à ITOP est non pas une couche hors de l’application. Que se passe-t-il si le front reboot lors de la tâche de backup ou si le réseau est indisponible, si l’application est indisponible ?

Donc si nous te comprenons bien, la fonctionnalité est naze ? Non, loin de là. Au contraire, je trouve que c’est une excellente fonctionnalité car elle permet pour les petites bases de données de réaliser un dump dans les meilleurs délais et de ne pas avoir à se connecter directement au serveur backend. De plus, il est possible de réaliser une restauration directement depuis le portail ITOP (webui).

C’est à partir de ce constat que j’ai décidé d’écrire ma lettre au Père Noël (ou Saint Nicolas suivant notre situation géographique).

Petit Papa Noël, 

J'ai été bien sage en ce début d'année 2019 même si j'ai fait une petite boulette. Afin de ne pas reproduire cette bêtise, je souhaiterai avoir une solution qui réalise les points suivants :
* Un outil qui réalise 2 dumps par jour ou plus (automatisation)
* Un outil qui envoi un mail en cas de succès ou d'erreur du dump
* Un outil qui puisse avoir une fonctionnalité de dump manuel
* Un outil qui soit GENERIQUE et s'adapte à n'importe quelle base de données MySQL/MariaDB.
* Un outil qui fonctionne sous GNU (RHEL et DEBIAN) en bash.

Merci Père Noël, je t'aime tu es le meilleur.

Bisous, 

Erwan

Hélas, je n’ai toujours pas eu de réponse à ma lettre. A croire que ma « boulette » n’était pas si petite que ça… Ce n’est pas grave…

Allez, on est pas des manches, on se relève les manches et… BANZAÏ !

Merci Groland

Configuration et installation du Script

Bien qu’initialement, l’outil que j’ai développé venait répondre à un besoin professionnel, la version présentée dans cette article a pour seul lien que le contexte et a été développé, testé sur mon temps personnel.

Lecture du script

Comme toujours nous positionnerons le script à la racine du système de notre serveur SGBD dans un répertoire à part avec des droits spécifiques. L’objectif étant de toujours garantir un niveau de sécurité suffisant et d’éviter une escalade potentielle des droits.

J’insiste sur ce point, l’ensemble des actions ci-dessous sont à réaliser sur le serveur backend.

$ sudo mkdir /script
$ sudo mkdir /script/SS_015-LINUX_MYSQL_DUMP-BDD

Editez le fichier ou copiez le fichier suivant : SS_015_E_LINUX_MYSQL_DUMP-BDD.sh

A ce jour le fichier en version E est construit de la manière suivante :

• Les constantes
• Une fonction vérifiant les prérequis
• Une fonction réalisant le dump de la base de données
• Une fonction assurant la rotation des fichiers de dumps suivant le nombre de points de rétention définit
• Une fonction pour préparer le mail
• Une fonction d’envoi de mail
• Une fonction pour forger le mail en html

Je vous propose de parcourir ensemble le script, fonction par fonction. L’objectif étant de partager ce bout de code et peut être pouvoir le soir me coucher en me persuadant que quelques parts, sur le SI d’une organisation ce bout de code, maigre contribution personnel fonctionne… Laissez moi un peu rêver ou alors dites vous que vous m’en vendez (du rêve naturellement) !

1 – Les constantes

Les noms des variables sont normalement explicites. Pour éviter toutes ambiguïtés :

• _modeHTML : Pour avoir des bô rapport en HTML
• _author : Pour afficher dans le rapport le nom du créateur
• _version : Pour la version du script
• _dateRelease : Pour la date du script (dernière modification)
• _mailTo : Contient l’email du destinataire qui va être spamé de mail
• _pathLogRepository : Emplacement où seront stockés les logs à chaque exécution du script.
• _pathLogFile : Nom du fichier de log
• _pathBDDRepository : Emplacement où seront stockées les dumps
• _nbRetention : Nombre de dump à conserver
• _dbName : Nom de la base de données concerné par le traitement
• _dbUser : Nom du compte Mariadb/MySQL qui sera autorisée à réaliser le dump de la BDD
• _dbPassword : Mot de passe du compte renseigné précédemment

2 – Fonction : Check Prérequis

Cette fonction à pour objectif de vérifier et de contrôler que toutes les conditions nécessaires au bon déroulement du script soient présentes.

• Création du répertoire de log si absent
• Création du fichier de log si absent ou différent

• Création du répertoire des dumps 1/2 et 2/2 journalier

Si et seulement si les conditions sont présentes alors le script fera appel à la fonction suivante dumpCreate.

« J’ai une question bête ? C’est quoi ta variable $codeArg et la commande tee ? »

Il est important de se rappeler « il n’y a pas de question bête, il n’y a que des réponses stupides« .

Lorsque j’ai écrit ce bout de code il y a 4 ans, je souhaitais offrir la possibilité de réaliser l’automatisation des dumps mais de garder la possibilité de lancer manuellement un dump sans à avoir à taper la commande mysqldump, le login et le mot de passe.

De ce fait, si nous appelons le script :

• Sans argument : Réalise un dump de la base de données à l’instant T
• Avec argument (MidDay ou MidNight) : Réalise un dump de la base de données dans un répertoire spécifique. A son intérêt si appelé dans une tâche planifiée.

La commande tee offre un avantage car elle permet de retourner l’affichage d’un terminal dans un fichier. Ce qui permet de voir ce qui se passe lors de l’exécution du script et de garder une trace de l’ensemble des actions. D’un côté cela reste plus lourd dans la syntaxe que le traditionnel 2>&1 qui ne gère que le stdout et stderr. Probablement qu’aujourd’hui je ferai différemment.

3 – Fonction : Dump Create

Nous rentrons dans le vif du sujet. Je réalise le dump de la base en deux temps.

• Export du dump .sql
• Compression du dump .sql en .gzip

Toujours en prenant en compte l’argument passé lors de l’appel du script pour positionner le dump dans le bon répertoire. Dans le cas contraire, le dump sera écrit à la racine du répertoire contenant les dumps.

Dans cette fonction, les commandes les plus intéressantes sont bien entendu les commandes mysqldump et gzip.

Pourquoi faire en deux temps alors qu’il est tout à fait possible de réaliser ces deux actions en une seule commande ?

Excellente question pour laquelle je ne me souviens plus pourquoi j’ai fait ça. Peut-être pour le plaisir de chercher midi à quatorze heures que sait où mon côté néophyte ?

Nous précisons l’utilisateur qui va réaliser le dump de la BDD (attention au permission sur la base) ainsi que son mot de passe -u $_dbUser et -p$_dbPassword. L’option –master-data permet de se positionner si une réplication SQL est se place sur la dernière position. L’option –quick est utile dans le cas de BDDs importante. Cela va permettre de récupérer les lignes d’une table, ligne par ligne, plutôt que de récupérer l’intégralité de toutes les lignes et de les garder en mémoire avant de l’écrire. L’option –single-transaction qui est à mon sens l’option la plus importante de notre ligne de commande puisque cette option permet de réaliser le dump de notre base de données à chaud sans verrouiller les tables ni bloquer l’application. Pour faire plus simple, cela permet de garantir la consistance des données de notre DUMP. L’option –verbose est quant à elle compréhensible. Nous indiquons la BDD dont nous souhaitons réaliser le dump $_dbName, redirigeons l’ensemble des flux dans le répertoire adéquate puis l’ensemble des flux dans notre fichier de log.

La compression est plus simple puisque nous appelons la commande gzip en indiquant que nous voulons de la verbe et que nous allons forcer la création de l’archive. Comme pour la commande précédente, nous redirigerons l’ensemble des flux dans notre fichier de log.

Et donc si nous souhaitons faire cette opération en une fois ?

Il suffirait de faire un pipe des deux commandes.

$ sudo /usr/bin/mysqldump -u $_dbUser -p$_dbPassword --master-data --quick --single-transaction --verbose $_dbName > $argDump/`date +"%Y-%m-%d"`-$_dbName.sql 2>>$_pathLogRepository/$_pathLogFile | /bin/gzip -f -v $_pathBDDRepository/`date +"%Y-%m-%d"`-$_dbName.sql 2>>$_pathLogRepository/$_pathLogFile

Je ne l’ai toutefois pas testé. Donc à vérifier, mais il n’y devrait pas avoir de raison que ça ne fonctionne pas.

Il y a toutefois une variation entre le commande présente dans le wiki de COMBODO et ma commande. Je ne précise pas les arguments –opt, –default-character-set=utf8, –-add-drop-database. Pourquoi cette prise de liberté soudaine ?

L’option –opt est activé par défaut et si nous ne référons au manuel mysqldump, cette commande est un raccourcie de plusieurs autres commandes. Dans notre cas et si l’installation de MySQL/MariaDB a été effectué comme dans un précédent article , la question ne se pose pas. A l’inverse, nous ne spécifions pas l’encodage des caractères –-default-character-set. Cela pourrait nous porter préjudice. Néanmoins et par défaut si ce dernier n’est pas spécifier, mysqldump utilisera le type utf8mb4. On ne va pas se mentir, je ne suis pas super à l’aise sur le sujet. Si ce n’est que l’utf8mb4 est plus récent que le format utf8 et prend en charge les emojis etc. Par expérience, tous les dumps que j’ai dû réimporter jusqu’à présent ont été réalisé sans spécifier le type d’encodage utf8. Je n’ai pas constaté d’erreurs ou de dysfonctionnements. Moralité, je vais me mettre au diapason. (D’un côté faut être un peu c*n pour dire j’ai RTFM mais j’ai pas appliqué les recommandations de l’éditeur…).

4 – Fonction : CleanUp Repository

Je vois déjà certains SysAdmins ou Dev se dire « Nan le gazié il est pas sérieux avec son _nbRetention, il a pas osé faire une fonction de rotation de ces fichiers .sql/.gzip ?! » Et bien désolé de vous décevoir, la réponse est bien un énorme OUI, j’ai osé.

Pourquoi ? Simplement pour me demander comment ferai je si je devais me passer de logrotate. Et le cas échéant, j’ai appris quelques choses d’autres et j’ai donc un as dans ma manche si je dois faire une rotation de fichier un jour sans logrotate.

(Comme déjà dit plusieurs fois, il est important de savoir se perdre de temps en temps.)

La commande find permet de lister l’ensemble des éléments sur un critère. Dans notre usage, nous souhaitons lister tous les éléments (fichiers réguliers) d’un des répertoires contenant nos Dumps -type f dont la dernière modification est inférieurs au nombre de point de rétention -mtime +$argNbRetention. (Notons que cela s’exprime en jour donc 5 x 24heures). Les fichiers ne répondant pas au critère sont supprimés -delete.

Je passe mon tour sur les trois dernières fonctions qui sont ennuyeuse au possible et qui pour moi n’apportent aucun intérêt dans le projet. Puisque cela concerne l’envoi d’un mail de notification de succès ou d’échec de l’archivage ou de la réalisation du dump.

Qui dit notification mail, dit serveur de messagerie (Apps – MUTT).

Nous contrôlons les droits sur le fichier afin de s’assurer que ce dernier est bien en 700 pour root:root.

$ sudo ls -ahl /script/SS_015-LINUX_MYSQL_DUMP-BDD

Dans le cas contraire, il sera nécessaire de réaliser les opérations adéquates.

Configuration du cron

Perso, je souhaite avoir un delta de 6 heures maximum en cas de panne et donc (attention largage de gros mots dans deux secondes) dans RTO⁹ de 1 heure ! Généralement, les entreprises travaillant de 8h00 à 18h00 du Lundi au Vendredi, nous allons automatiser nos dumps à 12h30 et à 18h30 sur les mêmes jours. Libre à chacun de faire comme il le souhaite. (Attention toutefois si vous avez des jobs de sauvegardes en parallèle des dumps car les SEs n’aiment pas ça, ni le matériel d’ailleurs les I/O¹⁰ un univers passionnant).

# vim /etc/crontab

Ainsi, chaque Lundi au Vendredi à 12h30 en tant que root, le script stocké sous /script/SS_015-LINUX_MYSQL_DUMP-BDD/SS_015_E_LINUX_MYSQL_DUMP-BDD.sh avec l’argument MidDay viendra générer un dump de la base de données compressée sous l’emplacement de stockage par défaut /midday/. Il sera de même à 18h30 mais avec l’argument MidNight, sous l’emplacement /midgnight/.

Configuration des logs

Si vous avez déjà déployé l’un de mes outils, vous devez déjà avoir la configuration de rotation des logs pour le contenu du répertoire /var/log/ERWAN.

Dans le cas contraire, éditez un fichier de rotation.

$ sudo vim /etc/logrotate.d/rone_scripts

/var/log/ERWAN/SS_015-LINUX_MYSQL_DUMP-BDD.log {
        daily
        rotate 7
        copytruncate
        missingok
        notifempty
}

Configuration de la BDD

Euh… Je veux bien que tu parles de backup, de dump, de SQL toussa toussa. Mais qu’est ce que vient faire la configuration de la BDD dans cet article ?

Je répondrai à cette question par une question me chuchote mon avocat.

On lance le dump avec quel compte, le root ?

Effectivement, vu sous cette angle c’est moche. Qui peut le plus peut le moins. Mais le risque est de ne pas exposer d’avantage notre système et de maitriser autant que faire se peu les utilisateurs et les privilèges qui leurs sont associés.

Alors nous allons créer un compte dédié pour la sauvegarde de nos bases MariaDB/MySQL. (D’ailleurs saviez vous que le Dauphin de MySQL est une dédicace à la fille ainée de son fondateur et qu’à la suite de son rachat par SUN puis ORACLE, il dédiera l’Otarie à sa fille cadette ? Non ? Et bien voilà, nous mourrons moins c*n ce soir).

# mysql -u root -p

[(none)]> CREATE USER `svc.backup`@'localhost' IDENTIFIED BY '5uZ9Bc5KLkIJ0io0Z_Px9';

[(none)]> GRANT LOCK TABLES, SELECT, PROCESS, SHOW VIEW, TRIGGER ON *.* TO 'svc.backup'@'localhost';

[(none)]> FLUSH PRIVILEGES;

Dans les grandes lignes, nous créons notre utilisateur SQL (on pense à changer éventuellement le nom du user et le mot de passe), rien de bien compliqué. Ce qui nous intéresse en revanche se sont les permissions que nous attribuons à notre utilisateur :

• LOCK TABLES : Parce que nous utilisons l’argument single-transaction pour la consistance de la BDD
• SELECT : Pour dump les tables
• PROCESS : Dans le cas où nous viendrions à utiliser l’argument no-tablespaces. Dans notre cas pratique, inutile mais peut-être pas pour d’autres BDDs.
• TRIGGER : Pour dumps les tables TRIGGER de notre BDDs. Comme pour l’option ci-dessous, ça serait dommage de ne sauvegarder qu’un bout de notre BDD. Ca serait comme faire une soirée raclette mais en ne touchant pas au plateau de charcuterie. Aucun intérêt de faire une soirée raclette/dump.
• SHOW VIEW : Pour sauvegarder la table des VIEWS. Dans notre cas, nous les supprimerons si nous devons réaliser un dump de la BDD iTop. Toutefois, nous voulons un backup complet en cas d’avarie.

Allez, fermons notre connexion SQL et passons à l’étape suivante. La princesse Peach nous attend, à moins que ce ne soit Peggy du Muppet Show. Je les confonds toutes les deux.

Configuration du script

Il sera nécessaire avant la configuration du script de dédié un disque pour nos dumps (comme indiqué plus haut). L’une des grandes questions étant oui mais comment définir l’espace de stockage afin de ne pas faire de surallocation de ressources ?

Il est toujours difficile d’apporter une réponse empirique à cette question. J’ai pour habitude de partir sur la formule suivante :

DiskSize (Go) = (BDDSize (Go) * AVG Compression Rate * NBRetentionPoints) * 30 %

Par exemple, si nous partons des données suivantes pour un total de deux jobs automatisés par jour sur 5 jours avec un taux de compressions de 46% et que notre BDD fait 2 Go :

DiskSize (Go) = (2 Go * 0,46 * (2*5)) * 1,3

DiskSize (Go) = 11,96 Go

Il nous faudrait donc un disque dédié de 12 Go. Nous avons prévu une marge de 30% d’espace de stockage afin de ne pas avoir d’alerte relative à notre supervision et saturer notre espace disque. Nous n’avons ainsi pas la nécessité d’étendre tous les deux jours ou quatre matins notre partition.

Attention à l’évolution de notre base de données dans le temps. Si cette dernière « gonfle » rapidement, il sera nécessaire d’engager les actions adéquates.

Optionnellement, si vous réalisez une sauvegarde de votre machine (ce qui est vivement recommandé) par une solution tierce (VEEAM, HYCU etc) vous aurez votre nombre de point de rétention de sauvegarde en dump plus votre notre de point de rétention max définit dans notre script. Cela nous fait une bonne assurance.

Pour la suite, je considère donc que nous avons monté un disque de 12 Go sous /mnt/backup/.

Les droits sur le répertoire /mnt/backup doivent être 700 pour l’utilisateur root:root. N’oublions pas qu’en dehors de la sauvegarde, nous avons un autre backup de notre BDD. Il est donc logique de ne faire confiance à personne d’autre que root.

Editons notre script et modifions les variables suivantes.

$ sudo vim /script/SS_015-LINUX_MYSQL_DUMP-BDD/SS_015_E_LINUX_MYSQL_DUMP-BDD.sh

• _mailTo : préciser l’adresse qui va recevoir les rapports de dump deux fois par jour.
• _pathBDDRepository : préciser le répertoire racine créé précédemment qui va contenir nos sauvegardes /mnt/backup.
• _nbRetention : Le nombre de point que vous avez définit dans notre formule. Vous pouvez l’augmenter ce dernier ou le diminuer à votre guise. Tant que l’espace de stockage arrive à suivre, pas de problème.
• _dbName : Le nom de la database dont nous voulons réaliser le dump.
• _dbUser : Le compte SQL dédié uniquement à la réalisation des dumps.
• _dbPassword : Le mot de passe du compte SQL ci-haut.

Et le reste, pas touche, sauvegarder les modifications.

Bon, plus qu’à tester.

Test, Let’s the Rock of Begins

Afin de vérifier que tout va bien nous allons exécuter un dump manuellement et simuler l’automatisation d’un dump.

# /script/SS_015-LINUX_MYSQL_DUMP-BDD/SS_015_E_LINUX_MYSQL_DUMP-BDD.sh

#/script/SS_015-LINUX_MYSQL_DUMP-BDD/SS_015_E_LINUX_MYSQL_DUMP-BDD.sh MidNight

Normalement si nous avons bien fait les choses, nous devrions avoir dans notre console le retour suivant :

Si nous laissons tourner notre script 24 heures, nous devrions avoir la structure suivante dans notre répertoire /mnt/backup

Nous pourrions supprimer un sous répertoire, ce dernier sera recréé lors de la prochaine exécution du script dans le contrôle des prérequis. 🙂

Au début, je voulais joindre en pj le fichier de log. Mais tant que nous n’avons pas une grosse BDDs ça passe, après c’est plus délicat. Je dois faire des efforts dans ce sens pour mieux gérer la verbosité de mes journaux je crois.

Néanmoins, nous pouvons faire une tour dans le répertoire de log et consulter l’ENSEMBLE de toutes les actions réalisées par le script.

Soit en petit échantillon.

Et pour terminer, le plus important car nous ne sommes pas en permanence sur notre terminal putty, le petit mail nous informant du bon succès des opérations.

GitHub

Le code source ? C’est par là => LIEN (Licence GNU).

Conclusion

Il n’y a rien de pire que l’excès de confiance dans la profession d’AdminSys. A la différence des chirurgiens et autres médecins qui sont en dessus des divinités, l’AdminSys se voit vite revenir à la réalité. Je pense et s’est ce que mes mentors m’ont inculqués, peu importe la tâche nous devons être en permanence vigilant.

C’est avec ce genre de situation que nous prenons pleinement conscience des manquements sur nos systèmes d’informations et qu’il est nécessaire de trouver des solutions palliatives, payantes ou homemade (bancales la plus part du temps mais qui font ce que nous attendons).

Dans mon cas et pour revenir à la situation initiale, je pense avoir répondu à ma problématique d’indisponibilité des données entre deux points de sauvegarde (24h). Mais c’est encore loin d’être parfait. La solution est générique certes, mais elle pourrait tellement être optimisée, factorisée et simplifiée.

Pourtant nous ne sommes pas allés au bout de ce projet. Et j’avoue que j’étais partagé pour aborder ce point. Je traiterai ce dernier dans un autre billet. Mais ce que nous devons garder à l’esprit c’est que nous avons un dump de notre base de données SQL (que ce soit, ITOP, ZABBIX ou autres applications), qu’est ce qui nous dit que le contenu de notre dump est intègre et fiable ? Il faudrait réimporter ce dernier dans un environnement de test et recetter le dump. Ainsi la boucle serait bouclée et nous validerions notre processus de reprise de données à partir d’un dump de bout en bout. Cela viendra s’inscrire dans le PAS¹¹ de notre application, organisation.

Le mot de la fin :

Il était une petite requête, pirouette cacahouète. Il était une petite requête qui a fait une grosse boulette.

Pirouette, pas de caouhète. Vous passez en week end studieux sans apéro…

Erwan GUILLEMARD

Source

• FIND
• GZIP
• ITOP – DataBackup (v3.X)
• ITOP – DataBackup (v2.7.X)
• MYSQLDUMP – master-data
• MYSQLDUMP – quick
• MYSQLDUMP – single-transaction
• MYSQLDUMP – minimum privileges
• TEE

1. ITSM : Information Technology Service Management ↩︎
2. SQL : Structured Query Language ↩︎
3. OQL : Object Query Language ↩︎
4. WEBUI : WEB User Interface ↩︎
5. SLA : Service Level Agreement ↩︎
6. OLA : Operational Level Agreement ↩︎
7. SLR : Service Level Requirement ↩︎
8. REX : Retour d’EXpérience ↩︎
9. RTO : Recovery Time Objective (différent du RPO Recovey Point Objective) ↩︎
10. I/O : Input / Output ↩︎
11. PAS : Plan d’Assurance Sécurité ↩︎

Cependant, j’ai insisté sur la différence entre le protocole FTP¹/FTPS² et SFTP³. Alors pourquoi faire tronc commun et parler de ramification ? Le seul point commun qu’il peut avoir dans un premier temps et le SE puisque c’est UNIX et dans un second temps la présence de FTP dans le nom. Puis je dirai que c’est tout…Ha si, tertio ils sont tous deux utilisés pour l’échange de fichiers.

Le protocole SFTP se base pour échanger des données sur la création d’un tunnel SSH entre le client et le serveur via le protocole SSH. Nulle autre dépendance n’est nécessaire contrairement à FTP/FTPS qui nécessite un daemon à installer.

Et SSHD c’est du nougat ? Non, bien entendu, c’est un daemon aussi. Ce que je veux dire par là, c’est que dans 99% des cas SSHD est présent dans le déploiement de base des SEs LINUX.

Nous allons utiliser le daemon openssh ( ou SSHD) pour notre serveur SFTP. Ce dernier est dans la grande majorité des cas présent sur le système d’exploitation lors du déploiement. La configuration du service aura été préalablement modifiée dans le cadre du durcissement de notre SE. Nous ne réaliserons que la configuration nécessaire au fonctionnement du service SFTP.

La finalité de ce billet sera comme pour l’article mentionné ci-haut de comprendre le déploiement et l’implémentation d’un service SFTP encore et toujours sur un environnement durci GNU.

Théorie – SFTP

Contrairement aux protocoles FTP et FTPS, SFTP est un protocole dédié, basé sur le protocole SSH.

SFTP est un protocole récent puisqu’il a été créé en 2001 par l’organisme IETF⁴. Il s’inscrit dans un sens comme le successeur du protocole SCP⁵. Le protocole SFTP se rapproche plus du système de fichiers que SCP et donc supporte une plus grande flexibilité.

Si nous venons à comparer les protocoles FTPx et SFTP sur le plan réseau, SFTP se veut plus simple car la notion de mode Actif, Passif, Explicite, Implicite n’existe pas. Là où il est nécessaire d’avoir les ports 21,20, 990, 989 avec SFTP seul le port 22 est nécessaire.

J’apporte toutefois une nuance dans le protocole SFTP vis à vis des protocoles FTPx. A ce jour le protocole SFTP ne possède pas de RFC⁶ à proprement parlé. Un projet à toutefois été initié mais celui ci est resté à l’état de brouillon et n’a plus à ce jour avancé (le RFC draft doit dater de 2006). Il est légitime de se demander si l’avenir et la stabilité du protocole sont viables dans le temps. Bien que le risque soit minime, il subsiste quant même.

Pratique – SFTP

Installation

Je dirais que cette sous-partie n’a pas lieu d’être puisque openssh a été déployé lors de la configuration de notre appliance.

La configuration de base a été supprimée et remplacée par une configuration customisée pour répondre aux recommandations de l’ANSSI concernant les systèmes UNIX.

Eventuellement nous pourrions nous inquiéter de la publication du port 22 sur notre daemon firewalld. Mais contrairement au service FTP, il ne sera pas utile d’ouvrir de port car celui ci est déjà présent dans le daemon firewalld.

Configuration SFTP

A la différence des services FTPx, nous n’allons plus/pas modifier la configuration du fichier vsftpd.conf (puisque nous ne l’avons pas installé, et qu’il n’est pas utile pour le fonctionnement de notre service SFTP ! 🙂 ). Comme présenté en amont, le SFTP se base sur l’établissement d’un tunnel SSH. Donc nous allons devoir ajuster la configuration de notre fichier sshd_config.

$ sudo vim /etc/sshd/sshd_config

# override default of no subsystems
Subsystem      sftp    /usr/libexec/openssh/sftp-server -l VERBOSE

Match Group sftp-user
        X11forwarding no
        AllowTcpForwarding no
        ChrootDirectory %h
        ForceCommand internal-sftp -u 0007

#Allow Users And Groups to uses SSHD
AllowGroups ssh-user sftp-user

$ sudo systemctl reload sshd

Et si nous disséquions ce brin de conf ?

• Match Group sftp-user : Nous indiquons ici que l’ensemble des commandes ci-dessous vont s’appliquer aux utilisateurs membre du groupe sftp-user. Dans notre cas, le groupe n’existe pas encore et il sera nécessaire de créer ce dernier. Il est bien évidemment possible de définir plusieurs politiques sur plusieurs groupes.
• X11forwarding no : Désactive la fonctionnalité X11 forwarding pour le groupe sftp-user et limite les utilisateurs membre de ce groupe à l’utilisation d’application GUI via SSH.
• AllowTcpForwarding no : N’autorise pas le transfert TCP et limite les applications internes qui pourraient être accessible des membres du groupes sftp-user.
• ChrootDirectory %h : Indique que les répertoires sont chrootés (restreints) au home des utilisateurs.
• ForceCommand internal-sftp -u 0007 : Lors de la connexion, le système va exécuter le processus internal-sftp en appliquant le masque 0007 sur tous les éléments qui font être up/down par l’utilisateur.
• AllowGroups ssh-user sftp-user : Les groupes ssh-user et sftp-user sont autorisés à utiliser le daemon SSHD.

Bon nous y voyons un peu plus clair. Mais vient alors une question sécurité. Comment nous assurons nous que les utilisateurs membres du groupes ssh-user n’ont pas accès aux SFTP et que les membres du groupes sftp-user ne puissent pas ouvrir de connexion en SSH ?

# override default of no subsystems
Subsystem      sftp    /usr/libexec/openssh/sftp-server -l VERBOSE

Match Group sftp-customer1
        X11forwarding no
        AllowTcpForwarding no
        ChrootDirectory %h
        ForceCommand internal-sftp -u 0007

Match Group sftp-customer2
        X11forwarding no
        AllowTcpForwarding no
        ChrootDirectory %h
        ForceCommand internal-sftp -u 0007

Match Group sftp-customer2_providers
        X11forwarding no
        AllowTcpForwarding no
        ChrootDirectory %h
        ForceCommand internal-sftp -u 0077
...
...
...
Match Group sftp-customerN
        X11forwarding no
        AllowTcpForwarding no
        ChrootDirectory %h
        ForceCommand internal-sftp -u 0007

#Allow Users And Groups to uses SSHD
AllowGroups ssh-user sftp-customer1 sftp-customer2 sftp-customer2_providers sftp-customerN

Dans le cas des utilisateurs qui sont exclusivement destinés à la consommation de notre service SFTP, nous devons nous assurer :

• Pas de connexion en SSH à la console : Lors de la création des comptes utilisateurs, bien préciser en valeur de l’argument –shell le /sbin/nologin ou /bin/false
• De chrooter le home des utilisateurs. Mais en leurs créant un sous-répertoire où ils pourront tout de même réaliser des actions de création, modification, suppression

Dans le cas des utilisateurs système (root) ou administrateur (membre de wheel ou sudo), l’approche est différente. Il n’est pas possible de limiter un utilisateur système à ne pas utiliser le protocole SFTP. Et dans un sens c’est logique. Néanmoins, il est possible de reprendre le principe suivant de moindre privilège et de silotage des comptes.

Ainsi nous devons nous assurer que le compte utilisateur r.one : 1 – Ne soit pas administrateur, mais bien utilisateur 2 – De chrooter son home à l’identique des utilisateurs du groupe SFTP 3 – Que le compte puisse être verrouiller en cas d’êchec d’authentification 4 – De demander une authentification supplémentaire (MFA)

Mais bon, en règle générale rien ne justifie l’usage d’un compte utilisateur à usage d’exploitation d’avoir un accès SFTP. Néanmoins, et par sécurité les comptes utilisateurs doivent ou devraient être restreints (chrootés). Nous ne sommes jamais assez prudent.

Autres points, QUID des logs de notre serveur SFTP ? Ces derniers sont consignés sous /var/log/secure pour la partie authentification et sous /var/log/messages pour la partie commande SFTP (à condition de préciser -l VERBOSE ou INFO à la fin de l’instruction de commande Subsystem. Tout dépendra du niveau d’information que vous souhaitez faire remonter).

Groups, Users and CHROOT

Je vais pour le coup « recycler » mon utilisateur Customer1 ainsi que son home créé dans l’article traitant du FTPx.

$ sudo adduser Customer1 --home-dir /mnt/customer1 --shell /sbin/nologin --badname

Créons le groupe sftp-user et ajoutons l’utilisateur Customer1 comme membre de ce dernier.

$ sudo groupadd sftp-user
$ sudo usermod -aG sftp-user Customer1

Maintenant, un partie plus délicate qui nécessite un peu de gymnastique mentale ou tout aussi bien un papier, crayon. Les droits et le chroot d’un répertoire peut vite devenir un calvaire. Nous allons donc bien définir notre contexte.

Nous souhaitons que le répertoire home de l’utilisateur soit restreint pour l’empêcher de s’échapper de son home ainsi que de lui interdire de créer, modifier et supprimer l’arborescence en place au niveau de son home mais de lui permettre dans un répertoire « home » de pouvoir faire ce qu’il souhaite.

Commençons par chroot le home

$ sudo chmod 2750 -R /mnt/customer1

Créons et appliquons les droits sur le répertoire « home »

$ sudo mkdir /mnt/customer1/home
$ sudo chmod 700 -R /mnt/customer1/home
$ sudo chown Customer1:Customer1 -R /mnt/customer1/home/

Maintenant reste plus qu’à tester le bon fonctionnement. Y à plus qu’à, faut qu’on comme dirait l’autre.

Connexion

Je reprends mon client FTPx/SFTP de prédilection sur Windows (WinSCP me susurre-t-on à l’oreille) et indique le couple login, mot de passe de l’utilisateur Customer1. Diantre que c’est agréable de constater que cela fonctionne 🙂

Nous constatons que les droits du répertoire « Home » (le /mnt/customer1 et non le répertoire /home affiché. Oui j’aurais du choisir un nom moins ambigüe. Toutefois, notons que cela nous force à faire travailler notre cafetière qui nous sert de cerveau) de l’utilisateur est bien restreint (chroot).

Nous constatons également que le fichier test.html a des droits qui sont différent et ne semble pas hérité du répertoire /mnt/customer1. C’est normal puisque j’ai fait des tests auparavant et se fichier va nécessiter l’intervention d’un administrateur du serveur.

Pourquoi ? Comme indiqué plus haut, nous n’avons pas souhaité laisser la possibilité à l’utilisateur de créer, modifier ou supprimer des ressources à la racine de son home.

Si nous rentrons dans le répertoire ./home, les permissions sont différentes et offrent ainsi la possibilité à l’utilisateur Customer1 de créer, modifier, supprimer le contenu de ce répertoire.

Ok nous sommes donc d’accord sur la partie restriction et droits sur la partie SFTP mais sommes nous certains que l’utilisateur ne peut pas se connecter via un terminal SSH ? Pour le coup, il suffit de faire un test de connexion via un terminal et de consulter les journaux relatifs aux événements d’authentification.

Le message est clair, l’utilisateur n’est pas autorisé à ouvrir de session depuis un terminal. Donc tout va bien puisque tout est conforme à nos attentes.

Si nous voulions aller plus loin et s’est ce que nous allons faire (libre à vous de passer votre route), penchons nous sur la différence entre FTPS et SFTP sur le plan réseau nous aurions les trames suivantes :

SFTP	FTPS

Rien de magique en sommes si ce n’est la mise en évidence de l’établissement des transactions via le protocole SSH2 pour le SFTP et l’utilisation du protocole SSL/TLS dans sa version 1.3.

La grosse différence se trouve sur le mécanisme de chiffrement. L’un use d’un certificat le second d’un jeu de clé. Il sera plus facile de maintenir un jeu de clé qu’un certificat. Toutefois, il faut se noter par sécurité de changer de clé au bout d’une durée définit comme nous pourrions le faire avec un certificat qui arrive à expiration.

Conclusion

Nous sommes arrivés au bout des objectifs que nous nous étions fixés au début de ce billet.

Le SFTP a pour moi toute ça place dans un service à la demande (SaaS) comme le serait FTPS. Toutefois bien qu’il offre certains avantages il a (pour moi) le lourd inconvénient de ne pas être reconnu officiellement (quel inconvénient sans être boudé pour autant).

Si la mise en place du service relève de la simplicité, il est nécessaire d’être rigoureux et méthodique quand à la création des utilisateurs, la restriction des répertoires « home ». Se basant directement sur le daemon sshd (openssh) la moindre erreur pourrait rendre le système vulnérable par l’escalade de privilège ou évasion de l’espace restreint. Je recommande fortement la mise en place d’une matrice ainsi qu’une revue périodique des droits d’accès. Egalement, lorsqu’un client ou utilisateur n’utilise plus le service, il est nécessaire de nettoyer le système dans les règles de l’art.

Il n’est toutefois pas exclu comme pour FTPx de renforcer la sécurité quant à l’accès du service si ce dernier est publié vers l’extérieur.

Au minimum et si possible sur le firewall :

• Activation de l’IPS
• Activation de l’Application Control (fonctionnalité WatchGuard) sur une politique définit
• Activation de la Géolocalisation sur la liste des pays autorisées à se connecter au service publié
• Utilisation d’un proxy FTP

Au maximum et si possible sur le firewall :

• Filtrer les adresses IP entrantes aux seules IP habilitées. (Généralement les IPs clientes).

Aujourd’hui, il convient à chacun de dire que SFTP > FTPS ou FTPS > SFTP. Pour ma part je prendrai le partie suivant SFTP est équivalent à FTPS, j’ai toutefois une préférence SFTP. Néanmoins, basé sur deux technologies différentes, tout dépendra du contexte ainsi que des moyens mis à disposition pour choisir l’une ou l’autre des protocoles.

A d’autres égards, il est souvent si ce n’est systématiquement privilégié par les éditeurs vis à vis du protocole FTPS.

Le mot de la fin :

« Donne moi ta Key baby, ton port baby hey ! Discute avec moi baby, je veux un serveur SFTP like you ! » Très joli interprétation, vous sortez de votre chroot et zoukez avec Patrick BALKANY en sortie de détention.

Erwan GUILLEMARD

Sources

• SFTP
• SSHD_CONFIG
• WINSCP
• WIRESHARK

1. FTP : File Transfert Protocol ↩︎
2. FTPS : File Transfert Protocol over SSL ↩︎
3. SFTP : Secure File Transfert Protocol ↩︎
4. IETF : Internet Engineering Task Force ↩︎
5. SCP : Secure Copy Protocol ↩︎
6. RFC : Request For Comments ↩︎