DDoS Protection Strategies: Mitigating Distributed Denial-of-Service Attacks

Distributed Denial-of-Service attacks continue to grow in scale and sophistication. With botnets capable of generating terabit-scale traffic and application-layer attacks that mimic legitimate user behavior, DDoS protection requires a layered strategy spanning network infrastructure, application logic, and operational procedures.

CDN-Based Traffic Absorption

The first line of defense against volumetric DDoS attacks is a content delivery network with large-scale traffic absorption capacity. CDNs like Cloudflare, Akamai, and AWS Shield distribute incoming traffic across a global network of edge nodes, absorbing attack traffic before it reaches your origin server.

# Cloudflare: DDoS protection configuration
resource "cloudflare_zone_settings_override" "soninow" {
  zone_id = cloudflare_zone.soninow.id

  settings {
    security_level = "high"
    challenge_ttl  = 1800
    browser_check  = "on"
  }
}

resource "cloudflare_ruleset" "ddos_mitigation" {
  zone_id  = cloudflare_zone.soninow.id
  name     = "DDoS mitigation rules"
  phase    = "ddos_l7"
  kind     = "zone"

  rules {
    action = "block"
    expression = "(ip.geoip.country in {'XX'})"
    description = "Block traffic from known attack source countries"
  }

  rules {
    action = "challenge"
    expression = "(http.request.rate.limit.requests > 100 and http.request.rate.limit.period eq 10)"
    description = "Challenge clients exceeding rate threshold"
  }
}

Enable DDoS alerting at the CDN level with notification thresholds set below your origin's capacity ceiling. Configure automatic origin IP obfuscation so attackers cannot bypass the CDN and target your server directly.

Web Application Firewall Rules

WAF rules filter malicious traffic at the application layer, blocking request patterns characteristic of Layer 7 DDoS attacks — SQL injection probes, credential stuffing, and bot-generated traffic.

// Nginx rate limiting with fail2ban integration
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
  location /api/login {
    limit_req zone=login burst=3 nodelay;
    limit_req_status 429;
    proxy_pass http://app;
  }

  location /api/ {
    limit_req zone=api:10m rate=100r/s burst=50;
    proxy_pass http://app;
  }
}

Managed WAF services (Cloudflare WAF, AWS WAF, Azure WAF, ModSecurity with OWASP CRS) provide pre-built rule sets that block known attack patterns. Tune these rules during a baseline period to reduce false positives before enforcing them in blocking mode.

# AWS WAF rate-based rule for IP reputation blocking
RateBasedRule:
  Name: high-rate-rule
  Priority: 1
  Statement:
    RateBasedStatement:
      Limit: 2000
      AggregateKeyType: IP
  Action:
    Block: {}
  VisibilityConfig:
    SampledRequestsEnabled: true
    CloudWatchMetricsEnabled: true
    MetricName: high-rate-rule

Application-Layer Rate Limiting

Beyond infrastructure-level limits, application-layer rate limiting protects specific endpoints from abuse. Different endpoints require different thresholds — login endpoints need strict limits, while public content APIs can tolerate higher rates.

import { RateLimiterRedis } from 'rate-limiter-flexible';

// Per-user endpoint rate limiting
const rateLimiter = new RateLimiterRedis({
  storeClient: redisClient,
  keyPrefix: 'ratelimit',
  points: 100,      // Number of requests
  duration: 60,     // Per 60 seconds
  blockDuration: 120, // Block for 2 minutes if exceeded
});

async function rateLimitMiddleware(req: Request, res: Response, next: NextFunction) {
  try {
    const key = req.user?.id || req.ip;
    await rateLimiter.consume(key);
    next();
  } catch (error) {
    if (error instanceof Error) {
      return res.status(429).json({
        error: 'Rate limit exceeded',
        retryAfter: Math.ceil(error.msBeforeNext / 1000),
      });
    }
    throw error;
  }
}

Implement exponential backoff in rate limit responses. When a client exceeds the limit, increase the blocking duration with each subsequent violation. Return Retry-After headers so well-behaved clients can pace themselves automatically.

Traffic Profiling and Anomaly Detection

DDoS attacks often follow recognizable traffic patterns — sudden traffic spikes from unfamiliar geographic regions, requests to unusual endpoints, or identical User-Agent strings. Profiling normal traffic patterns enables automated detection of anomalies.

# Datadog monitor: Detect traffic anomaly
monitor:
  name: "Traffic anomaly detection [production]"
  type: "query alert"
  query: "anomalies(sum:trace.requests.rate{env:production}.as_count(), 'basic', 2)"
  message: |
    Traffic anomaly detected on {{value.name}}.
    Current: {{value}}
    Baseline: {{comparator}}
    @ops-team
  tags: ["ddos", "production"]

Integrate traffic monitoring with automated mitigation actions. When anomaly detection triggers, automatically enable challenge pages (JavaScript challenges, CAPTCHAs) for suspicious traffic or increase rate limiting strictness.

Anycast Network Architecture

Anycast routing directs traffic to the nearest available data center, distributing load across multiple geographic locations. During a DDoS attack, traffic naturally spreads across the anycast network, preventing any single origin from being overwhelmed.

Anycast is most effective when combined with BGP-based traffic filtering. During large attacks, scrubbing centers can be announced via BGP to attract and filter traffic before forwarding clean traffic to the origin.

Incident Response Procedures

Even the best automated defenses benefit from a well-rehearsed incident response plan. Document the DDoS response workflow before an attack occurs.

DDoS Incident Response Steps:
1. Confirm attack: Verify traffic spike is malicious, not a legitimate surge
2. Enable challenge mode: Activate JS challenge or CAPTCHA at CDN edge
3. Identify attack vector: Determine if Layer 3/4 volumetric or Layer 7 application
4. Apply targeted filters: Block attack source IPs, ASNs, or geographic regions
5. Scale origin capacity: Temporarily increase server capacity if needed
6. Engage DDoS mitigation provider: Activate scrubbing center if attack exceeds CDN capacity
7. Post-incident analysis: Identify vulnerability that allowed attack to reach origin

Test the incident response plan quarterly with tabletop exercises. Document contact information for DDoS mitigation providers, hosting providers, and internal incident responders.

Client Reputation Scoring

Reputation-based defenses assign trust scores to clients based on behavior. Clients with poor scores — those that trigger WAF rules, exceed rate limits, or fail browser challenges — receive increasingly strict scrutiny.

// Client reputation scoring
interface ClientReputation {
  ip: string;
  score: number;     // 0 (malicious) to 100 (trusted)
  lastSeen: Date;
  violations: number;
}

async function getClientAction(req: Request): Promise<'allow' | 'challenge' | 'block'> {
  const rep = await getReputation(req.ip);

  if (rep.score < 20) return 'block';
  if (rep.score < 50) return 'challenge';
  return 'allow';
}

Distribute reputation data across your infrastructure using a shared Redis cluster so that detection on one server protects all others.

DDoS protection requires preparation before an attack occurs. Our <a href="/services/devops-server-management">infrastructure management services</a> include DDoS mitigation architecture, WAF configuration, and incident response planning. Contact SoniNow to assess your DDoS readiness.