Was ist ein DDoS-Angriff?
DDoS-Angriffe gehören heute zu den häufigsten und sichtbarsten Cyberbedrohungen. Plötzlich ist eine Website nicht erreichbar, Anwendungen laden endlos, Services brechen ab – und nichts scheint zu helfen. In diesem Beitrag erklären wir verständlich, was hinter einem DDoS-Angriff steckt, wie solche Angriffe funktionieren, welche Typen es gibt, wie du Anzeichen früh erkennst und dich sinnvoll schützt. Am Ende zeigen wir, wie wir bei der LEMA-IT mit dir gemeinsam ein praxistaugliches Schutz- und Reaktionskonzept aufsetzen.
Definition und Bedeutung von DDoS
Bevor wir ins Detail gehen, klären wir die Begriffe. DoS steht für Denial of Service – also die „Verweigerung eines Dienstes“. Ein DDoS ist die verteilte Variante (Distributed Denial of Service). Während beim DoS eine einzelne Quelle versucht, einen Dienst zu stören, greifen beim DDoS gleichzeitig sehr viele Systeme an. Das Ergebnis ist dasselbe: legitime Nutzer:innen bekommen keinen Zugriff, die Verfügbarkeit leidet oder bricht komplett ein.
In der Praxis heißt das: Der Angreifer flutet ein Ziel – etwa eine Website, eine API, einen Mail- oder DNS-Dienst – mit so viel künstlichem Datenverkehr, dass Kapazitäten wie Bandbreite, CPU, Arbeitsspeicher oder Verbindungs-Slots erschöpfen. Eine oft genutzte Analogie ist der Stau: Stell dir vor, auf einmal fahren Tausende Fahrzeuge gleichzeitig auf die gleiche Auffahrt – selbst eine sechsspurige Autobahn kommt zum Erliegen. Genauso „verstopfen“ DDoS-Angriffe Netze und Server.
Wie funktioniert ein DDoS-Angriff?
In diesem Abschnitt bekommst du den technischen Blick, ohne abgehobenes Vokabular – damit du die Funktionsweise wirklich einordnen kannst.
Botnetze und infizierte Geräte
Das Rückgrat moderner DDoS-Angriffe sind Botnetze: Netze aus kompromittierten Geräten, die zentral fernsteuerbar sind. Dafür missbrauchen Angreifer nicht nur klassische PCs oder Server. Besonders beliebt sind IoT-Geräte (Überwachungskameras, Router, Smart-Home-Hubs, Set-Top-Boxen), weil sie oft mit Standardpasswörtern laufen und selten Updates bekommen. Einmal infiziert, gehorchen sie dem „Botmaster“ – und senden auf Kommando massenhaft Anfragen an ein Ziel.
Ablauf eines Angriffs
Ist ein Botnetz aufgebaut, verteilt der Angreifer Befehle. Die Bots beginnen, große Mengen an Anfragen an die Ziel-IP zu schicken – HTTP-GETs an eine Website, UDP-Pakete an offene Ports, gefälschte TCP-SYNs für halboffene Verbindungen und vieles mehr. Für den Zielserver sehen viele dieser Anfragen legitim aus: Es sind ja „normale“ Protokolle. Genau das macht die Abwehr schwer – das System muss zwischen echtem Besucherverkehr und Angriffsverkehr unterscheiden, oft innerhalb von Millisekunden.
Unterschied zwischen DoS und DDoS
DoS und DDoS verfolgen denselben Effekt – Überlastung – unterscheiden sich aber in Herkunft und Wirkung:
- DoS (Single-Source): Eine Quelle, häufig ein einzelner Rechner oder Server, sendet übermäßig viele Anfragen. Das ist leichter zu erkennen und zu blockieren, weil die IP-Quelle klarer ist.
- DDoS (Multi-Source): Hunderte, Tausende, manchmal Hunderttausende Quellen (Bots) greifen gleichzeitig an. Hier ist die Blockade einzelner IPs sinnlos – die Angriffsfläche ist massiv verteilt. Außerdem kommen die Pakete oft aus unterschiedlichsten Netzen und Ländern.
In der Realität sehen wir weit öfter DDoS- als DoS-Ereignisse – schlicht, weil Botnetze verfügbar sind und Angriffe als „Service“ gemietet werden können.
Arten von DDoS-Angriffen
Bevor wir die gängigen Typen erklären, ein kurzer Rahmen: Netzwerkkommunikation lässt sich mit dem OSI-Modell in Schichten denken. DDoS-Angriffe zielen auf unterschiedliche Schichten – und damit auf verschiedene Ressourcen.
Angriffe auf Anwendungsebene (Layer 7)
Bei Layer-7-Angriffen greifen Bots direkt die Anwendung an, z. B. die Webschicht (HTTP/S). Typisch sind:
- HTTP-Floods: Viele gleichzeitige GET/POST-Anfragen an Webseiten oder API-Endpunkte. Besonders tückisch, wenn „teure“ Requests getroffen werden – etwa dynamische Seiten mit Datenbankabfragen.
- „Low and Slow“ (z. B. Slowloris): Der Server wird nicht mit Lautstärke, sondern mit Langsamkeit ausgebremst. Viele Verbindungen werden geöffnet, aber in winzigen Häppchen weitergeschickt, sodass der Server Ressourcen lange blockiert.
Warum schwer abzuwehren? Weil sich die Anfragen zunächst wie legitime Webzugriffe anfühlen.
HTTP-Floods – Ablauf und Wirkung aus Verteidiger-Sicht
Schritt 1 – Zielauswahl im Anwendungspfad.
Typischerweise konzentriert sich der Angriffsverkehr auf dynamische Endpunkte, an denen pro Request viel Serverarbeit anfällt: Suchmasken, Produktlisten mit aufwendigen Filtern, Login- oder Passwort-Funktionen, Warenkorb-/Checkout-Schritte oder API-Routen, die Daten aggregieren. Aus Verteidiger-Perspektive erkennst du das an plötzlichen Hotspots in genau diesen Pfaden, während statische Inhalte (Bilder, CSS) vergleichsweise unauffällig bleiben.
Schritt 2 – Charakter des Traffics.
Der Strom an HTTP-Anfragen steigt breitflächig und kontinuierlich; die Verteilung über User-Agents, Referrer und Zeitstempel wirkt zunächst plausibel. Entscheidend ist weniger die pure Bandbreite als Requests pro Sekunde und gleichzeitige Sitzungen. Auffällig wird es, wenn die p95/p99-Latenzen in der App anziehen, obwohl am Netzwerk-Edge noch alles „grün“ aussieht.
Schritt 3 – Teuer wird’s hinter der Mauer.
Die eigentliche Last entsteht nach dem Reverse-Proxy oder CDN: Dein Application-Server befüllt Templates, baut Sessions auf, zieht aus dem DB-Connection-Pool Verbindungen, führt Query-Pläne aus und wartet ggf. auf Dritt-APIs. Das führt zu Thread-/Worker-Sättigung, wachsenden Warteschlangen und Pool-Erschöpfung (DB-Connections, HTTP-Worker, Message-Queues). Im Monitoring sieht man zuerst steigende Queue-Times und eine CPU-Last im Applayer/DB, bevor 5xx-Fehler hochschnellen.
Schritt 4 – Warum das so schwer zu blocken ist.
Die Requests sind formal korrekt und verhalten sich oberflächlich wie echte Nutzer: gleiche Protokolle, valide Header, scheinbar normale Navigationspfade. Klassische Netzwerkfilter greifen daher zu spät oder gar nicht. Selbst WAF-Regeln tun sich schwer, weil es nicht um Signaturen geht, sondern um die Summe legitimer Operationen an den teuersten Stellen deiner Anwendung.
Schritt 5 – Typische Symptome in der Kette.
Edge/CDN bleibt unauffällig, aber dein Origin meldet erhöhte Antwortzeiten. Der DB-Pool läuft gegen das Limit, Cache-Hit-Rates fallen (weil ungewöhnliche Parameterkombinationen ankommen), die Anwendungs-Threads hängen auf I/O. Schließlich steigen HTTP 502/503 (Upstream kaputt/überlastet) oder 408/499 (Clients/Proxies geben auf), obwohl das physische Netzwerk nicht gesättigt ist.
„Low and Slow“ (z. B. Slowloris/Slow POST) — Ablauf und Wirkung (Verteidiger-Sicht)
Schritt 1 – Ressourcen werden durch Zeit gebunden
Der Angreifer eröffnet viele gleichzeitige Verbindungen, sendet aber extrem langsam: Header tröpfeln in Mini-Segmenten oder der Body eines POSTs wird nur Byte für Byte geliefert. Dein Server hält jede dieser Verbindungen geduldig offen, reserviert dafür Dateideskriptoren, Sockets, Worker-Slots oder Speicher, und blockiert so Kapazität für echte Nutzer.
Schritt 2 – Wo es am meisten schmerzt.
Betroffen sind vor allem Architekturen, die pro Verbindung Ressourcen binden (z. B. bestimmte Thread-/Worker-Modelle) oder bei langsamen Lesern/Schreibern lange Timeouts tolerieren. Auch Load-Balancer und Reverse-Proxies können erschöpfen, wenn ihre Max-Connections oder Header/Body-Read-Timeouts großzügig eingestellt sind.
Schritt 3 – Sichtbare Effekte im Betrieb.
Du bemerkst eine hohe Anzahl offener Verbindungen bei gleichzeitig niedriger Datenrate. In Dashboards klettern Kennzahlen wie „Current Connections“ und „Waiting/Reading“, während CPU zunächst moderat bleibt. Nutzer erleben timeouts und hängende Seiten, obwohl kaum Volumen übertragen wird. Im Log erscheinen vermehrt 408/504 (Timeouts), manchmal ohne klare Spitzen in Requests-pro-Sekunde.
Schritt 4 – Warum das schwer abzuwehren ist.
Die einzelnen Verbindungen sind RFC-konform und verletzen keine Protokollregeln; sie sind nur untypisch langsam. Klassische Volumen-Erkennung greift nicht, Rate-Limits pro IP helfen wenig, wenn zahlreiche Quellen beteiligt sind. Eine zu aggressive Verkürzung der Timeouts gefährdet wiederum legitime langsame Clients (z. B. mobile Netze, große Uploads).
Volumetrische Angriffe
Ziel ist die Bandbreitensättigung zwischen Internet und Ziel. Häufig über Amplification/Reflection:
- DNS-Amplification (Reflection): Kleine Anfragen an offene DNS-Server mit gefälschter Absender-IP (der IP des Opfers) erzeugen große Antworten, die beim Opfer landen. Das multipliziert die Angriffsleistung.
- Ähnliche Muster gibt es mit NTP, SSDP, CLDAP, Memcached und anderen UDP-basierten Diensten.
In der Praxis kombinieren Angreifer diese Vektoren zu Multi-Vektor-Angriffen: Während ein volumetrischer Angriff die Leitungen füllt, versucht ein paralleler Layer-7-Flood, die Anwendung selbst zu kippen.
Ziele und Motive hinter DDoS-Angriffen
Warum machen Angreifer das? Die Motive sind vielfältig:
- Erpressung: „Zahlt, sonst bleibt ihr offline.“ Häufig mit Drohungen, am Freitagabend oder vor Produktlaunches zuzuschlagen.
- Ablenkung: Während das Team mit DDoS beschäftigt ist, laufen im Hintergrund Datendiebstahl oder Ransomware-Initialangriffe.
- Wettbewerbsschädigung: Unlauterer Wettbewerb – der Shop der Konkurrenz ist während einer Rabattaktion „zufällig“ offline.
- Hacktivismus/Protest: Politisch oder gesellschaftlich motivierte Angriffe gegen Institutionen, Medien, Unternehmen.
- Staatliche Akteure: Geopolitisches Störfeuer gegen Infrastrukturen.
- „Fun“ und Testen: Leider auch: Machtdemonstration, Langeweile, Script-Kiddies.
Wie erkennt man einen DDoS-Angriff?
DDoS-Symptome ähneln oft legitimen Traffic-Spitzen (Produktlaunch, Medienbericht, Marketing-Kampagne). Trotzdem gibt es Muster, die warnen:
- Plötzliche, starke Verlangsamung oder Ausfälle ohne erklärbaren Anlass.
- Ungewöhnliche Traffic-Muster: Peaks zu untypischen Zeiten, regelmäßige Wellen (z. B. alle 10 Minuten), dauerhaft hohe gleichförmige Last.
- Konzentration auf Endpunkte: Eine einzelne URL oder API wird unverhältnismäßig häufig aufgerufen.
- Homogener Traffic: Viele Anfragen mit gleichem User-Agent, identischen Header-Mustern oder aus einer eng umrissenen ASN/Region (nicht zu verwechseln mit legitimen Kampagnen).
- Fehler- und Log-Signaturen: Zunahme von 503/504, steigende Verbindungstimeouts, SYN-Queues voll, erhöhte RST-/ICMP-Raten.
Wichtig ist kontinuierliches Monitoring (Metriken, Logs, Flow-Daten) plus Alarmierung. Wer erst bei Totalausfall merkt, dass etwas nicht stimmt, verliert wertvolle Reaktionszeit.
Abwehr- und Schutzmaßnahmen gegen DDoS
Du kannst DDoS nicht „abschalten“, aber Risiken senken und Wirkungen begrenzen. Ein realistischer Ansatz kombiniert Prävention, Detektion und Reaktion.
Präventive Maßnahmen
Bevor der Ernstfall eintritt, solltest du die Hausaufgaben machen. Dazu zählen:
- Angriffsfläche minimieren: Unnötige Dienste schließen, nur benötigte Ports freigeben, Rate-Limits an sensiblen Endpunkten, API-Keys und Auth überall, wo sinnvoll.
- Härtung & Updates: Systeme und IoT-Geräte patchen, Standardpasswörter verbieten, MFA für Admin-Zugänge, saubere Netzsegmentierung.
- Beobachtbarkeit aufbauen: Metriken (Traffic, Latenzen, Fehler), zentrale Logs, NetFlow/sFlow, synthetische Tests, Alarmierungsprofile.
- Kapazitätsplanung: Elastische Ressourcen (Cloud-Skalierung, horizontale Skalierung, Caching, CDN) reduzieren Anfälligkeit für Lastspitzen.
Technische Maßnahmen
Wenn es ernst wird, zählen diese Bausteine:
- Web Application Firewall (WAF): Filtert auf Anwendungsebene (Layer 7), erkennt typische Muster (z. B. bösartige Header, Bot-Signaturen), lässt legitime Anfragen durch.
- Rate Limiting/Connection Limits: Begrenzt pro IP/API-Key/Route, schützt vor Missbrauch – in Kombination mit Whitelists und Captchas.
- Anycast & verteilte Edge: Verteilte Infrastrukturen absorbieren und verteilen Angriffsverkehr – je näher an der Edge, desto besser.
- DDoS-Mitigation (Scrubbing): Spezialisierte Netze mit hoher Kapazität waschen Traffic und leiten bereinigt weiter (on-demand oder always-on).
- Blackhole/Null-Routing (ultima ratio): Verkehr für eine Ziel-IP verwerfen, um die übrige Infrastruktur zu schützen – schneidet aber auch legitime Nutzer ab, daher nur gezielt und temporär.
Strategischer Ansatz
Technik wirkt erst im Prozess:
- Runbook/Playbooks: Wer tut was, wenn Alarm X auslöst? Schwellenwerte, Eskalationsketten, Kommunikationsplan (auch extern: Status-Page, Kundeninfo).
- Übungen: DDoS-Drills, Chaos-Tests, Post-Mortems. Nur geübte Teams reagieren schnell und koordiniert.
- Mehrschichtige Abwehr („Defense in Depth“): Netzwerk-, Transport- und Anwendungsebene gemeinsam betrachten; Signale aus allen Schichten korrelieren.
Rechtliche Situation in Deutschland
Rein rechtlich ist bereits der Versuch der Computersabotage in Deutschland strafbar (§ 303b StGB). Auch die Vorbereitung – etwa die Verbreitung einschlägiger Tools – kann eine Straftat sein. Für Unternehmen wichtig: Dokumentation des Vorfalls und Beweissicherung unterstützen spätere zivilrechtliche Ansprüche (Schadensersatz). Dieser Abschnitt ersetzt keine Rechtsberatung; bei konkreten Fällen solltest du juristischen Rat einholen.
DDoS-Angriffe in der Praxis
Ob E-Commerce, Medien, Banking, Gaming oder öffentliche Einrichtungen – DDoS trifft alle Branchen. Die unmittelbaren Folgen sind spürbar: Umsatzausfälle, Support-Last, Reputationsschäden, verpasste SLAs und interne Produktivitätsverluste. Noch gravierender sind Kombinationsangriffe, bei denen DDoS nur die Bühne für eine zweite, verdeckte Attacke bereitet. Wer vorbereitet ist, limitiert die Auswirkungen und bleibt handlungsfähig.
Lösung: IT-Sicherheit mit professioneller Unterstützung
Viele Organisationen unterschätzen den Aufwand, einen wirksamen DDoS-Schutz sauber zu planen, zu testen und im Betrieb zu halten. Hier trennen sich Theorie und Alltag: Welche Limits sind sinnvoll, ohne echte Nutzer auszubremsen? Welche WAF-Regeln helfen tatsächlich gegen Layer-7-Floods – und welche erzeugen False Positives? Wie orchestrierst du CDN, Scrubbing, Firewall und App-Team im Ernstfall?
Wir von der LEMA-IT begleiten dich von der Analyse bis zum laufenden Betrieb – partnerschaftlich, pragmatisch und mit festen Ansprechpersonen:
- Individuelle Risikoanalyse: Bedrohungsmodell, Angriffsflächen, kritische Pfade deiner Anwendungen und APIs.
- Architektur & Härtung: Netzwerksegmentierung, saubere Exponierung, sinnvolle Rate-Limits, Caching-Strategien, CDN- und Anycast-Einbindung.
- DDoS-Mitigation-Konzept: Auswahl und Integration von WAF, Scrubbing-Services (on-demand/always-on), Logging/Monitoring, Alerting.
- Runbooks & Notfallprozesse: Klar definierte Abläufe, Eskalationsketten, Test- und Übungsszenarien – damit im Ereignisfall keine Zeit verloren geht.
- 24/7-Betrieb & Wartung: Überwachung, Regel-Tuning, regelmäßige Reviews, abgestimmte Updates und Changes außerhalb deiner Peak-Zeiten.
- Erweiterter Schutz: Von IT-Sicherheit (Firewall-Management, Endpoint, E-Mail-Security) über Microsoft 365 bis zu Cloud-Telefonie und MDM – wir denken Sicherheit ganzheitlich.
Unser Anspruch ist, Transparenz und Einfachheit zu schaffen: keine Blackbox, keine Buzzwords. Du bekommst Lösungen, die zu deinem Geschäft passen und mitwachsen – von On-Prem bis (Teil-)Cloud.
Fazit – DDoS als reale Gefahr für Unternehmen
DDoS-Angriffe sind kein exotisches Randthema, sondern gelebter Alltag im Netz. Wer die Bedeutung versteht, die Funktionsweise kennt und die richtigen Maßnahmen vorbereitet, reduziert Ausfälle und bleibt auch unter Feuer betriebsfähig. Entscheidend ist ein mehrschichtiger Ansatz aus Prävention, schneller Erkennung und geübter Reaktion – technisch und organisatorisch. Wir bei der LEMA-IT helfen dir, genau das aufzubauen: pragmatisch, transparent und mit festen Ansprechpartnern.
