Mitigating Layer 7 Application DDoS Attacks with Coraza WAF and Caddy Server on a VPS

Introduction to the Layer 7 DDoS Threat Landscape

In contemporary cybersecurity, Distributed Denial of Service (DDoS) attacks have shifted drastically from simple network-layer floods to highly sophisticated Application Layer (Layer 7) assaults. While Layer 3 and Layer 4 attacks target bandwidth and network infrastructure, Layer 7 attacks mimic legitimate human behavior to exhaust server resources like CPU, memory, and database connection pools.

Common Layer 7 attack vectors include heavy HTTP GET requests targeting resource-intensive search endpoints, HTTP POST floods, and slow-rate attacks like Slowloris. Because these requests look like authentic traffic, traditional firewalls operating at the network packet layer often fail to identify them. To safeguard business continuity, engineering teams must deploy a Web Application Firewall (WAF) capable of deep packet inspection and semantic analysis at the application tier.

Why Choose Coraza WAF and Caddy Server for Your VPS?

Deploying an enterprise-grade security stack on a Virtual Private Server (VPS) historically required combining Nginx or Apache with ModSecurity. However, ModSecurity has reached its end-of-life status, leading modern infrastructure engineers toward next-generation alternatives. The combination of Coraza WAF and Caddy Server represents a highly efficient, modern, and production-ready security framework.

Caddy Server: A modern web server written in Go, renowned for its performance, memory safety, native HTTP/3 support, and automated, seamless TLS certificate management via Let's Encrypt.
Coraza WAF: An open-source, enterprise-grade WAF framework written completely in Go. It acts as a drop-in replacement for ModSecurity, offering 100% compatibility with the SecLang rule syntax and the industry-standard OWASP Core Rule Set (CRS).

Integrating Coraza directly inside Caddy via an HTTP handler plugin eliminates the context-switching overhead often seen in multi-process architectures, delivering ultra-low latency request filtering on resource-constrained VPS instances.

Prerequisites and Environment Setup

Before proceeding with the deployment, ensure your environment meets the following baseline requirements:

A VPS running a modern Linux distribution (e.g., Ubuntu 24.04 LTS or Debian 12) with root or sudo access.
A registered domain name pointing to your VPS public IP address via an A record.
Go programming language toolchain installed (version 1.21 or newer) to compile custom binaries.

Step-by-Step Guide: Compiling Caddy with Coraza WAF

Since the official standard distribution of Caddy does not bundle the Coraza WAF plugin out of the box, we utilize xcaddy—the official Caddy builder tool—to compile a customized binary containing the necessary modules.

Step 1: Install xcaddy and Build the Binary

Execute the following commands to install xcaddy and compile Caddy alongside the coraza-caddy plugin v2:

sudo apt update && sudo apt install -y git go-golang
go install github.com/caddyserver/xcaddy/cmd/xcaddy@latest
~/go/bin/xcaddy build --with github.com/corazawaf/coraza-caddy/v2

Once compiled successfully, move the generated binary to your system execution path and configure a dedicated, low-privilege system user for service security:

sudo mv caddy /usr/bin/
sudo useradd --system --gid caddy --create-home --home-dir /var/lib/caddy --shell /usr/sbin/nologin caddy

Step 2: Initialize Configuration Directories and OWASP CRS

Create the structural configuration directories and fetch the recommended Coraza configuration along with the OWASP Core Rule Set (CRS), which provides the baseline signatures required to detect application-layer threats:

sudo mkdir -p /etc/caddy/rules
cd /etc/caddy/rules

# Download recommended Coraza configuration
sudo wget https://raw.githubusercontent.com/corazawaf/coraza/main/coraza.conf-recommended -O coraza.conf

# Clone the OWASP Core Rule Set
sudo git clone https://github.com/coreruleset/coreruleset.git
sudo cp coreruleset/crs-setup.conf.example coreruleset/crs-setup.conf

Configuring the Caddyfile for Layer 7 Protection

With the software components prepared, we now configure the Caddyfile located at /etc/caddy/Caddyfile. We must ensure that the Coraza global option block executes before other standard directives to drop malicious traffic immediately upon arrival.

Open the file with your preferred text editor and structure it as follows:

{
    # Initialize and order the Coraza WAF handler first
    order coraza_waf first
}

yourdomain.com {
    # Reverse proxy backend application or serve static files
    reverse_proxy 127.0.0.1:8080

    # Enable and configure Coraza WAF
    coraza_waf {
        load_owasp_crs
        directives `
            SecRuleEngine On
            SecRequestBodyAccess On
            SecResponseBodyAccess On
            SecAuditEngine On
            SecAuditLog "/var/log/caddy/coraza_audit.log"
            SecAuditLogFormat JSON
            Include /etc/caddy/rules/coraza.conf
            Include /etc/caddy/rules/coreruleset/crs-setup.conf
            Include /etc/caddy/rules/coreruleset/rules/*.conf
        `
    }
}

Production Note: During the initial deployment phase, it is highly recommended to set SecRuleEngine DetectionOnly inside your directives block. This logs potential triggers without dropping legitimate traffic, allowing you to fine-tune rules and mitigate false positives before shifting to full-blocking execution mode (SecRuleEngine On).

Fine-Tuning WAF Policies to Mitigate Layer 7 DDoS Attacks

While the standard OWASP Core Rule Set is remarkably effective against standard vulnerability exploits (SQLi, XSS, RCE), defending against application-layer DDoS requires strict request rate filtering, connection state validation, and client verification anomalies.

1. Global Rate Limiting and Request Quotas

To defend critical infrastructure, you should implement rate limits directly via custom SecLang rules within your Coraza configuration block. For example, the following rule tracks IP addresses and drops clients making more than 100 requests per minute to sensitive endpoints:

SecAction "id:900010,phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR}"
SecRule REQUEST_URI "^/api/v1/search" "id:900011,phase:1,chain,deny,status:429,log,msg:'Rate Limit Exceeded'"
  SecRule &ip:request_count "@gt 100" "setvar:ip.blocked=1"
SecAction "id:900012,phase:1,nolog,pass,setvar:ip.request_count=+1,expirevar:ip.request_count=60"

2. Enforcing Strict Request Schema and Protocol Checks

Attack scripts targeting Layer 7 layer often skip standard headers or protocol compliance parameters to maintain maximum execution speed. Coraza’s built-in rule sets systematically validate common elements such as missing User-Agent strings, unacceptable Content-Length fields mismatch, and invalid HTTP protocol versions. Enabling these protocol enforcement profiles naturally mitigates a vast majority of automated botnets.

Monitoring, Logging, and Verification

A defensive posture requires comprehensive visibility into ongoing traffic patterns. Because Coraza integrates natively into the Caddy pipeline, execution events are recorded with detailed transaction contexts.

To verify that your security architecture is working optimally, simulate an attack vector from an external terminal using a basic command utility like curl:

curl -H "User-Agent: AttackBot" http://yourdomain.com/?exec=/bin/bash

Review your logs to verify parsing accuracy and threat containment metrics:

tail -f /var/log/caddy/coraza_audit.log | grep -E "id|msg"

The structured JSON audit logs provide clear visibility, including the specific rule triggered, originating client IP address, request method, and the automated action executed by the platform.

Conclusion and Architectural Best Practices

Deploying Coraza WAF combined with Caddy Server on a dedicated VPS delivers an exceptionally lightweight, modern, and reliable shield against Layer 7 application DDoS attacks. By combining deep signature matching, protocol enforcement, and tailored rate limits, your business web applications remain resilient in hostile network conditions.

As standard operational maintenance, ensure that your operational teams periodically update the underlying OWASP Core Rule Set definitions, perform log analysis to spot systemic architectural adjustments, and combine local WAF filtering with edge CDN layer defenses to achieve an optimal defense-in-depth framework.