So funktioniert ZERO-PROTECT

DDoS-Schutz-Produkte optimieren oft auf Marketing-Zahlen. Globale PoP-Anzahl, aggregierte Scrubbing-Kapazität. Wir haben ZERO-PROTECT auf das optimiert, was während eines Angriffs tatsächlich passiert: eine Request-für-Request-Mitigation-Pipeline, die Infrastruktur-Teams nachvollziehen können.

Dieser Artikel geht die technischen Schichten durch. Wie Angriffe gestoppt werden, und warum jede Schicht existiert.

Die Angriffsfläche

DDoS-Angriffe zerfallen in zwei grundsätzlich verschiedene Probleme.

Volumetrische Angriffe (Layer 3/4) fluten Ihr Netzwerk mit Traffic. UDP-Amplification, SYN-Floods, IP-Fragmentation. Ziel ist, Ihre Bandbreite zu überlasten und Ihre Infrastruktur zu erschöpfen. Solche Angriffe misst man in Gbps und Mpps. Verteidigung verlangt Filterung am Netzwerk-Edge, bevor der Traffic überhaupt Ihre Server erreicht.

Application-Layer-Angriffe (Layer 7) sind subtiler. Sie sehen aus wie legitime HTTP-Requests. Gültige TLS-Handshakes, korrekte Header, realistisches Timing. Ein paar tausend Requests pro Sekunde von rotierenden IPs können einen Application-Server killen, der Millionen legitime Requests problemlos abarbeitet. Der Unterschied: Jeder Angriffs-Request löst teure Backend-Arbeit aus (Datenbankabfragen, API-Calls, Session-Erstellung).

Sie brauchen beide Schichten abgedeckt. Eine WAF hilft nicht, wenn 50 Gbps UDP-Floods Ihren Uplink fluten. Und BGP-Blackholing stoppt keine 200 Bots, die plausibel aussehende POST-Requests auf Ihre Checkout-Seite hämmern.

Layer 3/4: Volumetrische Angriffe am Edge stoppen

Volumetrische Angriffe müssen abgefangen werden, bevor sie Ihren Application-Stack erreichen. Wenn der Traffic erst Ihren Reverse Proxy erreicht, ist es zu spät. Die Leitung ist schon voll.

ZERO-PROTECT nutzt BGP Flowspec, um Mitigation-Regeln am Netzwerk-Edge anzuwenden. Flowspec-Regeln propagieren binnen Sekunden über unsere Edge-Knoten in Frankfurt und Helsinki. Traffic, der zu Angriffsmustern passt, wird auf Netzwerkebene verworfen. Er erreicht Ihren Origin nie.

Wir behaupten nicht, dass unsere Kapazität unbegrenzt sei. Niemandes ist es. Was wir Ihnen sagen: was unser Edge tatsächlich absorbieren kann. Ehrliche Dimensionierung schlägt Marketing-Versprechen. Siehe unsere DRS 6 Selbstbewertung für die Methodik dahinter.

Layer 7: Wo es interessant wird

Hier wird DDoS-Schutz entweder teuer oder nutzlos. Application-Layer-Angriffe sehen aus wie echte Nutzer. IP-basiertes Rate-Limiting funktioniert seit Jahren nicht mehr. Jeder halbwegs ausgestattete Bot-Operator rotiert durch Residential-Proxies.

ZERO-PROTECT stapelt mehrere Erkennungsmethoden auf Layer 7. Jede fängt ein anderes Angriffsmuster.

Proof-of-Work-Challenges

CAPTCHAs nerven legitime Nutzer und werden zunehmend von KI gelöst. Wir gehen einen anderen Weg: Argon2-basierte rechenintensive Rätsel.

Wenn ein Request eine Challenge auslöst, bekommt der Browser ein kleines Puzzle. Echte Browser lösen es in Millisekunden. Der Nutzer merkt nichts. Eine Bot-Farm, die tausende parallele Sessions fährt, braucht echte CPU-Zeit pro Request. In Skala macht das Application-Layer-Floods wirtschaftlich unrentabel. Die Schwierigkeit ist pro Service einstellbar. Bei aktivem Angriff hoch, im Normalbetrieb niedrig.

JA4-TLS-Fingerprinting

JA4 erzeugt einen Fingerabdruck aus TLS-Handshake-Parametern: Cipher Suites, Extensions, unterstützte Versionen, Key-Share-Gruppen. Die Idee ist simpel. Bots, die dasselbe Framework nutzen, erzeugen identische TLS-Fingerprints, selbst beim Rotieren über tausende IPs.

Ein Python-requests-Bot hat einen anderen JA4-Fingerprint als Chrome. Ein Go-HTTP-Client einen anderen als Firefox. Wir rate-limiten nach Fingerprint, nicht nur nach IP. Ein Angreifer, der durch eine Million Residential-Proxies rotiert, aber dasselbe Bot-Framework nutzt, wird auf jedem einzelnen Request erwischt.

Connection-Rate-Limiting + Slow-HTTP-Detection

Bevor etwas auf der HTTP-Schicht ankommt, drosselt ZERO-PROTECT pro Quelle. Das fängt Connection-Floods früh ab, aber auch Slowloris, Slow POST und Slow Read. Diese Angriffe fluten Sie nicht mit Volumen. Sie öffnen Verbindungen und tröpfeln Daten so langsam, dass sie Ressourcen unbegrenzt blockieren. ZERO-PROTECT erkennt und beendet sie, bevor sie Ihre Anwendung blockieren.

Cluster-synchronisiertes Rate-Limiting

Rate-Limiting klingt simpel. Ist es nicht. Nicht wenn man mehrere Edge-Knoten hat.

ZERO-PROTECT synchronisiert Rate-Limit-State über alle Edge-Knoten via HAProxy-Stick-Table-Peers. Per-IP-Limits, per-Path-Limits, per-Fingerprint-Limits. Alle clusterweit. Ein Angreifer kann Rate-Limits nicht umgehen, indem er einen anderen PoP attackiert. Der State folgt ihm.

JA4- und Pfad-Rate-Limiting

Eine Stufe über dem Basis-Rate-Limiting. Diese Schicht kombiniert TLS-Fingerprint und URL-Pfad für granulare Steuerung. Ein Bot, der Ihr Login-Endpoint mit demselben JA4-Fingerprint hämmert, wird genau auf diesem Pfad gedrosselt. Ohne legitime Nutzer auf anderen Site-Bereichen zu treffen. Nützlich für gezielte Bot-Muster und Hochmissbrauchs-Endpoints.

WAF mit OWASP CRS

Coraza WAF mit dem OWASP Core Rule Set. Nicht geteilt. Jeder Service bekommt seinen eigenen WAF-Container mit separater Konfiguration. Paranoia-Levels sind einstellbar. Log-only-Modus erlaubt das Beobachten von Regeln, bevor Enforcement aktiviert wird. Wichtig: Eine WAF ohne Log-only-Phase auszurollen ist der schnellste Weg, legitime Nutzer zu blockieren.

GeoIP-Blocking und Custom Access Rules

Länder-Allow- und -Blocklisten. Custom-Access-Regeln nach Geo, ASN, IP, Pfad, Crawler-Signaturen und TLS-Fingerprints. Visueller Regel-Builder mit Drag-and-Drop-Priorisierung im Portal. Nicht jeder braucht das. Wer es braucht, braucht es einfach handhabbar.

Architektur

Für die Technik-Crowd, wie es gebaut ist:

• Edge-Knoten: HAProxy-basierte Reverse Proxies auf Anycast-IPs, verteilt über mehrere Standorte (Frankfurt, Helsinki)
• Config-Verteilung: Git-basiertes Pull-Modell. Edge-Knoten ziehen Config nach Schedule. Fällt die Control-Plane aus, laufen Edge-Knoten mit der letzten bekannten Config weiter.
• State-Synchronisation: HAProxy-Stick-Table-Peers für clusterweites Rate-Limiting und Session-Tracking
• WAF-Isolation: Coraza-WAF-Container pro Mandant. Separate Configs, separate Rule-Sets, separate Log-Streams.
• Control-Plane: Kubernetes-gehostete API und Portal
• Infrastructure-Management: Ansible-gemanagt, vollautomatisierte Provisionierung

Die zentrale Design-Entscheidung: Edge-Knoten sind autonom. Sie hängen nicht an einer zentralen API, um Traffic auszuliefern oder Schutzregeln anzuwenden. Die Control-Plane verwaltet Konfiguration. Die Edge-Knoten erzwingen sie unabhängig. Das heißt: Schutz läuft weiter, auch während Control-Plane-Wartung oder -Incidents.

Für Kunden mit Isolations-Anforderung bieten wir dedizierte Edge-Knoten pro Kunde an. Ihr Traffic läuft auf Hardware, die nicht mit anderen Kunden geteilt wird. Ein Angriff auf einen anderen Kunden der Plattform berührt Ihre Edge-Infrastruktur nicht. Das ist der Dedicated-Tier. Gleicher Schutz-Stack, dedizierte Ressourcen.