源站IP泄露后的切换与CDN重新接入流程

源站IP泄露，意味着攻击者绕过了CDN节点，直接拿到了后端服务器的真实地址。这时候，所谓的DDoS防护、Web应用防火墙在攻击者眼里形同虚设，他们可以直接对源站发起精准打击，比如大流量拥塞、CC攻击，甚至是针对特定端口和服务的漏洞扫描与利用。一旦源站被精准打击，业务中断只是时间问题。所以，处理源站IP泄露不是简单的“换个IP”就完事了，它是一个需要严谨流程的运维和安全操作，核心目标是在切换新IP的同时，确保新IP不再被轻易获取，并重新接入CDN防护体系。

发现泄露后，第一步不是立刻去换IP，而是先做流量牵引和访问控制。如果源站服务器还绑定了公网IP，并且部分业务流量或管理流量直接暴露，需要立即在服务器防火墙（如iptables、firewalld或云平台安全组）上设置严格的入站规则。只允许CDN节点的回源IP地址段访问80和443端口，拒绝其他所有公网IP的访问请求。这一步能暂时缓解直接攻击旧IP的压力。同时，检查服务器上是否有其他服务（如SSH的22端口、数据库的3306端口）直接暴露在公网，如果有，立刻将其监听地址改为内网IP或通过VPN/堡垒机进行访问，彻底切断旧IP上一切非必要的公网暴露面。

旧IP已经全网皆知，继续使用它无论做多少防护都有被再次精准打击的风险。最彻底的方式是申请一个全新的公网IP。如果是云服务器，通常可以直接在控制台为实例绑定一个新的弹性公网IP（EIP），然后解绑旧的。如果是物理服务器，可能需要联系运营商或机房重新分配。这个新IP是后续所有操作的基础，务必确保它从未被使用过，也没有在任何公开的DNS记录、配置文件或日志中出现过。拿到新IP后，不要立刻将其绑定到生产服务上，先在内部进行连通性测试。

新IP绑定后，服务器端的配置是防止二次泄露的第一道防线。Web服务器（Nginx、Apache等）必须修改监听配置，将所有虚拟主机的默认监听改为仅响应CDN回源请求。更严格的做法是，配置Web服务器仅响应包含特定主机头的请求，丢弃所有直接通过IP地址发起的访问。例如在Nginx中，可以创建一个默认server块，直接返回444（关闭连接）或返回一个空页面，而真正提供服务的server块则明确指定server_name为你的域名。这样，即使有人扫描你的新IP，也无法获取任何有效网站内容，更无法通过页面中的资源链接或错误信息推断出你的域名。

# Nginx 配置示例：拒绝直接IP访问
server {
    listen 80 default_server;
    listen 443 ssl default_server;
    server_name _;
    # 直接返回444，关闭连接，不暴露任何信息
    return 444;
}

# 仅允许通过域名访问的正确站点配置
server {
    listen 80;
    server_name www.yourdomain.com yourdomain.com;
    # ... 其他正常配置
}

同时，彻底检查应用层代码。确保所有内部跳转、资源链接（图片、CSS、JS）都使用相对路径或明确的CDN域名，绝对不能在HTML源码中写死新源站IP。检查所有对外提供的API接口文档、SDK示例代码，清除任何可能包含旧IP的硬编码。邮件服务、FTP服务等容易忽略的边缘服务，也要逐一排查，确保它们的通信链路不会泄露源站信息。

这是最关键的一步，不是简单的把域名解析指向CDN就完事。登录你的CDN服务商控制台，找到源站配置部分。将源站地址从旧IP修改为新申请的内网IP或新公网IP。强烈建议使用“回源SNI”和“回源Host”配置。回源SNI确保CDN节点与你的源站建立TLS握手时，发送的是你的域名，而不是IP；回源Host则确保CDN在HTTP请求头中携带正确的Host字段，与Web服务器配置的server_name严格匹配。这能有效防止因证书不匹配或Host头错误导致的内容泄露或访问异常。

接下来，配置CDN层面的访问控制。开启“IP访问限频”、“CC防护”和“WAF”功能，并根据业务模型设置合理的阈值。最关键的一步是配置“CDN回源鉴权”。不同的CDN厂商叫法不同，但原理一致：在CDN节点发起回源请求时，会在请求头或URL参数中携带一个动态生成的加密Token，你的源站Web服务器需要验证这个Token的合法性，只有验证通过才响应内容，否则直接拒绝。这相当于在源站大门上又加了一把只有CDN知道的锁，即使新IP再次泄露，攻击者也无法直接通过IP获取任何内容。

# Nginx 配合CDN回源鉴权的简单验证示例（需根据CDN厂商具体规则调整）
location / {
    # 假设CDN在回源时添加了一个名为 X-Auth-Token 的请求头
    if ($http_x_auth_token != "your_secret_token_value") {
        return 403;
    }
    # ... 正常处理请求
}

配置完成后，务必在本地修改hosts文件，将你的域名指向CDN提供的CNAME地址，进行全链路测试。测试所有核心页面、登录接口、文件上传下载功能，确保CDN缓存命中、回源、动态请求加速等所有环节都正常工作，且响应头中包含了正确的CDN标识。

在确认新源站和CDN配合无误后，进行DNS切换。将域名的A记录或CNAME记录指向CDN服务商提供的加速域名。切记，不要使用A记录直接指向源站新IP，这会让CDN形同虚设。在切换前，将DNS的TTL值调低（如60秒），以便在出现问题时能快速回滚。切换完成后，全面检查域名的所有DNS记录，包括A、AAAA、CNAME、MX、TXT等，清除所有直接指向旧IP或泄露IP的记录。特别是TXT记录中的SPF、DKIM等邮件相关记录，有时会不小心包含源站IP。同时，检查域名的DNS历史记录查询站点，虽然无法删除历史，但确保当前没有任何有效记录指向旧IP。

IP泄露往往不是无缘无故的，找到并堵住泄露源头才能避免重蹈覆辙。常见的泄露途径包括：网页源码中的注释、错误页面堆栈信息、phpinfo()等探针文件、站点/subdomain的SSL证书透明度日志（Certificate Transparency Logs）、Github等代码仓库的提交历史、网站反向代理配置错误、邮件头信息等。你需要进行一次全面的安全审计。检查SSL证书，如果你的源站直接对外签发过SSL证书，其指纹会记录在CT日志中，攻击者可以通过工具搜索到。更换新IP后，务必为源站申请新的证书，或者直接使用CDN提供的边缘证书，源站与CDN之间使用自签名证书或CDN签发的专用回源证书。扫描所有代码仓库，删除包含旧IP、密钥等敏感信息的提交历史。关闭服务器上所有不必要的端口和服务，尤其是数据库、缓存服务（Redis、Memcached）的管理端口，它们绝不能对公网开放。

亡羊补牢之后，需要建立长效的监控机制。在CDN上设置流量监控和告警，重点关注回源流量是否有异常突增，这可能意味着新IP再次被泄露并遭到攻击。定期使用外部工具进行网络空间测绘扫描，搜索你的域名、关键字，检查是否有新IP被关联。在服务器上部署入侵检测系统（IDS），监控异常登录和敏感文件访问。最关键的一点是，建立一套安全开发运维规范（DevSecOps），将IP等敏感信息的管理纳入流程，从代码编写、提交、构建到部署的每个环节，都加入自动化扫描，防止内部人员无意识地再次泄露。

整个流程下来，核心思想就是：旧IP彻底废弃并清理痕迹，新IP深度隐藏并仅对CDN开放，CDN配置强鉴权与防护策略，最后通过全链路审计和监控确保长治久安。这不是一个简单的三步走，而是一个循环往复、持续改进的安全运营过程。