Why WAF Misses CC Attacks: Common Causes and Mitigations

WAF on, site still down from CC? Covers why WAFs miss CC requests, plus copy-paste Nginx rate limiting, API anti-CC, and log analysis configs.

CC attacks are among the most common attacks site operators face. Many still get knocked over after turning on a WAF and conclude the WAF is useless. This FAQ covers why WAFs miss CC requests, which techniques are inherently hard to block, and copy-paste configs for Nginx rate limiting, API protection, and log analysis.

Q: WAF is on. Why did CC still take the site down?

Three main reasons. First, WAF core capability is rule matching. It is good at blocking content-malicious requests such as SQLi and WebShells. CC requests are often fully legitimate in content—only volume is excessive. Rules have nothing to match. Second, CC typically mimics normal browser behavior with complete Cookie and Referer; signature detection struggles to separate humans from attack. Third, many WAFs do not enable rate limiting by default, or thresholds are too loose. Door installed, no throttle.

Q: Which CC techniques are inherently hard for WAF to block?

• Low-rate slow attacks: one or two requests per IP per second, but connections held open (e.g. Slowloris). Traffic signature is weak.
• Randomized requests: random URL parameters, rotating User-Agent. Rules miss.
• Mass proxy IPs: traffic from bots or proxy pools. Per-IP volume is low. IP bans are ineffective.
• Full handshake impersonation: real browser engines. JS challenges and CAPTCHAs can be bypassed.

Q: How to detect IP-dispersed CC early?

Key is log aggregation features, not reading requests one by one. Typical CC logs: URI concentrated on a few endpoints, total request volume far above normal, source IP count spikes. Count source IPs fast:

`awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20`

Then count hottest URIs:

`awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10`

If a few URIs account for more than half of requests and source IPs are highly dispersed, it is CC.

Q: How to configure Nginx rate limiting to catch CC that leaked past the WAF?

A Nginx rate-limit layer behind the WAF is the most practical backstop. Reference config:

`limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=connperip:10m;

server {
    location / {
        limit_req zone=perip burst=20 nodelay;
        limit_conn connperip 20;
        limit_req_status 429;
    }
}`

rate=10r/s is the per-IP average request-rate cap. burst=20 is allowed burst queue. limit_conn caps concurrent connections per IP. Tune thresholds against normal business peaks. Too low and you false-positive real users.

Q: Should static pages and dynamic APIs be protected separately?

Must separate. Static assets can use looser limits; CDN absorbs most origin-pull pressure. Dynamic endpoints (login, search, checkout) are the primary CC targets—tighten thresholds and stack CAPTCHA or session checks. Attackers most often hit search and login. Those endpoints are expensive on the backend; a small request volume can stall the database.

Q: API under CC. What then?

Tighten rate limits on the API path alone:

`location /api/ {
    limit_req zone=perip burst=5 nodelay;
    limit_req_status 429;
}`

Beyond rate limits, APIs need three more controls: signature verification (request params carry timestamp and signature), token rate limiting (limit by account, not just IP), and anomaly blocking (same account, high frequency → ban the session). Pure IP limiting is weak against proxy-pool attacks. Account-dimension rate limiting is the key.

Q: During an attack, which log fields matter?

Five fields: source IP, request URI, User-Agent, status code, response time. Mass 499/502/504 in status codes means the backend is already overloaded. Response time spiking across the board means the connection pool is exhausted. Tune these fields against rate-limit thresholds. More effective than blindly adding rules.

Q: Any additional recommendations?

CC defense is layered: WAF rules stop content attacks, rate-limit components control request rate, CDN offloads static pressure, anti-DDoS nodes absorb volumetric traffic. Four layers, each owns a slice. If your WAF only does rule matching and has no CC rate-limiting, onboard an anti-DDoS CDN or WAF with intelligent rate limiting. Pre-build emergency scripts (one-click switch of rate-limit config, one-click report/ban IPs) so you are not scrambling when the attack starts.