Le 10 octobre 2023, Cloudflare, Google et AWS ont révélé presque simultanément une méthode d'attaque qui harcelait Internet depuis des semaines : HTTP/2 Rapid Reset (CVE-2023-44487). Au lieu de s'appuyer sur la « tactique de masse » d'un botnet, elle abuse d'une caractéristique de conception du protocole HTTP/2 lui-même pour déclencher des flots de la couche application (L7) culminant à 398 millions de requêtes par seconde (RPS). Cet article décortique l'événement qu'on a appelé celui qui « a remodelé le champ de bataille L7 » à travers trois couches : protocole, données et défense.

1. Comment gagner avec peu de forces

L'une des têtes d'affiche d'HTTP/2 est le multiplexage : une seule connexion TCP peut ouvrir de nombreux « flux » concurrents. Rapid Reset abuse du cycle de vie d'un flux – en particulier le frame RST_STREAM.

La recette des attaquants est brutalement simple : sur chaque flux, ils envoient une requête (frame HEADERS), immédiatement un RST_STREAM pour l'annuler, puis ouvrent le suivant. La boucle « requête–annulation–requête–annulation » tourne à grande vitesse. La requête est annulée, mais le serveur a déjà alloué de la mémoire, décompressé du HPACK, routé et initialisé le flux – des coûts qu'il ne récupère qu'ensuite.

Il s'agit d'une guerre d'asymétrie de calcul : l'attaquant ne paie que ~20–30 octets par tour (HEADERS 9 octets + RST_STREAM 13 octets), tandis que le serveur paie des milliers d'octets de travail CPU et mémoire par tour. Avec un minimum de bande passante, c'est d'abord le CPU du serveur qui s'épuise.

Les chiffres de Cloudflare sont parlants : un botnet de seulement 20 000 nœuds, bouclant ~10 000 fois par seconde chacun, a généré 200 millions de RPS. Comparez avec les botnets IoT traditionnels de centaines de milliers ou de millions d'appareils qui peinent souvent à dépasser quelques millions de RPS. Rapid Reset a multiplié la puissance par nœud par ordres de grandeur.

2. L'échelle réelle : les mesures des trois géants

  • Google : pic de 398 millions de RPS – plus de 7× la plus grande attaque précédente de l'histoire d'Internet.
  • Cloudflare : pic de 201 millions de RPS – 3× le record de 71 millions de RPS de février 2023.
  • AWS : une douzaine d'attaques en deux jours, la plus grande à 155 millions de RPS.

Le point critique : ceci exploite un défaut de conception présent dans quasiment toutes les implémentations HTTP/2. Nginx, Apache HTTP Server, Apache Tomcat, Microsoft IIS, HAProxy, Envoy, gRPC, Node.js, Go net/http et .NET Kestrel ont tous exigé un correctif. La divulgation coordonnée du 10 octobre 2023 a été qualifiée de « l'un des plus grands événements de correctifs synchronisés de l'histoire d'Internet », et la CISA a publié l'avis AA23-283A.

3. Pourquoi les défenses traditionnelles échouent ici

  1. Les journaux ne voient pas l'attaque : RST_STREAM annule la requête avant que le serveur produise une réponse, si bien que les journaux d'accès n'enregistrent souvent pas ces requêtes « inachevées ». Vos journaux paraissent propres alors que le serveur est broyé.
  2. Le rate limiting basé sur l'achèvement ne se déclenche pas : le rate limiting classique compte les requêtes terminées ; les requêtes Rapid Reset sont annulées avant achèvement, donc les limites ne sont jamais atteintes.
  3. La mitigation volumétrique est inutile : ce n'est pas une attaque volumétrique – le goulot d'étranglement est le CPU, pas la bande passante. « Prendre un plus gros tuyau » ne sert à rien.

4. La longue traîne de 2024 : la périphérie corrigée, l'interne exposé

Beaucoup ont cru que le correctif suffisait. Mais au premier semestre 2024, les entreprises financières et fintech ont continué d'être ciblées ; des banques et acquéreurs individuels ont atteint des pics de 50–100 millions de RPS, provoquant des pannes de passerelle API, des expirations de transaction et des indisponibilités de mobile banking. La cause profonde : les organisations ont patché leurs reverse proxys de périphérie mais laissé les équilibreurs de charge internes et le middleware legacy tourner avec des implémentations HTTP/2 non corrigées – la « longue traîne » de la vulnérabilité est restée exploitable des mois après la divulgation.

5. Checklist de défense pour ingénieurs

  • Surveiller les métriques au niveau frame, pas le nombre de requêtes : le signal clé est le ratio RST_STREAM / réponses achevées. Normalement RST_STREAM doit être sous 1 % des fermetures de flux ; un pic est un fort indicateur d'attaque.
  • Appliquer des plafonds de flux par connexion et des limites de débit RST au niveau de la périphérie.
  • Mettre à niveau chaque composant HTTP/2 : Nginx 1.25.3+, Apache 2.4.58+, Node.js 18.18.2+/20.8.1+, Go 1.21.3+, HAProxy 2.8.4+ etc.
  • En L7, l'analyse comportementale bat les règles statiques : détectez l'anomalie « taux d'annulation élevé, taux d'achèvement faible » par rapport à une baseline, au lieu de bloquer les IP aveuglément.

Conclusion

Rapid Reset marque un changement de paradigme du DDoS L7 : les attaquants ne comptent plus sur la suprématie de la bande passante mais exploitent les défauts de conception du protocole pour une asymétrie de calcul – peu de forces, grand effet. Pour toute organisation servant du HTTP sur l'Internet public, c'est un réveil : ce que vous supposez être un « comportement de protocole normal » peut être l'arme de quelqu'un d'autre. La vraie réponse des défenseurs est une architecture qui fait identification au niveau frame et mitigation autonome à la périphérie du protocole.