Déclaration sur la panne en cours de SourceHut

Disponibilité actuelle des services

• sr.ht : hors ligne
• meta.sr.ht : hors ligne
• git.sr.ht : hors ligne
• hg.sr.ht : hors ligne
• todo.sr.ht : hors ligne
• lists.sr.ht : hors ligne
• paste.sr.ht : hors ligne
• man.sr.ht : hors ligne
• pages.sr.ht : hors ligne
• builds.sr.ht : hors ligne
• chat.sr.ht : hors ligne
• Le stockage d’objets est actuellement indisponible, ce qui rend aussi inaccessibles pour le moment les releases jointes aux tags git et hg.
• hg.sr.ht présente des problèmes de performances connus ainsi que des problèmes liés à hg clone, et comme le service est maintenu par la communauté, les travaux de restauration sont suspendus jusqu’à l’intervention d’un mainteneur communautaire.

Mise à jour 2024-01-13 14:17 UTC

• Nous devons trouver un nouveau fournisseur de transit et sommes en discussion avec des prestataires pour atténuer le problème.
• Les travaux d’ingénierie vont commencer sous peu, et nous communiquerons d’autres informations s’il y a de nouvelles mises à jour.

Mise à jour 2024-01-13 13:00 UTC

• Le nouveau fournisseur de transit a signalé que l’attaque DDoS avait suivi vers le nouveau réseau.
• Le fournisseur a déployé des mesures d’atténuation et nous ne prévoyons pas d’interruption de service.

Mise à jour 2024-01-13 12:40 UTC

• Le service mail pour lists et todo a été rétabli.
• Les e-mails restés en attente pendant l’interruption vont maintenant reprendre leur traitement, et nous ne pensons pas que des e-mails aient été perdus.

Mise à jour 2024-01-13 11:42 UTC

• pages.sr.ht a été remis en service en mode lecture seule.
• Tous les domaines personnalisés devraient bientôt fonctionner, à l’exception de ceux utilisant un enregistrement apex.
• Les utilisateurs concernés devront intervenir manuellement.

Mise à jour 2024-01-13 11:00 UTC

• L’accès en lecture/écriture a été réactivé pour la plupart des services.
• hg est toujours en lecture seule, et todo ainsi que lists traitent les requêtes sur le web, mais le système mail est encore en cours de remise en service.

Mise à jour 2024-01-13 09:26 UTC

• hg.sr.ht a été remis en mode lecture seule.
• Nous travaillons aujourd’hui à réactiver l’accès en lecture/écriture pour les services disponibles.
• Nous avons terminé de récupérer les écarts depuis les sauvegardes de git.sr.ht, et ceux de hg devraient être finalisés sous peu.

Mise à jour 2024-01-12 20:49 UTC

• Nous effectuons les dernières tâches pour atteindre les objectifs du jour.
• Sept services principaux fonctionnent en mode lecture seule.
• Les problèmes précédents liés à git clone/fetch ont également été résolus.

Mise à jour 2024-01-12 16:38 UTC

• todo et lists ont été remis en ligne en mode lecture seule.

Mise à jour 2024-01-12 16:13 UTC

• Nous avons commencé à remettre certains services en ligne.
• meta et git devraient redevenir disponibles en fonction de la propagation DNS.

Qu’est-ce que SourceHut ?

• SourceHut est une entreprise fondée par Drew, actuellement en interruption de service.
• Réputé pour sa fiabilité, SourceHut traverse cette fois sa panne la plus grave et la plus longue à ce jour.
• L’équipe SourceHut met tout en œuvre pour résoudre le problème et rétablir les services aussi vite que possible.

Que se passe-t-il ?

• Une attaque par déni de service distribué (DDoS) visant SourceHut a commencé le 10 janvier à 06:30 UTC.
• SourceHut peut gérer les attaques DDoS classiques, mais celle-ci dépasse, par son ampleur, ce qu’il peut atténuer seul.
• Le fournisseur de réseau en amont a complètement bloqué SourceHut, empêchant à la fois Internet et le personnel de SourceHut d’accéder aux serveurs.
• Le datacenter PHL a été touché, et SourceHut loue un espace de colocation auprès du fournisseur de PHL.
• Après deux acquisitions successives du fournisseur de PHL, le compte de SourceHut a été omis lors de la migration du système de tickets, ce qui a initialement retardé la prise de contact avec le prestataire.
• La disponibilité de SourceHut a été partiellement rétablie dans la soirée du 10 janvier, mais au début du 11 janvier, l’intensification du DDoS a conduit le fournisseur à imposer de nouveau le blocage.

Quelles mesures prenons-nous ?

• SourceHut maintient trois sites (PHL, FRE, AMS), et PHL, site principal, est actuellement hors ligne.
• Lorsqu’il est devenu totalement impossible d’accéder à PHL, la restauration depuis les sauvegardes a commencé à AMS pour une installation parallèle de SourceHut.
• Les perspectives concernant la perte de données utilisateur sont bonnes, les sauvegardes étant exécutées et testées régulièrement.
• Les services SourceHut sont en cours de restauration à AMS, et meta, todo, lists, paste ainsi que le hub de projets fonctionnent pleinement avec les données de production.
• La priorité est donnée à la restauration de services tels que git.sr.ht, hg.sr.ht, pages.sr.ht, chat.sr.ht, man.sr.ht et builds.sr.ht.
• L’objectif est d’activer dès que possible un accès en lecture seule pour la communauté, puis de rétablir un accès complet en lecture/écriture.

Comment aider ?

• Ce dont nous avons le plus besoin, c’est de patience et de compréhension.
• Atténuer ce type d’attaque s’apparente à un marathon, et il faut veiller à ne pas épuiser le personnel.
• Vous pouvez partager des mises à jour et des messages de soutien sur Mastodon et sur le canal IRC #sr.ht de Libera Chat.

Avis de GN⁺ :

1. La situation actuelle de SourceHut est un événement important pour la communauté open source et les développeurs, car elle montre la vulnérabilité même de services fiables et l’importance de plans de réponse en situation d’urgence.
2. Cet incident souligne la gravité des attaques DDoS et la nécessité pour les entreprises de se préparer à des cyberattaques de grande ampleur.
3. La communication transparente de l’équipe SourceHut et ses efforts pour résoudre le problème inspirent confiance aux utilisateurs et montrent que le soutien et la patience de la communauté jouent un rôle important.

[GN⁺]

Commentaires sur Hacker News

• Un service que nous exploitons a récemment subi une attaque DDoS ; juste avant, une agence de police indienne avait demandé des données sur un utilisateur précis.
  Elle affirmait que c’était lié au terrorisme ; nous avons expliqué notre politique, à savoir qu’une longue procédure judiciaire était nécessaire dans notre juridiction, puis le service est tombé en panne en quelques heures, pendant environ 12 heures.
  Il n’y a pas eu de demande de rançon, et les seules causes possibles étaient la police/le gouvernement indien, l’utilisateur initial, ou une coïncidence totale.
  Quand on vit ce genre de chose, on se dit que « cela ne devrait pas être possible », et cela révèle que, que l’on laisse le problème sans solution ou qu’on l’exploite directement, le jeu est beaucoup trop favorable aux plus forts.

  • Je me demande à quel point on peut être sûr que cette demande venait vraiment de la police indienne.
    Il est aussi possible que ce soit quelqu’un d’autre, susceptible de se mettre irrationnellement en colère parce qu’il n’a pas obtenu les données voulues.
  • Nous aussi, nous avons récemment subi un DDoS, et à chaque fois je me demande à qui cela profite, ou même qui peut bien s’intéresser à nous.
    Impossible de savoir si c’est un concurrent, quelqu’un qui s’ennuie, ou un client mécontent, et il est très probable que nous ne le saurons jamais.
  • Le service de police concerné a son importance.
    Il existe aussi des organisations militaires ou de sécurité intérieure dont le nom contient « Police », comme le CRPF ou l’ITBP ; si cela relève du MHA, alors ce n’est pas surprenant que ce soit classé dans la catégorie « sécurité nationale ».
  • Ce qui est surprenant, c’est que ce service ne disposait apparemment pas déjà d’une forme de protection DDoS.
    Pour un service public, c’est quelque chose de presque standard depuis 10 à 20 ans ; pour un petit service, Cloudflare est gratuit ou peu coûteux, et il existe beaucoup d’autres options.
    Il vaut mieux partir du principe qu’on peut subir un DDoS aléatoire juste après le lancement ; même si l’on identifie l’attaquant, il y a très peu de chances de le retrouver et de le faire condamner.
    La conclusion à en tirer ici n’est pas tant « cela ne devrait pas être possible » que « c’est courant depuis des décennies et cela continuera à arriver, donc il faut préparer la suite ».
    Qu’il s’agisse d’une agence locale corrompue ou d’un script kiddie, tant que la moitié du monde sera connectée avec des appareils médiocres, les DDoS continueront.
  • Je ne pense pas que la police indienne soit assez compétente pour DDoS ce service.

• Lors de ma première semaine chez [un grand hébergeur public de code], nous avons été attaqués par [un acteur étatique], probablement parce que nous hébergions quelque chose que [un pays] n’aimait pas.
  Le fait que SourceHut et Codeberg attirent ce genre d’attention est aussi un signe encourageant : les hébergeurs de code alternatifs commencent à obtenir une vraie traction.

  • Je me demande comment ils ont déterminé qu’il s’agissait de [un pays].
    Y avait-il des menaces explicites ou un message d’exigence du type « si vous ne faites pas ceci… » ?

• C’est intéressant de savoir pourquoi HN est tombé.
  Le message disait en substance : « Vous avez peut-être vu que Hacker News est tombé le 10 janvier ; je pense que c’était le résultat d’une réaction trop brutale de Cogent lors de l’atténuation du DDoS visant SourceHut ».
  C’était aussi sur https://news.ycombinator.com/item?id=38939532, mais je ne l’avais pas vu auparavant.

  • Je ne comprends pas bien comment Cogent aurait blackholé l’adresse IP de SourceHut, et comment cela aurait affecté l’adresse IP de HN.
    Les deux sont sur des allocations IP et des ASN totalement distincts.
  • À un certain stade, dans la défense contre les DDoS, la seule option restante est parfois le blackholing déclenché à distance sur le routeur de bordure.
    Résultat : tout le réseau /24 n’est plus routé vers son propre réseau et est abandonné côté pair.
  • Sachant que Drew n’aime pas Hacker News, je suis quand même surpris qu’il ait inclus ce genre de mention.

• C’est dommage que l’équipe doive gérer ce genre de situation, mais je veux saluer la manière dont elle communique avec ses clients : c’est un excellent exemple.

• J’espère que les employés de sr.ht réussiront bien la migration vers AMS.
  Heureusement, git est suffisamment distribué pour que j’aie pu faire pratiquement tout ce que j’avais à faire ces derniers jours ; la seule chose impossible était de pousser une nouvelle release vers le dépôt upstream officiel.

  • Comme SourceHut ne cache pas git send-email à ses utilisateurs de façon surprotectrice, le développement collaboratif qui se fait sur cette plateforme est particulièrement bien structuré pour continuer à fonctionner.
  • Tu veux dire une migration vers AWS ?
    En cas de DDoS sur AWS, même si Amazon absorbe le trafic, Drew et SourceHut risqueraient fort de faire faillite.
    Sans compter les problèmes de principe qu’ils ont avec AWS au départ.

• En lisant le passage disant « Nous avons parlé avec CloudFlare, mais on nous a proposé un tarif financièrement impossible à assumer », je me dis que quelqu’un de haut placé chez Cloudflare pourrait peut-être faire remonter le dossier et aider à obtenir un devis approprié.

  • Beaucoup de gens ne semblent pas savoir qu’une grande partie des services gratuits/bon marché de Cloudflare sont centrés sur HTTP.
    Les fonctionnalités qui couvrent plusieurs protocoles se trouvent dans les offres entreprise, celles avec lesquelles ils gagnent de l’argent.
  • Ce n’est pas parce qu’un devis est cher qu’il n’est pas approprié.
    CloudFlare devrait soit le faire gratuitement pour la publicité, soit facturer le prix correspondant à un devis correct.
  • Je ne vois pas pourquoi on devrait s’attendre à ce que Cloudflare prenne les coûts en charge à la place de SourceHut.
  • C’est peut-être parce que Cloudflare Spectrum, qui protège les services non HTTP comme SSH, est outrageusement cher.
  • Je me demande pourquoi ils ne publient pas le devis.
    D’autres entreprises pourraient proposer de meilleures conditions.

• Si Godot, Codeberg et SourceHut ont été touchés, y a-t-il d’autres sites concernés ?
  On dirait que quelqu’un vise des sites web liés à l’open source.

  • Quelqu’un est peut-être en train de démontrer sa capacité DDoS pour vendre de la bande passante à des acheteurs malveillants.

• Je me demande quelle est généralement la motivation derrière les attaques DDoS.
  Il doit y avoir un certain risque de poursuites pénales, donc il faut bien qu’il y ait quelque chose à gagner ; et dans ce cas précis, ni l’extorsion ni la perturbation d’un concurrent ne semblent très plausibles.

  • Souvent, c’est aussi simple qu’une personne instable qui estime avoir été lésée par la victime et loue une attaque.
    L’une des grandes raisons du succès de Discord, c’est aussi que Skype et Teamspeak exposaient les adresses IP ; et c’est pour la même raison que la plupart des jeux en ligne ont abandonné le réseau P2P direct.
  • Les causes sont variées : script kiddies, acteurs étatiques, botnets mal configurés, etc.
    La motivation ressemble souvent à celle pour laquelle beaucoup de choses sont réécrites : « parce qu’on peut le faire » ou « parce que c’est là ».
    Je ne fais pas partie de ces milieux, mais à en juger par l’histoire et l’actualité, cela vient souvent de personnes n’ayant pas encore l’âge d’être jugées comme adultes, ou de pays où les autorités n’ont aucune volonté de sévir ; le risque est donc faible, et même lorsqu’il existe, beaucoup ne pensent pas se faire prendre.
  • Les motivations incluent la rançon, l’élimination d’un concurrent, la censure, etc.
    Par exemple attaquer des sites de paris, ou le gouvernement chinois qui vise régulièrement GitHub parce qu’il héberge des logiciels de VPN.
  • Je me demande s’il y a déjà eu des poursuites réelles pour DDoS.
  • La raison la plus évidente pourrait être que quelqu’un n’aimait pas une partie du code publié sur le site, et que le site était facile à faire tomber.
    Il est aussi possible qu’il y ait eu auparavant un avertissement discret dont nous n’avons pas connaissance.

• Codeberg est aussi tombé à cause d’un DDoS il y a environ 12 heures.
  https://status.codeberg.eu/status/codeberg

  • Je me demande pourquoi ils envisagent une migration vers l’UE.
    Un service pair dans la même région semble rencontrer le même problème, et déménager en Europe ne le résoudra pas ; pourtant c’était mentionné dans l’annonce publique.