DDoS-Schutz für Websites: Was wirklich hilft

Wirksamer DDoS-Schutz für eine Website besteht nicht aus einem einzelnen Produkt, sondern aus mehreren Ebenen, die jeweils andere Angriffe abfangen: Netzwerkfilter gegen reine Überflutung, ein Reverse Proxy vor der Website, Regeln gegen Angriffe auf Anwendungsebene und ein Server, der nur noch mit diesem Proxy spricht. Entscheidend ist der Zeitpunkt, denn ein Schutz, der schon steht, greift ab der ersten Anfrage. Richtest du ihn erst während eines Angriffs ein, verlierst du Stunden. Wird deine Website gerade angegriffen, gehst du direkt auf die Seite für akute Angriffe oder liest unseren Ratgeber DDoS-Angriff auf deine Website: Was jetzt zu tun ist.

Warum der Schutz vor den Server gehört

Ein Server, der mit sinnlosen Anfragen überhäuft wird, kann nicht nebenbei auch noch aussortieren, welche davon sinnlos sind. Bis eine Firewall-Regel oder ein Sicherheitsplugin auf dem Server eine Anfrage prüft, ist die Bandbreite schon verbraucht und PHP oft schon gestartet. Guter Schutz filtert deshalb so weit vom Server entfernt wie möglich.

Für die Vorbeugung ist vor allem eine Frage wichtig: Welche Ebene fängt welchen Angriff ab?

Keine Ebene deckt alles ab: Einen Proxy ohne abgesicherten Server kann man umgehen, und ein abgesicherter Server ohne Proxy steht jedem HTTP-Flood allein gegenüber.

Die vier Schutzebenen im Detail

1. Netzwerkebene: volumetrische Angriffe und Protokollangriffe

Volumetrische Angriffe fluten die Leitung zu deinem Server mit mehr Traffic, als sie tragen kann. Auf dem Server selbst kannst du dagegen nichts einstellen, denn die Leitung ist voll, bevor deine Firewall überhaupt ein Paket sieht. Diese Ebene liegt deshalb vorgelagert beim Netzwerk deines Hosters oder bei einem spezialisierten Scrubbing-Dienst. Du solltest wissen, was dein Hoster hier leistet, und die IP deines Servers hinter einem Proxy verbergen. Dann müssen Angreifer das Netzwerk des Proxys fluten statt der Leitung deines Servers.

2. Ein Reverse Proxy vor der ganzen Website

Ein Reverse Proxy für die ganze Website nimmt jede Anfrage an deine Domain entgegen, beantwortet aus dem Cache, was er kann, und reicht den Rest an deinen Server weiter. Für den DDoS-Schutz zählen zwei Effekte:

• Gecachte Seiten kosten fast nichts. Ein Flood auf deine Startseite verpufft, wenn die Startseite vom Edge kommt und deinen Server nie erreicht.
• Gefiltert wird vor dem Server. Regeln, Rate Limits und Captcha-Abfragen laufen am Edge, blockierte Anfragen belasten deinen Server also gar nicht.

Achte darauf, dass der Proxy auch dein HTML ausliefert. Ein reines Asset-CDN für Bilder und Skripte auf einer eigenen Subdomain macht die Seite zwar schneller, doch jeder Seitenaufruf landet weiter direkt bei deinem Server, und jeder Angriff auch. Den Unterschied erklärt der Ratgeber Was ist ein CDN und braucht deine Website eins?.

3. WAF, Rate Limits und Bot-Regeln gegen Layer-7-Angriffe

Angriffe auf Anwendungsebene treffen kleine und mittelgroße Websites am häufigsten, und sie sind am schwersten zu erkennen, weil jede einzelne Anfrage harmlos aussieht. Dabei zielen die Angreifer auf die URLs, die deinem Server die meiste Arbeit machen. Genau dort setzt du deine Regeln an, am besten bevor etwas passiert:

Eine Web Application Firewall (WAF) mit verwalteten Regelsätzen hält zusätzlich typische Angriffsversuche wie SQL-Injection und Cross-Site-Scripting ab, und Bot-Regeln sperren Scraper aus. Länderregeln lohnen sich, wenn du nur wenige Märkte belieferst. Setz dabei lieber auf eine Captcha-Abfrage als auf eine harte Sperre, damit Kunden im Urlaub oder mit VPN trotzdem durchkommen.

4. Den Ursprungsserver abschotten

Ein Proxy schützt dich nur, wenn Angreifer nicht an ihm vorbeikommen. Sobald deine Website dahinter läuft, sicherst du deshalb den Server selbst ab:

• Webtraffic nur noch vom Proxy annehmen. Stell die Firewall auf dem Server oder beim Hoster so ein, dass Port 80 und 443 nur Verbindungen aus den veröffentlichten IP-Bereichen deines Proxy-Anbieters annehmen.
• Alte DNS-Einträge sind kein Geheimnis. Zeigte deine Domain früher direkt auf den Server, ist diese IP über Dienste, die historische DNS-Daten archivieren, leicht zu finden. Frag deinen Hoster, ob du nach dem Umzug eine neue IP bekommen kannst.
• Subdomains prüfen. Einträge wie staging, dev, ftp, cpanel oder mail zeigen oft direkt auf denselben Server und verraten so seine Adresse.
• E-Mail vom Webserver trennen. Zeigt dein MX-Eintrag auf den Webserver oder verschickt der Server Kontaktformular-Mails selbst, steht seine IP im DNS und im Received-Header jeder Mail. Schau außerdem in deinem SPF-Eintrag nach ip4:-Angaben, die den Server verraten.

Mit ein paar Abfragen siehst du schnell, welche Einträge auf deinen Server zeigen:

dig +short example.de A
dig +short mail.example.de A
dig +short example.de MX
dig +short example.de TXT

Taucht in einer Antwort die IP deines Servers auf, führt dieser Eintrag am Proxy vorbei.

Was dein Hoster abdeckt und was nicht

Viele Hoster filtern große volumetrische Angriffe am Rand ihres Netzwerks. Damit schützen sie ihre Infrastruktur und alle Kunden darauf, und das ist nicht dasselbe wie der Schutz deiner Website. Typische Lücken:

• Layer-7-Angriffe kommen durch. Ein paar hundert HTTP-Anfragen pro Sekunde fallen im Netz eines Rechenzentrums kaum auf, reichen aber, um ein typisches CMS oder einen Shop lahmzulegen.
• Null-Routing legt dich lahm. Gefährdet ein Angriff das Netzwerk, leiten manche Hoster den Traffic an die angegriffene IP ins Leere. Deine Website ist dann offline.
• Ressourcenlimits greifen. Bei Shared- oder Managed-Hosting treibt ein Angriff dein Paket schnell an die Grenzen für CPU oder Prozesse, und deine Website wird gedrosselt.

Stell deinem Hoster diese Fragen und heb die Antworten auf:

1. Welche Angriffe filtert ihr, und ist der Schutz vor HTTP-Floods (Layer 7) in meinem Tarif enthalten?
2. Was passiert bei einem großen Angriff mit meiner Website: Drosselung, Null-Routing, Sperre?
3. Kann ich meinen Server so einstellen, dass er Webtraffic nur aus den IP-Bereichen eines Proxys annimmt?
4. Wie erreiche ich euren Support während eines Angriffs?

Worauf du bei einem Schutzdienst achten solltest

Deckt dein Hoster die Netzwerkebene ab, deine Anwendung aber nicht, schließt ein Dienst mit Reverse Proxy die Lücke. Vergleiche die Anbieter anhand klarer Kriterien statt nach Werbeversprechen:

• Die ganze Website. Der Dienst liefert dein HTML aus, nicht nur Bilder und Skripte.
• Dauerhaft aktiv. Ein Schutz, der ständig läuft, muss im Ernstfall nicht erst umgeschaltet werden. Bei Diensten, die du erst bei Bedarf aktivierst, ist genau diese Umschaltzeit das Problem.
• Layer-7-Werkzeuge in deiner Hand. Automatische Erkennung, dazu eigene IP-Sperren, Länderregeln, Captcha-Abfragen und Rate Limits.
• Sauberes Caching und Transparenz. Der Dienst hält sich an deine Cache-Control-Header, cacht niemals Warenkorb oder Kundenkonto und zeigt dir Anfragen und Fehler samt Alarmen.
• Gute Bots kommen durch. Suchmaschinen-Crawler und Rückmeldungen von Zahlungsanbietern funktionieren auch bei strengeren Regeln.
• Vollständiges DNS. Egal ob du die Nameserver umstellst oder nur einen Eintrag änderst: MX-, TXT- und SRV-Einträge müssen weiter funktionieren. Unsere Checkliste Nameserver ändern ohne Ausfall hilft dir dabei.
• Abrechnung bei Angriffen. Frag nach, wie Angriffstraffic auf dein Inklusivvolumen angerechnet wird und ob Mehrverbrauch droht.
• Support. Wie du im Ernstfall schnell einen Menschen erreichst.

Das BSI veröffentlicht außerdem Auswahlkriterien und eine Liste qualifizierter DDoS-Mitigation-Dienstleister. Die Kriterien taugen auch als Maßstab, wenn du keinen dieser Anbieter brauchst.

Checkliste: So bereitest du dich vor

Geh diese Liste einmal durch und schau alle paar Monate wieder drauf:

• Kontakte. Support des Hosters samt Kundennummer, deine Agentur oder dein Entwickler, dein Schutzdienst und die Person, die entscheidet, ob Funktionen abgeschaltet oder Kunden informiert werden.
• Zugänge. Mindestens zwei Personen kommen in Registrar, DNS und Proxy-Dashboard, jeweils mit eigenem Konto und Zwei-Faktor-Anmeldung.
• DNS. Halte einen aktuellen Export deiner Zone bereit und notiere, welche Einträge erreichbar bleiben müssen.
• Monitoring. Eine Erreichbarkeitsprüfung von außen, Alarme bei Traffic-Spitzen und steigenden 5xx-Fehlern und ein Blick auf die CPU deines Servers.
• Notfallplan. Eine Seite mit den strengeren Regeln, die du einschaltest, den aufwendigen Funktionen, auf die du einen Tag verzichten kannst (Live-Suche, Produktempfehlungen, externe API-Aufrufe), und einem kurzen Text für deine Kunden.
• Server-Test. Prüfe, ob dein Server direkte Zugriffe ablehnt. Setz dafür die IP deines Servers ein:

curl -sI --max-time 10 --resolve www.example.de:443:203.0.113.10 https://www.example.de/

Bekommst du eine Antwort statt eines Timeouts oder einer Ablehnung, nimmt dein Server noch Traffic an, der nicht über den Proxy kommt.

So hilft dir fast.site

fast.site arbeitet als Reverse Proxy für deine ganze Website und sitzt vor deinem bestehenden Hosting. Du behältst deinen Hoster und stellst die Nameserver deiner Domain auf fast.site um. Ab dann landet jede Anfrage zuerst im Edge-Netzwerk und wird dort gefiltert, bevor etwas an deinen Server weitergeht. fast.site verwaltet deine DNS-Zone inklusive MX-, TXT- und SRV-Einträgen, Details stehen in der DNS-Dokumentation.

Die Erkennung von Layer-7-DDoS-Angriffen läuft auf allen Domains automatisch, ohne dass du etwas einstellen musst. Zusätzlich sperrst du IPs und CIDR-Bereiche, blockierst Länder oder schickst sie durch eine Captcha-Abfrage, legst eigene Challenge-Regeln an und setzt Rate Limits pro IP. Verwaltete Regelsätze filtern SQL-Injection, XSS und schädliche Bots. Alle Optionen findest du in der Sicherheits-Dokumentation.

Das Caching entlastet deinen Server zusätzlich: Öffentliche Seiten kommen mit fs-cache: HIT vom Edge, Warenkorb, Checkout und eingeloggte Sitzungen laufen als BYPASS zu deinem Server. Die Analytics zeigen dir Anfragen, Fehlerquoten und den Traffic von deinem Server, bei ungewöhnlichen Spitzen gibt es einen Alarm. Den Netzwerkschutz für die Leitung deines Servers übernimmt weiter dein Hoster. Deshalb solltest du den Server so abschotten, dass er nur noch Traffic vom Proxy annimmt.

Richte alles in Ruhe ein und miss das Ergebnis an deiner eigenen Website. Testen kannst du fast.site mit einer kostenlosen 7-Tage-Testphase, ganz ohne Kreditkarte. Die Tarife findest du auf der Preisseite.

Häufige Fragen

Brauchen kleine Websites überhaupt DDoS-Schutz?

Ja, denn die Größe schützt nicht vor Angriffen. Schon ein mäßiger HTTP-Flood legt eine kleine Website lahm, und beim Shared Hosting kann dich auch ein Angriff auf eine andere Website auf demselben Server treffen. Kostet dich ein Ausfall Bestellungen, Anfragen oder Vertrauen, lohnt sich ein Schutz vor der Website.

Ist DDoS-Schutz in meinem Hosting enthalten?

Oft teilweise. Viele Hoster filtern große Angriffe auf Netzwerkebene, um ihre Infrastruktur zu schützen. Angriffe auf Anwendungsebene gegen deine Website kommen aber meist durch, und manche Hoster leiten die angegriffene IP per Null-Routing ins Leere. Frag genau nach, welche Angriffe abgedeckt sind.

Schützt ein CDN vor DDoS-Angriffen?

Nur dann, wenn es deine ganze Website ausliefert und den Traffic filtert, bevor er deinen Server erreicht. Ein Asset-CDN auf einer eigenen Subdomain schützt deine Seiten nicht, denn die HTML-Anfragen gehen weiter direkt an deinen Server.

Macht DDoS-Schutz meine Website langsamer?

Ein Proxy schiebt zwar eine Station zwischen Besucher und Server. Seiten aus einem nahen Edge-Cache kommen aber oft schneller an als vorher. Wie es bei dir aussieht, hängt von Website und Besuchern ab. Mach deshalb einen Vorher-nachher-Vergleich, wie im Ratgeber Ladezeit einer Website richtig messen beschrieben.