DDoS-Schutz: Leitfaden für neun Schichten

Ein DDoS-Angriff versucht nicht, Ihre Daten zu stehlen. Er versucht, Ihren Dienst unerreichbar zu machen — und das gelingt, indem er die Ressource erschöpft, die zuerst ausgeht: Bandbreite, Verbindungstabellen, Rechenleistung oder Datenbankverbindungen.

Deshalb ist die ehrliche Antwort auf die Frage, wie Sie sich gegen einen DDoS-Angriff schützen, weder ein einzelnes Produkt noch eine einzelne Firewall-Regel. Verschiedene Angriffe erschöpfen verschiedene Ressourcen, und jede Schutzschicht deckt einen anderen Ausfall ab. Dieser Beitrag geht die Schichten in der Reihenfolge durch, in der sie Angriffe tatsächlich stoppen, und liefert danach einen Notfallplan für den Moment, in dem der Angriff bereits läuft.

Was ein DDoS-Angriff tatsächlich erschöpft

Angriffsfamilie	Beispiele	Was erschöpft wird	Wo gestoppt werden muss
Volumetrisch	UDP-Floods, DNS- und NTP-Amplification, Carpet Bombing	Die Netzwerkanbindung	Upstream, beim Hoster oder in einem Scrubbing-Netz
Protokoll- und Zustandserschöpfung	SYN-Floods, ACK-Floods, Verbindungsfloods	Verbindungstabellen auf Servern, Firewalls, Load Balancern	Ratenbegrenzung am Edge, Kernel-Tuning, SYN-Cookies
Anwendungsebene (L7)	HTTP-Floods, Cache-Busting, Slowloris, API-Missbrauch	Rechenleistung, Worker, Datenbankverbindungen	CDN und WAF, Caching, Ratenbegrenzung in der Anwendung

Die praktische Konsequenz: Ist der Angriff größer als Ihre Anbindung, hilft keine Konfiguration auf dem Server. Die Pakete haben gewonnen, bevor eine lokale Firewall-Regel sie überhaupt sieht. Volumetrischer Schutz muss upstream liegen. Alles andere können Sie selbst härten.

Die neun Schichten des DDoS-Schutzes

1. Eine Filterstufe vor die Origin setzen

Jede ernsthafte Verteidigung beginnt mit Kapazität, die Ihnen nicht gehört. Cloud-Scrubbing und Anycast-Netze verteilen Angriffsverkehr auf viele Standorte, filtern ihn und leiten nur saubere Anfragen an Ihren Server weiter.

Konkret bedeutet das:

Öffentlichen Verkehr hinter ein CDN oder einen Reverse Proxy mit integriertem DDoS-Schutz legen, etwa Cloudflare, AWS CloudFront mit Shield, Azure Front Door, Gcore, Bunny oder Fastly.
Beim Hoster erfragen, welche Mitigationskapazität vor Ihrer IP liegt und ob sie dauerhaft aktiv ist oder erst bei Erkennung einsetzt. On-Demand-Schutz lässt genau in der ersten Minute des Angriffs eine Lücke.
Anycast bevorzugen: Es verdünnt volumetrische Fluten geografisch, statt ein einziges Rechenzentrum alles aufnehmen zu lassen.

Der häufige Fehler ist die Annahme, ein CDN allein genüge. Es ist Schicht eins von neun.

2. Die Origin-IP abschotten

Diesen Schritt lassen die meisten Teams aus, und er hebt Schicht eins stillschweigend wieder auf. Erfährt ein Angreifer die echte Server-IP, umgeht er das CDN und greift direkt an — ein Vorgehen, das als Direct-to-Origin bekannt ist.

Wo Origin-IPs durchsickern:

DNS-Archivdienste — alte A-Records aus der Zeit vor dem Proxy.
Zertifikats-Transparenzprotokolle — TLS-Zertifikate, die auf den Origin-Hostnamen ausgestellt wurden.
Subdomains — mail., vpn., ftp. oder dev. zeigen oft auf denselben Server.
E-Mail-Header — ausgehende Mails können die Origin-IP in Received:-Zeilen mitführen.
Altlasten im DNS — MX-, SPF- und TXT-Einträge, die auf Infrastruktur außerhalb des CDN verweisen.

Was zu tun ist: Origin-IP nach dem Aktivieren des CDN rotieren, den Origin so absichern, dass nur die veröffentlichten IP-Bereiche des CDN die Ports 80 und 443 erreichen, und die eigene Exposition quartalsweise erneut prüfen.

3. Eine WAF für Ebene 7 einsetzen

Eine Netzwerkfirewall sieht eine gültige TCP-Verbindung und lässt sie durch. Eine Web Application Firewall liest die HTTP-Anfrage — und dort sitzen die Angriffe der Anwendungsebene: fehlerhafte Anfragen, Ausnutzungsversuche, Bot-Fluten auf Anmeldung und Suche.

Aktivieren Sie zuerst die verwalteten Regelsätze, also die OWASP-Kernregeln plus die Bedrohungsdaten des Anbieters, und ergänzen Sie dann gezielte eigene Regeln: übergroße Anfragekörper auf Upload-Endpunkten blockieren, Zugriffe auf Administrationspfade mit einer Challenge prüfen, Ratenbegrenzung pro Endpunkt statt pro Website.

4. Ratenbegrenzung auf jeder Stufe

Ratenbegrenzung ist die wirksamste günstige Kontrolle — und die am häufigsten falsch konfigurierte. Regeln, die nur auf dem Webserver greifen, richten nichts gegen Verkehr aus, der vorher das Netz sättigt; Regeln, die nur auf die IP-Adresse schlüsseln, bringen wenig gegen ein Botnetz mit tausenden Quelladressen.

Deshalb gestaffelt:

Edge: Anfragen pro IP, pro ASN, bei Bedarf pro Land.
Anwendung: pro Sitzung, pro API-Schlüssel, pro angemeldetem Nutzer.
Endpunktspezifisch: enge Grenzen für Anmeldung, Passwort-Reset, Suche und Bezahlvorgang — die teuren Routen, die Angreifer gezielt wählen.

Nutzen Sie Token-Bucket- oder Sliding-Window-Verfahren statt harter Sekundengrenzen und antworten Sie mit 429 und Retry-After, damit legitime Clients zurückhaltender werden, statt aggressiv zu wiederholen.

5. Den TCP-Stack härten

SYN-Floods füllen die Verbindungstabelle, bevor eine einzige HTTP-Anfrage ankommt. Die Gegenmittel sind alt, unspektakulär und wirksam:

SYN-Cookies aktivieren.
Listen-Backlog anheben und somaxconn sowie tcp_max_syn_backlog an die tatsächliche Parallelität anpassen.
tcp_fin_timeout verkürzen und Keepalive-Zeiten am Load Balancer reduzieren.
Gleichzeitige Verbindungen pro Quelle am Edge begrenzen.

Messen Sie die Änderung unter Last. Wer Werte aus einem Fachbeitrag übernimmt, ohne die eigene Baseline zu kennen, macht es meist schlechter.

6. Caching die Arbeit machen lassen

Eine aus dem Cache bediente Anfrage erreicht den Origin nie und verbraucht weder Worker noch Datenbankverbindung. Was statisch sein kann, sollte statisch sein: Bilder, CSS, JavaScript und HTML für anonyme Besucher.

Zwei Details zählen im Angriff:

Cache-Busting ist eine Angriffstechnik. Zufällige Query-Strings zwingen jede Anfrage bis zum Origin durch. Konfigurieren Sie das CDN so, dass irrelevante Parameter auf cachefähigen Routen ignoriert werden.
Die Cache-Trefferquote ist eine Sicherheitskennzahl. Fällt sie im Vorfall von 85 auf 20 Prozent, zahlen Sie Origin-Kosten für Angriffsverkehr.

7. Baseline messen und auf Abweichungen alarmieren

Sie können nicht verteidigen, was Sie nicht sehen. Halten Sie vor dem Angriff fest, wie normal aussieht: Anfragen pro Sekunde, Bytes in beide Richtungen, 4xx- und 5xx-Rate, p95-Latenz, Verbindungszahlen und die meistaufgerufenen URLs.

Alarmieren Sie dann auf Abweichungen statt auf absolute Werte: Ein fünffacher Anstieg der Anfragen pro Sekunde bei stabiler Fehlerrate ist oft ein Marketing-Erfolg, während eine flache Rate mit steigender Latenz und steigenden Verbindungszahlen auf eine Zustandserschöpfung deutet. NetFlow- oder IPFIX-Daten zusammen mit Anwendungsprotokollen liefern beide Sichten. Wer systematisch nach verborgenem Angreiferverhalten sucht, statt nur Alarme abzuarbeiten, erkennt solche Muster früher — der Beitrag zu Threat Hunting in der Cybersicherheit beschreibt den Ablauf.

8. Den Notfallplan schreiben, bevor er gebraucht wird

Im Angriff ist der schlechteste Moment, um zu klären, wer den Hoster anruft, wer mit Kunden spricht und wer den Under-Attack-Modus aktivieren darf. Schreiben Sie einen einseitigen Notfallplan:

Wer den Vorfall erklärt und wo er angekündigt wird.
Wer Hoster oder CDN-Support kontaktiert, einschließlich Vertragsnummern.
Welche Kontrollen in welcher Reihenfolge aktiviert werden und wer das darf.
Wer mit Kunden kommuniziert und wie die vorläufige Stellungnahme lautet.
Wann rechtliche Schritte oder Strafverfolgung geprüft werden, besonders bei Erpressung.

Üben Sie das einmal pro Quartal in einer Tabletop-Übung. Ein Notfallplan, den niemand gelesen hat, ist Dekoration.

9. Kapazität vertraglich einkaufen statt hoffen

Wo Ausfallzeit direkt Umsatz kostet, sollte Mitigationskapazität vertraglich geregelt sein: ein Scrubbing-SLA, eine definierte Schwelle, benannte Eskalationskontakte und ein Support-Level, das während eines Angriffs tatsächlich antwortet.

Günstige oder kostenlose Tarife sind hervorragend für kleine Seiten und unpassend für Unternehmen, die pro Ausfallstunde vierstellig verlieren. Passen Sie den Tarif an die realen Kosten eines Ausfalls an, nicht an die Preisliste.

Im Ernstfall: Sofortmaßnahmen

Arbeiten Sie in dieser Reihenfolge — vom geringsten zum größten Eingriff:

Bestätigen, dass es ein Angriff ist. Prüfen Sie Quellen, Anforderungsmuster, meistaufgerufene URLs und Geografie. Vergleichen Sie mit einer legitimen Kampagne, bevor Sie blockieren.
Die Ebene bestimmen. Gesättigte Bandbreite deutet upstream, erschöpfte Verbindungstabellen auf Ebene 3 und 4, Rechenlast und Latenz auf einzelnen Endpunkten auf Ebene 7.
Sofort ein Ticket beim Anbieter öffnen. Upstream-Mitigation braucht Zeit; starten Sie sie, bevor die Diagnose fertig ist.
Edge-Kontrollen aktivieren. Under-Attack-Modus, verwaltete WAF-Regeln, verschärfte Ratenbegrenzung und eine JavaScript-Challenge auf den am stärksten missbrauchten Routen.
Den Origin schützen. Sicherstellen, dass er nur Verkehr vom CDN annimmt, und direkte Anfragen an die IP blockieren.
Kommunizieren. Zuerst die Statusseite, dann die Support-Kanäle. Schweigen verursacht mehr Schaden als der Angriff.
Beweise sichern. Protokolle, Paketmitschnitte und Zeitstempel aufbewahren — sie zählen für den Anbieter, für die Versicherung und für ein mögliches Verfahren.

Wird der Angriff mit einer Geldforderung verbunden, verhandeln Sie nicht zu den Bedingungen des Angreifers. Erpresserische Verfügbarkeitsangriffe erfüllen regelmäßig Straftatbestände wie Computersabotage nach §303b StGB; hinzu kommen Datenveränderung nach §303a StGB und, bei vorangehenden Ausspähversuchen, §202a und §202b StGB. Wie Erpressungsfälle im Umfeld von Ransomware-as-a-Service für kleine und mittlere Unternehmen ablaufen, beschreibt ein eigener Beitrag.

Rechtlicher Rahmen und Meldepflicht

Verfügbarkeitsangriffe betreffen nicht nur die Technik, sondern auch Pflichten und Fristen. Die DSGVO verlangt bei Vorfällen mit personenbezogenen Daten eine Meldung an die Aufsichtsbehörde in der Regel innerhalb von 72 Stunden; für Betreiber kritischer Anlagen und regulierter Sektoren bestehen zusätzliche Meldewege zum BSI. Klären Sie deshalb vor dem Ernstfall, wer meldet, welche Frist gilt und welche Protokolle dafür vorliegen müssen — während des Angriffs fehlt die Zeit für diese Abstimmung.

Zur Beweislage gehört mehr als die Firewall-Konfiguration: Zeitstempel, Zugriffsprotokolle und die vollständige Erpresserkommunikation. Ohne diese Unterlagen bleiben sowohl eine Anzeige als auch die Abstimmung mit der Versicherung schwach. Setzen Sie Systeme erst neu auf, wenn die Spuren gesichert sind.

Checkliste für zehn Minuten Bereitschaft

Öffentlicher Verkehr läuft über ein CDN oder einen Scrubbing-Dienst mit DDoS-Schutz.
Die Origin-IP ist rotiert, auf die Bereiche des Anbieters begrenzt und über DNS-Historie oder Zertifikatsprotokolle nicht auffindbar.
Die WAF ist mit verwalteten Regeln und eigenen Regeln für Admin- und Anmeldepfade aktiv.
Ratenbegrenzungen existieren am Edge, in der Anwendung und auf teuren Endpunkten.
SYN-Cookies sind aktiv, Verbindungsgrenzen gegen eine gemessene Baseline eingestellt.
Statische Dateien und anonymes HTML werden mit hoher Trefferquote aus dem Cache geliefert.
Dashboards und Alarme decken Anfragen, Bandbreite, Fehlerrate, Latenz und Verbindungen ab.
Ein einseitiger Notfallplan existiert, ist aktuell und hat benannte Verantwortliche.
Der Vertrag mit Hoster oder CDN nennt Mitigationskapazität und Support-Reaktionszeiten.
Jemand hat diese Liste im letzten Quartal durchgearbeitet.

Jedes offene Kästchen ist eine Lücke, die eine externe Prüfung wert ist. Im Rahmen eines Penetrationstests wird genau der Weg getestet, den ein Angriff nehmen würde — von der Edge-Konfiguration bis zum Verhalten der Anwendung — und Sie erfahren, was zuerst versagt.

Was DDoS-Schutz tatsächlich kostet

Option	Typische Kosten	Geeignet für
CDN-Tarif kostenlos oder Pro (Cloudflare, Bunny)	0 bis 25 US-Dollar pro Monat	Blogs, kleine Unternehmensseiten, SaaS mit geringem Risiko
Schutz des Cloud-Anbieters (AWS Shield Standard)	in der Infrastruktur enthalten	Workloads, die ohnehin dort laufen
Managed WAF und DDoS (Gcore, Imperva, AWS Shield Advanced)	etwa 55 bis über 3.000 US-Dollar pro Monat	umsatzkritische Anwendungen, Compliance-Anforderungen
Dediziertes Scrubbing (Akamai, Radware, Link11, Myra)	Enterprise-Verträge, häufig ab 5.000 US-Dollar pro Monat	besonders exponierte Ziele, Gaming, Finanzsektor

Die entscheidende Zahl ist nicht der Abopreis, sondern die Kosten einer Ausfallstunde multipliziert mit der erwarteten Häufigkeit von Angriffen. Für die meisten kleinen Unternehmen gilt: eine sauber konfigurierte kostenlose oder günstige Lösung plus ein geübter Notfallplan schlägt ein teures Gerät, das niemand bedienen kann.

Häufige Fehler, die Seiten unten halten

Die IP-Bereiche des eigenen CDN blockieren. Sieht im Angriff effizient aus und nimmt die eigene Seite vollständig vom Netz.
Nur auf IP-Adressen begrenzen. Botnetze wechseln Quelladressen; schlüsseln Sie zusätzlich auf Verhalten.
Die Startseite schützen, aber nicht die API. Angreifer finden den teuren Endpunkt.
Ebene 3 und 4 ignorieren. Ein SYN-Flood taucht in den HTTP-Protokollen nie auf.
Kein Schutz der Origin. Das CDN schluckt die Flut, während der Angreifer die echte IP bearbeitet.
Ungetesteter Notfallplan. Unter Druck greifen Menschen zuerst zur falschen Maßnahme.

FAQ

Lässt sich ein DDoS-Angriff vollständig verhindern?

Nein. Jeder kann Verkehr an einen öffentlich erreichbaren Dienst senden. Das realistische Ziel ist, ihn aufzunehmen und zu filtern, während legitime Nutzer online bleiben — genau das leistet ein schichtweiser Schutz.

Reicht ein CDN, um einen DDoS-Angriff zu stoppen?

Ein CDN fängt volumetrische Fluten und viel Missbrauch auf Ebene 7 ab, behebt aber weder eine exponierte Origin noch den Missbrauch teurer Endpunkte oder eine Zustandserschöpfung. Es ist eine Schicht von mehreren.

Wie unterscheide ich einen DDoS-Angriff von einer Verkehrsspitze?

Sehen Sie auf die Zusammensetzung, nicht auf die Menge: Eine Spitze aus einer Region oder von einer einzigen URL, mit ungewöhnlichen User-Agents, steigender Latenz und flacher Konversionsrate ist ein Angriff. Eine Spitze über Ihre normalen Quellen ist meist eine Kampagne, die funktioniert.

Was sollte ein kleines Unternehmen zuerst tun?

Verkehr hinter ein CDN mit Mitigation legen, die Origin-IP abschotten, verwaltete WAF-Regeln aktivieren und den einseitigen Notfallplan schreiben. Diese Reihenfolge deckt die häufigsten Angriffe für das wenigste Geld ab.

Brauche ich einen spezialisierten DDoS-Anbieter?

Nur wenn Ausfallzeit mehr kostet als der Vertrag. Beginnen Sie mit dem CDN-Tarif, messen Sie die eigene Exposition und wechseln Sie, sobald die Rechnung es rechtfertigt.

Wie es weitergeht

Schichtweiser Schutz ist überwiegend Konfigurationshygiene: eine Upstream-Schicht mit Kapazität, ein Origin, den niemand findet, Anforderungskontrollen, die zur eigenen Anwendung passen, und ein Notfallplan, den das Team wirklich geübt hat. Wenn Sie bereits betroffen waren, lohnt zusätzlich der Blick auf die zehn Anzeichen, dass Ihr Unternehmen kompromittiert ist: Verfügbarkeitsangriffe sind oft nur die sichtbare Seite eines längeren Vorgehens.