Defending Nginx Against CC Attacks with Cookie Validation and Lua Rate Limiting

This guide explains how to use simple Nginx configurations, enhanced cookie checks, and Lua scripts to create unforgeable tokens, limit request rates, and protect web services from CC attacks, scanning tools, and other malicious traffic while maintaining normal user access.

ITPUB
ITPUB
ITPUB
Defending Nginx Against CC Attacks with Cookie Validation and Lua Rate Limiting

Introduction

The OpenCDN team demonstrates how to protect a website from various attacks—especially CC (Challenge Collapsar) attacks—by leveraging standard Nginx modules combined with Lua scripting, without relying on external firewalls or complex proxy layers.

Simple Cookie‑Based Validation

A basic approach sets a cookie named say to a fixed value and redirects the client. If the client returns the cookie on the next request, access is granted; otherwise the client remains trapped in a 302 redirect loop.

if ($cookie_say != "hbnl") { add_header Set-Cookie "say=hbnl"; rewrite .* "$scheme://$host$uri" redirect; }

This works only against browsers that cannot manually set the cookie, but attackers can easily mimic the value.

Enhanced Per‑IP Cookie Validation

To prevent attackers from reusing a static cookie, the cookie value is tied to the client’s IP address.

if ($cookie_say != "hbnl$remote_addr") { add_header Set-Cookie "say=hbnl$remote_addr"; rewrite .* "$scheme://$host$uri" redirect; }

Each IP receives a unique token, making simple cookie replay attacks ineffective, though a determined attacker could still compute the token.

Perfect Version: Unforgeable Hashed Tokens with Lua

By generating an MD5 hash of a secret string combined with the client’s IP, the token becomes computationally infeasible to forge. Nginx’s native modules cannot hash strings, so the ngx_lua module is used.

rewrite_by_lua ' local say = ngx.md5("opencdn" .. ngx.var.remote_addr) if (ngx.var.cookie_say ~= say) then ngx.header["Set-Cookie"] = "say=" .. say return ngx.redirect(ngx.var.scheme .. "://" .. ngx.var.host .. ngx.var.uri) end ';

This forces browsers to present a valid, IP‑specific hash before accessing the site, thwarting both low‑level CC tools and more sophisticated scripts.

Request Rate Limiting with Stateless Tokens

To avoid IP‑based rate limiting pitfalls (e.g., legitimate users behind a NAT), a stateless token is generated per request using a random number and the client’s IP. The token is stored in two cookies: token and random.

rewrite_by_lua ' local random = ngx.var.cookie_random if (random == nil) then random = math.random(999999) end local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random) if (ngx.var.cookie_token ~= token) then ngx.header["Set-Cookie"] = {"token=" .. token, "random=" .. random} return ngx.redirect(ngx.var.scheme .. "://" .. ngx.var.host .. ngx.var.uri) end ';

With this token, Nginx’s limit_req_zone can limit requests per token rather than per IP:

http { ... limit_req_zone $cookie_token zone=session_limit:3m rate=1r/s; }

Applying the limit is as simple as:

limit_req zone=session_limit burst=5;

Additional logic can restrict how often a client may obtain a new token, further tightening the rate‑limit.

Advanced Token‑Based Authorization Flow

A more robust design separates token issuance into an /auth endpoint, which itself is rate‑limited (e.g., one token per IP per minute). The main location checks the token and redirects unauthenticated clients to /auth.

http { ... limit_req_zone $cookie_token zone=session_limit:3m rate=1r/s; limit_req_zone $binary_remote_addr $uri zone=auth_limit:3m rate=1r/m; } location / { limit_req zone=session_limit burst=5; rewrite_by_lua '... token verification ...'; } location /auth { limit_req zone=auth_limit burst=1; if ($arg_url = "") { return 403; } access_by_lua '... generate token and set cookies ...'; }

This ensures that token generation itself cannot be abused at high rates.

Additional Defensive Measures

For scanning tools and generic attacks, the article recommends the ngx_lua_waf module, which can be combined with the rate‑limiting strategy to block malicious patterns without reinventing a WAF.

Conclusion

The configurations provided are intended as starting points; readers should adapt them to their own services, consider performance impacts, and be aware that sophisticated attackers may still find ways around static defenses. Nonetheless, the described cookie‑hash and token‑based rate limiting significantly raise the cost of launching successful CC or scanning attacks.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Nginxrate limitingLuaWeb Securitycc attack mitigationcookie validation
ITPUB
Written by

ITPUB

Official ITPUB account sharing technical insights, community news, and exciting events.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.