🛡️ Mode Résilience DDoS

Qu'est-ce que c'est et en quoi diffère-t-il de la Limitation de Débit ?

DDoS signifie "Déni de Service Distribué" : de nombreux ordinateurs différents (parfois des milliers, dans un "botnet") attaquent votre site en même temps pour le saturer et le faire tomber.

🐘 Pourquoi WordPress est une cible particulièrement facile

Un fichier statique (une image, un PDF, une page HTML simple) est servi directement depuis le disque : le serveur le lit et l'envoie, sans réfléchir. Une page WordPress ne fonctionne pas ainsi. Chaque visite oblige PHP à démarrer de zéro : charger le noyau WordPress, les extensions actives, le thème, et exécuter plusieurs requêtes à la base de données (MySQL) pour assembler cette page précise avec ses produits, commentaires ou menu. Cela transforme chaque requête en travail de processeur et de base de données, pas seulement de bande passante.

C'est pourquoi un serveur capable d'encaisser sans broncher des milliers de requêtes par seconde pour un fichier statique peut commencer à faillir avec seulement quelques dizaines ou centaines de requêtes par seconde vers des pages WordPress non mises en cache : la base de données atteint sa limite de connexions simultanées bien avant que la connexion réseau ne sature. Quand cela arrive, le site cesse de répondre même pour les vrais visiteurs, même si l'attaque implique un nombre relativement modeste de requêtes comparé à un DDoS classique au niveau réseau.

⚖️ Pourquoi la Limitation de Débit ne suffit-elle pas ?

La Limitation de Débit compte les requêtes par IP : si une IP dépasse la limite, cette IP est bloquée. Mais dans un vrai DDoS, l'attaque ne vient pas d'1 IP — elle vient de centaines ou milliers d'IPs différentes à la fois. Chaque nouvelle IP démarre son propre compteur à zéro, donc elle ne dépasse jamais la limite individuelle, et l'attaque passe inaperçue.

🧮 Comment cela résout-il le problème ?

Au lieu de compter par IP, il compte le trafic TOTAL de votre site (toutes les IPs combinées). Si ce total explose, le "mode flood" s'active : chaque nouveau visiteur (quelle que soit son IP) doit résoudre un petit calcul mathématique via JavaScript avant d'être autorisé à voir la page.

✅ Pour un vrai visiteur : cela se résout automatiquement, en moins d'une seconde, sans qu'il s'en aperçoive. Pour un bot d'attaque (sans moteur JavaScript) : il ne répond jamais correctement et reste bloqué, peu importe son IP.

Comment ça fonctionne en interne

SeenSecure compte le nombre de requêtes reçues par tout le site dans de courtes fenêtres de temps.
Si ce total dépasse le seuil configuré, le "mode flood" s'active pendant une durée minimale (refroidissement), afin que le défi ne s'active/désactive pas constamment si le trafic tourne juste autour de la limite.
Tant que le mode flood est actif, chaque nouveau visiteur reçoit la page de vérification au lieu de la vraie page, jusqu'à ce qu'il résolve le calcul (automatiquement, via JavaScript).
Une fois vérifié, le visiteur peut naviguer normalement pendant la durée configurée (durée du laissez-passer) sans être redemandé.

💥 Exemple réel : un botnet d'environ 4 000 IPs différentes envoie soudainement 15 000 requêtes/minute vers la page d'accueil d'une boutique WordPress sans cache de page complète. Chacune de ces requêtes exécute PHP et plusieurs requêtes SQL pour assembler le panier, le menu et les produits en vedette. En quelques secondes, MySQL atteint sa limite de connexions simultanées et commence à renvoyer des erreurs 500 — non seulement aux bots, mais aussi aux vrais clients qui faisaient leurs achats à ce moment-là. Avec le Mode Résilience DDoS actif, SeenSecure détecte que le trafic total du site dépasse le seuil configuré (par exemple, 15 000 requêtes/min contre une limite de 600-1000) et active le mode flood : les nouveaux visiteurs reçoivent la page de vérification légère au lieu de la vraie page WordPress, une page qui ne sollicite ni PHP complet ni la base de données. Les bots d'attaque, sans moteur JavaScript, restent bloqués là sans générer de charge réelle ; la pression sur MySQL retombe en quelques secondes et la boutique répond de nouveau normalement pour les clients qui résolvent effectivement la vérification.

🔒 Vous n'êtes jamais bloqué hors de votre propre site : les administrateurs déjà connectés, les IPs sur votre Whitelist, et wp-admin/login/cron ne voient jamais le défi, quoi qu'il arrive au trafic.

Paramètres de cette section

Seuil (requêtes/min pour tout le site)

Le niveau de trafic TOTAL à partir duquel une attaque possible est supposée. Commencez haut (600-1000) et baissez seulement si votre site subit de vraies attaques ; le régler trop bas peut déclencher le défi lors de pics de trafic normaux (ex. viralité sur les réseaux sociaux).

Durée du laissez-passer (minutes)

Combien de temps un visiteur ayant déjà résolu le calcul peut continuer à naviguer sans être redemandé.

Refroidissement (minutes)

Une fois activé, combien de temps le mode flood reste allumé après la baisse du trafic, avant de s'éteindre tout seul. Évite qu'il s'allume et s'éteigne constamment si le trafic tourne juste autour de la limite.

💡 Recommandation : laissez-le désactivé si vous n'avez jamais subi ce type d'attaque. Activez-le seulement si votre site est tombé à cause d'une surcharge soudaine de trafic, ou par précaution si vous attendez un pic (lancement, campagne, viralité).

Ce qu'il ne fait PAS (limites honnêtes)

Il ne protège pas les formulaires, les paiements ni les appels API (requêtes non "GET") — les interrompre en cours serait pire que l'attaque elle-même, donc ils sont laissés passer sans vérification.
Il ne remplace pas un CDN (comme Cloudflare) contre les attaques au niveau réseau/connexion — cela protège au niveau applicatif (pages web), pas le trafic réseau brut.

⚠️ Aucun défi n'est infaillible à 100% : ce mécanisme filtre la grande majorité des bots de flood génériques (ceux qui n'exécutent pas JavaScript), mais un attaquant très déterminé qui étudie spécifiquement votre site pourrait, en théorie, reproduire le calcul sans exécuter de JS. Pour le cas réel d'un site WordPress petit à moyen, c'est une amélioration solide et honnête, pas une promesse d'invulnérabilité totale.

❓ FAQ — Foire Aux Questions

🔹 Dois-je toujours l'avoir activé ?

Pas nécessaire pour la plupart des sites. Activez-le si votre site est déjà tombé à cause d'une surcharge soudaine de trafic, ou préventivement avant un événement dont vous attendez un fort trafic (lancement, campagne publicitaire, viralité).

🔹 Pourrait-il bloquer mes vrais clients lors d'un pic de ventes ?

Il ne les bloque pas — il leur demande une seconde de vérification automatique (invisible pour eux) avant d'afficher la page, seulement pendant que le mode flood est actif. Un vrai client avec un navigateur normal passe sans s'en apercevoir. Il est plus probable de déclencher le mode flood lors d'un pic de trafic légitime si le seuil est réglé trop bas — c'est pourquoi il est recommandé de commencer haut (600-1000 requêtes/minute).

🔹 Où activer cela dans le panneau ?

Dans Firewall → Rate Limiting, dans la carte "🛡️ Mode Résilience DDoS" (juste sous la carte "🚀 Première Ligne"). Disponible dans l'offre FREE, sans besoin du PRO. Ne confondez pas les deux cartes : "Première Ligne" s'exécute AVANT même le chargement de WordPress et continue de fonctionner même si la base de données est saturée, tandis que "Mode Résilience DDoS" s'exécute À L'INTÉRIEUR de WordPress avec un seuil par minute configurable. Elles sont indépendantes l'une de l'autre ; il est recommandé de garder les deux activées.

💡 Astuce : si vous lancez une campagne que vous pensez très populaire, augmentez temporairement le seuil (ou désactivez le mode) pendant l'événement, puis réactivez-le ensuite.