FreshRSS

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

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

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

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

2 novembre 2021 à 10:30

I. Présentation

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

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

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

A. L'objectif du jour

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

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

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

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

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

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

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

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

Insérez ce petit bout de code :

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

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

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

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

III. Installation de CrowdSec sur Debian 11

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

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

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

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

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

On peut lister les collections avec la commande suivante :

cscli collections list

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

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

sudo cscli decisions list

IV. Mon serveur Web Apache + PHP vs Nikto

A. Premier scan avec Nikto

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

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

L'installation s'effectue très simplement :

sudo apt-get update
sudo apt-get install nikto

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

curl -I it-connect.tech

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

nikto -h it-connect.tech

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

sudo cscli decisions list

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

cscli alerts list

B. Installation de PHP Composer

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

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

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

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

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

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

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

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

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

Enfin, lancez l'installation de Composer :

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

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

composer

Vous devez obtenir ceci :

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

C. Mise en place du Bouncer PHP

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

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

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

sudo apt-get install git

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

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

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

cd cs-php-bouncer/

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

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

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

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

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

sudo systemctl reload apache2

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

sudo cscli bouncers list

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

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

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

curl -I it-connect.tech

Puis, on lance notre scan Nikto :

nikto -h it-connect.tech

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

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

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

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

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

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

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

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

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

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

sudo nano /etc/crowdsec/profiles.yaml

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

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

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

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

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

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

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

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

Au final, vous obtenez ceci :

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

sudo systemctl restart crowdsec

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

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

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

Nous allons utiliser le modèle de commande suivant :

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

Voici quelques exemples :

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

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

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

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

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

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

sudo cscli decisions list

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

VI. Conclusion

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

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

Pour finir, quelques liens :

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

Log4Shell : la faille de sécurité qui secoue Internet

13 décembre 2021 à 11:17

Une faille de sécurité critique a été découverte au sein de la bibliothèque de journalisation Apache Log4j. Baptisée "Log4Shell" est extrêmement dangereuse puisqu'elle permet d'exécuter du code à distance sans authentification et de façon très simple !

La vulnérabilité Log4Shell (appelée aussi Javageddon), identifiée avec la référence CVE-2021-44228, bénéficie d'une note maximale de 10/10, ce qui est une preuve de sa dangerosité. D'ailleurs, vendredi dernier le CERT-FR a publié une alerte à son sujet.

La bibliothèque de journalisation Apache Log4j est utilisée par Java donc on l'a retrouve sur de très nombreuses plateformes dont Tomcat, et au sein de beaucoup d'entreprises y compris des géants de l'Internet et de l'industrie. En effet, parmi les entreprises vulnérables, on peut trouver Apple, Steam, Twitter, Amazon, Tesla, Minecraft, VMware, Webex, etc... Preuve que cette bibliothèque est très populaire (voir ce lien). Clairement, c'est la panique !

Log4Shell : une énorme menace !

Imaginez un site Internet, avec un formulaire (par exemple) et derrière un serveur Web où la bibliothèque Log4j est utilisée. À partir de là, l'attaquant peut exécuter une simple requête sur le serveur Web en intégrant une chaîne de caractères spécifiques. Lorsque cette chaîne de caractères sera traitée par Log4j (au moment de journaliser la requête), il va exécuter la requête malveillante envoyée par l'attaquant. Résultat, un malware peut être installé sur le serveur ciblé.

Si l'on regarde les statistiques de CloudFlare, on peut voir qu'il y a énormément d'attaques en cours (et bloquées par leur système) :

Par mesure de sécurité, certains préfèrent mettre le site hors ligne, c'est notamment le cas au Québec où près de 4 000 sites et services gouvernementaux ont été mis hors ligne par sécurité.

À propos de cette faille, il faut savoir une chose : ce n'est pas parce que vous n'utilisez pas Java que vous n'êtes pas vulnérable. En effet, de nombreux frameworks s'appuient sur cette bibliothèque donc elle peut être utilisée par ce biais. C'est le cas de Flink, Druid ou encore Apache Struts2. Même la NSA utilise un framework qui intègre cette bibliothèque, au sein de son outil GHIDRA comme le rapport Rob Joyce, directeur de la cybersécurité au sein de la NSA.

Quant à la date de détection de cette faille de sécurité, c'est un peu flou. L'équipe de sécurité d'Alibaba Cloud aurait notifié cette faille de sécurité à Apache le 24 novembre 2021. Néanmoins, certaines personnes évoquent l'utilisation de cette faille de sécurité lors de l'événement BlackHat USA de 2016.

Comment se protéger de la vulnérabilité Log4Shell ?

Pour faire simple, toutes les versions de Log4J sont concernées par cette faille de sécurité ! Enfin, presque car la version 2.15.0 qui vient de sortir corrige cette faille justement !

Se mettre à jour, c'est facile à dire, mais pas toujours simple à appliquer : tout dépend aussi de la version dans laquelle on se situe actuellement. Même si la mise à jour est fortement recommandée (et dès que possible), il existe quelques solutions alternatives.

Voici ce que nous dit le CERT-FR à ce sujet :

  • Log4j versions 2.7.0 et ultérieures : "il est possible de se prémunir contre toute attaque en modifiant le format des évènements à journaliser avec la syntaxe %m{nolookups} pour les données qui seraient fournies par l'utilisateur. Cette modification impose de modifier le fichier de configuration de log4j pour produire une nouvelle version de l'application. Cela requiert donc d'effectuer de nouveau les étapes de validation technique et fonctionnelle avant le déploiement de cette nouvelle version."

Mais aussi :

  • Log4j version 2.10.0 et ultérieures : "il est également possible de se prémunir contre toute attaque en modifiant le paramètre de configuration log4j2.formatMsgNoLookups à la valeur true, par exemple lors du lancement de la machine virtuelle Java avec l'option -Dlog4j2.formatMsgNoLookups=true. Une autre alternative consiste à supprimer la classe JndiLookup dans le paramètre classpath pour éliminer le vecteur principal d'attaque (les chercheurs n'excluent pas l'existence d'un autre vecteur d'attaque)."

Il existe une petite subtilité au sujet de la version 1.X de Log4j. En effet, elle est vulnérable seulement si le composant JMS Appender est configuré pour prendre en compte JNDI. Autrement dit, cette version est vulnérable seulement avec des configurations spécifiques.

Note : si vous utilisez CrowdSec, sachez qu'un scénario de détection pour Log4Shell existe et qu'il est présent au sein de la collection "http-cve" (que vous devez mettre à jour si vous l'utilisez déjà).

Pour tester votre application, vous pouvez utiliser ce site Web : CanaryTokens.org

The post Log4Shell : la faille de sécurité qui secoue Internet first appeared on IT-Connect.

Minecraft et de nombreuses autres applications victimes d’une vulnérabilité critique

13 décembre 2021 à 12:23
Par : UnderNews

Une faille Zero Day critique a été identifiée dans Apache Log4j par un membre de l’équipe sécurité d’Alibaba Cloud. Cette vulnérabilité permet  à des attaquants de réaliser des attaques d'exécution de code à distance.

The post Minecraft et de nombreuses autres applications victimes d’une vulnérabilité critique first appeared on UnderNews.

Commentaire de Kaspersky concernant la vulnérabilité Log4shell

13 décembre 2021 à 14:19
Par : UnderNews

La semaine dernière, une nouvelle vulnérabilité critique particulièrement dangereuse a été découverte dans la bibliothèque Apached Log4j. CVE-2021-44228 ou Log4Shell ou LogJam, est ce que l'on appelle une vulnérabilité de classe RCE (Remote Code Execution), ce qui signifie que si elle est exploitée sur un serveur vulnérable, les attaquants peuvent exécuter du code arbitrairement et potentiellement prendre le contrôle total d'un système. La CVE a été classée 10 sur 10 en termes de gravité.

The post Commentaire de Kaspersky concernant la vulnérabilité Log4shell first appeared on UnderNews.

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.

Vulnérabilité d’Apache Log4j : que faire ?

15 décembre 2021 à 10:56
Par : UnderNews

Depuis quelques jours, des cybercriminels exploitent massivement une vulnérabilité d’Apache Log4j, un utilitaire de journalisation basé sur Java utilisé par des millions d’entreprises.

The post Vulnérabilité d’Apache Log4j : que faire ? first appeared on UnderNews.

Bulletin d’actualité du CERT-FR – 14/12/2021

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

L’article Bulletin d’actualité du CERT-FR – 14/12/2021 est apparu en premier sur Tech2Tech | News, Astuces, Tutos, Vidéos autour de l'informatique.

❌