Plusieurs attaques DDoS effectuées via des serveurs Memcached ont été détectés ces derniers jours.

Des attaques DDoS incroyablement massives utilisant très peu de ressources de calcul côté attaquant ont été lancés. Cette technique s’appuie sur la mauvaise configuration des serveurs utilisant le système Memcached. Les serveurs Memcached exposent leur port UDP à des connexions externes dans la configuration par défaut, ce qui signifie que tout serveur Memcached qui n’est pas derrière un pare-feu peut être abusé pour des attaques DDoS

Qu’est ce qu’un système Memcached : Memcached est un système d’usage général servant à gérer la mémoire cache distribuée. Il est souvent utilisé pour augmenter la vitesse de réponse des sites web créés à partir de bases de données

OVH et GitHub ont déja fait les frais de ces attaques.

 

Le scénario :

L’attaquant envoit des requêtes de petite taille aux serveurs Memcached sur le port 11211. Le protocole UDP n’étant pas implémenté correctement, au lieu de répondre avec un paquet similaire ou plus petit, les serveurs Memcached répondent avec des paquets parfois des milliers de fois plus grand que la demande initiale.

Parce que c’est le protocole UDP, l’adresse IP d’origine du paquet peut être facilement usurpée, ce qui signifie que l’attaquant peut tromper le serveur Memcached pour envoyer ces paquets de réponse surdimensionnés à une autre adresse IP – l’IP de la victime d’attaque DDoS.

Dans la communauté DDoS, ce type d’attaque DDoS est appelé DDoS réfléchissant ou DDoS de réflexion. La quantité de fois que la taille de paquet de réponse est amplifiée est le “facteur d’amplification” de l’attaque DDoS.

 

Le correctif :

Les administrateurs de systèmes disposant de serveurs Memcached sont invités à désactiver complètement la prise en charge d’UDP, ou bien à limiter son accès au minimum en « écoutant » toutes les adresses IP. Il est également fortement conseillé d’utiliser un pare-feu pour empêcher que Memcached ne soit accessible publiquement.

L’usage d’UPD n’est donc pas forcément recommandé. Le cas échéant, un mécanisme vérifiant que le serveur répond systématiquement à une requête avec une taille de paquet strictement inférieure à la demande permet d’éviter de telles attaques DDoS.

cas GitHub :

GitHub a été frappé par cette attaque  qui a culminé à 1,35Tbps via 126,9 millions de paquets par seconde.

Selon une déclaration l’incident a eu lieu le 28 février et a duré environ neuf minutes. Il est issu de plus d’un millier de systèmes autonomes (ASN) répartis sur des dizaines de milliers de points de terminaison uniques.

“La première partie de l’attaque a culminé à 1,35Tbps [entre 17h21 et 17h30 UTC] et il y avait une deuxième pointe de 400Gbps un peu après 18h00 UTC”