Comment stopper les attaques DDoS : guide pratique

Comment stopper les attaques DDoS

Personne ne peut empêcher quelqu'un d'envoyer un déluge de trafic : stopper une attaque DDoS, c'est donc garder votre service disponible pendant qu'elle a lieu. Cela demande quatre choses : filtrer le trafic malveillant avant qu'il n'atteigne vos serveurs, absorber ce qui passe, réduire ce qu'un attaquant peut viser et décider à l'avance qui agit quand une alerte se déclenche. En pratique, l'essentiel se joue en périphérie du réseau, pas sur le serveur d'origine.

Une attaque par déni de service distribué (DDoS) utilise de nombreuses machines, souvent un botnet d'appareils détournés, pour inonder une cible afin que les utilisateurs légitimes ne puissent plus y accéder. Voir ce qu'est une attaque DDoS pour les bases.

Identifier d'abord le type d'attaque

La bonne défense dépend de la couche visée :

• Attaques volumétriques et par réflexion (couches 3 et 4) cherchent à saturer votre bande passante, par exemple par réflexion UDP. Seule une capacité supérieure à l'attaque aide : un réseau de périphérie ou un service de nettoyage du trafic.
• Attaques de protocole (couche 4) épuisent l'état des connexions ; le cas classique est l'inondation SYN.
• Attaques de la couche applicative (couche 7) envoient des requêtes d'apparence légitime, comme une inondation HTTP contre une recherche ou une page de connexion. Elles demandent peu de bande passante et se distinguent mal d'un pic de trafic. Plus de détails dans les attaques DDoS de la couche applicative.

Ce qu'il faut mettre en place

• Placer un réseau de périphérie devant l'origine. Un CDN ou un service de périphérie cloud avec protection DDoS intégrée absorbe le trafic volumétrique près de sa source. AWS décrit ce montage, CloudFront avec Shield et WAF, dans son livre blanc sur la résilience face aux DDoS.
• Ajouter un pare-feu applicatif web avec des règles basées sur le débit. Bloquez les schémas malveillants connus et plafonnez les requêtes par client, idéalement par IP et par session. N'oubliez pas qu'un bureau ou un opérateur mobile peut se cacher derrière une seule IP : fixez les limites à partir de l'usage réel.
• Réduire la surface d'attaque. Gardez l'adresse de l'origine privée et accessible uniquement depuis votre fournisseur de périphérie, fermez les ports inutilisés et soumettez les points d'accès coûteux (recherche, connexion, exports) à des limites plus strictes.
• Mettre en cache tout ce qui peut l'être. Chaque requête servie en périphérie est une requête que l'origine ne voit jamais, ce qui amortit les inondations de couche 7 sur les pages cacheables.
• Traiter les inondations SYN dans la pile. Les SYN cookies permettent au serveur de ne conserver aucun état pour les connexions à moitié ouvertes, au prix de la compatibilité avec certaines options TCP. La RFC 4987 décrit les SYN cookies, le filtrage et les autres parades avec leurs compromis.
• Dimensionner et alerter. L'autoscaling gagne du temps face au trafic de la couche applicative, mais fait aussi monter la facture : associez-le à des alertes et à des plafonds.
• Rédiger un plan de réponse. Décidez qui confirme une attaque, qui contacte le CDN, le DNS ou le fournisseur d'accès, et qui informe les clients. Le conseil de la CISA est le même : avoir un plan de communication, d'atténuation et de reprise, et contacter votre administrateur réseau et votre FAI pour confirmer ce que vous observez.

Exemple : une inondation HTTP sur une page de recherche

Une boutique voit sa recherche expirer. La bande passante est normale, mais l'origine est à pleine charge CPU et le journal des requêtes montre des milliers d'appels de recherche par minute depuis quelques centaines d'IP. La solution est en couches : servir des résultats en cache pour les requêtes répétées, ajouter une règle de débit sur le chemin de recherche, soumettre à un défi les clients qui la dépassent et alerter sur le débit de requêtes par chemin pour repérer la prochaine inondation en quelques minutes.

Erreurs courantes

• Se défendre uniquement à l'origine. Un serveur ou un lien unique peut être saturé : la protection en périphérie passe d'abord.
• Faire un null-routing de sa propre IP. Cela stoppe l'inondation en rendant votre service injoignable, ce que voulait l'attaquant. À réserver en dernier recours.
• Ignorer la couche 7. La protection au niveau réseau n'arrête pas des requêtes qui ressemblent à celles d'utilisateurs normaux.
• Pas de référence. Sans les débits normaux par chemin, impossible de distinguer une attaque d'une opération promotionnelle ou d'une publication virale.
• Mettre la protection en place en pleine attaque. Intégrer un fournisseur pendant un incident est lent. Préparez contrat, DNS et contacts à l'avance.

Défense DDoS, tests de charge et supervision

Un test de charge répond à une autre question qu'une simulation DDoS. Servez-vous-en pour savoir combien de trafic légitime votre propre système encaisse, où il se dégrade en premier et si vos limites de débit et votre autoscaling réagissent comme prévu. Commencez par load testing vs stress testing (en anglais), et consultez les causes de la limitation de débit des API (en anglais) pour voir comment les limites apparaissent sous forme de réponses 429 dans un test. Les tests de charge LoadFocus exécutent des tests HTTP contre votre propre site ou API depuis des régions cloud, ce qui convient à ce type de vérification de capacité et de limites de débit.

Ne dirigez aucun outil de charge vers un système qui n'est pas le vôtre et ne traitez pas un test de charge comme un exercice DDoS. Les vraies simulations DDoS suivent les règles des fournisseurs : AWS, par exemple, ne les autorise que via des partenaires pré-approuvés avec des limites de volume fixes, et sa politique interdit de générer le trafic depuis une ressource AWS. Consultez la politique de votre CDN et de votre fournisseur cloud, et prévenez-les avant tout test à fort volume.

Ensuite, continuez à surveiller : des contrôles synthétiques depuis plusieurs régions et des alertes sur le taux d'erreurs et la latence sont souvent le premier signe d'une attaque vue de l'extérieur.

Questions fréquentes sur l'arrêt des attaques DDoS

Puis-je stopper seul une attaque DDoS ?

Seulement les petites, avec des limites de débit et des blocages d'IP. Tout ce qui sature votre bande passante ou épuise votre origine demande un réseau de périphérie ou un service de nettoyage disposant de plus de capacité que l'attaque.

Un CDN arrête-t-il toutes les attaques DDoS ?

Non. Il absorbe la plupart des attaques volumétriques et de protocole en périphérie, mais les inondations au niveau applicatif exigent en plus des règles WAF, des limites de débit et un cache réglé sur votre trafic.

Comment savoir si je subis une attaque DDoS ?

Les signes typiques sont un site soudain lent ou injoignable, un bond des requêtes ou des erreurs et du trafic provenant de nombreuses sources à la fois. La CISA cite des performances anormalement lentes et des sites indisponibles comme symptômes, et note que les attaquants utilisent parfois une attaque comme diversion.

La limitation de débit suffit-elle ?

Elle aide contre les petites inondations et les clients abusifs, mais n'arrête ni une attaque distribuée depuis des milliers de sources ni une inondation volumétrique. Utilisez-la comme une couche parmi d'autres.

Faut-il payer la rançon ?

Non. Payer ne garantit pas la fin de l'attaque et vous désigne comme une cible qui paie. Signalez la demande et activez votre plan d'atténuation.

Puis-je tester ma protection DDoS ?

Seulement dans le cadre des règles de votre fournisseur, généralement via un partenaire agréé et avec une coordination préalable. Pour la capacité et les limites de débit, un test de charge maîtrisé contre votre propre système est le plus sûr pour commencer.