FreshRSS

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

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.

Comment cacher la version de son serveur web Apache ?

18 octobre 2021 à 16:00

I. Présentation

Dans ce tutoriel, nous allons apprendre à cacher la version du serveur web Apache dans les en-têtes HTTP envoyées par notre serveur Apache mais aussi sur les pages d'erreurs.

Pourquoi cacher la version de son serveur web ?

La version d'un serveur web ou d'une autre application serveur est une information très utile aux pirates, car en fonction de la version utilisée, ils peuvent tester diverses attaques et failles connues sur ces versions. Si vous utilisez Apache en version 2.4.49, le pirate pourra rechercher les failles existantes et connues sur cette version, ce qui lui facilite la tâche.

La meilleure protection face à cela étant bien entendu de garder son serveur web à jour, mais il est aussi possible afin de rendre la tâche des attaquants plus longue, et donc plus difficile, de cacher la version de son serveur web Apache. C'est simple à mettre en place, alors pourquoi s'en priver ?

II. Afficher le numéro de version d'Apache

En tant qu'administrateurs, nous avons accès au serveur en direct. Il est alors facile d'afficher dans la console le numéro de version correspondant à notre serveur Apache local.

  • En local sur le serveur Apache

Sous Debian, on peut afficher la version installée avec la commande suivante :

apt-cache policy apache2

Nous aurons alors un résultat comme celui-ci :

apt-cache policy apache2
Exemple - apt-cache policy apache2

Nous voyons donc bien que la version installée est la "2.2.22-13".

Mais, on peut aussi utiliser la commande apachectl, intégrée à Apache avec l'option "-v" ou "-V" (plus de détails). Personnellement, j'utilise plutôt cette méthode.

sudo apachectl -v

Ce qui donne :

Afficher la version d'Apache avec apachectl -v
Afficher la version d'Apache avec apachectl -v

On peut voir, là aussi, que mon serveur est en version 2.4.51.

  • À distance, en tant que visiteur

Depuis une machine distante sous Linux et du paquet Curl, on peut interroger notre serveur Web (par son nom de domaine ou son adresse IP) et obtenir sa version grâce aux informations de l'en-tête HTTP.

curl -I 192.168.100.120

Ce qui donne :

Encore plus simple, on peut générer une page d'erreur à partir d'un navigateur. Par exemple, en accédant à une page qui n'existe pas :

http://192.168.100.120/blabla.html

Au sein de cette page d'erreur 404 (Not Found), on peut voir "Apache/2.4.51" !

Afficher la version d'Apache avec une simple page introuvable
Afficher la version d'Apache avec une simple page introuvable

III. Cacher la version d'Apache

Pour cacher la version d'Apache, il faut changer quelques options dans sa configuration qui se situe par défaut dans "/etc/apache2". Dans ce dossier racine, il y a plusieurs sous-dossiers et fichiers. Le fichier de configuration principal "apache2.conf" appelle les fichiers du dossier "conf-enabled".

Le fichier "/etc/apache2/conf-enabled/security.conf" contient les options ServerTokens et ServerSignature que nous allons modifier. On peut aussi modifier ces options directement via "apache2.conf" en ajoutant ces directives à la fin du fichier.

Modifiez ce fichier (ou ajoutez les lignes à la fin de "apache2.conf") :

sudo nano /etc/apache2/conf-enabled/security.conf

On va venir remplacer :

ServerTokens OS

Par le niveau le plus restrictif :

ServerTokens Prod

Cela va permettre de masquer la version d'Apache. Néanmoins il restera toujours la mention "Apache Server".

En complément, si l'on veut masquer la mention "Apache Server", il faut venir remplacer :

ServerSignature On

Par :

ServerSignature Off

On enregistre et on ferme le fichier de configuration. Après toute modification, il faut recharger la nouvelle configuration du serveur Apache pour qu'elle soit prise en compte :

sudo systemctl restart apache2

On voit donc bien que la version du serveur Apache n'est plus affichée, tout comme la mention "Apache Server".

Voilà, votre serveur n'affichera plus la version d'Apache lorsqu'il sera interrogé. Même si la signature du serveur est masquée, c'est-à-dire la mention "Apache" sans la version, dans certains cas on peut l'obtenir malgré tout (comme avec l'outil Curl).

The post Comment cacher la version de son serveur web Apache ? 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.

Bulletin d’actualité du CERT-FR – 06/10/2021

Bulletin d’actualité du 06/10/2021 Nous voici de nouveau ensemble dans notre rendez-vous de fin de semaine pour revenir sur les différents bulletins de sécurité publiés par le CERT-FR ! Durant la période du 27 septembre au 3 octobre 2021, le CERT-FR (Centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques en France) a …

Apache 2.4.51 publié en urgence, dans la foulée de la 2.4.50

8 octobre 2021 à 07:34

Quelques jours à peine après la sortie de la version 2.4.50, l'Apache Software Foundation a publié Apache 2.4.51 car la précédente mise à jour ne corrigeait que partiellement la faille CVE-2021-41773 présente dans la version 2.4.49.

Dans le but de corriger la faille zero-day CVE-2021-41773 et une autre faille de sécurité au sein d'Apache 2.4.49, l'Apache Software Foundation a publié la version 2.4.50 du serveur Web. Malheureusement, des chercheurs en sécurité ont constaté que le correctif n'était pas suffisamment efficace et qu'il corrigeait partiellement la vulnérabilité.

Rappel au sujet de la faille CVE-2021-41773

Cette vulnérabilité permet d'effectuer une attaque "Path transversal" afin d'accéder à des fichiers situés en dehors de la racine du site, mais aussi de récupérer ces fichiers. Elle est exploitable si vous utilisez Apache 2.4.49 (et seulement cette version) et qu'Apache n'est pas configuré avec la directive "require all denied" sur les fichiers en dehors de la racine du site (DocumentRoot). Par défaut, Apache n'est pas configuré de cette façon, ce qui est d'autant plus alarmant.

Apache 2.4.50 et la faille CVE-2021-42013

Le nouveau vecteur d'attaque découvert dans Apache 2.4.50 a donné lieu à une nouvelle référence CVE : CVE-2021-42013. Elle offre les mêmes possibilités que la faille dans Apache 2.4.49, à savoir accéder à des fichiers en dehors de la racine du site.

D'après l'US-CERT, des scans de serveurs Web sont en cours afin d'exploiter les vulnérabilités CVE-2021-41773 et CVE-2021-42013. Maintenant que ces failles sont connues publiquement, les pirates ne vont pas tarder à développer des exploits prêts à l'emploi, si ce n'est pas déjà fait...

🚨 Active scanning of Apache HTTP Server CVE-2021-41773 & CVE-2021-42013 is ongoing and expected to accelerate, likely leading to exploitation. Please patch immediately if you haven’t already—this cannot wait until after the weekend. Read more: https://t.co/4Ljk730wz4 pic.twitter.com/TYPiXhOluf

— US-CERT (@USCERT_gov) October 7, 2021

Si vous utilisez Apache 2.4.49, il est fortement recommandé de passer en version 2.4.51 dès maintenant. Si vous venez d'installer Apache 2.4.50 cette semaine, c'est pareil, vous devez repasser par la case mise à jour pour passer sur Apache 2.4.51.

Source

The post Apache 2.4.51 publié en urgence, dans la foulée de la 2.4.50 first appeared on IT-Connect.

Apache 2.4.49 : deux failles de sécurité, dont une zero-day !

6 octobre 2021 à 07:43

L'Apache Software Foundation a mis en ligne Apache 2.4.50 afin de corriger deux failles de sécurité, dont une faille zero-day. Si vous utilisez un serveur Web Apache en version 2.4.49, alors votre serveur est vulnérable !

Il y a quelques semaines, Apache 2.4.49 est sortie et c'est précisément cette version qui est touchée par deux failles de sécurité. Les versions antérieures à celles-ci ne sont pas touchées. Comme elle est sortie il y a peu, il est fort probable qu'elle ne soit pas déployée sur la majorité des serveurs Web Apache, et c'est tant mieux. Malgré tout, Apache étant très très utilisé, la version 2.4.49 représenterait plus de 110 000 serveurs Apache dans le monde, dont un peu plus de 7 000 en France.

Par contre, si vous utilisez Apache 2.4.49, il est recommandé de passer sur Apache 2.4.50 sans attendre afin d'être protégé contre les deux failles suivantes : CVE-2021-41524 et CVE-2021-41773.

Apache 2.4.49 - Vulnérabilité CVE-2021-41773

Remontée par Ash Daulton de l'équipe sécurité de chez cPanel, cette faille zero-day Apache est déjà exploitée par les pirates informatiques d'après l'Apache Software Foundation. Cette vulnérabilité permet d'effectuer une attaque "Path transversal" afin d'accéder à des fichiers situés en dehors de la racine du site, mais aussi de récupérer ces fichiers.

Cette faille de sécurité est exploitable si vous utilisez Apache 2.4.49 (et seulement cette version) et qu'Apache n'est pas configuré avec la directive "require all denied" sur les fichiers en dehors de la racine du site (DocumentRoot). Par défaut, Apache n'est pas configuré de cette façon, ce qui est d'autant plus alarmant.

Apache 2.4.49 - Vulnérabilité CVE-2021-41524

Cette deuxième faille de sécurité a une sévérité modérée, et elle permet d'effectuer un déni de service sur le serveur cible en envoyant une requête spécifique sur le serveur, en HTTP/2.

Pour information, c'est LI ZHI XIN de l'équipe de sécurité NSFocus qui a découvert cette faille de sécurité et elle n'est pas exploitée actuellement, contrairement à la faille zero-day.

Si vous souhaitez savoir quelle version d'Apache tourne sur votre serveur Linux, exécutez l'une des commandes suivantes (en fonction de votre distribution) :

apache2ctl -v
httpd -v

Enfin, voici le lien vers le bulletin de sécurité publié sur le site officiel d'Apache.

Source

The post Apache 2.4.49 : deux failles de sécurité, dont une zero-day ! first appeared on IT-Connect.

Comment conteneuriser une application web avec Docker ?

15 septembre 2021 à 10:00

I. Présentation

Aujourd'hui, nous allons voir comment conteneuriser votre application web / site web avec Docker, par l'intermédiaire d'un exemple simple. Vous vous demandez surement dans quel but/objectif conteneuriser un projet ? Et bien cela permettra à une tierce personne de tester "On the fly" votre projet, en outrepassant une phase d'installation (de dépendances, etc.) qui peut s'avérer longue en fonction du type de solution. En effet, celle-ci sera intégrée directement dans l'image du conteneur Docker. Si vous souhaitez que quelqu'un puisse tester votre projet, c'est une bonne manière de lui simplifier le déploiement !

Si vous n'êtes pas très à l'aise avec Docker, je vous encourage à lire le cours suivant d'OpenClassrooms. La conteneurisation avec Docker est une technologie à part entière comme Git, vous ne pourrez pas saisir et comprendre tous les concepts et mécanismes en 1 heure... 🙂

En complément, je vous invite à consulter la ressource suivante si la technologie de conteneurisation est encore très floue pour vous : Principe des DockerFile.

II. Rédaction du fichier Dockerfile

Dans le cas présenté ci-dessous, je souhaite conteneuriser une page web que j'ai développée, permettant d'afficher un compte à rebours en fonction d'une date précise. Dans la pratique, ce n'est clairement pas la peine de conteneuriser cela, car le projet peut tourner facilement sur n'importe quel ordinateur en local disposant d'un navigateur web compatible avec JavaScript Internet Explorer. Mais, imaginez un plus gros projet digne de ce nom, requérant des outils comme PHP, NodeJS, Maven ou autre chose.

Le fait de conteneuriser son application (avec Docker ou autre) prend alors tout son sens, car cela évitera à la personne souhaitant tester l'application d'installer un environnement spécifique (long et fastidieux), si cela est simplement pour un vulgaire test.

Passons à la pratique... Ouvrez un terminal et saisissez les deux commandes suivantes pour créer le dossier "myWebApp" et le fichier "Dockerfile" à l'intérieur :

mkdir myWebApp
touch myWebApp/Dockerfile

Il est important de créer un dossier (à l'emplacement que vous souhaitez) et stocker le fichier DockerFile à l'intérieur. En fait, quand nous allons construire notre image, tout le contenu du dossier sera ajouté à notre image, d'où l'intérêt de "l'isoler".

Le fichier DockerFile va contenir toutes les instructions nécessaires à la fabrication de l'image de notre container. On va préciser l'image de base, ainsi que tous les paquets à installer et les données de notre site Web.

Editez le fichier avec votre éditeur de texte préféré, en insérant le contenu suivant : 

# Utilisation d'une image Ubuntu (par défaut la dernière en date) pour construire notre image docker file
FROM ubuntu 
# Mise à jour des repository distant du container, avant d'installer les paquets requis pour le projet
RUN apt update && apt upgrade -y
# Permet d'éviter d'avoir le bug concernant le choix de la timezone
RUN DEBIAN_FRONTEND="noninteractive" apt-get -y install tzdata 
# Installation des paquets requis pour le projet à savoir git et le service web apache2
RUN apt-get install -y -q git apache2 
# Le conteneur s'éxécutera en se basant sur le service apache2
ENTRYPOINT /usr/sbin/apache2ctl -D FOREGROUND 
# Renommage du fichier de base d'apache2 index.html vers index.html.old
RUN mv /var/www/html/index.html /var/www/html/index.html.old 
# Récupération de mon repository Git avec le mini projet
RUN git clone https://github.com/archidote/get-ready-simple-countdown-html-css-js 
# Copie des fichiers du mini projet web vers la racine de mon serveur web
RUN cd get-ready-simple-countdown-html-css-js && cp * /var/www/html/

Dès lors, enregistrez le fichier DockerFile, puis exécutez la commande suivante :

docker build .
# ou, si vous souhaitez nommer votre image Docker en "mywebapp" :
docker build -t mywebapp .

Une fois l'image construite, affichez les images présentes sur votre hôte Docker avec la commande suivante :

docker images 

Vous devriez voir la vôtre. Dans mon cas, elle est identifiée par l'ID suivant : 9e39...

III. Instanciation du container

L'image étant créée, il faut maintenant instancier un conteneur à partir de celle-ci. Utilisez la commande suivante :

docker run -d -p 8080:80 <id>
  • -d permets de lancer le conteneur en arrière plan (tâche de fond)
  • -p 8080:80 : permet d'exposer le port 8080 (de votre machine hôte Docker) vers le port 80 de votre container (là où est installé le service web, ainsi que le mini projet. C'est grâce à ce mécanisme, que vous allez pouvoir accéder à votre container depuis votre hôte Docker (via un navigateur web)

Vérifiez, que le conteneur est bien en cours d'exécution avec la commande suivante :

docker ps

Dès lors, ouvrez un navigateur et indiquez l'adresse IP de votre machine (hôte) ou localhost, en spécifiant le port "8080" que nous avons choisit précédemment.

Voilà ! L'application web en question, tourne sur le container que je viens de créer.

Si vous voulez interagir directement avec le shell du conteneur, pour éditer un fichier ou autres, entrez la commande suivante :

docker exec -it <id> bash

III. Conclusion

Le Dockerfile que je vous ai présenté peut vous servir de bonne base, pour la rédaction du vôtre. A vous d'adapter la configuration système et les dépendances requises en fonction des prérequis de votre application web :-).

The post Comment conteneuriser une application web avec Docker ? first appeared on IT-Connect.
❌