Qu'est-ce qu'une attaque DDoS et comment protéger un site web
Découvrez ce qu'est une attaque DDoS, pourquoi elle nuit aux sites web, et quelles méthodes de protection comme CDN, WAF, limitation de débit et surveillance fonctionnent le mieux.
Qu'est-ce qu'une attaque DDoS et pourquoi est-elle dangereuse pour un site web
Une attaque DDoS est un afflux massif de requêtes qui submerge un site web, un serveur ou une connexion réseau. Un visiteur ne causera aucun problème. 10 000 requêtes par seconde, c'est une toute autre histoire.
L'idée est simple : l'attaquant ne « pirate » pas le site de front, mais le surcharge jusqu'à ce qu'il ne puisse plus faire face, et parfois la cible est la page d'accueil, parfois l'API, parfois le formulaire de connexion. Il arrive aussi qu'un service étroit soit attaqué et que tout le site tombe en panne parce qu'il partage une base de données ou un seul serveur sans séparation de charge.
Les conséquences se manifestent rapidement. Les pages se chargent lentement, le panier d'achat cesse de fonctionner, le tableau de bord du compte utilisateur génère des erreurs, le bot de recherche reçoit des réponses 5xx, et les utilisateurs se tournent vers un concurrent. Les dommages réputationnels durent souvent plus longtemps que l'attaque elle-même, surtout si le site était indisponible pendant 20 à 30 minutes pendant les heures de travail.
Une attaque DDoS est dangereuse non seulement à cause du temps d'arrêt, mais elle augmente également les coûts d'infrastructure, déclenche de fausses alertes analytiques et fait que le support rate de vraies demandes de clients. Si le site vend des services, chaque heure de temps d'arrêt nuit aux prospects et aux demandes, et si c'est un média ou un SaaS, la consommation régulière de contenu et la confiance dans le produit en souffrent.
Protection DDoS pour un site web : quelles méthodes fonctionnent vraiment
Il n'existe pas de bouton unique pour la protection DDoS. Une configuration fonctionnelle combine presque toujours plusieurs couches : CDN, WAF, limitation de débit, filtrage de trafic, Anycast et restrictions côté hébergement. Si vous êtes intéressé par une protection pratique du site web contre les attaques DDoS, il vaut également la peine de consulter le matériel sur la sécurité des sites web, car les attaques DDoS sont presque toujours accompagnées d'autres attaques.
Un CDN aide à distribuer les demandes à travers les nœuds et à alléger une partie de la charge sur l'origine. Cela est particulièrement visible pour les pages statiques et les médias : au lieu d'un seul serveur, le trafic rencontre un réseau de points de présence, et l'Anycast fonctionne de manière similaire, mais se concentre sur le routage — la demande va au nœud le plus proche. Pour un grand projet, ce n'est pas un luxe, mais un moyen d'éviter de tomber à cause d'un pic local.
Un WAF filtre les modèles de demandes suspects. Il ne protège pas contre tout, mais il fait un bon travail pour éliminer certains trafics indésirables et bots. La limitation de débit restreint la fréquence à laquelle les demandes peuvent provenir d'une seule IP, sous-réseau ou session. Lorsqu'une attaque se manifeste sous la forme de milliers de demandes identiques à un seul formulaire, les limites commencent rapidement à aider.
Le filtrage de trafic du côté du fournisseur ou de l'hébergeur est important lorsque la ligne de connexion est saturée avant même que la demande n'atteigne votre serveur. C'est ici qu'il vaut la peine de demander à l'avance quels mécanismes la plateforme possède : un centre de nettoyage, un routage en trou noir, une redirection temporaire, et un support sans plan d'incident prêt à l'emploi répond souvent trop lentement pendant une attaque.
La protection au niveau de l'hébergement et du fournisseur est nécessaire non pas comme une option de sauvegarde, mais comme la première couche de réponse, et un serveur peut être renforcé, mais si le fournisseur lui-même ne peut pas couper le trafic indésirable, la ressource sera toujours en panne. Dans un projet réel, la configuration habituelle est une combinaison : CDN en avant, WAF à l'entrée, limites de requêtes, et hébergement qui maintient l'infrastructure opérationnelle.
Comment protéger un site web contre les DDoS avant qu'une attaque ne commence
La préparation commence par l'architecture. Si le site vit sur un seul serveur, sans mise en cache et sans séparation des rôles, il est plus facile de le faire tomber. Il est préférable de séparer la couche web, la base de données et les tâches lourdes en arrière-plan dès le départ, et de verrouiller la zone d'administration par IP ou VPN. Pour les projets à risque plus élevé, il est utile de regarder les approches du cas d'étude S4M — infrastructure de réseau privé : VPN et proxies.
La première étape consiste à supprimer les points d'entrée inutiles, et un panneau d'administration ouvert, un SSH non protégé, des sous-domaines de test supplémentaires et de vieilles méthodes API ne font qu'élargir la surface d'attaque. Si le formulaire de recherche et le formulaire de connexion sont disponibles sans restrictions, ce sont les premières choses que les attaquants cibleront.
La deuxième étape consiste à planifier un scénario de secours. Vous avez besoin d'un plan pour lorsque le serveur principal devient indisponible : un espace réservé statique, DNS de sauvegarde, le contact du fournisseur, et la personne responsable du basculement. Un tel plan ne prend pas beaucoup de place dans la documentation, mais il fait gagner des heures une fois que le trafic commence à arriver par vagues.
La troisième étape est la surveillance. Vous avez besoin de métriques pour RPS, CPU, RAM, temps de réponse, le nombre d'erreurs 5xx, et des anomalies par pays ou IP, et si le site reçoit soudainement 5 000 requêtes vers la page de connexion en 3 minutes, cela est immédiatement visible. Sans surveillance, une attaque ressemble souvent à « quelque chose est lent. »
La quatrième étape consiste à renforcer le serveur. Un CPU et une mémoire supplémentaires ne stopperont pas les DDoS, mais ils permettront de gagner du temps pour activer la protection et éviter de perdre des données. Il est judicieux de vérifier à l'avance les limites de PHP-FPM, les tailles de file d'attente, les paramètres de proxy inverse et les délais de connexion. Un mauvais délai peut transformer un court pic en une longue panne.
La cinquième étape est la mise en cache. Les pages qui peuvent être servies sans toucher à la base de données doivent être mises en cache, ce qui réduit le nombre d'opérations coûteuses et aide à résister à une charge similaire à celle des attaques de bots. La mise en cache ne résout pas le problème, mais elle atténue le choc.
Signes d'une attaque DDoS et comment la repérer à temps
Le premier signe est une forte augmentation du trafic sans raison claire. Si, à 2 heures du matin, le trafic passe de 30 pays en même temps et qu'il n'y a pas de campagne publicitaire sur le site, c'est un signe d'alerte. C'est particulièrement suspect si le pic est concentré sur une page ou une méthode API.
Le deuxième signe est un chargement lent. Le site peut encore s'ouvrir, mais avec un délai de 8 à 15 secondes, et parfois même plus long. Les utilisateurs ne vont pas attendre. Ils fermeront l'onglet.
Le troisième signe est les erreurs 5xx. Celles-ci peuvent être 500, 502, 503 et 504. Le serveur est surchargé, le proxy ne répond pas, l'application ne peut pas suivre les demandes, et si de telles erreurs augmentent avec le trafic, plutôt qu'après une mise à jour, il vaut la peine d'examiner une attaque DDoS.
Le quatrième signe est des problèmes d'authentification et du panneau d'administration. Le site peut encore être visible de l'extérieur, mais se connecter au compte utilisateur, à la zone admin ou au module de paiement commence à échouer. Pour les entreprises, c'est particulièrement désagréable : le client voit « le site fonctionne », mais ne peut pas compléter l'action.
Le cinquième signe est des modèles inhabituels dans les journaux, et des agents utilisateurs répétés, des URL identiques, beaucoup de demandes sans référent, des plages IP étranges. Si un journal de 10 minutes ressemble à un copier-coller, il est temps de vérifier la protection au lieu d'attendre qu'elle « passe d'elle-même ».
Que faire pendant une attaque DDoS sur un site web
La première action est d'activer tous les mécanismes de protection préparés. Activez le profil WAF, les limites de requêtes, le mode challenge si disponible, et le cache au niveau maximum sans risquer la logique commerciale. Si du site web contre les attaques DDoSa été mis en place à l'avance, c'est une question de minutes. Sinon, la situation est beaucoup pire.
La deuxième action consiste à contacter immédiatement le fournisseur d'hébergement ou le fournisseur d'infrastructure. Ne vous contentez pas d'envoyer un message de chat — fournissez des détails : l'heure de début de l'attaque, les URL affectées, le modèle de trafic, des captures d'écran de graphiques et les adresses IP des journaux. Plus la description est précise, plus le support peut activer rapidement le bon filtre.
La troisième action consiste à restreindre temporairement les points d'entrée vulnérables. Vous pouvez verrouiller la zone d'administration par IP, désactiver les formulaires lourds, passer une partie du site en mode lecture seule, réduire la fonctionnalité de l'API ou retirer temporairement des intégrations inutiles. Oui, c'est gênant. Mais une fonctionnalité réduite est préférable à un site complètement hors service.
La quatrième action consiste à analyser les sources de trafic, et vous avez besoin de journaux, de géographie, de modèles de requêtes, d'en-têtes identiques et de fréquence de requêtes — pas de suppositions. Si l'attaque provient d'un point de terminaison, vous pouvez l'isoler, et si l'attaque est distribuée, l'accent est mis sur le filtrage au niveau du fournisseur et du réseau.
La cinquième action consiste à tenir un calendrier court. Qui a activé la protection, quand le support a été contacté, ce qui a été changé et quel effet a été observé après 5, 15 et 30 minutes. Après l'attaque, cet enregistrement vous aide à comprendre ce qui a fonctionné et ce qui a encore plus fait tomber le site que l'attaque elle-même.
Comment choisir un service ou un hébergement pour la protection DDoS
Le choix commence par le filtrage du trafic. Demandez quels niveaux de protection sont disponibles : au niveau de la couche de liaison, de la couche réseau et de la couche application, et si le fournisseur ne peut que « bloquer par IP », ce n'est pas suffisant pour des attaques complexes. Vous avez besoin de mécanismes qui voient non seulement l'adresse, mais aussi le comportement des requêtes.
Vérifiez le SLA. Le contrat doit préciser les temps de réponse, la disponibilité du service et les procédures d'escalade. Sans ces lignes, vous ne découvrirez le « support 24/7 » qu'après la première attaque, lorsque la réponse arrive 40 minutes plus tard.
La géographie des nœuds est également importante. Si votre base d'utilisateurs se trouve dans 3 régions, mais que le filtrage n'est disponible que dans un seul centre de données, la latence et la perte de paquets augmenteront. Pour un site international, il est préférable de choisir une infrastructure répartie sur plusieurs points de présence.
La compatibilité avec le CMS et la pile de projet doit être vérifiée à l'avance. WordPress, Laravel, Bitrix, Node.js, architecture sans tête — chaque option a ses propres limitations concernant le cache, les proxies et les en-têtes, et un bon service de protection peut toujours ne pas convenir à un site spécifique s'il perturbe l'authentification ou le panier d'achat.
Le support doit être capable non seulement de répondre, mais aussi d'agir. Pendant une attaque, il est important qu'un ingénieur puisse rapidement appliquer une règle au lieu de faire passer le ticket entre les départements. Pour un site web d'entreprise, il est également utile de lire à propos de la structure du site web d'entreprise, car la protection dépend également de la manière dont les pages de connexion, les formulaires de demande et les comptes utilisateurs sont organisés.
Erreurs qui affaiblissent la protection DDoS du site web
La première erreur est l'absence de surveillance. Si les graphiques ne sont pas configurés, l'attaque est remarquée trop tard. Le site est déjà en panne, et l'équipe commence seulement à chercher la cause dans le code, le cache ou la mise à jour du plugin.
La deuxième erreur est des mots de passe faibles et des panneaux d'administration ouverts, et le dDoS va souvent de pair avec des tentatives de deviner l'accès ou de distraire l'équipe. Un panneau de contrôle sans restrictions IP est une mauvaise idée même pour un petit projet.
La troisième erreur est des paramètres de cache incorrects, et parfois après avoir activé le cache, le site devient rapide, mais le panier, l'authentification ou le compte utilisateur se casse. Cela crée un faux sentiment de sécurité, et sous attaque, le problème revient, à un moment plus inopportun.
La quatrième erreur est de ne compter que sur un seul outil. Un CDN sans WAF, un WAF sans limites, un hébergeur sans support — tous ces éléments sont plus faibles qu'une combinaison de plusieurs couches. Une attaque DDoS ne ressemble que rarement à la précédente.
La cinquième erreur est d'ignorer les tests de charge. Si le site n'a jamais été vérifié sous un pic, personne ne sait où il échouera en premier, et un test avec 1 000 requêtes n'est pas le même qu'une attaque, mais il fournit un point de référence utile et révèle des points faibles.
La sixième erreur est de garder tous les services critiques au même endroit. Lorsque le site, la base de données, le mail et l'analyse se trouvent tous sur un seul nœud, un problème entraîne également les autres vers le bas. Ici, il vaut la peine de regarder à l'avance le matériel sur support du site après le lancement, car la protection et le support post-lancement sont étroitement liés.
En résumé : un plan de base pour la protection des sites web contre les attaques DDoS
Commencez par 3 étapes : activez la surveillance, fermez les points d'entrée inutiles et convenez avec votre fournisseur d'hébergement du processus de réponse en cas d'attaque, et si le site fonctionne déjà sous charge, ajoutez un CDN, un WAF et des limites de requêtes. Si le projet est critique pour les ventes, gardez un scénario de secours et les coordonnées de votre fournisseur à portée de main.
Ensuite, vérifiez les journaux, les délais d'attente, le cache et les zones administratives, et la protection mise en place une fois ne vous sauve pas pour toujours, mais elle vous donne du temps lorsque l'attaque a déjà commencé. Et ce temps compte souvent plus que toute l'infrastructure qui l'entoure.
Si le projet est en croissance, la protection du site web doit être révisée après chaque grande version et après chaque changement de trafic, et un nouveau module, un formulaire, une méthode API peuvent ouvrir une charge supplémentaire, et une attaque DDoS trouvera rapidement ce point faible.
