How ZERO-PROTECT Works

DDoS protection products tend to optimize for marketing numbers — global PoP counts, aggregate scrubbing capacity. We optimized ZERO-PROTECT for what actually happens during an attack: a request-by-request mitigation pipeline that infrastructure teams can reason about.

This article walks through the technical layers — how attacks get stopped, and why each layer exists.

The Attack Surface

DDoS attacks split into two fundamentally different problems.

Volumetric attacks (Layer 3/4) flood your network with traffic. UDP amplification, SYN floods, IP fragmentation — the goal is to overwhelm your bandwidth and exhaust your infrastructure. These attacks are measured in Gbps and Mpps. Defending against them requires filtering at the network edge, before traffic ever reaches your servers.

Application-layer attacks (Layer 7) are more subtle. They look like legitimate HTTP requests — valid TLS handshakes, proper headers, realistic timing. A few thousand requests per second from rotating IPs can take down an application server that handles millions of legitimate requests just fine. The difference: every attack request triggers expensive backend work (database queries, API calls, session creation).

You need both layers covered. A WAF won't help when 50 Gbps of UDP floods your uplink. And BGP blackholing won't stop 200 bots making valid-looking POST requests to your checkout page.

Layer 3/4: Stopping Volumetric Attacks at the Edge

Volumetric attacks need to be handled before they reach your application stack. By the time traffic hits your reverse proxy, it's too late — the pipe is already full.

ZERO-PROTECT uses BGP Flowspec to apply mitigation rules at the network edge. Flowspec rules propagate across our edge nodes in Frankfurt and Helsinki within seconds. Traffic matching attack patterns gets dropped at the network level — it never reaches your origin.

We won't tell you we have unlimited capacity — nobody does. What we will tell you is exactly what our edge can absorb. Honest dimensioning beats marketing claims — see our DRS 6 self-assessment for how we measure that capacity against an open standard.

Layer 7: Where It Gets Interesting

This is where most DDoS protection either gets expensive or gets useless. Application-layer attacks look like real users. IP-based rate limiting stopped being effective years ago — any bot operator with a budget rotates through residential proxies.

ZERO-PROTECT stacks multiple detection methods at Layer 7. Each one catches a different attack pattern.

Proof-of-Work Challenges

CAPTCHAs annoy legitimate users and are increasingly solved by AI. We took a different approach: Argon2-based computational puzzles.

When a request triggers a challenge, the browser receives a small puzzle. Real browsers solve it in milliseconds — the user doesn't notice. A bot farm running thousands of concurrent sessions needs real CPU time per request. At scale, this makes application-layer floods economically unviable. The difficulty is adjustable per service — crank it up during an active attack, dial it back when things are quiet.

JA4 TLS Fingerprinting

JA4 creates a fingerprint from TLS handshake parameters: cipher suites, extensions, supported versions, key share groups. The insight is simple — bots using the same framework produce identical TLS fingerprints, even when rotating through thousands of IP addresses.

A Python requests bot has a different JA4 fingerprint than Chrome. A Go HTTP client has a different fingerprint than Firefox. We rate-limit by fingerprint, not just by IP. An attacker rotating through a million residential proxies but using the same bot framework gets caught on every single request.

Connection Rate Limiting + Slow-HTTP Detection

Before anything hits the HTTP layer, ZERO-PROTECT enforces per-source connection throttling. This catches connection floods early — but also Slowloris, Slow POST, and Slow Read attacks. These attacks don't flood you with volume. They open connections and trickle data just slowly enough to hold resources indefinitely. ZERO-PROTECT detects and terminates them before they tie up your application.

Cluster-Synchronized Rate Limiting

Rate limiting sounds simple. It isn't — not when you have multiple edge nodes.

ZERO-PROTECT synchronizes rate limit state across all edge nodes via HAProxy stick-table peers. Per-IP limits, per-path limits, per-fingerprint limits — all cluster-wide. An attacker can't dodge rate limits by hitting a different PoP. The state follows them.

JA4 / Path Rate Limiting

A step beyond basic rate limiting. This layer combines TLS fingerprint and URL path for granular control. A bot hammering your login endpoint with the same JA4 fingerprint gets throttled specifically on that path — without affecting legitimate users browsing other parts of your site. Useful for targeting specific bot patterns and high-abuse endpoints.

WAF with OWASP CRS

Coraza WAF running the OWASP Core Rule Set. Not shared — each service gets its own WAF container with separate configuration. Paranoia levels are tunable. Log-only mode lets you watch rules fire before enabling enforcement. This is important: rolling out a WAF without log-only mode is how you block legitimate traffic.

GeoIP Blocking and Custom Access Rules

Country-level allow/blocklists. Custom access rules matching geo, ASN, IP, path, crawler signatures, and TLS fingerprints. Visual rule builder with drag-and-drop ordering in the portal. Not everyone needs this — but when you do, you need it to be easy to manage.

Architecture

For the technical crowd, here's how it's built:

• Edge nodes: HAProxy-based reverse proxies on anycast IPs, deployed across multiple sites (Frankfurt, Helsinki)
• Config distribution: Git-based pull model. Edge nodes pull config on schedule. If the control plane goes down, edge nodes keep running with the last known-good config.
• State synchronization: HAProxy stick-table peers for cluster-wide rate limiting and session tracking
• WAF isolation: Per-tenant Coraza WAF containers. Separate configs, separate rule sets, separate log streams.
• Control plane: Kubernetes-hosted API and portal
• Infrastructure management: Ansible-managed, fully automated provisioning

The key design decision: edge nodes are autonomous. They don't depend on a central API to serve traffic or apply protection rules. The control plane manages configuration — the edge nodes enforce it independently. This means protection continues even during control plane maintenance or incidents.

For customers who need full isolation, we offer dedicated per-customer edge nodes. Your traffic is processed on hardware that isn't shared with other customers. An attack targeting another customer on the platform never touches your edge infrastructure. This is the Dedicated tier — same protection stack, dedicated resources.