Building a Private CDN to Mitigate Layer 7 DDoS: A Blueprint Using Apache Traffic Server and CrowdSec

Introduction: The Imperative for Private Infrastructure Resilience

In the contemporary digital landscape, high availability and low latency are no longer competitive advantages—they are baseline operational requirements. For enterprises managing high-traffic web applications, relying solely on commercial, multi-tenant Content Delivery Networks (CDNs) can introduce challenges, including rigid configurations, escalating variable costs, and vendor lock-in. More critically, sophisticated Layer 7 (Application Layer) DDoS attacks are growing in frequency and complexity, often bypassing traditional volumetric defenses by mimicking legitimate user behavior.

Building a private CDN empowers organizations to retain complete sovereignty over their data traffic, optimize caching strategies for specific workloads, and implement granular security policies. This technical guide provides a comprehensive blueprint for architecting a self-hosted, resilient CDN infrastructure. By leveraging Apache Traffic Server (ATS) as the caching engine and CrowdSec with its specialized ATS Bouncer as the security layer, engineers can construct a high-performance edge network capable of mitigating targeted application-layer attacks in real time.

Architectural Overview: The Edge Defense Model

A private CDN functions by distributing edge nodes geographically closer to the end users, terminating SSL/TLS sessions at the perimeter, and caching static and dynamic content. When a Layer 7 attack occurs (such as an HTTP flood, slowloris, or brute-force attack), the objective is to detect and drop malicious requests at these edge nodes before they can saturate the origin shield or internal database clusters.

The architecture detailed in this guide relies on two core components:

• Apache Traffic Server (ATS): Originally developed by Yahoo! and now maintained by the Apache Software Foundation, ATS is an industrial-grade, fast, scalable, and extensible caching proxy server. It handles concurrent connections efficiently through an asynchronous, event-driven processing model.
• CrowdSec: A modern, open-source, collaborative threat detection engine written in Go. It analyzes application logs in real time, detects aggressive behaviors using YAML-based scenarios, and leverages a global community blocklist to preemptively block known malicious actors.

Step 1: Deploying and Configuring Apache Traffic Server

To establish the caching infrastructure, Apache Traffic Server must be installed on your distributed edge instances (typically running a production-ready Linux distribution like Ubuntu LTS or Rocky Linux). Once installed, the primary configuration involves defining how ATS interacts with the origin server and manages cache rules.

Configuring Mapping and Reverse Proxy Rules

The core routing behavior of ATS is managed via the remap.config file. This file dictates how incoming client requests are mapped to backend origin servers. To configure ATS as a reverse proxy with caching enabled, add the following directive:

map [https://cdn.example.com/](https://cdn.example.com/) [http://origin.internal.example.com/](http://origin.internal.example.com/) @plugin=cachekey.so @plugin=compress.so

In this configuration, ATS terminates incoming HTTPS requests at the edge and forwards them over an internal network to the origin server. The addition of the cachekey.so and compress.so plugins ensures optimal cache key generation and on-the-fly Gzip/Brotli compression, reducing payload sizes and accelerating delivery times.

Optimizing Global Cache Policies

Fine-tuning memory and disk usage is critical for sustaining performance under heavy load. In records.config, adjust the following parameters to align with your edge hardware specifications:

• CONFIG proxy.config.cache.ram_cache.size INT 4294967296 (Allocates 4GB of RAM for ultra-fast memory caching)
• CONFIG proxy.config.http.cache.http INT 1 (Enables global HTTP caching)
• CONFIG proxy.config.net.connections_throttle INT 10000 (Prevents file descriptor exhaustion by throttling concurrent connections safely)

Step 2: Implementing CrowdSec for Real-Time Threat Intelligence

With the caching layer operational, the next phase is securing the edge against Layer 7 anomalies. Traditional firewalls operate at Layers 3 and 4, making them blind to HTTP request patterns. CrowdSec solves this by parsing ATS access logs to identify malicious behavior footprints.

Installing the CrowdSec Security Engine

Install the security engine on each edge node using the official repository. Once installed, configure the CrowdSec acquisition file (acquis.yaml) to monitor the Apache Traffic Server log stream:

filenames:
  - /usr/local/var/log/trafficserver/squid.blog
labels:
  type: squid

Note: ATS can be configured to output logs in the standard Squid format, which CrowdSec natively parses out of the box.

Enabling Layer 7 Protection Scenarios

Deploy specialized detection scenarios from the CrowdSec Hub to counter application-layer threats. For a robust anti-DDoS posture, install scenarios designed to detect HTTP floods, crawling, and scanning vectors:

1. cscli collections install crowdsecurity/http-cve
2. cscli scenarios install crowdsecurity/http-crawl-non_statics
3. cscli scenarios install crowdsecurity/http-slow-dos

These configurations allow CrowdSec to track request rates per IP address. If an IP exceeds behavioral thresholds—such as requesting non-static resources dozens of times per second—the engine immediately generates an alert and creates a local decision to block or challenge the actor.

Step 3: Integrating the CrowdSec Bouncer with Apache Traffic Server

Detection is ineffective without enforcement. To bridge the gap between CrowdSec's intelligence and Apache Traffic Server's traffic handling, we utilize a dedicated CrowdSec Lua Bouncer integrated via the ATS Lua plugin architecture.

Configuring the Lua Enforcement Plugin

The bouncer acts as a gatekeeper. When a request hits ATS, the Lua script executes before the cache lookup or origin forward occurs. It checks the requesting IP against CrowdSec’s local API (LAPI) database of active decisions.

To activate enforcement, reference the Lua bouncer script within your ATS global plugin configuration (plugin.config):

ts_lua.so /etc/trafficserver/plugins/crowdsec_ats_bouncer.lua /etc/crowdsec/bouncers/crowdsec-ats-bouncer.yaml

Inside the bouncer configuration file (crowdsec-ats-bouncer.yaml), define the LAPI endpoint, authorization tokens, and the fallback remediation strategy:

• remediation: Set to ban to drop connections immediately, or captcha to present a challenge page, allowing human users to bypass false positives during intense attacks.

Step 4: Stress Testing and Performance Validation

Before routing live enterprise traffic through your new private CDN, it is imperative to validate both caching efficiency and anti-DDoS mitigation capabilities under simulated stress conditions.

Simulating an Application Layer HTTP Flood

Utilize benchmarking tools such as wrk or Vega from an isolated testing subnet to simulate a distributed HTTP GET flood against an asset managed by the CDN:

wrk -t12 -c400 -d30s [https://cdn.example.com/index.html](https://cdn.example.com/index.html)

During the simulation, monitor the ATS performance metrics and the CrowdSec active decisions log simultaneously using cscli decisions list. You should observe the following sequence:

1. The initial burst of traffic is absorbed instantly by the ATS RAM cache, protecting the backend origin server from seeing any load increase.
2. Within seconds, the IP address running the load test breaches the threshold defined in the http-crawl-non_statics scenario.
3. CrowdSec updates the local decision state, and subsequent requests from the test IP are summarily rejected at the ATS edge with a 403 Forbidden or dropped entirely, dropping CPU utilization back to baseline levels.

Conclusion: Operational Autonomy and Forward Scalability

By pairing Apache Traffic Server with CrowdSec, organizations can build an autonomous, highly resilient private CDN that offers elite-tier protection against Layer 7 DDoS attacks. ATS guarantees that legitimate content delivery remains performant and scalable, while CrowdSec acts as an intelligent, automated security perimeter that adapts to evolving threats in real time.

As your traffic grows, this architecture scales horizontally. New edge nodes can be provisioned dynamically, registering automatically with a centralized CrowdSec Local API to pull shared blocklists. This strategy effectively immunizes your entire infrastructure against threats identified by any single node, providing enterprise-grade web performance and robust defense sovereignty.