Szenario DDoS-Angriff: Wenn deine Website und Services nicht mehr erreichbar sind

Dienstag, 09:47 Uhr: Der Ansturm beginnt

Die Lichtblick GmbH betreibt einen Online-Shop für nachhaltige Büroausstattung. 40 Mitarbeiter, davon zwei in der IT. Der Shop macht 60 Prozent des Gesamtumsatzes aus, der Rest läuft über den stationären Handel am Standort in Leipzig. Das Unternehmen hostet seinen Shop bei einem deutschen Rechenzentrum, betreibt ein separates Kundenportal für Geschäftskunden und nutzt eine Cloud-basierte Telefonanlage (VoIP).

Am Dienstagmorgen um 09:47 Uhr klingelt bei IT-Leiter Florian Roth das Telefon. Es ist die Kollegin aus dem Kundenservice: „Florian, drei Kunden haben gerade angerufen und sagen, dass der Shop nicht erreichbar ist. Ich komme auch nicht drauf." Florian öffnet den Browser und ruft den Shop auf. Die Seite lädt nicht. Er prüft das Monitoring-Dashboard. Die Antwortzeiten des Webservers sind explodiert, der Server ist mit 100 Prozent CPU-Auslastung am Anschlag, und die Netzwerkbandbreite ist komplett ausgelastet.

Florians erster Gedanke: ein technisches Problem, vielleicht ein fehlerhaftes Update oder ein Datenbankproblem. Er loggt sich per SSH auf dem Server ein, was ungewöhnlich lange dauert, und sieht in den Access-Logs einen Strom von Anfragen, der alles überrollt, was er je gesehen hat: tausende Requests pro Sekunde von hunderten verschiedenen IP-Adressen, alle auf die Startseite und die Suchfunktion des Shops.

Das ist kein technischer Ausfall. Das ist ein DDoS-Angriff.

Was bei einem DDoS-Angriff passiert

DDoS steht für Distributed Denial of Service. Anders als bei Ransomware oder Datendiebstahl geht es bei DDoS nicht darum, in Systeme einzudringen oder Daten zu stehlen. Das Ziel ist ausschließlich die Verfügbarkeit: Der angegriffene Dienst soll für legitime Nutzer nicht mehr erreichbar sein.

Der Angreifer nutzt dafür ein Botnetz, ein Netzwerk aus tausenden oder hunderttausenden kompromittierten Geräten (Computer, IoT-Geräte, Server), die gleichzeitig Anfragen an das Ziel senden. Die schiere Menge an Traffic überfordert die Netzwerkanbindung, die Server-Kapazität oder beides.

DDoS-Angriffe gibt es in verschiedenen Varianten:

Volumetrische Angriffe überfluten die Netzwerkanbindung mit Datenverkehr. Ein Server mit einer 1-Gbit/s-Anbindung kann einem Angriff mit 10 Gbit/s schlicht nicht standhalten, unabhängig von seiner Rechenleistung.

Protokoll-Angriffe (z. B. SYN Floods) nutzen Schwächen in Netzwerkprotokollen aus, um Verbindungstabellen von Firewalls und Load Balancern zu füllen und so die Verarbeitung legitimer Verbindungen zu verhindern.

Applikationsangriffe (Layer 7) senden scheinbar legitime HTTP-Anfragen, die den Webserver oder die Datenbank überlasten. Eine Suchanfrage mit einem komplexen Suchbegriff, die eine aufwendige Datenbankabfrage auslöst, kann bei tausend gleichzeitigen Ausführungen einen Server in die Knie zwingen, auch wenn die Netzwerkbandbreite nicht ausgelastet ist.

Der Angriff auf die Lichtblick GmbH ist eine Kombination: ein volumetrischer Anteil, der die Bandbreite füllt, und ein Applikationsanteil, der gezielt die Suchfunktion des Shops angreift.

Dienstag, 09:55 Uhr: Die ersten acht Minuten

Florian muss jetzt schnell und methodisch handeln. Ein DDoS-Angriff lässt sich nicht vom eigenen Server aus lösen, denn die Bandbreite, die der Angreifer kontrolliert, ist größer als die eigene. Eine funktionierende Firewall-Konfiguration hilft bei der Grundabwehr, reicht aber bei volumetrischen Angriffen nicht aus. Die Lösung muss upstream erfolgen, also beim Internet-Provider oder einem spezialisierten DDoS-Schutzdienst.

Schritt 1: Bestätigung und Einordnung

Florian bestätigt anhand der Logs und des Monitoring, dass es sich um einen DDoS-Angriff handelt und nicht um einen regulären Traffic-Spike (etwa durch eine Erwähnung in einem Newsportal). Die Indikatoren sind eindeutig: Traffic von hunderten verschiedenen IP-Adressen aus vielen Ländern, keine erkennbare Korrelation mit Marketing-Aktivitäten, und die Request-Muster sind untypisch (tausende identische Anfragen pro Sekunde).

Schritt 2: ISP kontaktieren

Florian ruft den Internet-Provider des Rechenzentrums an. Die Geschäftskunden-Hotline, nicht die allgemeine Support-Nummer. Er schildert die Situation: DDoS-Angriff auf die IP-Adresse des Webservers, geschätztes Angriffsvolumen deutlich über der verfügbaren Bandbreite.

Der ISP hat mehrere Optionen:

Blackhole Routing (Nullrouting): Der ISP kann den gesamten Traffic auf die angegriffene IP-Adresse verwerfen (ins „schwarze Loch" leiten). Das stoppt den Angriff, aber auch den gesamten legitimen Traffic. Die Website ist dann zwar vor dem Angriff geschützt, aber trotzdem nicht erreichbar. Diese Maßnahme ist die Notbremse, wenn nichts anderes funktioniert.

Traffic Scrubbing: Fortschrittlichere ISPs bieten Traffic Scrubbing an: Der Traffic wird über ein Filtercluster geleitet, das den Angriffs-Traffic identifiziert und verwirft, während legitimer Traffic durchgelassen wird. Die Qualität des Scrubbing variiert je nach ISP und Angriffstyp.

Upstream-Filterung: Der ISP kontaktiert seine eigenen Upstream-Provider und bittet um Filterung auf einer höheren Netzwerkebene.

In Florians Fall bietet der ISP Traffic Scrubbing an, braucht aber 15 bis 30 Minuten, um es zu aktivieren. Florian bittet gleichzeitig um die Aktivierung und sucht nach einer schnelleren Lösung.

Schritt 3: CDN aktivieren

Florian hatte vor Monaten ein Konto bei einem CDN-Anbieter (Content Delivery Network) eingerichtet, der DDoS-Schutz als Feature anbietet. Er hatte die Integration aber nie abgeschlossen, weil sie technisch aufwendig war und „kein akutes Problem" bestand. Jetzt ist das akute Problem da.

Die CDN-Integration funktioniert im Grundprinzip so: Der DNS-Eintrag des Shops wird auf die IP-Adressen des CDN umgestellt. Alle Anfragen gehen dann zuerst zum CDN, das über ein global verteiltes Netzwerk mit enormer Kapazität verfügt und DDoS-Traffic filtert, bevor der saubere Traffic an den eigentlichen Webserver weitergeleitet wird.

Florian ändert die DNS-Einträge. Aber DNS-Änderungen brauchen Zeit, um sich zu verbreiten (Propagation). Je nach TTL (Time to Live) der bestehenden DNS-Einträge kann es 30 Minuten bis mehrere Stunden dauern, bis alle Nutzer über den CDN-Schutz geleitet werden. Florian hatte eine TTL von 3600 Sekunden (eine Stunde). Das bedeutet: Mindestens eine Stunde lang wird ein Teil des Traffics weiterhin direkt auf den ungeschützten Server gehen.

Dienstag, 10:15 Uhr: Die Kommunikation

Während Florian die technischen Maßnahmen koordiniert, beginnt die Kommunikation auf mehreren Kanälen.

Interne Kommunikation

Florian informiert die Geschäftsführung, den Kundenservice und das Marketing-Team. Der Kundenservice braucht eine Sprachregelung für eingehende Anrufe, das Marketing muss geplante Social-Media-Posts stoppen (eine Marketing-Kampagne, die auf einen nicht erreichbaren Shop verlinkt, ist kontraproduktiv), und die Geschäftsführung muss die finanzielle Tragweite verstehen.

Die Sprachregelung für den Kundenservice: „Wir haben aktuell technische Beeinträchtigungen bei unserem Online-Shop. Unser IT-Team arbeitet an der Behebung. Wir rechnen damit, dass der Shop in wenigen Stunden wieder normal erreichbar ist. Ihre Bestelldaten und Ihr Kundenkonto sind nicht betroffen, es handelt sich nicht um einen Datenangriff. Wenn Sie jetzt bestellen möchten, können Sie uns gerne telefonisch Ihre Bestellung aufgeben."

Kundenkommunikation

Hier zeigt sich der Wert einer vorbereiteten Statusseite. Die Lichtblick GmbH hat eine einfache Status-Seite bei einem externen Dienst eingerichtet, die auf einer anderen Infrastruktur läuft als der Shop. Diese Seite wird jetzt aktiviert und zeigt:

„Aktueller Status: Unser Online-Shop ist derzeit eingeschränkt erreichbar. Ursache: Technische Beeinträchtigung durch erhöhtes Datenaufkommen. Unser Team arbeitet an der Lösung. Geschätzter Zeitrahmen: Wiederherstellung innerhalb der nächsten Stunden. Ihre Daten sind nicht betroffen. Telefonische Bestellungen: 0800-XXXXXXX. Letztes Update: 10:15 Uhr."

Florian postet den Link zur Status-Seite auf den Social-Media-Kanälen der Firma und richtet eine E-Mail-Weiterleitung ein, sodass Kunden, die den Support per Mail kontaktieren, eine automatische Antwort mit dem Verweis auf die Status-Seite erhalten.

Was man nicht kommunizieren sollte

Florian hat in einer Schulung gelernt, was man bei DDoS-Angriffen nicht öffentlich kommunizieren sollte:

• Nicht das Wort „DDoS-Angriff" in der öffentlichen Kommunikation verwenden, wenn es nicht nötig ist. „Technische Beeinträchtigung durch erhöhtes Datenaufkommen" reicht für Kunden aus und vermeidet, dass Trittbrettfahrer motiviert werden.
• Nicht den Angreifer provozieren. Öffentliche Statements wie „Wir lassen uns nicht erpressen" oder „Der Angriff hat uns nicht geschadet" können den Angreifer motivieren, den Angriff zu intensivieren.
• Keine technischen Details (IP-Adressen, Angriffsvolumen, eingesetzte Schutztools) öffentlich teilen, da sie dem Angreifer helfen, seine Strategie anzupassen.

Dienstag, 11:00 bis 14:00 Uhr: Die Abwehr stabilisiert sich

Um 11:00 Uhr beginnt das Traffic Scrubbing des ISP zu wirken. Ein Teil des Angriffs-Traffics wird gefiltert, und die Netzwerkbandbreite entspannt sich etwas. Der Server ist immer noch unter Last, aber das SSH-Login funktioniert wieder zuverlässig.

Um 11:30 Uhr beginnt die DNS-Umstellung zum CDN zu greifen. Die ersten Nutzer werden über das CDN geleitet, das den Applikationsangriff auf die Suchfunktion effektiv filtert. Der CDN-Anbieter hat automatische Regeln, die verdächtige Request-Muster erkennen und blockieren, etwa wenn eine IP-Adresse innerhalb von einer Sekunde hundert Suchanfragen stellt.

Um 12:30 Uhr sind etwa 70 Prozent des Traffics über das CDN geroutet. Der Shop ist für die meisten Nutzer wieder erreichbar, wenn auch mit erhöhten Ladezeiten. Die Suchanfragen funktionieren wieder.

Um 14:00 Uhr lässt der Angriff deutlich nach. DDoS-Angriffe sind für den Angreifer nicht kostenlos, Botnetze kosten Geld im Betrieb, und wenn die Wirkung ausbleibt (weil der Traffic gefiltert wird), wird der Angriff oft eingestellt. Das Angriffsvolumen sinkt von Spitzenwerten über 8 Gbit/s auf unter 500 Mbit/s und pendelt sich dann auf einem niedrigen Niveau ein.

Technische Maßnahmen während des Angriffs

Während der Angriff läuft, setzt Florian zusätzliche Maßnahmen um:

Rate Limiting: Auf dem Webserver wird ein Rate Limit konfiguriert, das die Anzahl der Anfragen pro IP-Adresse und Zeiteinheit begrenzt. Legitime Nutzer stellen selten mehr als 10 Anfragen pro Sekunde, Angreifer oft hunderte.

Geo-Blocking als Notmaßnahme: Die Analyse zeigt, dass der Großteil des Angriffs-Traffics aus Ländern kommt, in denen die Lichtblick GmbH keine Kunden hat. Florian aktiviert temporär ein Geo-Blocking, das Traffic aus diesen Ländern auf CDN-Ebene blockiert. Das ist keine dauerhafte Lösung (es blockiert auch legitime Nutzer aus diesen Regionen), aber als Notmaßnahme während eines laufenden Angriffs effektiv.

Caching verstärken: Florian konfiguriert das CDN so, dass möglichst viele Seiten aus dem Cache geliefert werden und weniger Anfragen den eigentlichen Server erreichen. Die Startseite, Produktseiten und statische Assets werden aggressiv gecacht.

Nicht-essentielle Dienste reduzieren: Der interne Blog, das Partner-Portal und das Kontaktformular werden vorübergehend deaktiviert, um Server-Ressourcen für den Shop freizumachen.

Dienstag, 15:00 Uhr: Hintergrund des Angriffs

Um 15:00 Uhr meldet sich ein anonymer Absender per E-Mail an die info@-Adresse der Lichtblick GmbH:

„We have demonstrated our capabilities. The attack will resume tomorrow at higher intensity unless 2 BTC are transferred to the following wallet. This is not negotiable."

Jetzt ist klar: Es handelt sich um einen DDoS-for-Ransom-Angriff (auch RDDoS genannt). Der Angreifer hat zunächst einen „Demonstrationsangriff" durchgeführt und fordert nun ein Lösegeld, um weitere Angriffe zu unterlassen.

Nicht zahlen

Florian und die Geschäftsführung sind sich einig: Nicht zahlen. Falls eine Cyber-Versicherung besteht, wird der Vorfall dort gemeldet. Die Gründe sind sowohl prinzipieller als auch praktischer Natur:

• Es gibt keine Garantie, dass der Angriff nach Zahlung aufhört
• Die Zahlung motiviert den Angreifer, andere Unternehmen anzugreifen
• Die Zahlung kann den Angreifer motivieren, dasselbe Unternehmen erneut anzugreifen, da es als zahlungswillig bekannt ist
• Die DDoS-Schutzmaßnahmen (CDN, Scrubbing) sind jetzt aktiv und werden auch einen intensiveren Angriff abfangen

Strafanzeige

Die Erpresser-Mail wird als Beweismittel gesichert (einschließlich der vollständigen E-Mail-Header) und eine Strafanzeige wegen Computersabotage und Erpressung erstattet.

Mittwoch: Der zweite Angriff und die Prävention

Am Mittwochmorgen setzt der Angreifer seine Drohung um. Der Angriff wird mit höherer Intensität fortgesetzt, diesmal mit Spitzenwerten von 15 Gbit/s und zusätzlichen Angriffsvektoren (DNS Amplification neben dem HTTP Flood).

Aber die Lichtblick GmbH ist jetzt vorbereitet. Der CDN-Schutz ist aktiv, das Traffic Scrubbing beim ISP läuft, und Florian hat die DNS-TTL auf 300 Sekunden gesenkt, um bei Bedarf schneller reagieren zu können. Der Shop bleibt für Kunden erreichbar, die Ladezeiten sind etwas erhöht, aber die Funktionalität ist gegeben.

Der Angriff dauert bis Donnerstagmittag und wird dann eingestellt.

Langfristige Prävention

In der Woche nach dem Angriff arbeitet Florian einen DDoS-Präventionsplan aus:

CDN dauerhaft aktivieren. Der CDN-Schutz bleibt permanent aktiv, nicht nur im Notfall. Die DNS-Einträge zeigen dauerhaft auf das CDN. Die echte Server-IP wird nirgendwo öffentlich kommuniziert (Origin IP Protection).

DNS-Infrastruktur härten. Der DNS-Dienst wird auf einen Anycast-DNS-Provider umgestellt, der selbst DDoS-geschützt ist. Ein Angriff auf die DNS-Infrastruktur hätte denselben Effekt wie ein Angriff auf den Webserver: Die Domain wäre nicht mehr auflösbar und der Shop nicht erreichbar.

DDoS-Response-Plan. Florian dokumentiert den kompletten Ablauf des Vorfalls als Incident-Response-Plan: Wen anrufen (ISP-Hotline-Nummer, CDN-Support-Nummer), welche Maßnahmen in welcher Reihenfolge, welche Kommunikationsvorlagen verwenden. Der Plan wird so formuliert, dass auch ein Vertretungskollege ihn ohne Vorkenntnisse abarbeiten kann.

ISP-Eskalationspfad definieren. Florian vereinbart mit dem ISP einen definierten Eskalationspfad für DDoS-Angriffe: direkte Durchwahl zum NOC (Network Operations Center), garantierte Reaktionszeit unter 15 Minuten, und die Möglichkeit, Traffic Scrubbing vorab zu konfigurieren, sodass es im Ernstfall nur aktiviert werden muss.

Redundante Infrastruktur. Für die kritischsten Services (Shop, Kundenportal) – ermittelt durch eine Business Impact Analyse – wird eine Failover-Konfiguration eingerichtet: Wenn der primäre Server nicht mehr erreichbar ist, wird der Traffic automatisch auf einen Backup-Server in einem anderen Rechenzentrum umgeleitet.

Status-Seite pflegen. Die Status-Seite wird dauerhaft betrieben und bei jedem Vorfall zeitnah aktualisiert. Kunden lernen, bei Problemen zuerst die Status-Seite zu prüfen, statt den Kundenservice zu überlasten.

TTL niedrig halten. Die DNS-TTL wird dauerhaft auf 300 Sekunden gesetzt. Im Normalbetrieb hat das keine Nachteile (die DNS-Auflösung ist ohnehin schnell), aber im Notfall erlaubt es eine DNS-Umstellung innerhalb von fünf Minuten statt einer Stunde.

Die Kosten eines DDoS-Angriffs

Florian erstellt eine Schadensbilanz für die Geschäftsführung:

Direkte Kosten:

• CDN-Service (Jahresvertrag nach Aktivierung): ca. 4.800 Euro/Jahr
• Überstunden IT-Team: ca. 2.500 Euro
• Entgangener Umsatz während des Ausfalls (ca. 6 Stunden am ersten Tag): geschätzt 8.000 bis 12.000 Euro
• Telefonkosten für Kundenservice während des Ausfalls: ca. 500 Euro

Indirekte Kosten:

• Drei Kunden haben ihre Bestellung bei einem Wettbewerber aufgegeben und sind nicht zurückgekommen
• Ein Geschäftskunde hat angefragt, ob die Lichtblick GmbH über eine DDoS-Schutzstrategie verfügt, bevor er seinen Rahmenvertrag verlängert
• Das Marketing-Team musste eine geplante Kampagne verschieben, weil der Shop am Kampagnentag nicht zuverlässig erreichbar war

Gesamtschaden: Geschätzt 15.000 bis 25.000 Euro, abhängig von den langfristigen Kundenverlusten.

Die Investition in dauerhaften DDoS-Schutz (CDN, Anycast-DNS, Redundanz) liegt bei etwa 8.000 bis 12.000 Euro pro Jahr. Angesichts der Schadenshöhe eines einzelnen Angriffs ist das eine rechnerisch klare Entscheidung.

DDoS als Ablenkungsmanöver

Ein Aspekt, den Florian im Lessons-Learned-Workshop anspricht: DDoS-Angriffe werden manchmal als Ablenkungsmanöver genutzt. Während das IT-Team mit der DDoS-Abwehr beschäftigt ist, findet der eigentliche Angriff auf einer anderen Ebene statt – beispielsweise ein Ransomware-Angriff, etwa der Versuch, über eine Schwachstelle ins Netzwerk einzudringen, oder eine Phishing-Kampagne gegen Mitarbeiter.

In diesem Fall gab es keine Anzeichen für einen parallelen Angriff. Aber Florian implementiert als Konsequenz eine Regel: Bei jedem DDoS-Angriff wird parallel eine Prüfung auf andere Angriffsformen durchgeführt. Ein Mitarbeiter überwacht die Firewall-Logs und das IDS (Intrusion Detection System) auf verdächtige Aktivitäten, die nichts mit dem DDoS-Traffic zu tun haben.

Was dieser Fall lehrt

DDoS-Angriffe gehören zu den Vorfällen, die sich am besten vorbereiten lassen, weil die Gegenmaßnahmen weitgehend standardisiert sind und der Schutz proaktiv eingerichtet werden kann, bevor ein Angriff stattfindet.

DDoS-Schutz ist kein Luxus. Jedes Unternehmen, dessen Geschäft von der Erreichbarkeit seiner Online-Dienste abhängt, braucht einen DDoS-Schutzplan. Die Kosten für CDN-basierten Schutz liegen im niedrigen vierstelligen Bereich pro Jahr. Die Kosten eines erfolgreichen Angriffs liegen oft bei einem Vielfachen davon.

DNS ist der Flaschenhals. Die DNS-Umstellung auf das CDN hat eine Stunde gedauert, weil die TTL zu hoch war. Diese eine Stunde war die verwundbarste Phase des gesamten Vorfalls. Eine niedrige TTL und die permanente CDN-Nutzung hätten den Schaden auf Minuten reduziert.

Kommunikation über alternative Kanäle. Wenn die Website down ist, musst du über andere Kanäle kommunizieren können: Status-Seite auf externer Infrastruktur, Social Media, Telefon, E-Mail-Autoresponder. Diese Kanäle müssen vorbereitet und getestet sein, nicht erst im Ernstfall eingerichtet werden.

Nicht zahlen, sondern schützen. DDoS-for-Ransom funktioniert nur, wenn Unternehmen zahlen. Wer einmal zahlt, wird erneut angegriffen. Die richtige Antwort auf eine Erpressung ist die Investition in Schutzmaßnahmen, nicht die Zahlung an Kriminelle.

DDoS kann jeden treffen. Die Lichtblick GmbH ist kein Großkonzern, kein Finanzdienstleister, kein kritisches Infrastrukturunternehmen. Es ist ein mittelständischer Online-Händler. DDoS-Angriffe sind heute so günstig durchzuführen (ein paar hundert Euro für einen mehrstündigen Angriff), dass jedes Unternehmen mit einer Onlinepräsenz zum Ziel werden kann. Die Frage ist nicht ob, sondern wann, und ob du darauf vorbereitet bist. In ISMS Lite lassen sich Notfallpläne, Verfügbarkeitsanforderungen und Incident-Response-Abläufe dokumentieren, damit du im Ernstfall strukturiert reagieren kannst.

Weiterführende Artikel

• IT-Notfallkarte: Alle Kontakte und Erstmaßnahmen auf einen Blick
• Wiederanlaufplan erstellen: Systeme priorisieren und strukturiert wiederherstellen
• Business Impact Analyse: Kritische Prozesse identifizieren und Ausfallkosten bewerten
• Sicherheitsvorfälle kommunizieren: Intern, extern und an die Presse
• Netzwerksegmentierung für KMU: Schaden begrenzen durch kluge Architektur