DDoS-Angriffe: Arten, Symptome und Schutzmaßnahmen

17. Februar 2026 • 7 min read

Inhaltsverzeichnis

DDoS ist kein neues Phänomen, aber es ist heute deutlich einfacher, billiger und skalierbarer geworden. Früher reichten ein paar schlecht konfigurierte Server oder ein kleines Botnetz, um einen Dienst zu stören. Heute sehen wir regelmäßig Angriffe, die in Sekundenbruchteilen ganze Leitungen füllen, Firewalls überfordern oder Anwendungen durch scheinbar „normale“ Requests in die Knie zwingen.

In diesem Artikel geht es nicht um Panikmache, sondern um Einordnung: Was ist DDoS genau, welche Angriffsklassen gibt es, woran erkennst du das Ganze im Betrieb, und welche Schutzmaßnahmen bringen in der Praxis wirklich etwas?

Was ist (D)DoS?

Bei einem Denial-of-Service (DoS)-Angriff versucht ein Angreifer, einen Dienst nicht durch Datenklau, sondern durch Überlastung oder Ressourcenerschöpfung unbrauchbar zu machen. Das Ziel ist „Availability“: Deine Website lädt nicht mehr, deine API time-outet, dein VPN-Gateway nimmt keine Sessions mehr an, deine DNS-Resolver kommen nicht hinterher.

Das „D“ in Distributed bedeutet: Der Traffic kommt nicht von einer Quelle, sondern von vielen. Das kann ein Botnetz aus kompromittierten Geräten sein, legitime Infrastruktur (Reflection/Amplification) oder eine Kombination aus beidem. Für dich als Betreiber ist das Ergebnis gleich: Du siehst nicht „den einen“ Angreifer, sondern eine Flut aus verteilten Quellen.

Motive: Warum werden DDoS-Angriffe gefahren?

Die Motive sind oft unspektakulär, aber effektiv:

Erpressung: „Zahl oder wir legen euch wieder lahm.“
Aktivismus/Politik: Sichtbarkeit erzeugen, Botschaften platzieren, Gegner stören.
Ablenkung: Ein DDoS kann Security-Teams binden, während parallel ein anderer Angriff läuft.
Wettbewerb/Sabotage: Gerade bei zeitkritischen Events (Ticketing, Releases, Launches) reicht schon ein kurzer Ausfall.
Kosten verursachen: Nicht jede Attacke zielt auf einen kompletten Down. Manchmal geht es darum, Cloud-Kosten, Supportaufwand oder Betriebsstress zu erhöhen.

Die wichtigen „Layer“ (und warum das relevant ist)

DDoS wird oft entlang von Schichten beschrieben, weil sich daraus Messwerte und Gegenmaßnahmen ableiten.

Layer 3 (IP): „Wo kommt es her, wo soll es hin?“
Layer 4 (TCP/UDP): Ports, Verbindungen, Handshakes, Zustände.
Layer 7 (Application): HTTP(S)-Requests, APIs, Business-Endpunkte.
„Layer 8“ (Business-Logik): Nicht offiziell, aber praktisch: teure Logik in deiner App, die sich ausnutzen lässt.

Die wichtigste Konsequenz: Ein Schutz, der auf Layer 3/4 perfekt funktioniert, kann bei Layer-7-Angriffen trotzdem versagen, weil die Requests „legitim aussehen“ und erst in deiner Anwendung teuer werden.

Angriffsklasse 1: Volumen und Amplification (meist UDP)

Volumetrische Angriffe zielen darauf ab, Bandbreite oder Paketverarbeitung (pps) zu erschlagen. Ein klassischer Verstärker ist Reflection/Amplification:

Der Angreifer sendet kleine Requests an öffentlich erreichbare Server (z. B. offene DNS-Resolver).
Er fälscht dabei die Absenderadresse (Spoofing) und setzt als „Source“ die IP des Opfers.
Die Server antworten mit deutlich größeren Responses an das Opfer.

Wenn aus 100 Byte Anfrage 1.000 Byte Antwort werden, hast du schon einen Faktor 10. Je nach Protokoll und Payload kann das deutlich höher ausfallen. Das Gemeine: Aus Sicht des Opfers kommt der Traffic von „normalen“ Diensten, die man ungern blockiert.

Wichtiger Punkt: Amplification braucht meistens Source-IP-Spoofing. Deshalb ist Ingress Filtering (BCP 38) so zentral: Wenn Provider gefälschte Absenderadressen am Rand konsequent blocken, fällt dieser Angriffsvektor deutlich schwerer.

Angriffsklasse 2: Protokoll- und State-Exhaustion (TCP/Layer 4)

Nicht immer geht es um maximale Bandbreite. Häufig ist es effizienter, Zustände auf der Gegenseite zu erzeugen, bis Tabellen oder Ressourcen voll laufen.

Ein Klassiker ist der SYN-Flood gegen TCP:

Normalerweise baut TCP eine Verbindung über den Three-Way-Handshake auf (SYN → SYN/ACK → ACK).
Beim SYN-Flood werden massenhaft SYNs geschickt, aber das finale ACK bleibt aus.
Der Server hält viele halboffene Verbindungen (State) und versucht Wiederholungen, bis Timeouts greifen.

Das kostet Speicher, CPU und kann auch die ausgehende Bandbreite belasten. Und selbst wenn du genug Bandbreite hast: Wenn das Session-Tracking voll ist, ist „Down“ schnell erreicht.

Eine verwandte Kategorie sind „low and slow“-Angriffe: Der Angreifer baut echte Verbindungen auf, hält sie aber mit minimalem Traffic offen, bis dein Webserver oder Loadbalancer seine Connection-Limits erreicht. Das kann deutlich weniger auffällig sein als ein harter Spike in der Bandbreite.

Angriffsklasse 3: Layer 7 und „Layer 8“ (HTTP, APIs, teure Endpunkte)

Layer-7-Angriffe sind oft am nervigsten, weil sie schwerer von legitimen Zugriffen zu unterscheiden sind. Beispiele:

HTTP Floods: Viele Requests auf dynamische Seiten, Search-Endpoints oder Login-Flows.
Slowloris/Slow-Header: Verbindungen werden offen gehalten, indem Header oder Body nur tröpfchenweise gesendet werden.
„Teure“ Business-Logik: Endpunkte, die Datenbank-Queries, externe API-Calls, PDF-Generierung, Kryptografie oder gar AI/Agent-Workflows triggern.

Der Trick ist nicht unbedingt „mehr Traffic“, sondern mehr Arbeit pro Request. Eine kleine Menge gut gewählter Requests kann teurer sein als ein großer Schwall statischer GETs auf gecachte Inhalte.

Woran erkennst du einen DDoS im Betrieb?

Wenn du „nur“ auf CPU und RAM schaust, wirst du manche Angriffe zu spät sehen. In der Praxis helfen Baselines und ein paar robuste Metriken:

Traffic: bps und pps am Edge (Router, Firewall, Loadbalancer).
Connection-Zahlen: neue Verbindungen/s, offene Sessions, SYN-Backlog, TLS-Handshakes/s.
HTTP-Metriken: RPS, Latenzen (p95/p99), 4xx/5xx-Quoten, Timeouts.
Upstream-Symptome: Paketverlust, erhöhte RTT, saturierte Links, BGP-Events.
Log- und WAF-Signale: ungewöhnliche Pfade, invalide Header, viele Requests ohne vollständige Requests, auffällige User-Agents/Patterns.

Der wichtigste Teil ist banal, aber entscheidend: Du brauchst eine Normalform. Ohne Baseline ist alles „irgendwie viel“. Mit Baseline siehst du plötzlich, dass z. B. „kleine Pakete“ oder „unvollständige Requests“ stark von der Norm abweichen.

Schutzmaßnahmen: Was in der Praxis funktioniert

Es gibt zwei grundsätzliche Wege: Make (selbst bauen) oder Buy (Dienst einkaufen). Für die meisten Teams ist „Buy“ realistischer, weil DDoS-Abwehr schnell in Größenordnungen wächst, die du nicht nebenbei betreibst.

1) Vor die Anwendung schalten: CDN/WAF/DDoS-Provider

Für Websites und APIs ist das häufig die effektivste Maßnahme:

Anycast-Netzwerke verteilen Traffic auf viele Standorte.
WAF-Regeln können offensichtliche Layer-7-Muster filtern.
Bot-Management, Rate-Limits, Challenge/Response reduzieren „billige“ Angriffe.

Wichtig: Nicht jeder Angriff geht über HTTP. Wenn du Dienste wie VPN, VoIP, Gameserver oder UDP-basierte Protokolle anbietest, brauchst du je nach Setup andere Schutzschichten.

2) Rate Limiting und Timeouts richtig setzen

Einfach, aber wirkungsvoll, wenn es sauber umgesetzt ist:

ICMP/„Ping“: limitieren, nicht komplett verbieten (Troubleshooting bleibt möglich).
HTTP: pro IP/Token/Route begrenzen, besonders für teure Endpunkte.
Slow-Requests: harte Timeouts für unvollständige Header/Bodies.

Ein Beispiel (Nginx, stark vereinfacht) für Request-Limits auf einer Route:

limit_req_zone $binary_remote_addr zone=api_per_ip:10m rate=10r/s;

location /api/ {
  limit_req zone=api_per_ip burst=40 nodelay;
}

Das ist kein Allheilmittel, aber es verschiebt die Economics: „billig angreifen“ wird schwieriger.

3) Architektur: „Teure“ Dinge entkoppeln

Layer-7-DDoS trifft oft nicht die Bandbreite, sondern die Stellen, an denen ein einzelner Request unverhältnismäßig teuer ist. Und genau diese Stellen gibt es in „normalen“ Firmen-Setups zuhauf: Login, Suche, PDF-Exporte, Reports, Uploads, alles mit komplexen DB-Queries oder alles, was externe APIs anfasst.

Ein typisches Beispiel aus dem Alltag: Ein Kundenportal hat einen Export-Button („Rechnung als PDF“, „Report generieren“, „Alles als ZIP“). Im Normalbetrieb klickt da alle paar Minuten mal jemand drauf. Im Angriff triggert jemand denselben Endpoint hunderte oder tausende Male pro Minute. Bandbreite ist dabei nicht das Problem, sondern CPU (Rendering), DB (Queries) und Worker-Pools (Threads/Connections). Von außen sieht es aus wie „die Seite ist langsam“, intern siehst du plötzlich Timeouts, Queueing und eine Datenbank, die nur noch hinterherläuft.

Die gute Nachricht: Man muss dafür nicht gleich alles neu bauen. Oft reichen ein paar Architektur-Entscheidungen, die den „teuren“ Teil vom Request-Pfad trennen und dem System eine Bremse geben:

Caching (auch für Fehlerseiten), sinnvolle TTLs, Edge-Caching.
Asynchrone Verarbeitung (Queues) für teure Jobs: statt „PDF sofort“ lieber „Job anstoßen“ und später liefern.
Strikte Input-Validierung und frühes Abbrechen: Query-Komplexität begrenzen, harte Limits pro Request.
Separater Schutz für Login, Suche, Upload, Export und ähnliche Endpunkte: eigene Rate-Limits, eigene Timeouts, ggf. eigene Worker-Pools.
„Notbetrieb“-Schalter (Feature-Flags): einzelne Funktionen temporär deaktivieren, ohne Deploy-Stress.

4) Upstream-Optionen: Filtern, scrubbing, Notfallpläne

Wenn es richtig groß wird, musst du Traffic vor deinem Anschluss rausfiltern:

Provider-seitiges Filtering / Scrubbing-Center
Temporäre Block-Regeln (z. B. „Warum kommt überhaupt UDP auf meinen Webserver?“)
Notfall-Routing (z. B. Traffic auf eine „Schutz“-IP umschalten)

Das funktioniert nur, wenn du es vorher mit deinem Provider geklärt hast. Im Ernstfall „ad hoc“ anfangen, ist teuer und langsam.

Eine pragmatische Checkliste (für Teams ohne DDoS-Spezialisten)

Inventar: Welche Dienste sind öffentlich? HTTP, DNS, VPN, Mail, Gaming, VoIP?
Single Points of Failure: DNS-Provider, Reverse Proxy, LB, eine einzige Region?
Observability: bps/pps, RPS, Latenzen, Errors, Connection-Counts, Alerts mit Baseline.
Defaults härten: Timeouts, Limits, maximale Headergrößen, Connection-Limits, Backpressure.
Provider-Plan: Wer scrubbt, wer kann filtern, welche Eskalationswege gibt es?
Runbook: „Wenn X passiert, dann Y“ inklusive Kontakte, Schwellwerte, Schalter (Feature-Flags).
Üben: kontrollierte Lasttests und Incident-Drills (legal und abgestimmt).

Zum Schluss: Testen, aber legal und sinnvoll

DDoS „testen“ ist ein sensibles Thema. Alles, was öffentliches Netz, fremde Systeme oder nicht freigegebene Infrastruktur betrifft, ist tabu. Was du aber sehr sinnvoll tun kannst:

Lasttests in einer eigenen Staging-Umgebung (z. B. Performance-Tests für teure Endpunkte).
Chaos-Tests für Abhängigkeiten (Cache aus, DB langsam, Rate-Limits scharf).
DDoS-Response-Prozess proben: Alarme, Kommunikation, Provider-Eskalation, Notfallmaßnahmen.

Quellen und weiterführende Links

Bis zum nächsten Mal, Joe