基于挑战应答机制过滤非浏览器DDoS流量

DDoS 攻击早已不是单纯的流量拥塞游戏。现在最让运维头疼的，是那些高度模拟真实浏览器的应用层攻击。攻击者不再使用简陋的脚本，而是利用无头浏览器、自动化框架，甚至完整的浏览器内核来发起请求。这类流量在 TCP 握手、TLS 指纹、HTTP 头字段上都与真实用户无异，传统的速率限制和 IP 黑名单基本失效。要解决这个问题，必须深入到协议层和应用逻辑的交界处，引入一种能区分“具备完整浏览器计算能力”和“仅能发送 HTTP 请求”的机制，这就是挑战应答机制的核心价值。

挑战应答机制的本质，是验证客户端是否拥有一个真实的浏览器运行环境，以及这个环境能否执行特定的计算任务。它不依赖请求频率，也不依赖 IP 信誉库，而是直接向客户端浏览器注入一段 JavaScript 挑战代码。这段代码会要求浏览器执行一系列计算，比如解析特定的 DOM 结构、执行加密哈希运算、验证 Web API 的完整性，然后将结果作为应答返回给服务器。非浏览器的 DDoS 工具，无论是基于 Python 的 requests 库、Go 语言的 net/http，还是 C 语言编写的原始套接字程序，都无法解析和执行这段 JavaScript，也就无法生成正确的应答。服务器在放行请求前，先验证应答的有效性，这就把不具备完整 JavaScript 执行环境的流量全部挡在了外面。

早期的挑战应答实现得非常粗糙，典型做法是返回一段包含 document.cookie 操作的 JavaScript，设置一个 Cookie 后刷新页面。这种机制在 2015 年前后还能应对大部分脚本小子，但现在的攻击者早已进化。无头浏览器如 Puppeteer、Playwright 和 Selenium 可以完整执行这类简单挑战，攻击成本并没有显著增加。因此，现代挑战应答机制必须引入更复杂的验证维度，包括但不限于：浏览器指纹的一致性校验、WebGL 渲染能力检测、音频处理 API 的浮点运算精度验证、甚至是 Canvas 指纹的细微差异。这些检测点利用了不同浏览器引擎在底层实现上的微妙区别，自动化工具很难在短时间内完美模拟所有细节。

在架构部署上，挑战应答机制通常有两种工作模式。第一种是被动模式，也叫旁路模式。流量先经过检测设备，设备对请求进行镜像分析，当判定某个客户端存在异常时，才会对其后续请求注入挑战代码。这种模式对正常用户完全透明，延迟极低，但存在一个时间窗口，在判定完成前，攻击流量可能已经到达源站。第二种是主动模式，也叫串联模式。所有首次访问的请求都会被拦截并返回挑战页面，只有通过挑战的客户端才会被加入白名单，后续请求直接放行。主动模式的安全性最高，但会在首次访问时引入几百毫秒的延迟，对用户体验有一定影响。实际生产环境中，通常会结合两种模式，对已知的安全客户端采用被动监控，对可疑 IP 段或新出现的会话采用主动挑战。

为了理解其核心逻辑，可以看一个极度简化的服务端实现思路。下面这段伪代码展示了 Nginx 配合 Lua 模块如何实现一个基础的挑战应答流程。它不依赖任何商业 CDN，完全可以在自有服务器上运行。

-- 挑战密钥，定期轮换
local secret = "a1b2c3d4e5f6"

-- 检查请求头中是否携带了有效的挑战令牌
local token = ngx.var.http_x_challenge_token
if token then
    -- 解析令牌: 时间戳:随机数:签名
    local parts = {}
    for part in string.gmatch(token, "[^:]+") do
        table.insert(parts, part)
    end
    if #parts == 3 then
        local ts, nonce, sig = parts[1], parts[2], parts[3]
        -- 验证时间戳是否在允许范围内（防重放）
        local now = ngx.time()
        if tonumber(ts) and math.abs(now - tonumber(ts)) < 300 then
            -- 重新计算签名
            local expected_sig = ngx.md5(ts .. ":" .. nonce .. ":" .. secret)
            if sig == expected_sig then
                -- 验证通过，放行请求
                return
            end
        end
    end
end

-- 令牌无效或不存在，返回挑战页面
local nonce = ngx.md5(ngx.now() .. math.random())
local html = [[
<!DOCTYPE html>
<html>
<head>
<script>
(function(){
    var now = Math.floor(Date.now() / 1000);
    var nonce = ']] .. nonce .. [[';
    var secret = ']] .. secret .. [[';
    // 在浏览器中计算签名，这部分逻辑攻击脚本无法预知
    var sig = md5(now + ':' + nonce + ':' + secret);
    // 将令牌写入请求头并重新发起请求
    var xhr = new XMLHttpRequest();
    xhr.open('GET', window.location.href, true);
    xhr.setRequestHeader('X-Challenge-Token', now + ':' + nonce + ':' + sig);
    xhr.onload = function() {
        if(xhr.status === 200) {
            document.open();
            document.write(xhr.responseText);
            document.close();
        }
    };
    xhr.send();
})();
</script>
</head>
<body>正在验证浏览器环境，请稍候...</body>
</html>
]]
ngx.header.content_type = "text/html"
ngx.say(html)
ngx.exit(ngx.HTTP_OK)

这个原型的核心思路在于，服务端将签名密钥嵌入到返回的 JavaScript 中，要求客户端在本地计算 MD5 签名并通过自定义请求头回传。攻击脚本如果不解析 HTML 并执行其中的 JavaScript，就永远无法获得有效的令牌。当然，这只是一个教学示例，生产环境需要加入更多混淆、浏览器指纹检测，并且密钥绝对不能明文出现在客户端代码中，而是应该采用非对称加密或零知识证明的方式。

单纯的数学计算挑战，理论上可以被攻击者用无头浏览器批量执行。因此，现代挑战应答机制必须结合浏览器指纹技术。指纹检测会在挑战代码执行的同时，收集客户端环境的数百个维度信息：屏幕分辨率、色深、时区偏移、安装的字体列表、WebGL 渲染器字符串、Canvas 指纹、AudioContext 指纹、navigator 对象的属性完整性等。一个真实的 Chrome 浏览器在 Windows 10 上的 WebGL 渲染器字符串可能是“ANGLE (Intel, Intel(R) UHD Graphics 620 Direct3D11 vs_5_0 ps_5_0)”，而 Puppeteer 默认的无头模式则可能返回“Google SwiftShader”或者完全缺失。攻击者如果尝试修改这些属性来伪装，又很容易因为属性之间的逻辑矛盾而被识别。例如，将屏幕分辨率设置为 1920x1080，但 devicePixelRatio 却保持默认的 1，这种不一致性会立刻触发告警。

挑战应答机制中还有一个容易被忽视的细节，就是计算工作量的设定。挑战代码的执行时间必须控制在一个精妙的范围内：太短则攻击者可以用极低成本通过验证，太长则影响真实用户的体验。通常，挑战的计算耗时应该控制在 100 到 300 毫秒之间。这个时间对于人类用户来说几乎无感知，因为页面加载本身就需要数百毫秒。但对于攻击者，如果他想维持每秒数千个请求的速率，每个请求都要额外消耗 200 毫秒的 CPU 时间，总计算资源消耗就会急剧上升。一些高级实现还会采用动态难度调整，当检测到某个 IP 段或 ASN 的挑战通过率异常时，自动增加挑战的计算复杂度，比如要求计算哈希碰撞的前导零数量，让攻击者的成本指数级增长。

挑战应答机制主要工作在应用层，但它可以和传输层的检测手段形成互补。TLS 握手阶段的 JA3 指纹能够反映客户端 TLS 库的实现特征。Python 的 requests 库、Go 的 http 客户端、以及真实浏览器在 TLS 握手时发送的密码套件顺序、椭圆曲线参数、扩展字段都有显著差异。即使攻击者使用了无头浏览器，如果他的请求代理工具在 TLS 层留下了非浏览器的指纹，仍然会被识别。同样，HTTP/2 的流优先级、窗口大小更新策略、头部压缩字典的使用模式，也是区分浏览器和非浏览器流量的重要信号。将挑战应答机制与这些协议层检测结合，可以构建一个多层次的防御体系，让攻击者即使绕过了应用层的 JS 挑战，也会在传输层暴露痕迹。

挑战应答机制在移动端和纯 API 场景下需要特殊设计。移动 App 的原生网络请求不会执行 JavaScript，如果对所有请求都返回 HTML 挑战页面，App 就会直接报错。针对这种情况，需要将挑战逻辑下沉到 SDK 层面。移动 App 集成防御 SDK 后，SDK 会在本地生成挑战应答所需的令牌，附加到每个请求中。服务端验证令牌的流程不变，但挑战的生成和应答都在原生代码中完成。对于公开 API，如果调用方是合作伙伴的后端服务，显然也无法执行 JavaScript。此时应该采用基于预共享密钥的签名机制，或者要求调用方在请求头中携带特定格式的签名，本质上是一种静态的挑战应答，验证的是调用方是否持有合法的密钥，而不是是否拥有浏览器环境。

如果决定自建而非采购商业方案，有几个关键点必须处理好。第一是挑战代码的混淆和更新频率。如果挑战逻辑长期不变，攻击者可以逆向工程后直接模拟签名算法，绕过 JS 执行环节。挑战代码应该每周甚至每天自动变更，变更内容包括变量名、加密算法、调用链顺序等。第二是状态管理。挑战通过后生成的令牌需要设置合理的有效期，并且与客户端 IP、User-Agent 等上下文绑定，防止攻击者截获一个有效令牌后无限复用。第三是降级策略。挑战应答系统自身可能故障，此时必须有旁路机制，保证合法流量不被误拦，可以配置为在系统负载过高或响应超时时自动放行所有请求，宁可漏过也不可误杀。

随着 WebAssembly 的普及和浏览器 API 的进一步丰富，挑战应答机制正在向更深层次发展。未来的挑战代码可能会以 Wasm 模块的形式下发，利用 Wasm 的字节码特性增加逆向难度。同时，验证的内容将从“是否能执行 JS”转向“是否能证明自己是人类操作”。例如，挑战代码可以检测鼠标轨迹、触摸事件的压力感应、设备陀螺仪的微动数据等生物行为特征。这些特征难以用脚本批量伪造，因为它们背后是物理世界的随机性。挑战应答机制最终会演变为一个持续性的身份验证过程，而不是一次性的门禁检查。