DDoS-Schutz für Unternehmen: Ebenen und Playbook

Ein Distributed-Denial-of-Service-Angriff muss nirgendwo eindringen, um einem Unternehmen zu schaden. Es genügt, eine einzige Ressource zu erschöpfen, von der Ihre Anwendung abhängt: die Bandbreite eines Uplinks, die State-Tabelle einer Firewall, den Verbindungspool eines Load Balancers oder die CPU einer Datenbank.

Guter DDoS-Schutz hängt daher weniger von einem einzelnen Produkt ab als davon, zu wissen, auf welche Ressource jede Angriffsart zielt, und sicherzustellen, dass davor eine Kontrolle sitzt, die mehr Kapazität hat als der Angreifer.

Drei Angriffsklassen, drei verschiedene Engpässe

Angriffe werden üblicherweise nach der Ebene gruppiert, die sie belasten. Die Einteilung ist wichtig, weil jede Klasse anders gemessen wird, eine andere Komponente auslastet und an einer anderen Stelle gestoppt wird.

• Volumetrisch. Ziel ist es, die Leitung zu füllen. Der Traffic wird in Bits pro Sekunde gemessen, und große Vorfälle erreichen Hunderte Gigabit oder Terabit. Reflection und Amplification sind verbreitet: Server Dritter im Internet werden dazu gebracht, große Antworten an das Opfer zu senden. Hier hilft kein Server-Tuning: Ist Ihr Uplink 10 Gbps groß und kommen 40 Gbps an, ist die Leitung voll, bevor auch nur ein Paket Ihre Firewall erreicht.
• Protokoll. Ziel ist es, die Zustands- oder Paketverarbeitungskapazität von Netzwerkgeräten zu erschöpfen. Diese Angriffe werden in Paketen pro Sekunde statt in Bandbreite gemessen. SYN-Floods und Floods mit fragmentierten Paketen sind typische Beispiele. Zur Orientierung: Eine 1-Gbps-Leitung mit Ethernet-Frames minimaler Größe liefert etwa 1,49 Millionen Pakete pro Sekunde, eine 10-Gbps-Leitung etwa 14,9 Millionen. Das reicht, um Stateful Firewalls und Load Balancer zu überlasten, die für normalen Traffic dimensioniert wurden.
• Anwendungsebene. Ziel ist es, die Anwendung zu aufwendiger Arbeit zu zwingen. Der Traffic wird in Anfragen pro Sekunde gemessen und sieht oft wie gewöhnliches HTTPS aus. Einige tausend Anfragen pro Sekunde gegen einen Such-Endpunkt, ein Anmeldeformular oder eine nicht gecachte Berichtsseite können die Datenbankverbindungen erschöpfen, während die Gesamtbandbreite moderat bleibt. Diese Angriffe sind am schwersten zu erkennen, weil jede einzelne Anfrage für sich gültig sein kann.

Reale Vorfälle kombinieren oft mehrere Klassen. Planen Sie für jede Klasse separat und testen Sie dann, was passiert, wenn zwei gleichzeitig auftreten.

Wo die Abwehr stattfindet

Es gibt vier Stellen, an denen Angriffs-Traffic gefiltert werden kann. Je weiter vorgelagert eine Kontrolle sitzt, desto mehr Volumen kann sie absorbieren, aber desto weniger weiß sie über Ihre Anwendung.

• Netzwerk-Edge und vorgelagerter Anbieter. Ihr Hosting- oder Transit-Anbieter kann Traffic verwerfen, bevor er Ihren Port erreicht, mithilfe von Access Lists, flowbasierter Erkennung und Remotely Triggered Blackholing. Blackholing schützt den Rest des Netzes, verwirft aber auch legitimen Traffic zur angegriffenen Adresse. Es ist daher ein letztes Mittel, keine Verteidigung.
• Scrubbing. Spezialisierte Abwehrsysteme, entweder inline im Netz des Anbieters oder in entfernten Scrubbing-Centern, die über eine Umleitung des Traffics per BGP oder DNS erreicht werden, untersuchen Traffic in großem Volumen und leiten nur saubere Pakete weiter. Scrubbing ist die wichtigste Antwort auf volumetrische und Protokollangriffe. Fragen Sie, ob es permanent aktiv ist oder erst bei Erkennung aktiviert wird und wie lange die Aktivierung dauert, denn die ersten Minuten eines Angriffs richten oft den größten Schaden an.
• CDN und WAF. Ein Content Delivery Network terminiert Verbindungen an vielen Edge-Standorten, absorbiert Traffic über eine große Fläche und liefert gecachte Inhalte aus, ohne Ihren Origin zu berühren. Eine Web Application Firewall ergänzt Regeln auf HTTP-Ebene, Bot-Erkennung und Challenge-Seiten. Dies ist die wichtigste Ebene gegen Angriffe auf Anwendungsebene, die sich gegen öffentliche Websites und APIs richten.
• Anwendung und Origin. Ihre eigenen Load Balancer, Reverse Proxies und Ihr Code setzen Verbindungslimits, Timeouts, Kontingente pro Nutzer und eine kontrollierte Degradierung durch. Diese Ebene hat den meisten Kontext (wer der Nutzer ist, was der Endpunkt kostet), aber die geringste Kapazität. Sie sollte nie die erste Verteidigungslinie gegen Volumen sein.

Vorgelagerte Kontrollen schützen die Kapazität, CDN und WAF schützen die Angriffsfläche der Anwendung, und der Origin schützt sich selbst vor allem, was durchkommt. Der typische Fehler ist die Annahme, eine Ebene decke die anderen ab, etwa wenn man sich auf eine WAF verlässt, während die IP-Adresse des Origin öffentlich bekannt und direkt erreichbar ist.

Rate Limiting, das unter Last standhält

Rate Limiting ist die nützlichste Kontrolle gegen Angriffe auf Anwendungsebene und zugleich die, bei der am leichtesten Fehler passieren. Die eigentliche Arbeit liegt in der Wahl des richtigen Schlüssels, des richtigen Schwellenwerts und der richtigen Reaktion.

• Von gemessenen Baselines ausgehen. Erfassen Sie mindestens zwei bis vier Wochen lang Anfrageraten pro Endpunkt, pro Client und pro Minute, einschließlich Spitzenereignissen. Setzen Sie Schwellenwerte als Vielfaches des beobachteten 99. Perzentils statt auf eine runde Zahl.
• Den Schlüssel sorgfältig wählen. Eine Begrenzung allein nach IP-Adresse versagt bei Kunden hinter Unternehmens-NAT oder Gateways von Mobilfunkanbietern, wo sich Tausende Nutzer eine Adresse teilen. Kombinieren Sie die IP nach Möglichkeit mit Sitzung, API-Schlüssel oder authentifizierter Nutzer-ID.
• Limits nach Kosten gewichten. Ein statisches Bild und eine Volltextsuche sollten sich kein Budget teilen. Geben Sie teuren Endpunkten (Login, Suche, Export, Checkout) eigene, strengere Limits.
• Auf mehr als einer Ebene durchsetzen. Setzen Sie grobe Limits am CDN oder an der WAF und feinere, identitätsbezogene Limits am API-Gateway oder in der Anwendung. Die Edge stoppt Massentraffic kostengünstig, und der Origin fängt ab, was an der Edge legitim aussieht.
• Verhältnismäßig reagieren. Antworten Sie gut programmierten Clients mit HTTP 429 und einem Retry-After-Header, setzen Sie Challenges bei verdächtigen Browsern ein und verwerfen Sie Traffic nur dann stillschweigend, wenn Sie sicher sind, dass er feindlich ist.
• Gemeinsame Zähler verwenden. Wenn Sie mehrere Anwendungs-Nodes betreiben, halten Sie die Zähler in einem gemeinsamen Speicher wie Redis. Andernfalls setzt jeder Node sein eigenes Limit durch, und die effektive Obergrenze vervielfacht sich mit der Zahl der Nodes.

Testen Sie Limits, bevor Sie sie brauchen. Spielen Sie Traffic-Muster aus der Produktion in einer Staging-Umgebung ab, erhöhen Sie das Volumen schrittweise und bestätigen Sie, dass legitime Abläufe weiter funktionieren, während der Überschuss abgewiesen wird.

Architekturmuster, die die Angriffsfläche verkleinern

Filterung ist nur die halbe Verteidigung. Die andere Hälfte besteht darin, das System so zu gestalten, dass es weniger Angriffsfläche bietet und mehr Spielraum hat, das Ankommende aufzufangen.

• Den Origin verbergen. Stellen Sie öffentliche Dienste hinter ein CDN oder einen Proxy und lassen Sie eingehenden Traffic zum Origin nur aus den veröffentlichten Adressbereichen dieses Anbieters zu. Wechseln Sie Origin-Adressen, wenn sie über alte DNS-Records, Mail-Header oder Certificate-Transparency-Logs bekannt geworden sind.
• Kritische Pfade trennen. Hosten Sie Marketing-Website, Kundenanwendung, API und administrative Oberflächen unter verschiedenen Adressen und, wo praktikabel, auf unterschiedlicher Infrastruktur. Ein Angriff auf die öffentliche Startseite darf nicht die Zahlungs-API lahmlegen.
• Management vom öffentlichen Internet fernhalten. SSH, RDP, Datenbankports und Control Panels sollten nur über ein VPN oder ein privates Netz erreichbar sein, niemals über dieselben Adressen, die Kunden bedienen.
• Konsequent cachen. Jede aus dem Cache ausgelieferte Antwort ist eine Anfrage, die der Origin nie sieht. Prüfen Sie die Cache-Header von Seiten, die auch nur 30 bis 60 Sekunden gecacht werden könnten; unter Angriff nimmt eine kurze TTL den größten Teil der Last vom Origin.
• Auf Degradierung auslegen. Identifizieren Sie Funktionen, die sich unter Druck abschalten lassen, etwa Empfehlungen, Live-Suche oder nicht notwendige Widgets, und legen Sie sie hinter Feature Flags, damit der zentrale Transaktionspfad weiter funktioniert.
• Auf mehrere Standorte verteilen. Der Betrieb in zwei oder mehr Regionen mit DNS- oder Anycast-Steuerung bedeutet, dass ein überlasteter Standort nicht das Ende des Dienstes ist. Außerdem haben Sie so einen Ort, an den Sie Traffic verlagern können, während ein Anbieter die Abwehr aktiviert.
• Reserven planen. Kennen Sie die Kapazität jeder Leitung und jedes Geräts im Pfad. Ein 1-Gbps-Port überträgt bei Volllast rund 10 TB pro Tag. Das klingt viel, ist aber wenig im Vergleich zu Angriffsvolumina, daher muss die vorgelagerte Abwehr auffangen, was Ihr Port nicht bewältigen kann.

DNS ist ein häufiger Single Point of Failure: Nutzen Sie einen Anbieter mit großem Anycast-Netz oder zwei Anbieter und halten Sie die TTLs der Records so kurz, dass Sie bei einem Vorfall schnell Änderungen vornehmen können.

Incident-Playbook

Der größte Schaden bei einem DDoS-Vorfall entsteht durch langsame Entscheidungen, nicht durch fehlende Technologie. Ein schriftliches Playbook mit Namen und Telefonnummern verwandelt eine chaotische Stunde in eine routinierte Viertelstunde.

• 1. Erkennen. Alarmieren Sie anhand von Traffic und Verhalten, nicht nur anhand des Serverzustands: eingehende Bandbreite, Pakete pro Sekunde, Anfragen pro Sekunde je Endpunkt, Fehlerraten und Latenz an der Edge und am Origin. Legen Sie Schwellenwerte im Voraus fest, damit der Engineer in Rufbereitschaft nicht im Moment selbst abwägen muss.
• 2. Einordnen. Bestimmen Sie, ob es sich um einen volumetrischen Angriff, einen Protokollangriff oder einen Angriff auf Anwendungsebene handelt, welche Adressen und Endpunkte betroffen sind und ob die Auswirkung an der Leitung, an den Netzwerkgeräten oder in der Anwendung liegt. Flow-Daten und Edge-Logs beantworten diese Fragen schneller als Serverlogs.
• 3. Die richtige Ebene einbinden. Bei volumetrischen und Protokollangriffen kontaktieren Sie den Hosting-Anbieter oder Scrubbing-Dienst über den vereinbarten Kanal und lassen sich bestätigen, dass die Abwehr aktiv ist. Bei Angriffen auf Anwendungsebene verschärfen Sie WAF-Regeln und Rate Limits, aktivieren Challenges und schalten nicht notwendige Funktionen ab.
• 4. Den Kern schützen. Priorisieren Sie den umsatzrelevanten Pfad und die Kundenauthentifizierung. Falls nötig, schränken Sie den Zugriff vorübergehend nach Region ein oder sperren ganze Client-Kategorien und nehmen dabei für kurze Zeit Kollateralschäden in Kauf.
• 5. Kommunizieren. Aktualisieren Sie die Statusseite frühzeitig, briefen Sie den Kundensupport mit einem kurzen Gesprächsleitfaden und informieren Sie die Geschäftsleitung in einem festen Rhythmus. Vermeiden Sie Spekulationen über die Herkunft des Angriffs.
• 6. Auf Folgeangriffe achten. Angriffe wechseln oft den Vektor, sobald der erste blockiert ist. Halten Sie die verstärkte Überwachung mindestens 24 bis 48 Stunden aufrecht und achten Sie auf andere Aktivitäten wie Anmelde- oder Einbruchsversuche, die sich hinter dem Rauschen verbergen können.
• 7. Nachbereiten. Halten Sie innerhalb einer Woche den zeitlichen Ablauf fest: was wann erkannt wurde, welche Kontrollen funktioniert haben, was zu langsam war und welche Schwellenwerte angepasst werden sollten. Aktualisieren Sie das Playbook und planen Sie die Korrekturen ein.

Üben Sie das Playbook mindestens zweimal im Jahr in einer Tabletop-Übung. Führen Sie niemals unangekündigte Tests gegen die Produktion oder gegen Infrastruktur Dritter durch.

Checkliste zur DDoS-Bereitschaft

Nutzen Sie diese Liste in Ihrem nächsten Infrastruktur-Review.

• Bestandsaufnahme. Alle öffentlichen IP-Adressen, Domains und Endpunkte sind erfasst, jeweils mit dem Geschäftsdienst, den sie unterstützen.
• Abwehr durch den Anbieter. Sie wissen, welchen DDoS-Schutz Ihre Hosting- und Transit-Anbieter enthalten, welche Kapazität er hat, ob er permanent aktiv ist und wie Sie die Aktivierung anfordern.
• Eskalationskontakte. Support- und Abwehrkontakte der Anbieter sind dokumentiert und getestet, auch außerhalb der Geschäftszeiten.
• Origin-Schutz. Origin-Server akzeptieren Web-Traffic nur vom CDN oder Proxy, und alte Origin-Adressen sind stillgelegt.
• Managementzugang. Administrative Ports und Panels sind nicht über öffentliche Adressen erreichbar.
• DNS-Resilienz. DNS wird in einem großen Anycast-Netz oder bei zwei Anbietern gehostet, und die TTLs sind überprüft.
• Rate Limits. Limits existieren pro Endpunkt, beruhen auf gemessenen Baselines, nutzen gemeinsame Zähler und lassen sich über die Konfiguration ändern.
• WAF-Regeln. Ein getestetes Notfall-Regelwerk ist einsatzbereit, einschließlich Challenge-Modus und geografischer Einschränkungen.
• Caching. Cachebare Seiten und Assets werden tatsächlich an der Edge gecacht, und die Trefferquoten werden überwacht.
• Degradierung. Nicht notwendige Funktionen lassen sich über Feature Flags ohne Deployment abschalten.
• Monitoring. Alarme decken Bandbreite, Pakete pro Sekunde, Anfragen pro Sekunde, Fehlerraten und Latenz an Edge und Origin ab.
• Playbook. Es gibt ein schriftliches Playbook, das eine Incident-Leitung benennt und in den letzten sechs Monaten geprobt wurde.
• Kommunikation. Statusseite, Support-Leitfäden und Vorlagen für Updates an die Geschäftsleitung sind vorbereitet.
• Nachbereitung von Vorfällen. Es gibt eine Standardvorlage und eine Frist für deren Fertigstellung.

Wie Vonahost unterstützen kann

Dedizierte Server von Vonahost sind Single-Tenant-Maschinen mit AMD EPYC und einem dedizierten 1-Gbps-Port in einer Netzwerk-Fabric mit 100/200 Gbps. Sie enthalten DDoS-Abwehr von Arbor, sodass die Filterung volumetrischer Angriffe und Protokollangriffe im Netzwerk erfolgt, bevor der Traffic Ihren Port erreicht. Die Managed Cloud von Vonahost enthält ein CDN, Monitoring und Redis, die das oben beschriebene Edge-Caching und gemeinsame Rate-Limit-Zähler abdecken, und läuft auf der eigenen Plattform von Vonahost, auf AWS oder auf Google Cloud.

Jedes Angebot nennt Konfiguration, Standort, Verantwortlichkeiten und Monatspreis in US-Dollar, sodass klar ist, welche Teile dieser Checkliste der Anbieter abdeckt und welche bei Ihrem Team verbleiben. Sie wählen das Land jedes Servers, und Daten werden nicht ohne Ihre Zustimmung verlagert.