DDoS防护源站隐藏与回源验证Token防流量穿透

DDoS防护中，源站隐藏是第一道防线，但攻击者一旦绕过CDN节点直接找到源站IP，就会形成流量穿透，直接打垮你的服务器。解决这个问题的核心方案就是"回源验证Token"机制——在CDN回源请求中加入动态令牌验证，只有携带合法Token的请求才能到达源站，非法流量在CDN层就被拦截。这套机制不是单一技术，而是源站IP隐藏、回源鉴权、Token动态生成三个环节的协同配合，下面我把每个环节拆开讲透。

一、源站隐藏为什么是基础但不够的

很多人以为用了CDN就万事大吉，源站IP不暴露就安全了。实际上，源站隐藏只是起点。攻击者通过历史DNS记录查询、子域名扫描、邮件头泄露、SSL证书透明度日志等手段，依然能拿到你的真实IP。一旦拿到IP，攻击者就可以绕过CDN，直接向源站发起大流量攻击，这就是所谓的"流量穿透"。

源站隐藏的常规做法包括：不使用源站域名做MX记录、不让源站IP出现在任何公开记录中、使用非标准端口通信、部署防火墙只允许CDN节点IP段访问。这些手段能挡住大部分扫描，但挡不住有针对性的定向攻击。所以必须在回源链路上再加一层验证，这就是Token机制存在的意义。

二、回源验证Token的核心原理

回源验证Token的本质是：CDN节点在向源站发起回源请求时，必须携带一个由双方约定算法生成的动态令牌。源站收到请求后，用同样的算法验证这个Token是否合法、是否在有效期内。如果验证失败，直接拒绝请求，返回403或401。

这个机制的关键在于"动态"二字。Token不是固定字符串，而是基于时间戳、请求参数、密钥等信息动态计算出来的。攻击者即便知道了算法，没有密钥也无法生成合法Token；即便截获了某次请求的Token，因为它有过期时间，下次也用不了。

三、Token生成与验证的具体实现方案

目前主流的实现方式有三种：基于时间戳的HMAC签名、基于请求参数的动态签名、基于IP+时间+随机数的复合令牌。下面给出一个基于时间戳HMAC的实现示例：

// CDN节点侧：生成回源Token
function generateToken(secretKey, timestamp, clientIP) {
    const payload = `${timestamp}|${clientIP}`;
    const signature = crypto.createHmac('sha256', secretKey)
        .update(payload)
        .digest('hex');
    return `${timestamp}.${signature}`;
}

// 源站侧：验证回源Token
function verifyToken(token, secretKey, clientIP, maxSkew = 300) {
    const parts = token.split('.');
    if (parts.length !== 2) return false;
    
    const [timestamp, signature] = parts;
    const currentTime = Math.floor(Date.now() / 1000);
    
    // 检查时间戳是否在允许范围内（防重放）
    if (Math.abs(currentTime - parseInt(timestamp)) > maxSkew) {
        return false;
    }
    
    const payload = `${timestamp}|${clientIP}`;
    const expectedSignature = crypto.createHmac('sha256', secretKey)
        .update(payload)
        .digest('hex');
    
    return signature === expectedSignature;
}

这段代码的逻辑很清晰：Token由时间戳和签名两部分组成，源站验证时先判断时间是否过期（这里设置了300秒的容差），再验证签名是否匹配。这种方案的安全性取决于密钥的保管和算法的强度。

四、源站防火墙配合Token做IP白名单+令牌双重验证

光靠Token还不够，最佳实践是把Token验证和IP白名单结合起来。在源站的防火墙或WAF层面，先做第一层过滤：只允许CDN节点的IP段访问源站端口。第二层才是应用层的Token验证。这样即使Token机制被突破，攻击者的流量也到不了应用层。

具体配置思路如下：在Nginx或WAF中设置allow规则，只放行CDN回源IP段，同时在应用代码中对每个回源请求检查Token头部。如果请求来自非CDN IP段，直接在防火墙层丢弃；如果来自CDN IP段但没有Token或Token无效，返回403。

# Nginx配置示例：只允许CDN回源IP段访问源站
location / {
    # CDN回源IP白名单（示例IP段，需替换为实际CDN节点IP）
    allow 103.28.54.0/24;
    allow 103.28.55.0/24;
    allow 103.28.56.0/24;
    deny all;
    
    # 验证Token头部
    if ($http_x_cdn_token = "") {
        return 403;
    }
    
    proxy_pass http://backend;
}

五、防止Token被窃取和重放攻击的关键细节

Token机制最怕两件事：一是密钥泄露，二是重放攻击。密钥泄露意味着攻击者可以自己生成合法Token；重放攻击意味着攻击者截获一次合法请求后反复使用。

防密钥泄露：密钥不要硬编码在代码里，用环境变量或密钥管理服务存储；定期轮换密钥；CDN和源站之间的密钥要分开管理，不要用同一套。防重放：Token必须绑定时间戳，设置较短的有效期（建议300秒以内）；可以加入请求URL的哈希值，让Token和具体请求绑定，即使被截获也只能用于那一次请求。

更高级的做法是加入nonce（随机数）机制。每次CDN回源时生成一个随机数，源站记录已使用的nonce，重复的直接拒绝。这能彻底杜绝重放，但会增加源站的存储开销，适合对安全要求极高的场景。

六、CDN厂商的原生支持与自建方案对比

目前主流CDN厂商都提供了类似的回源鉴权功能，比如阿里云的"回源鉴权"、腾讯云的"Referer防盗链+回源鉴权"、华为云的"回源Token验证"等。这些原生方案的好处是配置简单、和CDN节点深度集成、性能损耗小。

自建方案的优势是灵活性高，可以根据业务需求定制算法和验证逻辑。但需要注意：自建方案要确保CDN节点能执行Token生成逻辑，这通常需要在CDN的边缘计算或自定义回源头部中实现，技术门槛较高。对于大多数中小团队，直接用CDN厂商的原生回源鉴权功能是性价比最高的选择。

七、实际部署中容易踩的坑

第一个坑：Token验证逻辑放在了CDN节点上而不是源站上。记住，Token验证必须在源站做，CDN只是生成和携带Token。如果验证逻辑在CDN上，攻击者绕过CDN直接打源站时这层验证就不存在了。

第二个坑：忽略了HTTPS回源场景。如果CDN到源站走的是HTTPS，Token要放在HTTP头部里传输，注意头部名称不要和业务头部冲突。同时要确保Token不会被中间代理或负载均衡器意外清除。

第三个坑：没有做降级处理。如果Token验证服务出了问题，所有回源请求都会失败，导致网站不可用。建议做一个紧急旁路机制，在验证服务异常时允许特定IP段临时绕过验证，同时触发告警。

第四个坑：只做了回源验证，没有同步更新DNS和SSL证书。源站IP一旦在其他地方暴露，攻击者可以直接绕过CDN。所以源站隐藏、回源Token、DNS安全、证书管理要作为一个整体来做，缺一不可。

八、总结与最佳实践清单

DDoS防护是一个纵深防御体系，源站隐藏是第一层，回源Token验证是第二层，两者缺一不可。具体落地时，建议按以下清单执行：第一，确保源站IP不在任何公开渠道泄露；第二，在防火墙层只放行CDN回源IP段；第三，启用CDN的回源鉴权或自建Token验证机制；第四，Token绑定时间戳和请求参数，有效期控制在300秒以内；第五，密钥安全存储并定期轮换；第六，做好降级和告警机制；第七，定期进行穿透测试，模拟攻击者绕过CDN直接打源站的场景，验证整套防护是否有效。

流量穿透是DDoS攻击中最具威胁的手段之一，因为它直接绕过了你花大价钱部署的CDN防护。回源验证Token不是银弹，但它是目前性价比最高、实施难度最低的防穿透方案之一。把这套机制做扎实，你的源站安全等级至少提升一个档次。

DDoS防护源站隐藏与回源验证Token防流量穿透

服务指南

帮助中心