Wie unser DDoS Schutz funktioniert - ein technischer Einblick

DDoS-Angriffe sind für jeden Hoster Alltagsgeschäft: von kurzen Testpaketen im einstelligen Gbit/s-Bereich bis zu mehrstündigen volumetrischen Angriffen mit mehreren hundert Gbit/s. Bei IntraceX setzen wir dafür auf eine mehrstufige, selbst entwickelte Scrubbing-Architektur. In diesem Artikel gehen wir etwas tiefer in die Technik dahinter.

Die Architektur im Überblick

Kein einzelner Layer allein reicht aus. Erst das Zusammenspiel aus grober Vorfilterung und gezielter Detailanalyse macht den Schutz sowohl skalierbar als auch präzise.

1. Carrier-Ebene: Volumetrischer Schutz vor der eigenen Infrastruktur

Bevor Traffic überhaupt unsere eigenen Systeme erreicht, läuft er durch die Upstream-Schutzsysteme der jeweiligen Rechenzentren und Carrier an unseren Standorten. Das ist bewusst so gewählt, denn rein volumetrische Angriffe im dreistelligen Gbit/s-Bereich lassen sich am effizientesten so nah wie möglich am Backbone abfangen, statt sie erst über die letzte Meile zu unseren eigenen Systemen zu leiten und dort zu verwerfen.

Diese carrier-seitige Filterung ist grob granular. Sie erkennt klare volumetrische Muster (z. B. massive UDP-Floods) und reagiert automatisiert mit Rate-Limits oder temporären Null-Routen auf Netzebene.

Das reicht allein aber nicht aus, weil diese Systeme naturgemäß nicht zwischen "viel legitimer Traffic" und "gezielter Angriff mit moderatem Volumen" unterscheiden können. Genau hier setzt unsere eigene Ebene an.

2. Eigenes Anycast-Netzwerk statt zentraler Flaschenhals

Wir betreiben unser Scrubbing-Netzwerk unter einem eigenen Autonomen System mit eigenem Anycast-Adressraum. Dieselbe IP wird gleichzeitig von mehreren Standorten in Europa aus announced (aktuell Frankfurt und Stockholm, Vereinigtes Königreich weitere PoPs in Planung). Über BGP wählt das Internet automatisch den topologisch nächsten Einspeisepunkt. Ein Angriff aus Nordeuropa trifft dadurch primär den Stockholm-PoP, ohne die Kapazität in Frankfurt zu belasten.

Von den PoPs aus wird ausschließlich bereits vorgefilterter Traffic über getunnelte Verbindungen zur zentralen Infrastruktur in Frankfurt weitergeleitet. Jeder Standort filtert also eigenständig vor, bevor der bereinigte Rest zentral zusammenläuft. Dadurch bleibt die Tunnel-Kapazität zwischen PoP und Zentrale auch bei einem laufenden Angriff überschaubar, statt selbst zum Flaschenhals zu werden.

Diese Aufteilung hat noch einen weiteren Vorteil: Fällt ein PoP aus oder wird er selbst zum Ziel eines gezielten Angriffs, übernehmen automatisch die verbleibenden Standorte den Traffic für den betroffenen Adressraum, ohne manuelles Eingreifen und ohne Downtime für die dahinterliegenden Kundenserver.

3. Warum BGP der Schlüssel zur Skalierung ist

Ein zentraler Baustein unserer Architektur ist, dass wir selbst als Autonomes System im Internet auftreten und aktiv Routing-Entscheidungen beeinflussen können. Das unterscheidet unseren Ansatz von Lösungen, die nur auf einem einzelnen Uplink oder einer festen IP-Zuordnung basieren.

Konkret bedeutet das: Wird ein Standort überlastet oder fällt aus, lässt sich der Traffic über Anpassungen im Routing gezielt umlenken, zum Beispiel durch Community-basiertes Path-Steering gegenüber unseren Upstream-Providern oder durch kontrolliertes Zurückziehen einer Ankündigung an einem PoP. Das Internet "merkt" innerhalb von Sekunden bis wenigen Minuten, dass eine Route nicht mehr verfügbar ist, und wählt automatisch den nächstbesten Pfad.

Zusätzlich erlaubt uns das eigene AS, unabhängig von einzelnen Upstreams zu bleiben. Jeder PoP hängt an mehreren Transit- bzw. Peering-Partnern. Fällt einer aus oder liefert schlechte Performance in eine bestimmte Region, kann der Traffic über einen anderen Upstream desselben Standorts weiterlaufen, ohne dass Kunden davon etwas merken.

4. Paket- und Protokollvalidierung im Netzwerk-Stack

Die eigentliche Detailfilterung passiert direkt im Netzwerk-Stack unserer Scrubbing-Systeme, noch bevor Pakete tiefer verarbeitet werden. Das minimiert Latenz und Ressourcen-Overhead auch bei sehr hohem Paketdurchsatz. Konkret laufen dort mehrere Prüfstufen:

• Protokoll-Konformität: Pakete mit unplausiblen Header-Kombinationen (z. B. widersprüchliche TCP-Flags, ungültige Fragmentierung) werden verworfen, bevor sie überhaupt in die Verbindungsverfolgung aufgenommen werden.
• SYN-Flood-Schutz via SYN-Proxying: Der Drei-Wege-Handshake wird stellvertretend von unserem System abgeschlossen. Erst wenn eine Verbindung tatsächlich zustande kommt, wird sie an den Zielserver durchgereicht.
• Amplification-Filterung: Bekannte Verstärkungsvektoren (DNS-, NTP-, Memcached-Reflection u. Ä.) werden anhand von Quellport, Antwortgröße und Verhältnis Anfrage/Antwort erkannt und gezielt gedrosselt statt pauschal geblockt.
• Adaptive Rate-Limits pro Quelle: Der Traffic einzelner Quell-IPs wird dynamisch gedrosselt, sobald er von der Baseline abweicht. Das ist granular genug, um einzelne auffällige Quellen zu bremsen, ohne den Rest des Traffics zu beeinträchtigen.

5. Erkennung: Flow-Analyse statt starrer Schwellenwerte

Damit die vorherigen Schutzebenen überhaupt wissen, wann sie aktiv werden müssen, läuft parallel eine kontinuierliche Flow-Analyse. Traffic-Metadaten (Paketraten, Verbindungsraten, Protokollverteilung, Paketgrößenverteilung) werden pro Server fortlaufend mit einer individuellen Baseline verglichen. Weicht ein Wert signifikant ab, wird automatisiert ein Angriffsstatus gesetzt und die passenden Gegenmaßnahmen aktiviert, und zwar innerhalb weniger Sekunden, nicht Minuten. Das ist besonders bei kurzen "Hit-and-Run"-Angriffen relevant, wie sie häufig gegen Gameserver gefahren werden.

Läuft ein Angriff aus, wird das automatisch erkannt und die Gegenmaßnahmen werden ebenso automatisch wieder zurückgefahren, ohne manuelles Eingreifen.

6. Warum Angriffe pro Kunde individuell behandelt werden

Ein Server, der primär einen Gameserver wie CS2, Minecraft oder eine FiveM-Instanz hostet, hat ein völlig anderes Traffic-Profil als ein Webserver oder ein VPN-Gateway. Bei Gameservern etwa dominiert UDP mit vielen kleinen, häufigen Paketen. Das ist ein Muster, das bei einer pauschalen, serverübergreifenden Baseline schnell fälschlich als Angriff eingestuft werden könnte.

Deshalb wird die Baseline für die Flow-Analyse nicht global, sondern pro Kunde bzw. pro IP-Bereich erstellt und laufend nachjustiert. Das reduziert Fehlalarme erheblich und erlaubt es, Schutzmaßnahmen gezielter zu dimensionieren. Ein Rate-Limit, das für einen Webserver sinnvoll ist, würde einen aktiven Gameserver mit vielen gleichzeitigen Spielern unter Umständen selbst lahmlegen.

Monitoring und Nachvollziehbarkeit

Jeder erkannte Angriff, jede aktivierte Gegenmaßnahme und die zugehörigen Traffic-Metriken laufen in ein zentrales Monitoring. Intern nutzen wir dafür Dashboards mit Live-Metriken pro Scrubbing-Knoten. Nach außen bekommen Kunden eine nachvollziehbare Historie, wann welcher Angriff auf ihren Server lief und wie er behandelt wurde.

Warum diese mehrstufige Architektur

Die Kombination aus carrier-seitigem Volumenschutz und eigener, feingranularer Anycast-Scrubbing-Ebene ist bewusst so gewählt. Grobe volumetrische Angriffe werden dort abgefangen, wo genug Bandbreite zur Verfügung steht, nämlich am Carrier-Uplink. Alles, was diese erste Stufe durchlässt, wird anschließend gezielt und zustandsbehaftet auf unserer eigenen Infrastruktur gefiltert, ohne dass legitimer Traffic währenddessen leidet.

Diese Architektur ist nie "fertig". Wir bauen kontinuierlich weitere PoPs auf und verfeinern die Erkennungslogik anhand realer Angriffsdaten aus unserem eigenen Netzwerk.