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.