DDoS Megascale Operations: Defending Against AI-Orchestrated Terabit Attacks and Botnet Smokescreens

Problem

DDoS attacks have crossed the terabit-per-second threshold and they are not slowing down. In 2025, the largest recorded attack exceeded 5.6 Tbps. By 2026, attacks over 1 Tbps are routine.

Three shifts have changed the threat:

AI-orchestrated botnets. Compromised IoT devices (cameras, routers, smart home devices, industrial sensors) number in the tens of millions. AI-powered command systems coordinate these botnets in real time: rotating attack vectors, adapting to mitigation, distributing traffic patterns to evade detection, and selecting the most effective attack type for the target’s infrastructure.
Megascale volumetric attacks. A single botnet can generate traffic volumes that exceed the capacity of any single data centre. UDP amplification (DNS, NTP, memcached, CLDAP), TCP SYN floods, and HTTP/2 rapid reset attacks can saturate even 100 Gbps uplinks. Your origin infrastructure cannot absorb these volumes regardless of how well it is configured.
DDoS as a smokescreen. The most dangerous development: DDoS attacks are increasingly used as diversions. While the security team is focused on mitigating the volumetric attack, a simultaneous intrusion operation targets the application layer: credential stuffing, SQL injection, API abuse, or exploitation of a known vulnerability. The DDoS creates chaos and alert fatigue that masks the real attack.

The defensive architecture has three layers:

Edge absorption (CDN/scrubbing service) to handle volumetric attacks that exceed your origin capacity
Origin hardening (rate limiting, connection management, resource protection) to handle application-layer attacks that pass through the edge
Smokescreen detection (correlation of DDoS events with simultaneous application-layer anomalies) to detect the real attack hidden behind the DDoS

Threat Model

Adversary: Botnet operator using AI-coordinated command infrastructure. DDoS-for-hire services make attacks accessible to anyone for as little as $50/hour. Sophisticated adversaries use DDoS as a distraction for targeted intrusion.
Access level: None required for volumetric attacks (UDP/TCP floods). Application-layer attacks (HTTP floods, API abuse) may use stolen credentials or target unauthenticated endpoints.
Objective: Service disruption (availability impact). Financial damage (cloud infrastructure costs spike during attack). Smokescreen (distract defenders while a separate attack targets data theft or infrastructure compromise).
Blast radius: Volumetric attacks affect all services behind the same network link. Application-layer attacks target specific services. Smokescreen attacks affect the services targeted by the hidden operation.

The key shift: A DDoS attack is no longer just a denial-of-service event. It may be the distraction. If your incident response treats DDoS as the only threat, you miss the real attack happening simultaneously.

Configuration

Layer 1: Edge Absorption

Volumetric attacks that exceed 10 Gbps cannot be absorbed by origin infrastructure. Edge networks (CDN, scrubbing services) absorb the attack traffic before it reaches your origin.

Configure Cloudflare for DDoS protection:

# Enable DDoS protection for your zone (via Cloudflare API)
# This enables automatic detection and mitigation of volumetric attacks.

# Set security level to "high" during normal operation
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/settings/security_level" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"value":"high"}'

# Enable bot management to detect AI-orchestrated bot traffic
curl -X PUT "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/bot_management" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"enable_js_detection":true,"fight_mode":true}'

# Configure rate limiting at the edge
curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/rate_limits" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{
    "match": {
      "request": {"url_pattern": "*.example.com/*"}
    },
    "threshold": 100,
    "period": 60,
    "action": {"mode": "challenge"}
  }'

Ensure origin IP is not exposed:

# Verify that your origin IP is not leaked in DNS history, SSL certificates,
# or HTTP headers.

# Check DNS history for origin IP leaks
dig +short example.com
# Should return Cloudflare IPs, not your origin IP

# Verify origin IP is not in certificate transparency logs
# Search crt.sh for your origin IP in certificate SANs

# Remove origin IP from any public DNS records
# Only Cloudflare proxied records should resolve publicly

Configure origin firewall to accept only edge traffic:

# nftables: allow HTTPS only from Cloudflare IP ranges
# Block all direct access to origin from the internet

sudo tee /etc/nftables.d/cloudflare-only.conf << 'NFTEOF'
# Cloudflare IPv4 ranges (update periodically from https://www.cloudflare.com/ips-v4)
define cloudflare_ipv4 = {
    173.245.48.0/20,
    103.21.244.0/22,
    103.22.200.0/22,
    103.31.4.0/22,
    141.101.64.0/18,
    108.162.192.0/18,
    190.93.240.0/20,
    188.114.96.0/20,
    197.234.240.0/22,
    198.41.128.0/17,
    162.158.0.0/15,
    104.16.0.0/13,
    104.24.0.0/14,
    172.64.0.0/13,
    131.0.72.0/22
}

table inet filter {
    chain input {
        # Allow HTTPS only from Cloudflare
        ip saddr $cloudflare_ipv4 tcp dport 443 accept

        # Block direct HTTPS access from all other sources
        tcp dport 443 drop
    }
}
NFTEOF

sudo nft -f /etc/nftables.d/cloudflare-only.conf

Layer 2: Origin Hardening

Application-layer attacks (HTTP floods, slowloris, API abuse) pass through the edge because each individual request looks legitimate. The origin must handle these without exhausting resources.

NGINX connection and rate limiting:

# /etc/nginx/conf.d/ddos-hardening.conf

# Rate limiting zones
# $binary_remote_addr = per source IP
# 10m = 10MB shared memory zone (~160,000 IPs)
limit_req_zone $binary_remote_addr zone=general:10m rate=30r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# Connection limiting
limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
    listen 443 ssl;
    server_name app.example.com;

    # Maximum 20 concurrent connections per IP
    limit_conn addr 20;

    # General rate limit: 30 requests/second with burst of 50
    location / {
        limit_req zone=general burst=50 nodelay;
        proxy_pass http://backend;
    }

    # API rate limit: 10 requests/second with burst of 20
    location /api/ {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://backend;
    }

    # Login rate limit: 5 attempts per minute
    location /api/auth/login {
        limit_req zone=login burst=5 nodelay;
        proxy_pass http://backend;
    }

    # Block oversized request bodies (prevent resource exhaustion)
    client_max_body_size 10m;

    # Timeout slow connections (slowloris defence)
    client_body_timeout 10s;
    client_header_timeout 10s;
    send_timeout 10s;
    keepalive_timeout 15s;

    # Limit request header and body buffer sizes
    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;
    client_body_buffer_size 16k;
}

Kernel-level SYN flood protection:

# /etc/sysctl.d/99-ddos-hardening.conf
# Enable SYN cookies (handles SYN floods without allocating connection state)
net.ipv4.tcp_syncookies = 1

# Reduce SYN-ACK retries (drop half-open connections faster)
net.ipv4.tcp_synack_retries = 2

# Increase the SYN backlog
net.ipv4.tcp_max_syn_backlog = 65536

# Reduce TIME_WAIT connections
net.ipv4.tcp_fin_timeout = 15

# Enable connection tracking for stateful firewall
net.netfilter.nf_conntrack_max = 1048576

# Increase connection tracking timeout for established connections
net.netfilter.nf_conntrack_tcp_timeout_established = 600

# Disable source routing (prevent IP spoofing)
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# Enable reverse path filtering (drop packets with spoofed source IPs)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Disable ICMP redirect acceptance
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0

# Apply sysctl settings
sudo sysctl --system

nftables rate limiting for UDP amplification attacks:

# /etc/nftables.d/udp-protection.conf
# Rate limit inbound UDP to prevent amplification attacks.

table inet filter {
    chain input {
        # Rate limit DNS responses (prevents DNS amplification)
        udp sport 53 limit rate 100/second burst 200 packets accept
        udp sport 53 drop

        # Rate limit NTP responses (prevents NTP amplification)
        udp sport 123 limit rate 10/second burst 20 packets accept
        udp sport 123 drop

        # Drop memcached responses (no legitimate reason for inbound memcached)
        udp sport 11211 drop

        # Drop CLDAP responses
        udp sport 389 drop
    }
}

Layer 3: Smokescreen Detection

The most dangerous DDoS attacks are diversions. While the security team mitigates the volumetric attack, a simultaneous intrusion operation targets the application layer. Detect the real attack behind the smokescreen.

Correlate DDoS events with application-layer anomalies:

# prometheus-smokescreen-detection.yaml
groups:
  - name: ddos-smokescreen
    interval: 1m
    rules:
      # Detect DDoS event (traffic spike above 10x baseline)
      - record: security:ddos_active
        expr: >
          rate(nginx_http_requests_total[1m])
          > 10 * avg_over_time(rate(nginx_http_requests_total[1m])[7d:1m])

      # During DDoS: alert on ANY authentication anomaly
      # (normally low-priority, becomes high-priority during DDoS)
      - alert: AuthAnomalyDuringDDoS
        expr: >
          security:ddos_active > 0
          and (
            rate(authentication_failures_total[5m]) > 5
            or
            (authentication_success_total unless on (user, source_ip)
             authentication_success_total offset 7d)
          )
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "SMOKESCREEN ALERT: Authentication anomaly during active DDoS"
          description: >
            DDoS attack is active AND authentication anomalies detected
            simultaneously. This is a high-confidence indicator of a
            smokescreen attack. The DDoS may be a distraction for
            credential stuffing or lateral movement.
            INVESTIGATE THE AUTH ANOMALY, NOT THE DDOS.

      # During DDoS: alert on unusual database query patterns
      - alert: DatabaseAnomalyDuringDDoS
        expr: >
          security:ddos_active > 0
          and rate(database_queries_total{type="select"}[5m])
          > 3 * avg_over_time(rate(database_queries_total{type="select"}[5m])[7d:5m])
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "SMOKESCREEN ALERT: Database query spike during active DDoS"
          description: >
            Database queries are 3x above baseline during an active
            DDoS attack. May indicate data exfiltration running
            behind the DDoS smokescreen.

      # During DDoS: alert on new outbound connections
      - alert: NewOutboundDuringDDoS
        expr: >
          security:ddos_active > 0
          and (
            rate(container_network_transmit_bytes_total[5m])
            > 2 * avg_over_time(rate(container_network_transmit_bytes_total[5m])[7d:5m])
          )
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "SMOKESCREEN ALERT: Outbound data spike during DDoS"

Incident response procedure for DDoS with smokescreen risk:

#!/bin/bash
# ddos-response.sh
# DDoS incident response that includes smokescreen detection.

echo "=== DDoS INCIDENT RESPONSE ==="
echo "Time: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo ""

echo "Step 1: CONFIRM DDoS is being mitigated at the edge"
echo "  - Check Cloudflare dashboard for attack mitigation status"
echo "  - Verify origin is not directly accessible"
echo ""

echo "Step 2: IMMEDIATELY check for smokescreen indicators"
echo "  This is the PRIORITY. The DDoS itself is handled by the edge."
echo "  The real threat may be happening simultaneously."
echo ""

echo "  Checking authentication anomalies..."
# Query authentication logs for anomalies during the DDoS window
sudo ausearch -m USER_LOGIN --start recent -i 2>/dev/null | tail -20

echo ""
echo "  Checking for unusual outbound traffic..."
# Check for data exfiltration during the attack window
ss -s

echo ""
echo "  Checking for new processes..."
# Check for unexpected processes that may have been deployed during the chaos
ps aux --sort=start_time | tail -20

echo ""
echo "Step 3: Assignment"
echo "  - Team A: Continue DDoS mitigation and edge monitoring"
echo "  - Team B: Investigate ALL application-layer anomalies"
echo "  - Team B has PRIORITY. The DDoS is the distraction."
echo ""
echo "Step 4: Post-incident"
echo "  - Review ALL authentication logs during the DDoS window"
echo "  - Review ALL database query logs during the DDoS window"
echo "  - Review ALL outbound traffic logs during the DDoS window"
echo "  - The smokescreen attack may have succeeded silently"

Auto-Scaling for Application-Layer Attacks

# hpa-ddos.yaml
# Horizontal Pod Autoscaler configured for DDoS resilience.
# Scale up application pods to handle HTTP flood that passes through the edge.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-ddos-resilient
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: app
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 60
    - type: Pods
      pods:
        metric:
          name: nginx_http_requests_per_second
        target:
          type: AverageValue
          averageValue: "1000"
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
        - type: Percent
          value: 100
          periodSeconds: 30
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 10
          periodSeconds: 60

Expected Behaviour

Edge absorption: Volumetric attacks (SYN floods, UDP amplification, HTTP floods) are mitigated at the Cloudflare edge. Origin receives only legitimate traffic. Attack traffic never reaches your infrastructure.
Origin hardening: Application-layer attacks that pass through the edge are rate-limited at NGINX. SYN cookies handle SYN floods without resource exhaustion. Oversized requests are rejected. Slow connections are timed out.
Smokescreen detection: During an active DDoS, all application-layer anomalies (authentication failures, database query spikes, outbound data transfers) are escalated to critical priority. The incident response procedure assigns a separate team to investigate the smokescreen risk.
Auto-scaling: Application pods scale up within 30 seconds of CPU threshold breach. Maximum 20 replicas to handle sustained application-layer floods without cost overrun.

Trade-offs

Control	Impact	Risk	Mitigation
Edge proxy (Cloudflare)	All traffic routed through third party. Adds latency (5-20ms).	Dependency on edge provider availability. Provider outage = site down.	Multi-CDN architecture for critical services. Origin can serve directly as fallback (update DNS).
Origin IP hiding	Origin is not directly addressable	Origin IP leaked through DNS history, email headers, or SSL certificates	Audit all DNS records, SSL certificates, and email headers for origin IP exposure. Change origin IP if leaked.
Rate limiting (30 req/s per IP)	Legitimate users behind shared NAT (corporate offices, mobile carriers) may hit limits	Users receive 429 errors	Increase limits for known CIDR ranges (corporate offices). Implement challenge pages (CAPTCHA) instead of hard blocks.
SYN cookies	Trades CPU for connection state during floods	Minor CPU increase during normal operation	SYN cookies only activate when the SYN backlog is full. Under normal load, standard TCP handshake is used.
Smokescreen alerting during DDoS	High alert volume during DDoS event	Alert fatigue may cause the smokescreen alert to be missed	Smokescreen alerts are CRITICAL priority and routed to a separate team (not the DDoS response team).
Auto-scaling during attack	Cloud costs increase during sustained attack	Attacker can trigger cost exhaustion through sustained application-layer floods	Set maxReplicas to cap costs. Alert when scaling reaches 80% of max.

Failure Modes

Failure	Symptom	Detection	Recovery
Origin IP discovered by attacker	DDoS hits origin directly, bypassing edge	Origin traffic spike despite edge mitigation; edge shows no attack traffic	Change origin IP. Update firewall rules. Audit all potential IP leak sources.
Edge provider outage	Site unreachable even without active attack	Monitoring detects site down; edge provider status page confirms outage	Failover to direct origin access (update DNS). Accept reduced DDoS protection during failover.
Rate limiting blocks legitimate burst	Users during product launch or sale event hit rate limits	High 429 rate; user complaints; no actual attack in progress	Pre-scale rate limits before known high-traffic events. Use dynamic rate limits that increase during planned events.
Smokescreen attack succeeds undetected	Data breach discovered days after DDoS event	Post-incident forensics reveals data exfiltration during DDoS window	Implement the smokescreen detection rules. Assign dedicated team to investigate application-layer anomalies during every DDoS event.
Auto-scaler reaches max replicas	Application performance degrades under sustained flood even at max scale	All 20 replicas at high CPU; response times increasing	Increase edge rate limiting. Implement challenge pages. Block attacking IP ranges at the edge. Consider temporarily geo-blocking non-essential regions.
Bot adapts to mitigation	AI-orchestrated botnet changes attack vector after initial mitigation	New attack pattern detected after initial mitigation succeeds; second wave uses different protocol/path	Multi-vector mitigation. Edge providers with AI-adaptive mitigation. Do not assume a single mitigation solves the attack permanently.

When to Consider a Managed Alternative

Transition point: Any DDoS attack exceeding your upstream bandwidth capacity (typically 1-10 Gbps for cloud VMs, 10-100 Gbps for dedicated infrastructure) cannot be mitigated at the origin. Edge-based mitigation is mandatory, not optional, for any internet-facing service.

Cloudflare: Global edge network with 296+ Tbps capacity. Automatic DDoS mitigation for L3/L4 (volumetric) and L7 (application-layer) attacks. AI-powered bot detection adapts to AI-orchestrated botnets. Free tier includes basic DDoS protection; Business and Enterprise tiers include advanced mitigation and analytics.
Fastly: Edge cloud platform with DDoS mitigation. Programmable edge (VCL/Compute@Edge) allows custom mitigation logic that runs at the edge. Signal Sciences integration for application-layer attack detection.
AWS Shield Advanced: DDoS protection for AWS resources (ALB, CloudFront, Route 53). Includes 24/7 DDoS Response Team (DRT) access, cost protection (AWS credits for scaling costs during attacks), and advanced attack visibility.

What you still control: Origin hardening (NGINX rate limiting, kernel tuning, nftables rules). Smokescreen detection logic and incident response procedures. Auto-scaling configuration and cost caps. These controls protect the origin when application-layer attacks pass through the edge. The edge handles volume; you handle logic.

Premium content pack: DDoS defence templates. Cloudflare API configuration scripts for zone hardening. NGINX rate limiting configurations for different application profiles. nftables rules for UDP amplification protection. Prometheus alerting rules for smokescreen detection. DDoS incident response playbook with smokescreen investigation procedures.