Building a Self-Hosted CDN to Mitigate Layer 7 DDoS Attacks Using Apache Traffic Server and CrowdSec

Introduction: The Growing Threat of Layer 7 DDoS Attacks

In the contemporary digital landscape, maintaining high availability and optimal performance is paramount for business continuity. However, modern infrastructure faces sophisticated threats, particularly Layer 7 (Application Layer) Distributed Denial of Service (DDoS) attacks. Unlike volumetric attacks that target network bandwidth, Layer 7 attacks mimic legitimate user behavior, targeting specific application resources (such as database queries or heavy dynamic pages) to exhaust server resources like CPU and memory. For enterprises seeking absolute control over their data, latency, and security budget, commercial solutions might not always fit the bill. Building a self-hosted Content Delivery Network (CDN) offers a robust, tailored alternative.

By decoupling content delivery from your origin server and injecting an intelligent security layer at the edge, you can absorb traffic spikes and filter malicious actors simultaneously. In this architectural deep-dive, we will explore how to construct a resilient, private CDN using two powerful open-source tools: Apache Traffic Server (ATS) for caching and proxying, and CrowdSec for proactive, crowdsourced threat mitigation.

The Architecture: Apache Traffic Server and CrowdSec

Before diving into configuration, it is essential to understand how these components interact within your edge infrastructure. The self-hosted CDN operates as a reverse-proxy fleet stationed in geographically strategic datacenters.

Apache Traffic Server (ATS): Originally developed by Yahoo and now an Apache Software Foundation top-level project, ATS is an enterprise-grade caching proxy capable of handling tens of thousands of concurrent requests with minimal overhead. It serves as the frontend 'edge node' that terminates SSL/TLS, serves cached content instantly, and proxies dynamic requests back to the origin server.
CrowdSec: A modern, behavior-based security engine written in Go, CrowdSec acts as a local and global threat intelligence system. It analyzes access logs generated by ATS in real-time, detects aggressive patterns (such as HTTP flooding, aggressive scanning, or brute-forcing), and immediately instructs the CrowdSec Remediation Component (Bouncer) to block or challenge the offending IP addresses at the edge.

By coupling these technologies, malicious Layer 7 requests are detected by CrowdSec and dropped by the ATS bouncer before they can trigger expensive application logic or touch the origin database.

Step 1: Deploying and Configuring Apache Traffic Server

To establish our CDN edge nodes, we first install and configure Apache Traffic Server on a distributed fleet of Linux instances (e.g., Ubuntu Server LTS).

Installation

On modern Debian/Ubuntu systems, ATS can be installed via the official repositories, though compiling from source is recommended for high-performance tuning. For this architecture, we will utilize the package manager for baseline setup:

sudo apt-get update
sudo apt-get install trafficserver

Configuring Reverse Proxy and Mapping

The primary configuration file determining how ATS routes traffic is remap.config. We must instruct ATS to map incoming public domain requests to the backend origin server. Open /etc/trafficserver/remap.config and define the routing rule:

map [https://cdn.yourbusiness.com/](https://cdn.yourbusiness.com/) [http://origin.yourbusiness.internal/](http://origin.yourbusiness.internal/)

This directive enforces that any request arriving at the edge node for cdn.yourbusiness.com is securely tunneled to the internal origin server. To optimize caching behavior, modify records.yaml to enable HTTP caching, configure memory/disk storage allocation, and define thread pools optimized for multi-core edge CPUs.

Key Optimization Note: Ensure that proxy.config.http.cache.http is set to 1 in records.yaml to maximize cache hit ratios (CHR), drastically minimizing the volume of requests hitting your origin during an active attack.

Step 2: Integrating CrowdSec for Real-Time Log Analysis

With Apache Traffic Server caching content, we must now implement the security layer to detect anomalous traffic patterns indicative of a Layer 7 DDoS attack.

Installing the CrowdSec Security Engine

Execute the official installation script to add the CrowdSec repository and deploy the core engine:

curl -s [https://install.crowdsec.net](https://install.crowdsec.net) | sudo sh
sudo apt-get install crowdsec

Upon installation, the CrowdSec engine will automatically detect your operating system and environment. However, we need to explicitly configure it to read and analyze Apache Traffic Server custom logs.

Configuring Acquisition

Instruct CrowdSec to monitor the ATS access log file by editing /etc/crowdsec/acquis.yaml:

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

Note: ATS natively supports the Squid log format, which maps perfectly to CrowdSec's pre-built parser collections. Next, install the specific HTTP defense scenarios via the CrowdSec Hub:

sudo cscli collections install crowdsecurity/http-cve
sudo cscli scenarios install crowdsecurity/http-crawl-non_exist
sudo cscli scenarios install crowdsecurity/http-slow-dos

These scenarios empower the engine to flag IPs executing rapid sequential requests, probing for non-existent pages, or attempting slow-loris style connection exhaustion.

Step 3: Deploying the Remediation Component (Bouncer) at the Edge

Detection is useless without swift execution. To prevent malicious traffic from consuming ATS resources, we deploy a CrowdSec Bouncer. Depending on your infrastructure, you can utilize the Custom Firewall Bouncer (iptables/nftables) to drop traffic at the network layer, or integrate an application-level bouncer directly within ATS if using Lua scripts.

For optimal performance against Layer 7 DDoS, dropping the traffic via the network firewall before it reaches the application socket is highly efficient. Install the Firewall Bouncer:

sudo apt-get install crowdsec-firewall-bouncer-iptables

Now, when the CrowdSec engine detects a Layer 7 flood from an IP address based on ATS log telemetry, it generates a local decision. The firewall bouncer intercepts this decision within milliseconds and injects a drop rule into the kernel routing table, completely blocking the attacker from establishing a TCP handshake with Apache Traffic Server.

Step 4: Hardening and Tuning for Enterprise-Scale DDoS Resilience

To successfully weather a highly distributed attack, default configurations are insufficient. Implement the following edge tuning practices:

Aggressive Cache Control: Configure ATS to ignore client-side Cache-Control: no-cache headers during an attack. Attackers often bypass caches by appending random query strings or forcing revalidation. Use the ATS cachekey plugin to normalize URLs and strip malicious query parameters.
Connection Throttling: Limit the maximum number of concurrent client connections per IP address within records.yaml using the proxy.config.http.number_of_client_connections directive.
Global Threat Intelligence: Connect your CrowdSec engine to the global Central API. This enables your private CDN nodes to proactively download blocklists of known malicious IPs compiled from millions of engines worldwide, neutralising threats before they ever touch your edge network.

Conclusion

Building a self-hosted CDN using Apache Traffic Server and CrowdSec grants your enterprise elite, sovereign protection against Layer 7 DDoS attacks without relying on expensive, third-party black-box vendors. By offloading resource-intensive content delivery to an optimized caching proxy and enforcing automated, crowdsourced behavioral blocking at the firewall level, you establish a highly scalable, self-defending architecture. As cyber threats continue to evolve in complexity, regaining granular control over your edge infrastructure remains one of the most strategic security decisions an organization can make.