Sécuriser un serveur PrestaShop : fail2ban, Cloudflare et DDoS

Pour sécuriser un serveur PrestaShop, on combine plusieurs couches qui fonctionnent ensemble : un système et un PHP à jour, un pare-feu qui n'ouvre que les ports nécessaires, une connexion SSH par clé uniquement, fail2ban pour bloquer les adresses qui devinent les mots de passe ou scannent la boutique, des limites de requêtes dans nginx et Cloudflare devant le serveur, avec la protection contre les attaques DDoS, un pare-feu applicatif (WAF) et le filtrage des robots. S'y ajoutent un back-office protégé, des journaux, une supervision et des sauvegardes. Nous passons ci-dessous chaque couche en revue, avec des exemples de configuration et une liste de contrôle à la fin.

Pourquoi les serveurs de boutiques sont-ils attaqués ?

La plupart des attaques contre les boutiques en ligne ne visent pas une boutique en particulier. Ce sont des outils automatiques qui sondent des milliers d'adresses jour et nuit, à la recherche d'exports de base oubliés (backup.sql), de fichiers de configuration (.env, .git), de pages de connexion et de modules aux failles connues. Le registre Friends of Presta publie régulièrement de nouvelles failles de modules PrestaShop, dont certaines s'exploitent sans connexion. Nous expliquons comment savoir si une boutique a déjà été piratée dans Sécurité PrestaShop : failles CVE et signes de piratage.

Le serveur est la première ligne de défense. Bien configuré, il écarte les scanners avant qu'ils n'atteignent PHP, limite les tentatives de connexion et refuse d'exécuter un script envoyé par un pirate. Sur notre propre serveur, la règle fail2ban contre les scanners a bloqué d'elle-même 8 adresses dans l'heure qui a suivi son activation — toutes cherchaient des fichiers .env et des pages de connexion WordPress… sur une boutique PrestaShop.

Les bases : système, PHP et pare-feu

Aucune configuration ne sert à grand-chose si le serveur tourne avec des logiciels qui ne reçoivent plus de correctifs de sécurité. Commencez par les bases :

PHP pose souvent problème aux boutiques sous PrestaShop 8, qui fonctionne au mieux avec PHP 8.1. Passer à un PHP plus récent impose de mettre la boutique à jour — notre guide Mise à jour PrestaShop sans perte de données explique comment faire.

Dans la configuration nginx, bloquez aussi l'accès aux dossiers qui ne doivent pas être publics et l'exécution de PHP dans les dossiers d'envoi de fichiers. L'exemple officiel de la documentation PrestaShop refuse les requêtes vers des fichiers .php dans img/ et upload/, les fichiers cachés et les dossiers app, config, classes et vendor. Même si quelqu'un envoie un script par un formulaire, il ne pourra pas l'exécuter.

Connexion sécurisée : SSH et back-office PrestaShop

SSH par clé, sans compte root

Un mot de passe SSH peut se deviner, une clé pratiquement pas. Dans /etc/ssh/sshd_config, désactivez la connexion par mot de passe et le compte root, et n'autorisez que certains utilisateurs :

PasswordAuthentication no
PermitRootLogin no
MaxAuthTries 3
AllowUsers admin boutique

Chaque développeur qui travaille sur le serveur doit avoir son propre compte et sa propre clé. Quand la collaboration s'arrête, vous supprimez une clé au lieu de changer un mot de passe partagé.

Le back-office PrestaShop

• Un dossier d'administration unique : l'installeur de PrestaShop lui donne un nom aléatoire. Ne le renommez pas en admin et ne le publiez pas dans des liens.
• Des comptes employés séparés dans Paramètres avancés → Équipe → Employés, sans identifiants partagés. Supprimez tout de suite les comptes des personnes qui ne travaillent plus sur la boutique.
• Une session liée à l'adresse IP : l'option Vérifier l'adresse IP du cookie dans Paramètres avancés → Administration complique la réutilisation d'un cookie volé.
• Un accès depuis des adresses connues : si votre équipe travaille depuis des IP fixes ou via un VPN, réservez-leur le dossier d'administration dans nginx. C'est la protection la plus efficace contre le piratage des mots de passe.
• Un second facteur de connexion : selon l'OWASP, l'authentification multifacteur est la meilleure défense contre la prise de contrôle d'un compte. Si votre version de la boutique ne la propose pas, ajoutez-la avec un module ou limitez le back-office par adresse IP.

fail2ban : bloquer les attaques automatiquement

fail2ban lit les journaux du serveur et bloque dans le pare-feu les adresses qui se comportent comme des attaquants : quelques connexions ratées, une série de requêtes vers des fichiers inexistants, une limite de requêtes dépassée. Le blocage dure un temps défini, et une adresse qui revient est bloquée plus longtemps. C'est une protection simple et efficace contre le piratage des mots de passe et les scanners.

Pour un serveur PrestaShop, ces règles (jails) d'une installation standard de fail2ban sont utiles :

Exemple d'extrait du fichier /etc/fail2ban/jail.local :

[sshd]
enabled  = true
maxretry = 4
findtime = 10m
bantime  = 1h

[recidive]
enabled  = true
bantime  = 1w

Les limites de requêtes se règlent dans nginx avec le module limit_req. Les pages les plus importantes sont celles qui chargent le serveur ou reçoivent des mots de passe : connexion client, back-office, recherche. Nginx répond alors avec un code 429, et fail2ban bloque l'adresse qui insiste.

limit_req_zone $binary_remote_addr zone=login:10m rate=10r/m;

location ~ ^/(fr/connexion|login)$ {
    limit_req zone=login burst=5 nodelay;
    try_files $uri /index.php?$args;
}

Important : derrière Cloudflare, toutes les requêtes arrivent depuis des adresses Cloudflare. Si nginx ne rétablit pas la véritable IP du client (en-tête CF-Connecting-IP), fail2ban bloquera Cloudflare au lieu de l'attaquant, et les limites de requêtes s'appliqueront à tous vos clients à la fois. Les blocages du trafic qui passe par Cloudflare doivent aussi être envoyés à Cloudflare : fail2ban fournit pour cela les actions cloudflare et cloudflare-token.

Cloudflare devant PrestaShop

Cloudflare s'intercale entre vos clients et votre serveur. Quand l'enregistrement DNS de la boutique passe par le proxy (le nuage orange), les visiteurs voient une adresse Cloudflare et le trafic traverse ses filtres. L'offre gratuite comprend déjà :

• La protection contre les attaques DDoS aux couches 3, 4 et 7 — selon la documentation de Cloudflare, sans limite de taille ni de durée d'attaque, quelle que soit l'offre.
• Un WAF avec le jeu de règles gérées gratuit (Free Managed Ruleset) et vos propres règles, par exemple bloquer l'accès au back-office depuis les pays où vous ne vendez pas.
• Une règle de limitation de débit, à réserver plutôt à la connexion ou à la recherche.
• Bot Fight Mode et une option pour bloquer les robots d'IA.
• Le cache des fichiers statiques (images, CSS, JS), qui soulage le serveur. Par défaut, Cloudflare ne met pas en cache les pages HTML, et c'est très bien ainsi : le panier et le compte client doivent toujours être à jour. N'activez pas « Cache Everything » pour toute la boutique.

Choisissez le chiffrement Full (strict), pour que la connexion entre Cloudflare et votre serveur soit elle aussi chiffrée et vérifiée, et rétablissez les vraies adresses des clients dans nginx : module realip, set_real_ip_from avec les plages d'adresses Cloudflare et real_ip_header CF-Connecting-IP. Sans cela, journaux, statistiques et blocages ne voient que des adresses Cloudflare.

Protection contre les attaques DDoS

Une attaque DDoS (déni de service distribué) inonde votre boutique de trafic venant de milliers d'adresses à la fois, pour qu'elle cesse de répondre. On en distingue deux grands types :

• Les attaques volumétriques (couches 3 et 4) : des millions de paquets qui saturent la connexion du serveur. Aucun pare-feu installé sur le serveur ne peut les arrêter, car le lien est saturé avant que les paquets n'arrivent. Seul un filtrage en amont aide, par exemple chez Cloudflare.
• Les attaques applicatives (couche 7, HTTP flood) : des requêtes d'apparence normale vers des pages coûteuses, comme la recherche, les filtres ou le panier. Quelques centaines par seconde suffisent pour que PHP et la base de données décrochent. Ici, les limites de requêtes, le cache et les règles WAF font la différence.

Cloudflare ne vous protège que si l'attaquant ignore l'adresse réelle de votre serveur. S'il la connaît, il envoie le trafic directement et contourne toute la protection. C'est pourquoi il faut :

1. Masquer l'adresse du serveur. Vérifiez tous les enregistrements DNS : des sous-domaines comme ftp, mail ou dev sans proxy trahissent l'adresse. Les e-mails envoyés depuis le serveur de la boutique la contiennent dans leurs en-têtes : passez par un serveur SMTP externe.
2. Changer d'adresse IP après l'activation de Cloudflare. L'ancienne adresse a pu être enregistrée dans des bases DNS historiques.
3. N'accepter le trafic HTTP que de Cloudflare. Dans le pare-feu, n'ouvrez les ports 80 et 443 qu'aux plages de Cloudflare, ou activez Authenticated Origin Pulls, un certificat qui permet à Cloudflare de prouver ses connexions.
4. Soulager le serveur grâce au cache. Chaque image et chaque fichier CSS servis par Cloudflare sont autant de requêtes qui n'atteignent pas PHP. Nous parlons du cache côté boutique dans Accélérer PrestaShop.
5. Prévoir un plan en cas d'attaque. Le mode « I'm Under Attack » de Cloudflare affiche à chaque visiteur une courte vérification du navigateur pendant l'attaque. Il s'active d'un seul clic.

Conseil : fixez des limites de requêtes distinctes, dans nginx et dans Cloudflare, pour la recherche et les filtres de produits. Ce sont les cibles les plus fréquentes des HTTP floods contre les boutiques, car chacune de ces requêtes coûte bien plus cher à la base de données qu'une page ordinaire.

Robots : utiles, malveillants et IA

Une grande partie du trafic d'une boutique vient de robots. Il ne faut pas tous les bloquer :

• Les robots utiles : Googlebot, Bingbot, Google Merchant Center, comparateurs de prix. Sans eux, votre boutique disparaît des résultats de recherche et des annonces. Attention : n'importe qui peut se faire passer pour Googlebot. Google recommande de vérifier l'adresse par une requête DNS inverse (le nom doit se terminer par googlebot.com, google.com ou googleusercontent.com), puis par une requête directe sur ce nom.
• Les robots malveillants : scanners de failles, robots qui devinent les mots de passe, copient vos prix et vos contenus ou créent de faux comptes. Bot Fight Mode, les limites de requêtes, des pièges sur les chemins typiques des scanners (comme /wp-login.php ou /.env) et fail2ban en viennent à bout.
• Les robots d'IA : des crawlers qui collectent des contenus pour les modèles de langage. Certains respectent robots.txt, mais ce fichier n'est qu'une demande, pas un blocage. Si vous ne voulez pas partager vos contenus, activez le blocage des robots d'IA dans Cloudflare.

Protégez les formulaires de contact et d'inscription du spam avec un CAPTCHA, et les connexions avec une limite de tentatives. Vous n'aurez ainsi pas besoin de bloquer des pays ou des réseaux entiers, au risque d'écarter de vrais clients.

Journaux, supervision et sauvegardes

Il faut voir vos protections à l'œuvre. Activez et consultez :

• Les journaux nginx (trafic et erreurs) : ils révèlent les scans, les pics de trafic soudains et les erreurs 5xx.
• Le slowlog de PHP-FPM : les scripts trop lents, souvent le premier signe d'une attaque sur la recherche ou d'un module défaillant.
• Le slow query log de MySQL : les requêtes lentes qui font tomber la boutique dès que le trafic augmente.
• Une supervision externe : disponibilité de la boutique chaque minute, ressources du serveur, expiration du certificat SSL. Les alertes doivent arriver à quelqu'un qui réagira.
• Les sauvegardes : fichiers et base chaque jour, sur plusieurs jours, conservées aussi en dehors du serveur. Une sauvegarde jamais restaurée n'est qu'un espoir : testez la restauration au moins une fois.

Si vous ne savez pas où en sont votre boutique et votre serveur, commencez par un audit de sécurité de la boutique : vous recevez la liste des failles avec leur niveau de risque et le temps de correction estimé.

Liste de contrôle de la sécurité du serveur

Vous préférez ne pas vous en charger vous-même ? Avec notre service Serveur et infogérance PrestaShop, nous préparons le serveur selon cette liste, y transférons votre boutique et nous en occupons au quotidien.

Sources

• Cloudflare : About DDoS protection — protection des couches 3, 4 et 7 sur toutes les offres.
• Cloudflare : Protect your origin server — masquer l'adresse du serveur, trafic réservé à Cloudflare, Authenticated Origin Pulls.
• Cloudflare : Restoring original visitor IPs et plages d'adresses Cloudflare.
• Cloudflare WAF et protection contre les robots dans l'offre Free.
• fail2ban — dépôt officiel (règles et actions, dont cloudflare-token).
• nginx : module ngx_http_limit_req_module.
• PrestaShop : configurer nginx (documentation développeurs).
• OpenSSH : sshd_config.
• Ubuntu Server : mises à jour automatiques.
• PHP : versions maintenues.
• Google : vérifier les robots d'exploration de Google.
• OWASP : Credential Stuffing Prevention Cheat Sheet.
• Friends of Presta : alertes de sécurité PrestaShop.

Questions fréquentes

Vous voulez que quelqu'un sécurise le serveur de votre boutique et le surveille au quotidien ? Écrivez-nous, nous vous dirons par où commencer.

Produits de cet article

Serveur et infogérance PrestaShop (1 mois)

119,00 €

Note sur 5 étoiles d'après () avis

Ajouter au panier

Retour : Blog