Attaque DDoS amplifiée via Memcached : que faut-il savoir ?

Un serveur de cache oublié, exposé sur internet, et voilà des dizaines de gigaoctets de trafic qui s’abattent sur une infrastructure sans qu’aucun pirate n’ait eu besoin de contrôler un botnet. C’est la mécanique brutale des attaques par amplification via memcached, capables de générer des pics proches de 1,3 Tb/s. Comprendre comment ce vecteur fonctionne, savoir repérer ses signatures réseau et appliquer les bons réflexes de durcissement permet de réduire drastiquement l’exposition, sans pour autant bloquer les usages légitimes de cet outil de cache largement répandu.

Memcached et l’amplification DDoS : de quoi parle-t-on exactement

Memcached est un système open source de mise en cache distribué, conçu pour accélérer les applications web dynamiques en réduisant la charge sur les bases de données. Son principe est simple : stocker temporairement en mémoire des données fréquemment consultées, afin d’éviter des requêtes répétées et coûteuses vers un système de stockage plus lent. Ce mécanisme est utilisé par de nombreux services à forte audience pour absorber des pics de consultation sans multiplier les serveurs de base de données.

Le principe de la réflexion et de l’amplification

Une attaque par réflexion consiste à envoyer une requête à un serveur tiers légitime en usurpant l’adresse IP de la victime, de sorte que la réponse soit renvoyée non pas à l’expéditeur réel, mais à la cible visée. Quand cette réponse est nettement plus volumineuse que la requête initiale, on parle d’amplification. Le vecteur memcached s’est révélé particulièrement efficace sur ce plan, dépassant largement des vecteurs plus anciens et déjà connus comme DNS ou NTP, historiquement les plus utilisés pour ce type d’attaque.

Le contexte des vagues « Memcrashed »

La technique a été baptisée Memcrashed lors d’une vague d’attaques marquantes, qui a mis en lumière la puissance de ce vecteur. Des pics de trafic UDP entrant d’environ 260 Gb/s ont été observés, avec des estimations évoquant des capacités théoriques jusqu’à 1,3 Tb/s. Les cibles typiques étaient des plateformes à forte visibilité, notamment des dépôts de code hébergés sur des services comme GitHub, illustrant la capacité de ce vecteur à frapper des infrastructures pourtant robustes. Reste à comprendre précisément comment une requête minuscule peut engendrer une telle déferlante de données.

Comment une attaque DDoS via memcached est amplifiée

Le déroulé technique suit un schéma récurrent, structuré en quatre étapes bien identifiées, qui explique pourquoi ce vecteur est à la fois simple à exploiter et redoutablement efficace.

Les quatre étapes de l’attaque

• Dépôt d’une charge de données volumineuse sur un serveur memcached exposé publiquement, en utilisant les commandes de stockage classiques du protocole
• Envoi d’une requête de lecture avec une adresse IP source usurpée, correspondant à l’adresse de la victime visée
• Réponse du serveur memcached, renvoyée non pas à l’attaquant mais directement vers l’IP usurpée, donc vers la victime
• Saturation progressive des ressources réseau et serveur de la cible, provoquant un déni de service pour le trafic légitime

Pourquoi UDP facilite ce type d’attaque

Le protocole UDP ne nécessite pas de poignée de main préalable, contrairement à TCP. Il devient alors trivial d’envoyer un paquet avec une adresse IP source falsifiée, sans qu’aucune vérification bilatérale ne soit exigée avant l’envoi de la réponse. Cette absence de contrôle est au cœur du problème : le serveur memcached exposé en UDP/11211 traite la requête comme légitime et répond mécaniquement, sans jamais vérifier la cohérence entre l’expéditeur apparent et le destinataire réel.

Un facteur d’amplification hors norme

Les chiffres observés donnent la mesure du phénomène : une requête de 15 octets peut déclencher une réponse de 134 Ko, soit un facteur d’environ 10 000 fois. Dans les cas les plus extrêmes, la même requête minuscule a généré une réponse de 750 Ko, soit un facteur d’amplification de 51 200 fois. Ce ratio, largement supérieur à celui obtenu via DNS ou NTP, explique pourquoi memcached, bien que moins fréquemment exploité que ces vecteurs historiques, est considéré comme potentiellement plus puissant. Plus la charge stockée en amont est volumineuse, plus l’amplification finale est destructrice pour la cible.

Reconnaître une attaque : indicateurs réseau et symptômes côté services

Sur le terrain, une attaque par amplification memcached laisse des traces spécifiques, identifiables assez rapidement pour peu que l’observabilité réseau soit correctement outillée.

Les signaux à surveiller côté réseau

• Pic soudain de trafic UDP entrant, souvent associé au port source 11211
• Asymétrie marquée entre le volume de requêtes sortantes et le volume de réponses entrantes
• Motifs récurrents détectables via les flux NetFlow ou sFlow, montrant des sources multiples convergeant vers une même destination
• Saturation progressive des liens montants, visible sur les compteurs d’interface des routeurs de bordure

Les symptômes côté applicatif

Côté services, les effets se traduisent par des timeouts en cascade, des erreurs HTTP 503, une latence anormale sur les applications dépendant de la même infrastructure réseau, voire une indisponibilité totale si la bande passante disponible est totalement consommée par le trafic parasite. Le premier réflexe de qualification consiste à croiser les données NetFlow/sFlow avec les journaux du pare-feu et du WAF, afin de confirmer que le trafic entrant provient bien de multiples sources UDP/11211 non solllicitées, plutôt que d’un pic de charge légitime.

Cette phase de qualification rapide conditionne la rapidité de la réponse : plus l’équipe réseau identifie tôt la signature memcached, plus vite elle peut activer les mesures de filtrage adaptées, avant que la saturation ne devienne critique.

Réduire la surface d’attaque : sécuriser memcached et fermer l’exposition UDP

La meilleure défense reste préventive : réduire au maximum la surface d’exposition de memcached, en particulier sur le protocole UDP, qui est le principal vecteur exploité.

Les mesures de configuration essentielles

• Désactiver complètement la prise en charge d’UDP sur les instances memcached lorsque ce protocole n’est pas strictement nécessaire à l’usage métier
• Faire écouter memcached uniquement sur des interfaces réseau privées, jamais sur une interface publique
• Restreindre l’accès via une liste d’adresses autorisées, en évitant toute exposition ouverte au monde entier
• Mettre en place un mécanisme garantissant que la taille de la réponse reste strictement inférieure à celle de la requête, afin de neutraliser tout effet d’amplification

Segmentation et contrôle d’accès

Au-delà de la configuration du service lui-même, la segmentation réseau joue un rôle clé : isoler memcached dans un sous-réseau dédié, protégé par des ACL strictes et un pare-feu filtrant explicitement le port 11211 depuis l’extérieur. Le maintien à jour de la version logicielle et l’application d’une configuration minimale, sans options superflues activées par défaut, réduisent également la probabilité qu’un serveur mal paramétré finisse recensé parmi les milliers d’instances exposées publiquement. Un moteur de recherche de services exposés avait ainsi recensé au moins 88 000 serveurs memcached accessibles publiquement, dont 5 729 adresses IP uniques présentaient une configuration vulnérable exploitable pour l’amplification.

Mitigation en production : filtres, anti-spoofing et protection DDoS en amont

Même avec un durcissement rigoureux côté serveur, la défense en profondeur nécessite des mesures complémentaires en bordure de réseau et chez les opérateurs qui acheminent le trafic.

Les contre-mesures opérationnelles côté infrastructure

• Rate limiting appliqué sur le trafic UDP/11211 en entrée, pour limiter le débit toléré avant blocage automatique
• Règles d’ACL strictes en bordure de réseau, bloquant par défaut tout trafic UDP non indispensable
• Blackholing ou RTBH (Remote Triggered Black Hole) pour rediriger le trafic malveillant vers une route sans issue en cas de saturation critique
• Recours à un scrubbing center capable d’absorber et de nettoyer le trafic avant qu’il n’atteigne l’infrastructure cible

Le rôle du CDN, de l’anycast et du filtrage anti-spoofing

Un CDN combiné à une architecture anycast permet de répartir géographiquement l’absorption du trafic, diluant l’impact d’une attaque volumétrique sur plusieurs points de présence plutôt que sur une seule origine. Un WAF placé en amont filtre également les requêtes applicatives suspectes, complétant la protection réseau. Mais la mesure la plus structurelle reste la mise en œuvre de BCP 38, une pratique de filtrage anti-spoofing recommandée aux opérateurs et fournisseurs d’accès : en vérifiant que l’adresse IP source d’un paquet sortant correspond bien au réseau d’origine, cette pratique empêche la falsification d’adresse IP nécessaire à toute attaque par réflexion. Sa généralisation chez les opérateurs réduirait fortement la faisabilité de ce type d’attaque à la source, avant même qu’elle n’atteigne un serveur memcached vulnérable. La coordination avec le FAI reste indispensable lors d’un incident en cours, pour appliquer un filtrage en amont du dernier kilomètre.

Prévention durable : supervision, tests et plan de réponse aux incidents

La résilience face à ce type de menace ne se limite pas à des mesures ponctuelles : elle repose sur un dispositif de supervision continue et des exercices réguliers.

Établir une baseline de trafic normal permet de détecter rapidement tout écart significatif, notamment sur les volumes UDP entrants ou les motifs inhabituels remontés par NetFlow et sFlow. Des tableaux de bord dédiés à l’observabilité réseau, couplés à un système d’alerting réactif, réduisent le délai entre l’apparition d’une anomalie et sa qualification par les équipes. Des exercices de crise simulant une attaque par amplification, associés à des runbooks documentés, permettent de fiabiliser les procédures de réponse et d’éviter l’improvisation en situation réelle.

La gestion des dépendances externes, notamment avec le CDN et l’hébergeur, doit être clarifiée en amont : qui déclenche le scrubbing, sous quel délai, avec quels seuils. Enfin, des audits réguliers de l’exposition memcached, via des scans internes et externes, permettent de repérer toute instance oubliée avant qu’un moteur de recherche de services exposés ne le fasse à la place de l’équipe sécurité.

Memcached reste un outil précieux pour la performance applicative, mais sa puissance d’amplification impose une vigilance constante. Fermer l’exposition UDP, filtrer aux bons endroits et superviser en continu forment le socle d’une défense réellement opérationnelle.