FreshRSS

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

Une attaque supply chain cible WordPress : 93 thèmes et plugins infectés !

24 janvier 2022 à 09:21

C'est une attaque massive de type "supply chain" qui touche les webmasters de sites WordPress ! Au total, 93 thèmes et plugins sont infectés et contiennent une porte dérobée ajoutée par les pirates informatiques. Environ 360 000 sites actifs seraient vulnérables !

Une porte dérobée intégrée à 93 thèmes et plugins

Cette attaque a été découverte par les créateurs du célèbre outil Jetpack pour WordPress et voici ce qu'ils ont trouvé : une porte dérobée PHP ajoutée à de nombreux thèmes et de nombreux plugins attribués au développeur AccessPress. D'après Jetpack, le site d'AccessPress aurait été compromis afin de permettre l'ajout de la porte dérobée aux fichiers d'installation des différents plugins et thèmes.

Suite à cette attaque, les pirates informatiques ont pu compromettre 40 thèmes et 53 plugins WordPress développés par AccessPress. Au total, il y aurait environ 360 000 sites actifs qui s'appuient sur les thèmes ou plugins d'AccessPress, ce qui les rend vulnérables.

WordPress : une backdoor intégrée à 93 plugins et thèmes

La version infectée par la backdoor d'un plugin ou d'un thème peut être récupérée lors d'une mise à jour ou lors de l'installation initiale sur son site WordPress. Suite à cela, un nouveau fichier nommé "initial.php" est mis en place à la racine du thème et il est chargé via le fichier "functions.php" principal. Le fichier "initial.php" contient un bout de code encodé en base64 et correspondant à un webshell, ce dernier étant déployé ensuite au sein du fichier "./wp-includes/vars.php". Le webshell permet à l'attaquant de prendre le contrôle du site WordPress !

D'après les chercheurs de Sucuri, les pirates utilisent les sites infectés pour rediriger les visiteurs vers des sites malveillants, où sont distribués des malwares.

Mon site est-il infecté ?

Pour tous les propriétaires de sites WordPress, la même question : mon site est-il infecté ? Pour le savoir, commencez par regarder la liste des thèmes et plugins infectés sur le site Jetpack. Si vous utilisez un ou plusieurs éléments de cette liste, effectuez les mises à jour immédiatement pour récupérer une version saine. S'il n'y a pas de mises à jour disponibles, il faut songer à remplacer le thème/plugin par un autre (même si c'est facile à dire !).

Ce qui peut être fait également, c'est vérifier le contenu du fichier "wp-includes/vars.php" afin de voir si la fonction "wp_is_mobile_fix" contient du code obfusqué.

L'origine de l'attaque : septembre 2021

C'est en septembre 2021 que l'équipe de Jetpack a découverte la porte dérobée pour la première fois. À partir du 15 octobre, le portail de téléchargement officiel ne permettait plus de télécharger les différents thèmes et plugins, puisque l'enquête a permis d'identifier que c'était lui qui était compromis.

Depuis le 17 janvier 2022, AccessPress a mis en ligne des versions nettoyées et saines de quasiment tous les plugins ! Par contre, ce n'est pas encore le cas pour les thèmes... ce qui met les webmasters dans une situation embarrassante : prendre le risque d'attendre une mise à jour du thème ou changer immédiatement de thème.

Source

The post Une attaque supply chain cible WordPress : 93 thèmes et plugins infectés ! first appeared on IT-Connect.

Comment auditer un site WordPress avec WPScan ?

12 janvier 2022 à 13:00

I. Présentation

Dans ce tutoriel, nous allons voir comment réaliser un audit de sécurité sur un site WordPress à l'aide de l'outil WPScan, afin d'identifier les failles de sécurité, mais aussi les défauts de configuration.

Afin de réaliser un audit de sécurité d'un site Web, il existe divers outils de sécurité : Nikto, Wapiti, WPScan, etc... Aujourd'hui, nous allons nous intéresser à WPScan, un outil spécifique dédié à l'analyse de sites WordPress.

WordPress étant un CMS utilisé par des millions de sites, il attire forcément le regard des pirates informatiques qui vont chercher à trouver des vulnérabilités au sein du CMS en lui-même, mais aussi dans les extensions et thèmes populaires.

WPScan peut être utile pour auditer son propre site afin d'identifier d'éventuelles faiblesses connues, avant que quelqu'un le fasse avant vous. Cet outil est intéressant en complément des opérations de maintenance effectuées régulièrement, notamment pour maintenir à jour les différents éléments (WordPress, les thèmes et les plugins).

Par ailleurs, WPScan peut-être utilisée dans le cadre de prestation d'audit afin d'analyser le site d'un client. Je ne vais pas vous le cacher et vous l'avez surement deviné, ce type d'outil peut aussi être utilisé à des fins malveillantes.

Attention : n'utilisez pas ce genre d'outil sur des sites web qui ne vous appartiennent pas, à moins d'avoir eu le consentement du propriétaire au préalable.

II. Les fonctionnalités de WPScan

WPScan intègre différentes fonctionnalités que l'on va pouvoir activer ou non en fonction des paramètres utilisés au moment d'exécuter l'outil. Voici quelques-unes des fonctionnalités de WPScan :

  • Récupération du Header HTTP
  • Détection de la possibilité de s'inscrire ou non sur le site
  • Détection de la version de WordPress
  • Analyse du fichier d'exploration robots.txt
  • Récupération d'informations sur le thème, notamment le nom
  • Récupération d'informations sur les extensions
  • Identification de vulnérabilités au sein des extensions détectées
  • Détection de fichiers de configuration de sauvegarde
  • Etc.

Certaines fonctionnalités sont soumises à l'utilisation de l'API WPScan. Les requêtes à destination de cette API sont limitées dans la version gratuite : 25 requêtes par jour sur l'API, tout en sachant qu'une analyse d'un site nécessite généralement plusieurs appels vers l'API WPScan. En fonction des besoins et du nombre d'analyses à effectuer, il faudra peut-être songer à prendre un abonnement payant.

Les différents abonnements de l'API WPscan
Les différents abonnements de l'API WPScan

Avant d'aller plus loin, sachez que WPScan est développé en Ruby et que c'est un projet soutenu par Automattic, l'entreprise propriétaire de WordPress.

III. Installation de WPScan

Pour suivre ce tutoriel, vous avez besoin d'une machine avec Kali Linux puisque WPScan est préinstallé sur cette distribution Linux orientée sécurité.

Pour l'installer sur une autre distribution Linux, je vous invite à vous référer au GitHub du projet : WPScan - GitHub.

Si vous envisagez d'utiliser l'API WPScan (même en version gratuite), vous devez créer un compte sur leur site officiel : WPScan. La création d'un compte ne nécessite pas d'enregistrer une carte bancaire, ce qui est une bonne nouvelle.

IV. Utilisation de WPScan

Sur Kali Linux, l'outil WPScan est un binaire disponible dans "/usr/bin" alors il suffira de l'appeler par son petit nom dans un terminal Linux. Pour afficher l'aide complète de WPScan, la commande suivante doit être utilisée :

wpscan --hh

À partir de là, toutes les options seront affichées à l'écran. Voyons quelques exemples d'utilisation de WPScan.

La première à chose à savoir, c'est qu'il faut inclure le paramètre "--url" pour spécifier le nom de domaine du site à analyser.

wpscan --url www.domaine.fr

Sans aucun autre paramètre, WPScan va effectuer une analyse rapide du site et retourner quelques éléments : header HTTP, contenu du fichier robots.txt, état de la fonction d'inscription du site, détection de la version de WordPress, identification de certains plugins, etc.

Ensuite, il y a une option qui est particulièrement intéressante, c'est l'option "--enumerate" (ou "-e") puisqu'elle permet de spécifier ce qu'il faut analyser (dans le cas d'une analyse ciblée). Par exemple, la valeur "vp" permet de détecter les plugins vulnérables, tandis que la valeur "vt" recherchera la présence d'un thème vulnérable. On peut préciser plusieurs valeurs (mais certaines sont incompatibles entre elles ; voir l'aide), comme ceci :

wpscan --url www.domaine.fr --enumerate vp,vt

Pour que le résultat de cette commande soit complet et pertinent, il faut que l'on utilise l'API de WPScan. En effet, les informations liées aux vulnérabilités sont obtenues après sollicitation de l'API. Sans cela, WPScan va analyser le site distant, récupérer le maximum d'information au sujet des plugins et thèmes, mais il ne vous donnera pas d'informations sur les vulnérabilités détectées.

À partir de votre compte WPScan, vous devez récupérer votre "API Token" afin de l'utiliser avec votre instance WPScan.

Récupérer le jeton d'accès à l'API WPScan
Récupérer le jeton d'accès à l'API WPScan

Comment préciser le token de l'API au sein de la commande WPScan ? Pour cela, il y a deux possibilités : soit dans la commande directement via le paramètre "--api-token" suivi de la valeur, ou dans un fichier de configuration. La première option me semble préférable dans le cas de l'utilisation gratuite pour gérer au mieux ses 25 requêtes quotidiennes.

Ainsi, dans une requête cela donne :

wpscan --url www.domaine.fr --enumerate vp,vt --api-token VotreJetonAPI

Si vous souhaitez stocker ce jeton d'API dans un fichier de configuration pour ne pas avoir à le préciser à chaque fois, créez ce fichier :

nano ~/.wpscan/scan.yml

Précisez le contenu suivant (en modifiant le jeton) :

cli_options:
  api_token: VotreJetonAPI

Il suffit ensuite d'enregistrer le fichier. Si vous ne précisez pas de jeton d'API en utilisant WPScan, celui-ci sera utilisé systématiquement, sinon si vous précisez un jeton dans la ligne de commande, il sera utilisé à la place de celui dans le fichier de configuration. C'est bon à savoir.

Suite à l'analyse effectuée, vous pouvez voir s'il y a des vulnérabilités ou non au sein des plugins détectés sur le site. Néanmoins, il se peut que certains plugins ne soient pas détectés. Voici un exemple :

WPScan : découverte de vulnérabilités dans les plugins WordPress
WPScan : découverte de vulnérabilités dans les plugins WordPress

Sur la copie d'écran ci-dessus, on peut voir le plugin "NextScripts: Social Networks Auto-Poster". En recherchant sur le site de WordPress, on peut voir qu'il s'agit d'une extension qui permet de publier les nouveaux articles automatiquement sur les réseaux sociaux. C'est également précisé qu'il y a 6 vulnérabilités détectées, avec à chaque fois des informations.

Néanmoins, il faut prêter attention à une ligne en particulier : "The version could not be determined". Cela signifie que WPScan a détecté le plugin mais qu'il n'a pas pu récupérer la version installée. En fait, les vulnérabilités listées sont celles connues pour ce plugin, mais cela ne veut pas dire que le site analysé est vulnérable : tout dépend de la version installée.

À la fin de chaque analyse, plusieurs statistiques sont indiquées, notamment l'état de l'API. Sur l'exemple ci-dessous, on peut voir que cette analyse a consommé 8 requêtes d'API, et qu'il m'en reste 17 à consommer.

WPScan : statistiques sur l'analyse
WPScan : statistiques sur l'analyse

Par défaut, le mode de détection est défini sur "mixed", cela signifie qu'en fonction des éléments à détecter, le scan sera plus ou moins agressif (et donc visible). Pour passer en mode agressif (ou tout en mode passif ; "passive"), on peut utiliser l'option "--detection-mode" :

wpscan --url www.domaine.fr --detection-mode aggressive

Terminons l'utilisation de WPScan en prenant un exemple : l'énumération des utilisateurs WordPress.

L'outil WPScan permet d'énumérer les utilisateurs existants sur un site WordPress, et il faut savoir que par défaut WordPress autorise l'énumération des utilisateurs. Pour énumérer les utilisateurs, il y a plusieurs possibilités : à partir des permaliens via les pages auteur, à partir de l'API REST de WordPress (active par défaut) ou encore du flux RSS. Les comptes associés au flux RSS et aux pages liées aux auteurs sont visibles un peu par tout le monde de par leur visibilité sur les articles d'un site. Par contre, l'API REST de WordPress peut-être très bavarde si elle n'est pas bloquée et réellement donner une liste de comptes, ce qui est dangereux.

Cette énumération des utilisateurs s'effectue seulement avec la valeur "u" de l'option "--enumerate", comme ceci :

wpscan --url www.domaine.fr --enumerate u
WPScan : énumération des utilisateurs WordPress
WPScan : énumération des utilisateurs WordPress

Grâce à ces quelques exemples, vous avez connaissance des options basiques de WPScan. Libre à vous d'explorer l'aide pour aller plus loin dans l'utilisation de cet outil.

V. Conclusion

Une analyse de votre propre site web WordPress avec l'outil WPScan va peut-être vous faire prendre connaissance de certains défauts de configuration.

En complément d'un bon suivi des mises à jour, vous devez mettre en place des mécanismes de protection sur votre site WordPress. Certains plugins de sécurité permettent de vous guider en ce sens, notamment pour masquer des informations sensibles, désactiver l'accès à l'API REST, etc. Pour gérer spécifiquement l'accès à l'API REST, il y a le plugin "Disable JSON API" qui permet une gestion avancée.

Dernièrement, j'ai publié deux articles qui peuvent vous aider à renforcer la sécurité de votre site WordPress :

Si vous avez une question liée à la sécurité de WordPress, n'hésitez pas à laisser un commentaire sur cet article.

The post Comment auditer un site WordPress avec WPScan ? first appeared on IT-Connect.

WordPress 5.8.3 : une mise à jour de sécurité à installer d’urgence !

11 janvier 2022 à 08:31

Depuis quelques jours, WordPress 5.8.3 est disponible et cette mise à jour permet de corriger 4 vulnérabilités au sein de ce CMS utilisé sur des millions de sites.

Parmi ces quatre vulnérabilités, il y en a trois considérées comme importante. Tout d'abord, nous retrouvons la vulnérabilité CVE-2022-21661 qui est une injection SQL via WP_Query et elle affecte toutes les versions de WordPress, sauf la nouvelle version 5.8.3. Cette vulnérabilité n'est pas exploitable directement via le coeur de WordPress mais en passant par certains plugins ou thèmes.

Ensuite, nous avons la vulnérabilité CVE-2022-21662 qui est une faille XSS pouvant permettre l'installation d'une porte dérobée sur le site ou d'en prendre le contrôle. Pour exploiter cette faille de sécurité qui affecte toutes les versions de WordPress sauf la 5.8.3, il faut disposer d'un compte ayant les autorisations de publier des articles sur le site. Par exemple, il faut disposer du rôle "Auteur" sur le site cible.

La troisième vulnérabilité, associée à la référence CVE-2022-21663, est probablement la moins grave puisqu'elle est très difficile à exploiter. Enfin, disons qu'il faut des prérequis qui peuvent surprendre : pour exploiter cette vulnérabilité, il faut des droits de super administrateur, et elle concerne uniquement les sites Multisite de WordPress (gestion de plusieurs sites depuis une même interface). Comme l'explique Wordfence sur son site, dans certains cas, relativement rares, même le super administrateur n'est pas autorisé à exécuter du code arbitraire donc c'est là que l'exploitation de cette faille peut avoir du sens.

Enfin, un peu dans le même esprit que la première vulnérabilité évoquée dans cet article, la vulnérabilité CVE-2022-21664 est une injection SQL via WP_Meta_Query. Elle affecte WordPress pour les versions comprises entre la 4.1 et la 5.8.2.

Voilà, vous en savez un peu plus sur cette mise à jour de sécurité WordPress, et si ce n'est pas déjà fait, je vous invite à l'installer sur votre site !

Source

The post WordPress 5.8.3 : une mise à jour de sécurité à installer d’urgence ! first appeared on IT-Connect.

WordPress : un célèbre plugin SEO contient deux failles de sécurité !

24 décembre 2021 à 14:43

Le très célèbre plugin "All In One SEO" de WordPress contient deux failles de sécurité critiques, désormais corrigées au sein de la dernière mise à jour de l'extension. Ce plugin est utilisé par des millions de sites Internet.

Lorsque l'on administre un site Internet sous WordPress, on a forcément recours à l'utilisation à une extension pour optimiser son référencement sur les moteurs de recherche (SEO). Pour cela, on a le choix entre deux plugins qui sortent du lot : Yoast SEO et All In One SEO. D'ailleurs, sur la page de l'extension All In One SEO on peut voir qu'il y a plus de 3 millions d'installations actives.

Marc Montpas, un chercheur en sécurité de chez Automattic, a trouvé deux failles de sécurité au sein du plugin All In One SEO. La vulnérabilité "CVE-2021-25036" correspond à une élévation de privilèges (en étant préalablement authentifié) tandis que la vulnérabilité "CVE-2021-25036" est une injection SQL (en étant authentifié également).

Bien qu'il soit nécessaire d'être authentifié pour exploiter les vulnérabilités, cela est particulièrement dangereux et accessible, car de nombreux sites autorisent l'inscription des utilisateurs. Même si le rôle "Abonné" est attribué aux nouveaux inscrits, ce qui correspond au rôle avec le moins de privilèges, c'est suffisant pour qu'un attaquant soit en mesure d'exploiter ces failles de sécurité.

Depuis le 7 décembre 2021, une mise à jour du plugin All In One SEO est disponible afin de corriger ces deux failles de sécurité. La version à installer pour être protégé est All In One SEO 4.1.5.3. Le changelog du plugin précise : "Updated: Security hardening for REST API endpoints". Toutes les versions du plugin entre la 4.0.0 et la 4.1.5.2 sont vulnérables.

Si vous avez un site WordPress et que vous utilisez ce plugin, la mise à jour doit être réalisée sans attendre, mais c'est peut-être déjà fait, dans ce cas c'est tant mieux. Compte tenu du nombre d'installations actives de ce plugin, c'est certain que des milliers de sites sont actuellement vulnérables même si la mise à jour est sortie il y a environ 2 semaines. Cette popularité pourrait intéresser les pirates également.

Source

The post WordPress : un célèbre plugin SEO contient deux failles de sécurité ! first appeared on IT-Connect.

Comment protéger son site WordPress avec CrowdSec ?

20 décembre 2021 à 11:30

I. Présentation

Dans ce tutoriel, nous allons voir comment protéger un site WordPress avec l'outil CrowdSec afin de bannir les adresses IP malveillantes.

Grâce à CrowdSec, on va pouvoir protéger notre site WordPress contre toutes les attaques courantes, notamment les scans avec des outils de sécurité, mais aussi les attaques par brute force sur le formulaire de connexion de WordPress.

Afin de pousser un peu plus loin la configuration de l'extension CrowdSec, je vais utiliser un site WordPress derrière un reverse proxy HAProxy. Si vous n'utilisez pas de reverse proxy et que votre site Web est publié directement sur Internet (ou via un NAT), vous pouvez aussi utiliser l'extension CrowdSec (et ce sera encore plus rapide).

Le site WordPress "it-connect.tech" sera mon cobaye pour cette démonstration. Je vais manipuler le serveur Web où est déployé le site WordPress afin de mettre en place CrowdSec et le "PC de l'attaquant" présent sur le schéma ci-dessous.

Je ne vais pas détailler l'installation de mon serveur Web (LAMP - Linux Apache MariaDB PHP) ni l'installation de WordPress dans ce tutoriel. Si besoin, je vous oriente vers ces deux tutoriels existants :

II. Installation de CrowdSec sur le serveur

Sur mon serveur web sous Debian 11, je vais installer CrowdSec directement à partir des dépôts officiels.

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

Le cas échéant, si le paquet n'est pas disponible (sur une version Linux plus ancienne, par exemple), 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 :

sudo cscli collections list

On peut voir que la collection "WordPress" est automatiquement installée : CrowdSec a détecté la présence du CMS. En complément, on retrouve d'autres collections, dont "base-http-scenarios", ce qui va nous permettre d'être protégé contre les attaques Web courantes, y compris sur notre site WordPress.

Suite à l'installation, il est préférable d'effectuer une mise à jour des collections pour être certain de bénéficier des dernières versions et de tous les scénarios de détection. Voici les deux commandes à saisir :

sudo cscli hub update
sudo cscli hub upgrade

III. Mise en place du Bouncer CrowdSec dans WordPress

A. Installation et configuration de l'extension CrowdSec

À partir de l'interface d'administration de WordPress, cliquez sur le lien "Ajouter" du menu "Extensions".

Grâce à la zone de recherche, vous pouvez trouver facilement l'extension "CrowdSec". Ensuite, il suffit de cliquer sur le bouton "Installer maintenant".

Dans la foulée de l'installation, cliquez sur le bouton "Activer" pour activer l'extension. Cela n'aura pas d'impact sur votre site, car il faut lier le Bouncer CrowdSec à notre instance locale CrowdSec pour que cela fonctionne.

À ce sujet, accédez à la console de votre serveur Web et saisissez la commande ci-dessous pour générer une clé d'API pour notre Bouncer. Il faudra copier cette valeur.

sudo cscli bouncers add wordpress-bouncer

Ensuite, retournez sur WordPress et cliquez à gauche sur "CrowdSec" dans le menu afin d'accéder à la configuration de l'extension. Il va falloir renseigner plusieurs options :

  • LAPI URL : indiquez "http://localhost:8080", car CrowdSec est installé sur le même serveur que WordPress.
  • Bouncer API Key : collez la clé d'API générée précédemment
  • Bouncing level : en mode "Normal bouncing", CrowdSec va bannir ou présenter le Captcha aux clients malveillants selon la configuration, tandis qu'en mode "Flex bouncing", le blocage sera toujours effectué via un Captcha. Enfin, le mode "Bouncing disabled" permet à CrowdSec d'être transparent donc il ne bloquera plus personne, y compris les pirates. Prenons le mode "Normal bouncing" pour le moment.
  • Public website only : désactivez cette option afin de protéger la partie publique du site, mais aussi l'espace d'administration (wp-admin). Si cette option est active, CrowdSec protège seulement la partie publique du site (front office).

Validez en cliquant sur le bouton "Enregistrer les modifications".

À partir de la ligne de commande de votre serveur, exécutez la commande suivante pour lister les bouncers actifs :

cscli bouncers list

On constate que le bouncer WordPress est bien présent et valide ! Bonne nouvelle !

B. Un reverse proxy ? Configurez le module remoteip

Pour fonctionner, le bouncer WordPress va s'appuyer sur les journaux du serveur Web notamment pour identifier le client source par son adresse IP.

Dans le cas où vous utilisez un reverse proxy ou un CDN comme CloudFlare, c'est l'adresse IP du proxy qui est visible dans les journaux puisque c'est lui qui communique en direct avec le serveur Web. Cela ne joue pas en notre faveur, mais heureusement on peut ajuster la configuration d'Apache pour récupérer l'adresse IP d'origine du client.

Note : en amont, il faut configurer le reverse proxy pour qu'il ajoute le champ "X-Forwarded-For" à l'en-tête des requêtes HTTP afin de transmettre l'adresse IP du client au serveur Web.

Pour configurer Apache, il faut activer le module "remoteip" (normalement installé par défaut) :

a2enmod remoteip

Ensuite, il faut modifier le fichier de configuration d'Apache :

nano /etc/apache2/apache2.conf

Il faut modifier le format des logs et plus particulièrement la ligne qui termine par "combined". Il faut remplacer "%h" par "%a" pour spécifier dans les logs l'adresse IP du client d'origine plutôt que l'adresse IP de l'hôte qui contact le serveur Web directement.

Ce qui donne :

Enfin, on va ajouter à Apache que le champ "X-Forwarded-For" contiendra l'adresse IP du client d'origine au sein de l'en-tête HTTP. Pour cela, on utilise l'option RemoteIPHeader du module remoteip. Ajoutez la ligne suivante au fichier apache2.conf :

RemoteIPHeader X-Forwarded-For

Il ne reste plus qu'à sauvegarder le fichier et redémarrer Apache :

systemctl restart apache2

Nous verrons dans la suite de ce tutoriel l'impact de cette modification sur les logs d'Apache. La configuration de CrowdSec étant prête, nous allons pouvoir attaquer notre site WordPress.

IV. Tester le bon fonctionnement

Pour simuler une attaque contre un site Web, en l'occurrence ici un site WordPress, il y a plusieurs façons de faire. On peut utiliser Nikto, Wapiti, WPScan ou tout simplement Curl avec un user-agent suspect.

C'est d'ailleurs Curl que je vais utiliser, car ce que j'aime bien quand il s'agit de faire une démo, c'est que l'on voit en direct le code de retour HTTP : 200 quand la page se charge correctement, et il passe à 403 ou 401 une fois que CrowdSec est intervenu (le code dépend de la décision : bannir ou captcha).

On va contacter notre site en utilisant le user-agent OpenVAS (un outil de sécurité), ce qui ne devrait pas plaire à CrowdSec, car il est dans la liste des "bad user agent". Ce qui donne la commande :

curl -I https://it-connect.tech -H "User-Agent: OpenVAS"

Sur la copie d'écran ci-dessous, on peut voir qu'au début le serveur Web me répond bien, avec un code HTTP 200 donc j'accède au site. Ensuite, j'obtiens une réponse "403 Forbidden", ce qui correspond à un accès refusé. On va aller voir avec un navigateur ce qu'il se passe...

À partir du navigateur, si je tente d'accéder à l'espace d'administration de mon site WordPress ou au site en lui-même, j'obtiens un message qui m'indique je suis actuellement banni par le système ! Nous verrons dans la suite de ce tutoriel comment personnaliser cette page.

À partir de la ligne de commande, on peut lister les décisions actives dans CrowdSec et on peut voir la présence de notre adresse IP publique. L'action "BAN" montre bien que l'adresse IP est bannie pour une raison claire "http-bad-user-agent", ce qui montre clairement que CrowdSec n'a pas aimé que je me présente avec le user-agent OpenVAS.

sudo cscli decisions list

Si l'on regarde les journaux d'Apache, on peut voir la ligne avec le code HTTP 403, et cette même ligne commence bien par l'adresse IP publique utilisée par le PC de l'attaquant. Toutes les autres lignes visibles sur l'image ci-dessous correspondent aux différents "check alive" effectué par le reverse proxy pour vérifier si le serveur Web est opérationnel (d'où l'adresse IP du reverse proxy qui apparaît toutes les secondes).

J'ai l'avantage d'être à la fois l'attaquant et l'admin du site WordPress alors je vais débloquer mon adresse IP (via un autre accès sur le serveur) :

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

On va tester d'une seconde façon l'efficacité de CrowdSec : en s'attaquant au formulaire de connexion de WordPress, accessible via la page wp-login.php.

Brute force WordPress : comment va réagir CrowdSec ?
Brute force WordPress : comment va réagir CrowdSec ?

Si on liste les décisions actives, comme nous avons fait précédemment, on peut voir que cette fois-ci la raison du blocage est différente : http-fb-wordpress_bf. CrowdSec a bien détecté que j'étais en train d'effectuer un brute force sur la page de connexion !

Notre site WordPress est protégé par CrowdSec, mais pour finir je vous propose de voir quelques options supplémentaires du Bouncer WordPress.

V. Optimiser la configuration du Bouncer WordPress

A. Les options avancées du Bouncer WordPress

Dans l'interface d'administration de WordPress, à gauche sous le menu CrowdSec cliquez sur "Advanced".

Cette partie permet d'accéder à quelques options supplémentaires, dont l'option "Trust these CDN IPs (or Load Balancer, HTTP Proxy)". Cette option va permettre de préciser les adresses IP correspondantes au CDN que vous utilisez, par exemple CloudFlare, ou alors l'adresse IP de votre reverse proxy, comme dans mon cas. C'est pour cette raison que je spécifie l'adresse IP "192.168.100.1".

Ensuite, vous pouvez activer l'option "Hide CrowdSec mentions", cela va permettre d'éviter d'afficher sur la page de blocage que c'est CrowdSec qui sécurise le site. Même si CrowdSec c'est génial, ce n'est pas la peine d'afficher le nom de l'outil publiquement. 😉

Vous pouvez sauvegarder les changements.

Au sein de la section de configuration globale de CrowdSec, nous avons choisi le mode "Normal bouncing" pour bannir les adresses IP lorsque c'est utile. Si vous choisissez le mode "Flex bouncing", un captcha sera présenté. À titre d'information, voici ce que ça donne côté utilisateur via le navigateur :

B. Personnaliser la page de blocage CrowdSec

La page de blocage qui s'affiche lorsque l'on est banni ou la page du captcha sont toutes les deux en anglais. Sachez qu'il est possible de les configurer totalement via l'extension CrowdSec de WordPress. Cette fois-ci, sous le menu "CrowdSec", choisissez "Theme customization".

Vous allez pouvoir modifier le texte des deux pages, mais aussi jouer sur les couleurs, ainsi que sur le style CSS de la page ! De cette façon, la page de blocage présentée par CrowdSec pourra respecter la charte graphique de votre site.

Voici un exemple :

Ce qui donne en production :

C. Brute force WordPress : modifier le seuil de blocage

En listant les scénarios via la ligne de commande (cscli scenarios list), on peut voir que le fichier de configuration du scénario "http-bf-wordpress_bf" est situé à cet emplacement :

/etc/crowdsec/scenarios/http-bf-wordpress_bf.yaml

Pour ajuster le comportement de ce scénario, notamment le seuil de blocage, il faut modifier ce fichier. On obtient le contenu suivant :

Il y a deux paramètres ajustables :

  • capacity: 5
  • leakspeed: "10s"

Il faut interpréter cette configuration par défaut de cette façon : nous avons un sceau (bucket) d'une capacité de 5 unités au maximum (capacity: 5) et une unité de ce sceau est retirée toutes les 10 secondes (leakspeed: "10s"). À chaque fois que j’effectue une tentative en erreur sur la page de login, une unité est ajoutée dans le sceau et à la 6ème unité, le sceau déborde donc je dois être banni (ou avoir un captcha). Vous pouvez ajuster ces deux valeurs en fonction de vos besoins.

Note : à cause de la mise en cache des informations via PHP, il peut y avoir une certaine latence entre le moment où l'action se produit et le moment où la décision est appliquée.

Avec toutes ces informations, vous êtes désormais en mesure de déployer CrowdSec sur votre serveur Web afin de protéger votre site WordPress des attaques informatiques.

VI. CrowdSec : les autres épisodes

Avant de vous laisser, je tenais à vous rappeler que j'ai déjà publié deux épisodes sur l'installation et la configuration de CrowdSec correspondant à deux autres cas de figure. Voici les liens :

Je profite de cet article et de l'actualité du moment liée à la faille de sécurité critique "Log4Shell" pour vous informer que CrowdSec a publié un scénario afin de détecter et bloquer cette attaque. Grâce aux différentes instances de la communauté CrowdSec, plus de 1 100 adresses IP ont déjà été bloquées pour avoir tenté d'exploiter la vulnérabilité Log4Shell. Vous pouvez accéder à cette liste d'IP gratuitement ici.

En complément, vous pouvez accéder à une carte qui permet de voir en temps réel les adresses IP à l'origine d'attaques cherchant à exploiter cette faille de sécurité : Log4j - Carte temps réel CrowdSec.

The post Comment protéger son site WordPress avec CrowdSec ? first appeared on IT-Connect.

Nginx : comment réécrire des URL avec rewrite

19 décembre 2021 à 13:54

Le serveur WEB Nginx donne la possibilité de réécrire très facilement des URL.
Pour cela, on utilise les directives rewrite ou return.
Les deux permettent de créer des redirections 301, 302 mais la directive rewrite est bien plus puissante.
En effet, on peut utiliser les expressions régulières pour créer des réécritures d'URL complexes.

Dans ce tutoriel, je vous montre comment fonctionne la réécriture d'URL sur Nginx.

Nginx : comment réécrire des URL avec rewrite

Comment utiliser rewrite sur Nginx

La directive rewrite donne la possibilité d'une réécriture complète d'une ou un groupe d'URL en utilisant les expressions régulières.
Cela est utile lorsque l'on doit manipuler des arguments d'URL par exemple.
Voici la syntaxe :

rewrite regex URL [flag];
  • Regex : est l'expression régulière pour correspondre à une ou un groupe d'URL
  • URL : L'URL finale réécrite
  • Flag : les drapeaux break, last, redirect ou permanent. Voir le paragraphe suivant

Les variables et drapeaux

return et rewrite acceptent plusieurs variables dont voici les principales :

  • $host est le nom d'hôte
  • $scheme est utilisé pour définir le schéma de l'URL (HTTP ou HTTPS)
  • $request_uri contient une URI complète avec des paramètres

Les drapeaux de rewrite :

  • Last : arrête le traitement de l'ensemble actuel de directives rewrite et démarre une recherche d'un nouveau bloc location correspondant à l'URI modifiée
  • break : arrête le traitement de l'ensemble actuel de la directive rewrite et aucune recherche de bloc location avec la nouvelle URL est effectuée
  • redirect renvoie une redirection temporaire avec le code 302; utilisé si une chaîne de remplacement ne commence pas par "http: //", "https: //" ou "$scheme"
  • permanent : Renvoie une redirection permanente avec le code 301

Comment réécrire des URL avec rewrites avec Nginx

Utilisez return pour retourner un code spécifique ou effectuer une redirection sur une URL.
Tandis qu'il vaut mieux utiliser rewrite pour effectuer des redirections sur des groupes d'URL ou manipuler des arguments d'URI.

Réécrire une page statique avec rewrite

Voici un exemple de réécriture d'URL statique avec rewrite :

server {
          [...
]
          location = /tutoriel-malekal 
          { 
            rewrite ^/tutoriel-malekal$ /malekal-tuto.html break; 
          }
          [...]

}
  • Le bloc location correspond à l'URL avec /tutoriel-malekal
  • Puis rewrite cherche le motif ^/tutoriel-malekal?$
    • Le caractère ^ indique que la page doit commencer par le mot tutoriel
    • Le caractère $ correspond à la fin de l'URL
  • /malekal-tuto.html est la nouvelle URL réécrite
  • break indique d'arrêter la réécriture ici et aucune recherche de bloc location n'est effectuée avec la nouvelle URL

Réécrire des pages dynamiques

On peut aussi réécrire des pages dynamiques qui contiennent des arguments.
Cela est utile, par exemple en PHP.

Imaginons la page https://www.example.com/user.php?id=11 que vous désirez réécrire en https://www.example.com/user/11.
On peut faire cela en seule règle rewrite de cette manière :

server {
          [...]

          location = /user.php 
          { 
            rewrite user.php?id=$1 ^user/([0-9]+)/?$ break; 
          }
          [...]

}
  • La directive location /user.php indique de n'appliquer le bloc que pour les pages /user.php
  • Puis la directive rewrite s'applique sur les pages user.php?id=$1
    • L'expression régulière dans le support carré [0-9] + contient une plage de caractères compris entre 0 et 9. Le signe + signifie correspondant à un ou plusieurs des caractères précédents. Sans le signe + +, l'expression régulière ci-dessus correspondra à seulement 1 caractère comme 5 ou 8 mais pas avec 25 ou 44
    • La parenthèse () dans l'expression régulière fait référence à la référence arrière. Le $1 de l'URL de remplacement user.php?id=$1 fait référence à cette référence arrière

Ainsi, si un utilisateur se connecte avec l'URL https://www.example.com/user.php?id=20, il sera redirigé vers https://www.example.com/user/20 grâce à la réécriture de l'URL.

Comment retourner du texte ou JSON

On peut aussi return pour retourner du texte ou du contenu en JSON
Par exemple pour retourner des données au format texte :

location ~ ^/get_text {
  default_type text/html;
  return 200 'This is test text!'; 
}

Retourner des données en JSON :

location ~ ^/get_json {
  default_type application/json;
  return 200 '{"status":"success","result":"nginx test json"}';
}

Créer des redirections de pages, URL, domaine

Enfin rewrites vous permet aussi de créer des redirections de pages, URL ou domaine.
Le tutoriel suivant vous explique comment faire avec de multiples exemples

L’article Nginx : comment réécrire des URL avec rewrite est apparu en premier sur malekal.com.

Nginx : faire une redirection (301, 302, HTTP vers HTTPS, URL, …)

19 décembre 2021 à 13:54

Nginx est un puissant serveur Web HTTP haute performance open source. Il peut fonctionner comme proxy inversé ou proxy POP3 / IMAP. Parmi les nombreuses fonctionnalités, il est possible de créer des redirections de pages, de sites, domaines.
Avec Nginx, on peut créer des redirections 301, 302 ou complètement réécrire une URL à l'aide de règles rewrite.

Dans ce tutoriel, je vous donne de nombreux exemples de redirections Nginx avec les explications afin de pouvoir créer votre propre redirections HTTP.

Nginx : faire une redirection (301, 302, HTTP vers HTTPS, URL, ...)

Les redirections Nginx : comment ça marche

Une redirection HTTP consiste à rediriger un domaine, une URL ou un fichier vers une autre adresse.
Le serveur renvoie une en-tête HTTP avec une code HTTP spécifique.
En effet, il existe deux types de redirections.

Une redirection temporaire (statut code 302 Found) comme son nom l'indique permet de créer une redirection temporaire d'une ressource vers une autre.
Cela est utile par exemple pour mettre hors ligne une page spécifique ou un site entier en redirigeant les visiteurs vers une page de maintenance.

Une redirection permanente (statut code 301 Moved Permanently). Informe le navigateur internet de ne plus utiliser l'ancienne adresse et de mémoriser la nouvelle.
Cette redirection est utile lorsque vous changez l'URL d'une page WEB ou si une page n'est plus accessible et rediriger les visiteurs vers une autre page internet.
Enfin on peut aussi l'utiliser après des modifications techniques, par exemple, un changement de CMS.

Dans Nginx, les redirections se font essentiellement avec la directive rewrite qui permet de réécrire la requête HTTP.
On peut alors rediriger une page entière ou utiliser des regex pour rediriger des pages avec une structure spécifique.
Ainsi, selon les besoins, la maitrise des regex est utile, pour plus d'informations : Guide d'utilisation des expressions régulières.
Enfin il est aussi possible d'utiliser la directive return plus simple à utiliser pour retourner un code HTTP 301 ou 302 sur un bloc server ou dans un bloc location.

L'utilisation de la directive rewrite est décrite dans ce tutoriel :

Comment faire une redirection avec Nginx

Redirection permanente 301 ou une redirection temporaire 302

Dans Nginx la redirection permanente ou temporaire d'une page WEB se fait avec rewrite et utilise la même structure.
Simplement, on indique à la fin à l'aide d'un drapeau le type de redirection redirect ou permanent.

Pour créer une redirection permanente 301 sur Nginx, on utilise rewrite avec l'ancienne page puis la nouvelle page.
Enfin on termine avec redirect.

rewrite ^/ancienne_page$ http://www.newdomain.com/nouvelle_page redirect;

De même pour créer une redirection temporaire 302, on utilise la même structure et on termine avec le flag permanent.

rewrite ^/ancienne_page$ http://www.newdomain.com/nouvelle_page permanent;

Redirection d'une page vers une autre (ou un fichier)

La redirection d'un fichier ou d'une page vers une autre se fait avec rewrite comme expliqué dans le paragraphe précédent.
On peut donc rediriger une page spécifique ou un type de pages utilisant une structure spécifique à l'aide des expressions régulières.

Location path_pattern {        
     rewrite ^/oldURL$ https://www.domainone.com/nouvelleURL redirect; 
}

Par exemple, ci-dessous, je redirige une ancienne page du site https://www.malekal.com/tutorial_nLite.php vers https://www.malekal.com/tutorial-et-guide-nlite/ et ainsi de suite.

rewrite ^/tutorial_nLite.php$ https://www.malekal.com/tutorial-et-guide-nlite/ permanent;
rewrite ^/tutorial_LogMeIn.php$ https://www.malekal.com/tutorial-et-guide-logmein/ permanent;
rewrite ^/tutorial_ProcessExplorer.php$ https://www.malekal.com/tutorial-process-explorer/ permanent;
rewrite ^/tutorial_Microsoft_Security_Essentials.php$ https://www.malekal.com/tutorial-microsoft-security-essentials/ permanent;
rewrite ^/tutorial_Dial-a-fix.php$ https://www.malekal.com/tutorial-dial-a-fix/ permanent;

Redirection des pages avec des paramètres et variables

Mais on peut utiliser des redirections plus complexes à l'aide de regex, notamment en stockant les motifs dans des variables exactement comme avec la commande sed.

Par exemple, ci-dessous, on redirige toutes les images PNG du dossier wp-content de WordPress, vers un script PHP qui permet de watermark les images.
$1 correspond au motif de la première parenthèse soit le chemin de l'URL et $2 à la second parenthèse soit le nom fichier image.
Les variables sont alors utilisées en argument dans le script wm.php

      location ^~ /wp-content {
               rewrite ^/(.*)/(.*\.(png|PNG)$) /wm.php?d=wordpress&p=$1&i=$2;
      }

Voici un autre exemple ci-dessous pour rediriger les anciennes pages du forum https://forum.malekal.com/XXX-fYYY vers https://forum.malekal.com/viewtopic?f=$2.
$2 correspond à la variable f (second parenthèse), soit le numéro du forum.

rewrite ^/(.*)-f([0-9]*) /viewforum.php?f=$2&$query_string break;

La mise en place d'extension de sitemap pour WordPress nécessite souvent l'ajout de règle rewrite afin de rediriger des pages.
Par exemple ici, on redirige les requêtes de l'index du site map /sitemap_index.xml vers /index.php?sitemap=1.
Puis les pages du sitemap selon leurs numéros avec la même logique.

 rewrite ^/sitemap_index.xml$ /index.php?sitemap=1 last;
 rewrite ^/([^/]+?)-sitemap([0-9]+)?.xml$ /index.php?sitemap=$1&sitemap_n=$2 last;

Redirection d'une page avec un argument spécifique

On peut aussi tester la présence d'un argument afin d'effectuer des redirections de pages spéciques.
Par exemple sur le forum, je redirige des pages viewtopic ou viewforum selon la valeur de l'argument t.

location ~ /view(topic|forum)\.php(/|$) {
            [...]
    if ($args ~ "t=381(&|$)") {  rewrite ^ https://www.malekal.com/proteger-pc-virus-pirates/ permanent; }
    if ($args ~ t=36057) { rewrite ^ https://www.malekal.com/reparer-firefox/ permanent; }
    if ($args ~ t=35837) { rewrite ^ https://www.malekal.com/reparer-google-chrome/ permanent; }
    if ($args ~ t=33839) { rewrite ^ https://www.malekal.com/adwcleaner-supprimer-virus-adwares-pup/ permanent;   }
    if ($args ~ t=1065) {  rewrite ^ https://www.malekal.com/demander-aide/ permanent;  }
    if ($args ~ t=53039) { rewrite ^ https://www.malekal.com/reparer-google-chrome/ permanent;  }
    if ($args ~ t=52529) { rewrite ^ https://www.malekal.com/quest-ce-que-le-dossier-winsxs-et-le-magasin-des-composants-de-windows-10/ permanent; }
    if ($args ~ t=49834) { rewrite ^ https://www.malekal.com/ransomwares-rancongiciels-definition-comment-en-proteger/ permanent; }
    if ($args ~ t=52454) { rewrite ^ https://www.malekal.com/windows-10-mouchards-confidentialite-collecte-donnees/ permanent;      }
    if ($args ~ t=55579) { rewrite ^ https://www.malekal.com/antimalware-execution-service-et-forte-utilisation-cpu-disque-ou-ram-sur-windows-10/ permanent; }
    if ($args ~ t=52494) { rewrite ^ https://www.malekal.com/optimiser-son-disque-sur-windows-10/ permanent;  }

Ainsi par exemple l'URL https://forum.malekal.com/viewtopic?t=52529 redirige vers https://www.malekal.com/quest-ce-que-le-dossier-winsxs-et-le-magasin-des-composants-de-windows-10/

Redirection d'un site www en non-www

Pour retirer les www. d'un site afin de passer en non-www.
On créé un bloc server et on déclare le domaine avec server_name par exemple www.monsite.fr puis on utilise return 301 pour rediriger vers http://monsite.fr.
La variable $request_uri permet de renvoyer l'URL dans la requête HTTP.

server {
    server_name www.monsite.fr;
    return 301 $scheme://monsite.fr$request_uri;
}

avec rewrite, cela donne :

server {
    listen 443;
    server_name www.malekal.com;
    rewrite ^/(.*)$ https://malekal.com$request_uri permanent;
}

Redirection d'un site entier ou domaine

Lors d'un changement de domaine sur un site WEB, on peut rediriger l'ancien domaine vers le nouveau.

Pour cela, on créé le bloc server avec le server_name puis on redirige tout le contenu à l'aide du regex ^/(.*)$ vers le nouveau domaine.
$request_uri permet de rediriger n'importe quelle URL vers le nouveau domaine.

server {
    listen 443;
    server_name malekal.com;
    rewrite ^/(.*)$ https://www.malekal.com$request_uri permanent;
}

Notez que l'on pourrait aussi utiliser la variable $1 pour renvoyer les URL de cette manière :

server {
    listen 443;
    server_name malekal.com;
    rewrite ^/(.*)$ https://www.malekal.com/$1 permanent;
}

Enfin encore en utilisant la directive return :

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    server_name _;
    return 301 $scheme://www.malekal.com;
}

Redirection HTTP vers HTTPS (et port 80 vers le port 443)

Pour forcer le site en HTTPs et SSL, on peut aussi demander à rediriger toutes les connexions HTTP (du port 80) vers du HTTPS (port 443).
Pour cela, on créé un bloc server_name qui écoute sur le port 80 à l'aide de la directive listen.
Puis on créé une redirection 301 avec return sans oublier d'utiliser la variable $request_uri afin de renvoyer l'URL complète avec les arguments.

server {
        server_name www.malekal.com;
        listen 80;
        return 301 https://$host$request_uri;
}

Redirection par un code serveur

On peut aussi rediriger les codes serveur. Cela est utile par exemple lorsque l'on veut afficher des pages spécifiques sur les erreurs 403, 404 ou 503.
Par exemple pour personnaliser la page 403 avec Nginx :

error_page 403 /403.html;

Notez que l'on peut rediriger plusieurs codes serveurs à la fois de cette manière :

error_page 500 502 503 504  /50x.html;

Enfin il est aussi possible de rediriger les codes serveurs vers un bloc Nginx spécifique à l'aide de @ :

server {
[...]
error_page 404 502 504 = @php_micro;
[...]
}

location @php_micro {
[...]
}

Redémarrer nginx

Pour vérifier que la configuration est correcte :

nginx -t
sudo systemctl nginx reload

L’article Nginx : faire une redirection (301, 302, HTTP vers HTTPS, URL, …) est apparu en premier sur malekal.com.

Nginx : Comment activer un site avec sites-enabled ou nginx-modsite

18 décembre 2021 à 17:43

Parfois, on peut avoir besoin d'activer un nouveau site ou désactiver temporairement un site WEB sur Nginx.
Pour vous aider, les distributions Linux Debian ou Ubuntu proposent des répertoires sites-available et sites-enabled dans /etc/nginx.
A partir de là, on peut utiliser des commandes nginx pour activer ou désactiver un site.

Dans ce tutoriel, je vous explique comment activer un site WEB sur Nginx avec deux méthodes par sites-enabled et nginx-modsite.

Nginx : Comment activer un site avec sites-enabled ou nginx-modsite

sites-enabled dans nginx : comment ça marche

Dans les distributions Linux à base de Debian comme Ubuntu, on trouve deux sous-répertoire dans /etc/nginx :

  • sites-available : qui stocke le fichier de configuration des sites
  • sites-enabled : qui contient des liens symboliques vers le fichier de configuration de sites-available

Nginx joue les fichiers de configuration contenus dans sites-enabled.
Ainsi pour activer un site WEB, il suffit de créer le lien symbolique puis recharger la configuration nginx.
Ce fonctionnement n'a rien d'exceptionnel, puisque munin fonctionne de la même manière pour les plugins.
Apache2 fonctionne aussi comme cela pour activer des sites ou modules.

Dans certains distributions Linux, la configuration des sites est à placer dans le dossier /etc/nginx/conf.d/

Le chargement de la configuration des sites se fait à travers un include présent dans /etc/nginx/nginx.conf :

include /etc/nginx/sites-enabled/*;

Lors de l'installation du paquet nginx, ce dernier créé le fichier /etc/nginx/sites-available/default avec une configuration par défaut.

sites-enabled dans nginx : comment ça marche

Comment activer/désactiver un site sur Nginx manuellement

Activer un site sur nginx

  • Créez le fichier de configuration de votre site dans sites-available, dans cet exemple monsupersite :
sudo vim /etc/nginx/sites-available/monsupersite
Le nom du fichier configuration ne doit pas obligatoire comporter l'extension .conf puisque la directive include charge tous les fichiers.
Ainsi, dans notre exemple, vous pouvez utiliser le nom supersite ou supersite.conf
  • Puis créez la structure server de la configuration du site
server {
        root /var/www/html2;
        location / {
            ...
        }
}
  • Ensuite créez le lien symbolique dans /etc/nginx/sites-enabled avec la commande ln :
sudo ln -s /etc/nginx/sites-available/monsupersite /etc/nginx/sites-enabled/monsupersite
  • Eventuellement vérifiez que le fichier est correctement créé :
ls -lh /etc/nginx/sites-enabled/
cat /etc/nginx/sites-enabled/monsupersite
  • Vérifiez que la configuration nginx est correcte :
nginx -t
sudo systemctl nginx reload

Désactiver un site Nginx

La désactivation d'un site sur Nginx est très simple, il suffit de supprimer le lien symbolique.

  • Vous pouvez supprimer le fichier de configuration à l'aide de la commande rm :
sudo rm /etc/nginx/sites-enabled/monsupersite
  • Puis relancez la configuration de nginx :
sudo systemctl nginx reload

Comment activer/désactiver un site sur Nginx avec nginx-modsite

nginx-modsite est un script bash open source disponible sur github.
Ce dernier permet d'activer, désactiver des sites WEB Nginx et relancer la configuration.

OPTIONSDESCRIPTION
-e ou --enableActiver un site
-d ou --disable Disable siteDésactiver un site
-x ou --editEditer un site
-l ou --listLister la configuration des sites
Les options de la commande nginx-modsite

Pour télécharger le script nginx-modsite et le placer dans /usr/bin :

sudo wget https://raw.githubusercontent.com/ajsalkeld/nginx-modsite/master/nginx-modsite -O /usr/bin/nginx-modsite
sudo chmod +x /usr/bin/nginx-modsite

Pour activer un site on utilise l'option -e, par exemple, pour activer le site "monsupersite" :

sudo nginx-modsite -e monsupersite

Puis répondez oui avec la touche y pour recharcher la configuration nginx :

Would you like to reload the Nginx configuration now? (Y/n) y

Ensuite pour lister tous les sites de nginx et vérifiez que le site est bien actif, utilisez l'option -l :

sudo nginx-modsite -l
Available sites:
        default
        default.dpkg-old
        monsupersite
Enabled Sites
        default
        monsupersite
Comment activer/désactiver un site sur Nginx avec nginx-modsite

Enfin pour désactiver le site "monsupersite" dans nginx, on utilise l'option -d :

sudo nginx-modsite -d monsupersite

Confirmez à nouveau la mise à jour de la configuration de nginx par la touche y :

Would you like to reload the Nginx configuration now? (Y/n) y
Comment activer/désactiver un site sur Nginx avec nginx-modsite

L’article Nginx : Comment activer un site avec sites-enabled ou nginx-modsite est apparu en premier sur malekal.com.

Nginx : configurer un MicroCaching pour améliorer les performances

18 décembre 2021 à 13:29

Google à travers les Core Web Vital a lancé course à la vitesse.
La configuration du serveur WEB pour un temps de réponse le plus bas possible est donc primordiale pour un bon référencement.
Mais lorsque l'on héberge du contenu dynamique, tel qu'un forum phpBB, PunBB ou un site WooCommerce, il est n'est pas forcément simple de proposer de bon temps de réponse par une mise en cache.
Pour vous aider, il est possible de mettre en place une stratégie de MicroCaching sur Nginx et PHP-FPM.

Dans ce tutoriel, je vous explique ce qu'est le micro caching et comment le mettre en place sur Nginx.

Nginx : configurer un MicroCaching pour améliorer les performances

Qu'est-ce que le MicroCaching ?

Le micro caching ou cache micro consiste à mettre en place un cache avec un TTL très bas.
C'est à dire un délai de cache très bas par exemple 1 ou 2 minutes.
Ainsi, lorsqu'un utilisateur se connecte sur une page WEB, celle-ci est mise en cache.
Si d'autres utilisateurs envoient des requêtes sur cette même page, le cache va alors répondre.
Celle évite à PHP-FPM de reconstruire la page et donc le temps de réponse devient très bon.
Puis le cache expire et la page est remise en cache avec une version plus récente.
Ainsi de suite.

De ce fait, cette technique pour cacher une page est très intéressant sur les contenus dynamiques car elle permet de bénéficier d'une mise en cache tout en proposant une version de page relativement récent.

Cela permet un gain du TTFB car le serveur répond plus vite lorsqu'il n'a pas besoin de consulter le serveur upstream.
Ainsi, on obtient de meilleurs scores LCP et FCP.

Dans le cas d'un site WordPress, Joomla classique, cela n'a peut d'intérêt puisque les pages WEB ne changent pas souvent.
Il faut plutôt dans ce cas configurer un cache classique avec un délai important de plusieurs heures.

Comment configurer un MicroCaching sur Nginx pour améliorer les performances

Mettre en place le MicroCaching sur Nginx avec FastCGI

Tout d'abord, on créé le path fastcgi dans la partie http.
Il est important de créer une zone keys_zone=micro:10m

fastcgi_cache_path /data/cache/nginx/micro levels=1:2 keys_zone=micro:10m inactive=600s max_size=2G use_temp_path=off;

Voici un exemple de location PHP :

location ~ /\.php(/|$) {
            fastcgi_ignore_headers Cache-Control Expires;
            add_header X-Micro-caching-Status $upstream_cache_status;
            fastcgi_connect_timeout 300;
            fastcgi_send_timeout 300;
            fastcgi_read_timeout 300;

            fastcgi_cache micro;
            fastcgi_cache_key "$cookie_phpbb3_malekal_u$scheme$request_method$host$request_uri";
            fastcgi_pass $php_socket;
            fastcgi_index index.php;

            fastcgi_buffers 32 512k;
            fastcgi_buffer_size 512k;
            fastcgi_busy_buffers_size 512k;
            fastcgi_temp_file_write_size 1024k;


            fastcgi_buffering on;
            fastcgi_cache_use_stale updating;
            fastcgi_cache_background_update on;
            fastcgi_cache_lock on;

            fastcgi_cache_valid 200 302 5m;
            fastcgi_cache_valid 301 1d;
            fastcgi_cache_use_stale error timeout updating invalid_header http_500 http_503;
            fastcgi_cache_bypass $skip_cache;
            fastcgi_no_cache $skip_cache;

            fastcgi_keep_conn on;
            include /etc/nginx/fastcgi_params;
}

Je ne vais pas détailler tous les éléments des directives, pour plus de détails, suivez ce guide : Configurer le cache FastCGI de Nginx

Voici les réglages pour configurer un microcaching :

  • fastcgi_ignore_headers : régler l'en-tête pour faire apparaître les informations de cache (HIT, MISS, BYPASS)
  • fastcgi_cache micro : il s'agit du nom du nom de la keys_zone définit dans fastcgi_cache_path
  • add_header X-Micro-caching-Status $upstream_cache_status :
  • fastcgi_cache_valid 200 302 5m : On cache les pages retournant un HTTP 200 ou 302 pendant 5 minutes. Réglez le délai selon l'équilibre entre délivrer une version à jour du contenu et garder un délai de cache conséquent
  • fastcgi_cache_use_stale error : lorsque NGinx reçoit une erreur, un délai d'attente et des erreurs spécifiées du serveur upstream et dispose d'une version rassise du fichier demandé dans le contenu mis en cache, il fournit le fichier dépassé
  • fastcgi_cache_use_stale updating et fastcgi_cache_background_update on : demande à Nginx de servir de contenu obsolète lorsque les clients demandent un fichier expiré ou sont en cours de mise à jour à partir du serveur en amont
  • fastcgi_cache_lock on : si plusieurs clients demandent le même contenu qui ne figure pas dans le cache, Nginx n'enverra que la première demande au serveur en amont (upstream), le cache de la réponse servant ensuite les autres demandes clientes du cache.

Notez que pour vous pouvez utiliser la directive fastcgi_cache_min_uses qui définit le nombre de demandes après quoi la réponse sera mise en cache.
Par exemple pour ne cacher qu'après deux demandes :

fastcgi_cache_min_uses 2;

Tester les performances du MicroCaching de Nginx

Ensuite, on teste si tout fonctionne grâce aux informations du header.
Par exemple avec les outils de développement des navigateurs internet ou encore avec curl.

A la première connexion, la page n'est pas en cache, on le voit car header X-Micro-caching-Status retourne MISS.
Le temps de chargement de la page internet est de 1,70s et le DOM se charge en 768ms.

Tester les performances du MicroCaching de Nginx

Lorsque la page est en cache avec X-Micro-caching-Status retourne HIT.
Le DOM se charge en 505 ms et la page en 1,15s.

Tester les performances du MicroCaching de Nginx

Ainsi on gagne environ 200 ms entre une page en cache et une page non cachée.

L’article Nginx : configurer un MicroCaching pour améliorer les performances est apparu en premier sur malekal.com.

PfSense : reverse proxy HTTPS avec HAProxy et ACME (Let’s Encrypt)

13 décembre 2021 à 17:15

I. Présentation

Dans ce tutoriel, nous allons voir comment configurer un reverse proxy HTTPS avec HAProxy sur PfSense. Pour le certificat du site, on utilisera ACME pour générer (et renouveler) automatiquement le certificat SSL avec Let's Encrypt.

HAProxy est une solution très complète et incontournable lorsque envisage de mettre en place un reverse proxy. Lors de l'utilisation d'un pare-feu PfSense sur un réseau, on peut ajouter la brique HAProxy par l'installation d'un simple paquet qu'il faudra ensuite configurer.

Démonstration au format vidéo disponible ci-dessous, avec le reverse proxy et un pool de deux serveurs Web pour le même site.

Pour cet exemple, je vais utiliser un serveur PfSense déjà configuré avec 2 interfaces (WAN et LAN), un serveur Web qui sera derrière le reverse proxy et qui contient le site Web WordPress à publier sur Internet, et un poste de travail distant (client en provenance d'Internet) pour tester le reverse proxy.

Ce qui donne le schéma suivant pour le site Internet "it-connect.tech" :

Dans la pratique :

1 - Le client tente de se connecter au site Internet "it-connect.tech", en HTTPS, il tombe sur HAProxy (sans s'en rendre compte).

2 - Le reverse proxy HAProxy traite la requête, il voit que le client veut accéder au site "it-connect.tech" donc il interroge le bon serveur Web (192.168.100.121/24), sur le port 80, car le serveur Web écoute sur ce port (on pourrait en utiliser un autre).

3 - Le serveur Web traite la requête du client, relayée par le reverse proxy (c'est le reverse proxy qui communique avec le serveur Web) et lui retourne une réponse (par exemple : le code source de la page demandée).

4 - Le reverse proxy retourne la page Web demandée au client, au sein d'une connexion sécurisée HTTPS.

II. Gérer les certificats Let's Encrypt sur PfSense

La première étape consiste à gérer les certificats SSL Let's Encrypt directement sur notre pare-feu PfSense. L'idée étant de générer le certificat initial, mais aussi de le renouveler automatiquement. La question que l'on peut se poser, c'est "pourquoi gérer le certificat SSL au niveau du reverse proxy plutôt que sur le serveur Web, voire même les serveurs web ?".

Le reverse proxy HTTPS va répondre aux requêtes HTTPS (comme son nom l'indique), alors c'est lui qui doit être en mesure de présenter au client le certificat SSL correspondant au domaine du site visité. Cela signifie qu'il doit héberger le certificat SSL.

Pour cela, on peut importer un certificat SSL obtenu auprès d'une autorité de certification en ligne et qui est valide pour une durée limitée (1 an, 2 ans, etc.). Sinon, l'alternative consiste à utiliser Let's Encrypt pour utiliser un certificat SSL gratuit, valide 90 jours à chaque fois, mais que l'on peut renouveler automatiquement (c'est ce que nous allons faire).

Imaginons que l'on ait une ferme de 2, 5 ou 10 serveurs Web pour le même site, cela signifie que lorsqu'un nouveau certificat SSL doit être déployé, il faut répéter l'opération autant de fois qu'il y a de serveurs Web. En gérant le certificat au niveau du reverse proxy, on limite aussi la maintenance.

A. Installation du paquet ACME sur PfSense

La première étape consiste à installer le paquet ACME. Sous le menu "System", cliquez sur "Package Manager" puis via l'onglet "Available Packages", recherchez et installez le paquet "acme".

Une fois que c'est fait, sous le menu "Services", cliquez sur "Acme Certificates".

Passons à la configuration.

B. Générer les clés ACME

Il faut que l'on commence par demander une clé d'authentification auprès de Let's Encrypt pour être autorisé à demander les certificats par la suite. Pour cela, cliquez sur l'onglet "Account Keys" et cliquez sur le bouton "Add".

Commencez par nommez cette clé, par exemple "certs.it-connect.tech" (le nom DNS n'a pas besoin d'être résolvable) et choisissez "Let's Encrypt Production ACME v2" au niveau de l'option "ACME Server".

Cliquez sur le bouton "Create new account key" pour générer une clé d'authentification et cela va remplir le champ "Account key" juste au-dessus. Nous devons enregistrer cette clé, donc je vous invite à cliquer sur "Register ACME account key". Normalement, un petit icône validé doit venir s'afficher sur le bouton, comme ceci :

Cliquez sur "Save" et vous obtenez ceci dans "Account keys" :

C. Demander un certificat Let's Encrypt depuis PfSense

Basculez sur l'onglet "Certificates", car nous allons demander notre premier certificat SSL Let's Encrypt pour notre site "it-connect.tech". Cliquez sur le bouton "Add".

Donnez un nom à ce certificat : le nom de domaine est une bonne idée donc ce sera "it-connect.tech" pour ma part. Choisissez le compte ACME que l'on vient de créer au niveau de l'option "Acme Account".

Ensuite, pour l'option "Domain SAN list", ajoutez une nouvelle entrée et choisissez la méthode "DNS-Manual". De cette façon, on va créer un enregistrement DNS par la suite pour prouver que l'on est bien propriétaire du nom de domaine. Pensez à renseigner l'option "Domainname" pour préciser le nom de domaine : pour ma part "it-connect.tech", car c'est le nom de domaine pour lequel je veux obtenir un certificat SSL.

Note : par défaut, le certificat est configuré pour se renouveler automatiquement tous les 60 jours (voir option "Certificate renewal after" en bas de page), tout en sachant qu'il est valide 90 jours à chaque fois.

Une fois que c'est fait, validez. Dans l'onglet "Certificates", votre certificat doit s'afficher (attention, il n'est pas généré pour le moment). Cliquez sur le bouton "Issue".

Suite à cette action, on peut voir que l'ACME nous demande de créer un enregistrement DNS TXT avec le nom "_acme-challenge" et une valeur spécifique. Par exemple :

Sur l'interface où se situe la gestion de votre domaine, vous devez créer un nouvel enregistrement DNS de type "TXT" avec les valeurs fournies par ACME, notamment le nom "_acme-challenge". Voici un exemple chez OVH :

Une fois que c'est fait, vous devez cliquer sur le bouton "Renew" comme précisé dans la sortie de la commande précédente.

Vous devriez obtenir une réponse positive (attention, même si c'est vert, parfois il y a des erreurs alors prenez le temps de regarder) qui se caractérise par la présence des lignes "Cert success" et "BEGIN CERTIFICATE", puis tout ce qui suit.

Mon certificat SSL Let's Encrypt pour "it-connect.tech" a été généré avec succès et l'emplacement des fichiers est précisé dans les logs :

Your cert is in /tmp/acme/it-connect.tech//it-connect.tech/it-connect.tech.cer 
Your cert key is in /tmp/acme/it-connect.tech//it-connect.tech/it-connect.tech.key 
The intermediate CA cert is in /tmp/acme/it-connect.tech//it-connect.tech/ca.cer 
And the full chain certs is there: /tmp/acme/it-connect.tech//it-connect.tech/fullchain.cer

Pour finir la partie certificat, cliquez sur l'onglet "General Settings" et cochez l'option "Cron Entry" pour activer la tâche planifiée (dans la crontab) afin de le renouveler automatiquement.

Ce certificat va pour voir être présenté au client qui voudront se connecter au site it-connect.tech, afin de sécuriser la connexion, et cela sera fait par HAProxy. En parlant d'HAProxy, passons à la configuration du reverse proxy.

III. Reverse proxy HTTPS HAProxy sur PfSense

A. Installation du paquet HAProxy sur PfSense

Sur le même principe que le paquet "acme", installez le paquet "haproxy" sur votre serveur PfSense.

B. Configuration générale de HAProxy

Commençons par l'onglet "Settings" de la configuration de HAProxy. Pour accéder à la configuration de HAProxy, sous le menu "Services", cliquez sur "HAProxy" tout simplement.

Ensuite, il faut renseigner le champ "Maximum connections", c'est-à-dire le nombre de connexions maximales par processus. Il faut ajuster ce paramètre en fonction du dimensionnement de votre serveur et de la fréquentation des ressources derrière le reverse proxy. On peut voir que 1 000 connexions consomment 48 Mo de mémoire, et en dessous on peut choisir le nom de processus à démarrer (1 par défaut / option "Number of processes to start").

Note : il n'est pas nécessaire de cocher l'option "Enable HAProxy" pour le moment, on va préparer la configuration avant.

Un peu plus bas dans la page, indiquez la taille 2048, car c'est une valeur recommandée pour l'option "Max SSL Diffie-Hellman size" (afin d'éviter d'avoir un avertissement dans les logs HAProxy).

C. Déclarer les serveurs backend

Lors de la configuration d'un reverse proxy, il faut configurer le Backend et le Frontend.

Le Backend, c'est ce qui se passe derrière le reverse proxy, cela correspond donc aux différents serveurs qui hébergent les ressources (par exemple, notre serveur Web avec le site it-connect.tech).

Le Frontend, c'est ce qui se passe en frontal sur le reverse proxy, c'est-à-dire de quelle façon le reverse proxy doit se présenter aux clients, et surtout comment il doit traiter les requêtes (par exemple, s'il reçoit une requête HTTPS à destination du domaine it-connect.tech, il doit savoir quoi en faire).

Commençons par le Backend. Cliquez sur l'onglet "Backend" puis sur le bouton "Add".

Cela va permettre de créer un pool de serveurs. Dans cet exemple, même si nous avons un seul serveur Web, on peut considérer que c'est notre pool pour le domaine it-connect.tech. D'ailleurs, on va utiliser ce nom pour notre pool (option "Name").

Ensuite, il faut renseigner l'option "Server list" : c'est là que l'on va déclarer les différents serveurs Web membre de ce pool, et donc qui héberge le site "it-connect.tech". Ajoutez un élément avec les options suivantes :

  • Mode : Active (c'est un serveur actif dans le pool)
  • Name : le nom de l'hôte serveur Web pour s'y retrouver, en l'occurrence "debian-11" pour ma part puisque c'est mon serveur Web (oui, je sais, le nom n'est pas très original)
  • Forwardto : "Address+Port" puisque l'on va interroger ce serveur Web via son adresse IP et un numéro de port spécifique
  • Address : l'adresse IP du serveur Web, pour ma part "192.168.100.121"
  • Port : le port sur lequel est en ligne le site sur le serveur Web, pour ma part "80", car mon site est en HTTP au niveau du serveur Web, mais rassurez-vous, le reverse proxy va s'occuper de chiffrer les communications avec les clients, via le protocole HTTPS et mon joli certificat SSL Let's Encrypt.

Ne cochez pas les options "Encrypt (SSL)" et tout ce qui s'en suit, sinon cela va nous créer des ennuis... Pour l'option "Client certificate", elle est utile seulement si le serveur Web est sur le port 443 en HTTPS, auquel cas il faut spécifier le certificat SSL, comme sur l'exemple ci-dessous. Dans cet exemple, ce n'est pas utile.

Descendez dans la page... Vous verrez qu'il y a énormément d'options. Par exemple, la partie "Loadbalancing Options" sert à définir comment le reverse proxy doit répartir les connexions entre les serveurs du pool actuel. Par défaut, c'est le mode classique appelé round-robin (c'est plus ou moins chacun son tour), mais il y a beaucoup d'autres modes. Ici, j'ai qu'un serveur Web donc la question ne se pose pas. Sinon, le reverse proxy joue le rôle de répartiteur de charge entre les serveurs.

Au sein de la section "Health checking", il est impératif de configurer l'option "Health check method". En fait, le reverse proxy va vérifier à intervalle régulier si notre serveur Web est opérationnel ou pas. Il faut lui indiquer comment effectuer cette vérification. Pour ma part, je choisis "HTTP" : cela implique que le serveur Web soit accessible en HTTP via son adresse IP afin que le reverse proxy puisse l'interroger.

Note : dans les logs du serveur Apache (access.log), vous allez voir une requête par seconde en provenance du reverse proxy, cela signifie qu'il vérifie l'état du serveur Web - Exemple : 192.168.100.1 - - [07/Dec/2021:17:47:54 +0100] "OPTIONS / HTTP/1.0" 200 110048"

Quel est l'intérêt de cette vérification ? Si un serveur Web de notre pool est hors ligne ou que le service Web est planté, le reverse proxy va en tenir compte et ne plus envoyer de requête à traiter à ce serveur Web, jusqu'à ce qu'il revienne à son état normal.

Continuez à descendre dans la page et cliquez sur "Save".

Au sein de la section "Backend", notre pool de serveurs apparaît. Cliquez sur "Apply Changes" pour appliquer la configuration.

Passons à la configuration du Frontend.

D. Déclarer le frontend dans HAProxy

Cliquez sur l'onglet "Frontend" puis sur le bouton "Add".

Nommez ce Frontend "it-connect.tech" puisque l'on va gérer les requêtes à destination de ce domaine. Veillez à ce que le statut ("Status") soit sur "Active".

Ensuite, il faut que l'on configure l'option "External address" de cette façon :

  • Listen address : choisissez "WAN address (IPv4)", car on va traiter les requêtes qui arrivent sur l'interface WAN du PfSense (ce sera cette adresse IP déclarée dans l'enregistrement DNS "A" du domaine it-connect.tech).
  • Port : indiquez "443", car on va publier notre site en HTTPS
  • SSL Offloading : cochez cette option, car cela correspond à notre architecture, c'est-à-dire du HTTPS entre le reverse proxy et les clients, et du HTTP entre le reverse proxy et les serveurs Web. Le SSL Offloading correspond à ce processus du transformation du flux.

Un peu plus bas, sélectionnez l'option "http / https (offloading)" pour la valeur "Type". Cela veut dire que le reverse proxy va travailler au niveau de la couche HTTP/HTTPS.

Remarque : une alternative consiste à utiliser le mode "ssl / https (tcp mode)", mais dans ce cas, le reverse proxy travaille au niveau de la couche connexion avec le protocole TCP. Ce cas est utile si vous souhaitez gérer le certificat SSL au niveau des serveurs Web directement, mais ne permet pas l'activation de l'en-tête HTTP "X-FORWARDED-FOR". C'est utile aussi si vous utilisez le reverse proxy pour autre chose qu'un site Web.

PfSense - HAProxy Frontend

Passons à la section "Default backend, access control lists and actions". Cette section va permettre d'aiguillier les requêtes entre le Frontend et le Backend du reverse proxy. C'est ici que l'on va dire qu'une requête à destination du domaine "it-connect.tech" doit être redirigée vers notre Backend qui contient notre serveur Web.

Pour l'option "Access Control lists", ajoutez une ligne, c'est-à-dire une nouvelle règle (ACL). Comme ceci :

  • Name : nom de l'ACL, par exemple "AccesSite".
  • Expressions : on choisit "Host matches:", car on cherche à repérer la présence du nom de domaine dans l'URL / la requête
  • Value : on précise le nom de domaine du site, à savoir "it-connect.tech"

Pour définir ce que l'on doit faire lorsque cette règle matche, on va ajouter une action dans la section "Actions", comme ceci :

  • Action : on sélectionne "Use backend" et on choisit notre backend créé précédemment, cela permet d'utiliser notre Backend lorsque la requête va correspondre à l'ACL
  • Condition acl names : on spécifie "AccesSite", car c'est le nom de l'ACL que l'on vient de créer

Vous avez aussi la possibilité de définir un Backend qui sera sélectionné par défaut, sans tenir compte de vos ACLs, au niveau de l'option "Default Backend". Néanmoins, si la requête ne correspond pas à "it-connect.tech", il n'y a pas de raison qu'elle soit traitée par notre Backend : il vaut mieux que le reverse proxy refuse la requête.

PfSense - HAProxy Backend

Descendez dans la page. Cochez l'option "Use forwardfor option" pour ajouter le champ "X-Forwarded-For" à l'en-tête HTTP. Pour rappel, cela permettra au serveur Web de connaître l'adresse IP d'origine du client, et pas seulement l'adresse IP du serveur reverse proxy.

Note : pour que l'adresse IP du client d'origine soit visible dans les logs Apache 2.4, vous devez activer le module "remoteip" et adapter le format des logs.

Descendez encore un peu... jusqu'à la section "SSL Offloading" puisqu'il faut choisir le certificat SSL Let's Encrypt au niveau de l'option "Certificate".

Voilà, c'est terminé pour la configuration du Frontend. Cliquez sur "Save". On obtient ceci :

Retournez dans l'onglet "Settings" afin d'activer HAProxy en cochant l'option "Enable HAProxy" puisque notre configuration est prête. Sauvegardez et cliquez sur "Apply changes" avant de passer à la suite.

E. Modifier le port de l'interface de gestion PfSense

Pour que notre reverse proxy HAProxy traite les requêtes qui arrivent sur le port 443 de l'interface WAN de PfSense, il faut que l'on crée une règle de pare-feu. Le problème, c'est que par défaut le port 443 est utilisé par défaut pour l'interface d'administration. Afin d'éviter un conflit (et potentiellement d'exposer l'interface d'administration PfSense), on va modifier le port utilisé.

Sous le menu "System", cliquez sur "Advanced". Dans l'onglet "Admin Access", modifiez l'option "TCP port" pour définir un autre port. Par exemple, le port 8443. Validez et accédez de nouveau à votre PfSense en spécifiant le nouveau port à la fin de l'URL : https://<adresse-IP>:8443.

F. Créer la règle de pare-feu pour HAProxy

Venons-en à la création de la règle de pare-feu pour HAProxy, ce dernier doit être en mesure de recevoir les requêtes sur le port 443. Pour cela, sous le menu "Firewall", cliquez sur "Rules" puis choisissez la zone "WAN".

Créez une nouvelle règle en cliquant sur le bouton "Add" et autorisez les flux HTTPS (443) vers le pare-feu afin qu'ils soient gérés par HAProxy. Ce qui donne :

Remarque : pour que nos flux HTTPS soient traités par notre reverse proxy, je ne veux pas voir de règles de NAT pour rediriger le port 443 vers le serveur Web interne. 😉 - Sinon, cela permettrait de bypasser le reverse proxy est d'atteindre directement le serveur Web, ce qui n'est pas le but : nous n'avons pas fait tout ça pour rien !

G. Les statistiques dans HAProxy

En soit, le reverse proxy est prêt : il est configuré et il peut recevoir ses premières requêtes. Néanmoins, avant de tester, je vous invite à regarder la partie statistique de HAProxy. Pour cela, retournez dans la configuration de HAProxy est spécifiez un port pour accéder à l'interface de statistiques (option "Internal stats port") : l'accès s'effectue seulement en local, via l'interface du PfSense.

Validez et appliquez les changements. Ensuite, toujours dans HAProxy, cliquez sur l'onglet "Stats" dans le menu (le menu "Stats FS" est équivalent, mais en plein écran). L'interface suivante va s'afficher :

Vous pouvez obtenir de nombreuses statistiques, et notamment l'état des différents serveurs de vos Backend. Ci-dessus, on peut voir que le serveur "debian-11" est en ligne, car la ligne est verte, et on peut savoir également combien de sessions il gère, etc...

Lorsqu'un serveur est inaccessible (cela signifie que notre vérification HTTP a échoué), alors la ligne devient rouge. En sélectionnant l'hôte via la case à cocher à gauche, on peut effectuer différentes actions notamment forcer la vérification de l'état de cet hôte ou encore passer l'hôte en mode maintenance ("Set state to MAINT"), ce qui permet de l'exclure du pool de serveurs pendant une opération de maintenance.

Maintenant, il ne vous reste plus qu'à accéder à votre site Internet positionné derrière le reverse proxy pour voir s'il fonctionne bien ! Je vous invite à tester en profondeur le site, notamment le mode visiteur, mais aussi le mode authentifié, en fonction de votre type de site. Pour finir ce tutoriel, quelques mots sur WordPress et Apache...

IV. WordPress derrière HAProxy

Au moment de tester, vous allez peut-être rencontrer quelques problèmes... Sachez que le problème ne vient pas forcément de HAProxy, mais peut-être du serveur Web voire même de WordPress (si vous utilisez WordPress...).

Lorsque vous avez un site WordPress positionné derrière HAProxy, accessible via HTTP en local, mais via HTTPS en externe, comme dans le cadre de cette configuration, vous allez surement rencontrer l'erreur "ERR_TOO_MANY_REDIRECTS" au sein du navigateur.

Que se passe-t-il ? Si le site est configuré avec une URL "HTTPS" dans les paramètres de WordPress et que le reverse proxy lui envoie une requête HTTP, WordPress va vouloir rediriger la requête en HTTPS. Sauf qu'en faisant ça, il va repasser par le reverse proxy qui va lui renvoyer la requête HTTP, et donc lui va vouloir rediriger en HTTPS, ce qui crée une boucle infinie. 🙂

Pour contourner ce problème, il faut que l'on crée une règle dans le fichier "wp-config.php" du site pour écrire l'URL du site en HTTPS et faire croire à WordPress qu'il travaille déjà en HTTPS. En complément, on va forcer l'utilisation du SSL au niveau de l'interface d'administration de WordPress, sinon vous allez obtenir un message d'accès refusé si vous tentez d'accéder au backoffice ou à votre profil une fois authentifié sur le site.

Au début du fichier wp-config.php (c'est important que ce soit au début), ajoutez ces lignes (remplacez le nom de domaine par votre site) :

if ( (!empty( $_SERVER['HTTP_X_FORWARDED_HOST'])) ||
(!empty( $_SERVER['HTTP_X_FORWARDED_FOR'])) ||
(!empty( $_SERVER['HTTP_X_FORWARDED_PROTO']) && strtoupper($_SERVER['HTTP_X_FORWARDED_PROTO']) == 'HTTPS' ) ) {

  define('WP_HOME', 'https://it-connect.tech');
  define('WP_SITEURL', 'https://it-connect.tech');
  $_SERVER['HTTPS'] = 'on';
}

define('FORCE_SSL_ADMIN', true);

WordPress - Reverse Proxy HTTPS via HAProxy

Sauvegardez et le tour est joué, votre site WordPress doit fonctionner derrière le reverse proxy ! Ce qui s'applique à WordPress ne s'applique peut-être pas forcément à d'autres applications Web, et certainement pas à un site statique tout simple, mais c'est à connaître.

Désormais, les visiteurs du site it-connect.tech accèdent au site en HTTPS par l'intermédiaire du serveur HAProxy : mission accomplie.

The post PfSense : reverse proxy HTTPS avec HAProxy et ACME (Let’s Encrypt) first appeared on IT-Connect.

Une attaque massive cible 1,6 million de sites WordPress

13 décembre 2021 à 08:16

Ces derniers jours, les analystes de chez Wordfence ont détecté une attaque massive qui cible 1,6 million de sites WordPress, en s'appuyant sur un pool de 16 000 adresses IP pour effectuer l'attaque.

En l'espace de 36 heures, le système de protection Wordfence a bloqué 13,7 millions de tentatives d'attaques qui ciblaient 1,6 million de sites WordPress, mais pas n'importe lesquels ! Cette attaque cible particulièrement 4 extensions WordPress et 15 thèmes WordPress d'Epsilon Framework, car ils contiennent des vulnérabilités connues. Certaines de ces vulnérabilités sont corrigées depuis 2018 tandis que d'autres viennent d'être corrigées il y a quelques jours par les développeurs, et il reste encore un thème avec une vulnérabilité non corrigée.

Plus précisément, voici la liste des extensions touchées avec les numéros de version vulnérables :

  • PublishPress Capabilities <= 2.3
  • Kiwi Social Plugin <= 2.0.10
  • Pinterest Automatic <= 4.14.3
  • WordPress Automatic <= 3.53.2

Concernant les thèmes vulnérables, voici la liste également :

  • Shapely <=1.2.8
  • NewsMag <=2.4.1
  • Activello <=1.4.1
  • Illdy <=2.1.6
  • Allegiant <=1.2.5
  • Newspaper X <=1.3.1
  • Pixova Lite <=2.0.6
  • Brilliance <=1.2.9
  • MedZone Lite <=1.2.5
  • Regina Lite <=2.0.5
  • Transcend <=1.1.9
  • Affluent <1.1.0
  • Bonkers <=1.0.5
  • Antreas <=1.0.6
  • NatureMag Lite – Pas encore patché !

Lorsque cette attaque réussit, les pirates parviennent à modifier deux options au sein de WordPress : "users_can_register" qui permet d'ouvrir les inscriptions sur le site, et "default_role" pour choisir le rôle par défaut des nouveaux inscrits, en indiquant la valeur "Administrateurs". Cela permet à l'attaquant de créer un compte sur le site et de devenir administrateur du site WordPress !

Pour vérifier l'état de votre site, il suffit de vérifier l'état de ces deux options via le menu "Réglages" puis "Général". Si vous utilisez l'un de ces plugins et/ou l'un de ces thèmes, vous devez effectuer les mises à jour sans attendre ! Pour le thème "NatureMag Lite", Wordfence recommande de ne plus l'utiliser, car il n'y a pas encore de mise à jour et il n'y a pas de solution temporaire pour se protéger, si ce n'est peut-être de restreindre l'accès à l'interface d'administration depuis une adresse IP publique spécifique.

Enfin, voici le top des adresses IP utilisées dans le cadre de cette attaque, sur un total de 16 000.

Source

The post Une attaque massive cible 1,6 million de sites WordPress first appeared on IT-Connect.

Piratage GoDaddy : 1,2 million de comptes WordPress dans la nature !

25 novembre 2021 à 14:10

L'hébergeur américain GoDaddy a été victime d'un piratage, ce qui a donné lieu à une fuite de données importante : 1,2 million de comptes sont dans la nature. Que s'est-il passé ?

GoDaddy a été victime d'une intrusion et les pirates ont pu accéder à l'environnement Managed WordPress. Désormais, les vannes sont fermées depuis le mercredi 17 novembre suite à la découverte de l'intrusion, mais les pirates ont eu accès à des informations pendant plusieurs semaines : depuis le 6 septembre 2021, pour être précis.

Que contient cette fuite de données GoDaddy ?

Ce piratage a donné lieu à une fuite de données importante avec 1,2 million de comptes, tandis que GoDaddy compte environ 20 millions de clients dans le monde.

Au sein de cette fuite de données, on retrouve les numéros de client et les adresses e-mail associées. On retrouve aussi le mot de passe d'origine du compte "admin" de WordPress, renseigné au moment du provisionnement de l'application sur l'hébergement Web GoDaddy, est présent dans les données récupérées par les pirates.

GoDaddy précise que l'on peut aussi retrouver les noms d'utilisateur et mots de passe pour l'accès en FTP et à la base de données, ainsi que la clé privée SSL pour certains clients.

Par précaution, GoDaddy a réinitialisé les mots de passe compromis et renouvelé les certificats concernés par cette fuite de données. Les clients ont reçu un e-mail pour être avertis de la situation (voir l'e-mail reçu).

L'origine de cette attaque serait un mot de passe compromis, qui a permis à l'attaquant (ou aux attaquants) d'accéder au système d'approvisionnement des sites WordPress de l'hébergeur GoDaddy.

Source

The post Piratage GoDaddy : 1,2 million de comptes WordPress dans la nature ! first appeared on IT-Connect.

WordPress : des sites piratés, avec une demande de rançon à la clé !

17 novembre 2021 à 11:23

Depuis la semaine dernière, une nouvelle vague d'attaques touche les sites WordPress et elle aurait fait au moins 300 victimes jusqu'ici. Lorsque le site WordPress est hacké, une page s'affiche avec une demande de rançon de 0,1 bitcoin pour déchiffrer le contenu du site. Que se passe-t-il exactement ?

L'entreprise Sucuri a fait la découverte de cette nouvelle attaque à destination des sites WordPress, à la suite d'une sollicitation de la part d'un Webmaster victime de cette attaque.

Concrètement, certains webmasters ont eu la mauvaise surprise de découvrir une nouvelle page d'accueil sur leur site. En effet, le message "Site encrypted" s'affiche, accompagné par un compte à rebours de quelques jours et une adresse pour envoyer 0,1 Bitcoin afin de restaurer le site WordPress. Si l'on convertit cette somme en euros, cela correspond à un peu plus de 5 200 euros, ce qui n'est pas rien.

La bonne nouvelle, c'est que les équipes de chez Sucuri ont constaté que le site n'était pas chiffré ! À la place de ça, l'attaquant à simplement modifié le code d'un plug-in WordPress installé sur le site afin d'afficher la page d'alerte qui indique que le site est chiffré. En complément, l'ensemble des articles du site sont modifiés afin de définir l'état ("post_status") sur null, ce qui empêche l'affichage de l'article puisqu'il est dans un état inconnu.

En réalité, ce piratage  par un ransomware est une illusion dans le sens où le site n'est pas réellement chiffré, mais que le pirate cherche à tromper le Webmaster en l'incitant à payer la rançon de 0,1 Bitcoin. Sucuri estime qu'en supprimant le plug-in modifié par le pirate, en l'occurrence ici Directorist, et en exécutant une commande pour rectifier l'état des articles, le site peut revenir à son état normal.

En s'intéressant aux journaux du site, Sucuri a remarqué que le premier point où l'adresse IP de l'attaquant apparaissait était le panneau d'administration "wp-admin". On peut en déduire que l'attaquant s'est connecté en tant qu'admin sur le site, en réalisant une attaque par brute-force ou en achetant des identifiants via le dark web. Visiblement, l'attaquant n'a pas exploité une faille de sécurité dans un plug-in pour devenir admin du site. Quoi qu'il en soit, veillez à maintenir vos plug-ins et WordPress à jour.

Source

The post WordPress : des sites piratés, avec une demande de rançon à la clé ! first appeared on IT-Connect.

Comment ajouter l’authentification multifacteurs à WordPress ?

8 novembre 2021 à 10:00

I. Présentation

Dans ce tutoriel, nous allons voir comment ajouter l'authentification multifacteurs (MFA) à WordPress pour apporter une couche de sécurité supplémentaire. Le plug-in gratuit WP 2FA sera utilisé.

Pour renforcer la sécurité du formulaire de connexion WordPress, il y a plusieurs solutions et la bonne nouvelle c'est qu'elles sont cumulables. D'une part, vous pouvez mettre en place un plug-in pour bannir les adresses IP qui effectue des attaques par brute force, et d'autre part, vous pouvez mettre en place l'authentification multifacteurs sur votre site WordPress. De cette façon, il faudra saisir un code pour s'authentifier, en plus de l'habituel mot de passe.

Nous allons voir comment installer et configurer l'extension WP 2FA. Elle est totalement gratuite et va permettre de :

  • Définir un deuxième facteur d'authentification, avec un code reçu par e-mail ou généré sur une application (Microsoft Authenticator, Google Authenticator, FreeOTP, etc.)
  • Forcer l'activation du MFA sur tous les utilisateurs, uniquement sur certains utilisateurs ou certains rôles, ou laisser libre choix
  • Générer des codes de secours pour chaque utilisateur

Page du plug-in : WP 2FA

II. Authentification multifacteurs WordPress (MFA)

Je vous invite à vous connecter sur l'interface d'administration de WordPress, et sur la gauche, dans le menu "Extensions" cliquez sur "Ajouter". Ensuite, recherchez "WP 2FA" via la zone de recherche en haut à droite.

L'extension "WP 2FA - Two-factor authentication for WordPress" doit apparaître. Cliquez sur le bouton "Installer maintenant".

Installer l'extension WP 2FA
Installer l'extension WP 2FA

Dès lors que l'installation est réalisée, cliquez sur le bouton "Activer".

Un assistant de configuration s'exécute. Je vous invite à le suivre afin de configurer l'extension étape par étape. Cliquez sur le bouton "Let's get started!".

La première étape consiste à définir la ou les méthodes que vous souhaitez autoriser pour le second facteur. Voici les deux options possibles :

  • One-time code via 2FA App (TOTP) : activer ou désactiver l'utilisation des applications comme Google Authenticator, FreeOTP, Microsft Authenticator, etc... Je vous conseille d'activer cette option.
  • One-time code via e-mail (HOTP) : activer ou désactiver l'envoi d'un code de sécurité par e-mail en guise de second facteur. Je préfère désactiver cette option pour prioriser l'utilisation d'une application 2FA.

En complément, vous pouvez activer ou non la création de code de secours via l'option "Backup codes". Un code de secours peut être utilisé en remplacement du code généré par l'application 2FA par exemple.

Cliquez sur "Continue setup" pour passer à l'étape suivante.

Désormais, il faut choisir à qui vous souhaitez imposer l'authentification multifacteurs. Différentes options possibles :

  • All users : tous les utilisateurs de votre site doivent utiliser le MFA
  • Only for specific users and roles : forcer l'utilisation du MFA pour certains rôles et/ou certains utilisateurs
  • Do not enforce on any users : le MFA ne sera pas forcé, donc vous proposez l'option à vos utilisateurs, mais ils peuvent l'activer ou non

Dans l'exemple ci-dessous, je force le MFA uniquement pour les utilisateurs "Administrateurs" du site WordPress. C'est le minimum. Cliquez sur "Continue setup" une fois que le choix est fait.

Désormais, il faut choisir si l'on veut imposer la configuration du MFA dès maintenant aux utilisateurs (selon le choix de l'étape précédente) ou si on autorise une période de grâce (Give users a grace period to configure 2FA). Cliquez sur "All done".

Le temps que l'on y est, on va configurer le MFA sur le compte actuellement utilisé pour configurer le plug-in. Pour cela, cliquez sur "Configure 2FA now".

Prenez votre smartphone et ouvrez votre application 2FA. Si vous n'en avez pas, vous pouvez regarder la documentation officielle de WP 2FA pour en choisir une. Vous avez FreeOTP qui est très bien et publié par RedHat, ou sinon Google Authenticator et Microsoft Authenticator.

Pour ma part j'utilise FreeOTP (et l'application n'autorise par les copies d'écran). Il suffit d'appuyer sur le bouton en haut à droite de l'application pour scanner un nouveau code QR, et de scanner le code QR qui s'affiche sur l'interface WordPress.

Ensuite, depuis l'application, on peut générer un code et le saisir sur l'interface de WordPress pour finaliser la configuration du MFA pour mon utilisateur. Une fois que c'est fait, cliquez sur "Validate & Save Configuration".

Pour récupérer vos codes de secours dès maintenant, cliquez sur "Generate backup codes".

La liste des codes s'affiche à l'écran, pensez à la télécharger ou à l'imprimer.

La prochaine fois que je vais m'authentifier sur mon site WordPress avec cet utilisateur, il faudra saisir le mot de passe et ensuite générer un code avec l'application FreeOTP.

Authentification multifacteurs WordPress
Authentification multifacteurs WordPress

Voilà, l'authentification multifacteurs est en place sur votre site WordPress et votre compte actuel est déjà protégé !

III. Configuration du plugin WP 2FA

À tout moment, vous pouvez éditer la configuration du plugin WP 2FA, notamment pour activer ou désactiver une méthode d'authentification, mais aussi pour personnaliser le contenu de l'e-mail utilisé pour envoyer les codes (onglet "Email Settings & Templates").

Paramètres WP 2FA

Chaque utilisateur peut reconfigurer le MFA à partir de son profil : Modifier mon profil > Change 2FA Settings. Cela peut être utile pour changer d'application 2FA ou en cas de changement de smartphone, par exemple.

Dans le cas où vous n'avez plus de code de secours et que vous n'arrivez plus à vous authentifier avec votre application, il y a une solution : vous devez désactiver l'extension WP 2FA. Pour cela, accédez à votre serveur Web en ligne de commande et renommez le dossier de l'extension afin de la désactiver. Ainsi, vous allez pouvoir vous connecter uniquement avec le mot de passe le temps de remettre tout en ordre.

The post Comment ajouter l’authentification multifacteurs à WordPress ? first appeared on IT-Connect.
❌