Un hébergement WordPress ultra-performant et sécurisé, sans compromis
Chez LRob, notre mission est claire : offrir un hébergement WordPress rapide et sûr, en minimisant l’impact des attaques tout en optimisant les performances serveur. Contrairement à des solutions standard qui se contentent de répondre aux menaces, nous allons plus loin en prévenant activement les serveur charges inutiles.
Car si certains hébergeurs n’implémentent pas ou pas assez de blocage des attaques ou n’offrent aucune transparence, LRob peut afficher fièrement ses mesures en place et les résultats obtenus.
Dans cet article, nous vous expliquons notre stratégie qui repose sur trois couches de sécurité conçues pour bloquer efficacement les attaquants et vous offrir un maximum de sécurité et de performances pour vos site web.
Les attaques sur WordPress : un fléau qui consomme vos ressources
Les sites WordPress sont la cible de nombreuses attaques automatisées. Ces attaques prennent deux formes principales :
Les attaques réelles, qui consomment énormément de ressources. Par exemple, les tentatives de connexion massives ou les requêtes ciblant XML-RPC (xmlrpc.php) sollicitent fortement le CPU car elles atteignent directement PHP et ne peuvent pas être mises en cache. De même, certaines requêtes POST peuvent être interprétées par PHP et causer une charge excessive.
Les requêtes parasites, qui génèrent des réponses inutiles comme des erreurs 301, 403 (pare-feu applicatif ou règles serveur) ou 404. Bien qu’elles ne soient pas toujours malveillantes, elles alourdissent les logs et réduisent l’efficacité du serveur.
Sans les protections adéquates, cela peut saturer les serveurs et ralentir vos sites. C’est l’une des causes de lenteurs que l’on observe chez de nombreux hébergeurs.
C’est pourquoi LRob se bat activement contre ce type d’attaques. Et Notre approche fait la différence : nous ne nous contentons pas d’atténuer l’impact des requêtes malveillantes, nous les éliminons avant qu’elles ne deviennent un problème.
Notre stratégie de protection en trois niveaux
1. Des règles de sécurité spécifiques à WordPress
Nous implémentons des règles de sécurité strictes adaptées aux spécificités de WordPress, comme celles fournies par le WordPress Toolkit de Plesk, mais aussi des configurations personnalisées pour réduire la surface d’attaque.
Par exemple, nous interdisons certaines requêtes dans certains répertoires clé de WordPress, nous bloquons les requêtes sur XML-RPC lorsque inutilisé, et référençons les tentatives de connexion échouées à WordPress.
Cela permet de repérer ou bloquer directement les accès non autorisés et les comportements anormaux propres au CMS.
2. ModSecurity : un pare-feu applicatif puissant
ModSecurity agit comme un filtre intelligent en bloquant les requêtes malveillantes avant qu’elles n’atteignent WordPress. Cette solution permet d’arrêter les attaques les plus courantes comme les injections SQL, le XSS ou les scans de vulnérabilités, ajoutant ainsi une protection significative à votre site, même lorsque celui-ci contient des failles de sécurité connues.
Cependant, bloquer une requête ne suffit pas éviter l’utilisation inutile de ressources serveur. C’est là qu’intervient fail2ban.
3. Fail2ban : bloquer les attaquants de manière définitive
Fail2ban analyse les logs des attaques des deux sécurités précédentes et bloque automatiquement les IP malveillantes en les empêchant de faire d’autres requêtes.
En clair :
Fail2ban répertorie les attaquants via leur IP
Si un attaquant réitère son attaque, fail2ban bannit l’IP attaquante.
Résultat : cette IP ne pourra plus envoyer de requêtes à votre site.
Vous gagnez ainsi drastiquement sur deux plans : performance et sécurité. Votre site est plus rapide à charger et beaucoup moins sujet aux attaques.
Résultat : un site plus rapide, plus sûr, et des ressources libérées
Avec cette stratégie, nous constatons une baisse drastique de l’utilisation CPU sur nos serveurs, tout en améliorant la disponibilité et la réactivité des sites de nos clients.
Quelques chiffres :
Jusqu’à 95% de l’utilisation CPU économisée en bloquant directement les attaquants.
Un serveur autrefois saturé peut tomber à 5% d’utilisation après mise en place des protections.
Une réduction de 95% des logs parasites et une meilleure lisibilité des analyses de trafic.
J’aimerais pouvoir vous donner des chiffres sur le gain de sécurité. Mais il faudrait pour cela qu’un seul site hébergé par LRob aie été piraté. Cela n’est encore jamais arrivé. Il serait trop prétentieux de prétendre que cela réduit de 100% le risque de piratage d’un site. Néanmoins, on peut être confiant en le fait que cela mène la vie dure aux attaquants et rend le piratage de votre site extrêmement plus difficile.
Pourquoi choisir LRob pour votre hébergement WordPress ?
Nous ne nous contentons pas d’offrir un hébergement haute performance, nous optimisons en permanence notre infrastructure pour offrir une expérience fluide et sécurisée à nos clients.
Avec des règles de sécurité spécifiques, ModSecurity et fail2ban, nous assurons :
✅ Une protection proactive contre les attaques
✅ Des performances optimales pour vos visiteurs
✅ Un serveur déchargé des requêtes inutiles
Ne laissez pas des bots ralentir votre site.
Optez pour un hébergement web pensé pour la sécurité et la performance avec LRob ! 🚀
Une nouvelle menace d’ampleur inédite secoue le web : 2.8 millions de périphériques réseau compromis sont actuellement exploités pour inonder Internet de requêtes malveillantes.
Chez LRob, en tant qu’hébergeur web, nous avons observé une augmentation spectaculaire des attaques ces derniers jours. Nous vous expliquerons comment nous les bloquons efficacement.
Ces attaques ne sont pas seulement une nuisance : elles peuvent gravement impacter la performance et la sécurité de vos sites web. Quel est le fonctionnement de l’attaque ? Quel est son impact sur vos sites web ? Comment vous protéger ? Réponses.
Détails de l’attaque cyber
Découverte de l’attaque de cybersécurité
Comme nous l’indique notamment Cyber Security News dans son article, une vaste attaque par brute-force (essai de tous les mots de passe) a commencé par cibler les connexions VPN et pare-feu en utilisant 2,8 millions d’adresses IP. Une sorte de bruteforce croisé à du DDoS (Distributed Denial of Service) géant.
Détectée pour la première fois en janvier 2025 par la fondation Shadowserver, cette campagne vise les dispositifs de sécurité en périphérie, comme les VPN, pare-feu et routeurs de fournisseurs tels que Palo Alto Networks, Ivanti et SonicWall.
Les cybercriminels utilisent des réseaux de proxy résidentiels et des appareils compromis, notamment des routeurs MikroTik, Huawei et Cisco, pour mener ces attaques. Plus de 1,1 million d’adresses IP impliquées proviennent du Brésil. Suivi de la Turquie, la Russie, l’Argentine, le Maroc, le Mexique et d’autres pays comme l’Irlande selon certaines observations.
L’ensemble forme un botnet de plus en plus gros, pouvant mener diverses attaques. Et nous confirmons que cela commence à se voir côté hébergement web avec des attaques grandissantes depuis quelques jours. Il se pourrait donc que de nombreux nouveaux périphériques soient compromis.
Réaction des organismes officiels de cybersécurité
Face à cette menace croissante, les agences de cybersécurité internationales (CISA, NCSC, etc.) recommandent aux fabricants d’améliorer la sécurité par défaut de leurs dispositifs et aux entreprises de renforcer la protection de leurs accès réseau. L’utilisation de l’authentification multifactorielle (MFA), la mise à jour régulière des systèmes et la segmentation du réseau sont essentielles pour réduire les risques. Shadowserver avertit que ces attaques devraient se poursuivre, touchant d’autres fournisseurs et régions.
Propagation aux hébergements web – Observations LRob
Chez LRob, nous avons observé une augmentation des requêtes illégitimes depuis le début de l’année 2025, puis un bond drastique depuis le 8 février.
Ce 11 février, c’est le record avec +500% d’attaquants bloqués par rapport à la moyenne habituelle.
Un confrère confirme une augmentation simultanée des attaques reçues sur ses machines. Je me rapproche également d’autres confrères hébergeurs pour voir si eux aussi constatent une augmentation des attaques.
En chiffres bruts, nous avons dépassé 10.000 attaquants bloqués le mardi 11 Février 2025, soit 5x la valeur moyenne.
Concernant la charge serveur l’utilisation CPU moyenne des serveurs a augmenté d’environ 6%, passant de 14 à 20%. Si cela nous laisse 80% de marge de manœuvre, c’est déjà suffisant pour que nous réagissions (voir plus bas).
Provenance des attaques
De notre côté, les attaques proviennent de partout dans le monde et nous n’avons pas fait de statistiques précises sur la provenance, car cela demande une logistique importante pour peu de plus-value. La priorité est de bloquer un maximum d’attaques.
De plus, le type d’origine des attaques est très varié, cela vient d’IP domestiques comme d’IP en datacenter. Ce qui laisse à penser que nous avons affaire à un énorme botnet.
Concernant l’origine géographique, avec des pincettes, nous pouvons dire à vue d’œil que les attaques semblent provenir d’un peu partout dans le monde, avec la Chine potentiellement en tête (rien d’inhabituel, donc…).
Mais on observe également des attaques provenant de Singapour, du Brésil, d’Inde, du Vietnam, du Kazakhstan, Espagne, Finlande, Japon, Corée, Hong Kong, Thaïlande, Canada, USA, Géorgie, France, Italie, Royaume Uni, Bangladesh, Roumanie, Philippines…
Bref, rien ne se démarque à vue d’œil, les attaques viennent de partout, comme d’habitude.
Corrélation n’est pas causalité – Quelques réserves
Il faut concéder qu’il est impossible de faire un lien certain entre l’attaque mondiale en cours et cette augmentation d’attaques sur les serveurs web et les sites WordPress LRob. En effet, malgré la confirmation d’un confrère, l’échantillon n’est pas suffisant pour conclure avec certitude.
Cependant la corrélation reste frappante et il ne semble pas délirant de penser que les deux sont liés. Pour aller plus loin, la consultation d’autres confrères pourra nous permettre de vérifier si les attaques sont généralisées ou pas.
Les administrateurs, agences web et possesseurs de sites WordPress doivent s’interroger : « mon hébergement WordPress est-il prêt à encaisser cette vague d’attaques ?«
Que ce soit pour l’attaque actuelle ou les suivantes, si votre hébergeur web ne bloque pas ces attaques, vous pourriez rapidement en subir les conséquences :
Lenteurs : des requêtes parasites ralentissent votre site
Inaccessibilité : une saturation totale des serveurs peut empêcher toute réponse de votre site
Intrusions : une attaque réussie peut compromettre vos données et celles de vos clients
Dégradation du SEO : si un seul des points précédents se produit, cela peut dégrader fortement votre référencement
Comment protéger vos hébergements WordPress ? Méthode LRob.
LRob pratique déjà le blocage automatique des attaquants directement au niveau des serveurs. Cela réduit drastiquement la charge serveur, améliore les performances et réduit dratiquement le risque par rapport aux hébergeurs classiques. C’est selon nous la meilleure solution, testée et éprouvée depuis des années.
Un pare-feu applicatif (WAF), et de nombreuses règles de sécurité spécifiques à WordPress sont appliquées : cela permet de conserver vos sites web rapides et protégés.
Si ces sécurités sont déclenchées, alors l’attaquant est totalement bloqué du serveur. Ses attaques et requêtes n’ont alors plus aucun effet.
En bonus, on signale l’attaque sur AbuseIPDB pour aider les rares hébergeurs consciencieux à travers le monde.
Cependant, nous avons malgré cela observé une légère augmentation de 6% de l’utilisation CPU de nos serveurs, et en nombre d’attaques brutes, cela représente comme on l’a vu +500%.
En vérifiant la cause première de cette augmentation d’utilisation CPU, il s’agissait surtout de requêtes 404 (URLs inexistantes) pour environ 5%, et 1% d’autres requêtes plus complexes.
Nous avons donc pris des mesures supplémentaires pour retrouver un niveau de charge habituel. En s’ajustant ainsi, nous pouvons continuer d’assurer la performance maximale aux sites hébergés, même en cas d’accentuation de l’attaque. Nous ne sommes pas invincibles (personne ne l’est), mais nous n’avons pas à rougir face aux autres hébergeurs, bien au contraire. Et nous avons d’autres tours dans notre sac si besoin.
Nouvelles mesures de réduction du gaspillage de ressources
Certaines IP malveillantes génèrent un flot de requêtes inutiles (erreurs 404, scrapping abusif, etc.), gaspillant des cycles d’horloge processeur sans représenter une menace directe. Et le gaspillage est insupportable.
Nous avons donc mis en place une règle stricte : Les IP déclenchant trop de 404 sont désormais automatiquement bannies.
Les résultats sont immédiats :
Plus de 500 attaquants bannis grâce à cette règle en 24h
Réduction significative de l’utilisation CPU
Performance constante pour les visiteurs légitimes
Bien-sûr, nous ne pouvons pas détailler toutes les nouvelles règles publiquement, mais si vous êtes administrateur de serveur, un conseil : utilisez top/htop (en espérant que chaque site possède son propre user et FPM) et vérifiez vos logs avec de bons « grep », et enfin, créez des jail custom sur fail2ban… Également, whitelistez les moteurs de recherche comme Google et Bing car ceux-ci déclenchent de nombreuses 404 et il serait dommage de déréférencer vos sites hébergés.
Pourquoi tous les hébergeurs n’appliquent-ils pas ces sécurités ?
La détection fine des attaques et le blocage automatique des attaquants est une solution très efficace. Pourtant, tous les hébergeurs n’appliquent pas ce genre de sécurités. Pourquoi ?
Si l’adresse IP d’un utilisateur légitime déclenche la sécurité par accident, il perd l’accès à son site. On appelle cela un « faux positif ». Et vers qui va-t-il se tourner pour diagnostiquer l’origine du blocage et se faire débloquer ? Vers son hébergeur.
A ma connaissance, à de rares exceptions près, la plupart des hébergeurs n’ont pas envie d’utiliser leur temps pour cela. Parfois ils sont même difficilement joignables. En pratique, extrêmement peu d’hébergeurs semblent appliquer ce type de sécurités.
Ne pas appliquer ces sécurités a deux effets principaux :
Pour l’hébergeur : cela réduit drastiquement le nombre d’appels et de tickets reçus… Donc les coûts. Cependant, cela augmente drastiquement la charge serveur (l’utilisation inutile de ressources). Chacun fait donc son calcul… Payer des humains, ou payer des machines… Pour beaucoup, le choix semble se tourner vers les machines. Que ceux-là n’osent pas me parler d’éco-responsabilité.
Pour les clients : cela réduit dangereusement le niveau de sécurité final de vos sites web, laissant champ libre aux attaquants et pouvant causer des lenteurs.
Chez LRob, notre but n’est pas de pratiquer des prix planchers et de vous laisser vous faire attaquer et sans support. Nous n’avons pas peur de recevoir vos tickets, emails et appels. Nous restons à votre disposition et ajustons les sécurités en fonction de vos besoins spécifiques. Ainsi, vous êtes bien protégés, conseillés, et débloqués rapidement si besoin. Choisissez votre hébergement WordPress maintenant !
Au final, quel impact pour LRob ?
Nous n’avons pour l’heure subi aucune lenteur causée par ces attaques 🚀 (car nous sommes encore très loin d’une saturation serveur grâce à un taux de remplissage raisonné et une optimisation permanente).
Aucune attaque réussie n’a été détectée. Et toujours aucun site piraté à déplorer. 🔒
Par ailleurs nous avons retrouvé nos 6% de CPU gaspillés et amélioré encore le niveau de sécurité final.
Nous restons attentifs, car la sécurité à 100% n’existe pas et personne n’est invulnérable. Nous surveillons donc en permanence les nouvelles menaces et adaptons les systèmes de défense en temps réel. Pour que votre site reste performant et sécurisé, quelles que soient les évolutions du paysage cyber. 🚀
Optez pour un hébergement WordPress sécurisé et performant
Un hébergement optimisé ne se limite pas à proposer un espace disque et une bande passante. Il doit anticiper les menaces, protéger activement votre site et garantir une rapidité d’exécution. Votre hébergeur doit aussi vous conseiller au quotidien et vous fournir un vrai support de qualité.
Avec LRob, vous bénéficiez d’un environnement conçu spécialement pour WordPress, capable de détecter, bloquer et s’adapter aux attaques. Au passage, profitez d’un des du plus hauts niveaux de performances, d’un panel simple et intuitif avec le WordPress Toolkit, et d’un support attentionné !
Les choix technologiques et matériels de votre hébergeur impactent directement les performances de votre site web. Pourtant, la plupart des hébergeurs restent vagues sur leurs infrastructures et leurs performances réelles. En tant que client, vous ne savez souvent pas ce pour quoi vous payez.
Chez LRob, nous essayons de faire mieux. Beaucoup mieux. Nous avons une approche transparente : nous mesurons, comparons et optimisons chaque paramètre, chaque choix matériel, pour garantir une vitesse de chargement jusqu’à 10x plus rapide que la concurrence. Nous tentons ainsi de vous proposer les hébergements web spécialisés WordPress les plus rapides. Et comme nous sommes fiers des résultats, nous n’avons aucun mal à vous les dévoiler.
Dans cet article, nous dévoilons donc nos benchmarks CPU et IOPS (SSD NVMe) pour vous expliquer comment nous choisissons nos serveurs. Nous vous montrerons ce qui fait vraiment la différence en matière de performances web.
Sommaire
Quels sont les critères d’un hébergeur web performant ?
Une infrastructure web comporte plusieurs éléments. Entre logiciels, matériel, choix d’infrastructure et politique de remplissage, de suivi, de lutte anti-robots… Tout cela va impacter la vitesse finale de votre site.
Si en tant que webmaster, vous avez très certainement votre rôle à jouer dans l’optimisation de votre site web (et LRob peut vous y aider), l’hébergeur joue un rôle central et auquel vous ne pouvez pas couper.
Décortiquons ce qui compose un serveur web, et l’impact sur les performances de chaque élément. Et voyons ce qu’il en est chez LRob.
Les composants logiciels
Les logiciels d’un serveur web ne sont pas si nombreux. Leur impact peut cependant être drastique sur les performances finales.
Voici donc un résumé des différents composants logiciels et de leur impact.
Serveur front (Apache, nginx, LiteSpeed…)
Il s’agit du serveur HTTP(S) en lui-même. Il communique avec l’extérieur directement et son support de nouvelles technologies comme HTTP/3 ou la compression Brotli peuvent améliorer la vitesse de chargement des visiteurs. Les serveurs nginx et LiteSpeed sont considérés comme les plus performants, là où Apache est le plus compatible.
Chez LRob, nous combinons le meilleur des deux mondes, avec Apache en « back » et nginx en « front », via une astuce technique assez courante appelée « reverse proxy ». Cela permet de maximiser les performances et la compatibilité en même temps, tout en ajoutant le support d’HTTP/3 et la compression Brotli et la mise en cache des fichiers, grâce à nginx.
Configuration serveur front : Au delà du support ou non des nouvelles normes HTTP comme HTTP/3, deux critères principaux se démarquent : le nombre maximal de clients connectés en simultané, durée de vie d’une connexion. Cela détermine directement le nombre de visiteurs maximal supportés. D’autres critères comme le cache de fichiers nginx peuvent rentrer en jeu.
LRob optimise intelligemment ces limites de sorte qu’elles aient la valeur maximale supportée par le matériel, sans saturer les ressources CPU ou RAM. La configuration permet également le cache de fichiers nginx en plus du cache système. Les valeurs peuvent être augmentées à la demande en fonction des cas spécifiques.
Serveur de base de données (MySQL, MariaDB)
La base de données est appelée à chaque visite de page sur le site. L’utilisation d’une version plus récente de MySQL ou MariaDB ainsi que de configurations optimisées amélioreront les performances. MariaDB est généralement considéré comme le plus libre et le plus performant. Les deux sont globalement inter-compatibles.
Actuellement, les serveurs LRob utilisent MariaDB 10.11 et MariaDB 11.4.
Configuration du serveur de base de données : MySQL et MariaDB comportent de nombreux réglages, comme la taille maximale d’une requête ou la taille du cache en RAM. Aucun hébergeur ne communique sur cela. Pourtant, de bons réglages généreux en RAM peuvent décupler les performances de la base de données.
Chez LRob, le buffer innodb est de 32Go minimum, ce qui permet d’inclure la quasi totalité des bases de données en RAM serveur pour des performances maximales.
Versions de PHP
Chaque nouvelle version de PHP est plus rapide que la précédente depuis quelques années. Si votre site et hébergeur sont compatibles, alors il faut toujours opter pour la version la plus récente pour des performances maximales.
Le handler ou « connecteur » PHP fait le lien entre le serveur front et PHP. Celui-ci peut avoir un impact drastique sur les performances. FPM et LSPHP sont les deux plus performants.
LRob utilise FPM avec une instance dédiée par site plutôt qu’une instance générale sur le serveur.
Configuration du handler PHP : Le handler PHP déterminera d’une part les limites de PHP en lui-même (par exemple la durée maximale d’exécution d’un script, ou la quantité de RAM maximale utilisable par un script), mais également le nombre de processus (threads) PHP simultanées qui peuvent tourner, qui détermine finalement le nombre de visiteurs maximal que vous pouvez servir en un temps donné – critère qui dépend aussi de la vitesse finale de votre site-.
Chez LRob, les limites PHP dépendent de votre offre d’hébergement. Elles sont indiquées en toute transparence et sont dimensionnées en cohérence avec le dimensionnement de votre offre. A noter qu’un thread PHP-FPM sur un serveur puissant pourra servir davantage de pages par seconde que sur un serveur peu performant. Ainsi, même avec l’offre initiale LRob (Starter) qui offre seulement 2 FPM, vous pouvez, avec un site bien optimisé, servir plusieurs milliers de pages par minute (plus de 7500 pages/minute).
Support de Cache RAM
Support de cache RAM (Redis, memcached) : Si votre site et votre hébergeur sont compatibles, cela peut décupler les performances de votre site en stockant vos pages et requêtes en RAM serveur.
LRob fournit un cache Redis en standard sur tous ses hébergements.
Composants hardware (matériels)
Le matériel derrière les serveurs web fait une différence majeure sur la vitesse de chargement finale. Plusieurs composants interagissent.
Le CPU
Le processeur des serveurs va directement déterminer la puissance de calcul disponible.
On peut résumer cela en 2 parties : La puissance « single thread », la puissance « multi-thread ». Autrement dit, la quantité de travail réalisable sur une tâche seule qui s’exécute sur un seul cœur de processeur, et la quantité de travail totale réalisable sur tous les cœurs de processeur en même temps.
Grossièrement, la puissance « single thread » détermine la vitesse de votre site lorsqu’il n’y a qu’un seul visiteur, tandis que la puissance « multi-thread » détermine le nombre de visiteurs maximal que vous pouvez accueillir. A noter que lorsque vous utilisez toute la puissance « multi-thread », vous réduisez plus ou moins la puissance « single-thread » en fonction du type de CPU utilisé, comme on le verra dans les benchmarks suivants.
En 2025, LRob choisit des processeurs 12 à 16 cores (24 et 32 threads) chez AMD qui propose les meilleures performances brutes selon nos diverses mesures.
La RAM
La RAM stocke les programmes serveur et les calculs du CPU. Plus le serveur dispose de RAM, plus il pourra contenir de cache (MySQL, Redis, nginx, fichiers) et plus il pourra faire tourner de processus PHP. Là encore, cela affecte le nombre de visiteurs simultanés maximum et les performances obtenues.
En 2025, LRob choisit des serveurs avec 128Go de RAM en standard, de quoi ne jamais être à court et profiter de mises en cache très généreuses pour éviter tout ralentissement.
L’IO du stockage
La capacité de stockage n’est pas un critère de rapidité sur un serveur web. On mesure plutôt les vitesses d’IO, c’est à dire d’input-output disque.
Toute lecture ou écriture de fichiers n’étant pas en RAM serveur utilisera de l’IO, que ce soit une requête MySQL ou la lecture des fichiers PHP et multimédia de votre site. Cela peut avoir un impact monumental sur la vitesse d’un site, surtout en ce qui concerne MySQL qui est généralement le plus sensible aux nombre d’opérations aléatoires chaque seconde (en particulier pour l’écriture, qui ne peut pas être mise en cache RAM).
Le disque dur classique est le plus lent, suivi des SSD en SATA, suivi des SSD NVMe qui sont les plus rapides. Dans le cas de serveurs virtualisés, les disques, quelle que soit leur forme, peuvent être déportés dans un SAN. Dans le cas d’un SAN, le stockage n’est alors plus local, pouvant entraîner une réduction des débits et une augmentation de la latence d’accès.
En 2025, LRob choisit exclusivement des serveurs avec SSD NVMe en RAID local (le plus rapide disponible) pour ne jamais attendre les accès disque !
Choix d’architecture informatique
Deux types de serveurs existent chez vos hébergeurs :
Les serveurs dédiés
LRob utilise uniquement des serveurs dédiés.
Les serveurs virtualisés
Un serveur dédié est une machine physique « normale » qui accueille des services.
Un serveur virtualisé, est un sous-serveur crée à partir d’une machine plus grosse. On parle de « VPS » (virtual private server) ou de « VM » (virtual machine), comportant chacun son propre système d’exploitation. Cela donne une versatilité supérieure à l’hébergeur, mais coûte plus cher en RAM, en espace disque, et une baisse de performances peut avoir lieu en raison de la virtualisation et du nombre de systèmes à faire tourner.
Ensuite, on peut déployer les serveurs de différentes manières :
Serveur LAMP (Linux Apache MySQL PHP) classique : Tout est sur la même machine (dédiée ou virtualisée)
LRob utilise uniquement des serveurs LAMP classiques et locaux sur serveurs dédiés.
Cluster : On sépare chaque applicatif sur une machine différente (dédiées ou virtualisées)
La seconde méthode est plus versatile et peut permettre de supporter de plus gros trafics totaux et peut permettre des économies d’échelle sur les gros volumes avec potentiellement une redondance de service. Mais en contrepartie, complexifie l’architecture et elle peut avoir un coût important en performances. Car comme chaque machine est séparée, cela crée une latence due au réseau et aux différents protocoles utilisés, à chaque accès fichier, à chaque requête MySQL, à chaque exécution de PHP. De plus, les matériels utilisés sont généralement des processeurs avec de nombreux cœurs (32 et plus) mais une faible performance par cœur.
Utilisés à outrance, les clusters n’ont selon LRob de réelle nécessite qu’à partir de dizaines de milliers de visites par minute, par exemple pour les réseaux sociaux ou les sites de services d’état. Pour le commun des mortels qui possède un ou plusieurs sites web, les clusters auront pour principal effet de bien souvent réduire les performance.
D’autant plus que comme vous le verrez en toute fin d’article avec un test de charge sur le site « Copines de bons plans », on peut déjà faire plus de 12.000 visites par minute sur 2 process FPM chez LRob… Et bien plus sur les offres supérieures, pour peu que votre site soit très bien optimisé
Note : Bien que l’infrastructure LRob soit basée sur des serveurs dédiés, les offres que vous commandez sur le portail LRob sont bel et bien des offres mutualisées. Du mutualisé certes très performant, plus performant que ce que vous trouverez en VPS ou même sur serveur dédié à bas coût, mais techniquement ce sont bien des offres mutualisée, c’est à dire que plusieurs sites et utilisateurs sont sur la même machine physique.
Remplissage et blocage d’attaques : gestion de la charge serveur
La charge serveur, c’est l’utilisation moyenne de ressources des machines. Le but étant d’avoir une charge moyenne la plus faible possible, avec une réserve de ressources la plus haute possible. Cela permet que les serveurs supportent les pics de trafic, les pics de charge. Par exemple lorsque l’un de vos articles rencontre un fort succès sur les réseaux, ou qu’on parle de vous à la TV ou la radio, on cherche à tout prix à éviter la saturation serveur.
On devine bien souvent aux performances fluctuantes que les hébergeurs ont des serveurs plein à craquer, pour maximiser leur rentabilité. De plus, ils ne bloquent pas forcément efficacement les attaques de robots pirates, qui sur les sites à faible trafic peuvent représenter jusqu’à 95% de la charge. Imaginez, 95% des ressources de votre hébergement occupé par des robots… N’imaginez pas, c’est réellement ce qu’il peut se passer sans protection.
Et si la plupart des hébergeurs ne bloquent pas les robots, c’est à mon avis par choix stratégique : D’une part, cela incite les clients à passer sur serveur dédié ou offre supérieure (pour cause de lenteurs), et d’autre part, bloquer les attaques génère parfois des faux positifs, c’est à dire des clients qui se bloquent eux-même et feront donc une demande de support, que la plupart des hébergeurs n’ont pas envie de gérer.
En pratique, un serveur trop chargé comme on en voit souvent cause des lenteurs constantes ou occasionnelles sur votre site.
Chez LRob, on tente d’offrir les performances maximales à tout moment. Et pour cela, on applique une politique stricte :
On se fixe l’objectif de ne pas dépasser les 25% de charge moyenne et 50% en pic. Si cela se produit : On diminue la charge à la source (blocage d’attaques ? optimisation d’un site ?) ou on migre les sites les plus lourds et/ou populaires vers une nouvelle machine.
Blocage des attaques à différents niveaux, pour économiser jusqu’à 95% des ressources utiles, tout en protégeant vos sites web des attaques.
Limites intelligentes des process FPM, de sorte qu’aucun site ne sature les serveurs
Contact systématique des propriétaires de sites lents ou très populaires pour proposer des solutions d’optimisation des sites et ainsi réduire la charge serveur
24/7 monitoring des performances serveur et intervention directe en cas d’anomalie
Performances matérielles : Le gap technologique
On l’a vu, le choix du matériel peut joue un rôle drastique sur les performances. Aujourd’hui, nous allons nous focaliser sur les deux éléments essentiels pour traduire les performances d’un site web : La puissance de calcul CPU, et les performances en lecture/écriture disque (IO).
Puissance de calcul (CPU)
Nous avons mesuré un panel assez varié de serveurs afin d’avoir une idée représentative de ce que l’on peut obtenir en fonction du type de serveur choisi.
Le test du jour : Geekbench 6.4, permet de se faire une bonne idée de la puissance de calcul des machines.
Cliquez ici pour en savoir plus sur les « cores » et les « threads ».
Les « cœurs CPU » ou en anglais « CPU cores » permettent chacun d’obtenir une puissance de calcul unitaire pour un programme qui ne serait capable d’utiliser qu’un seul core. Les processeurs modernes ont plusieurs cores. Lorsque l’on utilise tous les cores en même temps, les performances par core baissent (en raison d’autres facteurs limitants, comme la consommation électrique et les températures, la vitesse de la RAM, ou la vitesse des caches internes des CPU).
Pour savoir si une application est capable d’utiliser un ou plusieurs cores, on parle d’application « monothread » ou « multithread ». Certaines applications sont entre les deux.
MySQL est multithread.
Apache et nginx sont un mix single-multithread : chaque thread correspond à un chargement de fichier ou une session HTTP.
PHP est aussi un mix single-multithread : chaque thread correspond à l’exécution d’une page PHP (si plusieurs scripts sont appelés, ils resteront enfermés dans un thread). Autrement dit, un visiteur seul ne peut utiliser qu’un core CPU à la fois.
On comprend que pour les performances maximales, il faut au minimum 2 cores, sinon tous ces programmes devront se partager un seul core de CPU. Et si vous attendez de la visite, vous avez intérêt à avoir bien plus, et à choisir des cores performants !
Voici donc les machines qui passent à la moulinette du Benchmark aujourd’hui :
VM 2 cores Intel Xeon chez PulseHeberg
VM 2 cores Intel Xeon chez Hetzner
VM 2 cores ARM chez Hetzner
VM 4 cores AMD Epyc chez Hetzner
Serveur dédié AMD Ryzen 9 3900 12 cores 24 threads chez Hetzner (serveur en production)
Les performances Single Thread, c’est à dire la puissance brute d’un seul core de processeur. Cela correspond aux performances lorsqu’une seule tâche a lieu (qui détermine la meilleure vitesse de chargement d’une seule page web lorsque le serveur est au repos).
Les performances Multi Thread, c’est à dire la puissance totale supportée. Cela impacte le nombre de visiteurs simultanés maximum.
Les performances par core en Multi Thread, c’est à dire les performances que vous pouvez espérer lorsque le serveur tourne à pleine charge. Cela est obtenu en divisant le résultat des performances Multi Thread par le nombre de cores CPU.
Les données brutes, avec en gras, les serveurs web mutualisés LRob :
Benchmark Geekbench 6.4 sur différents types de serveurs chez Hetzner et PulseHeberg
On peut tirer pas mal de conclusions.
Les performances single thread
Pour rappel, les performances en single thread vont directement affecter la vitesse perçue de votre site web. C’est le plus critique et souvent le plus négligé, car les hébergeurs classiques ont souvent tendance à choisir de très gros processeurs, avec de très nombreux cores, mais peu de performance single thread. Ainsi, ils peuvent accueillir de nombreux sites, mais individuellement, chaque site sera plus lent.
Et la différence peut être majeure, car nos mesures montrent que la vitesse va quasiment du simple au quadruple (x3.841) !
Benchmark serveurs single Thread GeekBench 6.4
Le moins performant étant le single thread sur VPS Intel chez Hetzner, le plus performant étant le single Thread sur VPS AMD R9 9900X chez PulseHeberg. Ce dernier est cependant un OVNI dans le monde des VPS, offrant des performances défiant l’entendement (et malheureusement victime de son succès depuis sa sortie, avec des stocks très limités). Nous n’en tiendrons donc pas spécialement compte pour le moment, mais cela nous donne simplement des perspectives pour l’avenir.
Petite mention pour Pulseheberg qui a le mérite d’indiquer clairement sur son site que les hôtes de virtualisation utilisent des Intel Xeon E5-2680v4 (14 cores 28 threads, 2.4-3.3Ghz).
Les VPS en processeur ARM ont de beaux restes et passent devant nos VM Intel. Ils ne battent cependant pas AMD et ses fameux Epyc, mais il faut se rappeler qu’ARM propose un gain significatif en termes de consommation, ce qui n’est pas anodin pour un datacenter.
On voit d’ailleurs que les CPU Epyc sont quasiment 2x plus performants que les CPU Intel chez Hetzner, avec à l’arrondi, x1.99 d’amélioration.
En comparant le VPS le plus lent et les serveurs dédiés LRob, on voit qu’on est à x2.33 et x3.03 de gain de performances single thread pour respectivement les Ryzen 3900 et 5950x.
En partant du meilleur CPU disponible en virtualisé (AMD Epyc chez Hetzner) et en arrivant sur les dédiés LRob, on fait encore respectivement x1.17 et x1.52 de performances. A noter que le serveur avec un Ryzen 3900 étant en production lors du benchmark, ses performances mesurées sont inférieures aux performances réelles.
Performances en multi thread
En multi, on a deux manières d’appréhender les résultats : d’une part, les performances brutes, et d’autre part voir à quel point le gain est proportionnel au nombre de cores. Avec cette dernière approche, on peut avoir une idée de la puissance et de la saturation de l’hôte des VM. Car nous ne sommes jamais seuls dessus.
Benchmark multi thread Geekbench 6.4
L’approche par « ratio »
Pour les VM 2 cores, où un score parfait serait un x2 en multi : chez PulseHeberg sur la VM 2 cores, on ne fait que x1.54 par rapport à son score single. Là où Hetzner nous fait du x1.8 sur sa VM 2 cores Intel. On peut imaginer que Hetzner a des CPU plus véloces sur ses hôtes ou un taux de remplissage moins important. De même que sur ARM avec x1.79, ce qui s’explique également par le nombre de cores importants des hôtes de virtualisation ARM.
En VM 4 cores, où un score parfait serait x4, Hetzner nous fait un respectable x3.36 sur la VM Epyc. Les CPU Epyc montant à 64 cores et plus tout en conservant une fréquence confortable, cela est très cohérent avec les attentes.
Côté dédié sur les Ryzen sélectionnés par LRob, on a du x5.3 les performances single, que ce soit sur le 3900 ou 5950x, où on s’attendrait à x12 ou x16.
Pour être exact, le 12 cores 24 threads Ryzen 3900 nous sort pile x5.3. Le 16 cores 32 threads Ryzen 5950x nous fait un x5.28. Alors pourquoi ça ne scale pas plus ? Car la fréquence CPU est fortement dynamique sur ces modèles. Ainsi, à faible charge, lorsque seulement quelques coeurs sont utilisés, on bénéficie d’une performance bien supérieure. Autrement dit, on obtient le meilleur résultat sur ces CPU en s’assurant de ne pas avoir une charge trop élevée.
En version desktop pour contrôle du 5950x (il s’avère que j’ai le même à la maison !), avec fréquence optimisée à la main, fixée à 4.4Ghz, on part d’un score single plus faible, mais en multi on fait finalement du x6.84. Résultat sensiblement supérieur au serveur, mais avec une consommation électrique également bien supérieure qui ne serait pas viable en datacenter.
Et pour la VM OVNI, la 8 cores sur Ryzen 9 9900X de PulseHeberg, celle-ci ne nous fait qu’un petit x3.89.. Mais à remettre en perspective, car les performances brutes restent exceptionnelles pour un 8 cores, dépassant le Ryzen 3900 (12 cores) et approchant les performances du Ryzen 5950x. De belles perspectives pour l’avenir.
Performances brutes
Voyons désormais la charge totale supportée par ces diverses machines.
Comparons la meilleure machine Intel dual core à nos dédiés : Le Ryzen 3900 en prod fait 6.89x le score. Le Ryzen 5950x, x8.86 le score.
Pour info, j’ai déjà vu des machines du type de ces 2 cores VM Intel héberger 50 sites sans trop de problème. Ce qui signifie qu’avec 7x les performances on pourrait héberger 350 sites. Cependant, on a fait le choix de s’arrêter autour de 200 à 250.
Face au plus véloce Epyc 4 cores : Le Ryzen 3900 en prod fait 1.86x le score. Le Ryzen 5950x fait 2.39x le score.
Performances par core
Sur les CPU de nos dédiés, les performances single core sont bien supérieures à la quasi totalité des serveurs, mais chutent en multi par rapport à ARM ou Epyc.
C’est un choix : En ne remplissant pas trop de tels serveurs, c’est ainsi que l’on obtient des performances drastiquement supérieures dans la vie de tous les jours, tout en ne s’écroulant pas totalement lors des forts pics de charges. Le but étant de faire en sorte que même les pics de charge soient sous les 50% d’utilisation totale.
Benchmark performances par core Geekbench 6.4
Donc oui, on chute en performances par core… Mais d’un autre côté, on a un bien plus grand nombre de cores ! Moralité : Pour conserver les performances maximales, il faut faire en sorte de ne jamais arriver dans ce « worst case scenario » (et c’est ce que l’on fait chez LRob !).
Performances IO (lecture/écriture)
La vitesse d’IO est la vitesse de lecture et écriture sur le disque de votre serveur. Cela a un impact pour de nombreux éléments, mais MySQL (et MariaDB) est l’élément qui bénéficie certainement le plus d’un excellent IO. Et qui dit de meilleures performances MySQL, dit un site plus rapide, un processeur qui n’attend pas pour que les opérations disque se complètent, et finalement, des performances optimales.
Pour cette partie on a simplifié les tests pour des raisons pratiques en réduisant le nombre de machines testées à celles qui sont les plus pertinentes.
On utilise le benchmark Linux « fio ». La commande de benchmark utilisée nous produit 75% de lecture et 25% d’écriture, le tout en fichiers aléatoires de 4K :
Comme beaucoup, PulseHeberg utilise probablement des SSD SATA classiques pour ses VM Intel, ce qui se traduit par le plus faible score ici. En revanche, sur les offres « Performance Cloud », ils ont manifestement sélectionné de bons disques NVMe, prenant la tête de ce benchmark.
Côté ARM et Hetzner, on est probablement en SSD NVMe ou en SATA avec carte contrôleur RAID. Les débits sont corrects mais sans plus. De plus, si un SAN est utilisé, alors ce débit peut varier au fil de la journée.
Sur serveur dédié avec RAID de SSD NVMe local, on obtient de très solides performances. La différence entre nos deux machines est de l’ordre de la marge d’erreur, probablement due au fait que le serveur à base de Ryzen 3900 soit en prod.
En écriture (le plus critique pour MySQL), on est 8.1x plus rapides que la machine la plus lente, et 2.76x plus rapides que la VM ARM d’Hetzner (qui fait déjà un score respectable pour un VPS).
En comparaison avec la plupart des offres de VPS que vous observez, la moyenne doit se situer entre ces deux-ci, avec des serveurs LRob autour de 5x plus rapides que la norme trouvable sur les VPS.
En pratique, cela se traduit par un serveur MySQL qui exécute les tâches rapidement et n’est jamais saturé, et par conséquent, des sites toujours les plus réactifs possibles. Dans l’absolu, nous n’avons jamais observé de saturation de l’I/O disque sur une telle configuration en utilisation normale.
Comment LRob choisit-il ses serveurs ?
Bien-sûr, le critère N°1 est la performance.
Les serveurs virtuels ayant des performances trop aléatoires sont hors de question pour la production web.
Pour répondre à nos exigences, les serveurs dédiés avec SSD NVMe et 128Go de RAM sont un pré-requis indiscutable.
Concernant les CPU, on choisit ceux qui ont les meilleures performances single core, tout en offrant de solides performances en multi.
Le partenaire principal choisi pour les serveurs LRob à ce jour est l’indétrônable Hetzner qui brille par son éco-responsabilité et la qualité de son support avec une équipe dans le datacenter en 24/7.
Pourquoi ne pas choisir des processeurs Epyc ?
Cette question est légitime. Avec un Epyc 32 cores ou plus, on obtiendrait une capacité totale bien supérieure. Mais ce serait un mauvais choix stratégique pour 3 raisons :
D’une part, en charge modérée, nous obtenons de meilleures performances finales pour chacun des sites hébergés, en utilisant des Ryzen. En single core, notre 5950x est jusqu’à 1.52x plus performant qu’un Epyc.
D’autre part, il y a le coût : les machines Epyc valent bien très cher, prenant donc davantage de temps à être amorties.
Enfin, cela augmente le risque inutilement : rentabiliser une machine Epyc voudrait dire mettre énormément de sites dessus. Or, LRob pour la fiabilité et l’évolutivité, nous pensons qu’il vaut mieux avoir un peu plus de serveurs de taille moyenne que moins de gros serveurs. Au final on accueille déjà bien assez de sites sur Ryzen sans aucun ralentissement.
Pour le moment, ce n’est pas encore d’actualité, mais on garde bien-sûr un oeil sur les sorties de CPU et sur ce que les hébergeurs proposent.
Qu’en est-il du réseau ?
La consommation réseau est souvent surestimée, ou bien les lenteurs lui sont injustement attribuées. Un site lent ne signifie pas un réseau lent, les lenteurs proviennent plutôt d’un serveur lent, qui peine à générer les pages et/ou d’un site mal optimisé.
La moyenne d’utilisation réseau d’un serveur mutualisé dépasse rarement les 50Mbit/s, avec une moyenne autour de 10Mbit/s (merci aux webmasters de bien optimiser leurs sites !).
Or, tous les serveurs sont gigabit, donc 1000Mbit/s disponibles. On a de la marge… !
Au final, ce sont davantage les sauvegardes et les migrations, qui bénéficient de ces débits importants.
Quelles sont les performances chez LRob
En pratique, que donnent les performances de LRob par rapport aux autres hébergeurs ?
Sans pouvoir citer les hébergeurs source (légalement on peut être accusé de dénigrement), on peut cependant vous dire que LRob fait mieux que la quasi totalité des hébergeurs testés.
Nous avons migré des centaines de sites vers l’infrastructure LRob. Il est arrivé une seule fois que l’on observe pas de gain. Ce fut un événement historique et agaçant. Pour tous les autres cas, nous avons observé des sites qui chargent 2 à 10x plus rapidement, avec même des sites chargeant plus de 20x voire 30x plus vite après mise en place d’un cache ou réglage de celui-ci. Et le tout avec des vitesses stables au fil du temps.
Nous avons désormais une belle collection de graphiques avant/après migration dont voici un extrait :
Le site https://dreams-night.fr/ tournait à plus de 3.4s de chargement. Il s’agit d’un site SPIP. Après migration, il passe à 0.18s. Soit près de 20x plus rapide (18.88x). Le graphe n’arrive même pas à le montrer précisément, il faut alors lire « Response » en comparaison à « Avg. Response » (la réponse moyenne).
Le site https://raiddesdentelles.com/ subissait des pics de lenteurs dépassant les 5 secondes… Il est plus de 3x plus rapide après migration chez LRob, avant même l’activation d’un cache. La moyenne de temps de chargement passe à 1.2s.
A ce sjour, le site https://raiddesdentelles.com/ chez LRob a un cache Redis actif. La vitesse de chargement hors cache est toujours à 1s environ, avec un petit pic lors du renouvellement automatique du cache et un gros pic en cas de cron. En cas de fort trafic, cela reste sous les 0.1s désormais. La moyenne est à 0.2s. C’est 15 à 30x plus rapide qu’avant migration, en fonction de comment l’on compte…
Le site https://copinesdebonsplans.fr/ peinait à rester sous les 200ms de réponse moyenne. 200ms étant le seuil critique pour être favorisé par les moteurs de recherche. Après migration, il tombe à 200ms. Après la désactivation de plugins inutiles, il tombe sous les 150ms. Mais attendez de voir l’optimisation du cache…
Après optimisation du cache WP Rocket, le site https://copinesdebonsplans.fr/ descend à 76ms de moyenne. Un tel site peut, sur l’offre minimale d’entrée LRob (Starter), servir plus que les 7500 pages par minute annoncées par l’offre. Nous avons mesuré 12711 pages par minute via un test de charge.Voir le test de charge complet
root@srv01 ~ # ab -c 200 -n 10000 https://copinesdebonsplans.fr/
This is ApacheBench, Version 2.3 <$Revision: 1913912 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking copinesdebonsplans.fr (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests
Server Software: nginx
Server Hostname: copinesdebonsplans.fr
Server Port: 443
SSL/TLS Protocol: TLSv1.3,TLS_AES_256_GCM_SHA384,4096,256
Server Temp Key: X25519 253 bits
TLS Server Name: copinesdebonsplans.fr
Document Path: /
Document Length: 114955 bytes
Concurrency Level: 200
Time taken for tests: 47.842 seconds
Complete requests: 10000
Failed requests: 0
Total transferred: 1153600000 bytes
HTML transferred: 1149550000 bytes
Requests per second: 209.02 #/sec
Time per request: 956.846 ms
Time per request: 4.784 [ms] (mean, across all concurrent requests)
Transfer rate: 23547.42 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 4 881 110.1 897 1005
Processing: 36 65 86.2 53 975
Waiting: 26 55 85.1 43 958
Total: 90 946 79.3 950 1183
Percentage of the requests served within a certain time (ms)
50% 950
66% 962
75% 970
80% 977
90% 1004
95% 1017
98% 1040
99% 1061
100% 1183 (longest request)
Au final, comment être sûr de choisir l’hébergeur le plus rapide ?
Un bon moyen est de choisir l’hébergeur capable de transparence, comme nous le faisons ici.
Nous conseillons de prendre du recul sur les idées pré-conçues, sur le marketing et de regarder les mesures, les données réelles (matériel, architecture), voire encore mieux, d’effectuer vos propres mesures.
Chez LRob, nous faisons tout ce que nous pouvons pour que chacun puisse profiter des ressources maximales pour son site, à tout moment.
Au delà des choix matériels, la politique interne joue un rôle élémentaire également :
Une bonne gestion du taux de remplissage et un blocage efficace des attaques font des miracles. Aussi, en cas de pic, nous vérifions son origine et corrigeons si nécessaire avec le propriétaire de chaque site. Oui, nous prenons la peine de les contacter un par un. Et vous savez quoi ? Ça marche ! Car chacun est toujours heureux d’accélérer son site.
Au final, nous faisons en sorte de tourner autour de 20% de charge moyenne sur les CPU et 50% en pic, ce qui laisse une marge importante pour absorber les pics d’activité sans ralentissement.
Au lieu de trop remplir chaque serveur, nous considérons que le serveur ci-dessous est presque plein, nécessitant le déploiement d’une nouvelle machine pour les futurs clients :
Charge serveur typique d’un serveur LRob en production
Si vous trouvez que cette politique transparente est idéale et souhaitez en bénéficier pour vos sites internet, réservez dès maintenant votre hébergement LRob ! Et soyez parmi les premiers à profiter d’un hébergement sur un Ryzen 9 5950X avec SSD NVMe local !
📌 Éclairer les parcours pro dans les métiers de la sécurité. 📌 Et pour ma partie, parler cybersécurité en autodidacte.
Mais aussi :
Le quotidien d’une militaire dans l’armée de l’air.
Celui d’une agente de sécurité.
Les formations, les réalités du terrain… et les clichés (militaires, geeks… vrais ou faux ?).
Une vidéo enrichissante et accessible, réalisée par Olecio & MERCI BOBBY ! Merci à eux pour leur accueil et à Naïm Aouaichia pour la mise en relation.
J’espère avoir bien représenté notre discipline tout en restant clair pour le grand public. À vous de me dire !
L’essentiel de l’intervention LRob
« Tous les services en ligne sont attaqués tout le temps. »
Sébastien : « Robin, toi tu travailles dans la défense et sécurité, plus précisément dans la cybersécurité. On peut tout de suite voir les menaces ou fantasmes autour du hacking et autres, mais en vrai quel est ton métier ? »
Robin : « Certains des fantasmes sont vrais ! Il y a énormément de métiers en cybersécurité. Le mien, c’est l’hébergement web. Et je travaille donc surtout en défense, cybersécurité, donc j’applique toutes les meilleures pratiques pour m’assurer que les systèmes sont sécurisés. J’ai rejoint un programme de reporting des attaquants (AbuseIPDB) et je report à peu près 1000 attaquants par jour.
Sébastien : « Quel est le but de ces gens qui attaquent 1000 fois par jour des sites… ? »
Robin : « En fait… Tous les services hébergés en ligne sont attaqués tout le temps. Les attaques ciblées sont rares, ce sont plutôt des robots qui attaquent tout. Donc si tu as une adresse email, ou même un serveur email sans adresse, les pirates vont essayer tous les mots de passe sur toutes les adresses possibles. Si tu as un site internet, les pirates vont tenter de s’y connecter (ou infiltrer), de même pour un serveur de fichiers… Bref, tous les services en ligne sont attaqués tout le temps. »
Sébastien : « Du coup, quels sont les risques ? Car tu dis que tu te défends contre, donc souvent, tu gagnes j’imagine, mais les fois où on perd, quel est le risque ? »
Robin : « Le but c’est de ne pas perdre, justement ! Les buts sont souvent financiers… Ils cherchent à contrôler des sites internet pour rediriger vers d’autres sites frauduleux; envoyer des emails de fishing (arnaques, faux emails)… Si ta boîte mail est piratée, ils se fichent généralement de son contenu : les pirates vont envoyer massivement du spam, du fishing, et tu deviens un vecteur d’attaques. Il y a des menaces constantes sur tout ce qui est hébergé en ligne, il y a des attaques permanentes, c’est un fait. Donc l’enjeu de la cybersécurité, c’est d’être prêt de se protéger de ces attaques, de savoir les bloquer. Si demain tu as un site internet, tu peux choisir de travailler avec moi et de le mettre sur mes serveurs, sur l’infrastructure LRob. Mon rôle est de sécuriser l’infrastructure le plus possible et de te fournir les outils pour sécuriser encore davantage ton site internet en lui-même. »
La vidéo complète originale
Vous souhaitez un hébergement sécurisé et rapide avec un support spécialisé WordPress ?
Votre hébergeur favori est heureux de vous annoncer que PHP 8.4 est désormais entièrement pris en charge sur vos hébergements web spécialisés WordPress.
Cette version apporte des améliorations notables au langage, en renforçant la performance, la flexibilité et la lisibilité du code. Voici un aperçu des principales nouveautés qui vous attendent.
Votre hébergeur LRob supporte PHP 8.4
Le support natif de Plesk est arrivé ce 21 Janvier. Cela aura pris 2 mois à Plesk, ce qui est plus long que d’habitude.
L’ajout sur les serveurs LRob et donc disponible pour vos hébergements vient d’être fait ce 24 Janvier.
Cependant nous aimons rester très à jour, et nous ferons donc la mise à jour vers PHP 8.4 progressivement sur les prochaines semaines.
Clients hébergement seul
Si votre site est hébergé chez LRob sans webmastering, tout est prêt pour que vous puissiez passer à PHP 8.4 en quelques clics ! Connectez-vous à votre panneau d’administration Plesk, puis sélectionnez PHP 8.4 dans vos réglages PHP.
Notes importantes :
Lors du passage à PHP 8.4, vous devez réinitialiser la valeur « error_reporting » dans les réglages PHP de sorte que la valeur « E_STRICT » n’apparaisse plus (car celle-ci n’est plus supportée par PHP 8.4).
Après tout changement de version de PHP, pensez à consulter vos logs pour vérifier qu’il n’y a pas d’erreur.
En cas de doute, n’hésitez pas à contacter votre support.
Si vous n’effectuez pas la mise à jour de votre version de PHP, l’upgrade généralisé de tous les sites compatibles vers PHP 8.4 aura lieu au mois d’août 2025.
Quoi de neuf dans PHP 8.4 ?
Des performances encore meilleures pour votre site WordPress
PHP 8.4 a été optimisé pour rendre votre site encore plus rapide. Des ajustements sous le capot permettent de mieux gérer les requêtes et d’accélérer le chargement des pages. Avec cette version, votre site peut être plus fluide et offrir une meilleure expérience utilisateur.
Plus de sécurité et de stabilité
Avec PHP 8.4, vous bénéficiez d’une version renforcée contre les failles de sécurité, tout en étant plus fiable. Cela signifie moins de risques de bugs ou d’erreurs inattendues, surtout si vous utilisez des extensions ou des thèmes bien entretenus.
Compatibilité améliorée
PHP 8.4 inclut des changements qui rendent la gestion de certaines fonctionnalités plus efficace. Pour les utilisateurs WordPress, cela peut se traduire par une meilleure compatibilité avec les extensions modernes et les nouveaux thèmes, tout en simplifiant les mises à jour à l’avenir.
Préparer votre site pour l’avenir
Passer à PHP 8.4, c’est aussi assurer que votre site WordPress est prêt pour les nouveautés à venir. Les développeurs de thèmes et d’extensions adaptent déjà leurs outils pour tirer parti des dernières versions de PHP. En choisissant cette version, vous vous assurez d’utiliser une technologie à jour et soutenue sur le long terme.
Conclusion
En résumé, PHP 8.4 est une mise à jour essentielle qui améliore les performances, la sécurité et la compatibilité de votre site WordPress. Migrer vers cette version vous permettra d’exploiter au mieux votre hébergement web et d’offrir une expérience optimale à vos visiteurs.
Passez à PHP 8.4 dès aujourd’hui ! 🚀 Chez LRob, nous sommes là pour vous accompagner à chaque étape.
Traduire un site WordPress peut être un challenge, en particulier lorsque la traduction automatique d’une page nécessite sa visite au préalable. En tant qu’hébergeur spécialiste WordPress et webmaster spécialiste WordPress, j’interviens régulièrement sur des sites multilingues avec traduction automatique. Pour cela, j’utilise généralement TranslatePress Developer edition, avec l’API DeepL pour opérer cette traduction. Le problème ? Tout traduire d’un coup n’est pas possible nativement. Alors il a fallu trouver une solution. Découvrez cette solution et gagnez des heures !
Problème : La traduction du site complet en une fois n’est pas possible.
Avec TranslatePress, la traduction du contenu de vos pages et articles et surtout de leurs URLs (disponible uniquement en version payante) n’intervient qu’une fois que quelqu’un a visité la page.
Or on voudrait que toutes les URLs soient à jour, pour éviter qu’elles ne changent pour Google et génèrent des redirections 301, voire pire, des erreurs 404.
Sur les petits sites, on peut visiter chaque page et article dans chaque langue.
Pour un site qui a des centaines de pages et articles, tout visiter à la main prendrait des heures.
Alors comment faire ?
Solution : Visiter tout le sitemap automatiquement !
La solution est la suivante : Créer un script qui visite toutes les pages de votre site, en s’appuyant sur son SiteMap.
Votre site n’a pas de SiteMap ? Cliquez ici pour plus de détails.
Un SiteMap est une page, généralement au format XML, que vous pouvez transmettre aux moteurs de recherche (typiquement la Google Search Console) pour lui faciliter le référencement de toutes les pages de votre site. Cela est plutôt indispensable avec les standards actuels.
Si vous n’avez pas encore de SiteMap, cela peut s’ajouter facilement grâce par exemple au plugin WordPress RankMath SEO.
Ensuite vous devez avoir un terminal supportant BASH. Sous Linux et Mac, c’est natif. Sous Windows, il est possible que le powershell supporte BASH, mais alternativement, je vous conseillerais plutôt d’installer WSL. Si vous avez accès SSH à un serveur Linux, cela fonctionne évidemment parfaitement.
Le script
Pour gagner du temps, je me suis aidé de ChatGPT pour faire le script suivant. Celui-ci va récursivement visiter toutes les URLs de votre sitemap.xml via curl.
Vous pouvez appeler ce script par exemple « sitemap_visitor.sh », le rendre exécutable (chmod +x sitemap_visitor.sh), puis l’exécuter avec votre sitemap.
Les deux arguments à indiquer sont :
L’URL de votre site
La durée d’attente entre chaque requête (vous pouvez mettre 0 si vous avez confiance en votre serveur, et en votre consommation d’API de traduction)
#!/bin/bash
sitemap_url="$1"
delay="$2"
declare -A visited_sitemaps # Declare an associative array to track visited sitemaps
# Function to visit all URLs in a sitemap
visit_sitemap_urls() {
local current_sitemap="$1"
# Check if the sitemap has already been visited
if [[ ${visited_sitemaps["$current_sitemap"]} ]]; then
echo "Skipping already visited sitemap: $current_sitemap"
return
fi
# Mark the current sitemap as visited
visited_sitemaps["$current_sitemap"]=1
# Fetch the sitemap
echo "Fetching sitemap from: $current_sitemap"
sitemap_content=$(curl -s -L "$current_sitemap") # Added -L to follow redirects
if [[ -z "$sitemap_content" ]]; then
echo "Failed to fetch sitemap. Skipping."
return
fi
# Extract URLs from the sitemap using grep and sed
urls=$(echo "$sitemap_content" | grep -oP '(?<=<loc>).*?(?=</loc>)')
if [[ -z "$urls" ]]; then
echo "No URLs found in the sitemap. Skipping."
return
fi
echo "Found $(echo "$urls" | wc -l) URLs in the sitemap."
# Visit each URL
while read -r url; do
echo "Visiting: $url"
response_code=$(curl -o /dev/null -s -w "%{http_code}" -L "$url") # Added -L here too
if [[ "$response_code" == "200" ]]; then
echo "Successfully visited: $url"
else
echo "Failed to visit $url: HTTP $response_code"
fi
# Respectful crawling: wait between requests
sleep "$delay"
# Check if the URL is another sitemap
if [[ "$url" == *.xml ]]; then
echo "Found nested sitemap: $url"
visit_sitemap_urls "$url"
fi
done <<< "$urls"
}
visit_sitemap_urls "$sitemap_url"
Vous avez maintenant traduit votre site WordPress en entier !
J’espère que vous aurez gagné des heures grâce à cette astuce !
Pour un site d’une centaine de pages, et 5 langues additionnelles, cela m’a coûté un peu moins de 20€ d’API DeepL (+4.99€ d’abonnement). Votre expérience peut varier, alors pensez bien à définir des plafonds, que ce soit dans TranslatePress ou DeepL.
PS : Cette solution permet également de mettre en cache l’intégralité de votre site après un vidage de celui-ci. 😜
Déjà client LRob et vous souhaitez traduire votre site ?
Les équipes de WordFence (un plugin de sécurité WordPress) nous ont remonté une faille de sécurité CVE-2024-12365, de criticité CVSS 8.5/10.
Qu’est-ce que W3 Total Cache ?
W3 Total Cache est un plugin de cache sérieux, performant et hautement personnalisable, que nous recommandons chaudement. Utilisé par plus d’un million de sites, il se distingue par sa fiabilité, ses nombreux paramétrages et le support du cache Redis.
Quel est le risque de cette faille ?
Le plugin W3 Total Cache pour WordPress présente une vulnérabilité d’accès non autorisé aux données en raison de l’absence de vérification des capacités dans la fonction is_w3tc_admin_page dans toutes les versions jusqu’à, et y compris, la version 2.8.1. Cette vulnérabilité permet à des attaquants authentifiés, disposant d’un accès au niveau Abonné ou supérieur, d’obtenir la valeur nonce du plugin et d’exécuter des actions non autorisées. Cela peut entraîner :
Divulgation d’informations : Les attaquants peuvent accéder à des données sensibles.
Consommation des limites du plan de service : Une surcharge des ressources peut entraîner des interruptions de service et des coûts accrus.
Requêtes web vers des emplacements arbitraires : Les attaquants peuvent inciter l’application web à effectuer des requêtes vers des services internes, y compris la récupération de métadonnées d’instance dans des environnements basés sur le cloud.
Ces actions exploitent la vulnérabilité pour compromettre la confidentialité, les ressources et les services internes des applications concernées. En somme, cela peut permettre le piratage d’un site web.
Quelle est l’ampleur de l’impact ?
Plus de 1 millions de sites touchés, dont quelques dizaines de sites hébergés chez LRob.
Quelles sont les versions touchées ?
Toutes les versions inférieures ou égales à 2.8.1 sont touchées. La première version patchée est la 2.8.2.
Comment LRob a géré le souci ?
90% des sites impactés sont en mise à jour automatiques faites directement par le serveur web, ce qui signifie que les sites été sécurisés automatiquement sous 24h après la mise à disposition du patch.
La faille ayant été révélée le 15 Janvier, nous en avons été alertés le jour même dans l’après-midi et avons fait la mise à jour manuellement pour les sites en mise à jour manuelle le 17 Janvier au matin.
Cela n’a donc eu aucune incidence négative chez LRob.
Pour bénéficier de cette attention privilégiée pour votre site WordPress, hébergez votre site chez LRob !
Si j’ai commencé à entreprendre en 2010, c’est en Septembre 2023 que j’ai décidé de me consacrer pleinement à mon entreprise du web, axée sur l’hébergement, la maintenance et la création spécialisée explicitement sur WordPress. L’année 2024 est donc la première année complète pour le « LRob » que vous connaissez aujourd’hui. Alors, qu’en est-il du bilan ? Spoiler : Les résultats sont très encourageants !
Les nouveautés et améliorations de 2024
2024 fut source de nombreuses améliorations de services chez LRob.
Voici quelques événements marquants :
Ouverture du Portail LRob pour commander directement vos abonnements !
L’activité d’hébergeur WordPress décolle ! Vous avez été nombreux à recommander LRob, et les nouveaux revendeurs et les agences web bien motivées font bien-sûr exploser les chiffres !
Sites hébergés
En 2024 nous avons fait un bond de 89 à 169 domaines hébergés. Soit une augmentation de +90% (presque x2) !
En comptant les sous-domaines, ce sont au total 217 sites qui sont hébergés.
Cela prend également en compte le seul et unique client perdu cette année.
Revendeurs
En 2024, nous avons accueilli 8 revendeurs, soit +400% d’augmentation !
Activité Webmaster 2024
LRob, c’est bien plus qu’un hébergeur : ce sont aussi des actes de webmastering, des créations, refontes, interventions diverses directement sur vos sites. Pour répondre à toutes les situations ! Cela représente plus de la moitié du CA.
10 sites externes réparés post-piratage
6 refontes web
2 créations de sites
Chiffres techniques 2024
Voici quelques données qui intéresseront les plus geek d’entre vous.
Backups : 20To
Upload : Environ 60To/an
Utilisation CPU moyenne : 15%
131 000 tentatives de hack bloquées et dénoncées via AbuseIPDB en 3 mois, soit 43 700 par mois ! On devrait atteindre plus de 500 000 en 2025.
Fréquentation site LRob 2024
La fréquentation du site a fait un bond de +400% (x5), tous les compteurs sont au vert.
Cela peut être attribué aux articles d’actualité et aux posts LinkedIn.
Finances & compta 2024
Chiffre d’affaires
Le CA 2024 est supérieur à 55 000€ (dont près de 10 000€ via le portail LRob pour sa première année)
En 2023, première année incomplète, le CA s’élevait à près de 15 000€, ce qui restait correct pour un lancement sur quelques mois d’activité seulement.
Taxes et Impôts
Le total URSSAF et Impôts est proche de 14 000€.
Frais professionnels
Ces frais non déductibles du CA en auto-entrepreneur.
Les frais couvrent les serveurs, les outils logiciels et télécommunication.
Montant : environ 5 500€.
Bénéfice net
Salaire après impôts et frais :
Pour vivre il m’est resté cette année : 35 600€ (2 970€/mois)
Si ce chiffre est bon pour une première année, il faut rappeler que cela a nécessité des semaines avec bien plus que 35h de travail.
Objectifs, prévisions , nouveautés pour 2025
Objectifs
Plusieurs objectifs et lignes directrices sont fixées :
Progressivement faire pencher la balance pour rendre l’hébergement majoritaire sur les créations/refontes en 2025.
Continuer de fournir une haute qualité de service et de satisfaire nos clients heureux !
Faire le même chiffre ou mieux
Réduire sensiblement le nombre d’heures de travail hebdomadaire.
Prévisions
Le CA devrait augmenter d’au moins +25%, faisant passer les frais pro à plus de 8000€ annuels.
L’embauche ou le changement de forme juridique pourrait arriver entre 2026 et 2027.
Un nouveau serveur mutualisé devrait voir le jour dans la première moitié d’année.
Les backups devraient atteindre 30 à 40To.
Nouveautés à venir (ou déjà en place)
A partir de ce 14 Janvier, un nouveau numéro de téléphone (0221 827 827) pour le support ! En arrière-plan c’est un standard complet en VOIP, qui permet l’arrivée future de collaborateurs, la gestion de messages enregistrés, d’horaires d’ouverture etc. Bien plus versatile pour mieux vous répondre en toute circonstance.
Pour le reste, on va consolider les offres et faire un maximum de bruit, prêcher la bonne parole pour tenter d’héberger la terre entière !
Conclusions
Mon niveau de vie se voit légèrement augmenté par rapport à mon dernier CDI, ce qui pour une première année complète est une grande réussite.
La croissance est claire, nette et sans appel. L’entreprise est viable.
Si l’activité hébergeur augmente drastiquement, elle reste minoritaire par rapport aux créa/refontes et interventions ponctuelles, j’aimerais inverser cette tendance.
Aussi, je dépasse amplement les 35h de travail pour le moment et j’aimerais tenter de réduire le nombre d’heures.
Des collaborations fantastiques ont vu le jour cette année. Accompagner vos projets est un honneur et un bonheur !
Merci à tous, et j’ai hâte de continuer le bon travail avec vous pour 2025 !
Je vous souhaite une belle année avec toute la réussite que vous méritez !
7 jours pour profiter de -50% à vie sur une sélection d’hébergements !
-50% à vie sur des certains hébergements web annuels
Propulsez votre site plus vite que jamais, avec la sécurité maximale et le support compétent dont vous avez toujours rêvé. Le tout avec une éco-responsabilité exemplaire !
Après un an sans faille, Symfony a dévoilé ce 6 novembre 2024 sur son blog huit vulnérabilités d’un coup. Elles affectent différentes versions du framework Symfony. Voici un résumé de ces failles critiques, leurs impacts potentiels, ainsi que les solutions mises en place par Symfony. De quoi comprendre les implications de ces vulnérabilités pour sécuriser vos applications.
Sommaire
Introduction
Même les frameworks les plus réputés comme Symfony ne sont jamais à l’abri de failles de sécurité. Quelle que soit la solution applicative retenue, la vigilance est de mise. Des sécurités comme un pare-feu applicatif ModSecurity ainsi que le blocage automatique des attaquants (fail2ban), combiné à une bonne politique de sauvegarde externalisée, sont indispensables.
Sur les hébergements web sécurisés LRob, nos serveurs Linux aident à votre sécurité applicative grâce à ModSecurity combiné à fail2ban qui bloquent activement les tentatives d’exploitation des failles; des sauvegardes externalisées complètes sont faites chaque jour avec une rétention d’un an. Choisir LRob comme hébergeur, c’est profiter d’une solution d’hébergement simple et sécurisée tout en ajoutant un sysadmin rigoureux, disponible et passionné à votre équipe !
Failles de sécurité Symfony (novembre 2024)
CVE-2024-51736 : Détournement d’exécution de commande sur Windows avec la classe Process
Description Cette faille permet un détournement d’exécution sur les systèmes Windows lorsque le fichier exécutable cmd.exe se trouve dans le répertoire de travail actuel. La classe Process pourrait alors exécuter ce fichier, ouvrant la voie à des détournements malveillants.
Résolution Symfony a corrigé ce problème en forçant la classe Process à utiliser le chemin absolu vers cmd.exe.
Description La méthode Security::login de Symfony ne prenait pas en compte le user_checker personnalisé, ce qui pouvait permettre des connexions non désirées.
Résolution Le correctif implémente désormais un appel au user_checker configuré.
Description En manipulant une chaîne de requête spécifique, des utilisateurs peuvent changer l’environnement ou le mode de débogage du noyau lorsqu’une directive PHP register_argc_argv est activée.
Résolution Le composant SymfonyRuntime ignore désormais les valeurs d’argv pour les environnements non CLI.
Description Avec NoPrivateNetworkHttpClient, certaines informations internes pouvaient encore être exposées, permettant ainsi une énumération d’adresses IP et de ports.
Résolution Le client NoPrivateNetworkHttpClient applique désormais un filtrage des IP bloquées dès le début de la résolution des hôtes.
Description Une validation utilisant une expression régulière pouvait être contournée en introduisant un caractère \n en fin d’entrée, ce qui entraînait une réponse incorrecte de la part du Validator.
Résolution Symfony utilise désormais le modificateur regex D pour garantir une validation de toute l’entrée.
Description En exploitant des caractères spéciaux dans une URL, un attaquant pouvait détourner une redirection basée sur la classe Request pour envoyer les utilisateurs vers un autre domaine.
Résolution La méthode Request::create vérifie désormais que les URI ne contiennent pas de caractères invalides.
Description Dans un environnement sandbox, un attaquant pouvait appeler la méthode __toString() d’un objet, même si cette méthode n’était pas autorisée par la politique de sécurité, ouvrant la porte à un contournement des restrictions du sandbox.
Résolution Le mode sandbox vérifie désormais systématiquement l’appel à __toString() sur tous les objets.
Description Dans un environnement sandbox, des objets ressemblant à des tableaux pouvaient exposer des attributs sans contrôle de sécurité. Cela permettait à un attaquant d’accéder à des propriétés potentiellement sensibles.
Résolution Le mode sandbox contrôle désormais les propriétés des objets de type Array et l’appel à __isset() après vérification de sécurité.
Ces huit failles montrent que même les frameworks les plus robustes comme Symfony ne sont pas à l’abri de vulnérabilités de sécurité. Heureusement, l’équipe Symfony a réagi rapidement pour fournir des correctifs. Et comme il se doit, les failles n’ont été rendues publiques qu’après leur correctif. Si vous utilisez Symfony, assurez-vous de mettre à jour dès que possible pour protéger vos applications et vos utilisateurs.
N’oubliez jamais qu’aucune solution logicielle n’est exempte de failles de sécurité. Votre vigilance doit être continue et les mise à jour régulières restent la meilleure ligne de défense face aux failles de sécurité et aux cybermenaces.
Chez LRob, nos serveurs offrent une sécurité optimale :
Pas de faille Windows : Nos serveurs étant sous Linux, ils ne sont pas affectés par les failles spécifiques à Windows.
Mise à jour applicatif serveur : Les logiciels serveur sont mis à jour quotidiennement et monitorés en 24/7.
Pare-feu ModSecurity : En filtrant activement les requêtes malveillantes, notre pare-feu protège vos applications.
Sauvegardes externalisées : Nous disposons de sauvegardes externalisées quotidiennes pour faciliter la récupération de données en cas d’incident, et vous pouvez aussi réaliser vos propres sauvegardes vers le FTP de votre choix (par exemple via un VPS Storage Cloud de PulseHeberg) via Plesk.
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.
![[Video] LRob Interview «Security and Defence Professions»](https://portail.lrob.fr/wp-content/uploads/2025/01/interview-taffer-comment.jpg)
