DDoS-Angriffe auf Ihre Website verhindern

Was ein DDoS-Angriff ist

Ein Distributed-Denial-of-Service-Angriff (DDoS) versucht, eine Website oder einen Dienst unerreichbar zu machen, indem er ihn gleichzeitig aus vielen Quellen mit Traffic oder Anfragen überflutet. Anders als bei einem Einbruch geht es meist nicht um Datendiebstahl, sondern darum, legitime Nutzer von Ihnen fernzuhalten. Die Quellen sind oft kompromittierte Geräte oder gemietete Infrastruktur – deshalb hilft es selten, einfach eine einzelne IP-Adresse zu sperren.

Dieser Leitfaden behandelt die Abwehr: die wichtigsten Angriffskategorien verstehen, um sinnvolle Schutzmaßnahmen zu wählen, Ihren Stack zu konfigurieren und im Ernstfall besonnen zu reagieren. Keine Website lässt sich vollständig immun machen, doch gute Vorbereitung senkt die Wahrscheinlichkeit erheblich, dass ein Angriff zu einem langen Ausfall führt.

Die wichtigsten Kategorien von DDoS-Angriffen

Angriffe werden üblicherweise danach eingeteilt, welche Ressource sie erschöpfen wollen. Die Kategorie zeigt Ihnen, wo die Abwehr ansetzen muss.

Der Kernpunkt: Volumetrische Angriffe übersteigen meist bei Weitem, was ein einzelner Server oder ein kleiner Hosting-Anschluss verkraftet. Filtern auf dem Server selbst kommt dann zu spät. Angriffe auf Anwendungsebene können dagegen wenig Bandbreite, aber viel CPU verbrauchen – hier spielt die Optimierung Ihrer eigenen Anwendung eine große Rolle.

Eine Schutzschicht vor die Website setzen

Für die meisten Websites ist der wirksamste Einzelschritt, den Traffic über einen Anbieter mit großer, verteilter Kapazität zu leiten: ein CDN mit DDoS-Schutz, einen spezialisierten Mitigation-Dienst oder einen Cloud-Load-Balancer mit integrierter Filterung. Diese Netzwerke verteilen volumetrische Fluten auf viele Standorte und filtern schädlichen Traffic, bevor er Sie erreicht.

Stellen Sie beim Vergleich praktische Fragen, statt sich auf Werbeversprechen zu verlassen:

• Welche Ebenen sind abgedeckt (Netzwerk, Protokoll, Anwendung), und sind einige davon kostenpflichtige Zusatzleistungen?
• Ist die Abwehr dauerhaft aktiv oder greift sie erst nach einer Erkennung?
• Gibt es Bandbreiten- oder Anfragelimits, und wird Angriffstraffic berechnet?
• Wie sieht der Support-Prozess während eines laufenden Vorfalls aus?
• Können Sie eigene Regeln, Rate Limits und Challenges für bestimmte Pfade festlegen?

Preise und Limits ändern sich häufig und unterscheiden sich je nach Tarif. Prüfen Sie daher die aktuelle Dokumentation Ihres Anbieters, statt einen bestimmten Schutzumfang vorauszusetzen.

Den Ursprungsserver verbergen und absichern

Eine Schutzschicht hilft nur, wenn Angreifer sie nicht umgehen können. Ist die IP-Adresse Ihres Ursprungsservers bekannt, können sie Traffic direkt dorthin schicken und das CDN komplett umgehen.

1. Die Origin-IP nicht preisgeben. Alte DNS-Einträge, ungeschützte Subdomains wie Mail- oder FTP-Hostnamen, E-Mail-Header und historische DNS-Daten können sie verraten. Erwägen Sie nach dem Aktivieren des Schutzes einen Wechsel auf eine neue IP.
2. Web-Traffic nur vom Anbieter zulassen. Konfigurieren Sie die Firewall so, dass die Ports 80 und 443 ausschließlich aus den veröffentlichten IP-Bereichen Ihres CDN erreichbar sind, oder nutzen Sie einen authentifizierten Tunnel beziehungsweise ein Origin-Zertifikat, sofern Ihr Anbieter das unterstützt.
3. Administrativen Zugang einschränken. SSH, Control Panels und Datenbank-Ports sollten nicht für das gesamte Internet offen sein; beschränken Sie sie auf VPNs oder bekannte Adressen.

Die TLDix-Hosting-Abfrage zeigt schnell, was die Öffentlichkeit darüber erfahren kann, wohin ein Hostname auflöst – hilfreich, wenn Sie Subdomains auf Lecks prüfen.

Die Anwendungsebene härten

Fluten auf Anwendungsebene imitieren echte Besucher. Die Abwehr konzentriert sich daher darauf, jede Anfrage günstig zu machen und missbräuchliche Muster zu begrenzen.

Konsequent cachen

Seiten, die aus dem CDN-Cache kommen, erreichen Ihren Ursprungsserver nie. Cachen Sie statische Dateien lange und erwägen Sie kurzes Caching auch für dynamische, aber nicht personalisierte Seiten. Jede zwischengespeicherte Antwort muss Ihr Server nicht berechnen.

Sinnvolles Rate Limiting

Begrenzen Sie die Anfragen pro Client an teuren Endpunkten wie Login, Suche, Checkout und APIs. Ein Beispiel für Nginx:

http {
    limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
    limit_conn_zone $binary_remote_addr zone=connperip:10m;

    server {
        location /search {
            limit_req zone=perip burst=20 nodelay;
            limit_conn connperip 20;
        }

        client_body_timeout 10s;
        client_header_timeout 10s;
    }
}

Die Zahlen sind Platzhalter. Leiten Sie echte Limits aus Ihren eigenen Traffic-Logs ab und bedenken Sie, dass sich hinter Firmen- oder Mobilfunknetzen viele Nutzer eine IP teilen können. Kommt der Traffic über ein CDN, konfigurieren Sie den Header für die echte Client-IP korrekt, damit Sie nicht das CDN selbst drosseln.

Teure Arbeit reduzieren

• Optimieren Sie langsame Datenbankabfragen und legen Sie Indizes für häufige Abfragen an.
• Verlagern Sie aufwendige Aufgaben wie Berichtserstellung oder Bildverarbeitung in Hintergrund-Warteschlangen.
• Setzen Sie Challenges oder CAPTCHAs gezielt bei sensiblen Formularen ein statt überall.
• Legen Sie Timeouts fest, damit langsame Verbindungen Ressourcen nicht unbegrenzt blockieren.

Kapazität und kontrollierten Leistungsabbau planen

Widerstandsfähigkeit bedeutet nicht nur Filtern. Überlegen Sie, was Ihre Website unter Last tun soll. Können Startseite und wichtige Landingpages als statische Dateien aus dem CDN ausgeliefert werden, wenn die Anwendung ausfällt? Lassen sich nicht wesentliche Funktionen wie Empfehlungen, Live-Suche oder schwere Widgets per Feature-Flag abschalten, um Ressourcen zu sparen? Autoscaling in Cloud-Umgebungen kann moderate Spitzen auf Anwendungsebene abfangen, setzen Sie aber Ausgabenlimits und Warnungen, denn das Hochskalieren für Angriffstraffic kann schnell teuer werden.

Auch die Trennung von Komponenten hilft. Liegen API, Adminbereich und öffentliche Website auf unterschiedlichen Hostnamen oder Diensten, reißt eine Flut gegen einen Teil nicht automatisch die anderen mit, und Sie können strengere Regeln dort anwenden, wo sie am wichtigsten sind.

DNS und die Domain selbst nicht vergessen

Fällt Ihr autoritatives DNS aus, ist Ihre Website unerreichbar, selbst wenn die Webserver einwandfrei laufen. Nutzen Sie einen DNS-Anbieter mit Anycast-Infrastruktur und Redundanz; Hintergründe finden Sie unter So funktioniert Anycast-DNS. Manche Organisationen setzen für zusätzliche Ausfallsicherheit zwei unabhängige DNS-Anbieter ein, was synchron gehaltene Zonen erfordert.

Schützen Sie auch die Registrierung selbst. Während eines Vorfalls müssen Sie womöglich schnell die Nameserver ändern, stellen Sie also sicher, dass der Registrar-Zugang abgesichert ist und die Domain nicht kurz vor dem Ablauf steht. Verfolgen Sie Verlängerungstermine im TLDix-Domain-Monitoring, damit eine abgelaufene Registrierung einen Angriff nie noch verschlimmert.

Monitoring und Frühwarnung

Je früher Sie einen Angriff bemerken, desto schneller können Sie reagieren. Nützliche Signale sind:

• Uptime-Prüfungen von mehreren externen Standorten.
• Plötzliche Spitzen bei Anfragen pro Sekunde, Bandbreite oder Fehlerraten (besonders 5xx-Antworten).
• Ungewöhnliche Konzentration des Traffics auf eine URL, einen User-Agent oder eine Region.
• Steigende CPU-, Speicher-, Verbindungs- oder Datenbanklast ohne passenden geschäftlichen Grund.

Halten Sie das Monitoring unabhängig von der überwachten Infrastruktur; ein Alarmdienst auf demselben Server verstummt genau dann, wenn Sie ihn brauchen.

Legen Sie eine Ausgangsbasis für normalen Traffic fest, damit Auffälligkeiten sofort erkennbar sind. Warnungen sollten eine Person erreichen, die handeln kann, nicht nur ein unbeachtetes Postfach.

Checkliste für den Ernstfall

Schreiben Sie Ihren Plan, bevor Sie ihn brauchen. Eine einfache Fassung:

1. Bestätigen Sie, dass es sich um einen Angriff handelt und nicht um einen legitimen Traffic-Anstieg, ein fehlerhaftes Deployment oder eine Störung beim Vorlieferanten.
2. Kontaktieren Sie Ihren Hosting- und Schutzanbieter über den vorab vorbereiteten Eskalationsweg.
3. Aktivieren Sie strengere Modi: höhere Sicherheitsstufen, Challenges auf angegriffenen Pfaden, vorübergehende geografische oder Rate-Regeln, wo gerechtfertigt.
4. Liefern Sie eine zwischengespeicherte oder statische Version wichtiger Seiten aus, wenn die Anwendung überlastet ist.
5. Informieren Sie Nutzer über eine Statusseite oder einen Social-Media-Kanal, der getrennt von der Hauptwebsite gehostet wird.
6. Werten Sie danach Logs aus, passen Sie Regeln an und aktualisieren Sie den Plan.

Die Menschen vorbereiten, nicht nur die Systeme

Im Ernstfall geht Zeit mit der Suche nach Logins und Telefonnummern verloren. Pflegen Sie eine aktuelle Kontaktliste mit Support-Kanälen der Anbieter, Kundennummern und den Personen, die DNS- oder Schutzeinstellungen ändern dürfen. Bewahren Sie sie an einem Ort auf, der auch erreichbar ist, wenn Ihre Hauptwebsite und E-Mail betroffen sind. Eine kurze Planspielübung ein- bis zweimal im Jahr, bei der Sie die obige Checkliste durchgehen, deckt Lücken wie abgelaufene Zugangsdaten oder unklare Zuständigkeiten auf, lange bevor ein echter Angriff es tut.

Geht ein Angriff mit einer Erpressungsforderung einher, beziehen Sie Ihren Anbieter ein und melden Sie den Vorfall den zuständigen Behörden. Dies ist keine Rechtsberatung; prüfen Sie die örtlichen Vorgaben.

Nach dem Angriff

Wenn der Traffic sich normalisiert hat, lockern Sie verschärfte Regeln schrittweise statt auf einmal, denn manche Angriffe kehren in Wellen zurück. Prüfen Sie, ob während des Vorfalls Zugangsdaten geteilt oder Firewall-Ausnahmen eingerichtet wurden, und machen Sie diese rückgängig. Halten Sie in einer kurzen Nachbetrachtung fest, was funktioniert hat, wo es gehakt hat und welche Änderungen an Plan, Regeln oder Architektur Sie daraus ableiten.