GitHub victime de « la plus grande attaque DDoS de son histoire »

GitHub victime de « la plus grande attaque DDoS de son histoire »

GitHub Defense

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

30/03/2015 3 minutes
41

GitHub victime de « la plus grande attaque DDoS de son histoire »

GitHub connait des difficultés à cause d'une attaque DDoS dont il fait l'objet depuis plusieurs jours. Si le service en ligne ne pointe personne du doigt pour le moment, les premiers éléments laissent penser qu'il s'agirait d'une attaque venant de Chine et qui viserait deux dépôts en particulier.

GitHub subit depuis plusieurs jours « la plus grande attaque DDoS de son histoire ». C'est par ces quelques mots que la plateforme spécialisée dans l'hébergement et la gestion de projets open source annonce la couleur sur son blog. L'attaque a commencé le 26 mars avec « une combinaison de plusieurs vecteurs », mais sans provoquer d'importants dégâts à ce moment-là. Des problèmes auxquels le site est d'ailleurs plus ou moins habitué ces dernières années.

Première attaque le 26 mars, puis un jeu du chat et de la souris entre pirates et GitHub

Mais ce n'était que le début de l'histoire et les assaillants ont rapidement passé la seconde avec une amplification de l'attaque dès le lendemain. Durant les heures qui ont suivi, GitHub et les pirates ont joué au chat et à la souris, le premier en déployant de nouvelles défenses face aux changements de tactiques des seconds. Résultats, le site GitHub était parfois inaccessible pour certains utilisateurs durant le week-end. Encore aujourd'hui, tout n'est pas réglé et, ce matin peu avant 9h, le dernier point du compte Twitter GitHub Status annonçait une énième évolution de l'attaque, à laquelleGitHub tentait de répondre.

Sur son blog, l'équipe technique ne donne aucune précision sur les tenants et les aboutissants de cette attaque DDoS, indiquant simplement, au vue des rapports obtenus, qu'ils estiment que « le but de cette attaque est de les pousser à supprimer certaines parties de leurs contenus », sans préciser lesquelles. Mais, selon le blog Insight-labs, il s'agirait des dépôts GreatFire (qui lutte contre la censure en Chine) et cn-nytimes, ce dernier proposant des traductions en chinois des articles du New York Times.

La Chine pointée du doigt

Insight-labs détaille sa vision de l'attaque et se base sur ses propres relevés : « Un certain dispositif à la frontière du réseau interne de la Chine et de l'Internet a détourné les connexions HTTP qui entrent en Chine, remplaçant un JavaScript de Baidu [NDLR : utilisé pour statistiques, comme Google Analytics par exemple] par une version piégée ». Cette dernière envoie une requête de manière aléatoire vers l'un des deux dépôts, et ce, toutes les deux secondes. Résultat : certaines machines hors de Chine et surfant sur des sites chinois seraient donc utilisées comme bots afin de créer une attaque DDoS.

De son côté, Baidu précise à plusieurs de nos confrères, dont The Verge, qu'il nie toute implication, ajoutant que sa sécurité n'a pas été compromise. Il faudra probablement attendre une éventuelle mise à jour de la part de GitHub afin d'avoir de plus amples informations sur cette attaque DDoS.

GitHub

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Première attaque le 26 mars, puis un jeu du chat et de la souris entre pirates et GitHub

La Chine pointée du doigt

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (41)


Merci de l’info, je comprends mieux pourquoi mes push/pull sont aussi lents.



Bon courage aux équipes de GitHub qui font un travail remarquable.


“Un certain dispositif à la frontière du réseau interne de la Chine”



Ils ne précisent pas à qui ça appartient?


Se venger ?

C’était arrivé à la quadrature également …


DDoS contre GitHut?

La Chine n’a pas d’autres manières d’appliquer sa censure?!



De plus, c’est une censure temporaire (puisqu’elle dépend du maintient du DDoS).



Non, vraiment je ne vois pas l’intérêt.. Et à la vu du contenu des articles d’ici et ailleurs, personne ne semble aborder ce point?!








Mithrill a écrit :



Étonnant, pourquoi ne bloquent-ils pas directement le contenu incriminé depuis leur Great Firewall ?



 Je ne vois vraiment pas l’intérêt pour la Chine de faire ainsi.





Parce que c’est plus simple de faire tomber un serveur que de configurer leur firewall.









Mithrill a écrit :



Étonnant, pourquoi ne bloquent-ils pas directement le contenu incriminé depuis leur Great Firewall ?



 Je ne vois vraiment pas l’intérêt pour la Chine de faire ainsi.





Traiter le problème à la source tout ça… ils doivent se rendre compte que leur great firewall n’est plus si great que ça&nbsp;<img data-src=" />



Je suis fan de la réaction de github:&nbsphttps://github.com/greatfire/ , du coup toutes les utilisateurs des sites qui DDOS involontairement Github se retrouvent avec une jolie alerte&nbsp;“WARNING: malicious javascript detected on this domain”.


Parce que ca a plus d’INpact.

Si tu te contentes de bloquer, les “dissidents” chercheront d’autres moyens de contourner, c’est un peu le jeu du chat et de la souris.



Par contre tu peux essayer de faire peur aux plateformes qui hébergent des moyens de contournement.

Si cela dissuade 50% d’entre-elles qui n’ont peut être pas l’infra, les connaissances techniques ou les moyens de GitHub pour y faire face, alors au bout d’un certains temps tu peux éventuellement gagner la partie…


https://lafibre.info/techno-du-web/le-trafic-de-baidu-detourne-pour-une-attaque-sur-ddos-sur-github/msg214342/#msg214342



“GitHub est un site que la chine n’ose pas bloquer, car utilisé

par de nombreuses entreprises chinoises (quand il a été bloqué cela a

été un tollé, et ils ont dé-bloqué le site)”








m1k4 a écrit :



Parce que ca a plus d’INpact.

Si tu te contentes de bloquer, les “dissidents” chercheront d’autres moyens de contourner, c’est un peu le jeu du chat et de la souris.



Par contre tu peux essayer de faire peur aux plateformes qui hébergent des moyens de contournement.

Si cela dissuade 50% d’entre-elles qui n’ont peut être pas l’infra, les connaissances techniques ou les moyens de GitHub pour y faire face, alors au bout d’un certains temps tu peux éventuellement gagner la partie…





Jouer sur la peur des plateformes pour qu’elles fassent d’elles-même de la censure (sur quels critères?), j’ai du mal à y croire..



En plus ça fait de la pub gratuite pour le service en question (github défenseur de votre liberté d’expression contre les méchants communistes totalitaires chinois). J’imagine pas le tollé si des services web se mettent à refuser les articles du New York Times…



Y’a que moi qui trouve débile ces images d’illustration ? A la rigueur, dans un magazine people, mais pas ici !

A chaque fois qu’on parle de piratage, on a le droit à une photo d’un mec en cagoule devant son laptop.&nbsp;Et pourquoi pas avec un pied de biche et des gants ?



&nbsp;Ne vous forcez pas à mettre une photo à chaque fois, surtout si&nbsp;elle n’apporte rien !&nbsp;


Options d’affichage &gt; Réduire l’image dédiée :oui2:


Ils font un travail remarquable aussi sur leur prix&nbsp;<img data-src=" />. Je suis passé à autre chose pour le privé et j’en suis bien content.


Question bête:

Comment savoir si c’est vraiment une attaque DDOS?



Parce que le principe d’une “attaque” n’est qu’une surcharge temporaire du nombre de connexion.

Comment dès lors différencier des connexions “d’attaque” de connexions normales?



Quand je vois certains cas où les serveurs sont clairement sous-dimensionnés par rapport aux évènements prévus (genre pour l’élection du président de l’ump durant laquelle les serveurs sont tombés à cause de 25 000 pauvres connexions), comment peut-on être sur qu’il s’agisse d’une attaque?



En plus avec la quantité de réseaux sociaux actuels, la volonté actuelle d’avoir tout, tout de suite, en premier, et les phénomènes de foule/moutonnage, il suffit d’une simple rumeur pour qu’un site qui n’avait que 2 000 visites par semaine se retrouve tout d’un coup avec 200 000 connexions simultanées (sans oublier les demandes de reconnexion en cas d’échec de la 1ere connexion).



Bref, je reste très méfiant quand on parle d’attaque DDOS, surtout venant de la Chine, parce qu’avec ses 618 millions d’internautes et la force de ses réseaux sociaux, tout mouvement venant de Chine peut faire tomber la majorité des serveurs du monde.

&nbsp;


Ben c’est assez simple, quand la BP explose soudainement, avec un trafic non lié a des activité normale sur le site.



Un utilisateur ‘normal’ envoie très peu de donnés a un site. La ce sont des demandes lourdes massives.


En l’occurrence, il y as bien un détournement d’un site visité par des millions de gens pour que les utilisateurs envoient des requêtes sur une repo, c’est bien une attaque. Sinon pour les cas plus globaux tu verra pas 2 ou 3 connexions par utilisateur, mais 200 &nbsp;requêtes par secondes (chiffre bidon, mais de quoi saturer la co de l’attaquant en requêtes ) et dans ces cas là on sais très vite que c’est une attaque .&nbsp;



&nbsp;/!\ les détails techniques sont pas exactes, mais c’est vulgarisé pour expliqué plus facilement&nbsp;








m1k4 a écrit :



Parce que ca a plus d’INpact.

Si tu te contentes de bloquer, les “dissidents” chercheront d’autres moyens de contourner, c’est un peu le jeu du chat et de la souris.



Par contre tu peux essayer de faire peur aux plateformes qui hébergent des moyens de contournement.

Si cela dissuade 50% d’entre-elles qui n’ont peut être pas l’infra, les connaissances techniques ou les moyens de GitHub pour y faire face, alors au bout d’un certains temps tu peux éventuellement gagner la partie…





C’est, temporairement, un succès de l’attaque alors : ils n’est plus possible d’accéder à ces projets depuis github.



“Hacked by Chinese. Man, this shit’s from Hong-Kong…”


Oh tu sais moi je dis parce que c’est la seule explication que je pouvais trouver <img data-src=" />

Les critères, c’est ce que je disais, sur les moyens de contournements de la censure.

Après que ca fasse de la pub pour un service à mon avis les attaquants s’en foutent complètement, ce n’est pas ce genre de conséquence qui est le plus important aux yeux d’un attaquant.









Spidard a écrit :



C’est, temporairement, un succès de l’attaque alors : ils n’est plus possible d’accéder à ces projets depuis github.





Oui pour GitHub, moi je parlais d’un succès s’ils arrivent à dissuader ne serait-ce que qqs services similaires d’héberger des projets de contournement de censure.

Après que je le dis ci-dessus, ce n’est que supposition de ma part…









Scarfy a écrit :



Y’a que moi qui trouve débile ces images d’illustration ? A la rigueur, dans un magazine people, mais pas ici !

A chaque fois qu’on parle de piratage, on a le droit à une photo d’un mec en cagoule devant son laptop. Et pourquoi pas avec un pied de biche et des gants ?



 Ne vous forcez pas à mettre une photo à chaque fois, surtout si elle n’apporte rien !







C’est vrai, il faudrait mettre une image d’un chinois devant son PC, avec la muraille de chine en arrière plan avec des hordes de barbares tentant de la franchir <img data-src=" />



Accessoirement, ça bloque l’attaque jusqu’à que le gus clic sur “ok” je crois :)


J’allais le dire. Ces images me font plutôt rire qu’autre chose. Elles sont ultra kitch.


ça mérite un tumblr dédié !!! <img data-src=" />








Scarfy a écrit :



Y’a que moi qui trouve débile ces images d’illustration ? […]&nbsp;Ne vous forcez pas à mettre une photo à chaque fois, surtout si&nbsp;elle n’apporte rien !&nbsp;&nbsp;





+1000

Non y’a pas que toi !



Parce que c’est en HTTPS, donc ils ne savent pas à quelle URL exacte l’internaute accède. Ils pourraient bloquer carrément le site par IP bien sûr, mais ça risquerait de donner un coup d’arrêt à l’industrie informatique chinoise ^^








Scarfy a écrit :



Y’a que moi qui trouve débile ces images d’illustration ? A la rigueur, dans un magazine people, mais pas ici !

A chaque fois qu’on parle de piratage, on a le droit à une photo d’un mec en cagoule devant son laptop.&nbsp;Et pourquoi pas avec un pied de biche et des gants ?



&nbsp;Ne vous forcez pas à mettre une photo à chaque fois, surtout si&nbsp;elle n’apporte rien !&nbsp;





Moi j’aime bien. Sans photo ça ferait un peu tristoune…









Scarfy a écrit :



Y’a que moi qui trouve débile ces images d’illustration ? A la rigueur, dans un magazine people, mais pas ici !

A chaque fois qu’on parle de piratage, on a le droit à une photo d’un mec en cagoule devant son laptop. Et pourquoi pas avec un pied de biche et des gants ?







Ce n’est pas un simple hacker. c’est… CAGOULE-MAN !!! AH AH ah ah ah



N’importe quoi, HTTPS ça chiffre entre le serveur et le client mais sur le serveur, encore heureux que tu saches ce qui se passe (au niveau URL)… Puis sur un site comme github, l’archi doit plus ressembler à ça:




[ Ferme serveurs] &lt;--http--&gt; [ Load balancer avec les cerficats SSL] &lt;--https--&gt; client      






Ce qui permet d'éviter de faire bosser les serveurs pour faire du SSL. Croire que SSL te protèges du site que tu visites, c'est juste faux vu que eux possèdent la clé privée.

T’inquiètes, t’es pas le seul…








tom103 a écrit :



Parce que c’est en HTTPS, donc ils ne savent pas à quelle URL exacte l’internaute accède. Ils pourraient bloquer carrément le site par IP bien sûr, mais ça risquerait de donner un coup d’arrêt à l’industrie informatique chinoise ^^





Le HTTPS n’empêche pas de savoir à quelle URL on accède. Ça chiffre uniquement le contenu, pas l’adresse de celui-ci.









gnumdk a écrit :



N’importe quoi, HTTPS ça chiffre entre le serveur et le client mais sur le serveur, encore heureux que tu saches ce qui se passe (au niveau URL)… Puis sur un site comme github, l’archi doit plus ressembler à ça:




 [ Ferme serveurs]  [ Load balancer avec les cerficats SSL]  client       






 Ce qui permet d'éviter de faire bosser les serveurs pour faire du SSL. Croire que SSL te protèges du site que tu visites, c'est juste faux vu que eux possèdent la clé privée.







Un load load balancer peut parfaitement rester en SSL côté client et côté serveur. Evidemment, ça nécessite d’installer des certificats sur les serveurs et ça supprime l’économie de charge. Ca permet notamment au LB d’effectuer des traitements HTTP (hashing, persistance, réécriture, redirection, …) sans compromettre le “contrat” SSL qui vide à chiffrer entre le client et le serveur.



En l’occurrence, dans le cas présent, s’il y a du contenu déchiffré, c’est pas derrière la muraille donc le firewall&nbsp; ne voit que l’URL, ce qui peut être suffisant pour bloquer.



Pour masquer l’URL, il faut du VPN.



Le nom de domaine apparaît dans le champ Host du header HTTP, une fois la connexion effectuée avec le serveur toute la requête HTTP est chiffrée, header compris.


T’es passé à quoi ? :)








porecreat a écrit :



Le HTTPS n’empêche pas de savoir à quelle URL on accède. Ça chiffre uniquement le contenu, pas l’adresse de celui-ci.





Tiens donc c’est nouveau ça oO. je vais pas tout répéter tout est dit ici. On voit de ces inepties dès fois :(









gnumdk a écrit :



N’importe quoi, HTTPS ça chiffre entre le serveur et le client mais sur le serveur, encore heureux que tu saches ce qui se passe (au niveau URL)… Puis sur un site comme github, l’archi doit plus ressembler à ça:




[ Ferme serveurs]  [ Load balancer avec les cerficats SSL]  client      






Ce qui permet d'éviter de faire bosser les serveurs pour faire du SSL. Croire que SSL te protèges du site que tu visites, c'est juste faux vu que eux possèdent la clé privée.









J’ai pas dit que ça te protégeait du site que tu visites… ce serait ridicule, évidemment que le site que tu visites sait à quelle URL tu accèdes, puisque c’est lui qui a le certificat.







porecreat a écrit :



Le HTTPS n’empêche pas de savoir à quelle URL on accède. Ça chiffre uniquement le contenu, pas l’adresse de celui-ci.







Non, je maintiens ce que j’ai dit. Ca n’empêche pas de savoir à quelle IP tu te connectes, mais la requête elle-même, qui inclue le chemin auquel tu accèdes sur le site, est chiffrée. Donc on peut savoir que tu te connectes à GitHub, mais on ne peut pas savoir à quel repo tu accèdes.



Award du commentaire à côté de la plaque décerné à gnumdk !&nbsp;<img data-src=" />



Edit : deuxième position porecreat !



Les gars avant de répondre essayez de regarder une trame https pour voir à quoi ça ressemble.








tom103 a écrit :



Non, je maintiens ce que j’ai dit. Ca n’empêche pas de savoir à quelle IP tu te connectes, mais la requête elle-même, qui inclue le chemin auquel tu accèdes sur le site, est chiffrée. Donc on peut savoir que tu te connectes à GitHub, mais on ne peut pas savoir à quel repo tu accèdes.









Yangzebul a écrit :



Award du commentaire à côté de la plaque décerné à gnumdk !&nbsp;<img data-src=" />



Edit : deuxième position porecreat !



Les gars avant de répondre essayez de regarder une trame https pour voir à quoi ça ressemble.



&nbsp;





g30lim4 a écrit :



Tiens donc c’est nouveau ça oO. je vais pas tout répéter tout est dit ici. On voit de ces inepties dès fois :(





Mea culpa, j’ai parlé trop vite, par réflexe de ne jamais faire

apparaitre d’info confidentielle dans les URL, même en HTTPS, simplement

parceque ça apparait dans les logs. Mais effectivement, l’url est

envoyée après le handshake SSL.



Par contre le host est bien envoyé avant par le browser en SNI.