FreshRSS

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Debian 11 Bullseye : la nouvelle version stable de Debian est disponible !

26 août 2021 à 14:38

Debian 11, la nouvelle version stable de Debian, alias Bullseye, est disponible au téléchargement depuis quelques jours ! L'occasion de parler des nouveautés de Debian 11 !

Debian est une distribution très populaire et sur laquelle s'appuie d'autres distributions. Alors forcément, la sortie d'une nouvelle version majeure de Debian est toujours un petit événement, d'autant plus que ce n'est pas très fréquent. Par exemple, la première version de Debian 10 est sortie en juillet 2019. Quant à Debian 11, il est disponible depuis le 14 août 2021.

Avec Debian, on ne cherche pas à avoir les dernières versions des paquets, mais on mise plutôt sur la stabilité et sur des versions de paquets qui bénéficient d'un support LTS, c'est-à-dire de plusieurs années. Debian 11 ne déroge pas à cette règle.

Avant de commencer, quelques chiffres au sujet de Debian 11 :

  • 11 294 nouveaux paquets
  • 59 551 paquets au total
  • 42 821 paquets mis à jour
  • 9 519 paquets supprimés (obsolètes)

Et oui, on ne chôme pas au sein de l'équipe Debian ! Bien sûr, certains changements sont plus marquants que d'autres... Tout d'abord, sachez que Debian 11 s'appuie sur un noyau Linux 5.10, ce qui signifie que le système prend en charge nativement le système de fichiers exFAT (comme de nombreux systèmes pour NAS). Ce qui implique qu'il n'est plus nécessaire d'installer le paquet exfat-fuse. Cette version de noyau est sortie en décembre 2020 et il s'agit de la version LTS actuelle.

Des paquets populaires, notamment auprès des sysadmins, ont pu bénéficier d'une mise à jour :

  • Apache 2.4.48
  • Nginx 1.18
  • OpenSSH 8.4p1
  • Vim 8.2
  • Samba 4.13
  • GnuPG 2.2.20
  • Bind (DNS) 9.16
  • Python 3.9.1
  • Emacs 27.1
  • PHP 7.4
  • PostgreSQL 13
  • Etc.

Au sein de la documentation de Debian, il y a d'ailleurs un tableau qui montre les changements de versions opérés entre Debian 10 et Debian 11, pour certains paquets :

Debian 10 vs Debian 11
Debian 10 vs Debian 11

Même si Debian s'utilise souvent en tant que serveur sans interface graphique, il peut très bien fonctionner sur un poste de travail. Plusieurs environnements graphiques sont proposés avec Debian 11, voici la liste : Gnome 3.38, KDE Plasma 5.20, LXDE 11, LXQt 0.16, MATE 1.24 et Xfce 4.16. Pas de révolution puisque Gnome 40 n'est pas dans la liste.

Par ailleurs, l'utilisation d'une imprimante et d'un scanner devient simplifiée avec Debian 11 ! En effet, avec la prise en charge de CUPS et de SANE, il devient possible d'utiliser un périphérique sans installer un pilote spécifique au matériel ! Une très bonne nouvelle, d'autant plus que cela prend en charge la majorité des équipements des 5 dernières années.

Enfin, sachez que Debian 11 prend en charge 11 architectures matérielles différentes, parmi lesquelles : x86 (i386 / amd64), ARM (arm64 / armel / armhf), etc. Assez parlé, rendez-vous sur le site officiel pour le téléchargement et les instructions d'installation : Debian 11

Pour plus de détails sur Debian 11, je vous recommande de lire ce très bon article de NextInpact. ou cette page sur le site de Debian.

PS : Hier, c'était le 30ème anniversaire de Linux !

The post Debian 11 Bullseye : la nouvelle version stable de Debian est disponible ! first appeared on IT-Connect.

Mettre à jour Debian 10 vers Debian 11 (Bullseye)

18 août 2021 à 14:00
Par : Le Crabe

Debian 11 « Bullseye » – la nouvelle version de la plus célèbre distribution Linux – est disponible depuis le 14 août 2021. Cette nouvelle version propose de nouvelles versions pour de nombreux paquets, de nouvelles fonctionnalités ainsi qu’un support de 5 ans. Vous possédez un ordinateur ou une machine sous Debian 10 et vous souhaitez faire la mise à niveau vers Debian 11 ? Dans ce tutoriel...

Source

Comment se connecter en RDP à Debian 10 avec xRDP ?

18 août 2021 à 11:00

I. Présentation

Dans ce tutoriel, nous allons voir comment installer xRDP sur Debian pour se connecter en RDP depuis Windows sur notre machine Linux. La connexion sera possible depuis Windows, mais également une autre machine sous Linux, sous macOS ou sous Android : il suffit d'un client RDP.

Le protocole RDP (Remote Desktop Protocol) sert à se connecter à distance sur une machine avec un client Bureau à distance. Quant à xRDP, il s'agit d'une implémentation open source du protocole RDP de Windows.

Au niveau de la machine Linux, il y a un prérequis : vous devez avoir un environnement de bureau installé. Que ce soit GNOME, MATE, XFCE, etc... Au choix. Par exemple, pour installer XCFE Desktop sur Debian 10, il faudra exécuter ces commandes :

apt update -y
apt install task-xfce-desktop -y

Si vous avez une machine Debian 10 avec un environnement de bureau installé, vous pouvez passer à la suite.

II. Installation de xRDP sous Debian 10

Ouvrez un Terminal sur la machine Debian et commencez par mettre à jour les paquets (le préfixe sudo est nécessaire si vous n'utilisez pas le compte "root").

sudo apt update

Ensuite, installez le paquet xRDP qui est dans les dépôts par défaut :

sudo apt install xrdp -y

Suite à l'installation, on peut s'assurer que le service est bien démarré :

sudo systemctl status xrdp

Malheureusement, si l'on regarde le détail du statut, on constate qu'il y a une erreur.

Nous devons ajouter l'utilisateur "xrdp", associé au serveur xRDP, au groupe ssl-cert de notre machine Debian. En fait, xRDP s'appuie sur le fichier "ssl-cert-snakeoil.key" pour la partie certificat de la connexion RDP, mais ce fichier est accessible uniquement aux membres du groupe "ssl-cert".

sudo adduser xrdp ssl-cert

Redémarrez le service xRDP :

sudo systemctl restart xrdp

Enfin, activez le démarrage automatique du service xRDP :

sudo systemctl enable xrdp

Notre serveur xRDP est prêt à l'emploi, passons à la configuration.

Note : si vous utilisez un firewall sur votre machine Debian, il faut penser à ouvrir le port 3389 qui est le port par défaut du protocole RDP. Par exemple pour UFW, voici la commande à exécuter : sudo ufw allow 3389

III. Configurer xRDP sous Debian 10

Sans apporter de modifications à la configuration, on pourrait déjà se connecter sur notre machine Linux à distance. Toutefois, il me semble important de vous présenter les fichiers de configuration du serveur xRDP.

Il y a un premier de configuration ici :

/etc/xrdp/xrdp.ini
Fichier de configuration xRDP
Fichier de configuration xRDP

Dans ce fichier, on pourrait modifier le port d'écoute du serveur xRDP pour ne pas utiliser 3389. Cela se configure au niveau de la directive suivante qu'il suffit de modifier :

port=3389

Ce fichier permet également de gérer l'apparence de l'écran de connexion (message, couleurs, image de fond, etc.).

Il y a un second fichier de configuration, que voici :

/etc/xrdp/sesman.ini

Il contient de nombreux paramètres. Il va permettre d'empêcher l'utilisateur "root" de se connecter en RDP :

# Définir sur "false" pour empêcher le compte "root" de se connecter en RDP (par défaut, c'est autorisé)
AllowRootLogin=false

Dans la configuration de xRDP, on peut aussi autoriser seulement les utilisateurs d'un groupe spécifique, par défaut "tsusers", à se connecter en RDP. Le problème, c'est que ce groupe n'est pas créé et que tout le monde peut se connecter.

Pour déclarer un groupe, il faut renseigner cette directive :

TerminalServerUsers=tsusers

Au passage, il faut basculer sur "true" la directive ci-dessous pour imposer la vérification des membres du groupe pour gérer la connexion.

AlwaysGroupCheck=true

On obtient le fichier suivant :

xRDP - Exemple sesman.ini

Il faut penser à créer votre groupe si ce n'est pas déjà fait. On peut aussi créer un groupe en prenant le nom suggéré par défaut :

sudo groupadd tsusers

Ensuite, on va ajouter un utilisateur au groupe :

sudo adduser florian tsusers

Enfin, pensez à redémarrer le service xRDP pour que les changements soient pris en compte. Il ne reste plus qu'à tester. Si un utilisateur n'est pas autorisé à se connecter, le gestionnaire de sessions lui renverra le message suivant :

Pour gérer les sessions, il y a d'autres paramètres à connaître :

# Nombre de sessions RDP maximales, en même temps
MaxSessions=10

# Tuer une session déconnectée après X minutes ou secondes
KillDisconnected=true

# Délai avant de tuer une session déconnectée. Si "0" = 60 secondes
DisconnectedTimeLimite=0

Les événements sont loggués dans deux fichiers de log :

/var/log/xrdp.log
/var/log/xrdp-sesman.log

Passons maintenant aux tests.

IV. Se connecter à Debian 10 depuis Windows

Depuis la machine Windows, il suffit d'ouvrir le client Bureau à distance, de saisir l'adresse IP de l'hôte Linux et de se connecter. Comme c'est la première connexion, il faudra accepter le certificat.

On arrive sur une fenêtre de connexion, où l'on renseigne un identifiant et un mot de passe.

Et voilà, on est connecté sur la machine Debian en RDP !

V. Résoudre les erreurs de connexion xRDP

Après avoir établi une connexion, si vous obtenez un écran noir ou un écran bleu (de la couleur du fond du prompt RDP) : pas de panique ! En fait, cela se produit si vous utilisez la même session (même utilisateur) en direct sur le serveur et en connexion RDP.

Vous devez fermer la session en local sur la machine et relancer la connexion RDP.  Ensuite, cela va fonctionner.

Il y a de fortes chances pour que deux prompts s'affichent suite à la connexion pour vous demander le mot de passe Administrateur :

  • Il est nécessaire de s'authentifier pour créer un périphérique avec gestion de couleurs
  • Authentication is required to refresh the system repositories

Authentication is required to refresh the system repositories

Cela se produit à cause du composant PolKit qui gère les interactions d'un utilisateur standard avec les applications. Nous allons créer une politique personnalisée pour qu'il nous laisse tranquilles quand on se connecte en RDP.

Créez le fichier suivant :

sudo nano /etc/polkit-1/localauthority.conf.d/02-allow-colord.conf

Ajoutez le contenu ci-dessous pour créer la règle :

polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.color-manager.create-device" ||
 action.id == "org.freedesktop.color-manager.create-profile" ||
 action.id == "org.freedesktop.color-manager.delete-device" ||
 action.id == "org.freedesktop.color-manager.delete-profile" ||
 action.id == "org.freedesktop.color-manager.modify-device" ||
 action.id == "org.freedesktop.color-manager.modify-profile" ||
 action.id == "org.freedesktop.packagekit.system-sources-refresh" || action.id == "org.freedesktop.packagekit.system-network-proxy-configure") &&
 subject.isInGroup("{users}")) {
 return polkit.Result.YES;
 }
});

Sans même redémarrer le service xRDP ou un autre service, vous pouvez retenter une connexion RDP : cette fois-ci vous allez accéder au bureau Linux sans être embêté ! 😉

Nous venons de voir dans ce tutoriel comment installer et configurer xRDP sous Debian 10. C'est assez simple, mais il faut penser à apporter quelques réglages pour que ce soit pleinement opérationnel.

The post Comment se connecter en RDP à Debian 10 avec xRDP ? first appeared on IT-Connect.

Télécharger les ISO de Debian 11 (Bullseye)

18 août 2021 à 09:00
Par : Le Crabe

Après de deux ans de développement, Debian 11 – nom de code « Bullseye » – est disponible ! Cette nouvelle version sera prise en charge pendant 5 ans, jusqu’en 2026. Sur cette page, vous trouverez les liens pour télécharger les ISO de Debian 11 (Bullseye) en téléchargement direct (direct download). Ces ISO sont nécessaires pour créer une clé USB d’installation de Debian. Utilisez ensuite cette clé...

Source

Comment vérifier l’espace disque sous Linux ?

16 août 2021 à 11:00

I. Présentation

Dans ce tutoriel, nous allons apprendre à vérifier l'espace disque sous Linux (Ubuntu, Debian, Kali Linux) à l'aide des commandes df et du. Que ce soit sur votre ordinateur, un serveur physique, une machine virtuelle, une distribution Linux gérée par WSL ou encore un serveur VPS, les commandes que nous allons voir aujourd'hui fonctionneront et font partie des commandes à connaître ! 😉

Grâce à la commande df, nous allons pouvoir regarder l'espace disque restant sur chaque partition et chaque disque monté au sein du système Linux. Ensuite, grâce à la commande du, nous allons pouvoir obtenir la taille des dossiers : de quoi faciliter l'identification des dossiers les plus volumineux de votre système, ce qui sera utile pour libérer de l'espace disque.

II. L'espace disque sous Linux avec df

Commencez par vous connecter sur votre machine et exécutez la commande df, sans option. D'ailleurs, "df" signifie "disk free", ce qui s'annonce plutôt de bien par rapport à ce que l'on cherche à faire !

df

Vous allez obtenir une sortie similaire à celle ci-dessous. Pour chaque volume, nous avons plusieurs informations au sujet de l'espace de stockage : la taille totale, l'espace utilisé, l'espace disponible et le pourcentage d'utilisation du disque. Néanmoins, ce n'est pas très facile à lire.

Linux - Commande "df"
Linux - Commande "df"

Reprenons la commande précédente et ajoutons simplement le paramètre "-h" : il va permettre d'avoir la sortie au format "human readable", c'est-à-dire plus facilement à lire pour les humains. Les valeurs seront alors indiquées en Gigaoctets ou Megaoctets, ce qui sera plus agréable.

df -h

Constatez l'amélioration de vos propres yeux grâce à l'image ci-dessous. 🙂

Linux - Commande "df -h"
Linux - Commande "df -h"

Intéressons-nous un instant aux différentes colonnes :

  • Sys. de fichiers : le nom du système de fichiers, c'est-à-dire les différents disques physiques, volumes logiques, etc.
  • Taille : la taille totale du système de fichiers
  • Utilisé : l'espace disque consommé
  • Dispo : l'espace disponible
  • Uti% : le pourcentage d'espace disque utilisé
  • Monté sur : point de montage correspondant à ce système de fichiers

Pour être un peu plus précis, on peut dire que /dev/sda1 correspond à notre disque physique, qui est en réalité un disque virtuel sur une VM. Les différents volumes tmpfs sont temporaires et utilisés par différentes fonctions et processus du système.

Cette commande très simple permet d'obtenir une synthèse de l'espace disque utilisé sur sa machine. Efficace.

Pour obtenir l'état d'un volume spécifique, on précise son nom ou alors "/" pour afficher les informations sur le disque primaire.

df -h /

Ce qui revient à saisir la commande suivante :

df -h /dev/sda1

Enfin, sachez que l'on peut obtenir le type de système de fichiers utilisés pour chaque volume. Il suffit d'ajouter l'option "T".

df -hT
# ou
df -h -T
Linux - Commande "df -hT"
Linux - Commande "df -hT"

III. La taille d'un dossier sous Linux avec du

Maintenant que l'on maîtrise la commande df et que l'on sait afficher l'espace disque restant sur notre machine Linux, on va apprendre à utiliser une seconde commande : du, pour disk usage.

Tout d'abord, exécutez la commande sans paramètre :

du

Surprise : la commande vous indique l'espace disque consommé par rapport au dossier dans lequel vous vous situez, mais aussi l'espace disque pour chaque sous-dossier.

Là encore, le résultat n'est pas très lisible, mais nous avons le droit à la même option que pour la commande df, à savoir "-h". Essayez :

du -h

On peut voir la taille de chaque sous-dossier, de manière récursive, ce qui est très puissant à partir d'une commande si simple ! À la fin de la sortie de la commande, il y a la taille totale.

Linux - Commande "du -h"
Linux - Commande "du -h"

Si l'on veut obtenir seulement la taille totale, il suffit d'ajouter l'option "s", comme ceci :

du -hs

Si l'on se déplace dans le dossier "/etc/nginx" et que l'on utilise du, on peut connaître la taille utilisée par ce dossier (cumul de tous les fichiers et sous-dossiers qu'il contient).

Linux - Commande "du -hs"
Linux - Commande "du -hs"

Bien sûr, nous ne sommes pas obligés de nous positionner dans le dossier avant d'utiliser du. On peut spécifier le chemin directement, comme ceci :

sudo du -hs /etc/nginx/

J'ai ajouté le préfixe "sudo" volontairement, car si vous utilisez un utilisateur classique, il se peut que vous n'ayez pas les droits sur tous les fichiers et dossiers. En préfixant avec "sudo", vous pouvez contourner un éventuel "accès refusé".

On pourrait utiliser cette commande pour calculer l'espace disque utilisé par le profil (home) d'un utilisateur :

du -hs /home/florian

Le mot  de la fin.

Vous l'aurez compris, la commande df permet d'obtenir un état global de l'espace disque utilisé sur les différents volumes, tandis que la commande du permet d'obtenir la taille des différents dossiers.

The post Comment vérifier l’espace disque sous Linux ? first appeared on IT-Connect.

Mettre à jour Debian 10 vers Debian 11 (Bullseye)

14 août 2021 à 17:43

Debian 11 (nom de code Bullseye) succède à Debian 10 (Buster).
Cette nouvelle version inclut plus de 11294 nouveaux paquets, pour un total de plus de 59551 paquets.
Entre autres, sont maintenant inclus GNOME 3.38, KDE Plasma 5.20, LXDE 11, LXQt 0.16, MATE 1.24, et Xfce 4.16.
Enfin, LibreOffice est mis à jour vers la version 7.0.
Attention, il ne s'agit pas d'une version LTS (Long Time Support).

Pour bénéficier de cette nouvelle version, vous pouvez mettre à niveau votre système avec APT.

Ce tutoriel vous guide pour mettre à jour Debian 9 vers 10 et ainsi passer de Debian 10 à Debian 11.
Vous trouverez toutes les étapes pour réussir la mise à niveau de votre distribution Linux Debian.

Mettre à jour Debian 10 vers 11 (Bullseye)

Les versions de Debian

Ce tableau récapitule les versions de Debian avec leurs noms de code.
La dernière version LTS est Debian 9.

Version et nom de codeDate de publicationFin de support
Debian 11 ("Bullseye")Aout 2021
Debian 10 ("Buster")20192022
Debian 9 ("Stretch") - LTS20176 juillet 2020
Fin LTS : juin 2022
Debian 8 ("Jessie") LTS201517 juin 2018
Debian 7 ("Wheezy")201325 avril 2016
Fin LTS : 31 mai 2018
Debian 6.0 ("Squeeze")201131 mai 2014
Fin LTS : 29 février 2016
Debian GNU/Linux 5.0 ("Lenny")20096 février 2012
Debian GNU/Linux 4.0 ("Etch")200715 février 2010
Debian GNU/Linux 3.1 ("Sarge")200531 mars 2008
Debian GNU/Linux 3.0 ("Woody")200230 juin 2006
Debian GNU/Linux 2.2 ("Potato")200230 juin 2003
Debian GNU/Linux 2.1 ("Slink")30 septembre 2000
Fin LTS : 30 octobre 2000
Debian GNU/Linux 2.0 ("Hamm")
Liste des versions de Debian

Comment mettre à jour Debian 10 vers Debian 11 (Bullseye)

Pour commencer, vérifiez la version Debian de départ pour s'assurer que vous êtes bien en Debian 9.
Par exemple avec la commande :

lsb_release -a

D'autres méthodes pour afficher la version de Debian :

Mettre à jour le gestionnaire de packages et les référentiels APT

  • Faites une sauvegarde des sources APT en copiant le fichier sources.list vers sources.list.bak
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
  • Éditez le fichier /etc/apt/sources.list :
sudo vim /etc/apt/sources.list
Mettre à jour le gestionnaire de packages et les référentiels APT pour mettre à jour Debian 10 vers Debian 11
  • Puis modifiez toutes les références de ce fichier de Buster à Bullseye. Les entrées doivent apparaître comme suit :
deb http://deb.debian.org/debian/ bullseye main
deb-src http://deb.debian.org/debian/ bullseye main
deb http://deb.debian.org/debian/ bullseye-updates main
deb-src http://deb.debian.org/debian/ bullseye-updates main
deb http://security.debian.org/debian-security bullseye-security main
deb-src http://security.debian.org/debian-security bullseye-security main
Mettre à jour le gestionnaire de packages et les référentiels APT pour mettre à jour Debian 10 vers Debian 11

Mettre à niveau de Debian 10 vers Debian 11

  • Téléchargez et mettez à jour les sources APT :
sudo apt-get update
apt-get update - Mettre à niveau de Debian 10 vers Debian 11
  • Ensuite, exécutez les mises à jour sur les packages logiciels pour préparer la mise à niveau du système d'exploitation :
sudo apt-get -y upgrade
apt-get -y upgrade - Mettre à niveau de Debian 10 vers Debian 11
  • Une fois la mise à jour des paquets terminée, vous revenez sur le terminal
apt-get -y upgrade - Mettre à niveau de Debian 10 vers Debian 11
  • Faire O pour confirmer. Puis des questions peuvent être posées durant cette mise à jour comme la conservation de fichiers de configuration
sudo apt-get dist-upgrade
apt-get dist-upgrade - Mettre à niveau de Debian 10 vers Debian 11
  • Là aussi des questions sont posées sur la conservation des fichiers de configuration
Confirmer les modifications de la configuration lors d'une mise à niveau Debian
  • Une fois le processus terminé, vous revenez sur le terminal
apt-get dist-upgrade - Mettre à niveau de Debian 10 vers Debian 11
  • Redémarrez le système pour démarrer dans Debian 11 BullEeye. Cela va démarrer sur la dernière version du noyau Linux. Vous pouvez attendre quelques heures s i vous ne pouvez pas redémarrer la machine de suite.
sudo reboot
Bravo ! vous avez réussi à mettre à jour Debian 10 vers Debian 11.

Vérifier la mise à jour Debian 11

Enfin, une fois les système réinitialisé, on vérifie la version de Debian pour s'assurer que la version est bien passée en Debian 11.
A nouveau on peut utiliser la commande lsb_release :

[email protected]:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye

Le champ Description doit afficher Debian GNU / Linux 11 (Bullseye).
Enfin la commande release affiche 11 et Codename est sur Bullseye :

Vérifier la mise à jour Debian 11 avec la commande release

Supprimer les packages obsolètes

Après la mise à niveau vers Debian 11, votre système peut avoir des packages et des dépendances obsolètes qui ne sont plus nécessaires.
Il est alors possible de nettoyer les restes de la mise à jour de la distribution.

Pour supprimer les packages obsolètes, exécutez la commande --purge autoremove :

sudo apt --purge autoremove

L’article Mettre à jour Debian 10 vers Debian 11 (Bullseye) est apparu en premier sur malekal.com.

Proxmox VE 7 est disponible pour tous (Debian 11, Btrfs, QEMU 6…)

8 juillet 2021 à 07:00
Par : EVOTk

Proxmox VE 7 300x225 - Proxmox VE 7 est disponible pour tous (Debian 11, Btrfs, QEMU 6...)Proxmox Virtual Environment est une solution de virtualisation libre. Mardi dernier, Proxmox annonçait la sortie d’une nouvelle version majeure de son outil : Proxmox VE 7. Ce dernier bénéficie de plusieurs évolutions et de la dernière mouture Debian 11 (non sortie officiellement). Explications… Proxmox VE 7 Proxmox VE 7 est basé sur Debian 11. Cela pourrait sembler curieux puisque la dernière version officielle est la version 10.10. Pour la version 11 (nom de code « Bullseye »), l’éditeur indique à côté de […]

Cet article Proxmox VE 7 est disponible pour tous (Debian 11, Btrfs, QEMU 6…) est apparu en premier sur Cachem

Comment protéger son serveur Linux des attaques avec CrowdSec ?

7 juillet 2021 à 11:30

I. Présentation

Vous connaissez surement Fail2Ban, un outil qui permet d'analyser les journaux de votre machine Linux dans le but de bannir les adresses IP correspondantes à des hôtes qui ont des comportements malveillants ou suspects. Dans ce tutoriel, nous allons voir comment mettre en place CrowdSec pour protéger son serveur Linux des attaques.

Qu'est-ce que l'outil CrowdSec ?

CrowdSec est un outil open source, gratuit, français, qui s'inspire de Fail2ban et qui a pour objectif de protéger votre serveur, en détectant puis en bloquant les attaques.

Lorsque des adresses IP sont bloquées par une instance de CrowdSec, l'information est remontée dans une base centralisée au travers d'une API : ce qui permet d'avoir une liste d'adresses IP malveillantes communautaire et gérée par CrowdSec. Bien sûr, il y a un mécanisme de réputation qui entre en jeu : une adresse IP n'est pas bannie chez tout le monde dès le premier signalement, c'est un peu plus complexe que cela vous vous en doutez bien.

Actuellement, CrowdSec est disponible en version 1.0. Suite à la sortie de cette version, CrowdSec a fait évoluer l'architecture interne de sa solution puisque les composants (client, bouncers, processus) communiquent entre eux via une API REST locale. L'utilisation d'une API est particulièrement intéressante pour rendre indépendants les composants les uns des autres et éviter d'attaquer directement la base de données (c'est réservé au service de l'API REST locale).

Pour ce premier article au sujet de CrowdSec et en guise d'introduction, je vous propose de prendre un serveur Web Nginx comme cible et d'apprendre à le protéger avec CrowdSec.

Voici les prérequis pour suivre ce tutoriel :

  • Une machine Debian avec un serveur Web Nginx opérationnel et accessible depuis l'extérieur (pour l'attaque distante)
  •  Une machine avec l'outil Nikto installé (cela peut-être via WSL) pour réaliser l'attaque

II. Installation de CrowdSec sur Debian 10

Pour l'installation, il y a plusieurs façons de faire : simplement aller piocher dans les dépôts de Debian (sur Debian Bullseye pour le moment), utiliser le dépôt CrowdSec, installer soi-même le package .deb, l'installer en mode interactif à partir d'une archive et d'un script d'installation, ou alors à partir d'une image Docker.

Nous allons utiliser le dépôt CrowdSec. Il suffit de l'ajouter à notre machine et de mettre à jour la liste des paquets :

wget -qO - https://s3-eu-west-1.amazonaws.com/crowdsec.debian.pragmatic/crowdsec.asc |sudo apt-key add - && echo "deb https://s3-eu-west-1.amazonaws.com/crowdsec.debian.pragmatic/$(lsb_release -cs) $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/crowdsec.list > /dev/null sudo apt-get update
sudo apt-get update

Ensuite, on lance l'installation de crowdsec :

sudo apt-get install crowdsec

Lors de l'installation, Crowdsec va analyser votre machine à la recherche de services qu'il prend en charge. Dans cet exemple, il détecte bien le système Linux, mais également les fichiers journaux de Nginx : access.log et error.log.

Ce qui donne :

Grâce à cette analyse de notre machine locale, Crowdsec va installer les collections correspondantes aux services détectés et qui vont lui permettre de détecter les attaques.

Pour lister les collections CrowdSec, utilisez la commande suivante du CLI CrowdSec (cscli) :

cscli collections list

À la fin de l'installation, on redémarre Crowdsec :

sudo systemctl reload crowdsec

Passons à l'utilisation de Crowdsec en prenant une simulation d'attaque comme exemple.

III. Scan du serveur Nginx : comment Crowdsec va-t-il réagir ?

A. Première analyse de notre serveur Web avec Nikto

Nikto est un outil open source qui permet de scanner les serveurs Web. Il permet de rechercher des vulnérabilités, des fichiers dangereux, etc... À l'aide de cet outil, on va déclencher un scanner sur notre serveur Web Nginx pour voir comment réagit Crowdsec. Il s'agit simplement d'un scanne, et non d'une attaque.

Avant toute chose, manipulons quelques instants la ligne de commande CrowdSec : cscli. Pour lister les décisions actives, c'est-à-dire les adresses IP que CrowdSec a décidé de bloquer, il faut exécuter la commande suivante :

cscli decisions list

On peut voir que la liste est vide : No active decisions. Essayez maintenant avec un paramètre supplémentaire :

cscli decisions list --all

Là, nous avons d'autres adresses IP : il s'agit des adresses IP obtenues à partir de la liste centralisée et partagée par CrowdSec directement (construire à partir des instances CrowdSec et des remontées associées).

Passons à l'utilisation de Nikto.

Depuis une machine distante, située sur un autre réseau, je vais déclencher un scan à destination de mon site it-connect.tech. Pour cette attaque, je vais utiliser l'outil mentionné précédemment : Nikto. Voici la commande à utiliser pour déclencher l'analyse :

nikto -h it-connect.tech

Nikto va requêter le site it-connect.tech à la recherche de vulnérabilités et de défaut de configuration. Sur le serveur Web, relancez la commande précédente : il se passe des choses.

cscli decisions list

Mon adresse IP fait l'objet d'une surveillance et Crowdsec a envie de la bannir pour une durée de 4 heures ! On peut voir qu'il y a deux événements associés à cette adresse IP.

Je dis bien "qu'il a envie" de la bannir, car il ne l'a pas fait, en tout cas, pour le moment ! 😉 - Disons que pour le moment, CrowdSec a identifié l'adresse IP malveillante.

Pour en savoir un peu plus, listons les alertes :

cscli alerts list

Le champ "VALUE" nous donne l'adresse IP source : il s'agit de l'adresse IP publique de la machine qui exécute le scanner via Nikto. On peut voir qu'il y a de nombreuses alertes générées par CrowdSec suite au scan que j'ai déclenché.

B. L'intervention du Bouncer Nginx

Pour que CrowdSec puisse bloquer une adresse IP, autrement dit qu'il puisse mettre en pratique la décision, il s'appuie sur des Bouncers. Ces bouncers vont permettre de contrer les menaces grâce à différentes actions (bloquer, présentation d'un Captcha, etc.).

Un bouncer s'apparente à un module qui va appliquer la décision. Par exemple, si l'on installe le Bouncer Nginx (ce que nous allons faire juste après), CrowdSec va bloquer mon adresse IP directement dans Nginx (et pas sur le firewall de ma machine Linux, vraiment dans Nginx) pour appliquer l'action "bannir".

Voici un lien vers la liste des bouncers disponibles : CrowdSec - Bouncers

Note : il existe de nombreux bouncers et d'autres sont en cours de développement. Par exemple, il y a un bouncer CloudFlare, un bouncer WordPress, mais pas encore de bouncer Apache.

Pour protéger notre serveur Nginx, on va installer le Bouncer Nginx. Il faut que l'on télécharge le paquet pour l'installer manuellement. Par la suite, il sera possible d'installer encore plus simplement les Bouncers.

À partir de la ligne de commande, on télécharger le fichier "cs-nginx-bouncer.tgz" :

wget https://github.com/crowdsecurity/cs-nginx-bouncer/releases/download/v0.0.4/cs-nginx-bouncer.tgz

Ensuite, on décompresse l'archive obtenue :

tar -xzvf cs-nginx-bouncer.tgz

On se positionne dans le dossier "cs-nginx-bouncer-v0.0.4" :

cd cs-nginx-bouncer-v0.0.4/

On lance l'installation :

sudo ./install.sh

D'ailleurs, le script d'installation va en profiter pour installer quelques dépendances, si elles sont manquantes bien sûr. Voici la liste des dépendances installées sur ma machine par ce Bouncer : lua, lua-sec, libnginx-mod-http-lua, lua-logging. Pour information, LUA est un système qui permet de développer et d'intégrer des modules au sein de Nginx.

Pour vérifier que notre bouncer est opérationnel, on va lister les bouncers :

sudo cscli bouncers list

Il est bien là et il est valide : parfait !

Avant d'aller plus loin, on va redémarrer Nginx :

sudo systemctl restart nginx

C. Deuxième analyse avec Nikto : CrowdSec va-t-il me bannir ?

Désormais, CrowdSec dispose d'un bouncer capable de nous bannir si l'on effectue des actions suspectes. On va vérifier s'il fonctionne correctement.

Sur la machine Kali Linux, on va tenter de se connecter à notre site Web. On va effectuer une requête avec l'outil CURL :

curl -I it-connect.tech

On voit bien que le code retourné par la page est "HTTP/1.1 200 OK" : cela signifie que l'on a pu accéder à la page du site et qu'il n'y a pas eu d'erreur.

Maintenant, je relance mon scanne Nikto :

nikto -h it-connect.tech

Dans la foulée, je relance ma commande CURL : oups, j'ai un code différent cette fois-ci ! J'obtiens le code "HTTP/1.1 403 Forbidden",  ce qui correspond à un accès refusé. Il y a de fortes chances pour que je sois bloqué par CrowdSec !

Nous allons le vérifier facilement avec la commande suivante (que l'on a vue précédemment) :

cscli decisions list

Sans réelle surprise, mon adresse IP apparaît bien et je suis bannie pour une durée de 4 heures !

Puisqu'il s'agit d'un faux positif étant donné que je m'attaque moi-même, cela me donne l'occasion de vous montrer comment débannir manuellement une adresse IP (il faut remplacer X.X.X.X par l'adresse IP publique) :

cscli decisions delete --ip X.X.X.X

De la même façon, on peut aussi bannir manuellement une adresse IP :

cscli decisions add --ip X.X.X.X

Dans ce cas, la raison du bannissement sera "Manual ban from <login API>". Par défaut, une adresse IP est bannie pendant 4 heures, mais on peut être un peu plus méchant et partir sur 24 heures directement :

cscli decisions add --ip X.X.X.X --duration 24h

IV. Le tableau de bord CrowdSec via Metabase

CrowdSec propose un container Docker basé sur Metabase pour bénéficier d'un tableau de bord très sympathique qui va permettre d'analyser les attaques subies par sa machine. Au préalable, il faut penser à installer Docker (apt-get install docker.io -y) sur la machine. Ensuite, on peut créer le container de cette façon :

sudo cscli dashboard setup --listen 0.0.0.0

À la fin de la création, le nom d'utilisateur et le mot de passe s'affichent dans la console :

À partir de l'hôte local ou d'un hôte distant, on peut accéder à l'interface de Metabase et s'authentifier.

Une fois connecté, on obtient des statistiques précises et des graphiques : nombre de décisions actives, nombre d'alertes, répartition des attaques par adresses IP, etc... Je me suis amusé à attaquer ma propre machine, mais visiblement je ne suis pas le seul a avoir essayé ! 😉

Un peu plus bas dans la page, nous avons d'autres graphes. Cette interface est très pratique pour effectuer des analyses pendant ou après une attaque.

Note : la commande cscli metrics permet d'obtenir des informations sur les métriques à partir de la ligne de commande, mais bon, une fois que l'on a gouté à l'interface Metabase c'est difficile de s'en passer.

Il faut savoir que CrowdSec est capable d'intégrer à ce tableau de bord d'anciens logs générés par vos applications avant même que l'outil soit déployé sur votre serveur.

Lorsque vous avez terminé d'utiliser le dashboard, vous pouvez l'arrêter temporairement grâce à cette commande :

sudo cscli dashboard stop

Pour le relancer, il suffira d'exécuter :

sudo cscli dashboard start

V. Conclusion

Ce premier tutoriel au sujet de CrowdSec touche à sa fin : je dis bien "ce premier article", car je pense qu'il y en aura d'autres sur le sujet ! Nous avons vu le bouncer pour Nginx, mais il existe un bouncer nommé "cs-firewall-bouncer" et qui va permettre à CrowdSec d'interagir avec le firewall, notamment iptables et nftables.

Grâce à CrowdSec, nous avons pu mettre en place un outil efficace pour protéger notre serveur Web en détectant et bloquant les attaques.

Pour finir, voici la commande qui va vous permettre de voir s'il y a des mises à jour disponibles pour les différents bouncers, collections, etc... De votre installation :

sudo cscli hub update

Ensuite, pour déclencher la mise à jour :

sudo cscli hub upgrade

Quelques liens :

Voilà, c'est tout pour cette fois !

Que pensez-vous de CrowdSec ? Pensez-vous le tester pour protéger un ou plusieurs de vos serveurs ?

Merci à Thibault Koechlin d'avoir pris le temps de me présenter CrowdSec.

The post Comment protéger son serveur Linux des attaques avec CrowdSec ? first appeared on IT-Connect.

Debian – comment installer Nginx en tant que serveur Web ?

5 juillet 2021 à 13:00

I. Présentation

Dans ce tutoriel, nous allons voir comment mettre en place un serveur Web Nginx sur Debian 10, dans le but d'héberger un site Web qui s'appuie sur PHP.

Nginx, que l'on prononce Engine-X, est un logiciel open source qui permet de monter un serveur web, mais également un reverse proxy pour mettre en cache des éléments et assurer la répartition de charge entre plusieurs serveurs Web.

À la différence d'Apache, Nginx est pensé pour les sites à très fort trafic : il est d'ailleurs connu et reconnu pour être un logiciel très performant. Dans de nombreux cas, il n'est pas utilisé en tant que serveur Web directement, mais plutôt en tant que reverse proxy pour gérer les connexions des clients en frontal.

Pour ma part, je vais utiliser une machine sous Debian 10 pour mettre en place le serveur Nginx.

🎥 Débutez avec Nginx grâce à ce tutoriel vidéo (installation, création d'un site, intégration de PHP, mise en place d'un certificat SSL, etc.).

II. Installer Nginx

Commençons par installer le paquet Nginx, mais avant cela mettons à jour le cache de paquets sur notre machine :

sudo apt update -y

Ensuite, on passe à l'installation du paquet Nginx, ce qui est très simple puisqu'il est disponible dans les dépôts officiels.

sudo apt install nginx -y

Lorsque l'installation est effectuée, on peut regarder quelle version est installée à l'aide de la commande suivante (similaire à celle d'Apache ou d'autres paquets) :

sudo nginx -v

Suite à l'installation, le serveur Nginx est déjà démarré, on peut le vérifier avec la commande ci-dessous. Cela permettra de voir qu'il est bien actif.

sudo systemctl status nginx

Pour que notre serveur Web Nginx démarre automatiquement lorsque la machine Linux démarre ou redémarre, on doit exécuter la commande suivante :

sudo systemctl enable nginx

Dès à présent, on peut accéder à la page par défaut du serveur Web à partir d'un navigateur. Si votre machine où est installé Nginx dispose d'une interface graphique, on peut y accéder en local :

http://127.0.0.1

À partir d'une machine distante, utilisez l'adresse IP de votre serveur Web plutôt que l'adresse de loopback (127.0.0.1). Voici la page qui doit s'afficher :

Le contenu de cette page Web correspond au fichier suivant :

/var/www/html/index.nginx-debian.html

En fait, le site par défaut de Nginx est déclaré dans le fichier de configuration suivant :

/etc/nginx/sites-enabled/default

La racine de ce site est :

/var/www/html

On peut le vérifier grâce à la directive suivante :

root /var/www/html;

Avant de continuer, prenez connaissance des informations suivantes :

  • Le fichier de configuration global de Nginx est :
 /etc/nginx/nginx.conf
  • Le dossier qui contient les fichiers de configuration des sites disponibles est :
/etc/nginx/sites-available/
  • Le dossier qui contient les fichiers de configuration des sites actifs est :
/etc/nginx/sites-enabled/

Lorsque l'on crée la configuration d'un nouveau site, on crée le fichier dans "sites-available" et ensuite lorsque le site est prêt à être activé, on crée un lien symbolique vers "sites-enabled". Cela tombe bien, nous allons créer notre premier site Web dans Nginx : l'occasion de voir ce mécanisme, identique à Apache.

III. Créer un premier site dans Nginx

Nous allons déclarer un nouveau site sur notre serveur Web Nginx. Pour ma part, ce sera le site "it-connect.tech", accessible également avec "www.it-connect.tech". Il sera stocké à l'emplacement suivant : /var/www/it-connect.tech.

Commençons par créer le dossier qui va accueillir notre site Web :

sudo mkdir /var/www/it-connect.tech

Ensuite, on va déclarer l'utilisateur www-data comme propriétaire de ce dossier. Il s'agit de l'utilisateur par défaut de Nginx (correspondant à la propriété "user www-data" du fichier nginx.conf).

sudo chown -R www-data:www-data /var/www/it-connect.tech/

On va définir les droits de ce dossier :

sudo chmod 755 /var/www/it-connect.tech/

Ensuite, c'est le moment de créer notre fichier "index.html" : cela correspond à la page d'accueil de notre site Web.

sudo nano /var/www/it-connect.tech/index.html

Dans ce fichier, insérez le code suivant :

<html>
<head></head>
<body>
<h1>Bienvenue sur IT-Connect !</h1>
</body>
</html>

Enregistrez et fermez le fichier. Il est temps maintenant de créer le fichier de configuration de notre site Internet. Dans le dossier "sites-available", on va créer le fichier "it-connect.tech" : grâce à ce nom, il sera facilement identifiable.

sudo nano /etc/nginx/sites-available/it-connect.tech

Dans ce fichier, intégrez la configuration suivante :

server {

    listen 80;
    listen [::]:80;

    root /var/www/it-connect.tech;

    index index.html;
    server_name it-connect.tech www.it-connect.tech;

    location / {
        try_files $uri $uri/ =404;
    }
}

Voici quelques consignes à appliquer quand vous éditez ce fichier, mais aussi pour bien le comprendre :

  • Respectez l'indentation (espace au début des lignes) pour avoir un fichier de configuration lisible facilement
  • Les lignes de type "commentaires" commencent par le caractère "#"
  • Les lignes qui se terminent par ";" correspondent à des directives, c'est-à-dire des options de configuration
  • Le bloc "Server" permet de déclarer un hôte virtuel et à l'intérieur on déclare sa configuration

Maintenant, je vais vous expliquer la signification des différentes directives de la configuration que l'on vient de créer.

listen 80; 
listen [::]:80;

La directive "listen" : la première ligne permet d'indiquer que le serveur Nginx écoute sur toutes ses adresses IPv4, sur le port 80, ce qui correspond au protocole HTTP. La seconde ligne est similaire, mais pour toutes les adresses IPv6 du serveur, toujours sur le port 80.

Pour que le serveur Web écoute seulement sur une adresse IP spécifique du serveur Linux, on pourrait utiliser :

listen 192.168.100.100:80;

En admettant que 192.168.100.100 soit l'adresse IP du serveur Linux.

root /var/www/it-connect.tech;

La directive "root" permet de déclarer la racine du site Internet : en toute logique, on précise la racine que l'on a créée précédemment et où se situe la page index.html.

index index.html;

D'ailleurs, c'est la directive "index" qui permet d'indiquer le nom (ou les noms) des pages par défaut du site. Si l'on définit "index.html", lorsque l'on accède à la racine du site, le serveur Web va chercher à nous présenter le contenu de la page index.html.

server_name it-connect.tech www.it-connect.tech;

La directive "server_name" sert à déclarer le nom de domaine, ou les noms de domaine, concerné par ce bloc "Server". On peut également utiliser une adresse IP. En l'occurrence dans cet exemple, on souhaite que Nginx traite les requêtes qui arrivent sur it-connect.tech et www.it-connect.tech.

location / { 
    try_files $uri $uri/ =404; 
}

Intéressons-nous au dernier bloc de notre fichier de configuration. La directive "location" permet d'indiquer un chemin relatif dans l'URL. En indiquant "/", on cible toutes les requêtes puisqu'une requête commence toujours par "/" après le nom de domaine pour spécifier le chemin vers une page.

Enfin, grâce à la directive "try_files" suivie de $uri et $uri/, nous allons chercher à vérifier l'existence du fichier ou du dossier (d'où le "/") passé en paramètre dans l'URL. La variable $uri reprend automatiquement l'URL saisie par le client qui accède au site. En fait, la règle "try_files $uri $uri/ =404;" permet de retourner une erreur 404 (page introuvable) au client s'il essaie d'accéder à un fichier ou un dossier qui n'existe pas.

Maintenant que vous en savez plus sur la configuration que nous venons de créer, vous pouvez passer à la suite ! 😉

Pour que notre site soit actif et la configuration chargée par Nginx, nous devons créer un lien symbolique : rappelez-vous de l'intérêt du dossier "sites-enabled". Pour créer un lien symbolique et renvoyer "/etc/nginx/sites-enabled/it-connect.tech" vers "/etc/nginx/sites-available/it-connect.tech", voici la commande :

ln -s /etc/nginx/sites-available/it-connect.tech /etc/nginx/sites-enabled/it-connect.tech

On pourrait copier-coller le fichier d'un dossier vers l'autre, mais cela ne serait pas pratique. Grâce à ce lien symbolique, on a qu'un seul fichier à gérer.

Avant de redémarrer le service Nginx, je vous invite à vérifier la syntaxe de la configuration :

sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

C'est tout bon, on peut redémarrer le service Nginx :

sudo systemctl restart nginx

On peut aussi arrêter Nginx et le démarrer, en deux temps :

sudo systemctl start nginx 
sudo systemctl stop nginx

Le site doit être accessible à deux adresses :

http://www.it-connect.tech
http://it-connect.tech

Je n'ai pas abordé la notion d'enregistrement DNS, mais on part du principe que c'est déjà fait de votre côté. Si vous souhaitez tester sans agir sur les enregistrements DNS, vous pouvez modifier le fichier hosts de votre machine Windows ou Linux.

Par exemple, si vous avez une interface graphique sur votre machine Nginx (ce qui sera peut-être le cas sur un lab), vous pouvez modifier le fichier "/etc/hosts" et ajouter la ligne suivante :

0.0.0.0 it-connect.tech www.it-connect.tech

Si vous utilisez une machine distante, remplacez "0.0.0.0" par l'adresse IP de votre machine Linux.

Les fichiers de logs, c'est-à-dire les journaux de Nginx, sont stockés à l'emplacement suivant :

# Log d'accès (toutes les requêtes)
/var/log/nginx/access.log
# Log d'erreurs
/var/log/nginx/error.log

Bien sûr, ils sont consultables avec la commande "tail" pour récupérer les dernières lignes ajoutées :

sudo tail -f /var/log/nginx/access.log 
sudo tail -f /var/log/nginx/error.log

Passons à l'étape suivante pour que Nginx prenne en charge les scripts PHP.

IV. Ajouter PHP à Nginx

Pour utiliser PHP avec un serveur web Nginx, il est obligatoire d'installer PHP-FPM (PHP FastCGI Process Manager) : Nginx lui transférera les requêtes PHP pour qu'elles soient traitées. 

Si l'on installe le paquet "php-fpm" de Debian 10, nous allons récupérer la version 7.3, ce qui n'est pas top. Il vaut mieux récupérer une version plus récente, par exemple PHP-FPM 7.4.X. Pour cela, nous devons agir sur les dépôts de notre machine. Exécutez les commandes suivantes pour ajouter notre nouveau dépôt PPA :

sudo apt-get update

On récupère la clé GPG du dépôt que l'on va ajouter :

sudo apt -y install lsb-release apt-transport-https ca-certificates 
sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg

Enfin, on ajoute le dépôt :

echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list

Il ne reste plus qu'à mettre à jour le cache de paquets et à installer PHP-FPM 7.4 :

sudo apt-get update
sudo apt-get install php7.4-fpm

En complément, et selon ce que vous souhaitez faire sur votre serveur Web Nginx, pensez à installer les extensions PHP qui vont bien (pour MySQL, par exemple).

Nous devons modifier la configuration de notre site :

sudo nano /etc/nginx/sites-available/it-connect.tech

Le bout de configuration suivant doit être ajouté au sein du groupe "Server", à la suite du bloc "location" déclaré précédemment :

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
}

Ce qui donne :

Intégration de PHP à Nginx

Grâce à la directive "location ~ \.php$", on peut agir sur le traitement de tous les fichiers PHP. Ce qui est fort intéressant puisque l'on va pouvoir préciser le fichier de configuration (fastcgi-php.conf) et le chemin vers le socket lié à PHP-FPM, c'est-à-dire le chemin vers php7.4-fpm.sock. Si vous utilisez une version différente de PHP-FPM, le chemin devra être adapté.

Lorsque la configuration est prête, enregistrez le fichier et redémarrez le service Nginx. Avant cela, pensez à vérifier qu'il n'y a pas d'erreur de syntaxe :

sudo nginx -t
sudo systemctl restart nginx

V. Vérifier le bon fonctionnement de PHP avec Nginx

Notre serveur Nginx doit être en mesure de gérer l'exécution des scripts PHP. Nous allons le vérifier. Je vous invite à créer un fichier "info.php" à la racine de notre site Web :

sudo nano /var/www/it-connect.tech/info.php

Dans ce fichier, ajoutez le contenu ci-dessous. Pour rappel, la fonction phpinfo() permet d'obtenir un état détaillé de PHP sur un serveur Web.

<?php
phpinfo();
?>

Enregistrez le fichier et tentez d'accéder à la page info.php avec un navigateur. Normalement, vous devez obtenir une page similaire à celle ci-dessous. On peut voir que PHP fonctionne et que j'utilise bien PHP 7.4.

PHP sur un serveur web Nginx
PHP sur un serveur web Nginx

Voilà ! Votre serveur Web sous Nginx est prêt à être utilisé !

The post Debian – comment installer Nginx en tant que serveur Web ? first appeared on IT-Connect.

Installer et configurer Postfix avec SPF + DKIM + DMARC

20 juin 2017 à 15:04

Postfix est serveur mail (MTA) très efficace et populaire et disponible sur la plupart des distributions Linux (Ubuntu, Debian, CentOS, Redhat ...).
Dans ce tutoriel, nous allons voir comment configurer Postfix avec les normes et technologiques : Sender Policy Framework (SPF), DKIM (DomainKeys Identified Mail) et DMARC.

Vous trouverez toutes les explications pour la mise en place de SPF et DKIM sur Postfix avec les fichiers de configuration.
En fin du tutoriel, des aides pour tester l'envoie de mail et vérifier que votre serveur de mail répond bien à ces spécifications.

Installer et configurer Postfix avec SPF + DKIM + DMARC

Introduction

La sécurisation des serveurs de mails (MTA) et la lutte contre l'usurpation d'email (spoofing en anglais), le phishing et SPAM n'est pas forcément chose facile.
Une des problématiques étant que le protocole Simple Mail Transfer Protocol (SMTP) utilisé pour le transfert du courrier électronique sur Internet ne prévoit pas de mécanisme de vérification de l'expéditeur.
C'est-à-dire qu'il est facile d'envoyer un courrier avec une adresse d'expéditeur factice, voire usurpée.
Quelques liens du site autour de ces problématiques :

Afin de limiter ces problèmes, des normes sont apparues pour tenter de limiter ces usurpations.
Quelques rappels :

  • SPF (Sender Policy Framework) : Définit les domaines ou IP autorisés à envoyer des mails dans la déclaration DNS du domaine. Cela vise à protéger contre l'usurpation d'identité et le SPAM
  • DKIM (DomainKeys Identified Mail) : ajoute une signature cryptographique à l’en-tête de chaque message envoyé afin de prouver que votre serveur SMTP est bien l'émetteur des emails. Là aussi il s'agit de protéger contre l'usurpation d'identité
  • DMARC (Domain-based Message Authentication, Reporting and Conformance) : Définit une politique à appliquer sur les emails reçus

Installation et configuration Postfix avec SPF + DKIM

SPF : Faire ses déclarations DNS

On commence par effectuer ses déclarations DNS SPF.
Pour cela, ouvrez l'interface de votre fournisseur DNS.
Vous pouvez vous en inspirer pour effectuer votre déclaration SPF.

Ceci indique que seul le serveur 1.1.1.1 peut envoyer des emails pour ce domaine :

@ 10800 IN TXT "v=spf1 ip4:1.1.1.1 ~all"

Il est aussi possible de déclarer un reverse DNS :

@ 10800 IN TXT "v=spf1 ptr:monreverse.mon_domaine.fr ~all"

Ceci indique que tous les serveurs ayant un “reverse” se terminant par malekal.com peuvent envoyer les emails de ce domaine:

@ 10800 IN TXT "v=spf1 ptr:malekal.com ~all"

ici seulement le serveur 94.23.44.69 peut envoyer des mails

@ 10800 IN TXT "v=spf1 ip4:94.23.44.69 ~all"

Configurer OpenDKIM

On commence par installer le package opendkim, le package spamass-milter est nécessaire si vous utilisez spamassassin.

 apt-get install opendkim opendkim-tools spamass-milter

Si vous utilisez clamav, il faut installer le packageclamav-milter (non testé)

Éditez le fichier /etc/opendkim.conf à la fin, ajoutez les éléments suivants :

AutoRestart             Yes
AutoRestartRate         10/1h
UMask                   002
Syslog                  yes
SyslogSuccess           Yes
LogWhy                  Yes

Canonicalization        relaxed/simple

ExternalIgnoreList      refile:/etc/opendkim/TrustedHosts
InternalHosts           refile:/etc/opendkim/TrustedHosts
KeyTable                refile:/etc/opendkim/KeyTable
SigningTable            refile:/etc/opendkim/SigningTable

Mode                    sv
PidFile                 /var/run/opendkim/opendkim.pid
SignatureAlgorithm      rsa-sha256

UserID                  opendkim:opendkim

Socket                  inet:[email protected]
  • AutoRestart: Redémarre le filtre en cas de plantage.
  • AutoRestartRate: Indique le ratio de redémarrage minimum et maximum. Si le nombre de redémarrage est plus rapide que ce ratio, ce dernier va être arreté.
  • UMask: indique les permissions et ID utilisateur/groupe.
  • Syslog, SyslogSuccess, *LogWhy: activé les log syslog
  • Canonicalization: méthode canonical de signature des messages,
    • simple : autorise aucune modification
    • relaxed : autorise des modificiations mineures comme changer les espaces.
    • relaxed/simple : L'en-tête du mail utilisera la méthode relaxed et le corps du message utilisera la méthode simple.
  • ExternalIgnoreList: la liste des des hôtes par lequel les mails peuvent passer sans signatures.
  • InternalHosts: liste des hôtes à ne pas vérifier et signer : signature sans vérification.
  • KeyTable: Le chemin des tables de clés de signatures.
  • SigningTable: Liste des tables de signatures pour lequels seront basés les champs from des mails.
  • Mode: declares operating modes; in this case the milter acts as a signer (s) and a verifier (v)
  • PidFile: Le fichier PID (process identification number)
  • SignatureAlgorithm:  indique l'algorithme de signatures à utiliser
  • UserID: Le UserID du processus opendkim
  • Socket: Le socket d'écoute de opendkim. Postfix va envoyer les messages à opendkim pour les vérification et signatures à travers ce socket.

A noter que vous pouvez déclarer un serveur DNS avec nameservers dans le fichier de configuration opendkim autre que celui de /etc/resolv.conf si vous filtrez certains résolutions DNS.

Editez /etc/default/opendkim

Ajoutez à la fin :

smtpd_milters = unix:/spamass/spamass.sock, inet:localhost:12301
non_smtpd_milters = unix:/spamass/spamass.sock, inet:localhost:12301

Si vous utilisez clamav et avez installé clamav-milter (non testé), cela donne :

smtpd_milters = unix:/spamass/spamass.sock, unix:/clamav/clamav-milter.ctl, inet:localhost:12301
non_smtpd_milters = unix:/spamass/spamass.sock, unix:/clamav/clamav-milter.ctl, inet:localhost:12301

On créé les dossiers suivants :

mkdir /etc/opendkim
mkdir /etc/opendkim/keys

Éditez le fichier :

/etc/opendkim/TrustedHosts

Il s'agit ici de déclarer les zones de confiances, modifiez selon votre classe d'IP et domaines.
Vous pouvez utiliser les wildcards, si vous désirez déclarer des sous-domaines

127.0.0.1
localhost
192.168.0.1/24
*.malekal.com

Éditez le fichier /etc/opendkim/KeyTable pour y insérer la ligne suivante
Il s'agit de la déclaration des clés par domaine avec le selector.
Par défaut, opendkim utilise le selector mail.
Modifiez le domaine ci-dessous, ajoutez d'autres domaines, si vous êtes en multi-domaines

mail._domainkey.malekal.com malekal.com:mail:/etc/opendkim/keys/malekal.com/mail.private

La table de signature dans le fichier : /etc/opendkim/SigningTable
Là aussi, modifiez et ajoutez les domaines selon votre configuration.

*@malekal.com mail._domainkey.malekal.com

Si vous utilisez spamassassin et vous avez installé spamass-milter.
Modifiez le paramètre OPTIONS du fichier /etc/default/spamass-milter

OPTIONS="-u spamass-milter -i 127.0.0.1 -m -I -- --socket=/var/run/spamassassin/spamd.sock"

Génération des clés privées et publiques

cd /etc/opendkim/keys
mkdir malekal.com
cd malekal.com

puis on génère les clés :

opendkim-genkey -s mail -d malekal.com
  • -s indique le sélecteur, ici dans notre cas il s'agit de mail
  • -d le domaine,

Cette commande créé deux fichiers :

  • mail.private est votre clé privée
  • mail.txt contient la clé publique

puis on attribue le bon utilisateur et groupe au fichier :

chown opendkim:opendkim mail.private

Ajouter les clés publics au DNS

On récupère la clé publique :

cat mail.txt

La clé publique se trouve dans le paramètre p.
On récupère l'entrée mail._domainkey correspondant à la table du fichier /etc/opendkim/KeyTable

mail._domainkey IN      TXT     ( "v=DKIM1; k=rsa; "
          "p=lacleprubliquequiestlongue" )  ; ----- DKIM key mail for malekal.com

La clé publique est à récupérer afin de la placer dans la déclaration DNS.
Cette déclaration DNS est de type TXT, elle est de la forme :

mail._domainkey 10800 IN TXT "v=DKIM1; k=rsa; p=lacleprubliquequiestlongue"

On redémarre les services :

service postfix restart
service spamass-milter restart
service opendkim restart

Installer clamav et Spamassassin

Pour installer un filtrage antivirus et Spam sur votre passerelle SMTP Postfix, cela se passe sur ces tutoriels :

Tester l'envoi de mail

Voici un exemple de déclaration DNS SPF et DKIM sur les serveurs Gandi :

Il faut attendre quelques heures que les modifications DNS se propagent.

Test et vérification de l'envoi de mails

Vérifier les entrées DNS de votre serveur mail

Pour vérifier les entrées DNS,
Sur Windows, vous pouvez la commande nslookup

nslookup
> set type=TXT
> malekal.com
Test et vérification de l'envoi de mails

Sur GNU/Linux, vous pouvez utiliser la commande dig afin de vérifier l'entrée spf.

dig TXT malekal.com
Test et vérification de l'envoi de mails

Voici la commande à utiliser pour vérifier l'entrée DKIM avec le selector mail.

dig mail._domainkey.malekal.com TXT

On peut utiliser aussi ce site qui vérifie aussi le contenu de la clé publique.

Pour les tests emails, de malekal.com vers une adresse gmail.com
Lorsqu'aucune entrée SPF n'est déclarée, le serveur gmail "devine" la règle SPF à appliquer "best guess record domain for"

Authentication-Results: mx.google.com;
spf=pass (google.com: best guess record for domain of [email protected] designates 94.23.44.69 as permitted sender) [email protected]
Test et vérification de l'envoi de mails

avec une déclaration SPF, la vérification est en succès :

Authentication-Results: mx.google.com;
spf=pass (google.com: domain of [email protected] designates 94.23.44.69 as permitted sender) [email protected]
Test et vérification de l'envoi de mails

Côté DKIM,

nslookup
> set type=txt
> mail._domainkey.malekal.com
Test et vérification de l'envoi de mails

on récupère un en-tête et on y retrouve la signature DKIM avec les informations déclarées :

  • -d domaine
  • -s le sélecteur
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=malekal.com; s=mail; t=1497960309; bh=xHOSDWRzKq/MzUni/4wNm2H933+iN2Z7+9Lq3JdxPvA=; h=To:Subject:Date:From:From; b=xxxx/code>

Tester l'envoie de mail

Côté Gmail, on obtient le dkim=pass et spf=pass

Test et vérification de l'envoi de mails

Vous pouvez aussi vérifier les entrées DNS avec le service mxtoolbox : http://mxtoolbox.com/

Test et vérification de l'envoi de mails

Le site mail-tester.com permet aussi de vérifier l'envoi de mail (surtout pour des mailling).
Rendez-vous sur le site https://www.mail-tester.com/
Récupérer l'adresse email, cliquez sur vérifier votre score
Envoyez un mail sur l'adresse email indiquée.

Test et vérification de l'envoi de mails

On note et des commentaire sont attribués à la configuration de votre serveur mail.

Test et vérification de l'envoi de mails

Voici un log de réception avec SPF et DKIM en fonction :

Dec 9 13:13:20 www postfix/smtpd[23402]: connect from mail-oi1-f171.google.com[209.85.167.171]
Dec 9 13:13:20 www policyd-spf[23471]: None; identity=helo; client-ip=209.85.167.171; helo=mail-oi1-f171.google.com; [email protected]; [email protected]
Dec 9 13:13:20 www policyd-spf[23471]: Pass; identity=mailfrom; client-ip=209.85.167.171; helo=mail-oi1-f171.google.com; [email protected]; [email protected]
Dec 9 13:13:20 www postfix/smtpd[23402]: B2309102668: client=mail-oi1-f171.google.com[209.85.167.171]
Dec 9 13:13:20 www postfix/cleanup[23472]: B2309102668: message-id=<[email protected]om>
Dec 9 13:13:20 www opendkim[23367]: B2309102668: mail-oi1-f171.google.com [209.85.167.171] not internal
Dec 9 13:13:20 www opendkim[23367]: B2309102668: not authenticated
Dec 9 13:13:21 www opendkim[23367]: B2309102668: DKIM verification successful
Dec 9 13:13:21 www opendkim[23367]: B2309102668: s=20161025 d=gmail.com SSL
Dec 9 13:13:21 www postfix/qmgr[19745]: B2309102668: from=<[email protected]>, size=2758, nrcpt=1 (queue active)
Dec 9 13:13:21 www spamd[10336]: spamd: connection from ::1 [::1]:44134 to port 783, fd 5
Dec 9 13:13:21 www spamd[10336]: spamd: processing message <[email protected]om> for spamassassin:1004
Dec 9 13:13:21 www postfix/smtpd[23402]: disconnect from mail-oi1-f171.google.com[209.85.167.171]
Dec 9 13:13:21 www spamd[10336]: util: refusing to untaint suspicious path: "/${SAHOME}"
Dec 9 13:13:21 www spamd[23476]: util: setuid: ruid=1004 euid=1004 rgid=1004 33 1004 1004 egid=1004 33 1004 1004
Dec 9 13:13:21 www spamd[10336]: spamd: clean message (-1.9/5.0) for spamassassin:1004 in 0.5 seconds, 2855 bytes.
Dec 9 13:13:21 www spamd[10336]: spamd: result: . -1 - BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_MSPIKE_H2,SPF_PASS,TVD_SPACE_RATIO scantime=0.5,size=2855,user=spamassassin,uid=1004,required_score=5.0,rhost=::1,raddr=::1,rport=44134,mid=<[email protected]om>,bayes=0.000000,autolearn=ham autolearn_force=no
Dec 9 13:13:21 www postfix/pickup[19744]: 94001105C23: uid=1004 from=<[email protected]>
Dec 9 13:13:21 www postfix/pipe[23474]: B2309102668: to=<[email protected]>, relay=spamassassin, delay=1.1, delays=0.53/0/0/0.52, dsn=2.0.0, status=sent (delivered via spamassassin service)
Dec 9 13:13:21 www postfix/qmgr[19745]: B2309102668: removed
Dec 9 13:13:21 www postfix/cleanup[23472]: 94001105C23: message-id=<[email protected]om>
Dec 9 13:13:21 www opendkim[23367]: 94001105C23: no signing table match for '[email protected]'
Dec 9 13:13:21 www opendkim[23367]: 94001105C23: DKIM verification successful
Dec 9 13:13:21 www opendkim[23367]: 94001105C23: s=20161025 d=gmail.com SSL
Dec 9 13:13:21 www postfix/qmgr[19745]: 94001105C23: from=<[email protected]>, size=3337, nrcpt=1 (queue active)
Dec 9 13:13:21 www spamd[10333]: prefork: child states: II
Dec 9 13:13:21 www postfix/local[23480]: 94001105C23: to=<[email protected]>, orig_to=<[email protected]>, relay=local, delay=0.06, delays=0.05/0.01/0/0, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -Y -a $DOMAIN)
Dec 9 13:13:21 www postfix/qmgr[19745]: 94001105C23: removed

Enfin cet autre site permet de tester le contenu des mails.

Test et vérification de l'envoi de mails

Configurer DMARC sur Postfix

DMARC, qui vient de l'anglais Domain-based Message Authentication, Reporting and Conformance est un standard qui vient se greffer à SPF et DKIM

DMARC standardise la façon dont les destinataires (au sens des MTA destinataires) réalisent l'authentification des e-mails en utilisant les mécanismes de Sender Policy Framework et de DomainKeys Identified Mail. Cela signifie que l'expéditeur (au sens d'un MTA expéditeur) recevra les résultats de l'authentification de ses messages par AOL, Gmail, Hotmail, Yahoo! et tout autre destinataire qui implémente DMARC.

Une politique DMARC autorise l'expéditeur à indiquer que ses e-mails sont protégés par SPF et/ou DKIM et dit au destinataire que faire si ces méthodes d'authentification échouent (ex : rejeter tous les emails sans DKIM et prévenir une adresse email). DMARC supprime les conjectures que le destinataire doit faire à propos de la façon de gérer ces messages en échec, limitant ou supprimant l'exposition de l'utilisateur aux messages potentiellement frauduleux ou dangereux. DMARC fournit également un moyen pour les destinataires de rendre compte à l'émetteur du message qu'il a réussi ou échoué l'évaluation DMARC.

v=DMARC1;p=quarantine;pct=100;rua=mailto:[email protected];ruf=mailto:[email protected];adkim=s;aspf=r
ParamètreDescription
vVersion du protocole
pctPourcentage de messages à filtrer
rufDestinataire du rapport forensique
ruaDestinataire du rapport agrégé
pProcédure avec le domaine principal
spProcédure avec le sous-domaine
adkimRègle pour le DKIM
aspfRègle pour le SPF

Source : https://fr.wikipedia.org/wiki/DMARC

Sur Debian, il faut installer le paquet opendmarc

apt-get install opendmarc

puis dans le fichier /etc/opendmarc.conf, on peut remplacer le socket.

Socket inet:[email protected]

Enfin on peut ajouter le contenu dans /etc/postfix/main.cf comme ceci.

smtpd_milters = inet:localhost:12301 inet:localhost:54321
non_smtpd_milters = inet:localhost:12301 inet:localhost:54321

Enfin relancez les daemon postfix et opendmarc.

Générer et configurer un certificat SSL sur Postfix

Pour chiffrer vos emails avec un certificat SSL sur Postfix, suivez ce tutoriel :

Liens

L’article Installer et configurer Postfix avec SPF + DKIM + DMARC est apparu en premier sur malekal.com.

Une faille présente dans Polkit depuis 7 ans touche Ubuntu, Debian, RHEL, etc.

14 juin 2021 à 13:29

Depuis 7 ans, le service système Polkit est vulnérable à une faille de sécurité importante qui permet à un attaquant en local d'effectuer une élévation de privilèges et de devenir "root" sur la machine cible.

Référencée avec le nom CVE-2021-3560, cette faille de sécurité touche de nombreuses distributions différentes. D'après Kevin Backhouse, qui est à l'origine de cette découverte, cette faille de sécurité est présente dans Polkit (PolicyKit) depuis le 9 novembre 2013. Toutes les versions de Polkit de la 0.113 à la 0.118 sont affectées. En complément, il s'avère que les distributions basées sur Debian et sur Polkit 0.105, sont vulnérables également. Des systèmes populaires sont affectés, tels que RHEL 8, Fedora 21 (ou supérieur), Debian 11 (Bullseye) ou encore Ubuntu 20.04. À l'inverse, RHEL 7, Debian 10 et Ubuntu 18.04 ne sont pas vulnérables.

Sur le site d'ArchLinux, voici la description associée à Polkit : "polkit est un ensemble d'outils permettant de gérer des règles pour autoriser la communication entre, d'un côté, des processus privilégiés offrant des services et de l'autre, des processus non privilégiés.". Ce qui permet de mieux comprendre l'utilité de cet outil et surtout que la faille permette une élévation de privilèges sur la machine. Par exemple, voici une fenêtre d'authentification générée par Polkit :

Source : Github de Kevin Backhouse

Kevin Backhouse précise que "la vulnérabilité est étonnamment facile à exploiter. Tout ce qu'il faut, c'est exécuter quelques commandes dans la console en utilisant uniquement des outils standard, comme bash, kill et dbus-send". Il précise également que la faille est déclenchée par l'envoi d'une commande via dbus-send, mais en tuant le processus alors que polkit est toujours en train de traiter la demande. Grâce à cette méthode, il parvient à bypasser l'authentification et à effectuer une élévation de privilèges, tout en étant avec un utilisateur standard à la base.

La version 0.119 de Polkit permet de se protéger contre cette vulnérabilité. Cette version est disponible depuis le 03 juin 2021. Vous pouvez l'installer sur vos systèmes dès à présent.

Pour plus de détails, lisez l'article de Kevin Backhouse sur GitHub.

Source

The post Une faille présente dans Polkit depuis 7 ans touche Ubuntu, Debian, RHEL, etc. first appeared on IT-Connect.

Comment mettre à niveau MariaDB 5.6 vers MariaDB 10.X ?

3 juin 2021 à 13:00

I. Présentation

Dans ce tutoriel, je vais vous expliquer comment mettre à niveau MariaDB 5.6 vers une version plus récente de MariaDB 10.X, par exemple MariaDB 10.3 ou MariaDB 10.6. Cette procédure s'applique aussi bien à CentOS qu'à Debian.

Il est à noter que pour migrer vos bases de données de MariaDB 5.6 sur un serveur A vers MariaDB 10.X sur un serveur B, vous devez d'abord mettre à niveau l'instance sur le serveur source. Sinon, la restauration de votre sauvegarde SQL échouera dans de nombreux cas (je pense que cela dépend en partie de la complexité de la base de données).

Je vous recommande également la lecture de la documentation sur le site MariaDB, pour prendre en compte les subtilités qu'il pourrait y avoir quant au saut de versions que vous souhaitez effectuer (par exemple : fonctions non supportées ou modifiées).

➡MariaDB Upgrade Path

Les étapes décrites dans ce tutoriel sont à respecter dans l'ordre et sont classiques pour mettre à niveau une instance de MariaDB. Prenez vos précautions en matière de sauvegarde avant de commencer. Ma machine source est sous CentOS, celle de destination sous Debian, mais toutes les commandes peuvent être adaptées à votre environnement.

II. Faire un dump de toutes les bases de données MariaDB

Nous allons commencer par effectuer une sauvegarde de l'intégralité des bases de données de votre serveur MariaDB dans son état actuel.

Note : assurez-vous d'avoir suffisamment d'espace disque votre serveur pour stocker une sauvegarde complète de toutes vos bases de données. La commande "df -h" pourra vous aider.

Sur le serveur source, connectez-vous en SSH et utilisez le compte "root" (sinon ajoutez "sudo" devant les commandes avec un compte qui dispose des droits).

Pour effectuer une sauvegarde et stocker celle-ci dans le dossier "/tmp/" :

mysqldump -u root -p --all-databases > /tmp/backup-bdd.sql

Vous devrez indiquer le mot de passe de l'utilisateur "root" de votre instance MariaDB pour effectuer la sauvegarde. Prenez un café pendant la sauvegarde 😉.

III. Ajouter le dépôt MariaDB sous CentOS

Pour récupérer une version plus récente de MariaDB, on va devoir ajouter un nouveau dépôt sur notre machine. Avant cela, mettez à jour votre cache de paquets :

# CentOS
yum update
# Debian
apt-get update

Ensuite, on va créer un fichier pour ajouter le dépôt MariaDB sur notre machine CentOS.

vi /etc/yum.repos.d/MariaDB.repo

Dans ce fichier, indiquez le code suivant :

# MariaDB 10.1 CentOS repository
# http://mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.1/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

Vous pouvez remarquer que l'on spécifie la version 10.1. Lorsque j'ai eu à faire une migration de MariaDB 5.6 vers MariaDB 10.X, j'ai préféré passer par la version 10.1 pour ne pas viser trop haut et tout faire cracher...

Sur Debian, l'ajout de ce dépôt sera différent et dépendra aussi de votre version de Debian. Pour avoir un MariaDB 5.6, c'est surement une ancienne version de Debian. Voici les informations sur le site de MariaDB où c'est bien documenté : MariaDB - Repositories

Par exemple pour Debian 8 :

sudo apt-get install software-properties-common
sudo apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc'
sudo add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://mariadb.mirrors.ovh.net/MariaDB/repo/10.2/debian jessie main'

IV. Désinstaller MariaDB 5.6

On va se débarrasser de ce bon vieux MariaDB 5.6. Pour cela, exécutez la commande correspondante à votre système (CentOS ou Debian) :

# CentOS
yum remove mariadb-server mariadb mariadb-libs
# Debian
apt-get purge mariadb-server mariadb mariadb-libs

Pour finir, on va nettoyer complètement le cache de notre gestionnaire de paquets. Comme ça, lorsque l'on va relancer l'installation de MariaDB, le système ira piocher dans notre nouveau dépôt.

# CentOS
yum clean all
# Debian
apt-get clean all

V. Installer MariaDB 10.1 (ou une autre version)

Puisque l'on cible MariaDB 10.1 dans notre dépôt, on va pouvoir installer cette version. Vous pouvez monter plus haut si vous le souhaitez, mais personnellement je n'ai pas essayé (les retours m'intéressent, j'ai préféré opter pour une étape intermédiaire).

# CentOS
yum -y install MariaDB-server mariadb-client
# Debian
apt-get install mariadb-server mariadb-client

Lorsque l'installation est effectuée, on va en profiter pour démarrer le service et activer son démarrage automatique (pas indispensable si le serveur est amené à disparaître au profit d'un nouveau).

systemctl start mariadb
systemctl enable mariadb

VI. Exécuter mysql_upgrade

Il est important d'exécuter la commande mysql_upgrade pour que l'instance MariaDB effectue une mise à niveau de vos bases de données. Cela va permettre de rendre les bases de données actuelles compatibles avec la nouvelle version installée.

mysql_upgrade

Cette action relativement rapide est indispensable ! 😉

Si besoin, vous pouvez relancer cette opération :

mysql_upgrade --force

Vous pouvez vérifier que votre instance de MariaDB tourne bien sur la nouvelle version :

mariadb -V

Bonne nouvelle ! L'instance MariaDB de votre serveur tourne sur une nouvelle version ! Il ne faudra pas se contenter de la version 10.1 puisqu'elle est déjà ancienne.

Dans ce cas, il faut modifier de nouveau les dépôts pour pointer vers une version plus récente, puis recommencer la suite du tutoriel. Dans sa documentation, MariaDB précise à chaque fois qu'il faut désinstaller MariaDB pour le réinstaller dans sa nouvelle version. Néanmoins, un update sur place peut suffire sur des petits sauts de version.

Enfin, supprimez la sauvegarde de vos bases de données effectuée au début si tout est OK pour vous.

rm /tmp/backup-bdd.sql

VII. Déplacer les bases de données sur un nouveau serveur

Si vous souhaitez déplacer vos bases de données sur un nouveau serveur, suivez la suite de ce tutoriel. Je vous recommande d'avoir la même version de MariaDB des deux côtés pour éviter les mauvaises surprises.

Commencez par refaire une sauvegarde des bases de données. C'est important puisqu'entre temps, les bases de données ont subi un "mysql_upgrade" qui n'est pas anodin 😉.

mysqldump -u root -p --all-databases > /tmp/backup-bdd.sql

Lorsque c'est fait, transférez le fichier SQL sur votre nouveau serveur. La commande "scp" pourra être utile pour le récupérer directement par SSH. Par exemple, depuis le nouveau serveur on peut récupérer la sauvegarde à distance :

scp -r <utilisateur>@<ip-serveur-source>:/tmp/backup-bdd.sql /tmp
scp -r [email protected]:/tmp/backup-bdd.sql /tmp

Sur le nouveau serveur, on va restaurer la sauvegarde de toutes les bases de données et de la configuration associée :

mysql -u root -p < /tmp/backup-bdd.sql

Si votre sauvegarde est imposante, c'est-à-dire plusieurs giga-octets, il se peut qu'une erreur soit renvoyée dès le début de l'importation. Dans ce cas, modifiez temporairement deux paramètres dans votre MariaDB pour accepter ce fichier volumineux :

mysql -u root -p

Puis, saisissez ces deux commandes :

set global net_buffer_length=1000000;
set global max_allowed_packet=1000000000;

Relancez la restauration de la sauvegarde :

mysql -u root -p < /tmp/backup-bdd.sql

Une fois que la restauration est terminée, redémarrer votre instance MariaDB :

systemctl restart mariadb

Vérifiez que vos applications fonctionnent correctement ! 👍👍

Si ce n'est pas encore fait, vous pouvez effectuer les montées de version sur le serveur de destination. Il n'était peut-être pas totalement à jour pour être en phase avec le serveur source.

The post Comment mettre à niveau MariaDB 5.6 vers MariaDB 10.X ? first appeared on IT-Connect.
❌