源站IP泄露后的应急处理与修复步骤：5步止血顺序
源站IP泄露后的应急处理与修复步骤，先用第0步判定真假泄露，再按“收口→定级→换IP→固定暴露面→验证”五步止血：先确认是不是真泄露，再立即用访问控制收口（比换IP快），然后评估是否降级限流，满足判据才换IP，最后用回源鉴权固定暴露面并验证外部已无法直连。本文只讲事故中的动作顺序、生效快慢与验证信号，不盘点泄漏点——事前自查可参考站内如何防止源站真实IP暴露。2026年6月，CISA发布BOD 26-04实施指南，要求组织收敛公网暴露面并将防护与访问控制前移至网络边缘，以缩短应急处置窗口。同年8月，Google Cloud Media CDN更新源站架构指南，明确多级缓存与Origin Shield可聚合回源请求、防止惊群效应。这两份官方文档共同支撑一个原则：源站IP泄露后，边缘侧的动作永远比源站侧更快生效。第0步判定：是源站IP真泄露，还是回源配置把流量引回了源站先别急着换IP。大量“疑似泄露”其实是回源配置问题——CDN回源时把流量引回了源站，让日志里看起来像被直连。误判的代价是白白中断一次业务。用四个信号区分：源站访问日志中的客户端IP是否全部落在CDN回源IP段内？如果是，大概率是回源路径问题，不是泄露。连接是否带回源标识头（如自定义Header）？缺标识的请求才是外部直连。目标端口和Host字段是否与CDN配置一致？不一致说明有独立探测。DNS历史解析、证书透明日志里是否出现过源站地址？出现过才算证据确凿的泄露。如果四个信号都指向“没有外部IP出现”，那问题在回源配置，换个IP只会让业务白断一次。第1步收口访问控制：只放行回源IP段，比换IP先生效无论是否真泄露，第一步不是换IP，而是先在源站安全组/防火墙做白名单收口。规则类变更不需要业务重新解析，生效快、回滚也快，先锁定来源能立刻缩窄暴露面。按这个顺序收口：先限来源：只放行CDN回源IP段和运维跳板机IP。再限端口：只保留80/443等业务必需端口，其余全部关闭。最后处理其他出网服务：邮件、监控、对象存储回调等，逐一收敛。关键区别在于：在源站防火墙逐条补规则，和让边缘完成连接终止与访问判定，后者更快生效且更隐蔽。CISA在BOD 26-04中强调的“把访问控制前移到边缘”，正是为了缩短这个窗口。配合回源白名单，源站只接受边缘回源IP段的连接，其余来源在源站入口即被拒绝；把连接终止与访问判定前移到边缘后，这类请求还没到源站就已被处理。第2步定级：区分“还能扛”和“已经打满”，决定是否降级与限流收口之后，马上评估源站当前承受的压力，决定要不要主动降级。看五个观测项：观测项判断依据对应动作带宽/PPS是否接近出口上限启用边缘清洗或限流连接数/连接池占用是否耗尽限制新连接或排队CPU/后端队列是否持续高位降级非核心路径错误率/延迟分位是否明显劣化优先保障核心接口行为特征慢速攻击、低频滥用走七层行为清洗，不能只看带宽必须把四层带宽压制和七层行为清洗分开验收。慢速攻击和低频接口滥用不触发带宽阈值，却能悄悄耗尽连接池和CPU。如果只盯着带宽，可能误判为“还能扛”，实际已濒临打满。若需要明确降级与限流的动作细节，可参考 DDoS应急响应。第3步换IP：什么情况下才换、换之前必须先做完哪几件事满足以下任一判据才换IP：收口后仍被直连，说明白名单没能覆盖所有暴露路径；源站地址已出现在公开渠道（如证书透明日志、被动DNS、历史解析记录）；存在无法用白名单解决的暴露面（如第三方回调必须直接访问源站）。换IP之前，必须先做完四件事：确认新地址不在任何历史解析记录里，避免换了个“旧IP”。同步更新CDN回源配置和源站白名单，让新IP立即生效。可参考无感接入高防CDN配置流程。准备回滚方案：保留旧IP一段时间，出问题能切回。评估业务中断窗口：换IP涉及DNS解析和连接重建，有些长连接业务会中断。恢复时长取决于云厂商和业务架构，不同场景差异很大，这里不给统一承诺。但在源站IP泄露后的应急处理与修复步骤里，换IP是最后手段，不是第一动作。第4步固定暴露面：回源鉴权与分层回源怎么配合换完IP，必须把暴露面固定在边缘，否则泄露会反复发生。回源鉴权：源站对不带自定义Header或证书校验的连接直接拒绝。这样即使地址被知道，没有凭据也进不来。分层回源（Origin Shield）：在边缘汇聚区域回源请求，避免突发流量穿透源站产生惊群效应。Google Cloud Media CDN的架构指南指出，多级缓存能聚合回源流量，同时把回源来源收敛成可白名单化的固定集合。两者是互补关系：回源鉴权解决“进不来”，分层回源解决“扛得住”。只做鉴权，流量照样能穿透到源站；只做分层，地址被知道后仍可能被直连。配合使用，相当于给源站上了双保险。第5步验证泄露已切断：直连测试、日志比对与持续观测项“配置成功”不等于“外部已探测不到”，这是两个独立验收点。验证清单：绕过CDN直接请求源站地址，应被拒绝或超时。源站日志中非回源IP段的请求数应归零。带缺失鉴权头的请求应被源站拒绝。DNS历史解析、证书透明日志、被动DNS中不再出现源站地址。保留一段跨越业务高峰的观测期，持续看日志与解析记录，直到非回源IP段请求连续为零且被动DNS无新记录，而不是配置完就收工。如果第1、2项没过，说明泄露没切断；第3项没过，说明鉴权没生效；第4项没过，说明地址还在公开渠道扩散，需要扩展收敛范围。换完IP仍被直连的复盘顺序：还有哪些服务在替源站说话换完IP后仍被直连，别急着怀疑CDN配置，先按顺序排查这些“替源站说话”的出网面：邮件与告警发信：很多服务器会用源站IP直接发信，IP出现在邮件头里。独立子域与旧解析记录：历史DNS记录没清干净，或被子域泄露。回源以外的管理端口：SSH、数据库端口直接暴露在公网。对象存储与第三方回调：回调URL里可能带源站IP。监控探针与SDK出网：监控系统主动探测源站，暴露地址。镜像仓库与容器构建流量：CI/CD过程中源站IP出现在日志里。每一项都要收敛：邮件走第三方发送服务、子域与旧记录清理、管理端口走堡垒机、回调走边缘函数、探针改走代理。详细的事前排查方法可参考站内如何防止源站真实IP暴露。边缘承载与源站保护的分工：RockCloud 在这几步的落位方式在“收口访问控制”和“固定暴露面”两步，RockCloud高防CDN的落位方式很直接：回源IP段白名单：把源站安全组只放行边缘节点回源IP段，外部请求在边缘就被拦下。回源鉴权：给回源请求加自定义Header，源站只认带凭据的请求，地址泄露也进不来。源站保护：所有回源流量先经过边缘清洗，源站只对CDN可见。这样做的差别在于：源站防火墙逐条补规则，要手工维护、容易漏；边缘做连接终止和访问判定，规则统一、生效快。换IP后，边缘承载业务流量，源站保持隐蔽，这是职责的自然分工。需要评估回源收口与回源鉴权如何落到现有架构，可联系RockCloud技术支持一起过一遍配置。可打印的源站IP泄露处置清单步骤动作负责人角色生效特征验证信号回滚方式第0步判定真泄露还是回源配置问题值班运维日志与配置比对清晰外部IP未出现无第1步源站安全组白名单收口安全工程师非回源IP请求被拒日志中非回源IP归零删除白名单规则第2步定级并决定降级限流SRE连接池与CPU回落错误率下降关闭限流第3步按判据换IP并同步配置运维+安全新IP生效、DNS更新直连被拒切回旧IP第4步回源鉴权与分层回源运维缺鉴权头请求被拒鉴权日志无异常关闭鉴权第5步验证与持续观测值班+安全直连超时、日志干净被动DNS无新记录重新开放观测这份源站IP泄露后的应急处理与修复步骤清单可以直接打印，事故中照做。也建议把清单固化为值班SOP，并在下一次演练中验证一次直连拦截与日志归零。常见问题源站IP泄露了要不要先停机？大多数情况不需要先停机。先做访问控制收口，把非回源IP段全部拒绝，业务可以继续跑。只有当攻击已打满源站资源、收口无法生效，或者源站服务本身被攻破时才考虑停机。停机是最后手段，会直接造成业务中断。回源白名单配了还是被直连怎么排查？先检查安全组是否真的只放行了白名单IP，很多情况是规则没删干净。再看是不是有旁路绕过，比如其他服务（邮件、监控）直接出网暴露了源站IP。还要确认CDN回源IP段是否准确，有些厂商的IP段会变动。最后看日志，确认直连请求的来源IP和端口，判断是外部扫描还是内部服务泄露。更换源站IP的正确顺序是什么？先更新CDN回源配置，再改源站白名单，最后才切换DNS。顺序不能乱：如果先切DNS，旧IP还没被CDN接管，流量会直接打到源站。换完IP后，要等DNS缓存过期，再用直连测试和日志比对验证。整个过程要保留旧IP一段时间，作为回滚方案。只做回源鉴权不换IP够不够？不够。回源鉴权能挡住不带凭据的直连，但攻击者如果拿到鉴权头（比如通过日志泄露），照样能进。换IP是切断源头，回源鉴权是加固防线，两者要配合。如果地址已经在公开渠道扩散，必须先换IP再配鉴权。怎么确认源站IP是不是真的泄露了？看三个地方：一是CDN源站日志，如果出现非回源IP段的请求，大概率真泄露；二是证书透明日志，搜一下域名是否出现过源站IP；三是被动DNS，用在线工具查历史解析记录。如果都没有，那可能是回源配置问题，别急着换IP。接入高防CDN后源站IP是否就不可能再被发现？不是绝对的。高防CDN能大幅增加探测难度，但如果源站还有其他出网路径（邮件、监控、第三方回调），IP照样会暴露。回源白名单和鉴权能限制直接访问，但无法保证100%隐藏。所以还要持续监控解析记录和日志，定期做暴露面检查。