Cloudflare dit avoir bloqué 23,2 millions d'attaques DDoS au niveau réseau pendant les six premiers mois de 2026, soit environ 5 343 attaques par heure. Son nouveau rapport met surtout en évidence la croissance des événements hypervolumétriques : 935 attaques ont dépassé 1 térabit par seconde, avec une hausse de 519 % entre le premier et le deuxième trimestre.

Ces mesures ne décrivent pas l'intégralité des attaques sur Internet. Elles proviennent du réseau et des clients de Cloudflare, ce qui donne un observatoire immense mais nécessairement partiel. Elles montrent néanmoins une évolution utile pour les responsables d'infrastructure : les attaques extrêmes se multiplient, tandis que DNS et CLDAP reprennent une place centrale dans les mécanismes de réflexion et d'amplification.

La réponse rapide

QuestionRéponse
Que signifie la hausse de 519 % ?Elle compare le nombre d'attaques réseau dépassant 1 Tb/s entre le premier et le deuxième trimestre 2026.
Combien d'attaques géantes Cloudflare a-t-il bloquées ?935 au-delà de 1 Tb/s sur le semestre, dont 805 au deuxième trimestre.
Toutes les attaques sont-elles gigantesques ?Non. 96,62 % restent sous 500 Mb/s et 90,60 % durent moins de dix minutes.
Quel vecteur progresse le plus ?Les attaques CLDAP ont augmenté de 580 % d'un trimestre à l'autre ; les attaques DNS dominent globalement.
Un CDN suffit-il à protéger un service ?Non. Il faut aussi masquer l'origine, limiter les requêtes et préparer les dépendances qui ne passent pas par le CDN.
Faut-il attendre l'attaque pour régler la protection ?Non. Les règles, seuils, contacts et procédures doivent être testés avant l'incident.

Les attaques au-delà de 1 Tb/s changent d'échelle

Cloudflare classe comme hypervolumétrique une attaque dépassant 1 Tb/s, un milliard de paquets par seconde ou un million de requêtes par seconde. Au deuxième trimestre, l'entreprise a atténué 805 attaques réseau franchissant le seul seuil du térabit, soit plus de six fois le volume du trimestre précédent.

Une telle valeur dépasse largement la capacité de la plupart des liaisons d'entreprise et peut saturer un centre de données non protégé avant que les serveurs applicatifs ne traitent la moindre requête. L'enjeu n'est pas d'acheter une interface réseau équivalente au pic : la défense doit distribuer et filtrer le trafic en amont, sur une infrastructure disposant de capacités et de présence géographique suffisantes.

Le chiffre spectaculaire ne doit pourtant pas masquer le profil ordinaire. Cloudflare indique que 96,62 % des attaques réseau restent sous 500 Mb/s. Ce niveau peut sembler faible à l'échelle d'un opérateur mondial, mais 100 Mb/s suffisent déjà à rendre indisponible un petit serveur ou une connexion limitée. Une attaque n'a pas besoin d'établir un record pour réussir.

Courtes, automatisées et difficiles à traiter manuellement

Plus de neuf attaques sur dix observées par Cloudflare se terminent en moins de dix minutes. Cette brièveté réduit l'efficacité d'une réponse fondée sur un ticket, une réunion puis une règle écrite à la main. Lorsque l'équipe identifie le vecteur, le pic peut être terminé, tout en ayant provoqué une indisponibilité et en étant prêt à revenir sous une autre forme.

La protection doit donc reconnaître automatiquement une anomalie, produire une signature ciblée et la diffuser au point d'entrée approprié. Cloudflare explique que ses systèmes analysent les champs de paquets, les caractéristiques des requêtes HTTP, les erreurs retournées par l'origine et les rythmes de trafic. Les règles temporaires expirent lorsque le motif d'attaque disparaît.

Cette automatisation ne dispense pas de supervision. Une sensibilité trop forte peut bloquer un lancement commercial, une campagne ou un afflux légitime. Une sensibilité trop faible laisse passer une attaque lente. Les équipes ont besoin d'une ligne de base, de journaux exploitables et d'une procédure pour ajuster les règles sans désactiver toute protection sous la pression.

DNS devient le principal terrain d'attaque réseau

Les attaques fondées sur DNS représentent 34,3 % de l'activité DDoS réseau du semestre selon Cloudflare. Les seuls floods DNS sont passés de 25,7 % à 40 % des attaques entre les deux trimestres. Un flood envoie directement de très nombreuses requêtes vers les serveurs DNS autoritaires afin d'épuiser leur capacité. Si ces serveurs ne répondent plus, le service devient difficile à joindre même lorsque l'application fonctionne encore.

L'amplification DNS suit un autre principe. L'attaquant interroge des résolveurs accessibles en usurpant l'adresse IP de la victime. Une petite requête déclenche une réponse plus volumineuse envoyée vers cette victime. Le ratio entre trafic émis et trafic reçu rend la technique économiquement attractive.

La résilience DNS doit par conséquent être traitée comme une dépendance de production. Elle demande plusieurs serveurs, un déploiement distribué, une capacité d'absorption, des limites adaptées et une surveillance distincte de celle du site Web. Un tableau de bord HTTP vert ne prouve pas que la résolution du domaine reste disponible.

CLDAP progresse de 580 %

Cloudflare mesure une hausse trimestrielle de 580 % pour les floods CLDAP, devenus le troisième vecteur du deuxième trimestre. CLDAP est une variante sans connexion de LDAP qui utilise UDP. L'absence d'établissement de session facilite l'usurpation de l'adresse source et donc la réflexion d'une réponse vers une victime.

Les services CLDAP exposés sur Internet, souvent liés à des environnements d'annuaire mal filtrés, peuvent devenir des amplificateurs involontaires. L'organisation qui les exploite n'est pas forcément la cible ; son infrastructure participe à l'attaque d'un tiers. Il faut inventorier les services UDP accessibles, fermer l'exposition publique lorsqu'elle n'est pas indispensable et filtrer les flux au niveau du pare-feu et de l'opérateur.

La lutte contre l'usurpation d'adresse reste également collective. Le filtrage des paquets sortants par les réseaux d'accès réduit la capacité d'un attaquant à se faire passer pour sa cible. Une seule entreprise ne peut pas corriger tout Internet, mais elle peut éviter que ses propres systèmes et adresses contribuent au problème.

Les médias arrivent en tête des secteurs visés

Le secteur médias, production et édition concentre 14,2 % des requêtes HTTP DDoS atténuées par Cloudflare et conserve la première place sur les deux trimestres. L'entreprise associe cette pression à la couverture de conflits et de grands événements internationaux. Les chiffres ne permettent pas d'attribuer chaque attaque à un gouvernement ou à un groupe précis, mais ils rappellent que l'actualité peut modifier rapidement le risque d'un site.

Une rédaction, une plateforme vidéo ou un média local doit donc intégrer les jours sensibles dans son plan de capacité. La publication d'une enquête, une élection, un conflit ou une compétition sportive peut combiner un trafic légitime exceptionnel et une attaque. Les distinguer exige des règles qui tiennent compte des chemins, des méthodes HTTP, des sessions et du comportement, pas seulement d'un seuil global de requêtes.

Les attaques peuvent aussi cibler une API, un serveur de diffusion, un VPN ou le DNS plutôt que la page d'accueil. Le plan de continuité doit cartographier toutes les entrées publiques et les prestataires critiques.

Les cinq contrôles à vérifier maintenant

La première mesure consiste à ne pas exposer directement l'adresse de l'origine. Si un attaquant peut contourner le CDN ou le proxy et joindre le serveur, il peut saturer la liaison ou les ressources sans rencontrer les protections périphériques. L'origine ne devrait accepter que les plages et mécanismes authentifiés du frontal autorisé.

Il faut ensuite vérifier les règles DDoS gérées, le WAF et la limitation de débit. Cloudflare recommande de conserver les réglages gérés à leur sensibilité et action par défaut, puis de compléter avec des règles adaptées à l'usage connu. Le cache doit absorber autant de contenu que possible et les paramètres inutiles dans les clés de cache doivent être examinés pour éviter qu'une variation aléatoire force systématiquement un retour à l'origine.

Troisième contrôle : mesurer séparément le site, le DNS, l'API, le réseau et les services d'administration. Quatrième contrôle : préparer les contacts du fournisseur, de l'hébergeur et du registrar ainsi que les accès d'urgence protégés par MFA. Enfin, un exercice doit simuler la perte du frontal principal et vérifier la page de statut, la communication et la restauration des réglages.

Le rapport Cloudflare ne signifie pas que chaque site subira demain une attaque d'un térabit. Il montre plutôt que la défense manuelle et la seule capacité du serveur ne sont plus une stratégie crédible. Le bon objectif est de filtrer automatiquement les volumes extrêmes tout en conservant assez de visibilité pour reconnaître les événements plus modestes qui suffisent à arrêter une petite infrastructure.