← News
/PLAYBOOK · 2026-09-05

CC vs DDoS: how to tell them apart and how to defend

CC vs DDoS — mechanism and resource-consumption differences. Tell them apart from bandwidth and access.log. Nginx rate-limit, iptables bans, and DDoS-protected CDN configs.

Q: What is the essential difference between CC and DDoS?

The two get conflated; the attack layers are completely different. DDoS (Distributed Denial of Service) is volumetric, L3/L4. Goal: flood the pipe or exhaust the connection table with massive packets or connection requests. Typical methods: SYN Flood, UDP Flood. CC is application-layer (L7): attackers mimic legitimate HTTP requests and keep hitting the site. Traffic may be small; it exhausts CPU, memory, database connections — compute, not bandwidth.

Q: Why is CC harder to defend than volumetric DDoS?

Volumetric DDoS has a loud signature; carrier or scrubbing nodes can clean at the traffic layer. CC is hard because every request looks almost identical to a real user:

Q: How do you tell whether the site is under CC or DDoS?

Symptoms first, then logs. Symptom layer: heavy ping loss, pipe saturated, entire IP unreachable — likely volumetric DDoS. Bandwidth normal, ping works, site slow, 502/504, CPU and DB connections spike — likely CC.

Log layer, use access.log to find abnormal sources and URIs:

`# Count the top 20 source IPs by request volume
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20

# Count the top 20 most requested URIs
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -20

# Check request density within a given second (whether high-frequency and concentrated)
awk '{print $4}' access.log | cut -d: -f1-4 | uniq -c | sort -rn | head`

If one IP or a set of IPs concentrates on the same dynamic endpoint (search, query, login), it is CC. If logs cannot even be written and traffic stats blow out, it is DDoS.

Q: Common CC techniques?

Q: How does Nginx defend against CC?

Baseline: limit_req + limit_conn:

`http {
    # Max 10 requests per second per IP
    limit_req_zone $binary_remote_addr zone=cc:10m rate=10r/s;
    # Max 20 concurrent connections per IP
    limit_conn_zone $binary_remote_addr zone=conn:10m;

    server {
        # burst allows 20 requests to queue as a burst; nodelay means process immediately without delay
        limit_req zone=cc burst=20 nodelay;
        limit_conn conn 20;
        limit_req_status 503;
        limit_conn_status 503;
    }
}`

Key params: rate=10r/s caps per-IP frequency; burst caps burst tolerance. For expensive endpoints (search, query, login), set stricter thresholds in a dedicated location:

`location /search {
    limit_req zone=cc burst=5 nodelay;
    proxy_pass http://backend;
}`

Q: What can the firewall layer do?

iptables can cap per-IP concurrent connections and drop confirmed sources:

`# Drop immediately if a single IP exceeds 50 concurrent connections
iptables -I INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j DROP

# Ban a confirmed attacking IP
iptables -I INPUT -s 203.0.113.10 -j DROP`

Note: CC source IPs are usually a proxy pool. Hand-banning one by one is too slow. Pair with fail2ban-class automation: ban by request rate in logs, with a sane unban timer.

Q: When do you need WAF or a DDoS-protected CDN?

Local rate-limit is capped by that server's capacity. When attack sources hit thousands to tens of thousands, or the server is already drowning, local config will not save you. Move scrubbing to the cloud:

For onboarding see DDoS-protected onboarding in practice — split volumetric L3/L4 from application-layer CC. More on Nginx rate-limit: Nginx limit_req in practice.

Q: Any extra advice?