GitHub a survécu à une attaque DDoS de 1,3 Tbps, OVH réagit

GitHub a survécu à une attaque DDoS de 1,3 Tbps, OVH réagit

GitHub a survécu à une attaque DDoS de 1,3 Tbps, OVH réagit

Le réseau de distribution de contenu (CDN) Akamai annonce avoir été sous le feu d'une attaque par déni de service distribué (DDoS) en direction d'un acteur du développement logiciel, le 28 février vers 18 h. La cible ? GitHub, la principale plateforme en ligne de développement logiciel, utilisée par de très nombreux projets open source.

La tentative a culminé à 1,3 Tbps, un trafic doublé par rapport à l'ancien record constaté par Akamai, à savoir celle contre Dyn fin 2016, via un botnet Mirai (voir notre analyse).

Cette nouvelle attaque utilise un nouveau vecteur : memcached. Il s'agit d'un service destiné à accélérer les applications web, en maintenant un cache en mémoire. Le problème est que le service écoute à la fois les trafic TCP et UDP, sans besoin de s'authentifier, affirme Akamai.

Des instances memcached ont donc été exploitées pour « refléter » et amplifier le trafic reçu de l'attaquant vers GitHub, à la manière d'un miroir. « La vulnérabilité via cette mauvaise configuration est assez unique pour ce type d'attaque, car l'amplification peut atteindre un facteur de 51 000. Autrement dit, pour chaque octet envoyé par l'attaquant, jusqu'à 51 kilo-octets sont envoyés à la cible » constate GitHub.

Face aux premiers signes de l'attaque, l'entreprise a rapidement basculé son trafic vers Akamai, à raison. En réponse à l'incident, OVH a publié un guide pour sécuriser les instances memcached. L'opération tient en quelques commandes. De quoi faire un bon projet pour ce vendredi ou le week-end.

Commentaires (16)


Je viens de vérifier mes serveurs (dont le forum de NXI) et la configuration est bonne par défaut ! Pratique le petit guide d’OVH.


Est-ce que du coup le retour “mirroir mirroir c’est toi qui l’est !” peut de nouveau être considéré comme une défense dans les cours de récré ? <img data-src=" />


Des « hackers russes © » ont-ils récupéré le code source de tous les logiciels hébergés ? <img data-src=" />








La Doc de Memcached a écrit :



By default memcached listens on TCP and UDP ports, both 11211. -l allows you to bind to specific interfaces or IP addresses. Memcached does not spend much, if any, effort in ensuring its defensibility from random internet connections. So you must not expose memcached directly to the internet, or otherwise any untrusted users







https://github.com/memcached/memcached/wiki/ConfiguringServer#networking



C’est n’importe quoi cette affaire :





  • des dévs maintiennent une conf qui par défaut ouvre le truc au public en sachant que c’est dangereux

  • les admins sont pas fichus capable de lire le chapitre 1 de la doc du-dit soft…



    <img data-src=" /> pour tout le monde



Ah et c’est marqué en gros dans le fichier de conf aussi <img data-src=" />









memcached.conf a écrit :




Specify which IP address to listen on. The default is to listen on all IP addresses



# This parameter is one of the only security measures that memcached has, so make sure

# it’s listening on a firewalled interface.







https://anonscm.debian.org/cgit/collab-maint/memcached.git/tree/debian/memcached…



bah non c’est commenté. Du coup le mec qui a parsé le fichier avec ses yeux pour mettre en place le bouzin a ignoré, logique <img data-src=" />


En plus memcached c’est en dépendance assez commune du coups par effet domino tu peux vite te retrouver avec le port ouvert si tu ne ferme pas tout par défaut.

J’avais remarqué ça sur des installation Zimbra par exemple.


Où est le problème ? Par défaut c’est 127.0.0.1








cyp a écrit :



En plus memcached c’est en dépendance assez commune du coups par effet domino tu peux vite te retrouver avec le port ouvert si tu ne ferme pas tout par défaut.

J’avais remarqué ça sur des installation Zimbra par exemple.







Oui, la config de parefeu qui me semblait devait être de base sur une machine avec une IP publique <img data-src=" />









TheMyst a écrit :



Où est le problème ? Par défaut c’est 127.0.0.1







Parce que le mainteneur Debian l’a (heureusement) ajouté. En précisant bien en que c’est pas suffisant. Sinon c’est 0.0.0.0 par défaut.



C’est vraiment des feignasses les développeurs : pas capable de sortir des applications non bugguées ou sans failles risibles, ils codent avec les pieds, utilisent des outils qui leur mâchent tout le travail, se plaignent d’être esclave des méchants commerciaux. D’autant plus que leur job se limitent la plupart du temps à de simple copier/coller.








John Shaft a écrit :



https://github.com/memcached/memcached/wiki/ConfiguringServer#networking



C’est n’importe quoi cette affaire :





  • des dévs maintiennent une conf qui par défaut ouvre le truc au public en sachant que c’est dangereux

  • les admins sont pas fichus capable de lire le chapitre 1 de la doc du-dit soft…



    <img data-src=" /> pour tout le monde





    j’ai envi de dire qu’a la limite que les dev memcached bind large, pourquoi pas, c’est un choix qui peut ce défendre, même si d’un point de vue sécuritaire c’est pas le meilleur.



    Mais à partir du moment que tu délivre du service publiquement, l’admin sys (que ce soit son titre ou non) ce doit de soit changer le réglage si l’usage le permet, soit mettre en place un firewall, idéalement les deux.



    Le firewall ne doit même pas être une option en fait.



    Et qu’on vienne pas me dire que c’est un dev qui maintient le serveur et que du coup il a une excuse.

    Non, soit il apprend, soit il fait pas.

    Ça fait quelque années qu’on entend dire un peu partout ques les admin sys servent à rien, et ba voila le résultat.









TheMyst a écrit :



Où est le problème ? Par défaut c’est 127.0.0.1







Ah, ca explique pourquoi ma connexion rame… <img data-src=" />









127.0.0.1 a écrit :



Ah, ca explique pourquoi ma connexion rame… <img data-src=" />





<img data-src=" />









Gigatoaster a écrit :



…ils codent avec les pieds…







<img data-src=" />, avec le Q.



Merci pour cette généralité :)


Fermer