Attaques DDoS expliquées : formes courantes et comment vous en protéger

D'abord la réponse : aucune couche à elle seule n'arrête un DDoS

Une attaque par déni de service distribué est une tentative d'épuiser une ressource dont vous dépendez (votre bande passante, la table de connexions de votre serveur, ou la capacité de votre application à répondre aux requêtes) en utilisant du trafic issu de nombreuses sources à la fois. La chose la plus utile à comprendre est que différentes formes d'attaque épuisent différentes ressources, et qu'une défense qui fonctionne contre une famille ne fait rien contre une autre :

• Les attaques volumétriques remplissent votre tuyau réseau. Une fois votre uplink saturé, ce que vous configurez sur le serveur n'a plus aucune importance ; le trafic doit être absorbé ou rejeté en amont, par la mitigation de votre hébergeur ou un service de scrubbing.
• Les attaques de protocole (épuisement d'état) remplissent les tables de suivi de connexions des serveurs, pare-feux et répartiteurs de charge. On les combat avec des SYN cookies, des timeouts raisonnables et des limitations de débit, en partie sur l'hôte, en partie au niveau de l'edge.
• Les attaques de couche application épuisent votre application elle-même avec des requêtes qui semblent légitimes. Il leur faut des défenses de niveau 7 : mise en cache, limitation de débit, un WAF ou un CDN, et le durcissement de l'application.

Une protection efficace est donc en couches : scrubbing côté fournisseur contre le volume, réglages d'edge et de kernel contre l'état, contrôles applicatifs contre la couche 7, plus une base de règles de pare-feu qui réduit d'emblée votre surface d'attaque. Le reste de cet article détaille chaque famille, puis assemble les couches en une défense concrète.

Les trois familles d'attaques DDoS

Les éditeurs de sécurité classent les attaques DDoS d'une bonne douzaine de façons différentes, mais presque tout ce que vous rencontrerez en pratique se range dans trois familles, distinguées par la ressource qu'elles épuisent.

Attaques volumétriques : remplir le tuyau

L'objectif est la force brute : envoyer plus de trafic que votre lien ne peut en transporter. La forme la plus courante est un simple UDP flood (des datagrammes sans signification à line rate), que la télémétrie de Cloudflare plaçait en tête de la liste des vecteurs de couche réseau fin 2025, avec une croissance de 231 % d'un trimestre sur l'autre.

La variante la plus intéressante est l'attaque par réflexion/amplification. L'attaquant envoie de petites requêtes à des services internet ouverts (résolveurs DNS, serveurs NTP, instances memcached exposées) avec une adresse source usurpée pour ressembler à celle de votre serveur. Ces services vous « répondent » alors, et pour la bonne requête, la réponse est bien plus volumineuse que la question. Les facteurs d'amplification classiques tirés de l'avis de la CISA sur l'amplification basée sur UDP montrent pourquoi les attaquants adorent cette technique :

Avec memcached, un mégabit de trafic amont de l'attaquant peut se transformer en dizaines de gigabits arrivant à votre adresse. Les attaques par réflexion expliquent aussi pourquoi le trafic que vous capturez pendant une attaque semble provenir du port 53, 123, 389 ou 11211 ; les réflecteurs sont des serveurs légitimes qui répondent à ce qu'ils croient être vos requêtes. (Notre guide complémentaire sur l'analyse d'une attaque DDoS avec Wireshark montre comment repérer ces signatures dans une capture.)

Un schéma volumétrique plus récent à connaître est le carpet bombing : plutôt que de se concentrer sur une seule IP, l'attaquant disperse des volumes modérés sur tout un subnet ou sur des milliers de ports de destination, restant sous les seuils de détection par IP tout en saturant la capacité globale. NETSCOUT a recensé 750 à 830 attaques de carpet bombing par jour au second semestre 2025.

Jusqu'où peuvent monter les attaques volumétriques ? Le record public a grimpé à un rythme saisissant : de 3.8 Tbps fin 2024, en passant par une attaque à 7.3 Tbps en juin 2025, jusqu'à une attaque à 31.4 Tbps et 14.1 milliards de paquets par seconde en décembre 2025, portée par des botnets IoT issus de Mirai (Aisuru et ses dérivés) bâtis à partir de routeurs, caméras et boîtiers Android TV compromis. Ce sont des records face aux plus grands réseaux de mitigation au monde, pas des événements ordinaires, mais même un flood multi-gigabit sans rien d'exceptionnel dépasse l'uplink de la plupart des serveurs isolés, ce qui est précisément l'objet de la règle « l'amont d'abord » de la section suivante.

Attaques de protocole : épuiser l'état des connexions

Plutôt que la bande passante brute, ces attaques visent les tables d'état que les serveurs, pare-feux et répartiteurs de charge tiennent pour chaque connexion.

Le classique, c'est le SYN flood. La poignée de main TCP force le serveur à allouer de l'état dès qu'un SYN arrive, pendant qu'il attend l'ACK final qui ne vient jamais. Suffisamment de connexions à moitié ouvertes et la listen queue est pleine : les clients légitimes ne peuvent plus se connecter alors même que la bande passante et le CPU vont très bien. Les SYN floods restent un vecteur de couche réseau du top trois dans les données de Cloudflare, des décennies après leur première description ; ils sont bon marché, efficaces et faciles à générer avec des sources usurpées.

La défense standard, les SYN cookies, encode l'état de la connexion directement dans le numéro de séquence du SYN-ACK, de sorte que le serveur n'alloue rien avant que la poignée de main soit terminée. Linux les active par défaut (net.ipv4.tcp_syncookies = 1), et ils doivent rester actifs sur tout serveur exposé à internet.

Cette famille compte aussi des apparentées : les ACK/RST floods (paquets parasites qui forcent des recherches conntrack), les attaques par fragmentation (fragments incomplets qui monopolisent les buffers de réassemblage), et les connection floods qui terminent la poignée de main puis restent inactives pour occuper des slots. À noter : un pare-feu à état (y compris les règles basées sur le conntrack de votre propre serveur) est lui-même une table d'état qu'un attaquant peut viser, une des raisons pour lesquelles les règles de pare-feu des serveurs très exposés évitent délibérément de suivre certains trafics. Notre guide des règles de pare-feu par défaut explique où se situe cet arbitrage.

Attaques de couche application : des requêtes d'apparence légitime

Les attaques de couche 7 court-circuitent la plomberie et épuisent l'application elle-même : des HTTP request floods contre des endpoints coûteux, du cache-busting (des query strings randomisées qui forcent chaque requête à remonter jusqu'à l'origin), des attaques façon slowloris qui maintiennent des connexions ouvertes en envoyant les en-têtes un octet à la fois, et des astuces au niveau du protocole comme HTTP/2 Rapid Reset (CVE-2023-44487), qui a exploité l'annulation de flux pour générer des centaines de millions de requêtes par seconde en 2023, avant que les implémentations n'ajoutent des contrôles de débit sur les resets.

Ce sont les attaques les plus difficiles à filtrer car chaque requête, prise individuellement, est valide ; la malveillance réside dans le volume et la distribution. Les HTTP floods modernes proviennent majoritairement de botnets et de navigateurs headless qui présentent des empreintes TLS et des user agents plausibles. La mitigation est donc adaptée à l'application : mise en cache agressive pour que les requêtes n'atteignent jamais l'origin, limitation de débit par client et par endpoint, un WAF ou un CDN qui évalue les clients selon leur comportement, et rendre vos endpoints coûteux (recherche, connexion, génération de rapports) bon marché ou protégés par une barrière.

À quelle fréquence cela arrive-t-il ?

Assez fréquent pour que vous le traitiez comme une certitude opérationnelle plutôt que comme un risque marginal. Cloudflare, à lui seul, a bloqué 47.1 millions d'attaques DDoS en 2025, en hausse de 121 % sur un an, et NETSCOUT a recensé plus de 16 millions d'attaques dans le monde sur l'année, dont plus de la moitié multivecteurs : des combinaisons des familles ci-dessus lancées simultanément.

Deux statistiques comptent le plus pour la façon dont vous planifiez votre défense :

• Les attaques sont courtes. 89 % des attaques de couche réseau et 71 % des attaques HTTP se terminent en moins de dix minutes ; même le record de 31.4 Tbps n'a duré que 35 secondes. Une mitigation qui nécessite qu'un humain remarque l'attaque, ouvre un ticket et active le scrubbing finit régulièrement son déploiement une fois l'attaque déjà terminée. La mitigation automatisée always-on est aujourd'hui la norme, pas le scrubbing à la demande.
• Les attaques sont multivecteurs. NETSCOUT a constaté qu'environ 42 % des attaques utilisaient de deux à cinq vecteurs. Se défendre contre une seule famille en ignorant les autres revient simplement à indiquer à l'attaquant sur quel bouton appuyer.

La pile de mitigation, couche par couche

Pensez la défense comme quatre couches, depuis internet vers l'intérieur. Chaque couche arrête ce que les couches situées en dessous ne peuvent pas.

Couche 1 : la mitigation en amont (la seule réponse au volume)

La physique incontournable : si l'attaque est plus grosse que votre tuyau, seul quelqu'un en amont de ce tuyau peut l'arrêter. Un serveur sur un port 10 Gbit/s ne peut pas se sortir par le pare-feu d'un flood à 50 Gbit/s ; les paquets ont déjà gagné au moment où ils atteignent l'interface sur laquelle tournent vos règles.

Les défenses en amont fonctionnent parce qu'elles disposent de plus de capacité et d'un meilleur point de vue que n'importe quel serveur isolé :

• L'absorption anycast et le scrubbing, l'approche des grands réseaux de mitigation et des hébergeurs protégés contre le DDoS : le trafic d'attaque est attiré vers le plus proche d'une multitude de sites, dilué, filtré, et seul le trafic propre est livré. C'est ainsi que les records multi-térabits ont été absorbés, de façon autonome et sans intervention humaine.
• RTBH (remotely triggered blackhole) : un outil d'opérateur réseau qui rejette tout le trafic vers un préfixe cible en bordure du réseau. Cela protège le reste du réseau mais achève le travail de l'attaquant pour l'hôte mis en blackhole ; la pratique actuelle en fait une première réponse grossière, affinée ensuite avec des règles BGP FlowSpec qui ne ciblent et ne rejettent que la signature de l'attaque (protocole, ports, taille de paquet) plutôt que tout.

En tant que client, vous n'opérez rien de tout cela vous-même ; vous choisissez un hébergeur ou un fournisseur de mitigation qui s'en charge, et vous vérifiez que la protection est always-on plutôt que réactive. Étant donné que neuf attaques sur dix sont terminées en moins de dix minutes, cette distinction concentre l'essentiel de la valeur.

Couche 2 : filtrage en edge et limitation de débit

Entre le scrubber en amont et votre application se trouvent des défenses qui coûtent peu et atténuent le milieu du modèle de menace :

• ACL réseau / règles de pare-feu en edge : si votre serveur ne sert que du HTTPS, le trafic vers UDP 11211 ou TCP 23 n'a rien à faire là. Rejeter le trafic non lié au service avant qu'il ne touche le conntrack de votre serveur élimine des classes entières d'attaques. Un pare-feu network-edge en self-service (que nous fournissons sur nos serveurs dédiés) effectue ce filtrage sur le réseau, en amont de votre port.
• Limitation de débit par source : des plafonds sur les nouvelles connexions par seconde et par IP absorbent le bas de gamme des connection floods et le bruit de brute-force. Rudimentaire mais efficace contre les attaques peu sophistiquées ; inefficace contre celles largement distribuées, ce qui n'est pas un problème ; c'est à ça que servent les couches 1 et 4.

Couche 3 : l'hôte lui-même

Les réglages sur l'hôte ne vous sauveront pas d'un flood volumétrique, mais ils déterminent avec quelle aisance vous survivez à tout ce qui est plus petit :

• SYN cookies activés (par défaut sous Linux, à vérifier avec sysctl net.ipv4.tcp_syncookies).
• Une base de pare-feu en default-deny pour que seuls vos services réels acceptent du trafic ; notre article sur les règles de pare-feu par défaut raisonnables fournit un jeu de règles complet et commenté, et si vous hésitez encore sur l'outil à utiliser pour l'écrire, consultez iptables vs nftables.
• Dimensionnement du conntrack et timeouts : sur les serveurs chargés, augmentez net.netfilter.nf_conntrack_max et raccourcissez agressivement les timeouts pour que l'état parasite expire vite, ou dispensez complètement de suivi vos ports de service à fort volume.
• Pas de réflecteur involontaire. L'envers de la table d'amplification ci-dessus : assurez-vous que ce n'est pas votre serveur qui amplifie. Ne faites pas tourner de résolveur ouvert, désactivez monlist sur NTP (corrigé depuis ntpd 4.2.7, mais vérifiez tout ce qui est ancien), et n'exposez jamais memcached en UDP sur internet.

Couche 4 : défenses de couche application

Pour les HTTP floods et leurs cousins : placez un CDN ou un reverse proxy avec mise en cache devant vos applications dynamiques, limitez le débit des endpoints coûteux séparément des endpoints bon marché, maintenez les implémentations HTTP/2 à jour (Rapid Reset et son successeur 2025, « MadeYouReset », sont tous deux neutralisés par des serveurs à jour), et concevez vos systèmes pour que les requêtes anonymes soient cachables par défaut. Si vous exploitez votre propre reverse proxy sur un serveur dédié, limit_req et limit_conn de nginx couvrent une part surprenante du terrain.

Détecter une attaque : les signaux

La plupart des attaques s'annoncent par une anomalie soudaine sur exactement une ressource. À surveiller (et à mettre sous alerte) :

• Bande passante : un trafic entrant plaqué à la vitesse de votre port est la signature volumétrique. Si votre fournisseur trace le trafic avant et après mitigation, la différence, c'est l'attaque.
• Débit de paquets : des millions de petits paquets par seconde pour une bande passante modeste évoquent des attaques par débit de paquets (SYN/ACK floods) plutôt que des attaques par bande passante.
• Connexions à moitié ouvertes : ss -s affichant des compteurs synrecv de l'ordre du millier signale un SYN flood en cours.
• Saturation applicative avec charge système normale : worker pools pleins, temps de réponse qui s'envolent, mais réseau et CPU sans particularité, la signature L7.
• Motifs de port source : des floods entrants depuis le port 53/123/389/11211 signifient que vous recevez du trafic réfléchi.

Quand vous devez savoir précisément ce qui vous frappe (pour écrire un filtre façon FlowSpec ou donner à votre fournisseur des détails exploitables), capturez un échantillon et analysez-le ; c'est le sujet de notre guide d'analyse DDoS avec Wireshark.

Un plan de réponse à incident

Le moment venu, l'ordre des opérations compte plus que l'héroïsme :

1. Confirmez qu'il s'agit d'une attaque, pas d'une panne ou d'un lancement. Vérifiez si le trafic est anormal par sa nature (ports bizarres, sources à l'air usurpé, une seule URL martelée) et pas seulement par son volume.
2. Identifiez le vecteur : via le tableau de bord de mitigation de votre fournisseur ou un échantillon de paquets de 30 secondes. La famille détermine la réponse : volumétrique → en amont ; état → ajuster et limiter le débit ; L7 → mettre en cache et filtrer.
3. Activez la mitigation dont vous disposez déjà. Si la protection de votre hébergeur est always-on, vérifiez qu'elle s'active (graphiques de trafic scrubbé) ; si quelque chose est en self-service (règles de pare-feu en edge, profils de mitigation), appliquez la règle qui correspond au vecteur.
4. Réduisez votre surface en pleine attaque. Désactivez temporairement les listeners non essentiels, activez une mise en cache agressive, placez les endpoints coûteux derrière un challenge si vous avez un WAF.
5. Parlez à votre fournisseur avec des faits précis. « SYN flood, ~4 Mpps, sources usurpées, ciblant 203.0.113.10:443 » obtient une réponse utile bien plus vite que « nous sommes attaqués ».
6. Notez ensuite ce qui a fonctionné. Les attaques se reproduisent. Le filtre qui a arrêté celle-ci devrait devenir un profil enregistré, pas un souvenir.

Questions fréquentes

Un pare-feu sur mon serveur peut-il arrêter une attaque DDoS ?

Il peut en arrêter certains types, pas d'autres, et tout l'enjeu est de savoir lesquels. Un pare-feu sur le serveur atténue efficacement les petits SYN floods, les connection floods et le trafic parasite visant des ports que vous ne servez pas. Il ne peut rien faire contre une attaque volumétrique qui sature votre uplink : ces paquets ont déjà traversé le lien en amont de votre pare-feu, le filtrage doit donc se faire en amont, au niveau de l'edge ou de la couche de scrubbing de votre fournisseur.

Quelle est la différence entre DoS et DDoS ?

Une attaque DoS vient d'une seule source ; le D supplémentaire correspond à « distributed » (distribuée) : de nombreuses sources à la fois, aujourd'hui typiquement un botnet IoT ou une flotte de proxys. Cette distribution rend les attaques à la fois massives (un botnet d'un million de boîtiers Android TV a généré l'actuel record de 31.4 Tbps) et difficiles à filtrer par adresse source, puisqu'il n'existe pas une seule adresse à bloquer ; la mitigation doit plutôt s'adapter à la forme de l'attaque.

Combien de temps durent les attaques DDoS ?

Moins longtemps que ce que la plupart des gens pensent : environ neuf attaques de couche réseau sur dix se terminent en moins de dix minutes, et même les attaques record ont duré moins d'une minute. Cette brièveté joue en faveur des attaquants (les rafales courtes échappent à une mitigation on-demand qui met plusieurs minutes à s'activer), et c'est pourquoi la protection always-on a remplacé le scrubbing façon « appelez-nous quand ça arrive » comme bonne pratique.

Ai-je besoin d'une protection DDoS pour un petit site ?

Oui, en ce sens que vous devriez choisir une infrastructure où la protection est incluse plutôt que de l'acheter dans l'urgence plus tard. Les petits sites se font attaquer pour des raisons peu glorieuses : un utilisateur mécontent avec un abonnement de $20 à un service de booter, un concurrent, ou simplement un voisin de subnet victime collatérale d'un carpet bombing. Comme les attaques coûtent peu cher à lancer et que la protection est désormais incluse sans surcoût chez les bons hébergeurs, la logique économique veut que vous l'ayez avant d'en avoir besoin.

Déploiement chez Serverside

Chaque serveur de notre réseau est protégé par une mitigation DDoS always-on ; les attaques sont détectées et scrubbées automatiquement en bordure du réseau, ce qui (comme cet article l'a, on l'espère, montré clairement) est le seul endroit où les attaques volumétriques peuvent être arrêtées. En plus de cela, nos serveurs dédiés incluent un pare-feu self-service en bordure de réseau, qui vous permet de rejeter le trafic non lié au service avant même qu'il n'atteigne votre port, ainsi que des contrôles de mitigation en self-service pour ajuster la protection à votre workload. Le provisionnement prend moins d'une minute, sur notre propre réseau ASN 55285.

Pour la moitié de la défense qui se joue sur l'hôte, commencez par nos règles de pare-feu par défaut pour un serveur Linux, choisissez votre outillage avec iptables vs nftables, et apprenez à identifier précisément ce qui vous frappe avec comment capturer et analyser une attaque DDoS dans Wireshark. Si vous configurez une machine neuve, notre guide des distributions Linux couvre le choix du système d'exploitation de base.