Sécurisé l’accès à Pfsense

Installation Pfsense sur VMWare Workstation

La gestion des identités et des autorisations constitue un pilier essentiel de la sécurité informatique, une importance qui prend tout son sens lors du renforcement des mesures de sécurité. En effet, l’un des principes fondamentaux de la sécurité informatique est la Triade CIA (Confidentialité, Intégrité, Disponibilité) :

• Confidentialité : Garantir que les informations soient accessibles uniquement aux personnes autorisées.
• Intégrité : Assurer l’exactitude et l’intégrité des informations, empêchant toute modification non autorisée.
• Disponibilité : Garantir que les informations soient disponibles et accessibles en fonction des besoins.

Les UTM n’échappent pas à ses règles, bien au contraire.

Gestion des comptes utilisateurs

L’identifiant de connexion, s’il est partagé, peut être considéré comme générique, sauf dans le cas où un seul administrateur a accès à pfSense. Pour assurer la confidentialité, il est impératif d’avoir un compte distinct pour chaque utilisateur, configuré avec les droits appropriés. La gestion de la confidentialité intègre 3 principes :

• Identification : ‘utilisateur fournit des informations d’identification telles qu’un nom d’utilisateur.
• Authentification : Le système vérifie ces informations d’identification en les comparant à une base de données d’utilisateurs autorisés.
• Accès : Si l’authentification réussit, l’utilisateur est autorisé à accéder aux ressources ou aux données spécifiques pour lesquelles il est autorisé.

Ajouter une source d’authentification

La gestion des utilisateurs peut se faire en utilisant les comptes internes ou alors en nous appuyant sur l’Active Directory, cela permet d’avoir une source unique d’authentification ce qui nous simplifiera la gestion et qui nous permet de conserver une cohérence dans la politique de sécurité des mots de passe (mot de passe complexe, changement régulier, etc…).

Pour l’organisation de notre Active Directory, sur le contrôleur de domaine, à l’aide de la console « Utilisateurs et ordinateurs Active Directory », nous allons créer une unité d’organisation que nous nommerons pfSense.

Dans l’unité d’organisation que nous venons de créer, nous allons créer deux groupes de sécurité global, « pf_administrateur » et « pf_technicien ».

Les membres du groupe « pf_administrateur » auront un accès total alors que les membres du groupe « pf_technicien » auront un accès limité.

Nous créerons également 2 comptes utilisateur, le premier, « pf_admin », sera membre du groupe de sécurité « pf_administrateur » et le second « pf_tech » sera membre du groupe de sécurité « pf_technicien ».

Nous créerons un compte pfSense qui sera un compte de service, nous y reviendrons un peu plus tard dans cette documentation.

A l’étape suivante, nous allons ajouterons à pfSense notre Active Directory, comme source d’authentification.

Une fois que les utilisateurs ont été créés, nous accéderons à l’interface d’administration de pfSense. Nous naviguerons vers le menu « System » et cliquerons sur « User Manager ».

Nous allons ensuite, nous rendre dans l’onglet, « Authentication Servers », puis sur le bouton « Add » pour avoir accès au formulaire web d’ajout d’un serveur d’authentification.

Dans la section « Server Settings », nous indiquerons un nom et nous laisserons le type LDAP proposé par défaut.

Hostname or IP Address : Indiquer l’IP ou le nom de votre contrôleur de domaine. Dans le cas où vous indiqueriez votre FQDN, il faudra être sûr que votre Pfsense est client de votre serveur DNS.

Search scope : Dans la liste déroulante, nous allons étendre la recherche dans toute l’arborescence de l’AD

Base DN : Le « Distinguished Name » de notre AD

Authentication containers : le Distinguished name de l’Unité d’organisation ou conteneur que l’on souhaite lier à l’authentification de pfSense.

• Bind anonymous – Bind credential : En décochant Bind anonymous, nous refusons les requête LDAP anonyme, il nous voudra donc indiquer un identifiant et un mot de passe qui sera autorisé à se connecter. Un peu plus tôt dans cette documentation, nous avions créé un compte « pfsense », sans l’associer à un groupe, c’est ici qu’il va avoir son utilité. Il sera dédié à pfSense.
• Initial Template : Choisissez Microsoft AD

Nous sauvegarderons cette configuration en cliquant sur le bouton « Save ».

Notre Active Directory est maintenant présent dans la liste des serveurs d’authentification de pfSense.

Pour tester notre nouvelle source d’authentification, nous déroulerons le menu « Diagnostics », puis nous sélectionnerons « Authentication ».

Nous accédons à un formulaire pour tester les authentifications. Dans la liste déroulante « Authentication Server », nous sélectionnerons le nom que nous avons donnée à notre nouvelle source d’authentification, dans cette documentation, le nom est « Active Directory ».

Nous testerons avec l’utilisateur « pf_tech », nous renseignerons son nom d’utilisateur et son mot de passe.

Après avoir renseigner tous les champs, nous cliquerons sur le bouton « Test »..

Dans la capture ci-dessus, nous pouvons lire dans le bandeau vert que l’ajout de de serveur d’authentification est fonctionnelle.

Gestion des accès

Nos utilisateurs que nous avons créés doivent être exclusive à pfSense si nous souhaiter garder l’approche du minimum de privilèges et par extension à l’approche plus générale qu’est le « Zero Trust ». Il nous faut bloquer l’ouverture des sessions sur des postes ou des serveurs de notre infrastructure en utilisant les comptes dédiés à pfSense. Dans le gestionnaire de stratégie de groupe de notre contrôle de domaine, nous avons un objet de stratégie de groupe à créer et à lier à notre unité d’organisation pfSense.

Dans le menu « Outils » du Gestionnaire de serveur de notre contrôleur de domaine, nous sélectionnerons « Gestion des stratégies de groupe ».

Dans le menu latéral, nous nous rendrons dans le nœud de notre domaine :  Forêt : « votre_nom_de_forêt » > domaine > « votre_nom_de_forêt » .Dans le menu contextuel de l’unité d’organisation, nous sélectionnerons « Créer un objet GPO dans ce domaine, et le lier ici … » puis nous donnerons un nom à notre nouvel objet GPO.

L’étape suivant consistera à modifier cette stratégie, dans le menu contextuel de notre nouvel objet GPO, nous sélectionnerons « Modifier ».

Notre stratégie est une configuration d’ordinateur, nous sélectionnerons donc « Stratégies » qui se trouve en dessous de « Configuration ordinateur ».

Nous avons 3 choix possible, Paramètre logiciel, Paramètre Windows et Modèle d’administration. Pour ce qui nous concerne, c’est un paramètre de sécurité Windows, nous déplierons « Paramètre Windows », et nous déplierons « Paramètre de sécurité » pour pouvoir sélectionner « Stratégies locales ».

Nous rentrerons ensuite dans les « Attribution des droits utilisateurs » et nous modifierons les propriétés du paramètre « Interdire l’ouverture d’une session locale » en y effectuant un doucle-clic.

Nous cocherons la case « Définir ces paramètres de stratégie », puis nous cliquerons sur le bouton « Ajouter un utilisateur ou un groupe ». Dans la fenêtre Ajouter un utilisateur ou un groupe, nous cliquerons sur le bouton « Parcourir… » pour sélectionner le groupe pf_administrateur, pf_technicien et notre utilisateur pfsense.

Nous validerons ce choix en cliquant sur OK à chaque fenêtre.

Pour vérifier que notre stratégie est bien fonctionnelle, nous tenterons de nous connecter sur notre poste client avec l’un des comptes pour lequel nous avons interdit l’ouverture de session locale.

Attribution des droits aux utilisateurs pfSense

PfSense offre une fonctionnalité puissante permettant la création de groupes d’utilisateurs, offrant ainsi une gestion fine des privilèges et des accès. Cette approche flexible permet d’attribuer des droits différenciés en fonction du profil de chaque utilisateur. Par exemple, les droits d’accès d’un technicien de proximité ne seront pas les mêmes que ceux d’un administrateur, chaque utilisateur jouant un rôle défini avec un périmètre d’action spécifique au sein du système d’information.

Dans notre laboratoire, nous avons choisi d’utiliser notre contrôleur de domaine comme source d’authentification. Nous continuerons à exploiter cette source pour la création de nos groupes. Une fois ces groupes établis dans notre Active Directory, nous les associerons à des groupes préalablement créés dans PfSense.

Dans notre Active Directory, nous avons créés deux groupes, pf_administrateur et pf_technicien. Dans notre mise en pratique, pf_administrateur aura tous les droits et pf_technicien aura des droits plus restreints.

Avant d’attribuer les droits à nos groupes, nous créerons deux groupes dans notre pfSense et nous lierons ses groupes à nos deux groupes de sécurité présent dans notre Active Directory.

Dans pfSense, nous déroulerons le menu « System » pour nous rendre dans le menu « User Manager ».

Ensuite nous nous rendrons dans l’onglet « Groups » où nous cliquerons sur le bouton « Add ».

Dans le formulaire de création du groupe, nous indiquerons le nom de notre groupe, il doit être strictement identique au nom de notre groupe de sécurité créé dans notre Active Directory, c’est dû au fait qu’il porte le même nom qu’ils sont liés.

Après avoir renseigner le nom, nous préciserons que le groupe est disponible à distance. Dans la liste déroulante « Scope », nous sélectionnerons « Remote ». Nous pouvons éventuellement ajouter une description. Pour valider, nous cliquerons sur le bouton « Save ».

De la même façon, nous ajouterons le deuxième groupe, pf_technicien.

Nos deux groupes ont été ajouté à notre pfSense.

Les groupes étant créé, nous ajusterons leurs droits. La gestion des droits se fait dans les paramètres du groupes concernés, il nous faut donc modifier le groupe. Pour ce faire, nous cliquerons sur le bouton modifier représenté par un crayon dans la colonne action.

Pour le groupe pf_administrateur, nous lui attribuerons tout les droits. Nous cliquerons sur le bouton modifier.

En bas de page, dans la section « Assigned Privileges », nous cliquerons sur « Add » pour afficher les options privilèges que nous pouvons attribuer au groupe pf_administrateur.

Dans la liste de choix, nous avons accès à la liste de tous les privilèges que nous pouvons attribuer à notre groupe. Dans notre cas, nous souhaitons lui donner tout les droits, c’est-à-dire lui donner accès à tout les paramètres de notre pfSense. Nous sélectionnerons donc « WebCfg – All pages ».

Pour valider notre choix, nous cliquerons sur le bouton « Save » présent en bas de page.

Dans les paramètres de notre groupe, nous constaterons que les privilèges ont été ajouter. Nous enregistrerons notre modification en cliquant sur le bouton « Save ».

Pour le groupe pf_technicien, nous lui attribuerons des accès plus restreint c’est-à-dire, le droit de voir les logs du pare-feu, les logs système, le graphique trafic ; il aura également la possibilité de faire des requêtes ICMP. Ses paramètres sont liées au accès aux pages suivant.

• WebCFG – Dashboard
• WebCFG – Diagnostics :Ping
• WebCFG – Diagnostics :Traceroute
• WebCFG – Status : Logs :System
• WebCFG – Status : Logs :Firewall
• WebCFG – Status : Traffic Graph

Pour modifier les droits, nous allons nous modifierons notre groupe, puis nous lui attribuerons les priviléges listé ci-dessus.

Avant de tester que nos modifications sont fonctionnelles, nous modifierons la source d’authentification utiliser par défaut. Dans l’onglet, Setting, nous sélectionnerons « Active Directory » dans la liste déroulante « Authentication Server » puis nous validerons ce choix en cliquant sur le bouton « Save ».

Nous testerons en premier lieu avec l’utilisateur « pf_tech » est membre du groupe pf_technicien qui a des droits restreints. Nous constaterons que nous avons bien un accès restreint au vu du nombre d’élément que compose notre menu.

Pour le compte pf_admin, nous constaterons qu’il aura tous les accès.

Renforcement de la sécurité LDAP

LDAP (Lightweight Directory Access Protocol) est un protocole largement utilisé pour l’authentification et l’accès aux services d’annuaire. Cependant, comme tout protocole, il présente certaines faiblesses en termes de sécurité. Par défaut, LDAP transmet les données en clair, exposant ainsi les informations sensibles, y compris les identifiants, à d’éventuels attaquants qui pourraient intercepter le trafic réseau.

Nous constaterons cette faiblesse à l’aide une mise en pratique utilisant Wireshark. Sur notre machine physique, si ce n’est pas déjà fait, nous installerons WireShark pour sniffer notre réseau. Après avoir installé Wireshark, nous sélectionnerons l’interface réseau « VMware Network Adapter VMNET1 », en double cliquant dessus.

A l’aide d’un filtre d’affichage, nous listerons que les communications LDAP, renseigner ldap dans le champs filtre puis valider à l’aide du bouton [entrée] du clavier.

Depuis notre interface d’administration de pfSense, nous nous identifierons, ce qui générera du trafic LDAP qui seront visibles dans Wireshark

Sur la première ligne du trafic réseau de Wireshark, nous ouvrirons le menu contextuel, nous sélectionnerons « Suivre », puis « TCP stream », cela nous permettra de retracer toutes les communications LDAP liée à cet échange..

Nous constaterons que le mot de passe transite dans le réseau en claire.

Cette faiblesse peut être atténuée en utilisant LDAP avec StartTLS ou en établissant des connexions sécurisées via LDAPS, c’est cette deuxième option que nous allons explorer dans cette documentation.

Pour configurer le LDAPS, il est essentiel de comprendre son fonctionnement. Le LDAPS est un protocole qui vise à sécuriser les communications LDAP en utilisant le protocole TLS (Transport Layer Security), qui est également connu sous le nom de SSL (Secure Sockets Layer). Le protocole LDAP fonctionne à la couche 7 du modèle OSI (couche application), tandis que le TLS opère aux niveaux des couches 6 (présentation) et 4 (transport).

D’un point de vue fonctionnel, dans notre contexte, lorsqu’une requête LDAP est émise par pfSense, elle est chiffrée à l’aide d’une clé publique. Le serveur Active Directory réceptionne la requête, la déchiffre à l’aide de sa clé privée, puis traite la demande de manière sécurisée.

Nous avons donc besoin d’avoir un générateur de clé, ce générateur de clé est une fonctionnalité des autorités de certification. L’autorité de certificat sera en charge de créer les couples de clé, 1 privé qui sera utilisé par notre contrôleur de domaine et une clé publique qui sera distribué aux clients, dans notre cas, à pfSense.

L’autorité de certification aura également la charge de certifié de l’authenticité de la clé publique, ce qui donnera lieu à un certificat numérique, ce certificat sera signé par la clé privée. Lorsque la connexion entre notre pfSense et notre client est établie, c’est-à-dire que les 3 handshake (SYN, SYN-ACK, ACK) du protocole TCP ont été effectué, pfSense va demander le certificat d’authenticité au serveur Active directory. Pfsense soumettra ce certificat à une autorité de certification pour qu’il le valide.

En utilisant LDAPS, nous chiffrons les messages LDAP pour assurer la confidentialité des données transitant entre pfSense et le serveur Active Directory. De plus, en vérifiant le certificat d’authenticité du serveur auprès de l’autorité de certification, nous nous assurons de l’identité légitime du serveur. Ainsi, LDAPS offre à la fois la confidentialité et l’authenticité dans les communications LDAP, renforçant la sécurité de l’ensemble du processus.

Mise en place d’une autorité de certification

Microsoft propose un service de rôle à déployer pour mettre en place une autorité de certification. Sur notre contrôleur de domaine, nous installerons le rôle AD CS, nous en auront besoin pour activer le service de rôle Autorité de certification.

Dans le gestionnaire de serveur, nous cliquerons sur Ajouter des rôles et des fonctionnalités.

Nous allons ensuite passer le message présentant l’assistant d’ajout des rôles et des fonctionnalités. Dans la fenêtre « Sélectionner le type d’installation », nous cliquerons sur le bouton « Suivant ».

Après avoir indiqué sur quel serveur nous souhaitons ajouter le rôle, nous sommes amené à sélectionner le rôle que nous souhaitons installer.

Nous n’ajouterons pas de fonctionnalités, ce qui nous emmène à la fenêtre de présentation du rôle Service de certificats Active Directory.

Par défaut, le service de rôle proposé est « autorité de certification », pour notre lab, nous n’aurons besoin que de ce service de rôle, nous pouvons cliquer sur le bouton suivant et confirmer notre choix en cliquant sur le bouton « Installer » dans la fenêtre qui suit.

Après avoir installé le rôle AD CS et le service de rôle Autorité de Certification, nous devons le configurer. Confirmer les identifiants puis cliquer sur le bouton « Suivant »

Nous activerons l’Autorité de certification en cochant la case « Autorité de Certification ». Nous aurons ensuite le choix entre installer une autorité de certification d’entreprise ou une autorité de certification autonome. Notre choix se portera sur la première option, c’est-à-dire l’installation d’une autorité de certification d’entreprise. De manière générale, lorsque nous voulons déployer une autorité de certification en local sans avoir à mettre en place une infrastructure de clé publique (PKI – Public Key Infrastructure), l’option d’installation d’une autorité de certification d’entreprise sera privilégiée.

Dans Windows Server, il existe deux types d’autorité de certification, l’autorité racine ou l’autorité de certification secondaire, cela permet de répartir la charge et la responsabilité des actions de notre autorité de certification, dans notre cas, nous aurons qu’un seul serveur, par conséquent, nous sélectionnerons Autorité de certification racine, nous créerons ensuite la clé privée qui permettra à l’autorité de certification de signé les certificats.

La configuration de la clé privée passe par le paramétrage de 3 éléments :

• Le chiffrement
• Le nom de l’AC
• Période de validité.

Pour ce qui concerne le chiffrement, nous utiliserons les valeurs qui nous sont proposées par défaut, il en sera de même pour le nom de l’AC. Concernant la durée de validité, nous mettrons une durée volontairement longue, 100 ans Nous laisserons les emplacements par défaut de la base de données de certificats et du journal de la base de données de certificats. En résumé, hormis pour la fenêtre « Période de validité », toutes les autres fenêtres conserverons leurs valeurs par défaut.

Nous arrivons aux étapes finales. Après avoir vérifié les informations que nous avons renseignées, nous pouvons cliquer sur le bouton « Configurer ». Nous terminerons en cliquant sur le bouton « Fermer » à la fin de la configuration.

L’installation du rôle AD CS va entraîner des modifications au niveau du système d’exploitation. Pour que ces changements soient pris en compte, il nous faut redémarrer le serveur. Après les modifications apportées au niveau du système d’exploitation, d’autres changements interviennent, par exemple, les certificats doivent être activés et configurés, ce qui nécessitera également un redémarrage. Entre les deux redémarrages, nous attendrons quelques minutes (environ 5 minutes devraient être suffisantes) pour que les premières modifications aient le temps d’être appliquées et prises en compte.

Au redémarrage du serveur, nous testerons que notre AD CS est bien fonctionnel, Microsoft met à disposition un utilitaire baptisé ldp.exe, accessible dans C:\Windows\System32\.

Nous nous connecterons à notre serveur Active Directory, nous déroulerons le menu Connexion, et nous sélectionnerons « Se connecter… ». L’outils étant exécuté sur notre serveur Active Directory, nous renseignerons « Localhost » dans le champ « Serveur », nous cocherons la case SSL, et nous indiquerons le port par défaut du protocole LDAPS, c’est-à-dire 636. Une fois que toutes ses informations ont été renseigner dans la fenêtre « Se connecter », nous cliquerons sur le bouton « OK ».

Dans la réponse, il ne doit y avoir aucune erreur, et nous devons recevoir la confirmation que la connexion a été établie.

Chiffrement des requêtes LDAP avec LDAPS

Pour chiffrer notre communication, nous aurons besoin de notre clé publique sur pfSense. Il faudra donc l’exporter depuis notre serveur AD CS, puis l’importer dans pfSense.

Sur le Serveur Active Directory où nous avons installé le rôle AD CS, nous allons nous rendre dans le magasin de certificat. Après avoir ouvert la fenêtre « Exécuter » à l’aide de la combinaison de touche [windows] + [R], nous ouvrirons l’outil MMC.

Dans l’outil MMC, nous déroulerons le menu « Fichier », puis nous sélectionnerons « Ajouter/Supprimer un composant enfichable ».

Dans les composants, nous sélectionnerons Certificats, en précisant que cette console gérera un compte ordinateur, cette option sera proposée après avoir cliqué sur le bouton « Ajouter ».

Après avoir cliqué sur suivant dans la fenêtre « Composant logiciel enfichable Certificats », nous préciserons que ce composant gérera l’ordinateur local. Après avoir cliqué sur Terminer, nous cliquerons sur le bouton « OK » pour valider notre choix.

Nous déroulerons ensuite « Certificats ordinateurs », « Autorités de certification racines de confiance », pour nous rendre dans le conteneur Certificats. Nous retrouvons les certificats de notre autorité de certification, nous le sélectionnerons puis nous afficherons le menu contextuel à l’aide du clic-droit de la souris. Dans le menu contextuel, nous sélectionnerons « Exporter » accessible sur la liste « Toutes les tâches ». Cette action aura pour effet d’ouvrir l’assistant d’exportation de certificat.

Après avoir passé le message de bienvenu de l’assistant d’exportation de certificat, nous conserverons la proposition du format faite par défaut, à savoir, l’option « X.509 binaire encodé en base 64 (*.cer).

Nous exporterons ce certificat sur notre bureau, nous devrons également lui donner un nom. La fenêtre suivante, nous amène à la fin de l’assistant Exportation du Certificat, nous cliquerons sur le bouton « Terminer ».

Ce certificat devra être importer dans pfSense, pour des raisons pratiques, nous accéderons à l’interface Web de gestion de notre pfSense depuis le navigateur de notre contrôleur de domaine. Après nous être authentifier, nous déroulerons le menu System et nous sélectionnerons « Certificates ».

Pour importer notre certificat, après avoir vérifié que nous sommes bien dans l’onglet « Authorities », nous cliquerons sur le bouton « Add», ce qui nous permettra d’accès au formulaire d’importation de certificat.

Dans la section « Create / Edit CA », nous attribuerons un nom à notre Autorité de certification, nous déroulerons la liste Method pour sélectionner « Import an existing Certificate ».

Dans la zone de texte « Certificate data », nous ajouterons le contenu du certificat que nous avons exporter. Pour récupérer le contenu, il nous faut l’ouvrir avec le bloc-notes de Windows.

Une fois le contenu du bloc-notes de Windows copier, nous retournerons dans notre formulaire d’importation de certificat et nous collerons le contenu de notre certificat dans le champ « Certificate Data », puis nous sauvegardons cette configuration en cliquant sur le bouton « Save »

Nous validerons cette configuration en cliquant sur le bouton « Save ».

Pour que le certificat puisse être vérifier, il faut que notre pfSense puisse résoudre les noms de notre domaine Active Directory. Nous allons nous en assurer en déroulant le menu « System » de pfSense et nous nous rendrons dans « General Setup ».

Dans la section « DNS Server Settings », nous vérifierons que le Server DNS est bien notre contrôleur de domaine.

Nous allons nous assurer également qu’il utilise le DNS de notre domaine, nous allons donc le forcer à l’utiliser.

Après avoir sauvegarder ses changements, nous allons modifier la configuration de notre server d’authentification. Nous déroulerons le menu « System », puis nous nous rendrons dans l’onglet « Authentification Servers » de « User Manager ». Nous cliquerons sur le bouton modifier pour activer le LDAPS.

Dans la section « LDAP Server Settings », nous remplacerons l’adresse IP par le nom complet de notre contrôleur de domaine. Dans le champ « Port Value », nous indiquerons le port de LDAPS soit 636 et nous modifierons également le champs « Transport » où nous sélectionnerons dans la liste déroulante « SSL/TLS Encrypted ». Nous devons également préciser que le nom de l’autorité de certification qui va gérer les certificats de cette connexion, c’est bien entendu le nom que nous avons indiqué précédemment lorsque nous avons importé le certificat de notre AD CS vers pfSense.  Les autres éléments que nous avions configurés resterons les mêmes. Nous validerons cette configuration en cliquant sur le bouton « Save ».

Nous testerons que notre authentification est toujours fonctionnelle, nous en profiterons également pour vérifier que la connexion est bien chiffrée. Après avoir ouvert Wireshark sur notre machine physique et sélectionné l’interface VMNET1.

Dans pfSense, nous allons dérouler le menu « Diagnostics », puis nous sélectionnerons « Authentication ».

Après avoir renseigner les informations d’identification de l’un de nos utilisateurs, nous cliquerons sur le bouton « Test ».

Dans Wireshark, nous pouvons remarquer que plus aucune requête LDAP passe en claire dans notre réseau.

Pour renforcer la sécurité, nous pourrions exploiter des outils IAM (Identity and Access Management), qui rassemblent divers processus, technologies et politiques. Ces outils visent à gérer et sécuriser l’accès aux ressources en attribuant des droits granulaires aux utilisateurs.

Haute disponibilité