Seit mehreren Wochen andauernde DDoS-Angriffsversuche – und wir tun nichts dagegen

Wir werden per DDoS angegriffen, tun aber nichts

• Seit mehreren Wochen versucht jemand einen DDoS-Angriff.
• Der Server wird mit Millionen von Requests überflutet, um die Konfigurationsdatei millionenfach herunterzuladen.
• Allein in den letzten 5 Tagen wurde mehr als 800.000 Mal ein Download versucht; die Konfigurationsdatei ist pro Download etwa 200 MB groß.
• Der Großteil des Traffics kommt aus der EU, insbesondere aus Deutschland und dem Vereinigten Königreich.
• Der Angriff läuft auch in diesem Moment weiter, während dieser Blogbeitrag geschrieben wird.

Was wir in dieser angespannten Situation tun

• Wir blockieren die IP-Adressen des Angreifers nicht.
• Wir nutzen Cloudflare, aktivieren aber den Modus „Under Attack“ nicht.
• Die Server-CPU ist während des Angriffs die meiste Zeit nahezu im Leerlauf.
• Im Grunde tun wir fast gar nichts.

Warum?

• Der Service kann problemlos mehrere Milliarden Requests pro Monat verarbeiten und kostet nicht viel.
• Es gibt etwa 8 API-Services und Datenbanken, die auch ohne Caching mehrere Milliarden Requests pro Monat verarbeiten können.
• Wir haben Cloudflare und unbegrenzte Bandbreite.

Wie ist das möglich?

• Das Design der TablePlus-App ist schlicht, und diese Philosophie gilt auch für die bewusst minimal gehaltenen Backend-Services.
• Es werden keine Drittanbieter-Dienste wie Vercel oder Netlify verwendet. Stattdessen kommen Webserver ohne Begrenzungen zum Einsatz.
• Früher wurde ein Monolith durch schwache VPS/Prozessoren zum Flaschenhals, aber heute können leistungsstarke VPS auf einer einzelnen Instanz mehrere Milliarden Requests pro Monat verarbeiten.
• Deshalb wird für jede App ein monolithischer Service gebaut. Das ist einfach bereitzustellen und zu warten.

Sprechen wir über Monolithen

• Es gibt die Tendenz, alles kompliziert zu machen, aber das ist kein Problem, bis man unter Druck oder an Grenzen gerät.
• Weil wir Komplexität nicht mögen, entscheiden wir uns für Monolithen. Alles, was die App braucht, wird in einen einzigen Service integriert.
• Das Deployment ist einfach. Es braucht nur eine einzige Konfigurationsdatei sowie Build und Deployment.
• Durch weniger Abhängigkeiten lassen sich Fehler leichter debuggen und Flaschenhälse einfacher identifizieren.

Ein einzelnes Web-Framework in Go oder Rust kann bei korrekter Implementierung mehrere Milliarden Requests pro Monat verarbeiten

• Es wird ein High-Performance-Framework gewählt.
• Die Datenbank wird indiziert, um die Abrufzeiten mit wachsendem Datensatz zu verkürzen.
• Die Hauptdatenbank wird von der Log-/Nutzungsdatenbank getrennt, damit Performance-Probleme das Kerngeschäft nicht beeinträchtigen.
• Ein leistungsfähiger Reverse Proxy wie Nginx verarbeitet und verteilt Requests an die Kern-API.
• Alles läuft hinter Cloudflare und ist passend konfiguriert.
• Es wird ein CDN mit DDoS-Schutz verwendet.
• Große Download-Dateien werden nicht ohne CDN oder Caching auf einem VPS abgelegt.

Sprechen wir über Deployment

• Bei TablePlus wird der Deployment-Prozess so weit wie möglich vereinfacht.
• Es werden weder Docker, Kubernetes noch Container verwendet, und es ist keine Umgebungs-Konfiguration nötig.
• Es werden Binärdateien verwendet. Diese lassen sich kopieren und auf einem Linux-Server als Prozess ausführen.
• Gewählt werden Go und Rust. Das sind High-Performance-Sprachen, die Binärdateien für das Deployment erzeugen können.

Update

• Vercel hat sich gemeldet und erklärt, dass es Funktionen gibt, mit denen die Site in solchen Situationen geschützt werden kann.
• Über Ausgabenverwaltung lassen sich Ausgabenlimits setzen, und es gibt einen Attack-Challenge-Modus, der dem „Under Attack“-Modus von CF ähnelt.

Meinung von GN⁺

• Dieser Artikel betont die Bedeutung einer leistungsfähigen Infrastruktur und einer vereinfachten Deployment-Strategie, die selbst unter DDoS-Angriffen einen stabilen Servicebetrieb ermöglichen.
• Die monolithische Architektur zeigt Vorteile bei der Reduzierung von Komplexität, der Vereinfachung von Deployments und der Performance-Optimierung.
• Der effektive Einsatz von Cloud-Services und CDN zur Erhöhung der Widerstandsfähigkeit gegen DDoS-Angriffe kann auch für andere Unternehmen ein gutes Beispiel sein.
• Dieser Ansatz bietet insbesondere Startups in der Frühphase oder kleinen und mittleren Unternehmen Einblicke in den Aufbau einer kosteneffizienten Infrastruktur.
• Allerdings ist ein monolithischer Ansatz nicht für jedes System oder jede Anwendung geeignet; wichtig ist, eine Architektur zu wählen, die zu den jeweiligen Anforderungen und Rahmenbedingungen passt.

[GN⁺]

Hacker-News-Kommentare

• Zusammenfassung des ersten Kommentars:

  • Der Kommentator hält das Prahlen mit der Performance der Website für übertrieben.
  • „1 Milliarde Requests pro Monat“ entspricht nur einigen Hundert Requests pro Sekunde; das ist trivial und kann kaum als DDoS-Angriff gelten.
  • Da die Website hinter einem CDN (Cloudflare) steht, scheint in Bezug auf die Performance nichts Besonderes gemacht worden zu sein.
  • Dass eine 200-MB-Datei über ein CDN gecacht und ausgeliefert wird, ist selbstverständlich; damit zu prahlen wirkt wie unangemessenes Design.

• Zusammenfassung des zweiten Kommentars:

  • 4 TB Traffic pro Monat sind kaum als DDoS-Angriff zu betrachten.
  • 6 Millionen Requests pro Monat entsprechen nur 2 Requests pro Sekunde; bei dieser Größenordnung ist der Betrieb eines einzelnen Dienstes (Monolith) kein Problem.
  • Es wird davon ausgegangen, dass Cloudflare die meisten Requests bereits auf CDN-Ebene aus dem Cache bedient.

• Zusammenfassung des dritten Kommentars:

  • Die Website ist eine einfache statische Marketing-Seite, hat kein Diskussionsforum, und Feedback wird über GitHub-Issues abgewickelt.
  • Es ist seltsam, damit zu prahlen, dass tägliche Millionen-Downloads statischer Dateien mit einem simplen Deployment verarbeitet werden können.
  • Cloudflare übernimmt die gesamte Mitigation; tatsächlich könnte sie bei diesem sehr geringen Traffic womöglich gar nicht nötig sein.

• Zusammenfassung des vierten Kommentars:

  • Der beschriebene zusätzliche Traffic wirkt wie „sinnloser Missbrauch des Dienstes“ und kaum wie ein echter DDoS-Angriff.
  • Solcher Missbrauch kann ignoriert werden, solange er keine Kosten oder Ressourcenerschöpfung verursacht.
  • Geschichten darüber, dass der Großteil einer Auto-Scaling-Infrastruktur keine nützliche Arbeit leistet, sind üblich; es ist sinnvoll, den Traffic im Blick zu behalten.
  • Es gibt Unmut über Logging; wenn Log-Speicher günstig und reichlich vorhanden ist, ist das kein großes Problem, aber es wäre gut, Missbrauchs-Traffic automatisch zu klassifizieren und routinemäßige Verarbeitung zu unterdrücken.

• Zusammenfassung des fünften Kommentars:

  • 50 Millionen Requests pro Monat aus Großbritannien können durch ein einzelnes laufendes Skript entstehen.
  • Der Verfasser erwartet, dass ein Go-Server ohne Optimierung 250-mal mehr Requests pro Sekunde verarbeiten könnte.
  • Der Rat an sich ist nicht schlecht, aber ihre Zahlen belegen diesen Rat nicht.

• Zusammenfassung des sechsten Kommentars:

  • Das Ausliefern von Binärdateien kann gegenüber Docker bevorzugt werden, aber es gibt Sicherheitsprobleme in Bezug auf den Host, auf dem die Binärdateien laufen.
  • Ein einzelner Dienst (Monolith), der auf einem einzelnen VPS gehostet wird, ist kostengünstig und gut, aber bei Hardware-Problemen kann es zu erheblichen Ausfallzeiten kommen.
  • Wenn alles in einem einzelnen Dienst zusammengeführt wird, kann Defence in Depth verloren gehen, was bei einem Sicherheitsproblem Zugriff auf den Datenspeicher ermöglichen könnte.

• Zusammenfassung des siebten Kommentars:

  • „1 Milliarde Requests pro Monat“ ist ein Niveau, das ein einzelner Server bewältigen kann; schon ein einzelnes fehlerhaftes Skript kann so viel Traffic erzeugen.

• Zusammenfassung des achten Kommentars:

  • Es wird infrage gestellt, ob Milliarden Requests pro Monat überhaupt als großer DDoS-Angriff gelten.

• Zusammenfassung des neunten Kommentars:

  • Für jede App einen einzelnen Dienst (Monolith) zu bauen, ist einfach zu deployen und zu warten.
  • Man muss nur eine Binärdatei deployen, ohne Docker, Kubernetes, Abhängigkeiten oder Runtime-Umgebung.

• Zusammenfassung des zehnten Kommentars:

  • Nach dem Lesen des Titels wurde mehr erwartet, aber dass die Seite hinter Cloudflare steht, ist ein entscheidender Faktor.
  • Je nach Traffic-Verteilung könnte sie auch ohne Cloudflare gut auf einem VPS laufen.
  • Layer-7-DDoS-Angriffe aus Russland sind so groß, dass große Provider wegen Kapazitätsproblemen scheitern.