Par défaut, Plesk utilise NGINX en Reverse proxy d’Apache. Mais cette configuration par défaut est-elle optimale ? Quel est l’impact sur les performances ? Pour répondre à ces questions en tant qu’hébergeur web utilisant Plesk, j’ai effectué des tests de charge sur un VPS Hetzner (8 cœurs AMD Epyc) pour mesurer l’impact de l’activation d’NGINX comme reverse proxy sur les performances globales.
Sommaire
Contexte et Configuration
Dans le cadre de ce benchmark, j’ai comparé les performances du serveur en activant et en désactivant NGINX. J’ai également testé l’activation du cache de NGINX (et cela change tout !).
Les tests de charge ont été réalisés avec ApacheBench (ab) en envoyant localement 5000 requêtes avec une concurrence de 200 requêtes simultanées. Ce pour que le test dure suffisamment longtemps et que cela limite la marge d’erreur. Il est à noter que le site de test est très léger et performant par rapport à la moyenne, avec seulement 50 à 80ms de TTFB (temps de réponse).
Voici les configurations principales :
Serveur : VPS Hetzner 8 cœurs (AMD Epyc)
Serveur Web : Plesk 18.0.65 avec Apache + NGINX comme reverse proxy
Site de test : LRob.fr un site WordPress FSE, thème Twenty Twenty-Four avec cache Breeze
Commandes de test : ab -n 5000 -c 200 https://portail.lrob.fr/
Configurations NGINX
Configuration NGINX par défaut (Plesk 18.0.65)Configuration NGINX personnalisée
Avec la configuration par défaut (NGINX activé), le serveur fonctionne correctement, mais un bottleneck du CPU a été constaté. L’utilisation CPU globale (tous les cœurs) ne dépasse pas les 85 % lors du test de charge, avec un process NGINX qui est bloqué également autour de 85%.
Sans NGINX, Apache gère directement les requêtes. Les résultats montrent une amélioration de +33% des performances.
Mais la surprise est lorsque le cache NGINX est activé et gère directement les fichiers statiques. On observe +66% de gains de performances ! Et ce n’est pas tout : on observé également une réduction d’utilisation des cœurs CPU à 30%, laissant une importante marge de CPU disponible pour d’autres usages essentiels comme PHP-FPM ou MariaDB/MySQL. NGINX est cependant limité à 99% d’utilisation CPU (donc un cœur) : Peut-être est-il possible d’étendre son utilisation à plusieurs cœurs CPU et de décupler encore les résultats. Lors du test, j’avais encore 5 à 6 cœurs CPU disponibles, de quoi potentiellement multiplier ce résultat par 2 ou 3. Cela mérite d’être étudié ultérieurement.
Autres considérations concernant NGINX et Plesk
Plesk favorise l’utilisation d’NGINX avec plusieurs avantages qui peuvent justifier son activation :
Génération de certificats améliorée : Plesk permet par exemple de générer un certificat pour le webmail seulement, uniquement lorsque NGINX est en place.
Sécurité : Des fonctions comme OCSP Stapling sont dispo en 1 clic, uniquement avec NGINX
D’autres avantages m’échappent peut-être. L’inconvénient est bien-sûr que vous avez alors deux applicatifs web qui augmentent légèrement la complexité de l’installation.
Conclusion
L’utilisation de NGINX comme reverse proxy sous Plesk peut être extrêmement puissante pour des sites statiques, ou lorsque combiné à un bon système de cache (voir comparatif des cache pour WordPress). Mais selon mon test, il est indispensable de modifier les réglages NGINX pour obtenir un gain de performances plutôt qu’une réduction en comparaison à Apache seul.
Par ailleurs, les résultats peuvent varier fortement en fonction de vos applicatifs finaux (vos sites) et de leur cache. Utilisez si besoin ma méthodologie du test pour faire vos propres mesures et comparer. A ce sujet, vos retours m’intéressent : partagez vos résultats en commentaires !
Les mises à jour de WordPress, qu’elles soient manuelles ou automatiques, suscitent toujours des interrogations, voire des craintes chez les webmasters. Ces mises à jour sont nécessaires pour la sécurité et l’évolutivité de votre site, mais elles comportent aussi des risques. Alors faut-il activer les mises à jour automatiques WordPress ? Explorons les enjeux.
Sommaire
Mises à jour manuelles
Quel que soit votre mode de mise à jour (manuelle ou automatique), les risques existent.
Globalement, peu importe si la mise à jour est automatique ou manuelle, vous rencontrerez parfois des soucis à traiter, tôt ou tard.
Quels sont les risques des mises à jour de WordPress ?
Du simple bug à l’inaccessibilité du site, voici les problèmes les plus fréquents :
Intervention nécessaire : Parfois, une mise à jour nécessite une intervention manuelle pour ajuster certains paramètres ou configurations.
Un plugin ou un thème présente un bug : Une mise à jour peut introduire un dysfonctionnement, surtout si le plugin ou le thème n’est plus maintenu par ses développeurs.
Incompatibilité de versions : Un plugin ou un « addon » dépend d’un autre plugin et peut ne pas être mis à jour aussi fréquemment, créant des conflits.
Comment réduire le risque
Pour éviter ces risques et désagréments, un processus de staging est nécessaire : cela consiste à essayer toute mise à jour dans un environnement de test avant de l’appliquer en production. Cependant, cette pratique nécessite du temps et des ressources conséquents, ce qui n’est pas envisageable pour les sites les plus modestes.
Mises à jour automatiques
Quels sont les avantages des mises à jour automatiques WordPress ?
Passer aux mises à jour automatiques offre un gain de temps et de sécurité.
Cela se fait en quelques clics depuis votre panneau de contrôle Plesk. Vous avez la possibilité de désactiver la mise à jour automatique de tout plugin qui poserait souci.
1. Gain de sécurité
En activant les mises à jour automatiques, votre site est protégé contre les dernières failles de sécurité identifiées dès leur correction. Cela permet de limiter les risques de piratage et de maintenir votre site en sécurité sans intervention manuelle systématique.
2. Économie de temps et d’énergie
Les mises à jour automatiques réduisent la nécessité d’une intervention fréquente. Au lieu de vérifier manuellement les nouvelles versions de plugins ou de WordPress, vous économisez du temps précieux qui peut être réinvesti dans des tâches à plus forte valeur ajoutée.
3. Des bugs plus mineurs
Grâce à une mise à jour régulière, les bugs rencontrés seront globalement plus mineurs, tout simplement car les changements sont plus mineurs. De plus, le diagnostic sera plus simple : si un plugin pose problème, vous trouverez rapidement parmi les quelques scripts récemment modifiés, lequel pose problème, tandis que si tous les plugins ont reçu une mise à jour, vous devrez tous les tester un par un.
Pré-requis des mises à jour automatiques
En mise à jour automatique, il il y a des pré-requis encore plus importants qu’en MAJ manuelle.
1. Sauvegardes automatisées et externalisées
Les sauvegardes sont indispensables dans certains cas. Il est donc important d’avoir des sauvegardes régulières, externalisées, avec une rétention longue. Ces sauvegardes doivent être sélectivement et facilement restaurables.
Sur les hébergements web LRob, nous effectuons une sauvegarde hébergeur remontant jusqu’à 1 an en arrière.
2. Monitoring du site
Vous devez monitorer la bonne réponse de vos sites et faire une vérification manuelle de temps en temps.
Vous devez réagir rapidement si besoin, pour éviter qu’un souci ne dure sur votre site. Et vous devez avoir les bons outils pour diagnostiquer (accès aux logs, phpMyAdmin, explorateur de fichiers, désactivation des plugins depuis le panel hébergeur – tout cela est disponible sur les hébergements web LRob). Votre support LRob peut vous aider à diagnostiquer et résoudre votre souci, en s’impliquant dans la recherche et le diagnostic WordPress.
Que faire en cas de problème suite à une mise à jour WordPress ?
Si une mise à jour cause un problème, il faut réagir vite et bien :
Consultez les logs : Les journaux du serveur peuvent indiquer très rapidement la source du problème.
Désactivez le plugin fautif : Si vous pouvez vous en passer, désactivez le plugin concerné.
Adaptez les réglages : Parfois, une simple modification de réglage suffit pour résoudre l’incident.
Support des développeurs : Contactez le support du plugin ou du thème concerné pour remonter le problème et obtenir de l’aide.
Restaurez une sauvegarde : Si le problème est critique et n’a pas de solution immédiate, alors une restauration de sauvegarde est peut-être nécessaire solution. Dans ce cas, il peut être judicieux de suspendre temporairement les mises à jour (automatiques) jusqu’à ce que la solution soit trouvée. Si vous n’avez pas de sauvegarde de votre côté, votre support LRob peut restaurer sa sauvegarde hébergeur.
Contactez votre support LRob : Nous gérons de nombreux sites, il est fort probable que nous ayons déjà passé des heures à résoudre un souci similaire ou que notre expérience nous permettant de trouver votre solution très rapidement. Nous sommes toujours heureux de vous aider à gagner du temps !
En résumé : mise à jour manuelle ou automatique ?
Mise à jour manuelle
En MAJ manuelle, vous retardez l’apparition des problèmes que vous devrez résoudre tôt ou tard, tout en vous exposant à davantage de failles de sécurité.
Ce choix peut convenir aux sites très complexes, soumis à de potentiels bugs et nécessitant un suivi plus extensif.
Mise à jour automatique
En MAJ auto vous risquez un bug temporaire, vous devez prendre en charge les (rares) problèmes dès leur apparition.
L’exception : les sites complexes
L’exception étant les gros sites complexes, tels que des WooCommerce avec du dev custom, où dans ce cas, il vaut mieux faire un staging et tester chaque mise à jour (maxi tous les 3 mois, ou lorsqu’une faille de sécurité connue apparaît), moyennant un forfait de maintenance approprié.
Avec un service d’hébergement professionnel, tel que celui proposé par LRob, vous pouvez bénéficier d’un support technique et de sauvegardes prolongées, jusqu’à un an en arrière, pour sécuriser votre site face aux imprévus.
Conclusion
Globalement, la mise à jour automatique devrait selon nous être votre choix par défaut car la sécurité prime sur la fonctionnalité. Si vous êtes « agile », alors cela ne devrait pas poser de souci. Car mieux vaut avoir un bug à résoudre qu’un site piraté et toutes ses conséquences à traiter. Les petites et moyennes structures tireront souvent plus de bénéfices des mises à jour automatiques, tandis que les sites plus complexes requièrent une gestion de maintenance spécifique et approfondie.
Si vous êtes prêt à adopter les mises à jour automatiques, assurez-vous d’avoir des sauvegardes et une stratégie de monitoring en place pour gérer efficacement les rares incidents qui pourraient survenir.
👉 Pour une gestion simplifiée de votre site WordPress, découvrez les offres d’hébergement LRob et bénéficiez de notre expertise pour éviter ou résoudre les soucis techniques et garder votre site en ligne, sécurisé et performant.
Découvrez WPMasterToolKit : le plugin indispensable pour vous simplifier la vie et alléger vos sites WordPress.
Ce plugin made-in France, développé par le talentueux Ludwig YOU de Webdeclic, regroupe une multitude de fonctionnalités essentielles de WordPress, que vous pouvez chacune activer en un clic. Le tout en une seule extension : de quoi simplifier votre gestion tout en accélérant votre site ! 🚀
Un plugin vraiment différent
WPMasterToolKit est simple et flexible. Avec déjà plus de 83 fonctionnalités gratuites activables, ce plugin vous permet de remplacer d’innombrables extensions par une seule.
Ce qui rend WPMasterToolKit unique, outre le fait d’être français, c’est sa capacité à activer uniquement les fonctionnalités dont vous avez besoin, sans alourdir inutilement votre site. Là où d’autres extensions sont monolithiques, chargeant des scripts inutiles même lorsque vous ne les utilisez pas, WPMasterToolKit est conçu pour être léger et efficace.
Si une fonctionnalité est désactivée, le programme associé ne se charge pas du tout. Ainsi, vous allégez l’utilisation de ressources de votre site et améliorez ses performances, en ne chargeant que les fonctionnalités dont vous avez réellement besoin.
D’autres fonctionnalités sont sur le feu, et quelques unes sont disponibles en premium pour pérenniser le projet.
Le développeur, Ludwig YOU, est très à l’écoute des suggestions et améliore activement son plugin. Avec notamment l’ajout récent d’un onglet permettant de voir d’un coup d’œil les fonctionnalités actives.
Fonctionnalités phares de WPMasterToolKit
WPMasterToolkit : Modules actifs sur le site LRob.fr
Voici quelques-unes de mes fonctionnalités préférées jusqu’à présent :
1. Cacher la version de WordPress
Cacher la version de WordPress affichée dans le code source est une excellente mesure de sécurité. Cela réduit les chances que votre site soit ciblé par des attaques automatisées visant des versions spécifiques de WordPress.
2. Limitation des révisions
La gestion des révisions de contenu est un point souvent négligé qui peut rapidement surcharger la base de données. WPMasterToolKit permet de limiter le nombre de révisions par article, ce qui aide à garder la base de données propre et performante.
3. Désactiver le support des emojis
Les emojis sont utiles pour certains sites, mais la plupart des navigateurs modernes supportent déjà nativement ces symboles. Désactiver leur prise en charge au niveau de WordPress permet d’alléger le chargement des pages.
4. Désactiver les balises Really Simple Discovery (RSD)
En désactivant le chargement des balises RSD (et des scripts comme Dashicons pour les visiteurs non connectés), vous pouvez réduire le temps de chargement de vos pages publiques, particulièrement si votre site n’utilise pas de services tiers qui nécessitent ces éléments.
5. Désactiver jQuery Migrate
Si votre site utilise des versions récentes de jQuery, le script jQuery Migrate devient inutile et peut être désactivé pour améliorer la vitesse de chargement des pages.
D’autres fonctionnalités intéressantes
Outre ces fonctionnalités favorites, WPMasterToolKit propose également une panoplie d’outils qui facilitent la gestion quotidienne de votre site. Parmi les plus populaires, vous trouverez :
Auto-publication des articles manqués : publie automatiquement les articles qui ont raté leur date de planification.
Gestion du SMTP : Se connecte à un serveur SMTP tiers pour relayer plus fiablement vos emails.
Désactivation des API REST pour les utilisateurs non authentifiés : améliore la sécurité en limitant l’accès aux données via l’API REST.
Ban d’emails : bloque la création de comptes utilisateurs avec des adresses email temporaires ou non autorisées.
Mode Maintenance : affiche une page de maintenance personnalisée pendant vos travaux sans gêner les administrateurs.
Redirection des 404 vers la page d’accueil : améliore l’expérience utilisateur en redirigeant les pages inexistantes vers la page d’accueil.
Et bien d’autres encore… L’idéal reste d’explorer et de tester par vous-même ! Qui sait, vous pourriez remplacer des dizaines de plugins !
Une boîte à outils WordPress essentielle qui gagnera à être connue
Avec ses multiples fonctionnalités personnalisables, vous avez tout sous la main pour mieux personnaliser et contrôler votre site, améliorer ses performances et renforcer sa sécurité.
Le plugin, encore récent compte à l’heure où j’écris ces lignes +500 installations active. Pour moi, ce plugin est un véritable game changer et je suis convaincu qu’il dépassera le millier bien avant la fin de l’année, et que sa popularité explosera ensuite.
Trouver le meilleur plugin de cache n’est pas évident. Il faut le tester, mesurer les performances, connaître son support à long terme…
Alors quel est le cache le plus rapide ? Quel est le meilleur plugin de cache ? Lesquels sont pratiques et complets, lesquels sont performants ? A-t-on besoin de payer pour un bon plugin de cache ?
Aujourd’hui, on tente de répondre à ces questions avec des mesures indépendantes et les plus objectives possibles. Le test est un peu « meta » car il porte sur essai sur lrob.fr, une vitrine/blog réalisée avec FSE (full site editing). Un site standard et léger.
Sommaire
Introduction
L’objectif d’un plugin de cache : tomber sous 200ms de temps de réponse ou « TTFB » (Time To First Byte, 200ms est le temps maximum préconisé par Google PageSpeed Insights).
Mais tous les cache ne se valent pas, comme le rappelle Yoan De Macedo dans son article de blog. Certains sont plus performants et d’autres dégradent même parfois les performances. Alors pour vraiment choisir le meilleur cache, il reste nécessaire d’en tester plusieurs sur son propre site et de mesurer précisément les résultats. En raison de la variabilité du temps de réponse, il est important de faire des tests sur une certaine durée et de moyenner les résultats. Cela peut cependant être fastidieux, alors vous pouvez choisir de vous baser sur ce test comparatif pour commencer à y voir plus clair.
On rappelle aussi que le cache ne fait pas tout. Le cache permet d’alléger les ressources serveur, mais votre site doit être optimisé à la base. Sinon cela s’appelle un « cache-misère ». Privilégiez donc les plugins et thèmes légers et bien optimisés pour éviter les mauvaises surprises. Le cache sera alors la cerise sur le gâteau.
Plugins testés
Je me suis basé sur un « top » des plugins de cache ainsi que sur mon expérience des plugins réellement rencontrés chez les différents clients hébergés pour établir cette liste des plugins à tester :
Ce test réalisé par LRob n’est aucunement sponsorisé par un quelconque plugin de cache. Il a vocation à être le plus objectif possible. Cependant, ce test n’est que le reflet de lui-même et de notre avis qui ne saurait être parfaitement objectif et n’a donc pas vocation à produire des vérités générales. LRob est un hébergeur web indépendant spécialiste de WordPress.
Détails du site web
Le test est réalisé sur https://portail.lrob.fr/. La fonction WP-Cron est désactivée et est exécutée directement par le serveur toutes les 4 minutes. Le site tourne sous PHP 8.3.12 en FPM dédié derrière Apache 2, avec MariaDB 11.4. Redis server est également disponible sur le serveur hôte (version 5:6.0.16).
Thème
Le site est réalisé avec FSE et le thème Twenty Twenty-Four
Plugins
Le site comporte 17 plugins actifs au moment du test (sans compter le plugin de cache testé) :
Voir la liste des plugins
Comment Blacklist Updater
Complianz | GDPR/CCPA Cookie Consent
Connect Matomo
Easy WP SMTP
hCaptcha for WP
Insert PHP Code Snippet
Optimize Database after Deleting Revisions
Rank Math SEO
Regenerate Thumbnails
Simple Local Avatars
Site Reviews
Social Sharing Block
TranslatePress – Developer
TranslatePress – Multilingual
Update URLs
WPForms Lite
WPMasterToolKit
Mesures et détails
La mesure du temps de réponse est effectuée avec Uptime Kuma sur un serveur chez PulseHeberg en Suisse (Lausanne), qui fournit cette moyenne. Le serveur en production est situé en Allemagne chez Hetzner à Falkenstein.
Chaque plugin est testé successivement, avec une mesure toutes les 20 secondes pendant 5 minutes ou plus (parfois je suis allé me faire un café entre temps), soit minimum 15 mesures pour obtenir une moyenne cohérente.
Entre chaque test, les valeurs enregistrées d’Uptime Kuma sont effacées après une première mesure une fois que le cache est mis en place; le dossier de cache est supprimé et il a été vérifié que le .htaccess et wp-config.php sont bien exempts de toute trace du précédent plugin.
Limites du protocole
Le test est fait sur un serveur en production, générant une variabilité des résultats légèrement supérieure à celle observée sur un serveur sans activité. Cependant, l’utilisation serveur est très modérée au moment du test et la variabilité est compensée par une série de plus de 15 mesures à chaque fois qui permet de moyenner les résultats. Le but n’est pas d’avoir la valeur à la milliseconde près, mais d’obtenir un ordre de grandeur.
Par ailleurs, le test est fait sur un site spécifique et ne peut pas être extrapolé à l’ensemble des sites : chaque site est différent et régira différemment à certains plugins (en particulier les boutiques). Mais si votre site est fait avec le thème Twenty Twenty-Four ou un autre thème FSE (Full Site Editing), alors il y a fort à parier que vos résultats soient similaires.
Tests et Benchmarks
Baseline – Test contrôle : Réponse sans plugin de cache
Sans aucun plugin de cache, le site répond en moyenne en 379ms avec une faible variabilité. Cette valeur est relativement faible de base, puisque les sites faits avec des builders peuvent facilement prendre 2 à 4x ce temps de réponse.
Temps de réponse sans cache
Voyons comment s’en sortent les différents plugins de cache pour améliorer ce temps de réponse.
Autoptimize
Autoptimize Réglages 1Autoptimize Réglages 2Temps de réponse Autoptimize : 379ms
Réponse moyenne : 379ms
Le temps de réponse est identique au site sans cache. Et pour cause, la fonction de cache de Autoptimize n’est en fait disponible qu’avec le plugin payant. Autrement dit, vous n’accélérerez pas votre site en version gratuite avec ce plugin. Dommage.
Cependant, comme le précise le développeur Simon JANVIER, Autoptimize, en version gratuite, est davantage utile pour la concaténation et minification intelligente des scripts. Sur ce point, il peut alléger votre site, mais cela n’améliorera pas le TTFB (temps de réponse) de votre site.
Breeze
Contrairement à ce que je pensais initialement, Breeze n’est pas réservé à Cloudways ou à Varnish, il fonctionne également sur un système classique. Je l’ajoute donc à ce test et je remercie Michael GOUT d’avoir porté ce plugin à mon attention.
Réglages Breeze 1Réglages Breeze 2
Temps de réponse Breeze : 98ms
Réponse moyenne : 98ms
Le résultat est bluffant : on tombe sous les 100ms avec une très bonne stabilité des temps de réponse ! Je découvre ce plugin et j’en tombe de ma chaise !
J’émets une petite réserve sur la compatibilité du plugin avec tous les sites en raison des commentaires sur wordpress.org. A la lecture de ces commentaires, il semble que son utilisation pourrait poser quelques soucis avec les sites les plus dynamiques ou complexes, comme les e-commerce WooCommerce.
Pour le reste, il semble être un excellent choix à ne surtout pas manquer.
Cachify
Cachify propose par défaut une mise en cache en base de données et supporte également un cache par fichiers et par Redis. Nous avons testé le cache par défaut et Redis. En dehors de cela, très peu de réglages nous sont disponibles.
Les résultats sont similaires entre le cache « Database » et Redis, on est dans la marge d’erreur. Les résultats semblent cependant plus stables avec Redis. Le résultat dépasse dans tous les cas les 200ms escomptées, ce qui est donc décevant. Ce plugin ne peut pas vraiment être recommandé.
LiteSpeed Cache
LiteSpeed Cache a beaucoup fait parler de lui récemment pour ses failles de sécurité. Le plugin prétend correspondre également à un serveur Apache. Alors comment s’en sort-il en pratique ?
Un résultat décevant pour LiteSpeed cache sur notre configuration de test, puisque le site est dans la marge d’erreur du temps de réponse original du site, sans cache.
Et pour cause, comme le relève Louis Chance, LiteSpeed, comme son nom l’indique, n’apporte aucun cache sur un serveur Apache ! Il faut forcément un serveur LiteSpeed disponible. Impossible de recommander ce plugin si vous tournez sous Apache, étant donné les performances obtenues et les multiples failles de sécurité récentes.
W3 Total Cache
W3 Total Cache offre un assistant de configuration et de nombreux réglages. C’est le plugin gratuit le plus complet que je connaisse. Il supporte différents types de cache dont Redis. Ici, la minification a été activée, ce qui peut augmenter légèrement le temps de réponse mesuré mais offre de meilleures performances pour les visiteurs à la connexion plus lente (mobiles, ADSL, etc.).
Réglages W3 Total Cache 1Réglages W3 Total Cache 2Réglages W3 Total Cache 3Réglages W3 Total Cache 4Réglages Minifcation W3 Total CacheTemps de réponse W3 Total Cache : 159ms
Réponse moyenne : 159ms
Enfin un résultat sous les 200ms ! Avec Redis, donc en évitant des milliers de fichiers de cache. Et un grand contrôle sur les réglages et des options comme le Lazy Load des images, et la désactivation de certains scripts optionnels de WordPress. Sa configuration versatile permettra de s’adapter plus précisément à chaque site : vous pourrez mesurer les performances obtenues avec différents réglages et choisir les plus pertinents pour votre site spécifique.
Par ailleurs, les autres types de cache disponibles sont également performants, bien que non testés aujourd’hui, les résultats sont assez similaires quel que soit le type de cache choisi.
Ce plugin n’a jamais déçu selon notre expérience est donc tout à fait recommandable. (C’est même le choix de LRob.fr)
WP Fastest Cache
Ce plugin offre des options intéressantes en version gratuite. Certaines options offertes gratuitement avec W3 Total Cache manquent cependant à l’appel.
Mais le plus important aujourd’hui : ce plugin porte-t-il bien son nom, en étant réellement le plus rapide ?
Ce plugin porte assez bien son nom, c’est effectivement l’un des plus rapide testés ! Sur notre test, Breeze arrive cependant en tête.
Chez LRob, nous avons vu plusieurs blogs divers et variés obtenir de très bons résultats avec ce plugin. Il n’a jamais déçu, et nous le recommandons sans hésiter.
WP-Optimize
WP-Optimize n’offre que très peu de réglages de cache. Car en réalité, sa fonction première semble plutôt être le nettoyage de la base de données. Alors comment s’en sort-il en cache ?
Réglages WP-OptimizeTemps de réponse WP-Optimize : 152ms
La variabilité du temps de réponse est trop élevée à notre goût avec des réponses oscillant entre 132 et 180ms.
Néanmoins, la moyenne reste très bonne avec 152ms. Une bonne surprise.
Nous ne sommes pas du tout rassurés par cette variabilité et ne recommandons donc pas ce plugin en tant que cache. D’autant plus que nous avons déjà observé des sites plus lents avec ce plugin que sans… A utiliser donc avec précaution en tant que cache.
Solid Performance
En bonus, je vous propose de tester un nouveau plugin de cache, Solid Performance, qui semble prometteur. (merci à Julien ROUSSEL pour la recommandation).
Réglages Solid PerformanceTemps de réponse Solid Performance : 155ms
Réponse moyenne : 155ms
Si celui-ci ne fournit strictement aucun réglage, son temps de réponse mesuré figure parmi les meilleurs de ce test. De quoi potentiellement satisfaire ceux qui n’ont pas envie de faire le moindre réglage. Le plugin étant jeune, il n’a pas encore été éprouvé, néanmoins un plugin de cache se change facilement si besoin dans la plupart des cas, il n’y a donc pas trop de risque à l’essayer si le cœur vous en dit !
Résumé des résultats et conclusion
Plugin
Réponse moyenne (ms)
Pourcentage (lower is better)
Baseline (pas de cache)
379
100%
Autoptimize
379
100%
Breeze 🥇
98
25.8%
Cachify Database
257
67.8%
Cachify Redis
263
69.4%
LiteSpeed
376
99.2%
W3 Total Cache Redis 🥉
159
41.9%
WP Fastest Cache 🥈
123
32.4%
WP-Optimize
152
40.1%
Solid Performance
155
40.9%
Nous pouvons sans hésiter recommander Breeze, WP Fastest Cache et W3 Total Cache qui sont tous les trois excellents. Ils proposent de très bon temps de réponse avec suffisamment de réglages, même en version gratuite. A noter toutefois que Breeze pourrait poser quelques soucis sur certains sites. Aussi, W3 est toutefois un peu plus complet en gratuit que WP Fastest Cache, raison pour laquelle il a été choisi pour LRob.fr, mais Breeze pourrait potentiellement le remplacer à terme, car il fournit presque autant de fonctionnalités tout en étant plus simple d’utilisation.
En résumé, selon notre test :
Choisissez Breeze pour la performance max, plutôt pour les sites vitrine
Choisissez W3 Total Cache pour le plus haut niveau de personnalisation ou si votre hôte supporte Redis (c’est le cas des hébergements LRob)
Choisissez WP Fastest Cache pour d’excellentes performances sans configuration
Mention pour WP-Optimize qui malgré son manque de réglages et sa grande variabilité de temps de réponse montre un temps de réponse moyen tout à fait correct. Mention également pour Solid Performance qui, nouvel arrivant, porte bien son nom et semble prometteur sans pour autant révolutionner quoi que ce soit, en l’état, dû à son manque de réglages. Cachify montre des réglages et des performances inférieures aux autres plugins. Nous ne pouvons pas nous prononcer sur LiteSpeed dans notre configuration Apache (si ce n’est que son intérêt est donc très limité dans ce type de configuration). Autoptimize enfin, n’apporte aucune amélioration sur les temps de chargement et est donc totalement inutile à cet effet, selon nos mesures, mais pourrait être utilisé en conjonction avec un plugin de cache pour réduire le nombre de fichiers.
Vu les bons résultats obtenus avec ces plugins gratuits, il ne semble donc pas indispensable de payer pour un plugin de cache si vous n’avez pas besoin des fonctions additionnelles proposées. Nous pourrions cependant tester les versions payantes dans un futur article, si cela vous intéresse.
Comme tous les 6 mois, Nextcloud vient de sortir sa nouvelle version majeure. Les notes de mises à jour officielles sont assez limitées et personne n’a envie de lire le changelog complet… Avec 2.363 changements cumulés sur Nextcloud 30.0.0 et 30.0.1.
Correctifs, nouveautés, améliorations, mises à jour de dépendances, etc. Tout cela est assez complexe à analyser et résumer. Heureusement, ChatGPT peut nous résumer et mettre tout ça en forme (plus de 2.400 lignes de texte et 172.879 caractères).
Alors pour gagner des heures dans votre vie, voici le résumé ChatGPT de ce qu’il faut retenir des changelogs Nextcloud 30 :
Mises à jour du système et de la base de données :
PHP 8.0 n’est plus supporté, tandis que PHP 8.1 est obsolète mais toujours utilisable.
Le support pour MariaDB 10.3 et 10.5 et PostgreSQL 9.4 ont été retirés.
Améliorations de la configuration :
De nouveaux paramètres dans le fichier de configuration ont été introduits, et certains sont dépréciés :
L’option blacklisted_files est remplacée par forbidden_filenames.
De nouvelles options comme forbidden_filename_basenames et forbidden_filename_extensions permettent de mieux contrôler les noms de fichiers et extensions bloqués.
Amélioration de la gestion des images WebP dans la configuration des serveurs web.
Gestion des fichiers et des dossiers :
Les utilisateurs peuvent désormais voir l’emplacement d’origine des fichiers supprimés dans la corbeille, et certains attributs de fichiers/dossiers sont hérités pour préserver l’état de partage.
Amélioration des aperçus de fichiers : les aperçus pour les PDF utilisent désormais le nouveau fournisseur ImaginaryPDF.
Performances et optimisation :
Plusieurs améliorations de performance, notamment le chargement différé de certaines fonctionnalités comme la génération des métadonnées, et une meilleure gestion des tâches cron pour réduire la charge du serveur.
Amélioration du tri et des fonctions de glisser-déposer dans la gestion des fichiers, avec un meilleur support pour les fichiers cachés.
Sécurité et gestion des utilisateurs :
Introduction d’une API de traitement des tâches pour gérer plus efficacement les tâches en arrière-plan.
Nouvelles fonctionnalités de sécurité, comme un contrôle plus strict des CSRF, une meilleure gestion des mots de passe pour les partages de fichiers, et un nettoyage automatique des mots de passe d’applications inutilisés.
Améliorations pour LDAP, avec une meilleure synchronisation des utilisateurs et groupes, et un journalisation améliorée des connexions LDAP.
Interface utilisateur et personnalisation :
Améliorations de l’interface utilisateur, avec une séparation des couleurs primaires et de fond pour un menu d’en-tête plus propre, et des améliorations dans les couleurs de l’interface.
Introduction de Vue.js pour plusieurs dialogues, remplaçant les anciens composants de jQuery UI pour une meilleure expérience utilisateur.
Mises à jour du tableau de bord avec des améliorations de la mise en page et des API pour plus de personnalisation.
Collaboration et partage améliorés :
Nouvelles options pour les demandes de fichiers, permettant de solliciter des fichiers de la part d’autres utilisateurs plus facilement.
Améliorations diverses des capacités de partage, incluant une gestion améliorée des dates d’expiration pour les partages publics et des options de protection par mot de passe.
Corrections de bogues et divers :
Corrections liées à la gestion des sessions, à la gestion des erreurs, et à l’intégration LDAP.
Améliorations dans la gestion de certains types de fichiers, la synchronisation des calendriers, et les notifications utilisateurs.
Ces changements mettent l’accent sur la performance, la sécurité, et l’amélioration de l’expérience utilisateur, tant dans les paramètres d’administration que dans la gestion quotidienne des fichiers.
Mise à jour pour les clients Nextcloud chez LRob
La version 30 de Nextcloud entre en phase de test de notre côté pour prévoir le déploiement plus large à tous les clients.
Le conflit entre Matt Mullenweg, fondateur de WordPress et WP Engine continue de secouer la communauté WordPress. Le dernier développement dans cette affaire concerne un plugin majeur de l’écosystème : Advanced Custom Fields (ACF). Depuis le 12 octobre 2024, ACF a été entièrement remplacé sur le répertoire officiel de WordPress.org par Secure Custom Fields (SCF), un fork mis en place par l’équipe de sécurité de WordPress.
Ce conflit autour d’ACF est l’une des nombreuses étapes dans la tension croissante entre Matt Mullenweg et WP Engine. La relation entre ces deux acteurs majeurs de l’écosystème WordPress a dégénéré en raison de divergences sur la gestion de la marque WordPress, la gouvernance du projet, et certaines pratiques commerciales de WP Engine. Ces tensions se sont intensifiées lorsque Mullenweg a critiqué ouvertement WP Engine, l’accusant de nuire à l’écosystème en désactivant certaines fonctionnalités cruciales (comme l’historique des révisions), et de brouiller les cartes avec l’utilisation de la marque « WP ».
Ce conflit pose des questions sur la gouvernance de WordPress et la gestion de l’open source dans un environnement où les intérêts commerciaux sont en jeu.
Un changement officiellement motivé par la sécurité
Dans un billet publié le 12 octobre 2024, Matt Mullenweg a annoncé la création de Secure Custom Fields en tant que fork d’ACF pour répondre à une faille de sécurité critique découverte dans le plugin d’origine.
Secure Custom Fields remplace ainsi totalement ACF sur WordPress.org et tous les sites qui utilisaient ACF via ce dépôt passeront automatiquement à SCF lors de la mise à jour.
On ne peut pas s’empêcher de penser que les tensions entre les deux entreprises n’y sont pas pour rien dans cette décision. Mais nous ne sommes cependant pas à la place de Matt Mullenweg, qui, intelligent et au service du projet WordPress, a probablement de bonnes raisons de faire ce choix.
La réaction de l’équipe ACF
Face à ce changement, l’équipe ACF a exprimé sa déception et son inquiétude dans un article publié sur leur blog officiel. Ils dénoncent une décision qu’ils jugent unilatérale et qui, selon eux, va à l’encontre des principes de l’open source. Depuis leur intégration à WP Engine, ils ont continuellement travaillé sur le développement d’ACF avec plus de 200 000 lignes de code et de nombreuses améliorations, tant sur le plan fonctionnel que sécuritaire.
Voici ce qu’ils déclarent dans leur billet :
« Nous sommes consternés par les actions de Matt Mullenweg, qui a unilatéralement et sans notre consentement pris le contrôle du plugin Advanced Custom Fields, un outil que nous développons activement pour la communauté WordPress depuis 2011. »
L’équipe ACF indique que les utilisateurs d’ACF Pro ou ceux hébergés sur WP Engine et Flywheel ne sont pas concernés par ce changement et continueront de recevoir les mises à jour directement via WP Engine. En revanche, ceux utilisant la version gratuite d’ACF sur d’autres hébergements doivent télécharger manuellement la version 6.3.8 d’ACF depuis leur site pour continuer à bénéficier des mises à jour de leur côté.
ACF indique comment continuer d’utiliser sa propre version du plugin en cas d’utilisation de la version gratuite d’ACF chez un hébergeur autre qu’eux-même (WP Engine).
Il joue enfin la carte de la fidélité sur son site avec un encart spécial sur l’accueil :
Encart sur la page d’accueil d’ACF
« Vous faites confiance à ACF depuis plus de dix ans. Les experts qui maintiennent ACF continueront à soutenir et à améliorer les fonctionnalités que nos utilisateurs apprécient et en lesquelles ils ont confiance. »
Néanmoins ces plugins sont moins essentiels qu’ACF et peuvent être remplacés par Update URLs et Query Monitor pour ne citer qu’eux.
Impact pour les utilisateurs
Différences entre ACF et SCF
Pour l’heure, les deux plugins gratuits sont fonctionnellement identiques car le « fork » est très récent. Il faudra donc suivre leurs évolutions respectives afin d’observer si l’un d’eux se démarque par sa stabilité, sécurité, ou ses fonctionnalités.
On peut envisager qu’ACF finisse par être intégré au core WordPress. Restons patients, l’avenir nous le dira.
Version payante d’ACF
Pour la version payante d’ACF et les clients WP Engine, il n’y a aucun changement à prévoir.
Version gratuite d’ACF
Si vous utilisez la version gratuite d’ACF sur la vraie version originale de WordPress.org, chez un hébergeur indépendant comme LRob :
Lors de mise à jour de vos plugins, ACF sera transformé en SCF, puis maintenu par la communauté WordPress
Si vous utilisez d’autres plugins de WP Engine, songez à leur trouver un remplaçant si ces derniers ne voient pas leur accès à WordPress.org restauré.
Conclusion
Bien que ce conflit puisse soulever des inquiétudes, il faut se rappeler que Matt Mullenweg a toujours eu pour objectif de maintenir l’intégrité et la sécurité de l’écosystème WordPress. Secure Custom Fields a été introduit dans cet esprit et malgré les critiques, Mullenweg reste une figure respectée dans la communauté.
En attendant que la situation s’éclaircisse davantage, restons prudents sur nos avis et à restons attentifs aux mises à jour et aux news à ce sujet.
Voir une IP blacklistée fait partie de la vie d’hébergeur, le quotidien pour les plus gros ou les plus permissifs. Néanmoins, c’est une première pour LRob en 10 ans d’existence !
Les plus positifs d’entre vous diront que c’est la rançon de la gloire… Forcément, plus le volume augmente, plus le risque de voir une activité non autorisée sur un site augmente. Les plus critiques feront un scandale. Quoi qu’il en soit, chez LRob, on fait le choix de la transparence. Alors on répond à toutes vos interrogations.
Que s’est-il passé et quelles solutions mettons-nous en œuvre ? Réponses.
Découverte du blacklisting sur AbuseIPDB
Dimanche 13 Octobre, j’ai été alerté par mon client Météo Centre que son site était bloqué par l’antivirus MalwareBytes en version payante (merci à eux pour cette alerte).
Face à cette anomalie, l’urgence est sonnée pour LRob. Que l’on soit Dimanche ou le jour de Noël : j’ai immédiatement vérifié son site qui n’avait aucun souci, puis investigué auprès de MalwareBytes. La cause du blocage a été donnée en 1h seulement (bravo au support MalwareBytes) : l’IPv4 du serveur hébergeant ce site est blacklistée sur AbuseIPDB pour requêtes malveillantes. Mais manifestement, le souci provient d’un autre site.
Coup de cœur pour AbuseIPDB
Toutes les blacklists ne se valent pas (CF : SPFBL), néanmoins, AbuseIPDB est un vrai projet bien fait et sérieux.
Dans cette mauvaise nouvelle, la découverte de cette blacklist communautaire été un coup de cœur : non-seulement celle-ci m’avait permis de détecter une anomalie sur mon serveur, mais il était facile de contribuer. C’est pourquoi LRob a immédiatement rejoint AbuseIPDB pour contribuer à reporter les IP attaquantes et aider la communauté mondiale des sysadmins en retour.
Mais le plus important était cependant de stopper la source des requêtes malveillantes. Alors d’où venaient-elles ?
Une cause inattendue
Bien-sûr, j’ai immédiatement cherché la cause de ces requêtes émanant d’un de mes serveurs. Si c’est un client, cela n’est pas toléré. Si c’est un site piraté, celui-ci devait être coupé et réparé immédiatement… Si c’est une intrusion serveur, c’est gravissime. J’ai donc entamé les recherches et ce que j’ai trouvé à la fois anodin et inhabituel.
Mais récemment, un nouveau site réparé m’a joué un mauvais tour : une récidive. Un site réparé s’est à nouveau fait pirater, ce qui ne m’était encore jamais arrivé sur mes hébergements.
Cela entrant dans la garantie de 90 jours, j’ai donc réparé à nouveau ce site sans aucun frais. Mais les attaques, bien que moins fréquentes, continuaient d’arriver sur AbuseIPDB.
Au bout de 3 jours de recherches de logs infructueuses au cours des journées et soirées, j’ai finalement analysé l’ensemble du trafic réseau sur le serveur (un travail de titan), jusqu’à remonter un des processus (programmes) anormaux lancés en tant que l’utilisateur système de ce site. Eurêka ! Je tiens là la cause originelle du problème.
Comment est-ce possible ?
Je le sais désormais, dès son arrivée, ce site contenait en fait des programmes (pas juste des scripts PHP mais bel et bien des programmes) malveillants, qui ont réussi à s’exécuter dès l’importation du site. Cela signifie que même une fois supprimés, et même avec le site désactivé, les programmes malveillants continuaient de tourner. Les hackers ont donc pu utiliser cela comme vecteur d’attaque même après la réparation du site. Ils ont également pu réécrire des fichiers malveillants, générant la récidive visible.
Comme ces programmes ne tournaient pas directement via le serveur web habituel, mais indépendamment, il était impossible de détecter leur activité via les logs du serveur web, rendant la détection plus difficile (raison pour laquelle aura fallu en dernier recours analyser le trafic réseau, ce qui est inhabituel). D’autant plus que ce type de programme n’est même pas sensé pouvoir s’exécuter et pour cause : la fonction « PHP exec() » qui permet de les lancer est sensée être désactivée… Mais elle ne l’était pas pour ce client en raison d’une configuration spécifique (corrigée depuis). J’avais déjà vu ce souci sur d’autres serveurs et si ça n’avait pas été le mien, j’aurais pensé à regarder directement les process lancés et j’aurais trouvé le souci en 30 minutes… Mais ici, comme cela n’était pas sensé arriver, ça m’a pris 3 jours. Les joies du métier !
La solution immédiate
Tous les process (programmes en cours d’exécution) douteux ont bien-sûr été sauvegardés pour investigation, puis stoppés. Un checkup complet du site a été refait et une vérification manuelle 3x par jour a été mise en place pour s’assurer qu’aucune récidive n’avait lieu.
Situation actuelle
A l’heure où j’écris ces lignes, plus aucune attaque n’est reportée sur AbuseIPDB, mais la blacklist n’a pas encore été levée.
Delisting
La demande de delisting a été effectuée le jour même de la découverte du souci, et peut prendre entre 7 et 10 jours à être levée. C’est lent, et ce serait là le seul défaut d’AbuseIPDB. L’impact de ce blacklisting est heureusement assez faible en attendant cette levée.
Aucun autre site touché
Grâce à l’excellente isolation des sites web appliquée sur mes hébergements, le site piraté était cantonné à lui-même et n’a pas pu avoir d’impact sur les autres sites hébergés.
Des solutions supplémentaires à long terme
L’impact de ce blacklisting est très minime et pour preuve : seul Météo Centre m’a remonté ce souci, car ce site est probablement le plus populaire que j’héberge, ce qui leur permet de rapidement être notifiés de ce type d’informations. Merci encore à eux et à MalwareBytes pour leur réactivité dans la remontée d’informations pertinentes.
Néanmoins, il est possible un jour que certains clients souhaitent la possibilité d’éviter totalement que leur site ne soit hébergé sur une IP blacklistée à cause d’un tiers site web. Pour cela, la solution est l’adresse IP dédiée.
C’est pourquoi prochainement, je vais lancer l’option IP dédiée disponible pour tous les hébergements web LRob.
Cela nécessite quelques préparatifs car l’ajout de multiples IP sur un serveur dédié n’est pas anodin. De plus il faut que j’estime et définisse le prix de l’option. Lorsque l’option sera lancée, chaque client LRob pourra bénéficier d’une IPv4 et IPv6 dédiée s’il le souhaite.
Avec un peu d’imagination, cela pourrait également permettre des migrations de serveur sans changement d’IP, grâce aux « IP Failover » (plus coûteuses mais plus flexibles, elles peuvent être transportées d’un serveur à un autre, tant que le fournisseur de serveur reste inchangé). Cela devrait plaire à mes revendeurs n’ayant pas la main sur la zone DNS de tous leurs clients… !
L’importance de la transparence
Un service où il n’y a jamais aucune anomalie n’existe pas en ce monde. Bien-sûr, j’aurais pu cacher ce souci mineur et un seul client l’aurait remarqué. Mais chez LRob, on fait le choix montrer notre engagement à gérer toute anomalies avec rigueur et dévotion.
La transparence est la base de la confiance. Et je vous remercie pour votre confiance.
Remplacer un wiki par WordPress : une solution plus simple pour la documentation
Chez LRob, la gestion de la documentation est essentielle, mais elle était jusqu’à récemment assurée par MediaWiki. Bien que cet outil soit efficace pour des projets collaboratifs, il devient lourd et compliqué à gérer quand on est seul à rédiger et maintenir la documentation.
C’est en travaillant sur un site WordPress aux nombreuses pages utilisées comme des catégories que l’idée m’est venue : pourquoi ne pas utiliser WordPress pour gérer la documentation, sans plugin supplémentaire ?
Pourquoi passer à WordPress ?
WordPress, qui fait tourner portail.lrob.fr/, offre déjà toutes les fonctionnalités de base nécessaires pour organiser la documentation, sans avoir à installer de plugin supplémentaire. Voici quelques avantages natifs qui m’ont poussé à faire la transition :
Hiérarchie des pages : Créer des pages et des sous-pages, comme dans un wiki, est très simple grâce à la structure native de WordPress.
Bloc Gutenberg pour l’arborescence : Il existe un bloc permettant d’afficher l’arborescence des sous-pages d’une page parente, facilitant la navigation dans la documentation.
Pour compléter cette configuration, j’ai utilisé RankMath SEO, déjà présent sur lrob.fr, qui m’a aidé à intégrer deux fonctionnalités clés pour un site de documentation :
Breadcrumbs : Un fil d’Ariane pour améliorer la navigation et le référencement.
Sommaire automatique : Un index des titres et sous-titres, idéal pour des pages bien structurées comme dans un wiki.
En prime, le wiki pourra être traduit automatiquement en anglais grâce à TranslatePress et l’API DeepL qui fait des miracles.
La transition vers WordPress
Le 17 Octobre au soir, j’ai donc transféré la documentation sur WordPress. L’éditeur de blocs Gutenberg a rendu le processus facile, en conservant les titres, listes, et liens lors du copier-coller depuis MediaWiki. Ensuite, j’ai mis en place des redirections 301 du wiki vers les nouvelles pages de documentation sur WordPress, puis j’ai désactivé l’ancien wiki.
Ce matin, j’ai profité de cette migration pour réorganiser et améliorer une partie de la documentation, avec une mise en page plus claire et plus moderne, tout en ajoutant des liens internes pour une meilleure navigation.
Un résultat plus simple et efficace
Le passage à WordPress simplifie la gestion de la documentation. Non seulement cela m’a permis d’éliminer les lourdeurs de maintenance de MediaWiki, mais c’est aussi une solution plus flexible et facile à utiliser pour moi, tout en offrant un contenu plus accessible à mes clients.
Grâce à RankMath SEO, la documentation est mieux structurée et plus optimisée pour le SEO, ce qui devrait améliorer sa visibilité en ligne.
Depuis longtemps, je cherchais un moyen d’exploiter efficacement les données de hacking bloquées par mes serveurs. Et en tant qu’hébergeur spécialiste WordPress, croyez bien que je déjoue des centaines voire des milliers de tentatives de piratages chaque jour (et je répare régulièrement des sites WordPress piratés qui proviennent d’autres hébergeurs). Les tentatives d’intrusion sont permanentes, mais grâce à des systèmes de sécurité tels que Fail2ban, les attaques sont stoppées automatiquement avant de causer des dommages. Cependant, au-delà de la simple protection de mes systèmes et clients, je souhaitais aller plus loin : partager ces informations et rendre l’internet plus sécurisé pour tous.
Déjà plus de 2000 IP malveillantes reportées en seulement 48 heures !
C’est dans cette optique que LRob a commencé à contribuer au reporting des attaquants via AbuseIPDB, une plateforme qui permet à chacun de signaler des IP malveillantes. En seulement 48 heures, plus de 2000 IP ont déjà été signalées, ce qui montre à quel point cette initiative peut avoir un impact significatif.
Ci-après le nombre total d’IP reportées depuis que LRob a rejoint AbuseIPDB (MAJ en août 2025 on tourne plutôt à 8000/jour) :
Pourquoi reporter les IP malveillantes ?
Les hackers attaquent tout, tout le temps. Que vous soyez une petite entreprise, un particulier ou une grande organisation, vous êtes une cible. Toutefois, même si ces attaques sont incessantes, les ressources des cybercriminels sont limitées. En les identifiant, nous avons une chance de mieux les combattre et de limiter leurs capacités d’action.
Il y a deux principales raisons pour lesquelles reporter les IP malveillantes est crucial :
Identifier et bloquer les attaquants : En reportant ces IP, vous contribuez à la création d’une base de données accessible à tous, facilitant ainsi le blocage de menaces potentielles avant qu’elles n’atteignent d’autres infrastructures.
Informer les hôtes légitimes : Certains hôtes légitimes peuvent être infectés ou détournés à leur insu, servant alors de relais pour des attaques. En signalant ces IP, vous leur donnez une chance de réagir et de corriger la situation.
Le partage d’informations via des plateformes telles qu’AbuseIPDB permet de rendre le web plus sûr, non seulement pour vous, mais aussi pour toute la communauté.
Une API simple pour un reporting efficace
L’une des grandes forces d’AbuseIPDB est sa simplicité d’utilisation. Via une API accessible à tous, il devient très facile de contribuer au signalement des IP malveillantes. En validant votre identité, vous pouvez même augmenter la limite des signalements à 5000 IP par jour, ce qui permet de couvrir un plus large spectre d’attaques.
J’ai donc décidé de mettre en place un système pour automatiser ces reports, et ainsi faire profiter la communauté de mes données de hacks bloqués. Une bannière est désormais visible en bas de mon site LRob.fr, renvoyant directement vers mon profil AbuseIPDB, où chacun peut voir les IP que j’ai signalées (voir mon profil ici).
Automatisation du reporting avec Plesk et Fail2ban
Pour ceux qui, comme LRob, utilisent Plesk pour gérer leurs serveurs, j’ai développé un script permettant de reporter automatiquement les IP malveillantes via l’API d’AbuseIPDB en utilisant les jails de Fail2ban.
Ce script est librement disponible sur GitHub et peut être utilisé par tout sysadmin souhaitant automatiser ce processus. Il suffit de configurer votre clé API et vous êtes prêt à commencer !
Nous avons tous un rôle à jouer pour construire un internet plus sain et sécurisé. Chaque IP signalée est une attaque potentielle en moins pour nos infrastructures, une menace en moins pour les entreprises et les particuliers. Grâce aux efforts conjugués des contributeurs et des plateformes comme AbuseIPDB, nous pouvons réduire l’impact des cyberattaques et rendre le web plus sûr pour tous. 🌐
Alors, que vous soyez un sysadmin expérimenté ou un utilisateur individuel souhaitant contribuer, je vous encourage à rejoindre cette initiative. Ensemble, nous pouvons faire une vraie différence et rendre le web plus sécurisé. 👊
Et si vous cherchez simplement un hébergeur sécurisé et spécialiste de WordPress, je vous invite à découvrir mes offres :
Il est temps de dénoncer une organisation – SPFBL.net – qui, bien qu’elle prétende lutter contre le spam, semble en réalité adopter des pratiques contraires à cet objectif. Au lieu de remplir son rôle, ce prestataire semble profiter de sa position pour mener des pratiques absolument scandaleuses et inacceptables.
Toutes les RBL ne sont pas gérées de manière éthique. L’exemple du jour est celui de SPFBL.net, une RBL brésilienne née en 2015(source MXToolbox), qui est de plus en plus mise en lumière pour ses pratiques largement contestables.
Info : Qu’est-ce qu’une RBL ?
Une RBL (Real-time Blackhole List) est une liste d’adresses IP suspectées d’envoyer du spam ou d’autres contenus malveillants. Les serveurs de messagerie s’appuient sur ces listes pour bloquer ou filtrer les e-mails potentiellement dangereux.
Dans cet article, nous allons décortiquer cette situation et expliquer pourquoi les pratiques de cette entreprise sont non seulement douteuses, mais potentiellement nuisibles à l’ensemble de l’écosystème internet si des administrateurs décident d’utiliser cette RBL. Nous verrons également comment combattre ces pratiques.
L’avis des utilisateurs et fournisseurs de services confrontés à la blacklist SPFBL
Commençons par montrer l’avis général ressortant de cette blacklist. Une rapide recherche sur les moteurs de recherche montre que les forums (en anglais) sont remplis de personnes criant au scandale et à l’arnaque au sujet de SPFBL.net.
Pour avoir contacté leur support (je vous détaille cela ensuite), je serais plutôt de leur avis… Jugez par vous-même.
« I contacted the operator of this spfbl.net and he threatened me with getting my IP’s blocked throughout the internet, how can something like this be allowed to happen. »
« We got flagged because we don’t have a contact email in our whois record (we have privacy turned on for it). Given that google.com also has that, I conclude that these guys are just a scam who want to be paid to have your domain unrestricted. »
Le cas LRob : une blacklist manifestement injustifiée
Le serveur d’infrastructure LRob est un exemple parfait d’un système configuré et géré avec soin depuis plusieurs années. En tant qu’administrateur système de ce serveur, je peux affirmer avec certitude qu’aucun spam n’a jamais été envoyé depuis cette machine. De plus, tous les paramètres essentiels sont correctement mis en place : Hostname, rDNS, MX, SPF, DKIM, et DMARC.
Malgré ces mesures exemplaires de conformité, l’IPv6 du serveur s’est retrouvée sur la liste noire de SPFBL.net.
A domain is considered non-compliant when the WHOIS search result for that domain does not contain the email address of the domain owner. Update the registration data and remove privacy protection for this domain in WHOIS and wait one hour for the cached result of this WHOIS query to expire.
This IP was flagged due to misconfiguration of the e-mail service or the suspicion that there is no MTA at it.
For the delist key can be sent, select the e-mail address responsible for this IP:
add a PayPal user’s email for 2.00 USD.
The rDNS must be registered under your own domain. We do not accept rDNS with third-party domains.
Résumé des échanges avec le support de SPFBL.net
J’ai bien-sûr contacté la RBL pour vérifier si j’avais bien compris leur politique et s’il était possible de discuter en bonne intelligence. Résultat : oui, j’avais bien compris, et non, il ne me semble pas possible de discuter en bonne intelligence avec eux en l’état.
Voici un résumé ChatGPT des échanges par mail :
Demande initiale (Robin) : Robin, administrateur système, a contacté SPFBL pour demander de l’aide concernant la suppression de son adresse IPv6 de leur liste noire DNS. Il souhaitait obtenir des précisions sur les raisons de l’inscription et des conseils pour corriger d’éventuelles mauvaises configurations, suspectant un lien avec la protection de la confidentialité WHOIS.
Réponse (Leandro) : Leandro, de SPFBL, a répondu en demandant à Robin de retirer temporairement la protection de la confidentialité WHOIS afin de pouvoir retirer l’IP via leur outil de suppression en ligne.
Préoccupations (Robin) : Robin a exprimé des inquiétudes quant à l’exigence de retirer la protection de la confidentialité WHOIS, invoquant les réglementations du RGPD. Il a remis en question la nécessité d’exposer des données personnelles, soulignant qu’aucun rapport d’abus n’avait été émis sur son domaine.
Explication (Leandro) : Leandro a expliqué que leur système utilisait les données du propriétaire du domaine pour prédire le spam et associer des domaines sous le même titulaire. Il n’a pas fourni d’autres justifications pour cette politique.
Objection (Robin) : Robin a contesté l’utilité des informations WHOIS pour évaluer le comportement d’une IP, qualifiant la politique de SPFBL de contre-productive. Il a réitéré que son IP ne présentait aucun risque et a demandé sa suppression de la liste noire.
Options (Leandro) : Leandro a proposé deux options pour la suppression : retirer temporairement la protection WHOIS ou payer des frais.
Réponse ferme (Robin) : Robin a fermement rejeté les deux options, qualifiant cette pratique de malhonnête et assimilable à une escroquerie. Il a souligné que son IP était conforme et a menacé de prendre des mesures légales si le problème n’était pas résolu.
Réponse finale (Leandro) : Leandro a rejeté les menaces légales de Robin, affirmant que SPFBL respecte les lois américaines et l’invitant à poursuivre toute action légale qu’il jugerait appropriée.
Dernier avertissement (Robin) : Robin a rappelé que l’internet est un système global et qu’aucune localisation ne justifie de nuire à des entreprises légitimes à travers des pratiques éthiques douteuses. Il a confirmé son intention de prendre les mesures nécessaires, en précisant que ses contacts identifieraient les autorités locales compétentes si nécessaire.
Ces échanges ont eu lieu entre le 8 et le 9 septembre 2024.
Par ailleurs, je dispose d’un log qui montre qu’ils ont tenté d’envoyer un mail à une adresse inexistante pour test, pouvant vérifier par eux-même la bonne configuration du serveur qui a donc rejeté ce mail :
Oct 9 14:55:13 ds postfix/smtpd[899530]: connect from matrix.spfbl.net[54.233.253.229]
Oct 9 14:55:14 ds postfix/smtpd[899530]: NOQUEUE: reject: RCPT from matrix.spfbl.net[54.233.253.229]: 550 5.1.1 <inexistent-feature-check-192715907d9@lrob.net>: Recipient address rejected: User unknown in virtual mailbox table; from=<admin@spfbl.net> to=<inexistent-feature-check-192715907d9@lrob.net> proto=ESMTP helo=<matrix.spfbl.net>
Oct 9 14:55:14 ds postfix/smtpd[899530]: disconnect from matrix.spfbl.net[54.233.253.229] ehlo=1 mail=1 rcpt=0/1 quit=1 commands=3/4
Oct 9 14:55:14 ds psa-pc-remote[2023328]: Message aborted.
Le cas SPFBL.net : une pratique abusive
Le cas de SPFBL.net met en lumière des pratiques alarmantes qui vont à l’encontre de la protection des données et des standards éthiques que de nombreuses autres RBL respectent.
En particulier, cette RBL blacklist des IP selon des critères abusifs, puis impose des conditions très problématiques pour le délistage d’adresses IP.
Décortiquons les « règles pour un délistage gratuit » selon la politique affichée sur leur site le 9 Septembre 2024, qui nous informe également sur les raisons possibles au blacklistage initial :
Only IP with rDNS pointing to the same mail server IP will be accepted, with FCrDNS validation;
❌ Ce critère est certes standard, mais cette vérification devrait être effectuée par le serveur destinataire de l’e-mail, pas par une RBL, qui ici n’apporte aucune valeur ajoutée.
The rDNS must be in the domain of the MTA administrator, so third-party domains such as the generic rDNS of the data-center or ISP will not be accepted, and its TLD cannot be free and must have a public and accessible WHOIS without privacy obfuscation;
❌ L’administrateur peut très bien infogérer les mails d’un tiers, comme dans mon cas où le MTA est « lrob.net » et l’administration est faite via « lrob.fr ». Cela ne devrait pas justifier un blocage. ❌ Bloquer les rDNS génériques peut être une bonne pratique, mais cela relève du serveur destinataire, pas d’une RBL. ❌ Exiger un WHOIS public contrevient au RGPD en Europe. Le droit d’envoyer des mails ne devrait pas dépendre de la visibilité des informations personnelles dans le WHOIS.
The postmaster account must be configured for the domain registered on the rDNS and the account must be active and responding;
❌ Les rDNS sont souvent des sous-domaines techniques, comme « ds.lrob.net ». Avoir une adresse e-mail du type « postmaster (at) ds.lrob.net » n’a aucun sens. Le postmaster peut être contacté via d’autres canaux plus appropriés, comme un formulaire de contact ou une adresse principale.
If you are using an IPv6 with SLAAC flag, you must keep port 25 opened to proof the existence of an active SMTP service and
❌ Bien que le serveur doive effectivement écouter sur le port 25 pour assurer le bon fonctionnement du SMTP, c’est encore une fois au serveur destinataire de vérifier cela, pas à une blacklist de le contrôler.
Reputation of IP should be below 25% of negative points per total send volume
✅ Ce critère est cohérent avec le principe même d’une RBL, qui évalue la réputation d’une adresse IP en fonction de son comportement réel.
Voyons aussi les conditions payantes :
Only static IPs with configured mail server reverse, even if FCrDNS is invalid;
❌ Sous prétexte de payer, on permettrait d’avoir un rDNS invalide, ce qui est contraire aux normes de configuration des e-mails. C’est un contournement des bonnes pratiques, qui pourrait permettre l’envoi de courriers mal configurés.
A PayPal account is required for the email address of this account to be assigned to the IP, as responsible for the abuse;
❌ Forcer l’utilisation de PayPal pour attribuer une adresse IP à un compte est une restriction injustifiée. Cela limite les options des utilisateurs et n’a aucune raison légitime dans un cadre technique.
The PayPal user must agree to have their email address shown publicly on this platform as responsible for the abuses of that IP and
❌ Exposer publiquement l’adresse email associée au compte PayPal est une atteinte à la vie privée et peut entraîner des risques de harcèlement ou d’abus. Cela va clairement à l’encontre des principes de confidentialité.
Reputation of IP should be below 25% of negative points per total send volume.
✅ Ce critère est acceptable et s’aligne avec le principe d’évaluation de la réputation d’une adresse IP sur la base de son comportement effectif, comme attendu d’une RBL.
En somme, cette blacklist me semble tenter de réinventer la roue avec des règles de blocage qui ne font strictement aucun sens d’un point de vue technique.
Quand aux conditions de délisting, même dans sa version payante, les conditions restent abusives. De mon point de vue, cela devrait déjà, à ce stade, avoir dissuadé tout sysadmin d’utiliser cette RBL.
Le but semble bien-sûr être de faire du profit sur le dos des utilisateurs tout en récupérant des données personnelles.
Résumé des problèmes de SPFBL.net
Plusieurs problèmes majeur remettent en question le bienfondé de leurs pratiques et leur impact négatif sur les entreprises légitimes.
Voici les principaux points à retenir :
Exposition des données privées WHOIS SPFBL.net exige que les administrateurs retirent la protection de leur WHOIS pour être retirés de leur liste noire. Cela signifie que des informations personnelles et sensibles, comme l’adresse email du propriétaire du domaine, doivent être publiquement accessibles pour que l’adresse IP ne soit plus blacklistée. En Europe, cette demande est en totale contradiction avec le RGPD (Règlement Général sur la Protection des Données), qui garantit la protection des données privées des utilisateurs. Les informations contenus dans le WHOIS sont privées par défaut depuis plusieurs années. Cette exigence exposerait les administrateurs système et les entreprises à des risques d’abus ou de spams ciblés, ce qui est contraire aux bonnes pratiques en matière de sécurité et de confidentialité.
Paiement pour la délistage En plus de la suppression de la protection WHOIS, SPFBL.net propose également une alternative : payer 2 dollars pour retirer une adresse IP de la liste noire. Cette pratique est perçue par beaucoup comme une forme de chantage. Exiger un paiement pour rétablir la légitimité d’une adresse IP, alors qu’il n’y a aucune preuve d’activité suspecte ou malveillante, remet en question la transparence de leurs opérations. Cette approche pousse probablement de nombreuses entreprises légitimes à payer simplement pour éviter les désagréments causés par le blacklistage.
Un modèle de détection inefficace Regrouper les domaines en fonction des informations WHOIS ignore les réalités du web moderne, où de nombreuses entreprises légitimes utilisent des infrastructures partagées, hébergées par des fournisseurs comme Google ou OVH. En conséquence, des adresses IP pourraient être injustement blacklisted simplement parce qu’elles partagent un propriétaire de domaine avec d’autres utilisateurs, sans considération pour leur comportement réel.
Un impact potentiel très grave
Les conséquences de ces pratiques sont nombreuses et graves pour l’écosystème internet :
Impact sur les entreprises : Lorsqu’une adresse IP est bloquée à tort, cela peut affecter la capacité d’une entreprise à communiquer par e-mail avec ses clients, partenaires ou prestataires. Les erreurs de détection ou les exigences abusives peuvent ainsi perturber le bon fonctionnement d’une entreprise.
Chantage et extorsion : Demander de l’argent pour supprimer une adresse IP d’une liste noire sans preuve d’activité malveillante s’apparente à de l’extorsion. Cette approche nuit gravement à la confiance entre les fournisseurs de services internet et leurs clients.
Violation de la confidentialité : En demandant la suppression de la protection WHOIS, SPFBL.net viole les principes fondamentaux de la protection des données personnelles, particulièrement en Europe, où le RGPD (Règlement Général sur la Protection des Données) protège les informations privées des utilisateurs. En exposant ces données, SPFBL.net expose les administrateurs système et les entreprises à des risques d’abus.
Que faire en tant que fournisseur de services sur internet ?
1. Cessez d’utiliser cette RBL immédiatement
Nous devons tous enjoindre nos relations chez les grands fournisseurs de services à ne surtout PAS utiliser cette RBL.
Il est absolument indispensable que les fournisseurs de services internet cessent d’utiliser SPFBL.net et d’autres RBL qui ne respectent pas les standards éthiques. Une autre RBL de ce type est également UCEPROTECT qui blacklist des blocks d’IP complets et demande ensuite de l’argent à chacun des usagers des IP pour les débloquer.
L’utilisation d’une RBL douteuse peut entraîner des conséquences néfastes pour les utilisateurs finaux, les entreprises et l’ensemble de l’écosystème numérique.
Il existe de nombreuses alternatives respectables qui se concentrent sur la détection des activités malveillantes en se basant sur des comportements réels, et non sur des informations privées ou des regroupements arbitraires de domaines. Les administrateurs système doivent rester vigilants et choisir des solutions qui respectent la vie privée et qui suivent des pratiques équitables et transparentes.
2. Ne cédez pas
Si comme moi vous êtes victime de cette RBL et estimez que ces pratiques sont abusives, ne cédez surtout pas aux prérequis scandaleux de cette RBL. Au contraire, battez-vous à mes côtés.
3. Dénoncez ces pratiques aux autorités compétentes
Faites jouer vos relations pour que cela remonte aux CSIRT français (Computer Security Incident Response Team), à l’ANSSI mais également à la CNIL pour non respect de la RGPD. Si vous avez des contacts au niveau européen, relayez l’info. Si vous êtes en dehors de France ou d’Europe, contactez les organismes à votre portée, et n’hésitez pas à vous appuyer sur cet article pour expliquer le problème.
Si vous n’avez pas de contact mais que vous comprenez l’enjeu, relayez également l’info à des personnes du domaine de l’hébergement et du sysadmin web.
Conclusion
L’affaire SPFBL.net est un exemple flagrant des dangers des pratiques douteuses de certaines RBL.
On comprend que celui qui se prétend combattre les « méchants » n’est pas toujours « gentil » lui-même.
Pour protéger l’intégrité de l’internet et le respect des utilisateurs, il est impératif que les fournisseurs de services internet cessent d’utiliser cette RBL et privilégient les solutions plus respectueuses disponibles.
Confrères sysadmin : ne cédez surtout pas aux prérequis grotesques de cette RBL.
LRob ne cédera pas, cet article marque d’ailleurs le début d’une lutte qui ne s’arrêtera qu’une fois que la communauté aura eu gain de cause. Cela est possible, en contactant les bonnes personnes. Et vous pouvez aider à ce combat.
Si vous êtes confronté aux pratiques abusives de SPFBL.net, rejoignez-nous pour dénoncer ces actions et protéger l’intégrité de l’écosystème internet. Contactez les autorités compétentes, partagez cette information dans vos réseaux professionnels, et refusez de céder à ces pratiques déloyales.
A few cookies to keep the shop running 🍪
LRob respects your privacy. This site uses essential technical cookies (customer access, tickets, basket, payment). Stripe, our payment solution, may place additional security and marketing cookies.
YouTube forces its commercial cookies on videos integrated into the site.
Functional
Always active
Some cookies are required for the basic functions of this site.
Preferences
Technical access or storage is necessary for the legitimate purpose of storing preferences not requested by the subscriber or Internet user.
Statistics
Storage or technical access used exclusively for statistical purposes.Technical storage or access which is used exclusively for anonymous statistical purposes. In the absence of a subpoena, voluntary compliance by your internet service provider or additional records from a third party, information stored or retrieved for this sole purpose cannot generally be used to identify you.
Marketing
Technical access or storage is necessary to create user profiles in order to send advertisements, or to track the user on a website or on several websites with similar marketing purposes.
