Identifying DDoS and CC Attacks: From Connection Counts, Logs to Emergency Rate Limiting

When a website suddenly becomes inaccessible, CPU usage hits 100%, or bandwidth is saturated—the first step is to determine whether traffic has genuinely increased or if the site is under attack. The response strategies for these two scenarios are completely different: genuine traffic spikes require capacity expansion, while attacks require interception.

Furthermore, the responses to DDoS and CC attacks differ significantly: DDoS relies on bandwidth and upstream scrubbing, whereas CC attacks rely on application-layer rate limiting. Confusing the two will lead to ineffective countermeasures.

Differentiating the Attack Type

Quick Diagnosis

# Is bandwidth saturated? → Points to DDoS
sar -n DEV 1 3
# Or check bandwidth monitoring in the cloud console

# CPU/Load high but bandwidth normal → Points to CC
top
uptime

# Check connection counts
ss -s
ss -ant | awk '{print $1}' | sort | uniq -c | sort -rn

Criteria: Bandwidth full = DDoS; Bandwidth normal but CPU full = CC.

Identification: Finding the Attack Source

# ① Count connections by IP (most common)
ss -ant | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

# Connections in ESTABLISHED state
ss -ant state established | awk '{print $5}' | cut -d: -f1 
  | sort | uniq -c | sort -rn | head -20

# ② Count requests by IP in access logs
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# ③ Count requests from the last minute
awk -v d="$(date -d '1 min ago' +'%d/%b/%Y:%H:%M')" '$4 ~ d' 
  /var/log/nginx/access.log | wc -l

# ④ Check if URLs are concentrated on specific paths
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# ⑤ Check if User-Agents (UA) are abnormally concentrated
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

Typical characteristics of CC attacks:

• A small number of IPs generate massive requests (dozens of IPs account for the majority of traffic)
• Requests concentrate on a few URLs (especially resource-intensive ones: search, list pages, uncached dynamic pages)
• UA is highly consistent or clearly indicates a script/bot

Emergency Response: Application-Layer Rate Limiting (for CC)

# Define rate limiting rules in the http block
http {
    # Rate limit by IP: 10 requests per second, burst allows 20
    limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
    # Limit concurrent connections per single IP
    limit_conn_zone $binary_remote_addr zone=perip_conn:10m;

    server {
        location / {
            limit_req  zone=perip burst=20 nodelay;
            limit_conn perip_conn 20;
            ...
        }
    }
}

# Validate and apply changes
nginx -t && nginx -s reload

# Monitor rate-limited requests
grep -c 'limiting requests' /var/log/nginx/error.log

rate must be adjusted according to actual business needs. Setting it too low will affect legitimate users (especially mobile users sharing the same exit IP). It is better to start with a looser limit, observe, and then tighten it.

Emergency Response: Blocking IPs

# Block IP at the nginx level
echo 'deny 1.2.3.4;' >> /etc/nginx/conf.d/blockip.conf
nginx -t && nginx -s reload

# System firewall (earlier stage, lower overhead)
iptables -A INPUT -s 1.2.3.4 -j DROP

# Batch block high-frequency IPs from logs (Verify before executing!)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn 
  | awk '$1 > 1000 {print $2}' > /tmp/badip.txt
while read ip; do iptables -A INPUT -s "$ip" -j DROP; done < /tmp/badip.txt

Always review the IP list before batch blocking. If there is a CDN or reverse proxy in front of the site, the IPs in the logs might be CDN nodes—blocking them will cause all legitimate users to lose access. The cost of this mistake is high.

# Verify if IPs in logs are real users or CDN nodes
head -20 /tmp/badip.txt
# If the top IPs have extremely high request volumes and are concentrated, they are likely CDN nodes; do not block them

A More Fundamental Approach: Stopping Attacks Before They Reach the Server

Application-layer rate limiting only takes effect after the server has received the requests, meaning resources have already been consumed. A more effective approach is to prevent requests from reaching the server:

• CDN / High-Defense Services: Traffic is scrubbed at the edge, and only legitimate requests reach the origin.
• Hide Origin IP: Only allow CDN IP ranges to access the origin server, preventing attackers from bypassing the CDN to hit the origin directly.

# Allow only CDN origin-pull IP ranges (Example, replace with actual ranges)
allow 203.0.113.0/24;
deny all;

# Close ports 80/443 on the server to the public (only allow CDN ranges) — Configuring this in the Cloud Security Group is more effective

“Hiding the Origin IP” is particularly critical for small sites. If attackers know the origin IP, the CDN becomes useless.

Decision Tree

Site Under Attack
├─ Is bandwidth saturated?
│  ├─ Yes → DDoS (Traffic-based)
│  │  ├─ Can you still log into the server?
│  │  │  ├─ No → Use cloud console: High-Defense/Scrubbing
│  │  │  └─ Yes → Coordinate with upstream, hide origin IP
│  │  └─ Application-layer rate limiting is ineffective; rely on upstream
│  └─ No, but CPU/Load is full → CC
│     ├─ Identify high-frequency IPs (Distinguish CDN nodes)
│     ├─ Apply rate limiting via limit_req / limit_conn
│     ├─ Block confirmed attacking IPs
│     └─ Long-term: CDN + Hide Origin IP
└─ Uncertain
   └─ Check request distribution in access logs: Concentrated on few URLs/IPs → CC

Scenario Walkthrough: Bandwidth Saturated, Site Unavailable to All

Symptoms: Site response slows down until completely inaccessible; monitoring shows egress bandwidth consistently maxed out.
Logs show requests appearing as normal page views with no obvious anomalies.

1. Analyze connection characteristics rather than request content → Large number of connections from dispersed addresses,
   all concentrating on a few resource-intensive paths.
2. Statistically analyze request distribution to find the true target → Grouping by path reveals that
   the vast majority of requests fall on a few high-overhead paths (e.g., search, large images, dynamically generated pages).
3. Differentiate between bandwidth-saturating and resource-consuming attacks → The former fills bandwidth with massive requests,
   while the latter cripples the backend with fewer requests; this case is the latter, as bandwidth usage is disproportionate to request size.
4. Stop the bleeding first: Rate limit target paths → Apply request rate limits and temporarily control high-frequency sources.
5. Reduce the cost of high-frequency paths → Add caching for cacheable results,
   add verification or block at the web layer for high-overhead entry points.
6. Preserve evidence and plan future protection → Keep connection snapshots and statistical results
   as a basis for adjusting thresholds and rules later.

# Statistic request distribution by path — Find the true target
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -15

# Statistic by source address
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -15

# Check connection state distribution (大量 half-open connections are typical)
ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn

# Nginx rate limiting example
# limit_req_zone $binary_remote_addr zone=req:10m rate=10r/s;
# location /search_path { limit_req zone=req burst=20 nodelay; ... }

Root Cause: Requests concentrated on a few high-overhead dynamic paths. Each request is costly,
so even a small number of sources can exhaust backend capabilities. Every request looks normal in the logs, so content analysis alone cannot identify the threat.

Two key takeaways:

• To identify this type of pressure, look at “distribution”, not “content”.
  Perform counting statistics by path and source; the target will often become immediately apparent—the requests themselves are legal, the problem is their concentration.
• Rate limit first, optimize second. Do not reverse the order.
  If you modify performance without stopping the pressure, the effects of your changes will be masked by the ongoing load, making it impossible to judge effectiveness.

8 Common Pitfalls

1. Failing to distinguish between DDoS and CC: The countermeasures are entirely different.
2. Applying application-layer rate limiting to traffic-based attacks: If bandwidth is full, rate limiting won’t help.
3. Making judgments without checking bandwidth: Bandwidth is the key indicator to distinguish between the two.
4. Accidentally blocking CDN node IPs: This causes all legitimate users to lose access.
5. Setting limit_req too strictly: This harms legitimate users.
6. Exposing the Origin IP: Allows attackers to bypass the CDN.
7. Relying solely on server-side protection: By the time requests arrive, resources are already consumed.
8. Failing to harden defenses after an attack: The same attack will happen again.

Real Customer Feedback (From Reviews and Consultations on Similar Cloud Marketplace Products)

The following excerpts are taken from real buyer reviews and consultations for similar operations and maintenance services on Alibaba Cloud / Tencent Cloud / Huawei Cloud Marketplaces (service providers include our store and competitors, provided here for reference only, not fictional tickets from this site):

1****8 Rating: 5.0 Stars 2019-10-29 22:35 Good 1

1****1 Rating: 5.0 Stars 2020-06-18 11:50 1****1 Rating: 5.0 Stars 2020-04-26 18:46 1****1 Rating: 5.0 Stars 2020-04-26 18:45 1****1 Rating: 5.0 Stars 2020-04-26 18:45 1****1 Rating: 5.0 Stars 2020-04-26 18:45 1****1 Rating: 5.0 Stars 2020-04-26 18:44 He****She Rating: 5.0 Stars 2019-09-26 09:47