L'Offensive Security est à l'origine de la distribution Kali Linux qu'il n'est plus nécessaire de vous présenter ! La bonne nouvelle, c'est que des cours gratuits vont être diffusés via la plateforme Twitch afin de vous former aux tests d'intrusion (pentests) !

Le contenu diffusé sur Twitch correspondra au contenu de la formation officielle "Penetration Testing with Kali Linux (PWK) (PEN-200)" proposée par l'Offensive Security et qui sert de préparation pour tenter la certification OSCP (Offensive Security Certified Professional). Habituellement, cette formation est assurée en présentielle, enfin ça, c'était avant le début de la pandémie.

À cause de la pandémie, l'Offensive Security s'est adaptée, comme beaucoup d'autres entreprises, ce qui a donné lieu à "OffSec Academy", un cours en ligne de treize semaines destiné à préparer les étudiants à la certification OSCP. Aujourd'hui, l'OffSec a annoncé une évolution de son offre en ligne afin de se tourner vers une plateforme appelée "OffSec Live", qui sera diffusée en direct sur Twitch.

Sur Twitch, il y a aura deux sessions de 60 minutes par semaine, soit 2 heures par semaine, sur du contenu de formation issue du programme PEN-200. Tout le monde pourra assister gratuitement à ces sessions de formation et les participants peuvent également interagir entre eux, ainsi qu'avec les formateurs, en utilisant le serveur Discord d'Offensive Security. Précision importante, tout le monde peut assister à ces streams Twitch mais il n'y a que les étudiants inscrits qui auront accès aux labs et aux documents de formation d'Offensive Security pour se préparer au cours.

• Twitch - OffSec Official

Si cela vous tente, sachez que ça va commencer rapidement ! En effet, la première session est prévue pour le mercredi 22 juin 2022, et il y aura ensuite une session tous les mercredis et tous les vendredis jusqu'au 30 novembre 2022. En France, la diffusion aura lieu de 18h à 19h, ce qui est plutôt cool en termes d'horaire !

Prêt à jouer avec Kali Linux ?

Source

The post Kali Linux : l’Offensive Security va diffuser des cours gratuits sur Twitch ! first appeared on IT-Connect.

I. Présentation

OVHcloud propose de nombreux services Cloud dans le but de permettre aux entreprises et aux particuliers d'héberger des services divers et variés, en fonction des besoins. De ce fait, OVHcloud propose ce que l'on appelle des serveurs dédiés, c'est-à-dire des serveurs physiques, que l'on peut louer sous la forme d'un abonnement, et qui ne sont pas mutualisés. Autrement dit, lorsqu'une entreprise loue un serveur dédié, elle est la seule à exploiter ce serveur physique qui est en quelque sorte privatisé.

Après avoir soigneusement sélectionné votre serveur dédié, une nouvelle étape se présente : l'installation du système d'exploitation sur le serveur dédié. C'est une étape indispensable, que ce soit pour héberger un site web, créer un serveur de fichiers dans le Cloud, etc... En effet, le serveur dédié est une coquille vide qu'il va falloir installer, administrer et maintenir dans le temps.

Dans ce tutoriel, nous allons apprendre à installer un système d'exploitation, en l'occurrence VMware ESXi, sur un serveur dédié OVHcloud à partir de l'espace client OVHcloud. Si vous êtes dans cette situation, alors cet article tombe à pic.

II. Installation du serveur depuis l'espace client OVHcloud

La première étape consiste à se connecter à l'espace client d'OVHcloud, à partir de cette adresse : www.ovh.com

Une fois que c'est fait, vous devez cliquer sur l'onglet "Bare Metal Cloud" dans le menu. Une fois la page chargée, différents services vont s'afficher dans le menu à gauche, mais inutile de chercher très longtemps puisque c'est la section "Serveurs dédiés" qui nous intéresse. Sélectionnez le nouveau serveur dédié à installer dans la liste (si vous avez plusieurs serveurs dédiés rattachés à ce compte, ils s'affichent tous ici).

La fiche descriptive du serveur apparaît avec le paramètre "Dernier système d'exploitation (OS) installé par OVHcloud" et la valeur "Non installé". Nous allons remédier à cette situation.

Cliquez sur le menu "..." puis sur "Installer" afin de lancer l'assistant d'installation du serveur.

L'installation du serveur physique via l'espace client OVH, c'est différent puisque l'on ne peut pas accéder au serveur physiquement pour insérer une clé USB bootable. Il y a tout de même trois options :

• Installer à partir d'un template OVHcloud : c'est la formule la plus simple et que nous allons utiliser. Idéale pour un premier serveur (et un nombre restreint de serveurs)
• Installer un de vos gabarits : cette méthode permet de gagner du temps en utilisant une sorte de modèle, mais il faut d'abord installer un premier serveur pour avoir un modèle, ce qui n'est pas notre cas
• Installer à partir d'une image personnalisée : cette méthode avancée permet d'utiliser votre propre image Cloud Ready (voir cette documentation officielle)

Choisissez "Installer à partir d'un template OVH" et continuez.

Ensuite, vous devez choisir le système d'exploitation que vous souhaitez installer. Il est possible d'installer un système d'exploitation en dur tel que Debian ou Rocky Linux (ou Windows Server, avec un supplément pour la licence), mais également de s'orienter vers une solution de virtualisation dans le but de créer des VMs sur ce serveur. Ainsi, il faudra choisir un hyperviseur : VMware ESXi, Proxmox VE ou Hyper-V Server (version gratuite d'Hyper-V, en ligne de commande).

Restons sur l'idée de base : l'installation de VMware ESXi, même s'il y a une limitation à connaître (voir ci-dessous). Pour retrouver VMware ESXi, il faut choisir "Virtualisation" comme type d'OS.

Dans la liste, prenez "VMware ESXi 7.0 U3C - esxi70" qui est la version la plus récente proposée par OVHcloud. Il conviendra d'accéder au site de VMware pour demander une licence de l'édition gratuite. J'attire votre attention sur l'option "Personnaliser la configuration des partitions" qui n'est pas disponible lorsque l'on sélectionne VMware ESXi, mais qui l'est avec Proxmox.

Dans le cas où Proxmox VE est retenu, on peut voir qu'il est possible de modifier les partitions : modifier, ajouter et supprimer une partition.

Il est à noter que VMware ESXi ne supporte pas le RAID logiciel donc même si ce serveur dédié dispose de 2 disques SSD, il n'est pas possible de faire un RAID ! 

Note : certains modèles de serveurs dédiés, comme la référence "Advance Gen 2" intègre une carte RAID qui permet de faire du RAID matériel.

De ce fait, une banque de données nommée "datastore1" sera créée et elle fera 971,5 Go, puisque j'ai deux disques de 512 Go. Il y a une partition de 120 Go montée en "/scratch" qui est utile à VMware ESXi 7 pour stocker des crash dump et différentes informations (ça fait beaucoup, mais il faut faire avec, car c'est l'installeur de VMware qui veut ça).

A l'étape suivante, il y a la section "Options d'installation" où l'on peut activer le paramètre "Sauvegarder cette installation" afin de créer un fameux gabarit ! Ce n'est pas du tout obligatoire, surtout si vous n'envisagez pas d'installer d'autres serveurs dédiés via ce compte OVHcloud.

Par ailleurs, le paramètre "Hostname" est intéressant pour donner un nom qui sera attribué au système directement, et le paramètre "Script d'installation" permet d'appeler un script qui va permettre d'automatiser certaines tâches suite à l'installation du système (cela est utile surtout lorsque l'on installe une distribution Linux sur le serveur dédié). Dans le cas où une clé SSH est définie dans votre compte, vous pouvez l'associer ici via le paramètre "Clés ssh".

Cliquez sur "Valider" pour lancer l'installation du serveur dédié OVHcloud !

Pendant l'installation, qui nécessite environ 15 minutes, il n'y a rien à faire : vous pouvez faire autre chose.

Lorsque ce sera terminé, le message "L'installation est terminée" va s'afficher sur l'interface OVHcloud. Que faire ensuite ? C'est ce que nous allons voir.

Petite remarque avant de poursuivre : si vous avez pris la décision de sauvegarder cette configuration sous la forme d'un gabarit, lors de l'installation d'un prochain serveur dédié (ou la réinstallation de celui-ci), ce gabarit sera proposé.

III. Comment se connecter au serveur dédié ?

Rendez-vous dans votre boîte e-mail où vous avez dû recevoir un e-mail d'OVHcloud au sujet de votre nouveau serveur. Cet e-mail indique que le serveur est installé, qu'il est accessible en HTTPS, et qu'il y a le compte "root" prêt à l'emploi. Un lien est présent dans l'e-mail pour vous permettre de récupérer le mot de passe (qu'il faudra personnaliser par la suite) du compte root.

Cliquez sur le lien HTTPS avec l'adresse IP publique du serveur afin d'accéder à la page de connexion d'ESXi. Ici, vous devez vous connecter avec le compte "root" et le mot de passe fournit par OVHcloud.

Voilà, vous êtes connecté à votre hôte VMware ESXi ! L'installation initiale est terminée.

IV. L'installation est terminée : que faire ensuite ?

A. La banque de données

Avant de vous laisser, je souhaitais vous donner quelques informations supplémentaires, notamment sur le stockage. Si vous cliquez à gauche sur "Stockage", vous verrez qu'il y a une banque de données "datastore1" de 348,75 Go. Cela ne correspond pas aux 971,5 Go annoncés lors de l'installation. Pas de panique, nous allons remédier à cela.

Il y a deux solutions : créer une nouvelle banque de données en cliquant sur le bouton "Nouvelle banque de données" afin d'utiliser le second disque SSD NVMe. Ainsi, vous avez deux banques de données distinctes, qui pourront accueillir des VMs toutes les deux. Ce qui va donner :

L'autre option consiste à augmenter la capacité de la banque de données "datastore1". Pour cela, il suffit de la sélectionner, de cliquer sur "Augmenter la capacité" puis de choisir le disque SSD. Suite à cette opération, on obtient une banque de données de 825,5 Go. Dans un cas comme dans l'autre, il n'y a pas de sécurité au niveau du stockage en l'absence de RAID.

B. La licence VMware ESXi

Sur la page d'accueil du serveur, le message suivant s'affiche : "Vous utilisez actuellement ESXi en mode d'évaluation. Cette licence expirera dans 60 jours". Pour obtenir une licence gratuite, suivez ce lien (il faut créer un compte gratuit) : Licence VMware ESXi 7.0 (Free)

Lorsque la licence est entre vos mains, cliquez sur "Gérer" sous "Hôte" dans le menu à gauche. Ensuite, il faut cliquer sur l'onglet "Attribution de licence", indiquer la clé et valider par deux fois.

Ouf, l'hôte est activé et la licence à une date d'expiration rassurante : jamais.

C. Les sauvegardes des machines virtuelles

En cas de panne qui implique une réinstallation, l'hôte VMware ESXi en lui-même peut se réinstaller et se reconfigurer assez rapidement du moment que c'est bien documenté. La véritable richesse, ce sont les machines virtuelles hébergées par cet hyperviseur.

Il est impératif de gérer vous-même la sauvegarde de données et de vos machines virtuelles. Ce n'est pas à la charge d'OVHcloud. D'accord, mais comment fait-on ? Tout d'abord, il faut savoir qu'avec serveur dédié, OVHcloud met à disposition un espace de stockage pour les sauvegardes via la fonction "Backup storage".

Cet espace de stockage est externe au serveur, est inclus avec tous les serveurs dédiés OVHcloud, et il est accessible via différents protocoles (SMB, FTP, NFS). Par défaut, l'espace de stockage offert est de 500 Go et 1 To supplémentaire sera facturé 12 euros HT par mois).

Cet espace de stockage est accessible depuis votre serveur VMware ESXi et depuis vos VMs (selon la configuration). Pour générer des sauvegardes, il y a diverses solutions, dont :

• Le script GhettoVCB (voir mon tutoriel à ce sujet)
• La solution Nakivo Backup & Replication Free (à renouveler tous les ans)
• Etc.

Je ne connais pas la politique liée à cet espace "Backup storage" donc je ne sais pas à quel point il est redondé. De ce fait, je vous recommande de prévoir également des sauvegardes externalisées, en dehors de chez OVHcloud.

D. Mise à jour de VMware ESXi

Imaginons que le serveur VMware ESXi fraîchement installé n'exécute pas la dernière version du système : comment faire pour le mettre à jour ? Cela est vrai aussi dans le temps, où il y aura sans aucun doute des mises à jour de VMware ESXi.

Pour effectuer la mise à jour, il va falloir se connecter sur le site de VMware pour télécharger la version la plus récente et procéder à la mise à jour manuellement. Je vous invite à suivre mon tutoriel qui explique comment mettre à jour VMware ESXi (cela fonctionne pour des mises à jour majeures et mineures) :

• Tutoriel - Comment mettre à jour VMware ESXi ?

Dans ce cas précis, le serveur est livré avec une image nommée "ESXI-7.0U3c-19193900-OVH (OVHcloud SAS)", correspondante à "ESXI-7.0U3c" sauf qu'il existe la version 7.0U3d donc une mise à jour s'impose ! Suite à cette mise à jour, la valeur est différente : (Updated) ESXi-7.0U3d-19482537-standard (OVHcloud SAS).

E. L'accès SSH

L'accès SSH est actif par défaut, mais il représente une porte d'entrée supplémentaire donc si vous ne l'utilisez pas, il est préférable de le désactiver. Effectuez un clic droit sur "Hôte", puis sous "Services", cliquez sur "Désactiver Secure Shell (SSH)". Au besoin, l'opération inverse permettra de le réactiver le temps d'une manipulation (par exemple : pour réaliser une mise à jour).

V. Conclusion

Grâce à ce guide, vous êtes en mesure d'installer VMware ESXi sur un serveur dédié OVHcloud, et surtout, la mise en service d'un serveur dédié doit vous paraître moins abstraite. Je vous encourage à explorer l'espace client d'OVHcloud afin de voir les différentes fonctionnalités de votre serveur dédié.

Dans le cas où vous envisagez de mettre en place un pare-feu virtuel sur cet hyperviseur, vous devrez utiliser une seconde adresse IP publique (en tout cas, je vous le recommande). Il y a quelque temps, j'ai mis en ligne un tutoriel à ce sujet et il reste valide : OVH - Configuration d'une adresse IP failover sur PfSense.

The post Infra Cloud : comment installer un serveur dédié OVH ? first appeared on IT-Connect.

L'unité de Microsoft dédiée aux crimes numériques a engagé des poursuites judiciaires contre des cybercriminels iraniens, surnommés Bohrium, qui agissaient dans le cadre d'une opération de spear phishing.

Microsoft Digital Crimes Unit (DCU) affirme que ce groupe de cybercriminels aurait des entreprises dans différents secteurs, notamment de la technologie, du transport, mais aussi des entités gouvernementales et des écoles. Ces attaques ciblées concernent des établissements situés aux États-Unis, au Moyen-Orient et en Inde.

Pour rappel, une attaque de spear phishing est une attaque de type hameçonnage à laquelle s'ajoute une couche d'ingénierie sociale, ce qui signifie que ces attaques sont plus ou moins ciblées selon les méthodes utilisées. Dans le cas présent, Amy Hogan-Burney du DCU, précise : "Les acteurs de Bohrium créent de faux profils sur les médias sociaux, se faisant souvent passer pour des recruteurs". Elle ajoute également : "Une fois les informations personnelles des victimes obtenues, Bohrium envoie des e-mails malveillants avec des liens dont l'objectif est d'infecter les ordinateurs de leurs cibles avec des logiciels malveillants."

Grâce à ces attaques et à l'installation des malwares, les cybercriminels espéraient exfiltrer des informations sensibles, prendre le contrôle des machines infectées et explorer l'infrastructure compromise. En réaction aux activités de Bohrium et pour mettre fin à ces activités malveillantes, Microsoft a supprimé 41 domaines ".com", ".info", ".live", ".me", ".net", ".org" et ".xyz" utilisés par l'infrastructure de serveurs C2 (Command & Control) des pirates informatiques.

Récemment, Microsoft a également contrarié les activités des cybercriminels du groupe Polonium qui s'appuyaient sur OneDrive dans le cadre d'attaques informatiques.

Source

The post Spear phishing : Microsoft a bloqué 41 domaines utilisés par les pirates de Bohrium first appeared on IT-Connect.

Un de plus ! Le ransomware Black Basta prend désormais en charge le chiffrement des machines virtuelles sur des hôtes VMware ESXi. Il vient s'ajouter à la liste des ransomwares compatibles VMware ESXi, qui ne cesse de s'agrandir.

Pour les pirates informatiques, les hyperviseurs représentent la cible idéale, car en compromettant un seul serveur, ils peuvent en chiffrer plusieurs puisque le serveur VMware ESXi héberge plus ou moins de machines virtuelles selon les entreprises. Ainsi, l'attaque peut s'avérer plus rapide tout en étant dévastatrice.

Les analystes en sécurité d'Uptycs ont remarqué qu'il existe une version du ransomware Black Basta qui cible spécifiquement les serveurs VMware ESXi. De ce fait, le nom de ce ransomware vient s'ajouter à la liste de ceux qui sont déjà en mesure de s'attaquer aux hyperviseurs VMware, notamment LockBit, HelloKitty, Hive, AvosLocker ou encore plus récemment, Cheerscrypt.

Lorsqu'il entre en action, Black Basta va faire comme ses petits copains : il va rechercher la présence de banque de données dans le répertoire "/vmfs/volumes" du serveur afin de détecter l'emplacement des machines virtuelles. S'il ne trouve rien, il s'arrête, mais s'il trouve des machines virtuelles, il s'en prend aux VMs.

Pour chiffrer les machines virtuelles, le ransomware d'appuie sur l'algorithme ChaCha20 et sur du multithreading afin que la phase de chiffrement soit plus rapide. Les différents fichiers chiffrés se retrouvent avec l'extension ".basta" et un fichier "readme.txt" avec des notes (notamment un ID unique pour que les cybercriminels identifient la victime) est déposé dans chaque dossier.

Le ransomware Black Basta est assez récent, car il a été vu pour la première fois en avril 2022, et à ce moment-là, il s'attaquait aux serveurs Windows. Désormais, les pirates se tournent vers les serveurs VMware ESXi. "D'après le lien qui mène au chat et l'extension du fichier chiffré, nous pensons que les acteurs à l'origine de cette campagne sont les mêmes que ceux qui ont ciblé les systèmes Windows auparavant avec le ransomware Black Basta.", précisent les analystes d'Uptycs.

Source

The post Une version spécifique du ransomware Black Basta cible les serveurs VMware ESXi first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons voir comment mettre en place KeepAlived sur plusieurs serveurs Debian 11 afin de bénéficier d'une adresse IP virtuelle (et partagée) entre trois serveurs. Grâce à cette adresse IP virtuelle appelée VIP, on va pouvoir appliquer le principe de l'IP failover ou IP flottante en français. Pour fonctionner, KeepAlived s'appuie sur le protocole VRRP (Virtual Router Redundancy Protocol) qui est conçu pour gérer une adresse IP virtuelle entre plusieurs hôtes (une passerelle par défaut, sur un réseau, comme le fait le protocole HSRP de Cisco).

Pour cet exemple, je vais prendre comme point de départ un cluster de trois serveurs MariaDB (voir tutoriel ci-dessous) sur lequel je vais ajouter KeepAlived afin de pouvoir contacter mon cluster à partir d'une adresse IP flottante. Ainsi, mon serveur Web pourra contacter mon instance MariaDB à partir d'une adresse IP unique, et si un nœud MariaDB tombe, l'adresse VIP sera portée par un autre nœud de mon cluster.

• Comment mettre en place MariaDB Galera Cluster sur Debian 11 ?

Ainsi, lorsque KeepAlived sera mis en place sur les serveurs du cluster MariaDB, nous obtiendrons le schéma ci-dessous. Le serveur Web va toujours requêter le même serveur de base de données, en l'occurrence ici "SRV-DEB-1" car il sera prioritaire pour porter l'adresse VIP. Si le serveur SRV-DEB-1 tombe, le serveur SRV-DEB-2 devra prendre le relais (selon l'ordre de priorité définie dans la configuration de KeepAlived).

Lorsque l'on utilise MariaDB Galera pour créer un cluster de serveurs MariaDB, on fonctionne en mode multimaître, donc nous pourrions exploiter plus intensément notre cluster en ajoutant HAProxy pour effectuer de la répartition de charge entre les nœuds du cluster MariaDB Galera. Cela fera l'objet d'un autre article.

Vous pouvez mettre en place KeepAlived pour utiliser une adresse IP failover sous Linux dans d'autres cas de figure, et pas obligatoirement avec un cluster MariaDB. Par exemple, cela peut-être entre plusieurs serveurs Web.

II. IP failover avec KeepAlived

Tout d'abord, nous allons configurer le serveur SRV-DEB-1 mais ces différentes étapes seront à reproduire sur l'ensemble des nœuds du cluster MariaDB Galera. Il y a tout de même une modification à apporter à la configuration de chaque hôte : ce sera précisé.

Commençons par installer le paquet "keepalived" sur le serveur après avoir mis à jour le cache des paquets :

sudo apt-get update
sudo apt-get install keepalived

A. Fichier keepalived.conf

On va créer le fichier de configuration de KeepAlived qui n'existe pas par défaut :

sudo nano /etc/keepalived/keepalived.conf

Dans ce fichier, intégrez la configuration suivante :

# Paramètres généraux
global_defs {
   enable_script_security
}

# MariaDB est-il en cours d'exécution ?
vrrp_script check_mariadb {
   script "/usr/bin/pgrep mariadb"
   interval 1
   fall 2
   rise 2
}

# Configuration interface virtuelle
vrrp_instance VIP {
   interface ens192
   state MASTER
   priority 100
   virtual_router_id 70
   authentication {
      auth_type PASS
      auth_pass Vip2022
   }
   virtual_ipaddress {
      192.168.100.50
   }
   track_script {
      check_mariadb
   }
}

Quelques explications s'imposent pour bien comprendre ce que l'on fait... Le bloc "vrrp_instance" permet de déclarer la configuration de notre IP surnommée "VIP", avec les paramètres suivants :

- interface : le nom de l'interface locale qui va exploiter l'adresse VIP (un petit "ip a" vous permettra d'obtenir le nom de votre interface).

- state : l'état initial de chaque instance KeepAlived, il est recommandé d'indiquer "MASTER".

- priority : le serveur qui bénéficiera de l'adresse VIP sera celui qui sera en ligne et qui aura le priorité la plus élevée. Autrement dit, la priorité permet d'élire le MASTER. La valeur doit être comprise entre 1 et 255, et plus elle est élevée, plus la priorité est élevée. Ici, la valeur est 100 donc elle devra être inférieure (et différente) sur les deux autres hôtes.

- virtual_router_id : numéro pour identifier cette instance VRRP, doit être compris entre 1 et 255, et la valeur doit être la même sur les trois serveurs KeepAlived.

- authentication > auth_pass : mot de passe pour s'authentifier et participer à l'instance VRRP. Attention, le mot de passe ne doit pas excéder 8 caractères, sinon le message "(/etc/keepalived/keepalived.conf: Line 23) Truncating auth_pass to 8 characters" s'affichera au niveau du statut de KeepAlived.

- virtual_ipaddress : adresse IP virtuelle à partager entre les hôtes, donc 192.168.100.50 dans mon cas

- track_script : comment vérifier l'état de chaque serveur participant à l'instance KeepAlived ? En appliquant les conditions de "check_mariadb" où plusieurs paramètres sont définis et sont à adapter en fonction de vos besoins. En fait, la commande "/usr/bin/pgrep mariadb" sera exécutée pour voir s'il y a un processus nommé "MariaDB" qui tourne bien, et si ce n'est pas le cas, on configure que le serveur n'est pas opérationnel, et donc qu'il doit lâcher l'adresse VIP. Ce sera vérifié chaque seconde (interval) et il faut 2 erreurs pour passer en KO (fall) et 2 succès pour passer en OK (rise).

En complément, je vous recommande de regarder ces deux liens pour vous aider à créer votre configuration :

• KeepAlived - Manpage
• KeepAlived - Exemple GitHub

La configuration est prête : sauvegardez le fichier keepalived.conf. Le fichier de configuration doit être identique sur tous les serveurs participants à l'instance KeepAlived, à la différence du paramètre "priority" qu'il faut ajuster.

B. Étapes supplémentaires

Comme la configuration est prête, sécurisons le fichier en ajustant les droits :

sudo chmod 600 /etc/keepalived/keepalived.conf

Par défaut, KeepAlived utilise l'utilisateur "keepalived_script" pour exécuter les scripts c'est-à-dire la commande "/usr/bin/pgrep mariadb" dans cet exemple. Le problème, c'est que l'utilisateur n'existe pas, donc nous devons créer un utilisateur et un groupe avec ce nom (-U), mais cet utilisateur n'aura pas besoin de dossier home (-M) et n'aura pas d'un accès shell (-s). Ce qui donne la commande suivante pour le créer :

sudo useradd -U -M -s /sbin/nologin keepalived_script

Une fois que les deux étapes précédentes sont effectuées, redémarrez le processus KeepAlived sur le premier nœud (SRV-DEB-1) puis sur les autres :

sudo systemctl restart keepalived

Pour en savoir un peu plus sur l'état, il suffit d'afficher le statut :

sudo systemctl status keepalived

Sur le serveur SRV-DEB-1, en listant les adresses IP de l'hôte local, on peut remarquer qu'il porte l'adresse VIP :

ip a

III. Tester l'IP failover

A. Configuration du serveur Web

Au niveau de mon serveur Web qui héberge un site WordPress, il faut que j'édite le fichier "wp-config.php" pour lui indiquer l'adresse IP virtuelle, comme ceci :

nano /var/www/html/wp-config.php

Lorsque le serveur MySQL / MariaDB n'est pas situé sur le même serveur que le serveur Web en lui-même, il faut autoriser les connexions distantes dans MySQL / MariaDB sur chaque nœud. Une modification du fichier de configuration suivant est indispensable sur chaque nœud du cluster :

nano /etc/mysql/mariadb.conf.d/50-server.cnf

Par défaut, la propriété "bind-address" est définie sur "127.0.0.1" donc on autorise uniquement les requêtes provenant de l'hôte local (via la boucle locale). Désormais, il faut que l'on autorise les connexions en provenance d'un hôte distant en écoutant sur toutes les adresses IP locales : 127.0.0.1, 192.168.100.51 et 192.168.100.50 si l'on prend SRV-DEB-1 pour exemple.

#bind-address = 127.0.0.1
bind-address = 0.0.0.0

Ensuite, il faut donner des autorisations à l'utilisateur "utilisateur-bdd-wp" utilisé par WordPress pour administrer la base de données "wordpress" correspondante au site, à partir de l'adresse IP du serveur Web. Ce qui nécessite de se connecter à l'instance MySQL pour créer une autorisation comme ceci :

GRANT ALL privileges ON `wordpress`.* TO 'utilisateur-bdd-wp'@'192.168.100.14' IDENTIFIED BY 'Mot-de-Passe' WITH GRANT OPTION;
FLUSH PRIVILEGES;

Voilà, à partir de ce moment-là, le serveur Web peut exploiter le cluster MariaDB Galera via l'adresse VIP gérée par KeepAlived.

B. Panne de SRV-DEB-1 : que se passe-t-il ?

Pour finir, nous pouvons simuler une panne de SRV-DEB-1 pour voir ce qu'il se passe... Ainsi, on peut simplement éteindre le serveur ou arrêter le service MariaDB puisque KeepAlived vérifie que le processus tourne bien.

systemctl stop mariadb

Suite à l'exécution de cette commande, si l'on regarde le statut de SRV-DEB-1, on peut voir plusieurs messages qui montrent qu'il y a du mouvement... Et on voit "Entering FAULT STATE" ce qui montre que l'adresse VIP va être affectée à un autre hôte.

Puisque SRV-DEB-2 a une priorité de 90 et SRV-DEB-3 une priorité de 80, c'est bien SRV-DEB-2 qui hérite de l'adresse VIP. Son statut indique "Entering MASTER STATE", ce qui confirme qu'il hérite de l'adresse VIP. Une bonne chose !

Au niveau du site Web WordPress, la bascule s'est faite rapidement avec une perte de connexion pendant 2 secondes environ, avant que le site fonctionne correctement, en toute transparence. Ce système est diablement efficace, d'autant plus que l'on fonctionne en mode multimaître sur les instances MariaDB donc c'est d'autant plus simple de passer d'un nœud à un autre.

Nous venons de voir comment mettre en place une adresse VIP sous Linux (Debian) avec KeepAlived !

The post Comment mettre en place une adresse VIP avec KeepAlived sous Debian 11 ? first appeared on IT-Connect.