Aller au contenu principal

Protection DDoS

Fonctionnalité Pro

La protection DDoS est disponible avec la licence Pro. Obtenez votre licence Pro pour y accéder.

Sentinel compte les requêtes de chaque adresse IP, ralentit puis bloque celles qui dépassent largement une navigation normale.

La protection se règle dans l'onglet DDoS de Sentinel > Configuration ; la page Sentinel > Protection DDoS en montre les réglages en vigueur, les bans, la couverture et le trafic. Les adresses jamais limitées sont celles de la carte IP de confiance de l'onglet Général : une seule liste, partagée avec la protection brute-force et avec la détection des menaces, qui se modifie quel que soit le plan, gratuit compris. Un proxy ou un CDN devant votre boutique se déclare dans la carte Derrière un proxy ou un CDN ? du même onglet.

Fonctionnement​

  1. Comptage : chaque requête est comptée par adresse IP sur une fenêtre glissante.
  2. Ralentissement : au-delà du seuil de ralentissement, les requêtes reçoivent une réponse HTTP 429 Too Many Requests avec un en-tête Retry-After. L'adresse n'est pas bannie.
  3. Bannissement : au-delà du seuil de bannissement, l'adresse est bannie pour la durée configurée et apparaît dans la liste des bans.
  4. Libération automatique : les bans expirent d'eux-mêmes. En cas de récidive, la durée augmente progressivement, plafonnée à 24 heures. Les bans décidés par la protection Auto Prepend, avant le démarrage de PrestaShop, gardent la durée de base, même en cas de récidive. Un ban que vous levez, depuis l'écran Protection DDoS ou en ligne de commande, ne compte pas : le ban suivant de cette adresse reprend la durée de base.

Le code 429 est utilisé plutôt que 403 car il signifie « temporaire » : les moteurs de recherche réessaient plus tard au lieu de retirer vos pages de leur index.

Lever un ban​

La liste Adresses IP limitées de cette page ne montre que les bans de limitation de débit. Débannir lève le ban de limitation de débit de l'adresse et remet ses compteurs de requêtes à zéro : l'adresse n'est plus bannie dès sa requête suivante. Elle peut encore être ralentie tant que son réseau est attaqué, car la limite par réseau est partagée avec ses voisines. Un ban brute force ou une entrée de la liste noire manuelle de la même adresse reste en place : ils se lèvent depuis la page Protection brute-force.

Réglages​

Les réglages se font dans l'onglet DDoS de Sentinel > Configuration. Sa carte Paramètres porte les deux contrôles qui couvrent le cas courant :

  • Protection — Désactivé, Surveillance ou Activé.
  • Sensibilité — Souple, Équilibré (défaut), Strict ou Personnalisé. C'est le seul curseur dont la plupart des boutiques ont besoin : il règle pour vous les seuils de requêtes et la durée de ban. Souple tolère plus de trafic avant d'agir ; Strict réagit plus tôt.

Tout le reste se trouve dans la carte Avancé et n'a pas besoin d'être touché pour une configuration normale : les seuils exacts par fenêtre, la durée de ban, le seuil de sécurité, les options robots vérifiés / récidive, les options par réseau / par chemin / pic et le champ DSN Redis décrits plus bas.

Choisir une sensibilité remplit la fenêtre de temps, les deux seuils et la durée de bannissement, pour que vous voyiez ce qu'elle fait ; saisir l'une de ces valeurs à la main bascule la Sensibilité sur Personnalisé. En Personnalisé, un Seuil de ralentissement (requêtes par fenêtre) supérieur au Seuil de bannissement (requêtes par fenêtre) est refusé avant l'envoi du formulaire, avec Le seuil de ralentissement ne peut pas dépasser le seuil de bannissement.

La carte URLs exclues prend un chemin par ligne. Cliquez sur Enregistrer les paramètres, sous les trois cartes, pour enregistrer tout l'onglet.

Quand le plan de la boutique n'inclut pas la protection DDoS, l'onglet affiche à la place des réglages l'invitation au Pro décrite sous DDoS ; pendant une panne du service Sentinel, voir Quand le service Sentinel ne répond pas.

Seul un employé qui peut configurer le module Sentinel modifie ces réglages ; les autres voient l'onglet en lecture seule. Voir Qui peut modifier les réglages.

Réglages en vigueur​

La page Sentinel > Protection DDoS montre les réglages sans les modifier : sa carte Réglages en vigueur donne les valeurs enregistrées de Protection, Sensibilité, Fenêtre de temps (secondes), Seuil de ralentissement (requêtes par fenêtre), Seuil de bannissement (requêtes par fenêtre) et Durée du bannissement (secondes). Son bouton Réglages ouvre l'onglet DDoS ; il n'apparaît que pour un employé qui peut configurer le module Sentinel.

Mode surveillance​

En mode Surveillance, Sentinel compte et rapporte sans rien bloquer. Les statistiques montrent ce qui aurait été bloqué. Utilisez-le quelques jours pour valider les seuils sur votre propre trafic avant de passer la Protection sur Activé.

Ce qui n'est jamais limité​

  • Les IP de confiance : les adresses de la carte IP de confiance, partagée avec la protection brute-force et la détection des menaces, et les IP de maintenance PrestaShop quand cette carte leur fait confiance.
  • Les employés connectés : le travail en back-office génère des rafales pour lesquelles les seuils du front-office ne sont pas dimensionnés.
  • Les robots d'indexation vérifiés : Googlebot, Bingbot et d'autres sont confirmés par résolution DNS inverse puis directe, de sorte qu'un user-agent falsifié n'obtient pas l'exemption.
  • Les URLs exclues, pré-remplies avec les chemins habituels de callback de paiement. Conservez-y vos URLs de notification de paiement : une notification rejetée ne devient jamais une commande. Elles ne sont pas exemptées de la détection des menaces : voir URL jamais bloquées.
  • Les ressources statiques réellement servies par PHP, ainsi que l'exécution en ligne de commande. Une URL qui ressemble à une ressource statique n'est pas exemptée : PrestaShop réécrit vers index.php tout chemin ne correspondant pas à un fichier existant, si bien qu'une requête vers un .css inexistant démarre la boutique en entier et est comptée comme n'importe quelle autre.

Le seuil de sécurité​

Si plus que la part configurée de votre trafic est bloquée sur une heure, Sentinel suspend le blocage de lui-même, affiche un avertissement dans le back-office et continue de compter.

Ce garde-fou existe pour un scénario précis : un reverse proxy non déclaré dans la carte Derrière un proxy ou un CDN ?. Tous les visiteurs sont alors vus sous la même adresse, cette unique adresse dépasse tous les seuils, et la boutique entière se bannirait elle-même. Plutôt que de laisser cela arriver, Sentinel cesse de bloquer et vous prévient.

Pendant que le blocage est suspendu, la page Sentinel > Protection DDoS affiche un bandeau avec la part du trafic qui était bloquée et le seuil de sécurité, et deux boutons : Réglages, qui ouvre l'onglet DDoS et n'apparaît que pour un employé qui peut configurer le module Sentinel, et Reprendre le blocage.

Une fois la configuration corrigée, cliquez sur Reprendre le blocage (ou lancez sentinel:rate-limit resume). Le blocage reprend également seul au bout d'une heure.

Derrière un reverse proxy ou un CDN

Déclarez votre infrastructure dans la carte Derrière un proxy ou un CDN ? de l'onglet Général de Sentinel > Configuration : Sentinel détecte Cloudflare ou un reverse proxy devant votre boutique et propose de lui faire confiance en un clic. Sans cela, Sentinel ignore délibérément les en-têtes transmis et voit l'adresse de votre proxy au lieu de celle de vos visiteurs.

Statistiques​

La carte Trafic analysé (dernières 24 heures) affiche Requêtes analysées, Ralenties, IP bannies (24h) et Part du trafic bloquée. Les chiffres sont agrégés à l'heure plutôt que journalisés à chaque requête, afin que la protection ne devienne pas elle-même un problème de charge.

Le dashboard Sentinel met aussi la protection en avant : un KPI avec les requêtes bloquées sur les dernières 24 heures, et une carte dédiée affichant les bans actifs, les IP bannies sur les dernières 24 heures, les requêtes bloquées et les bannissements les plus récents. Quand le plan de la boutique n'inclut pas la protection DDoS, une invitation à passer à Pro est affichée à la place ; pendant une panne du service Sentinel, voir Quand le service Sentinel ne répond pas.

Couverture​

Un bandeau indique la couverture active :

  • Étendue — la protection Auto Prepend est activée : les requêtes sont filtrées avant le démarrage de PrestaShop.
  • Limitée — seules les requêtes routées par PrestaShop sont filtrées. La protection fonctionne, mais chaque requête bloquée coûte encore un démarrage complet de PrestaShop.

La couverture étendue mérite d'être activée partout où votre hébergement le permet, pour deux raisons :

  • Le coût. Prendre la décision avant le démarrage de PrestaShop prend environ 0,2 ms, contre à peu près 130 ms pour démarrer PrestaShop et ouvrir ses connexions à la base. Sous un flood, c'est la différence entre absorber le trafic et s'y noyer.
  • La portée. Les fichiers PHP qui ne font pas partie de PrestaShop — un script déposé dans un répertoire d'upload, un installeur oublié — n'atteignent jamais le routeur : aucun hook PrestaShop ne peut les voir. Seul cet étage le peut.

Les réglages sont lus dans un petit fichier que Sentinel exporte à chaque sauvegarde, de sorte que cet étage n'a besoin ni de la base de données ni de PrestaShop. Si ce fichier est absent ou illisible, les requêtes passent simplement : la protection peut cesser de fonctionner, mais elle ne peut pas mettre la boutique à terre.

Réglages avancés​

Ces options se trouvent dans la carte Avancé de l'onglet DDoS et sont toutes désactivées, ou vides, par défaut.

Limite par réseau​

Compte les requêtes par réseau — un /24 en IPv4, un /64 en IPv6 — en plus du comptage par adresse. Cela attrape un attaquant réparti sur une plage, où chaque adresse prise isolément reste sous son propre plafond.

Un réseau est seulement ralenti, jamais banni : un /24 peut être tout un pool opérateur ou un bureau, et le bannir couperait tous les visiteurs légitimes derrière lui.

Limites par chemin​

Une règle par ligne, un chemin puis sa limite propre :

/connexion 20
/recherche 40
/module/*/pay 5

La correspondance se fait par préfixe, ou avec des jokers *, et la première règle qui correspond l'emporte. Chaque chemin dispose de son propre quota : naviguer dans le catalogue ne consomme jamais le quota de connexion, et une limite stricte sur la connexion ne pénalise pas la navigation normale.

C'est ce qu'un seuil global unique ne peut pas exprimer : réglez-le assez bas pour protéger le formulaire de connexion et la navigation ordinaire casse.

Débannir une adresse, depuis l'écran Protection DDoS ou en ligne de commande, remet aussi à zéro son compteur sur chaque règle de chemin : sa visite suivante de la page qui l'avait fait bannir repart de zéro au lieu de la faire bannir à nouveau. Le compteur de son réseau est conservé, car ses voisines le partagent.

Resserrement automatique lors d'un pic​

Lorsque le trafic total sur une fenêtre dépasse le seuil de pic, toutes les limites sont divisées par quatre pendant dix minutes, puis réévaluées.

Cela répond à ce que les limites par adresse ne peuvent structurellement pas voir : un flood réparti sur des milliers d'adresses, chacune restant sous son propre plafond. Rien ne paraît anormal individuellement, et pourtant la boutique sature.

Le back-office et sentinel:rate-limit status indiquent tous deux quand le régime est engagé, et Reprendre le blocage le relâche par anticipation.

Redis​

Les compteurs vivent dans des fichiers, locaux à chaque serveur. Si plusieurs serveurs font tourner la même boutique, un attaquant dispose d'un quota complet sur chacun.

Le champ DSN Redis est enregistré, mais il n'a pas d'effet à ce jour : même quand il est renseigné, les compteurs restent dans des fichiers locaux, et les serveurs d'une boutique ne les partagent pas.

La protection Auto Prepend compte et bannit dans ces mêmes fichiers locaux, avant le démarrage de PrestaShop. Débannir une adresse, depuis l'écran Protection DDoS ou en ligne de commande, lève aussi ce ban, mais seulement sur le serveur où vous débannissez : sur une boutique servie par plusieurs serveurs, les autres continuent de refuser l'adresse jusqu'à la fin de son ban.

Ligne de commande​

# Mode, seuils, backend et chiffres de trafic actuels
php bin/console sentinel:rate-limit status
php bin/console sentinel:rate-limit status --json

# Ce que le limiteur pense d'une adresse (ne compte rien)
php bin/console sentinel:rate-limit test 203.0.113.10

# Réinitialiser une adresse : compteurs et ban éventuel, comme Débannir sur la
# page Protection DDoS (les bans brute force et la liste noire sont conservés)
php bin/console sentinel:rate-limit reset 203.0.113.10

# Reprendre le blocage après suspension par le seuil de sécurité
php bin/console sentinel:rate-limit resume

# Écrire les compteurs courants dans la table de statistiques, et les bans
# décidés par la protection Auto Prepend dans la liste des bans
php bin/console sentinel:rate-limit flush

# Supprimer les anciennes statistiques et les compteurs expirés
php bin/console sentinel:rate-limit purge

reset est la procédure de récupération si un visiteur légitime est pris au piège.

Avec la protection Auto Prepend activée, une adresse qui inonde la boutique est bannie avant le démarrage de PrestaShop. Le ban rejoint la liste des bans au prochain chargement d'une page du back-office (après un flood venu de plus de 200 adresses, le reste suit aux pages suivantes), ou en une fois quand flush s'exécute : planifier flush tient à jour la liste, le tableau de bord et sentinel:brute-force list sans que personne n'ouvre le back-office.

Prérequis​

Aucun. La protection fonctionne avec PHP tel quel : aucune extension à installer, aucun paquet à ajouter, aucune configuration serveur à modifier.

Les compteurs sont stockés dans des fichiers, ce qui fonctionne sur tous les hébergements. Redis n'est jamais requis : le champ DSN Redis n'a pas d'effet à ce jour (voir Redis).

Remarques et limites​

  • Adresses partagées : le comptage se fait par IP, donc les visiteurs derrière un NAT d'entreprise, un CGNAT mobile ou un réseau scolaire partagent un même compteur. C'est pourquoi les seuils par défaut sont larges.
  • Stockage des compteurs : les compteurs sont conservés dans des fichiers, locaux à chaque serveur. Ils peuvent être réinitialisés au redémarrage du serveur ; les bans sont stockés en base et ne sont pas affectés.
  • Portée : cette protection couvre les floods applicatifs, le scraping agressif et le trafic de robots. Une attaque volumétrique au niveau réseau sature le serveur avant que le moindre code PHP ne s'exécute, et aucun module PHP ne peut y répondre.