Protection DDoS expliquée : ce dont votre site a besoin avant une attaque

Protégez un site web contre les DDoS en plaçant une capacité et un filtrage suffisants devant l’origine, en masquant ou en verrouillant l’accès direct à l’origine, en séparant les contrôles réseau et applicatifs et en répétant la réponse. Configurez la protection avant une attaque. Pendant une attaque, l’équipe doit exécuter un playbook connu, non décider qui est responsable du DNS, ce qui peut être limité en débit ou si le certificat d’un fournisseur est valide.

DDoS signifie déni de service distribué : de nombreuses sources ou une infrastructure distribuée submergent les ressources réseau, de transport, de protocole ou applicatives d’un service. Le trafic peut être volumétrique, comme des déferlantes UDP ou TCP ; orienté protocole, comme l’épuisement SYN ; ou au niveau HTTP, où il ressemble à des requêtes ordinaires mais consomme un travail applicatif coûteux. Ces couches peuvent se chevaucher, et un site a besoin de contrôles adaptés à l’actif protégé.

Choisissez les bonnes couches de protection

La protection de niveaux 3 et 4 absorbe ou filtre les déferlantes réseau et de transport avant qu’elles ne consomment vos connexions de transit, de pare-feu, d’équilibreur de charge ou de serveur. Une périphérie mondialement distribuée, un réseau Anycast, un service de nettoyage en amont ou un fournisseur de transit peut être nécessaire pour les attaques importantes ou les protocoles non HTTP.

La protection de niveau 7 analyse le comportement HTTP, comme le débit de requêtes, le chemin, la méthode, le coût de réponse, les en-têtes et les signaux client. Elle peut protéger un point de terminaison de connexion ou de recherche contre une déferlante applicative, mais une simple limite globale de requêtes peut bloquer de vrais clients pendant un pic légitime. Les contrôles de niveau 7 nécessitent des seuils adaptés aux routes et une référence de trafic normal.

La résilience applicative réduit les dégâts du trafic qui franchit le périmètre. Mettez le contenu public en cache, bornez les requêtes coûteuses, utilisez des files d’attente, protégez les connexions à la base de données, appliquez des limites de débit par identité et rendez les écritures idempotentes. Un fournisseur DDoS ne peut pas corriger une application qui effectue un travail non borné par requête.

Cloudflare fournit des jeux de règles managées DDoS activés automatiquement pour les zones web prises en charge ainsi que des produits distincts pour une protection plus large des IP, TCP, UDP et du réseau. Fastly peut combiner la diffusion en périphérie, le shielding, les vérifications d’état, les contrôles de débit et ses produits de sécurité, mais le bon service dépend de la nature de l’actif protégé : HTTP, TCP, UDP, DNS ou réseau privé. Confirmez les limites du plan, les protocoles, le périmètre d’atténuation, la journalisation, l’escalade et les conditions commerciales auprès du fournisseur avant de vous y fier.

Préparez l’architecture

1. Cartographiez la surface publique. Inventoriez les enregistrements DNS, noms d’hôte, IP, ports, API, points de terminaison mobiles, services d’origine, dépendances tierces et protocoles non HTTP. Recherchez dans l’historique DNS et les données de certificats les anciens noms et adresses d’origine. Supprimez les enregistrements inutilisés et restreignez les interfaces administratives.

2. Placez le trafic web public derrière la périphérie. Faites passer par proxy les noms d’hôte web et API prévus via la couche de protection. Utilisez TLS vers l’origine, validez l’hôte et le SNI attendus, et maintenez les certificats à jour. Ne publiez pas un enregistrement DNS seul qui pointe vers la même origine, sauf s’il est intentionnellement protégé par un autre chemin.

3. Verrouillez l’origine. N’autorisez que les plages IP ou connexions authentifiées de vos fournisseurs de périphérie et systèmes opérationnels de confiance. Les équivalents Cloudflare incluent les enregistrements proxifiés, les listes d’autorisation IP Cloudflare actuelles et Authenticated Origin Pulls avec certificats clients. Une simple liste d’autorisation IP est utile mais doit être maintenue ; mTLS apporte une preuve plus forte de la relation entre périphérie et origine. Si plusieurs CDN sont actifs, autorisez-les tous et testez la politique lors du basculement.

4. Séparez les politiques par point de terminaison. Les pages publiques, la connexion, la recherche, le paiement, les API, les webhooks et l’administration exigent des comportements de limitation et de challenge différents. Protégez les callbacks de machine à machine par authentification et signatures, plutôt que par des challenges de navigateur. Mettez en cache les réponses publiques sûres afin que le trafic d’attaque n’impose pas un calcul sur l’origine pour chaque requête.

5. Définissez un comportement de défaillance sûr. Déterminez ce que sert le site lorsque l’origine est lente, qu’une dépendance en amont échoue ou que le trafic suspect augmente. Une page de statut statique, un catalogue en cache, une file d’attente ou une fonctionnalité de recommandation désactivée peut préserver le parcours client principal. Ne servez pas de données privées périmées et ne masquez pas un échec d’autorisation derrière une solution de repli générique.

Élaborez le plan de réponse

Rédigez un court runbook mentionnant le responsable d’incident, les responsables réseau et application, le contact sécurité, le chemin d’escalade chez le fournisseur, le responsable de la communication et l’autorité de décision. Incluez les identifiants de compte, noms de zone ou de service, accès d’urgence, adresses d’origine actuelles, liens vers les plages IP des fournisseurs et les étapes pour modifier une règle. Stockez les identifiants de secours de manière sécurisée et testez que les bonnes personnes peuvent les utiliser.

Définissez les déclencheurs et les actions. Les exemples incluent une hausse soudaine des paquets ou de la bande passante, un pic régional d’erreurs, un taux élevé de requêtes HTTP coûteuses, l’épuisement des connexions à l’origine ou une alerte d’atténuation du fournisseur. La première action peut être la vérification et la collecte de preuves, non un blocage agressif. Conservez des échantillons de requêtes, horodatages, en-têtes, signatures de l’attaque, routes affectées et identifiants d’atténuation tout en respectant les exigences de confidentialité et de conservation.

Pour Cloudflare, les jeux de règles et alertes DDoS managés fournissent une base, et des dérogations peuvent ajuster la sensibilité ou les actions pour un trafic défini. Les propres recommandations de Cloudflare préconisent d’analyser le trafic signalé et d’ajuster les règles avec soin lors de la validation de faux positifs potentiels. Sur Fastly, utilisez les journaux de service, l’état de santé, le shielding, les contrôles de débit et la télémétrie de sécurité adaptés à la configuration du produit. Dans les deux cas, utilisez la journalisation ou l’observation non destructive lorsqu’elle est disponible avant de modifier une action large, et ne désactivez jamais la protection de base pour dépanner un seul client.

Testez avant une attaque

Organisez un exercice sur table couvrant la détection, l’escalade, le contact du fournisseur, les changements de règles, l’isolement de l’origine, la communication client, le traitement des preuves et la récupération. Testez ensuite le chemin technique avec un fournisseur ou spécialiste approuvé. Ne générez pas une attaque importante contre la production ou un réseau non consentant. Un test sûr peut valider le DNS, TLS, les listes d’autorisation du pare-feu, les vérifications d’état, les limites de débit, la solution de repli en cache, les tableaux de bord et le retour arrière sans créer de trafic nuisible.

Exercez le basculement et la récupération. Confirmez que tous les CDN actifs peuvent atteindre l’origine, que l’origine fait confiance à leurs connexions, que la purge et la politique de cache restent cohérentes et que le trafic revient progressivement après l’événement. Surveillez un effet de troupeau lorsque le contenu en cache expire ou que les clients réessaient simultanément. Consignez le temps de récupération, l’impact client, les faux positifs, le temps de réponse du fournisseur et toute étape manuelle qui devrait être automatisée ou documentée.

Observez à la fois l’attaque et l’activité. Suivez la bande passante, les paquets, les connexions, les requêtes par seconde, les codes d’état, l’état du cache, les actions WAF, les actions de limitation, le CPU de l’origine, les connexions à la base de données, la profondeur de file d’attente, la latence et la réussite des conversions ou transactions. Alertez sur les écarts par rapport à la référence établie, par région et par route, et pas seulement sur le trafic total.

Les erreurs consistent notamment à supposer qu’un CDN protège un nom d’hôte non proxifié, à autoriser l’accès direct à l’origine, à utiliser une même limite de débit pour chaque route, à bloquer un pays entier comme première réponse, à challenger les webhooks, à se fier à une page de statut plutôt qu’à la télémétrie, à ne tester que le parcours nominal et à ne pas effectuer de revue après incident. Le guide de protection DDoS couvre la couche de périphérie managée ; associez-le au guide WAF et à un CDN résilient.

Pour les concepts actuels de plateforme, consultez Cloudflare DDoS Protection et Cloudflare Authenticated Origin Pulls. Pour la préparation aux incidents, utilisez NIST SP 800-61 Rev. 3. Contactez Optimi pour examiner votre périphérie et votre plan de réponse avant d’en avoir besoin.

Il n’y a que deux choses difficiles en informatique : l’invalidation du cache et nommer les choses.