FreshRSS

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

Télécharger et installer des logiciels sur Ubuntu Linux

1 décembre 2021 à 10:00
Par : Le Crabe

Vous avez l’habitude d’installer des logiciels sur Windows mais vous ne savez pas du tout comment vous y prendre pour installer Firefox, VLC et tous vos logiciels préférés sur Linux ? Vous êtes au bon endroit : cet article va vous expliquer comment installer n’importe quel logiciel sur une distribution GNU/Linux (Debian, Ubuntu…) et ce, de plusieurs façons différentes. Contrairement à ce que vous...

Source

Bloquer les attaques sur son serveur Web (Apache + PHP) avec CrowdSec

2 novembre 2021 à 10:30

I. Présentation

Dans ce tutoriel, nous allons voir comment l'outil gratuit CrowdSec va nous permettre de protéger un serveur Web (Apache et PHP) contre les attaques informatiques.

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

Récemment, les équipes de CrowdSec ont travaillé sur le développement d'un bouncer PHP pour protéger les serveurs Web qui tournent sur "Apache + PHP". Une excellente une idée puisque PHP est utilisé sur une très très grande majorité des sites Internet à l'échelle mondiale.

A. L'objectif du jour

Pour suivre ce tutoriel, nous allons utiliser deux machines : un serveur Web qui sera notre cible, et une seconde machine pour émettre une attaque très légère, mais réelle. Ce qui donne :

  • Un serveur Web sous Debian 11
    • Apache et PHP installés, avec un site Web tout simple
    • CrowdSec va être déployé pour protéger le serveur
  • Un poste client pour simuler une attaque, sous Kali Linux pour ma part
    • L'outil Nikto sera utilisé pour effectuer un scan du serveur Web afin de rechercher des vulnérabilités ou des erreurs de configuration

Avant d'aller plus loin, je vous invite à prendre connaissance de mon premier article au sujet de CrowdSec où je présente plus précisément l'outil et dans lequel nous avons vu comment protéger un serveur Web sous Nginx.

Si vous êtes prêt à découvrir ce second cas d'usage de CrowdSec, poursuivez la lecture !

II. Mise en place d'Apache et PHP sur Debian 11

Pour la mise en place du serveur Apache avec PHP, je vous recommande de lire ce tutoriel sur la mise en place d'un serveur LAMP sous Debian 11. Il servira de point de départ afin d'avoir un serveur Web opérationnel.

On va se contenter d'une simple page d'accueil "index.php" avec un message "Hello !". Pour créer cette page, suivez ces quelques étapes.

sudo nano /var/www/html/index.php

Insérez ce petit bout de code :

<?php
echo "<h1>Hello !</h1>";
?>

Enfin, supprimez la page d'accueil d'origine d'Apache.

sudo rm /var/www/html/index.html

Le serveur Web est prêt, nous avons une page PHP en place. Elle est accessible sur le domaine it-connect.tech.

III. Installation de CrowdSec sur Debian 11

Sur Debian 11, CrowdSec est directement dans les dépôts, ce qui va nous faciliter la vie. Il suffit de mettre à jour le cache des paquets et de lancer l'installation :

sudo apt-get update
sudo apt-get install -y crowdsec

Le cas échéant, si le paquet n'est pas disponible, vous devez utiliser cette méthode pour réaliser l'installation :

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash 
sudo apt install crowdsec

Lors de l'installation, CrowdSec va analyser votre machine afin de détecter les services présents et de télécharger les collections associées. Ces composants vont permettre à CrowdSec de détecter les attaques (sans les bloquer).

On peut lister les collections avec la commande suivante :

cscli collections list

Si la collection "base-http-scenarios" est présente dans la liste, ce qui normalement le cas si vous avez déjà installé Apache sur votre serveur, cela va notamment permettre de bloquer les mauvais User Agents, comme ceux utilisés par certains outils de scans. Ceci n'est qu'un exemple, car cette collection va détecter d'autres événements comme la recherche de backdoors, etc.

On peut regarder si nous avons des décisions actives au niveau de notre instance CrowdSec. En toute logique, non. Vérifions que ce soit bien le cas avec la commande ci-dessous issue de "cscli", l'ensemble de commandes associées à CrowdSec.

sudo cscli decisions list

IV. Mon serveur Web Apache + PHP vs Nikto

A. Premier scan avec Nikto

Rappel : Nikto est un outil open source qui sert à analyser un serveur Web à la recherche de vulnérabilités ou de défaut de configuration.

Avant toute chose, il faut installer l'outil Nikto sur la machine qui sert à réaliser le scan. Pour ma part, j'utilise Kali Linux via WSL (Windows Subsystem for Linux).

L'installation s'effectue très simplement :

sudo apt-get update
sudo apt-get install nikto

Avant d'exécuter le scan Nikto, vous pouvez vérifier que votre machine Kali Linux parvient à charger la page d'accueil de votre site :

curl -I it-connect.tech

Si vous obtenez un résultat avec un code de retour HTTP égal à 200, c'est tout bon ! Maintenant, on va lancer un scan de notre serveur Web avec Nikto. Pour cela, on spécifie l'adresse IP de l'hôte cible ou le nom de domaine, et on laisse tourner. Comme ceci :

nikto -h it-connect.tech

Suite au scan avec Nikto, mon adresse IP est bien dans le viseur de CrowdSec puisqu'il a décidé de bannir mon adresse IP. Cependant, l'adresse IP n'est pas bloquée. En effet, CrowdSec doit s'appuyer sur un Bouncer pour appliquer la décision et bannir l'adresse IP.

sudo cscli decisions list

On peut voir aussi que mon analyse avec Nikto a généré plusieurs alertes, ce qui donne des indications sur les types d'attaques détectés (reason).

cscli alerts list

B. Installation de PHP Composer

Pour déployer le Bouncer PHP sur son serveur, il faut installer Composer sinon il ne s'installera pas correctement. Pour l'installer, nous avons besoin de deux paquets : php-cli et unzip, que l'on va installer sans plus attendre :

sudo apt-get update
sudo apt-get install php-cli unzip

Ensuite, il faut se positionner dans son répertoire racine et récupérer l'installeur avec Curl :

cd ~
curl -sS https://getcomposer.org/installer -o composer-setup.php

Une fois qu'il est récupéré, il faut vérifier que le hash SHA-384 correspond bien à l'installeur que l'on vient de télécharger. Cela permet de s'assurer de l'intégrité du fichier. On stocke le hash dans une variable nommée "HASH" :

HASH=`curl -sS https://composer.github.io/installer.sig`

Puis, on lance la commande fournie sur le site officiel de Composer qui va permettre de vérifier le hash avant que l'installation soit lancée :

php -r "if (hash_file('SHA384', 'composer-setup.php') === '$HASH') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"

Vous devez obtenir le message "Installer verified". Sinon, cela signifie que votre installeur est corrompu, vous devez relancer le téléchargement.

Enfin, lancez l'installation de Composer :

sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer

Pour vérifier que l'installation est opérationnelle, exécutez simplement :

composer

Vous devez obtenir ceci :

Composer est correctement installé, vous pouvez passer à l'installation du Bouncer en lui-même.

C. Mise en place du Bouncer PHP

Souvenez-vous du premier tutoriel sur CrowdSec où j'utilisais un serveur NginX. J'avais utilisé le Bouncer NginX directement pour bloquer les adresses IP que CrowdSec souhaitait bannir. Cette fois-ci, comme nous n'utilisons pas NginX mais Apache, on va se tourner vers un autre Bouncer : PHP.

Note : le Bouncer PHP développé par CrowdSec prend en charge de nombreuses versions (PHP 7.2.x, 7.3.x, 7.4.x et 8.0.x).

Nous avons besoin de Git pour installer ce Bouncer afin de cloner le projet. Pour installer Git :

sudo apt-get install git

Ensuite, on récupère le projet en le clonant en local :

git clone https://github.com/crowdsecurity/cs-php-bouncer.git

On obtient un dossier nommé "cs-php-bouncer" dans lequel on va se positionner :

cd cs-php-bouncer/

Puis, on lance le script d'installation (il ne doit pas être lancé avec le compte "root", ni "sudo" !) en spécifiant que l'on utilise le serveur Web "Apache" :

./install.sh --apache
Installation du Bouncer PHP sur CrowdSec
Installation du Bouncer PHP sur CrowdSec

Enfin, on suit les instructions qui s'affichent à l'écran pour finaliser l'installation. On définit comme propriétaire sur le dossier "/usr/local/php/crowdsec/" l'utilisateur associé à Apache. Par défaut, il s'agit de l'utilisateur "www-data".

sudo chown www-data /usr/local/php/crowdsec/

Puis, on termine en rechargeant la configuration d'Apache :

sudo systemctl reload apache2

Si on liste les Bouncer installés sur notre serveur, on va voir qu'il apparaît dans la liste :

sudo cscli bouncers list

D. Deuxième scan avec Nikto : le bouncer PHP va-t-il se montrer intraitable ?

Cette fois-ci, on devrait être en mesure de détecter l'attaque, de décider de bannir l'adresse IP de l'hôte "Nikto" et surtout d'appliquer la décision grâce au Bouncer PHP. C'est ce que nous allons vérifier.

On peut commencer par utiliser Curl pour vérifier que l'on obtient bien un code de retour HTTP 200.

curl -I it-connect.tech

Puis, on lance notre scan Nikto :

nikto -h it-connect.tech

Cette fois-ci, le scan mouline un peu... Comme s'il était bloqué par quelque chose. Si on force son arrêt (CTRL+C) et que l'on relance la commande Curl, on peut voir que le code de retour HTTP a changé : HTTP/1.0 403 Forbidden. Ce qui correspond à un accès refusé sur la page, y compris si l'on essaie d'accéder au serveur avec l'adresse IP au lieu du nom.

Si j'essaie d'accéder au site avec un navigateur, on peut voir qu'un message s'affiche pour indiquer que mon adresse IP a été bloquée par CrowdSec ! Le Bouncer PHP est entré en action !

Je vous rappelle que l'on peut débannir manuellement une adresse IP avec la commande suivante (nous allons utiliser cette commande dans la suite du tutoriel) :

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

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

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

V. Bouncer PHP : mise en place d'un captcha

Avec la configuration actuelle, l'adresse IP sera bloquée pour une durée de 4 heures et l'utilisateur n'a pas de possibilité d'être débloqué pendant ce temps. À moins de prendre la peine de contacter le Webmaster du site...

Pour limiter l'impact des éventuels faux positifs sur la règle "bad user agents", nous allons présenter un captcha à l'utilisateur bloqué, plutôt qu'un blocage pur. De cette façon, un robot sera bloqué tandis qu'un utilisateur réel pourra  déverrouiller l'accès au site. Nous allons réserver le même sort au crawlers malveillants (robots d'exploration).

Pour cela, il faut éditer le fichier de configuration nommé "profiles.yaml", qui est au format YAML, comme son nom l'indique.

sudo nano /etc/crowdsec/profiles.yaml

Ce fichier contient une configuration par défaut qui sert à bloquer les adresses IP pendant 4 heures, peu importe le type d'attaque détectée. Nous souhaitons conserver ce comportement, à l'exception de deux types d'alertes :

  • http-crawl-non_statics
  • http-bad-user-agent

Il faut que l'on ajoute notre configuration au début du fichier, et non pas à la fin. À ce jour, CrowdSec gère la priorité par rapport à l'ordre dans le fichier puisque dès que l'on match sur une règle, on ne vérifie pas la suite (un peu sur le même principe que les ACL sur un routeur, finalement) compte tenu de la présence de la directive "on_success: break" (voir ci-dessous).

Autrement dit, si l'on ajoute notre configuration spécifique à la suite dans le fichier profiles.yaml, cela ne fonctionnera pas, car la première règle correspondra (matchera) toujours, et donc notre règle ne sera pas prise en compte.

Voici le bout de code à ajouter au tout début du fichier :

# Bad User agents + Crawlers - Captcha 4H
name: crawler_captcha_remediation
filters:
- Alert.Remediation == true && Alert.GetScenario() in ["crowdsecurity/http-crawl-non_statics", "crowdsecurity/http-bad-user-agent"]
decisions:
- type: captcha
duration: 4h
on_success: break
---

La partie "filters" sert à spécifier que l'on cible seulement les scénarios d'alertes "http-crawl-non_statics" et "http-bad-user-agent". Ensuite, au niveau du "type", on spécifie "captcha" au lieu de "ban" qui est l'action standard.

Enfin, la partie "duration" sert à spécifier la durée pendant laquelle on présente un captcha à l'adresse IP associée au "blocage". En l'occurrence, 4h par défaut, mais vous pouvez modifier cette valeur.

Au final, vous obtenez ceci :

Sauvegardez le fichier et fermez-le. Il ne reste plus qu'à relancer CrowdSec :

sudo systemctl restart crowdsec

Avant de refaire des tests, on va supprimer la décision qui s'applique actuellement sur notre adresse IP, c'est-à-dire "ban". On utilise la commande ci-dessous en remplaçant "X.X.X.X" par l'IP publique correspondante.

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

Ensuite, il faut que l'on simule un accès depuis un user-agent non autorisé, car si j'utilise Firefox, Chrome, Brave, Edge, etc... cela ne fonctionnera pas, car ce sont des user-agent légitimes. Pour cela, on peut se référer à la liste de user-agents malveillants relayée par CrowdSec sur GitHub. Pour l'outil à utiliser, on partira sur l'excellent Curl que l'on a déjà utilisé précédemment.

Nous allons utiliser le modèle de commande suivant :

curl -I it-connect.tech -H "User-Agent: <nom-user-agent>"

Voici quelques exemples :

curl -I it-connect.tech -H "User-Agent: Cocolyzebot"
curl -I it-connect.tech -H "User-Agent: Mozlila"
curl -I it-connect.tech -H "User-Agent: OpenVAS"
curl -I it-connect.tech -H "User-Agent: Nikto"

En effectuant deux-trois requêtes Curl à destination de notre site, on se retrouve rapidement avec un code d'erreur HTTP : 401 Unauthorized. Comprenez accès non autorisé.

Maintenant que je suis bloqué par CrowdSec, on va utiliser un navigateur classique pour voir comment réagit le serveur Web.

Aaaaah ! Bonne nouvelle ! Une page avec un captcha s'affiche ! Pour outrepasser le blocage, il suffit de compléter le captcha, de cliquer sur "Continue", afin d'accéder au site.

CrowdSec - Page de blocage avec captcha
CrowdSec - Page de blocage avec captcha

Si on liste les décisions actives, on peut voir que mon adresse IP est bien associée à l'action "captcha" au lieu de l'action "ban". On peut voir aussi que mon instance CrowdSec a banni quelqu'un d'autre, qui visiblement, s'en prend à mon serveur Web.

sudo cscli decisions list

Si l'on effectue un scan avec Nikto comme nous l'avons fait à plusieurs reprises dans cette démonstration, nous n'aurons pas le captcha, nous allons être directement bannis. En fait, il y a bien un user-agent Nikto, mais le scan avec cet outil va générer d'autres alertes avant celle sur le user-agent, ce qui implique que c'est l'action "bannir" qui va s'appliquer avant l'action "captcha". En soi, ce n'est pas plus mal, car quelqu'un qui scanne notre serveur Web, on préfère autant qu'il soit complètement bloqué.

VI. Conclusion

Voilà, nous venons de voir comment sécuriser une application ou un site Internet qui tourne sur un serveur Web Apache + PHP en détectant et bloquant les attaques avec CrowdSec. On peut voir que CrowdSec est un outil efficace et personnalisable grâce à la mise en place du captcha.

Je vous rappelle que vous pouvez démarrer un container Metabase pour accéder à un dashboard afin de visualiser de beaux graphiques et avoir des métriques précises quant à l'activité de CrowdSec sur votre serveur (voir mon précédent tutoriel).

Pour finir, quelques liens :

The post Bloquer les attaques sur son serveur Web (Apache + PHP) avec CrowdSec first appeared on IT-Connect.

Installer un serveur LAMP (Linux Apache MariaDB PHP) sous Debian 11

18 octobre 2021 à 09:00

I. Présentation

Dans ce tutoriel, nous allons voir comment mettre en place un serveur Web "LAMP" sous Debian 11, afin de pouvoir héberger un site Internet (WordPress, Joomla, Drupal, etc...) ou une application (NextCloud, etc.).

Au fait, c'est quoi un serveur LAMP ? Il s'agit d'un serveur qui s'appuie sur 4 composants : L pour Linux, c'est-à-dire le système d'exploitation (Debian, dans notre cas), A pour Apache, c'est-à-dire le serveur Web, M pour MySQL/MariaDB, c'est-à-dire le système de gestion de bases de données, et P pour PHP, c'est-à-dire le moteur de scripts.

Pour suivre ce tutoriel, vous avez besoin d'une machine sous Debian, ou une distribution basée sur Debian.

II. Serveur LAMP sous Debian 11

A. Installer Apache sous Debian 11

On commence par mettre à jour le cache des paquets :

sudo apt-get update

Ensuite, on installe le paquet "apache2" afin d'obtenir la dernière version d'Apache 2.4.

sudo apt-get install -y apache2

Pour qu'Apache démarre automatiquement en même temps que Debian, saisissez la commande ci-dessous (même si normalement c'est déjà le cas) :

systemctl enable apache2
Synchronizing state of apache2.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable apache2

Suite à l'installation du paquet, le serveur Apache démarre directement. On devrait pouvoir accéder à sa page par défaut. Pour cela, il suffit de récupérer l'adresse IP du serveur :

ip address

Puis, à l'aide d'une machine équipée d'un navigateur, on peut accéder à notre serveur Apache :

http://192.168.100.120
Apache en ligne, sous Debian 11
Apache en ligne, sous Debian 11

Pour visualiser la version d'Apache que vous venez d'installer, c'est tout simple : exécutez la commande suivant :

apache2ctl -v
Server version: Apache/2.4.51 (Debian)
Server built: 2021-10-07T17:49:44

Apache 2.4.51 est la dernière version d'Apache au moment où j'écris cet article.

Avant d'aller plus loin, je vous recommande d'activer quelques modules d'Apache qui sont indispensables, notamment pour faire tourner un site Internet. Commençons par le module utilisé pour la réécriture d'URL :

a2enmod rewrite

L'occasion de découvrir la commande "a2enmod" qui sert à activer un module. A l'inverse, la commande "a2dismod" sert à désactiver un module.

Activons trois :autres modules :

  • "deflate" pour la gestion de la compression, notamment en gzip, pour utiliser la mise en cache des pages sur votre site
  • "headers" afin de pouvoir agir sur les en-têtes HTTP
  • "ssl" pour gérer les certificats SSL et donc l'utilisation du protocole HTTPS
a2enmod deflate
a2enmod headers
a2enmod ssl

Après avoir activé ou désactivé un module, ou modifié la configuration d'Apache, il faut redémarrer le service apache2 :

systemctl restart apache2

Où se situent la configuration d'Apache et des sites dans tout ça ?

Le fichier de configuration d'Apache 2 est le suivant :

/etc/apache2/apache2.conf

Dans un premier temps, il peut servir à configurer Apache pour ne pas afficher le numéro de version sur les pages d'erreurs. Même si cette option est gérable aussi dans le fichier "/etc/apache2/conf-enabled/security.conf", c'est au choix.

Note : pour la configuration qui concerne PHP, le fichier de configuration est différent : "/etc/php/7.4/apache2/php.ini"

Tandis que pour déclarer les hôtes virtuels, en anglais "Virtual hosts", ce qui correspond aux différents sites hébergés par Apache (oui, un serveur Apache peut gérer plusieurs sites indépendamment), il faudra s'intéresser à ces deux dossiers :

  • Dossier qui contient les fichiers de configuration des sites disponibles : /etc/apache2/sites-available/
  • Dossier qui contient les fichiers de configuration (via un lien symbolique), des sites actifs : /etc/apache2/sites-enabled

Par défaut, nous accédons à la page d'accueil d'Apache grâce à l'hôte virtuel déclaré dans le fichier "/etc/apache2/sites-enabled/000-default.conf", qui écoute sur le port 80 (HTTP) et dont la racine est le dossier "/var/www/html".

Je vous invite à lire mon tutoriel dédié à la configuration d'un Virtual Host pour en savoir plus :

Enfin, si vous souhaitez mettre en place l'authentification basique sur votre site, vous avez besoin de l'outil "htpasswd" inclus dans le paquet "apache2-utils" (comme d'autres outils). Vous pouvez l'installer à tout moment d'une simple commande :

sudo apt-get install -y apache2-utils

B. Installer PHP sous Debian 11

PHP va venir se greffer sur notre serveur Apache, comme une extension, afin de pouvoir traiter les scripts intégrés aux pages ".php". Afin d'y aller progressivement, installons le paquet "php" en lui-même :

sudo apt-get install -y php

On peut voir que cette commande va installer une multitude de paquets :

libapache2-mod-php7.4 libsodium23 php-common php7.4 php7.4-cli php7.4-common php7.4-json php7.4-opcache php7.4-readline

C'est très bien, nous avons quelques modules de base indispensables et "libapache2-mod-php7.4" qui permet l'intégration avec Apache.

Actuellement, c'est PHP 7.4 qui est dans les dépôts de Debian, même si PHP 8 est déjà disponible, toutes les applications ne sont pas encore compatibles. Il faut savoir que le support de PHP 7.4 assure les mises à jour de sécurité jusqu'au 28 novembre 2022. Ce qui laisse un peu de temps, mais il faut garder en tête qu'il faudra envisager de passer sur PHP 8.

Avant d'aller plus loin, nous allons installer quelques paquets supplémentaires pour compléter l'installation de PHP sur notre serveur. Par exemple, pour permettre les interactions entre PHP et notre instance MariaDB.

sudo apt-get install -y php-pdo php-mysql php-zip php-gd php-mbstring php-curl php-xml php-pear php-bcmath

Suite à cette installation, je vous invite à vérifier quelle version de PHP vous venez d'installer. Exécutez la commande suivante :

php -v
PHP 7.4.21 (cli) (built: Jul 2 2021 03:59:48) ( NTS )

Maintenant, pour nous assurer que notre moteur de script PHP est bien actif, nous allons créer un fichier "phpinfo.php" (ou un autre nom) à la racine de notre site Web :

sudo nano /var/www/html/phpinfo.php

Dans ce fichier, indiquez le code suivant :

<?php
phpinfo();
?>

Elle sera accessible à partir de cette adresse :

http://192.168.100.120/phpinfo.php

Cette page donne énormément d'informations sur toute la configuration de PHP et de notre serveur Apache. Il est fortement recommandé de la mettre en place seulement quand c'est nécessaire. Autrement dit, vous ne devez pas laisser cette page accessible par n'importe qui.

C. Installer MySQL/MariaDB sous Debian 11

MariaDB est un fork communautaire de MySQL et il présente l'avantage d'être open source et sous licence GPL, à la différence de MySQL qui est un logiciel propriétaire de chez Oracle, mais qui reste gratuit malgré tout. Il y a un excellent suivi pour MariaDB et c'est réellement un système très performant, vous pouvez miser sur ce composant sans aucun problème !

Pour installer MariaDB sous Debian 11, voici la commande à exécuter :

sudo apt-get install -y mariadb-server

Suite à l'installation, je vous invite à exécuter le script "mariadb-secure-installation" afin de sécuriser un minimum votre installation de MariaDB.

sudo mariadb-secure-installation

En résumé, vous allez pouvoir définir un mot de passe pour le compte "root" de MariaDB, empêcher les connexions distantes sur votre instance à l'aide du compte "root", empêcher les connexions anonymes et supprimer la base de test.

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
haven't set the root password yet, you should just press enter here.

Enter current password for root (enter for none):
OK, successfully used password, moving on...

Setting the root password or using the unix_socket ensures that nobody
can log into the MariaDB root user without the proper authorisation.

You already have your root account protected, so you can safely answer 'n'.

Switch to unix_socket authentication [Y/n] n
... skipping.

You already have your root account protected, so you can safely answer 'n'.

Change the root password? [Y/n] Y
New password: **************
Re-enter new password: **************
Password updated successfully!
Reloading privilege tables..
... Success!


By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y
... Success!

Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y
... Success!

By default, MariaDB comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] y
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] y
... Success!

Cleaning up...

All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.

Voilà, l'interrogatoire est terminé.

Pour obtenir le numéro de version de MariaDB, on peut utiliser cette commande :

mariadb -V
mariadb Ver 15.1 Distrib 10.5.12-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper

Ou celle-ci en consultant le gestionnaire de paquets Aptitude (apt) :

apt policy mariadb-server
   mariadb-server:
   Installé : 1:10.5.12-0+deb11u1
   Candidat : 1:10.5.12-0+deb11u1
   Table de version :
   *** 1:10.5.12-0+deb11u1 500
   500 http://ftp.fr.debian.org/debian bullseye/main amd64 Packages
   100 /var/lib/dpkg/status

Il est à noter que même si l'on a installé MariaDB, on peut utiliser la commande "mysql", notamment pour afficher le numéro de version avec "mysql -V" ou ouvrir une console MySQL/MariaDB.

Avant de passer à la suite, vérifiez que vous parvenez à vous connecter à votre instance MariaDB :

sudo mariadb -u root -p

Saisissez le mot de passe "root". Ensuite, vous avez accès à la console MariaDB / MySQL. Vous pouvez saisir vos requêtes SQL ici. Par exemple, pour lister les bases de données de votre instance :

show databases;
Première connexion à MariaDB en ligne de commande
Première connexion à MariaDB en ligne de commande

Pour sortir de la console, saisissez la commande suivante :

exit

Il faudra revenir dans cette console lorsque vous allez déployer votre application sur votre serveur LAMP, par exemple WordPress, NextCloud, etc.... Afin de créer une base de données dédiée et un utilisateur dédié à cette application. Une alternative consiste à déployer PhpMyAdmin sur son serveur dans le but d'administrer MariaDB à partir d'une interface Web.

Après un changement de configuration de MariaDB, vous devez redémarrer le service :

systemctl restart mariadb

III. Conclusion

Voilà, votre serveur LAMP est installé ! Pour la suite de la configuration, cela dépend de l'application que vous souhaitez déployer, ou peut-être même qu'il s'agit d'un projet que vous avez vous-même développé.

Généralement, on commence par créer un nouvel hôte virtuel sur Apache pour accueillir les sources d'installation de l'application. Ensuite, on crée une base de données dédiée à cette application, avec son propre utilisateur (qui aura les droits seulement sur cette base), et on lance l'installation.

Si vous désirez installer WordPress sur votre serveur, vous pouvez suivre ce tutoriel (Installation de WordPress pas à pas) et cette vidéo :

The post Installer un serveur LAMP (Linux Apache MariaDB PHP) sous Debian 11 first appeared on IT-Connect.

Comment installer WordPress facilement sur un serveur Apache ?

15 octobre 2021 à 16:00

I. Présentation

Dans ce tutoriel, nous allons voir comment installer WordPress facilement sur son serveur Web LAMP : Linux, Apache, MariaDB (MySQL) et PHP. Ce guide vous aidera étape par étape pour installer WordPress correctement.

Tutoriel pas à pas au format vidéo, en partant de zéro :

WordPress est un CMS (Content Management System) créé en 2003 qui va permettre de mettre en ligne un site Internet sans partir de zéro puisqu'il permet de créer, de modifier et d'administrer facilement un site web.

Aujourd'hui, c'est WordPress est le CMS le plus populaire et il permet de mettre en place de nombreux types de sites : sites vitrine, blog, sites d'e-commerce, etc...Grâce à son énorme communauté et les nombreux développeurs qui proposent des plug-ins (gratuits ou payants) afin de permettre la personnalisation de son site Web.

Nativement, WordPress va permettre de créer des utilisateurs, des pages et des articles. Il va permettre aussi de gérer la configuration globale du site (nom, adresse, format des liens, etc...). Cette base solide doit être complétée par des plug-ins (appelés aussi extensions) qui vont permettre d'ajouter des fonctionnalités à votre site WordPress, mais aussi d'avoir un thème graphique correspondant à vos attentes.

II. Prérequis pour installer WordPress

Certains hébergeurs proposent une installation clé en main, il suffit de cliquer sur un bouton et WordPress se déploie tout seul. Par contre, si vous gérez vous-même votre serveur, par exemple sur un serveur VPS ou un serveur dédié, c'est vous qui allez devoir réaliser l'installation.

Quant aux ressources que doit avoir votre machine, c'est-à-dire l'espace de stockage, le CPU et la RAM, j'ai envie de dire "ça dépend". En effet, au début ce sera surement très peu, mais si votre site grossit et qu'il y a de nombreux visiteurs, vous allez avoir besoin d'adapter les ressources en conséquence.

Pour suivre ce tutoriel, vous avez besoin d'une machine sous Linux, avec un accès "root" sur cette machine (ou un niveau de droits suffisants pour réaliser les manipulations qui vont suivre).

A. L'archive d'installation de WordPress

Connectez-vous sur votre serveur Linux en SSH afin de télécharger l'archive ZIP qui contient les sources de WordPress.

Positionnez-vous dans le dossier "/tmp" et téléchargez la dernière version de WordPress :

cd /tmp
wget https://wordpress.org/latest.zip

Voilà, laissez le téléchargement s'effectuer... Nous allons utiliser cette archive dans une prochaine étape.

B. Le serveur Web

Dans cet exemple, je vais partir sur un socle LAMP sous Debian 11 pour effectuer l'installation. Cela correspond à un serveur Web basé sur Linux (Debian 11) sur lequel on va retrouver Apache, MariaDB ou MySQL et PHP.

Pour Apache, installez la dernière version disponible dans les dépôts de votre distribution et vérifiez que vous êtes en mesure d'activer certains modules ("deflate" pour la compression GZip, "rewrite" pour la réécriture d'URL et "ssl" pour le support du HTTPS).

Au sujet de PHP, pour le moment je vous recommande de commencer par PHP 7.4 dans un premier temps et de basculer sur PHP 8 dans un second temps. Le support pour les mises à jour de sécurité de PHP 7.4 expire en novembre 2022.

Pour le système de gestion de bases de données, MariaDB (open source fork de MySQL) ou MySQL (gratuit, mais propriétaire Oracle), installez la dernière version disponible.

Si vous avez besoin d'aide pour mettre en place le serveur Web, c'est-à-dire installer les différents paquets, suivez le premier lien ci-dessous. Ce sera mon point de départ.

III. Créer une base de données pour WordPress

WordPress s'appuie sur une base de données afin de stocker toutes les informations liées à la configuration et à vos contenus (catégorie, pages, articles, etc.). Sur notre serveur Web, nous allons lui créer une base de données dédiée avec un utilisateur dédié, et ce dernier aura les droits uniquement sur la BDD WordPress.

Que ce soit avec MariaDB ou MySQL, vous pouvez vous connecter à la console de votre instance avec la commande suivante :

mysql –u root –p

Saisissez le mot de passe "root" de votre instance : une console va s'ouvrir, prête à recevoir des commandes SQL.

Première étape : la création de la base de données. Ne donnez pas un nom trop évident, mais parlant malgré tout, par exemple cela peut être : wp202110_itconnect. Ce nom reste parlant pour vous : on sait qu'il s'agit de la base de données WordPress (wp), créée en octobre 2021 pour le site "itconnect".

CREATE DATABASE wp202110_itconnect;
# Retour dans la console : 
Query OK, 1 row affected (0.001 sec)

Vous pouvez lister les bases de données de votre instance avec la commande suivante :

SHOW DATABASES;

On peut voir que notre base de données apparaît bien dans la liste :

Deuxième étape : créer l'utilisateur qui sera administrateur de la base de données WordPress. Cet utilisateur sera nommé "adminwp202110_itconnect" et il aura comme mot de passe "Votre-Super-Mot-De-Passe".

Ce qui donne la requête SQL suivante :

CREATE USER 'adminwp202110_itconnect'@'localhost' IDENTIFIED BY 'Votre-Super-Mot-De-Passe';

Troisième étape : donner tous les droits à l'utilisateur "adminwp202110_itconnect" sur la base de données WordPress. Notre serveur Web et la base de données étant sur le même serveur, nous allons donner ces droits pour une connexion locale. Ce qui donne :

GRANT ALL PRIVILEGES ON wp202110_itconnect.* TO adminwp202110_itconnect@localhost;

Enfin, il faut exécuter la commande suivante pour actualiser les droits et activer les nouveaux privilèges sur notre base de données :

FLUSH PRIVILEGES;

La base de données pour WordPress est prête. Pour le moment elle est vide, mais WordPress va créer sa structure de tables lors de l'installation. Quittez la console MariaDB / MySQL :

exit

Passons à l'étape suivante.

IV. Décompresser l'archive WordPress à la racine du site

Nous allons utiliser le site par défaut d'Apache, qui a pour racine "/var/www/html" afin de stocker les données de notre site WordPress. Au préalable, on supprime la page d'index créée par défaut par Apache :

sudo rm /var/www/html/index.html

Ensuite, on installe le paquet « zip » sur notre serveur pour pouvoir décompresser l’archive de WordPress :

sudo apt-get update 
sudo apt-get install zip

On décompresser l'archive dans "/var/www/html" grâce à la commande suivante (en étant positionné dans le dossier où l'on a téléchargé le fichier latest.zip) :

sudo unzip latest.zip -d /var/www/html

L'option "-d" permet de définir là où sera décompressée l'archive. Le dossier WordPress apparaitra donc dans "/var/www/html" qui est le dossier où sont stockées les pages web par défaut.

Le problème, c'est que là on vient de décompresser le contenu de l'archive ZIP dans un dossier nommé "wordpress", ce qui donne : /var/www/html/wordpress. Du coup, pour accéder à notre site, il faudra faire : http://domaine.fr/wordpress/. Ce n'est pas top, nous allons corriger cela dès maintenant.

Déplacez-vous dans le dossier "/var/www/html" :

cd /var/www/html

Ensuite, exécutez la commande ci-dessous pour déplacer tout le contenu du dossier "wordpress" à la racine de notre site :

sudo mv wordpress/* /var/www/html/

Puisque le dossier "wordpress" ne sert plus à rien, on va le supprimer :

sudo rm wordpress/ -Rf

Enfin, on termine en donnant les droits à l'utilisateur "www-data" (correspondant à Apache) sur tous les fichiers de notre site, de manière récursive :

sudo chown -R www-data:www-data /var/www/html/

On obtient une belle liste de fichiers et dossiers. Au niveau des droits et pour des raisons de sécurité, vous devez avoir 755 sur les dossiers et 644 sur les fichiers. Ce qui est le cas par défaut si vous n'avez pas fait de modifications. En aucun cas vous ne devez poser des droits "777" sur un dossier ou un fichier.

Aperçu des droits WordPress
Aperçu des droits WordPress

Si vous avez un doute ou que vous pensez avoir modifié les droits, vous pouvez rectifier la situation.

Pour les fichiers, exécutez cette commande :

sudo find /var/www/html/ -type f -exec chmod 644 {} \;

Pour les dossiers, exécutez cette commande :

sudo find /var/www/html/ -type d -exec chmod 755 {} \;

Passez à la suite : ce sera à partir d'un navigateur.

V. Installation de WordPress

Pour la première fois, nous allons nous connecter sur l'interface web WordPress dans le but d'effectuer l'installation. Pour cela, il faut se rendre sur "http://IP-SERVEUR" avec votre navigateur préféré. Si vous avez déjà enregistré le nom de domaine et que l'enregistrement A du DNS pointe vers votre serveur, vous devriez pouvoir accéder au site grâce au nom de domaine du serveur.

Note : vous pouvez aussi tricher avec le fichier hosts de votre machine cliente (Linux : /etc/hosts - Windows : C:\Windows\System32\drivers\etc\hosts) afin d'associer l'adresse IP de votre serveur à un nom de domaine en créant un enregistrement local.

La première étape consiste à choisir la langue du site et de l'interface de WordPress. Ça devrait aller. 🙂

Ensuite, cliquez sur le bouton "C'est parti !". WordPress va générer lui-même le fichier "wp-config.php" : il s'agit d'un fichier de configuration très sensible qui contient des informations confidentielles comme le nom de la base de données, le nom de l'utilisateur pour s'y connecter et le mot de passe associé. Indispensable pour que PHP (et donc WordPress) puisse utiliser votre base de données.

Voilà l'étape la plus délicate de l'installation via l'assistant. Vous devez renseigner les différents champs pour indiquer à WordPress comment se connecter à votre base de données.

  • Nom de la base de données : dans cet exemple, ce sera "wp202110_itconnect"
  • Identifiant : le nom de l'utilisateur qui a les droits sur la base de données, en l'occurrence "adminwp202110_itconnect"
  • Mot de passe : le mot de passe de cet utilisateur
  • Adresse de la base de données : si le serveur Web et la base de données sont sur le même serveur, indiquez "localhost", sinon indiquez l'adresse IP du serveur distant
  • Préfixe des tables : chaque table de la base de données WordPress aura un préfixe. Par défaut, ce préfixe est "wp" donc par exemple la table des utilisateurs sera nommée "wp_users". Il faut personnaliser ce préfixe et le rendre un peu plus aléatoire pour des raisons de sécurité. Pour ma part, je vais partir sur "web14_", mais vous pouvez prendre aussi quelque chose d'aléatoire comme "sg389_".

Quand vous êtes prêt, cliquez sur "Envoyer". Ce qui donne au final :

Indiquez à WordPress comment il doit se connecter à votre base de données.
Indiquez à WordPress comment il doit se connecter à votre base de données.

WordPress va tester de se connecter à votre base de données et si cela fonctionne, un bouton "Lancer l'installation" va s'afficher. Cliquez dessus.

Installer WordPress sous Linux : c'est le grand moment !
Installer WordPress sous Linux : c'est le grand moment !

Il ne reste que quelques champs à renseigner comme le titre du site (modifiable ultérieurement) et la création d'un premier compte utilisateur. Je dirais même d'un compte administrateur, car ce compte sera admin du site. Évitez les identifiants trop évidents comme "admin", "administrateur", "webadmin", "adminwordpress", etc... Prenez quelque chose de plus original et personnel !

Choisissez un mot de passe complexe pour cet utilisateur, indiquez l'adresse e-mail associée et cliquez sur "Installer WordPress". Si vous désirez monter votre site tranquillement sans qu'il soit indexer par Google et consort, cochez la case associée à l'option "Visibilité par les moteurs de recherche".

WordPress est installé ! Cliquez sur le bouton "Se connecter". Sur la page de connexion qui apparaît, authentifiez-vous avec le compte admin que vous venez de créer, pour ma part "adm_florian".

Avant d'aller plus loin, prenez 30 secondes pour retourner sur votre console Linux et réaliser deux petites opérations. Tout d'abord pour supprimer le fichier "wp-config-sample.php", car il n'a plus d'intérêt (nous avons notre fichier wp-config.php définitif).

sudo rm /var/www/html/wp-config-sample.php

Ensuite, pour appliquer des droits très restrictifs sur le fichier "wp-config.php" pour le basculer en lecture seule seulement pour Apache. Indispensable pour des raisons de sécurité.

sudo chmod 400 /var/www/html/wp-config.php

Suite à la connexion, vous arrivez sur l'interface d'administration de WordPress. C'est votre centre de contrôle pour créer vos pages, vos articles, mais aussi ajouter des extensions, des thèmes et configurer WordPress dans son ensemble.

Cette interface d'administration est accessible à l'adresse suivante : http://<adresse-ip-ou-domaine>/wp-admin/.

L'interface d'administration de WordPress
L'interface d'administration de WordPress

En haut de l'interface, on peut qu'il y a une notification avec un "1". Cette icône correspond aux mises à jour et signifie qu'il y a une mise à jour disponible. Il peut s'agir d'une mise à jour de WordPress, d'une extension, d'un thème ou d'une traduction.

Par défaut, WordPress est livré avec deux extensions :

  • Akismet Anti-Spam qui est une extension performante pour lutter contre les spams dans les commentaires (je vous la recommande si vous envisagez de laisser la possibilité de publier des commentaires sur votre site)
  • Hello Dolly qui ne sert pas à grand-chose puisqu'elle sert seulement à afficher les paroles de la chanson "Hello, Dolly" de Louis Armstrong. Ne me demandez pas pourquoi, mais elle est là.

Ces deux extensions sont désactivées par défaut. En fait, une extension peut être présente sur votre installation de WordPress, c'est-à-dire qu'elle est téléchargée, mais non activée. De toute façon, lorsqu'une nouvelle extension est ajoutée sur WordPress, il faut toujours l'activer manuellement.

Le suivi des mises à jour est indispensable
Le suivi des mises à jour est indispensable

Sur le site en lui-même, c'est-à-dire la partie publique, cela donne :

WordPress est installé et il ne demande plus qu'une chose : être configuré et personnalisé.

Je vous recommande fortement de maintenir dans le temps votre site WordPress et de bien suivre les mises à jour. C'est un outil très populaire et donc, de fait, très ciblé par les hackers. Lorsque vous choisissez d'installer une extension, veillez à ce que ce soit une extension suivie (regardez la fréquence des mises à jour et la date de la dernière mise à jour) et bien notée.

Il y a également de bonnes extensions à mettre en place pour sécuriser son site WordPress contre les attaques courantes en ajoutant une fonction de pare-feu à WordPress. Pensez également à mettre en place une solution pour sauvegarder votre site (base de données + fichiers).

Si vous avez des questions sur l'installation ou sur WordPress, n'hésitez pas à laisser un commentaire sur ce tutoriel. De même si vous aimeriez un tutoriel sur une fonctionnalité particulière.

The post Comment installer WordPress facilement sur un serveur Apache ? first appeared on IT-Connect.

Automatiser le processus de mise à jour Apt sur Debian

15 octobre 2021 à 10:00

I. Présentation

Dans ce tutoriel, nous allons voir comment automatiser le processus de mise à jour d'une machine Linux sous Debian ou Ubuntu. En effet, à partir d'un certain nombre d'instances de VM (ou de machines physiques), il est assez fastidieux de taper ne serait-ce qu'une fois par mois : "apt update && apt upgrade" sur toutes vos machines. L'objectif de cet article est de se la jouer fainéant, mais surtout futé en automatisant le processus.

"Je choisis une personne paresseuse pour un travail difficile, car une personne paresseuse va trouver un moyen facile de le faire." - Bill Gates 

II. Automatiser le processus de mise à jour avec un script bash

Nous allons créer un petit script bash pour réaliser notre automatisation. Afin de garder une trace de chaque exécution, je vais rediriger le contenu de stderr (en cas de retour d'une erreur lors de l'exécution du script) et stdout (en cas de succès).

Plus d'informations concernant la redirection des flux standard sous Linux.

Suivez les étapes ci-dessous, les commentaires sont là pour vous guider.

# Création du fichier
touch /home/user/script.sh 

# Edition du script
nano /home/user/script.sh
# Contenu du script "script.sh"
#!/bin/bash
echo ">>------------------------------------------------$(date)---------------------------------------------<<" >> /var/log/update_upgrade.log
echo ">>------------------errors------------------------------$(date)---------------errors------------------------------<<" >> /var/log/update_upgrade.err
export DEBIAN_FRONTEND=noninteractive
apt-get update && apt-get upgrade -y >> /var/log/update_upgrade.log 2>> /var/log/update_upgrade.err

# On donne les droits d'exécution sur le script
chmod u+x /home/user/script.sh 

# On édite la crontab 
crontab -e 

# Adaptez l'heure de la cron en fonction de l'heure à laquelle vous souhaitez faire votre test. 
06 17 * * * /home/user/script.sh

# Affichez les logs 
cat /var/log/update_upgrade.*

Je vais détailler quelques éléments du script ci-dessous :

- "DEBIAN_FRONTEND=noninteractive" : Nous allons activer ce mode par le biais de l'instanciation d'une variable DEBIAN_FRONTEND.  Utilisez ce mode lorsque vous n'avez besoin d'aucune interaction lors de l'installation ou de la mise à niveau du système via apt. Il accepte la réponse par défaut pour toutes les questions. Il peut envoyer un message d'erreur à l'utilisateur root, mais c'est tout. Une interface parfaite pour les installations automatiques. On peut utiliser ce mode dans des fichiers Dockerfile, des scripts shell, etc.

- ">> /var/log/update_upgrade.log" : Redirige la sortie standard du couple de commandes vers le fichier update_upgrade.log, afin d'avoir une trace de ce qu'il s'est passé.

- "2>> /var/log/update_upgrade.err" : Redirige la ou les erreurs en cas d'échec du couple de commandes vers le fichier update_upgrade.err. Normalement, ce fichier devrait toujours être vide. Le cas contraire indiquerait que vous avez un problème lors de l'exécution des deux commandes (il faudrait le cas échéant, déprogrammer la tâche cron, puis investiguer manuellement). Cas concret : si vous avez une coupure internet pile au moment du lancement du processus, apt vous renverra une erreur.

Il est à noter que les upgrades de tous les paquets se feront automatiquement sur Debian/Ubuntu, sauf les upgrades du noyau Linux, qui sont exclus par défaut, lorsque apt upgrade est automatisé. Pour faire ce genre de mise à jour, il faudrait manuellement taper la commande. 

Note 1 : Si au sein de votre parc informatique, vous avez un très grand nombre de machines Debian/Ubuntu (plus d'une centaine) par exemple, il serait peut-être judicieux de créer votre propre reposiotry local. Je vous laisse le soin de consulter ces deux articles si le sujet vous intéresse :

Ubuntu : comment créer son propre repository local ?  

Debian : comment créer son propre repository local ?

Note 2 : lors de la première exécution du script, il se peut que vous obteniez les messages (warnings) suivant :

cat /var/log/update_upgrade.err

Après quelques recherches, cette erreur intervient lors de la première exécution du script. Mais par la suite, vous ne devriez pas la rencontrer de nouveau.

En effet d'après ce que j'en ai déduit, le processus dpkg parent d'apt s'inquiète que la modification du mode frontend ait été changée, et nous le signale simplement. En aucun cas, ces messages qui pourraient s'apparenter à des "erreurs fatales" ne sont bloquants pour la mise à jour des dépôts distants et l'installation de nouveaux paquets, donc pas de stress ! 🙂

III. Automatiser le processus de suppression des paquets obsolètes  ?

Hum... Selon moi ce n'est pas une bonne idée, car certaines applications (anciennes ou non) peuvent reposer sur d'anciens packages. Je ne vous recommande pas d'effectuer cette automatisation au risque de perturber certains services de vos serveurs et d'occasionner un dysfonctionnement.

Selon moi, la commande "apt autoremove" doit être exécutée manuellement et avec une attention toute particulière, afin de bien évaluer l'impact de la suppression des paquets détectés comme obsolète/plus utile.

IV. Conclusion et idées d'optimisations

L'automatisation c'est génial ! Mais, gardez en tête qu'il faut de temps à autre jeter un œil au fichier de log, afin de vérifier que les automatisations fonctionnent comme vous le souhaitez.

Pour cela, je vous conseille de vous créer un fichier Excel ou équivalent avec la création d'un planning de tâche cron. C'est ce que j'utilise actuellement, et cela me permet de "prendre de la hauteur" sur l'ensemble de mes automatisations, et de ne pas être perdu parmi les nombreuses tâches cron qui s'exécute (à savoir des dizaines...).

Afin de ne pas vérifier tous les fichiers de logs apt un par un sur tous vos serveurs, il pourrait être judicieux d'implémenter un serveur RSYSLOG afin de centraliser la gestion de vos logs de mises à jour. Comme je suis sympa, je vous donne le morceau de configuration a ajouter dans la configuration rsyslog côté client (pas besoin de mettre quoi que ce soit dans la configuration côté serveur rsyslog).

Ajoutez ce bout de code à la fin du fichier /etc/rsyslog.conf de la machine qui transfert ses logs, et adaptez le en conséquence.

# ...
$ModLoad imfile
$InputFileName /var/log/update_upgrade.log
$InputFileTag tag_app_log:
$InputFileStateFile app_log1
$InputFileSeverity info
$InputFileFacility apt-update-upgrade
$InputRunFileMonitor
apt-update-upgrade @ip-du-serveur-rsyslog:514

# Si-vous utilisez TCP pour le transfert des logs au lieu d'UDP, veilliez à mettre deux @@ au lieu d'un.

A vous de jouer !

The post Automatiser le processus de mise à jour Apt sur Debian first appeared on IT-Connect.

Serveur de fichiers Debian : installer et configurer Samba 4

30 septembre 2021 à 11:30

I. Présentation

Dans ce tutoriel, je vous propose d'installer et configurer Samba 4 sur un serveur Debian 11 afin de créer un serveur de fichiers sous Linux, avec un partage de fichiers.

Qu'est-ce que Samba ?

Samba est une application libre qui tourne sous Linux et qui permet de créer un serveur de fichiers en s'appuyant sur l'implémentation du protocole SMB (CIFS). C'est précisément cette fonctionnalité qui va nous intéresser aujourd'hui, mais sachez que Samba permet également de partager des imprimantes et de créer un véritable contrôleur de domaine Active Directory (prise en charge des GPO, Kerberos, LDAP, DNS, etc.).

Quels sont les prérequis pour suivre ce tutoriel ?

Pour suivre ce tutoriel, vous avez besoin :

  • D'une machine sous Linux, pour ma part Debian 11 (selon la distribution quelques commandes peuvent changer)
  • D'un poste client sous Windows pour tester l'accès au partage, pour ma part Windows 11 (mais Windows 10 fera très bien l'affaire)

Quel est l'objectif de ce tutoriel ?

Nous allons installer le paquet Samba sous Debian 11 dans le but de monter un serveur de fichiers. Ce serveur de fichiers contiendra un seul partage nommé tout simplement "Partage" et il sera accessible par plusieurs utilisateurs. Nous verrons également comment accéder à ce partage depuis un poste client.

Si vous découvrez le protocole SMB à l'occasion de ce tutoriel, rendez-vous à la fin de l'article !

Ready ? Go !

II. Installer Samba sous Debian 11

Note : les commandes sont exécutées directement avec l'utilisateur "root" mais si vous agissez depuis un compte administrateur (autre que root), pensez à préfixer les commandes avec "sudo".

Connectez-vous sur votre machine Linux et mettez à jour la liste des paquets :

apt-get update

Ensuite, installez le paquet "samba" :

apt-get install -y samba
apt-get install -y samba
apt-get install -y samba

Suite à l'installation, on peut afficher la version actuelle de Samba via la commande smbd :

smbd --version
Version 4.13.5-Debian

Pour afficher le statut du serveur Samba, et voir s'il est démarré ou arrêté, voici la commande à exécuter :

systemctl status smbd

Avant de passer à la suite, nous allons activer le démarrage automatique de smbd (Samba) :

systemctl enable smbd

Maintenant, passons à la création du partage Samba.

III. Créer son premier partage sous Samba

La création du partage va s'effectuer en plusieurs étapes : la configuration de Samba dans un premier temps, et la préparation du groupe, de l'utilisateur et du dossier du partage dans un second temps.

A. Configurer le partage dans smb.conf

Le fichier de configuration de Samba est "/etc/samba/smb.conf", nous allons l'éditer :

nano /etc/samba/smb.conf

Ajoutez ensuite les lignes suivantes pour déclarer notre partage :

[partage]
   comment = Partage de données
   path = /srv/partage
   guest ok = no
   read only = no
   browsable = yes
   valid users = @partage
Configurer un partage dans Samba
Configurer un partage dans Samba

Quelques explications :

  • [partage] : sert à spécifier le nom du partage entre "[]", c'est le nom qui devra être utilisé pour accéder au partage
  • comment : description du partage
  • path : chemin vers le dossier à partager, sur le serveur
  • guest ok : accès invité au partage (par défaut "no"). Si vous décidez d'activer cette option, vous devez configurer l'option "guest account" qui par défaut prend la valeur "nobody".
  • read only : partage accessible uniquement en lecture seule (yes ou no)
  • browsable : le partage doit-il être visible ou masqué si on liste les partages du serveur avec un hôte distant (découverte réseau). La valeur "yes" permet de le rendre visible.
  • valid users : spécifier les utilisateurs ou les groupes qui ont les droits d'accès au partage (les droits sur le système de fichiers doivent être cohérents vis-à-vis de cette autorisation). On précise un utilisateur avec son identifiant et un groupe avec son identifiant précédé du caractère "@". Pour indiquer plusieurs valeurs, séparez-les par une virgule.

La configuration étant terminée, sauvegardez le fichier et redémarrez le service smbd :

systemctl restart smbd

B. Créer un utilisateur et le groupe "partage"

Le groupe "partage" que nous avons déclaré dans la configuration n'existe pas. Nous allons créer le groupe, ainsi qu'un utilisateur nommé "it-connect" et qui sera membre de ce groupe.

Créez l'utilisateur "it-connect" et définissez son mot de passe :

adduser it-connect

Pour que l'utilisateur puisse se connecter au partage, il faut l'autoriser dans Samba, en plus de la création au sein du système Linux. Pour cela, il faut utiliser la commande "smbpasswd" pour déclarer l'utilisateur et lui créer un mot de passe Samba (ce dernier pouvant être différent du mot de passe du compte sur le système).

Voici la commande pour ajouter l'utilisateur "it-connect" :

smbpasswd -a it-connect
Créer l'utilisateur et définir son mot de passe Samba avec smbpasswd
Créer l'utilisateur et définir son mot de passe Samba avec smbpasswd

Lorsqu'un utilisateur exécute lui-même la commande "smbpasswd", cela lui permet de modifier lui-même son mot de passe Samba.

L'utilisateur étant prêt, nous allons créer le groupe "partage" :

groupadd partage
Ajouter l'utilisateur au groupe associé à notre partage
Ajouter l'utilisateur au groupe associé à notre partage

Avec gpasswd ou usermod, ajoutez l'utilisateur "it-connect" au groupe "partage" :

gpasswd -a it-connect partage

Le tour est joué pour l'utilisateur et le groupe !

C. Préparer le dossier du partage

Le partage va être hébergé à l'emplacement "/srv/partage" de notre serveur. Commençons par créer le dossier :

mkdir /srv/partage

Ensuite, on va attribuer le groupe "partage" comme groupe propriétaire de ce dossier :

chgrp -R partage /srv/partage/

Puis, nous allons ajouter les droits de lecture/écriture à ce groupe sur ce dossier :

chmod -R g+rw /srv/partage/

On peut vérifier la configuration des droits avec la commande suivante :

ls -l /srv/
Préparer le dossier du partage Samba
Préparer le dossier du partage Samba

Tout est prêt, nous pouvons tester depuis un poste client mais avant cela lisez le point suivant.

D. Le partage [homes] de Samba

Dans sa configuration par défaut, Samba dispose d'un partage nommé [homes]. En fait, il ne s'agit pas réellement d'un partage nommé "homes" mais cette configuration spécifique permet de créer un partage personnel pour chaque utilisateur qui se connecte sur votre machine Linux.

De cette façon, l'utilisateur "it-connect" dispose d'un partage personnel (correspondant à son dossier personnel définit au niveau de Linux) accessible à l'adresse suivante :

\\<nom-du-serveur>\it-connect

Il faut savoir que, par défaut, ces partages sont accessibles en lecture seule et l'utilisateur ne voit que son propre partage, après s'être authentifié au serveur.

Si vous souhaitez désactiver ces partages car vous n'en avez pas l'utilité, il suffit de commenter les différentes lignes (la ligne [homes] ainsi que les directives en dessous) dans le fichier smb.conf et de redémarrer le service Samba.

IV. Accéder au partage Samba depuis Windows

Pour tester l'accès au partage, j'ai pris une machine Windows mais j'aurais pu utiliser un client sous Linux également. Pour accéder au partage, il y a plusieurs possibilités : à partir de l'explorateur de fichiers Windows, d'un lecteur réseau, de la commande net use voire même New-PSDrive en PowerShell.

Exemple - Connecter un lecteur réseau sous Windows
Exemple - Connecter un lecteur réseau sous Windows

Utilisons la méthode la plus courante pour accéder à un partage : un chemin UNC directement dans la barre d'adresse de l'Explorateur de fichiers. Pour ma part, ma machine se nomme "debian-11", ce qui donne :

\\debian-11\partage

Note : vous pouvez utiliser l'adresse IP à la place du nom si vous rencontrez des difficultés.

Accéder au partage Samba depuis Windows
Accéder au partage Samba depuis Windows

Le message accès refusé apparaît, c'est normal, car je dois m'authentifier, donc j'utilise le compte "it-connect" et le mot de passe saisit lors de l'exécution de la commande "smbpasswd".

Parfait ! J'accède bien à mon partage Samba depuis Windows ! Je peux même créer un fichier puisque j'ai accès en lecture / écriture.

Sur le serveur Linux, on peut lister le contenu de notre partage :

ls -l /srv/partage/

Il n'y a pas quelque chose qui vous choc ?

Si l'on regarde les droits du fichier "IT-Connect.txt", on peut voir que l'utilisateur propriétaire est "it-connect" et que le groupe propriétaire est "it-connect" également. En bref, il n'y a que l'utilisateur "it-connect" qui peut modifier ce fichier. Les autres utilisateurs pourront seulement le lire.

C'est gênant, car l'objectif c'est que plusieurs utilisateurs puissent accéder à ce partage et travailler sur les mêmes fichiers et dossiers. Nous allons voir comment ajuster la configuration de notre partage dans Samba.

V. Améliorer la gestion des droits sur le partage Samba

Au sein du fichier smb.conf et de notre bloc [partage], nous allons ajouter trois options :

create mask = 0660
directory mask = 0770
force group = partage

- L'option "create mask" va permettre de définir les droits par défaut sur les fichiers (lecture/écriture pour l'utilisateur propriétaire et le groupe propriétaire seulement)

- L'option "directory mask" va permettre de définir les droits par défaut sur les dossiers

- L'option "force group" va permettre de forcer le groupe "partage" comme groupe propriétaire des fichiers et dossiers

Ce qui donne :

[partage]
   comment = Partage de données
   path = /srv/partage
   guest ok = no
   read only = no
   browsable = yes
   valid users = @partage
   create mask = 0660
   directory mask = 0770
   force group = partage

Une fois cet ajustement effectué, sauvegardez la configuration et redémarrez le service :

systemctl restart smbd

Ensuite, les droits sur les nouveaux dossiers et fichiers permettront la collaboration entre plusieurs utilisateurs :

VI. Désactiver le SMB v1 sur Samba

Pour des raisons de sécurité (voir article ci-dessous), je vous rappelle qu'il est déconseillé d'utiliser le protocole SMB v1. C'est pour cette raison que nous allons configurer le serveur Samba de manière à désactiver le SMB v1.

Retournez dans le fichier "smb.conf" et sous le bloc [global], ajoutez ces deux lignes :

min protocol = SMB2
client min protocol = SMB2
smb.conf - "min protocol" et "client min protocol"
smb.conf - "min protocol" et "client min protocol"

Cela va permettre d'imposer le SMB v2 comme version minimale pour négocier une connexion SMB avec notre serveur Samba. Si vous souhaitez imposer le SMB v3, remplacez "SMB2" par "SMB3".

VII. Découvrir le protocole SMB

Le partage de fichiers avec Samba s'appuie sur le protocole SMB, mais connaissez-vous réellement ce protocole ? Je vous propose une introduction avec mon article "Le protocole SMB pour les débutants", disponible également au format vidéo.

Pour finir, voici le lien vers la documentation de Samba pour aller plus loin.

The post Serveur de fichiers Debian : installer et configurer Samba 4 first appeared on IT-Connect.

Linux : configuration d’un espace de stockage sécurisé avec SFTP

29 septembre 2021 à 10:00

I. Présentation

Dans ce tutoriel, je vais vous expliquer comment mettre en place un système de stockage de fichier sécurisé par l’isolation de chaque utilisateur et le chiffrement des connexions. Autrement dit, nous allons permettre à différents utilisateurs de bénéficier d’un espace de stockage dédié et isolé sur notre serveur, au travers d’une connexion SFTP.

SFTP (pour Secure File Transfert Protocol) est un protocole de transfert de fichier sécurisé qui utilise SSH. Un des gros avantages de FTP est qu’il est simple à déployer et à utiliser ; à l’inverse, il est par nature non sécurisé dans le sens où tout passe en clair sur le réseau, y compris les mots de passe !

SFTP quant à lui, assure un chiffrement dès l’authentification, il permet ainsi d’assurer la sécurité des accès et des données qui transitent. En revanche, il nécessite plus de travail de mise en place et bien que nativement prit en charge dans Windows 10 depuis l’ajout du support OpenSSH, il est plus aisé d’utiliser un logiciel tel que WinScp ou Filezilla. Pour la sauvegarde, vous pouvez utiliser FullSync qui gère les connexions SFTP.

Pour ce tuto, j’ai utilisé un serveur Rocky Linux en installation minimale (pas besoin de plus) et le client OpenSSH de Windows pour la connexion SSH, mais vous pouvez utiliser un logiciel tiers comme PuTTY par exemple.

Bien entendu, ce tuto est reproductible sur CentOS, AlmaLinux ou Oracle Linux tel quel. Pour les utilisateurs de Debian, des notes viennent indiquer les changements de commandes et/ou de chemins de fichiers.

II. Préparation du serveur

A. Configuration du réseau

La première chose à faire bien entendu est d’adresser notre serveur en statique. Comme il s’agit d’un serveur de fichier, il n’est pas concevable de le laisser en dynamique au risque de voir son IP changer !

La gestion des adresses IP sur Linux varie en fonction de la distribution. Par chance sur CentOS, il existe un utilitaire qui permet de faire cela en un rien de temps : NetworkManager TUI

Il suffit donc de taper la commande :

[[email protected] ~]# nmtui

Un menu nous permet alors de définir notre adresse IP en statique. Dans un premier temps, sélectionnez « Modifier une connexion »

Puis de sélectionner l’interface correspondante (pour moi c’est facile, il n’y en a qu’une, mais attention si vous en avez plusieurs) et choisir « Modifier… »

Dans la fenêtre suivante, il faut vous rendre dans « CONFIGURATION IPv4 » pour le changer en « Manuel » puis sélectionner « Afficher ».

Ici, mon réseau étant en 192.168.1.0/24, je choisis l’adresse 192.168.1.100. Bien entendu, vous faites comme vous le souhaitez tant que votre adresse reste dans votre plage.

Au passage, vérifiez bien que la case « Connecter automatiquement » est bien cochée, cela vous évitera des déconvenues…

Note : les utilisateurs de Debian n’auront pas la chance d’avoir ce menu. Pour ceux-ci ou les aficionados de la ligne de commande, je vous laisse suivre les excellents tutos sur ifconfig ou iproute2 en fonction de vos systèmes.

Une fois tout ceci validé, un petit redémarrage des services réseau pour la prise en compte des modifications :

[[email protected] ~]#systemctl restart network
# Sous Debian : 
systemctl restart networking

Et pour valider le changement, on va afficher le résultat de la commande ip a.

Notre serveur est bien adressé, on peut passer à la suite.

B. Vérification de la présence du service SSH

Toutes les distributions Linux viennent avec un client SSH ; la plupart avec un serveur SSH, mais celui-ci n’est pas forcément installé par défaut. Ou encore, il m’arrive également de sauter l’étape correspondante lors de l’installation donc on va déjà vérifier qu’il est bien installé :

[[email protected] ~]#systemctl status sshd

Voici le retour pour moi :

Le service est bien installé et même actif.

Si vous avez un retour de ce genre :

Unit sshd.service could not be found

Pas de chance, c’est que le service n’est pas présent ! Mais pas de panique, on peut l’installer à tout moment grâce à la commande magique :

[[email protected] ~]#yum install -y sshd

Yum est le gestionnaire de paquet pour toutes les distributions dérivées de Red Hat comme le son Rocky, Alma et CentOS, cette commande appelle donc l’installation d’OpenSSH ; l’option « -y » permet d’éviter le prompt de validation.

Note : les utilisateurs de Debian avertis auront ici compris qu’il faut utiliser le gestionnaire de paquet Debian « apt ». La commande devient donc apt-get install -y sshd

C. Mise à jour du système

Donc avant tout, on va déjà se connecter, sur mon PC Windows, j’ouvre une fenêtre PowerShell et utilise la commande suivante :

ssh [email protected]

Si la fonctionnalité SSH n'est pas installée sur votre machine Windows, suivez ce tutoriel : le client SSH sous Windows.

Où « florian» est le nom d’utilisateur (à remplacer bien entendu par le vôtre). Une fois connecté, une petite mise à jour, ça ne fait pas de mal surtout maintenant que le serveur n’est pas encore entré en production. Mais pour cela, il faut se connecter en root avec la commande « su ».

[[email protected] ~]$ su
Mot de passe :

Au passage, vous pouvez constater que ma machine s’appelle « sftp », bien entendu, cela n’a aucune influence sur la suite du programme, vous pouvez la nommer comme vous voulez.

Une fois ceci fait, tapez la commande « yum update » :

[[email protected] ~]$ su
Mot de passe :
[[email protected] florian]# yum update

Dépendances résolues.

Là je n’en ai pas beaucoup, mais cela peut être différent chez vous, donc prévoir un petit temps pour compléter toutes les mises à jour.

Note : les systèmes Debian nécessitent deux étapes pour faire une mise à jour de paquets. D’abord la commande apt-get update pour la mise à jour des dépôts puis apt-get upgrade pour la mise à jour des paquets

III. Mise en place du service

Ce qu’il y a de bien avec SFTP, c’est qu’on peut utiliser ce qu’on appelle une prison chroot (chroot jail). L’appel système « chroot » permet de changer le répertoire racine d’un processus ou d’un utilisateur. On parle de prison, car, lorsqu’il est utilisé, l’utilisateur (ou le processus) à l’impression d’être à la racine du système et donc de n’avoir aucun répertoire au-dessus de celui dans lequel il se trouve.

Cela a ses avantages, car il permet, dans un contexte multi-utilisateur, de ne faire apparaître à l’utilisateur uniquement SES répertoires, il ne pourra pas afficher ceux du voisin. Autre avantage, même si un utilisateur se fait piquer son mot de passe, le voleur n’ira pas bien loin et ne pourra corrompre la totalité du serveur.

On va ajouter à cela l’impossibilité pour un utilisateur d’ouvrir un shell sur le serveur. De base, SFTP est une « variante » de SSH donc en théorie, l’utilisateur pourra ouvrir une ligne de commande, mais ça, on ne veut pas !

Vu qu’on va pas mal manipuler les fichiers de configuration, je vais vous éviter l’utilisation de vi, j’aimerais que ce tuto soit reproductible par le plus grand nombre. On va donc installer nano, pour cela, on se connecte en root puis on tape la commande :

[[email protected] ~]#yum install -y nano

Pour Debian, l’éditeur nano est présent nativement. Pour vous en assurer, vous pouvez utiliser la commande « nano --version ».

Une fois l’installation terminée, l’éditeur de texte est prêt à l’emploi.

A. Empêcher la connexion de root via SSH

Ici, les utilisateurs Debian sont chanceux, l’implémentation de sshd dans cette distribution empêche d’office la connexion de root.

Il est indispensable de ne pas autoriser la connexion de cet utilisateur en SSH. Il faudra alors se connecter avec un utilisateur « lambda » et utiliser le compte root seulement quand nécessaire. Pour mettre cela d’aplomb, il faut aller modifier le fichier /etc/ssh/sshd_config avec nano.

[[email protected] ~]#nano /etc/ssh/sshd_config

Ce qui nous intéresse, ce sont ces lignes :

#Authentication:
#LoginGraceTime 2m
PermitRootLogin yes

On va tout simplement supprimer le « yes » de la dernière ligne pour le transformer en « no ». Une fois fait, on enregistre (Ctrl+o) et on quitte (Ctrl+x). Pour que cela soit pris en compte, on redémarre SSH :

[[email protected] ~]#systemctl restart sshd

B. Configuration SFTP

La première étape est de créer un groupe d’utilisateurs qui pourront se connecter en SFTP. Il sera ainsi plus facile de les gérer le cas échéant.

[[email protected] ~]#groupadd sftp

Encore une fois, le nom « sftp » est celui que j’ai choisi pour mon groupe, vous pouvez l’appeler comme vous voulez.

La seconde étape consiste à créer un répertoire qui va servir de « home » aux utilisateurs sftp :

[[email protected] ~]#mkdir /sftp

Je choisis de le mettre à la racine « / » pour plus de facilité, notamment pour les scripts de sauvegardes. Bien entendu, vous pouvez le mettre où vous le souhaitez.

Là encore, vous le nommez comme vous le souhaitez. L’important est de lui donner les bons droits. En effet, il est IMPÉRATIF de donner la propriété à root ainsi que les droits d’écriture. Rappelez-vous il s’agit de faire croire à l’utilisateur qu’il est à la racine, dont seul root à les droits d’écriture. SI on tape la commande « ls -al / », on constate ceci :

drwxr-xr-x. 2 root root 6 20 juin 03:46 sftp

Ce n’est pas bon, car seul root doit avoir les droits complets (lecture, écriture, exécution r-w-x) or ici, les autres utilisateurs ont également les droits d’exécution. Pour modifier cela, il faut taper la commande :

[[email protected] ~]# chmod 750 /sftp

Les droits sous Linux pouvant être représenté par des chiffres (octal):

  • r (read) = 4
  • w (write) = 2
  • x (execute) = 1

Et chaque bloc représente un utilisateur (propriétaire-groupe-autres). Donc à partir de là, 750 octroie les droits complets au propriétaire, lecture et exécution au groupe et rien aux autres.

Maintenant que la base est là, on va retourner dans la modification du fichier sshd_config :

[[email protected] ~]#nano /etc/ssh/sshd_config

Ce qui nous intéresse ici, ce sont les dernières lignes :

override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
 
Example of overriding settings on a per-user basis
Match User anoncvs
X11Forwarding no
AllowTcpForwarding no
PermitTTY no
ForceCommand cvs server

Il est nécessaire de les modifier de la sorte (les explications viennent après) :

override default of no subsystems
Subsystem sftp internal-sftp
 
Example of overriding settings on a per-user basis
Match Group sftp
X11Forwarding no
AllowTcpForwarding no
PermitTTY no
PermitTunnel no
ForceCommand internal-sftp -d /upload
ChrootDirectory /sftp/%u

Bien, décortiquons tout ça :

- Subsystem sftp internal-sftp va indiquer au démon sshd d’utiliser les commandes intégrées

- Match Group sftp va appliquer les lignes qui suivent à tous les utilisateurs faisant partie du groupe « sftp »

- X11Forwarding no va interdire la transmission de l’affichage entre le serveur et le client (ici nous n’avons pas d’interface graphique, mais il vaut mieux l’activer si d’aventure on en rajoute une)

- AllowTcpForwarding no va interdire les redirections TCP

- PermitTTY no va interdire l’utilisation du shell

- PermitTunnel no va interdire l’utilisation des commandes SSH pour créer des tunnels chiffrés

- ForceCommand internal-sftp va obliger les utilisateurs à n’utiliser QUE les commandes SFTP, l’option « -d /upload » va spécifier le répertoire dans lequel l’utilisateur arrive au moment de la connexion, ceci pour éviter qu’il n’arrive à sa racine, car il n’aura pas les droits d’écriture (voir plus bas)

- ChrootDirectory /sftp/%u va indiquer au démon que les utilisateurs doivent croire que la racine est /sftp/nomdelutilisateur

Il ne nous reste qu’à enregistrer et fermer, puis redémarrer sshd.

IV. Création des utilisateurs

On va créer maintenant notre premier utilisateur « john» avec une seule ligne de commande :

[[email protected] ~]#useradd -s /usr/bin/false -d /sftp/john -G sftp john

- L’option « -s » spécifie le shell à utiliser, on ne veut pas qu’il en utilise donc on lui indique un « faux » shell (en fait, c’est plutôt une commande qui ne fait rien et se termine avec un code d’erreur)

- L’option « -d » indique quel répertoire sera celui de l’utilisateur

- L’option -G ajoute l’utilisateur au groupe (ici sftp)

N’oubliez pas de lui affecter un mot de passe :

[[email protected] ~]#passwd john

Attention, par défaut, le répertoire « john » aura des permissions uniquement pour l’utilisateur john (et root bien entendu). Comme indiqué plus haut, pour que SFTP puisse fonctionner, il est obligatoire d’avoir des droits réglés sur 750 avec root en tant que propriétaire.

Il faut donc modifier le propriétaire du dossier. J’en profite pour déclarer « sftp » comme groupe propriétaire également et modifie les droits :

[[email protected] ~]#chown root:sftp /sftp/john
[[email protected] ~]#chmod 750 /sftp/john

On ne peut pas s’arrêter ici, car l’utilisateur « john » pourra bien se connecter, mais en aucun cas uploader quoi que ce soit. Il faut donc lui créer un répertoire dans lequel il pourra à loisir uploader des fichiers, créer d’autres répertoires, etc.

Rappelez-vous, lors de la configuration du service, on a spécifié  « ForceCommand internal-sftp -d /upload » donc le répertoire qui sera utilisé par l’utilisateur doit s’appeler « upload ».

[[email protected] ~]#mkdir /sftp/john/upload
[[email protected] ~]#chown john:john /sftp/john/upload
[[email protected] ~]#chmod 750 /sftp/john/upload

V. Tester le bon fonctionnement

Pour le test, j’utilise WinSCP que j’aime beaucoup, mais vous pouvez utiliser Filezilla sans problème. Pour rappel, Windows 10 permet l’utilisation de sftp nativement, mais en ligne de commande, WinSCP ou FileZilla ont l’avantage de représenter l’arborescence à la manière d’un Explorer ce qui facilite grandement la manipulation de fichiers et répertoires.

Il est fort probable qu’a la première connexion, vous ayez un message de ce type. Normal, le serveur est inconnu, donc le logiciel ne peut comparer sa clé à une autre en mémoire. Cliquer sur « Oui » pour continuer le processus de connexion.

Comme promis, nous arrivons immédiatement dans le répertoire « upload » où l’utilisateur a les droits d’écriture (répertoire courant en haut à gauche) :

Si on remonte d’un cran, on arrive à ce résultat :

Vous constaterez qu’il est bien indiqué « racine » en haut à gauche en guise de répertoire actuel, alors que nous savons bien que c’est faux ! D’ailleurs, si vous essayez de remonter dans l’arborescence, vous ne pourrez pas.

Comme annoncé également, il sera impossible de créer ou uploader quoi que ce soit dans le répertoire courant, mais dans « upload » pas de soucis, notre utilisateur pourra faire ce qu’il veut.

Et qu’en est-il de la connexion par SSH ?

ssh [email protected]
[email protected]'s password:

PTY allocation request failed on channel 0
This service allows sftp connections only.
Connection to 192.168.1.100 closed.

Le message est on ne peut plus clair, seules les connexions et commandes sftp sont autorisées pour cet utilisateur. En revanche, pas de soucis pour mon utilisateur « florian » qui lui peut encore se connecter.

VI. Montage automatique du répertoire SFTP

Pour une utilisation ponctuelle ou une cible de sauvegarde, les étapes ci-dessus suffisent largement. En revanche, si on veut utiliser le répertoire sftp comme lecteur réseau par exemple, il est nécessaire de « monter » ce répertoire dans le système de fichier actuel pour l’utiliser comme s’il était directement attaché à notre machine.

Pour cela, il existe SSHFS, disponible sur toutes les distributions Linux et même sur Windows !

Note : je ne préconise pas de montage permanent ni sous Linux ni sous Windows. La création d’un tel serveur de fichier est à des fins de sécurité, or un montage permanent va à l’encontre de ce principe, surtout si l’utilisateur n’as pas de mot de passe de session par exemple.

A. Utilisation de SSHFS sous Linux

Retrouvez notre tutoriel dédié à SSHFS à cette adresse : Tutoriel SSHFS - Sinon, en résumé voici les étapes à suivre.

Pour tous ceux équipés d’une distribution desktop, rien de plus simple, il suffit d’installer le paquet sshfs sur leur machine à l’aide de la commande :

# Sur Debian
apt install -y sshfs

# Sur CentOS et dérivés
yum install -y sshfs

Une fois l’installation faite, il faut créer un répertoire qui « accueillera » notre montage, ici, je décide que ce sera un dossier nommé sftp que je crée dans mon répertoire user :

mkdir /home/flo/sftp

Maintenant, il ne me reste plus qu’a utiliser la commande qui va bien :

sshfs [[email protected]]serveur:[dossier distant] point_de_montage [options]

Soit dans mon cas :

sshfs [email protected]:/upload /home/flo/sftp
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
[email protected]'s password:

Une fois le mot de passe rentré, nous pouvons naviguer dans notre répertoire en local.

Note : n’oubliez pas que pour john, son répertoire est à la racine d’où le chemin « /upload » dans la commande sshfs. Si vous indiquez le VRAI chemin (/sftp/john/upload), cela ne fonctionnera pas !

Il est possible de monter ce répertoire en permanence via le fichier fstab en ajoutant la ligne :

[email protected]:/upload /home/flo/sftp fuse.sshfs defaults 0 0

La commande est identique à deux exceptions prêtes :

  • fuse.sshfs : spécifie le système de fichier utilisé
  • defaults : spécifie les options de montage, ici on laisse les options par défaut
  • 0 0 : Ces deux chiffrent sont utiles pour la vérification des erreurs du système de fichier au démarrage. Le premier concerne la racine, le deuxième pour les partitions externes. Ici je ne veux pas de vérification, donc je mets les deux valeurs à « 0 »

Note : si vous voulez vraiment faire un montage automatique, il sera obligatoire de vous authentifier par clé. Le montage par fstab via une authentification par mot de passe n’est pas possible.

B. Utilisation de SSHFS sous Windows

SSHFS est également disponible sur Windows, un grand merci à Bill Zissimopoulos (billziss-gh) pour les deux installateurs disponibles sur GitHub qu’il faudra d’ailleurs récupérer :

Une fois l’installation de ces deux paquets, l’ajout du lecteur réseau est aussi simple qu’un partage SMB directement dans l’explorateur :

\\sshfs\[email protected]

Ici, pas besoin de spécifier de chemin, comme pour les connexions manuelles, l’utilisateur sera immédiatement « propulsé » dans son dossier « upload »

Si tout est OK, vous aurez la demande du mot de passe :

Et le répertoire est monté. Je vous invite grandement à lire le manuel de SSHFS-Win pour voir toutes les possibilités offertes par ce merveilleux utilitaire.

VII. Conclusion

Notre serveur est prêt, vous pouvez maintenant créer d’autres utilisateurs selon le modèle de john et constater qu’ils ne peuvent connaitre l’existence des autres, et encore moins accéder à leurs dossiers.

Nous avons donc vu comment mettre en place un serveur de fichier sécurisé, avec chiffrement des données échangées et isolation des utilisateurs par « enfermement » dans une racine virtuelle.

Avec les possibilités de montage sur Linux ou Windows, cela offre un réel plus, notamment si vous avez plusieurs « clients » que vous souhaitez leur offrir un espace personnel sécurisé pour leurs fichiers sensibles ou encore leurs sauvegardes.

The post Linux : configuration d’un espace de stockage sécurisé avec SFTP first appeared on IT-Connect.
❌