En février 2018, GitHub a subi une attaque DDoS de 1,35 Tbps – non pas avec des milliers de bots, mais avec moins de 2 000 serveurs Memcached exposés. Les attaquants envoyaient de minuscules requêtes et recevaient des réponses amplifiées jusqu'à 51 000×. Voilà la réflexion/amplification : elle découple proprement la bande passante dépensée par l'attaquant de celle absorbée par la victime. Cet article décortique une course aux armements de dix ans.
1. Le facteur d'amplification : le levier de l'attaque
Le facteur d'amplification (AF) est brutalement simple : AF = taille de la réponse / taille de la requête. La condition préalable est le spoofing d'adresse IP source – l'attaquant contrefait l'IP de la victime comme source, si bien que la réponse surdimensionnée du serveur vise la victime tandis que l'attaquant ne paie presque rien.
| Vecteur | Port | AF typique | État |
|---|---|---|---|
| Memcached | UDP/11211 | ~5 000–51 000× | largement contenu |
NTP monlist | UDP/123 | ~556× | majoritairement désactivé |
| CLDAP | UDP/389 | ~56–70× | courant 2017–2019 |
| WS-DD | UDP/3702 | ~15–50× | explosion depuis 2021 |
| SSDP (UPnP) | UDP/1900 | ~30× | routeurs domestiques fréquents |
| DNS (ANY) | UDP/53 | ~28–54× | resolveurs ouverts persistants |
| SNMP | UDP/161 | ~6,5× | v3 atténue |
Ce tableau révèle une vérité inconfortable : tant qu'un seul service UDP ouvert sur Internet peut être interrogé avec une source spoofée, il devient l'amplificateur gratuit de l'attaquant.
2. Pourquoi UDP ? Le sans-connexion est le péché originel
La réflexion/amplification s'appuie sur la nature sans connexion d'UDP : pas de handshake, pas de vérification de source, donc une requête à source spoofée obtient tout de même une réponse. US-CERT a listé 14 vecteurs d'amplification basés sur UDP dans TA14-017A. Le handshake à trois voies de TCP (le SYN doit être ACK par la vraie source) rend la réflexion classique quasi impossible – voilà pourquoi l'amplification est presque exclusivement un phénomène UDP.
Idée clé : le levier de l'amplificateur n'est pas le calcul, c'est le stock de services mal configurés. Les attaquants n'élèvent pas de bots ; ils louent les mauvaises configurations de l'Internet – faisant chuter le coût de l'attaque près de zéro.
3. La migration des vecteurs : un jeu de massacre
Chaque fois que les défenseurs tuent un vecteur, les attaquants pivotent :
- 2013–2014 : NTP
monlist(~556×) a dominé avec des centaines de Gbps par événement ; la communauté NTP a ensuite désactivé monlist par défaut. - 2017–2018 : CLDAP (~70×) et Memcached (~51k×) ont pris le relais ; ce dernier a produit le record de 1,35 Tbps.
- Depuis 2021 : WS-DD (UDP/3702, protocole de découverte de périphériques) a explosé – Microsoft a rapporté une hausse de 3 300 % en glissement annuel de l'amplification WS-DD, car d'innombrables appareils IoT, imprimantes et caméras l'activent par défaut.
- 2024–2025 : les rapports annuels de Cloudflare montrent que la réflexion pure reste une part importante des attaques L3/4, mais les pics à vecteur unique ont cédé la place à des hybrides multi-vecteurs (réflexion + flood direct + L7) et à des attaques directes de classe Tbps menées par des variantes Mirai.
4. Cause racine vs symptômes : la promesse perdue de BCP 38
Le remède ultime en théorie est BCP 38 / RFC 2827 (filtrage d'entrée) : chaque opérateur dépose au bord les paquets dont la source n'est pas dans son propre préfixe, rendant le spoofing de source impossible à l'échelle d'Internet. Pourtant, trois décennies plus tard, BCP 38 est encore loin d'être universel – car il exige que tous les opérateurs agissent, sans retour direct pour un déploiement unilatéral.
C'est une tragédie des biens communs : chaque opérateur espère que les autres filtrent pendant qu'il profite du système. Le résultat – nous combattons en 2025 la même vulnérabilité qu'en 2014.
5. La guerre sur deux fronts des défenseurs
Jusqu'à ce que BCP 38 soit universel, les défenseurs doivent combattre sur deux fronts :
- Comme amplificateur potentiel (durcissement) : désactiver NTP
monlist, restreindre les résolveurs DNS à la récursion locale, déposer en ACL l'UDP/3702 entrant au bord, lier Memcached à localhost. Ne laissez pas vos serveurs devenir les complices de l'attaquant. - Comme victime potentielle (absorption) : s'appuyer sur un réseau de scrubbing mondialement distribué avec absorption de classe Tbps ; limiter la réflexion UDP par comportement plutôt qu'en bloquant aveuglément les IP (le spoofing rend les blocs IP inutiles) ; utiliser Anycast pour diluer au bord.
- Intelligence active : s'abonner à Shadowserver, scanner et corriger ses propres services UDP exposés avant qu'ils ne figurent sur une liste « d'actifs amplifiables ».
Conclusion
La réflexion/amplification est un miroir qui reflète le problème de dispersion de la responsabilité sur Internet. Tant que persistent les services UDP ouverts et le spoofing de source, la course aux armements ne finira pas. Pour les défenseurs, la vraie barrière n'est pas une seule ACL – c'est une architecture qui absorbe des flots de classe Tbps au cœur et identifie le comportement UDP anormal en quelques secondes. Vous ne pouvez pas compter sur tout Internet déployant BCP 38 demain.