How We Handle DDoS Protection: Cloudflare + Traefik Defense in Depth | Deployxa

DDoS attacks can take your app offline. Here is how Deployxa handles DDoS protection with Cloudflare and Traefik, in a defense-in-depth strategy.

← Back to Dispatch Articles
Engineering Log

How We Handle DDoS Protection: Cloudflare + Traefik Defense in Depth

DDoS attacks can take your app offline. Here is how Deployxa handles DDoS protection with Cloudflare and Traefik, in a defense-in-depth strategy.

How We Handle DDoS Protection: Cloudflare + Traefik Defense in Depth

DDoS (Distributed Denial of Service) attacks can take your app offline by overwhelming it with traffic from thousands of sources. Defending against DDoS requires a defense-in-depth strategy: filtering at the edge (Cloudflare) and at the origin (Traefik). Deployxa uses both, which provides robust protection against most DDoS attacks. Here is how the system works.

The direct answer is that Deployxa's DDoS protection has two layers: Cloudflare (which filters traffic at the edge, blocking obvious attacks before they reach the origin) and Traefik (which rate-limits and routes traffic at the origin, handling attacks that slip through Cloudflare). The two layers work together in a defense-in-depth strategy, which provides robust protection against most DDoS attacks. For more on the infrastructure, see our article on the container networking model.

The Two Layers

1. Cloudflare (edge filtering)

Cloudflare sits in front of all Deployxa apps, providing edge filtering. Cloudflare's DDoS protection automatically detects and blocks common DDoS attacks (e.g., SYN floods, UDP floods, HTTP floods) at the edge, before they reach the origin. Cloudflare also provides rate limiting (which limits the number of requests per IP), bot protection (which blocks known bots), and Web Application Firewall (WAF) rules (which block common attacks like SQL injection and XSS).

2. Traefik (origin filtering)

Traefik is the origin reverse proxy, which handles traffic that passes through Cloudflare. Traefik provides rate limiting (which limits the number of requests per IP at the origin), connection limiting (which limits the number of concurrent connections per IP), and health checks (which removes unhealthy containers from the load balancer). Traefik also handles SSL termination and routing.

Step-by-Step: How a Request Flows Through the DDoS Protection

Step 1: The user sends a request

The user's browser sends a request to https://myapp.com.

Step 2: Cloudflare filters the request

The request hits Cloudflare's edge network. Cloudflare checks:

  • Is the IP a known attacker? If so, block.
  • Is the request rate above the limit? If so, rate limit.
  • Is the request a known bot? If so, challenge or block.
  • Does the request match a WAF rule? If so, block.

Step 3: Cloudflare proxies to Traefik

If the request passes Cloudflare's filters, Cloudflare proxies it to Traefik (at the origin).

Step 4: Traefik filters the request

Traefik checks:

  • Is the connection rate above the limit? If so, reject.
  • Is the request rate above the limit? If so, rate limit.
  • Is the target container healthy? If not, return 503.

Step 5: Traefik proxies to the container

If the request passes Traefik's filters, Traefik proxies it to the container.

Common Pitfalls and Troubleshooting

The first pitfall is false positives. Cloudflare's DDoS protection might block legitimate traffic (e.g., a user behind a shared IP that is also used by an attacker). The fix is to monitor false positives and to adjust Cloudflare's security level. The second pitfall is rate limiting legitimate users. Traefik's rate limiting might rate limit legitimate users (e.g., a user who makes many API calls in a short period). The fix is to set appropriate rate limits (e.g., 100 requests per minute per IP). The third pitfall is Cloudflare cache invalidation. Cloudflare caches static assets, and if you update a static asset, the cache might serve the old version. The fix is to use cache-busting (e.g., content hashes in filenames). The fourth pitfall is Cloudflare downtime. If Cloudflare is down, your app is inaccessible (because all traffic goes through Cloudflare). The fix is to have a fallback (e.g., a DNS failover to a different CDN). The fifth pitfall is not configuring Cloudflare properly. Cloudflare's default settings are good, but some settings (e.g., SSL mode, caching rules) need to be configured for your app. The fix is to review Cloudflare's settings and to configure them appropriately.

Advanced DDoS Protection Patterns

Beyond the basics, Deployxa's DDoS protection supports several advanced patterns. The first is custom WAF rules. Cloudflare's Web Application Firewall (WAF) lets you write custom rules (in a DSL similar to Wireshark filters) that block specific attack patterns. For example, you can block requests that contain SQL injection patterns (UNION SELECT), XSS patterns (