Twitters Self-DDoS-Angriff

• Während der Twitter-Home-Feed an diesem Vormittag größtenteils ausgefallen war, wurde beobachtet, dass der Web-Client Inhaltsanfragen immer wieder wiederholte und dabei offenbar selbst einen DDoS auslöste
• Auch auf einem Bildschirm, der nicht lud, hörten die Wiederholungsversuche nicht auf; im ersten Video sind ein rate limited-Fehler und eine zitternde Scrollbar zu sehen
• Im zweiten Video ist zu sehen, wie Twitter beim Versuch, Inhalte abzurufen, die nicht ankommen, etwa 10 Anfragen pro Sekunde an sich selbst sendet
• Als mögliche Ursache wird genannt, dass die kürzlich eingeführte Lesebeschränkung für nicht angemeldete Nutzer unerwartete Bedingungen geschaffen haben könnte
• Auch in der Firefox-Netzwerkkonsole eines Folge-Videos gingen die Anfragen ununterbrochen weiter; dies wird als Self-DDoS interpretiert, bei dem die Browser der Nutzer wiederholt Anfragen an Twitter sendeten

---

Wiederholte Anfragen im Twitter-Web-Client

• Der Twitter-Home-Feed war an diesem Vormittag größtenteils ausgefallen, und selbst in einem Zustand, in dem nichts geladen wurde, hörte die Website nicht auf, Anfragen erneut zu versuchen
• Das erste Video zeigt eine Fehlermeldung, dass der Nutzer rate limited ist, sowie eine zitternde Scrollbar auf der rechten Seite
• Das zweite Video zeigt, warum die Scrollbar zitterte: Twitter sendete beim Versuch, Inhalte abzurufen, etwa 10 Anfragen pro Sekunde an sich selbst
• Als Hintergrund dafür, dass keine Inhalte ankamen, wird eine Änderung genannt, die nicht angemeldete Nutzer daran hindert, Twitter zu lesen

Nachträgliche Bestätigung und angehängtes Material

• Ein Folgebeitrag zeigt zusätzlich über die Firefox-Netzwerkkonsole, dass weiterhin Netzwerkanfragen auftreten
• Dazu wird die Einschätzung geäußert, dass der ausgerollte Code eine Race Condition verursacht habe, wodurch Nutzer letztlich DDoS-artige Anfragen gegen Twitter ausführten
• Der Poster gab an, die Verbindung zunächst geschlossen zu haben, Twitter danach aber noch eine Zeit lang in einem Zustand belassen zu haben, in dem weiterhin Anfragen ausgelöst wurden
• Angehängtes Material:
  • Video 4: rate-limited-Fehler und zitternde Scrollbar
  • Video 5: Szene, in der Twitter wiederholt Anfragen an sich selbst sendet
  • Video 6: Szene, in der in der Firefox-Netzwerkkonsole fortlaufend Anfragen auftreten

[xguru]

Twitter wechselt vorübergehend in einen Modus mit begrenzter Geschwindigkeit

[GN⁺]

Hacker-News-Kommentare

• Aus sehr schmerzhafter persönlicher Erfahrung kann ich sagen, dass es nur wenige Dinge gibt, die einen so sehr zermürben, wie dazu gezwungen zu werden, etwas umzusetzen, von dem man genau weiß, dass es eine schreckliche Idee ist
  Besonders schlimm ist es, wenn man versucht hat, der Person, die einen dazu drängt, gegen das eigene beste Urteilsvermögen zu handeln, genau das zu vermitteln, damit aber gescheitert ist, und diese Person später sogar bei schriftlichen Belegen lautstark behauptet, sie habe so etwas nie verlangt
  Ich weiß nicht, ob die Leute, die gerade bei Twitter arbeiten, gewarnt haben, dass die jüngsten Maßnahmen solche massiven Nebenwirkungen haben könnten, aber wenn man sich ansieht, wie die Führung dort arbeitet, wäre das überhaupt nicht überraschend
  Ich hasse sehr, was aus Twitter in den letzten Monaten geworden ist, und mochte es schon vor der Übernahme nicht besonders, weil durch das Kurzformat oft jede Nuance verloren geht und ein paar leicht einbettbare Tweets zur Grundlage ganzer Artikel werden, aber die Menschen, die unter so einer Führung arbeiten müssen, tun mir wirklich leid

  • Die Leute bei Twitter, die das System verstanden und Nebenwirkungen vorhersehen konnten, wurden wahrscheinlich alle entlassen oder sind gegangen
    Meine Vermutung: Elon hat gesagt: „Die Seite ist zu langsam“, die Engineers haben gesehen, dass Requests an den Home-Feed langsam sind, aber die Struktur nicht verstanden, hatten keine Profiling-Tools und wurden unter Druck gesetzt, das innerhalb einer unrealistischen Frist zu beheben
    Daher war das fast Einzige, was sie tun konnten, vermutlich, mehrere parallele Requests abzusetzen und zu hoffen, dass einer davon schnell ist
    Durch meine Arbeit in der Games-Branche verstehe ich inzwischen, warum Spiele trotz riesiger Summen und enormem Zeitaufwand veröffentlicht werden, obwohl sogar Grundfunktionen kaputt sind
    Solcher extreme Termindruck erzeugt paradoxerweise einen riesigen Morast, in dem man an einer Stelle etwas ändert und an zehn anderen etwas kaputtgeht, und am Ende kommt der Fortschritt ganz zum Stillstand
  • Um einmal den Advocatus Diaboli zu spielen: Auch Frontend-Entwickler sollten etwas klüger sein
    Das ist grundlegendes Error-Handling, das schon vor Jahren hätte eingebaut werden müssen
    Eine 403 oder irgendeine andere Antwort, die einen Tweet blockiert, darf niemals endlose Retries in kurzen Abständen auslösen
  • Als ich einmal aufgefordert wurde, etwas wirklich Dummes zu tun, habe ich vorsichtshalber eine CC-Bombe geworfen
  • Ich erlebe genau so eine Situation gerade in meinem Job
    Ich habe ein Tool gebaut, um die Vulnerability-Tickets des Teams zu verwalten, und der erste Anwendungsfall war trotz meines Widerspruchs das Löschen aller Vulnerability-Tickets
    Die Person, die das ausführt, interessiert sich mehr dafür, dass es auf dem Papier gut aussieht, als für echte Verbesserungen der Sicherheit
  • Viel schlimmer als der Strom an Leuten, die gemeinsam etwas beschimpfen, das alle benutzen und das allen wichtig ist, ist eine Situation, in der man die Lösung kennt, aber zu viel Angst hat, es überhaupt zu versuchen, und deshalb handlungsunfähig wird
    Man weiß es seit Langem, hat es wiederholt vorgeschlagen, darf es aber nicht einmal ausprobieren und wird stattdessen ausgegrenzt und als „diese Person“ abgestempelt
    Ich habe das bei technischen und geschäftlichen Ansätzen erlebt, die „auf die alte Art“ irgendwie noch funktionieren, das Unternehmen aber langsam umbringen
    Wenn allerdings eine Führungskraft klar Verantwortung für etwas übernimmt, das sie als riskant, aber notwendig ansieht, gibt es bei Problemen viel mehr Spielraum, gut darauf zu reagieren, und Entwickler müssen sich weniger nachträglichen Spott gefallen lassen
    Natürlich ist es trotzdem leichter, darüber herzuziehen

• Man sollte beachten, dass das an einem langen Feiertagswochenende passiert ist
  Elon hat ein großes Release durchgedrückt und damit die Engineers dazu gebracht, zur Arbeit zu kommen und in den letzten 12 Stunden immer wieder Patches einzuspielen

  • Seine Arroganz ist so groß, dass Arroganz als Wort dafür kaum ausreicht
    Die Programmierer tun mir leid
    Noch erstaunlicher ist, wie sehr Twitter Engineering heutzutage nach Flickschusterei aussieht
    Statt Energie darauf zu verwenden, tief in die Codebase einzutauchen, nimmt man nur die einfachsten und kürzesten Fixes, und genau das führt zu Problemen
  • Die Twitter-Engineers hatten über ein Jahr Zeit, sich einen anderen Job zu suchen
    An diesem Punkt sind sowohl die Arbeitsbedingungen als auch die Erwartungen des Chefs vollkommen klar
    Aus welchen Gründen sie auch immer geblieben sind, es fällt schwer, mit Leuten Mitgefühl zu haben, die das weiterhin mitmachen
  • Wenigstens konnten sie direkt in die Produktionsumgebung deployen

• Es ist sehr unwahrscheinlich, dass dieser Bug die Ursache ist
  Ein serverseitiger Rate Limiter ist billig, und der Frontend-Bug wird nur ausgelöst, wenn das Rate Limiting bereits aktiv ist
  Ich habe in Systemen, die ich betreue, schon ähnliche Bugs gesehen, weil Netzwerklibraries standardmäßig gern Requests ohne sinnvolle Begrenzung retryn
  Aber diese Retries haben den Rate Limiter nie belastet
  Wenn man allerdings eine API trifft, die erst etwas tatsächlich Teures macht und dann einen Fehler zurückgibt, wird es etwas lästiger, aber genau deshalb gibt es Rate Limiting auf allen öffentlichen Endpoints
  Die Web-App ist wahrscheinlich der kleinste Teil des Twitter-Traffics, und die nativen Apps haben dieses Problem vermutlich gar nicht

  • Ich denke nicht, dass das bedeuten muss, dass die selbst verursachte DDoS-Situation technische Probleme erzeugt hat, die den Zugriff blockiert haben
    Es könnte auch sein, dass das Blockieren anonymer Zugriffe einen DDoS ausgelöst hat, der dann zu einem gewaltigen Spike in irgendeiner Metrik führte, woraufhin Elon daraus einen Anstieg beim Scraping ableitete und dann zur Bestrafung von Scrapern ein Limit von 600 Tweets pro Tag einführte
    Mein Kontingent scheint zurückgesetzt worden zu sein oder die Richtlinie wurde geändert, denn ich komme wieder auf die Seite
  • Wenn man eine Führung hat, die dafür bekannt ist zu lügen, sobald sie glaubt, dass es ihr persönlich nützt, wird der Begriff Wahrheit selbst zerstört
    Ich stimme zu, dass es unwahrscheinlich ist, dass dieser Bug die eigentliche Wurzel des Ganzen ist
    Aber ich glaube auch nicht an die Geschichte, mit der Musk den faktischen Shutdown der Seite erklärt
    Vielleicht stimmt beides, und man denkt ständig weiter über andere mögliche Gründe nach, was völlige Zeitverschwendung ist, sich aber wie ein seltsamer mentaler Köder anfühlt
    Das Buch "Nothing is true and everything is possible" handelt davon, wie Putin Desinformation nutzt, um die Öffentlichkeit zu kontrollieren und demokratische Politik auszuschalten, und es fühlt sich an, als passe das auch hier
    Musk-Fans werden einfach wiederholen, was immer er ihnen zu sagen vorgibt, aber die meisten werden wissen, dass es nur eigennütziges Geschwätz ist
    Und wer versucht, die eigentliche Ursache zu finden, driftet leicht in Erzählungen wie diesen Bug ab, die sich zwar richtig anfühlen, aber überhaupt keine stützenden Daten haben
    Wenn man mögliche Zukunftspfade der USA sehen will, kann ich dieses Buch sehr empfehlen
    https://en.wikipedia.org/wiki/Nothing_Is_True_and_Everything...
  • Hängt von der Größenordnung des Gesamtsystems ab
    Ich habe selbst versucht, solche Degenerationsfälle zu entschärfen, in denen diese Retries das Backend so überrollen, dass die Server es nicht einmal mehr schaffen, Requests abzuweisen
    Wegen der Retries auf mehreren Ebenen vorgelagerter Aufrufer wurde die Lage so schlimm, dass Requests faktisch schon in TCP-Buffern oder Queues in ein Timeout liefen, noch bevor sie die Anwendung überhaupt erreichten
    Ich weiß nicht, ob das Homepage-Backend von Twitter in einer ähnlichen Größenordnung liegt

• Eine interessante Situation.
  Auf dem Screenshot ist zu sehen, dass eine enorme Menge an GET /TweetDetail erzeugt wird, und wie die 429er zeigen, scheint dadurch irgendein Rate Limit ausgelöst zu werden.
  Falls das mit der jüngsten Entscheidung zusammenhängt, Authentifizierung für alle API-Aufrufe zu erzwingen, könnte der Schuldige tatsächlich das API-Gateway oder eine ähnliche darunterliegende Komponente sein.
  Außerdem scheint dieses Verhalten nicht aufzuhören, was nicht dem entspräche, was man bei Wiederholungen mit exponentiellem Backoff erwarten würde.
  Ich behaupte nicht, ein besserer Engineer zu sein als die Leute, die bei Twitter arbeiten, aber auch ohne Musk-bezogene Überlegungen ist es interessant, so etwas in der Praxis zu sehen.

  • Theoretisch ist exponentieller Backoff optimal, aber ich glaube nicht, dass er in der Praxis so oft verwendet wird.
    Ich habe zu oft gesehen, dass man konstantes zufälliges Backoff gegenüber exponentiellem Backoff bevorzugt, weil man entscheidet, dass es zu wichtig ist, Nutzeranfragen mit geringer Latenz zu bedienen.
    Ich habe in vielen Design-Meetings und Dokumenten gesehen, dass explizit entschieden wurde, keinen exponentiellen Backoff zu verwenden, obwohl man den Trade-off zwischen Überlastung und Systemerholung verstanden hatte.
  • Das Frontend wurde vermutlich unter der Annahme geschrieben, dass das Backend auch ohne Authentifizierung weiter funktionieren würde.
    Die Backend-Änderung, also verpflichtende Authentifizierung + Rate Limiting, könnte ausgerollt worden sein, ohne Frontend und Backend ausreichend gemeinsam zu testen.
  • Hat Elon die AWS-Rechnung bezahlt?
    Das wirkt wie ein plausibler Schuldiger.
    Es könnte sein, dass Twitter-Instanzen zwangsweise beendet werden.

• Platformer berichtete am 10. Juni, dass „Twitter sich geweigert hatte, die Kosten für Google-Cloud-Dienste vor dem Vertragsverlängerungsdatum am 30. Juni zu bezahlen“.
  Außerdem hieß es, „Twitters Google-Cloud-Vertrag läuft seit 2018“.
  https://www.engadget.com/twitter-has-supposedly-started-payi...
  Ah, das scheint dieses ganze Chaos zu erklären.

  • Laut dem Artikel und Berichten von Bloomberg usw. hat Twitter sich am Ende doch mit Google geeinigt, und das Problem wurde gelöst.
    Wahrscheinlich versucht man, von GCP wegzukommen, aber es dürfte nicht so sein, dass plötzlich der GCP-Zugang verloren ging, weil Zahlungen verweigert wurden.
  • https://www.reuters.com/technology/twitter-resumes-paying-go...
    Das ist ein Artikel von vor einer Woche.
  • Twitter nutzt Google Cloud nicht als primären Backend-Service.
    Alles ist selbst gehostet.
    Gcloud unterstützt nur Batch-Jobs und Datenanalyse.
  • Twitters Kerndienste laufen in On-Premises-Rechenzentren.

• Eine interessante Theorie, aber das DDoS begann schon vor der Entscheidung, anonymen Zugriff zu deaktivieren.
  Tatsächlich wurde diese Entscheidung getroffen, um eine laufende DDoS-Abwehr zu unterstützen[0][1].
  Daher könnte eine verdächtige Retry-Logik im Web-Frontend die Lage verschlimmert haben, aber sie ist nicht die Grundursache.
  [0] https://twitter.com/elonmusk/status/1674865731136020505
  „Dies ist eine vorübergehende Notfallmaßnahme. Das Data Scraping war so extrem, dass die Servicequalität für normale Nutzer beeinträchtigt wurde!“
  [1] https://twitter.com/elonmusk/status/1674942336583757825
  „Das wird in Kürze aufgehoben. Wie im vorherigen Beitrag erwähnt, waren wegen extremen Data Scrapings drastische und sofortige Maßnahmen nötig.“
  „Fast jedes Unternehmen, das KI betreibt, von Startups bis zu einigen der größten Firmen der Welt, hat riesige Datenmengen gescrapt.“
  „Es ist ziemlich frustrierend, dringend eine große Zahl von Servern hochfahren zu müssen, nur um bei der absurden Bewertung irgendeines KI-Startups zu helfen.“

  • Ehrlich gesagt scheint das eher mit der Entscheidung zusammenzuhängen, den API-Zugang ohne absurde Gebühren praktisch zu schließen, als mit irgendwelchen KI-Startups.
    Es ist sicher längst irgendwo ein riesiges Archiv aller Tweets bis zu einem bestimmten Datum unterwegs, das diese Startups verwenden.
  • Das war eine Behauptung, die Elon Musk nach dem Gegenwind aufgestellt hat, also sollte man sie mit großer Vorsicht betrachten.

• Weiß jemand, ob es solche Anfragen auch schon vor der Umstellung auf Login-Pflicht gab?
  Es wäre wirklich witzig, wenn sich herausstellen würde, dass die riesige Scraping-Aktion in Wirklichkeit ihr JavaScript-Bug war.

  • In den letzten Wochen habe ich gesehen, dass das Frontend das Backend ziemlich häufig anpingt.
    Es würde mich überhaupt nicht überraschen, wenn der Großteil des „Scraping-Traffics“ Twitters eigene Schuld wäre.
  • Ein Teil des Scrapings liegt daran, dass Twitter die API ruiniert hat und Bots deshalb auf Scraping umgestiegen sind.
    Ein dummes, aber offensichtliches Ergebnis.
  • In bestimmten Abläufen, etwa auf der Profilansicht, führte ein Druck auf „Zurück“ in Firefox auf Android definitiv zu einer Endlos-Redirect-Schleife.
    Bevor das Rate Limit griff, dürften in ein paar Sekunden Dutzende Requests abgesetzt worden sein.
    Viele kleine Bugs dieser Art zusammen könnten wie eine Art DDoS oder Scraping ausgesehen haben.

• Es sieht so aus, als müsse es nicht einmal ein Bug sein.
  Elon sagte, die Zahl der Tweets, die man pro Tag sehen könne, sei auf 600 begrenzt, und das ist ein völlig verrücktes Limit.
  Die meisten Menschen dürften schon nach fünf Minuten Scrollen darüber liegen.

  • Vielleicht ist es Zeit, darüber nachzudenken, wie viel nutzlose Information wir konsumieren.
  • Fünf Minuten sind vielleicht etwas übertrieben.
    Ich erinnere mich aber, dass ich, wenn Tweetbot anzeigte, dass mein Feed mehr als 500 Einträge hatte, für mehrere 20-minütige Straßenbahnfahrten genug Unsinn zu lesen hatte.
  • Da ich in den letzten Wochen gesehen habe, wie das Frontend auf das Backend einschlägt, vermute ich, dass dieses neue Rate Limit eine Reaktion darauf ist, auch wenn Musk das nicht öffentlich einräumt.
    Ich bezweifle nicht, dass Twitter zuletzt einen massiven Anstieg des Traffics gesehen hat, aber ich bin ziemlich sicher, dass Twitter den Großteil davon selbst verursacht hat.

• Elon hätte es einfach nur laufen lassen müssen, aber ach ja, da waren ja 44 Milliarden Dollar
  Parag Agrawal und sein Team wussten ganz genau, was sie taten
  Genau das klassische Beispiel dafür, dass ein Narr und sein Geld bald getrennte Wege gehen

  • Haben sie mit dieser Giftklausel also 5D-Schach gespielt?
  • Es gibt auch eine andere Theorie dazu
    Nachdem Elon vom Gericht in Delaware dazu gezwungen worden war, Twitter zu kaufen, sei er zu reichen Diktatoren gegangen, habe sich von ihnen 44 Milliarden Dollar geholt und versprochen, Twitter in ihrem Auftrag niederzubrennen
    Ohne Twitter gäbe es keinen Arab Spring, keine Echtzeit-Updates bei Katastrophen, und man müsste das Internet nicht abschalten, um die Verbreitung von Gegenstimmen zu verhindern

• Nicht besonders bedeutsam, aber das Rate Limit wird wieder gelockert
  6k/600/300 → 8k/800/400 (gegen Mittag) → 10k/1k/500 (gegen 15 Uhr)
  https://twitter.com/elonmusk/status/1675214274627530754 und basierend auf seinen eigenen Antworten

  • Man kann nichts lesen
    Es erscheint „Something went wrong“
    Unter der neuen Nur-Login-Regel hätte man wohl selbst dann nichts lesen können, wenn die Seite online gewesen wäre
    Twitter-Links sind jetzt kontaminierte Links und damit faktisch nutzlos
  • Ich habe nur auf den Link getippt und bin sofort in das offenbar neu angehobene Rate Limit gelaufen
    Das ist ein kompletter Zirkus
  • Es war wieder zugänglich, aber vermutlich bin ich unter diesem neuen Limit nach 5–6 Minuten erneut ins Rate Limit gelaufen