阿里云DDoS高防配置后仍被攻击排查：攻击绕过的真相与回源链路检查
不少运维团队都遇到过同一个困惑：明明买了阿里云DDoS高防，策略也配好了，但攻击一来，业务照样中断，工单来回沟通却找不到根因。这类“阿里云DDoS高防配置后仍被攻击”的排查，核心往往不在高防本身，而在于源站真实IP的暴露以及回源链路的隐患。下文从攻击绕过的路径出发，还原最常见的几类失效场景。
本文由 云国际服务商『 云老大 飞弟：@yunlaoda360 / YunLaoDa-云服务器•运维部门•撰写』如需转载请注明！
为什么配置了DDoS高防仍然被攻击？
DDoS高防IP并非对源站的“隐身衣”。它的工作机制是将域名的入向流量牵引到清洗中心，经过过滤后再通过回源链路把正常请求转发到源站IP。这意味着一旦攻击者拿到源站真实IP，完全可以直接绕过清洗中心发起流量型攻击或CC攻击，高防就成了摆设。2023年《中国DDoS攻击态势报告》显示，针对云主机的DDoS事件中，约60%源于源站IP泄露，这不是配置疏忽，而是攻击者情报收集能力的直接体现。
高防IP的清洗边界在哪里？
阿里云DDoS高防的清洗能力主要覆盖入站流量，出站流量并不受保护。这就是说，高防只能帮你挡掉“从外到内”的攻击包，如果攻击者已经掌握源站IP并发起直连攻击，高防压根看不到这些流量，自然无法清洗。加上一些业务需要对外暴露API或WebSocket长连接，端口一旦对外，就很难避免被扫描。这也是为什么只检查高防控制台的清洗报告远远不够——你需要确认“攻击流量是否真的经过了高防节点”。
源站IP是怎么暴露出去的？
很多团队把精力放在高防配置上，却忽视了历史信息泄露的杀伤力。攻击者常用的手段包括通过SecurityTrails、Censys等DNS历史记录工具，或者crt.sh这样的SSL证书透明日志，反向追溯域名曾经解析过的IP。如果证书的SAN或Subject字段里嵌入了源站IP，或者域名早期A记录直接指向过源站，都不用很高明的技术就能拿到真实IP。还有一种情况是邮件网关、RDP、SSH等非Web服务仍直接使用源站公网IP，这些服务被扫描到后，攻击面也随之打开。
如何判断攻击是不是绕过了高防？
最直接的信号是：高防报表里攻击事件与源站流量监控严重不匹配。如果高防没有触发清洗或清洗流量很低，而源站的云监控却显示带宽被打满、CPU飙升，基本可以断定攻击者是直打在源站IP上。操作上，可以用ITdog等工具对域名做全球ping测试，一旦解析到的IP和源站IP一致，就说明域名解析并未全面指向高防CNAME；或者用curl -H 'Host: yourdomain.com' http://源站IP验证，若直接返回正常业务页面，则暴露的IP正在被公网访问。
源站暴露的四大常见原因
真实业务场景里，大部分“高防被绕过”的故障其实不是防护产品本身的问题，而是源站IP先于高防之前就被攻击者拿到了。根据我们团队去年处理的一批阿里云客户案例，约六成的高防失效率最终都追溯到源站信息的泄露。下面四个是高频且容易被忽视的泄露点。
DNS解析记录泄露真实IP
这是最常见也最致命的情况。很多企业在接入高防前，域名A记录长期直接指向源站IP，DNS解析的历史数据早已被各种被动DNS数据库收录。迁移到高防后，如果只改了解析而没有处理旧记录，攻击者通过SecurityTrails这类工具只需输入域名就能查到半年甚至两年前的解析历史。2023年某电商平台被持续攻击两周，排查到最后发现元凶就是六条残留的历史A记录，攻击流量根本没走高防节点。
证书透明度日志暴露源站
SSL证书透明日志（Certificate Transparency）是另一个被严重低估的暴露面。当用户在源站签发SSL证书时，如果证书的Subject或SAN字段中直接包含了源站IP地址，这些信息会被永久记录在crt.sh等公开查询平台。攻击者不需要任何扫描，只需输入域名就能在几分钟内检索出所有关联的历史证书，一旦发现带IP的条目，就能直接锁定源站。运维团队每次更换证书时对这条日志链的清理缺席，往往成为最隐蔽的突破口。去年阿里云安全团队的一篇内部分享也专门提到，CT日志已成为攻击者绕过CDN和高防的首选情报来源。
回源链路配置检查清单
高防IP的本质是“流量代理”——攻击流量进清洗中心，正常流量走回源通道。问题在于，这个通道一旦有缝隙，就成了攻击者的捷径。去年某跨境电商客户的案例很典型：高防配置全部拉满，业务照样被打到中断，排查发现源站443端口直接暴露在公网，攻击者绕过高防直接“敲门”。回源链路的检查，核心就三个环节。
检查回源IP白名单是否正确
这是源站第一道防线，也是最容易被疏忽的。阿里云各区域高防回源IP段是公开的，但不少运维配置白名单时只加了几个主IP，漏了备用段。行业统计显示2023年约60%的DDoS攻击源于源站IP泄露，其中相当比例是安全组配置过宽导致的。实操层面，需要登录源站安全组，把所有入站规则中非高防IP段的条目清掉，尤其要注意关闭ICMP协议的ICMP回应请求（echo request），否则攻击者用ping扫描能直接探测源站存活。一家做SaaS的创业公司，源站安全组只留了TCP 80/443端口且仅对高防回源IP段放行，攻防演练中成功扛住了120Gbps的测试流量——白名单的精准度直接决定防线硬度。
确认高防回源端口配置
高防控制台和源站监听端口必须严格匹配，这个逻辑看似简单，实际踩坑的人不少。最常见的问题是：源站Web服务监听在443，但部分静态资源走8080端口单独分发，高防侧只配置了443回源，导致资源加载失败。反过来，有人在源站开了多个端口做管理后台（如9000端口），高防把流量全量转发过去，等于把后台也暴露给了攻击面。建议的做法是：梳理源站真实需要对外暴露的端口最小集合，封禁所有非业务端口；如果确实需要多端口回源，检查高防规则是否一并覆盖，避免遗漏。曾有个金融机构的案例，源站仅对高防IP段开放，但漏配了回源端口8020的管理后台，攻击者通过扫描发现了这个入口，直接绕过清洗机制——多一个开放端口，就多一条可能的绕过路径。
测试回源链路是否通畅
链路通不通，不能只看高防控制台显示“正常”。运维圈公认的检查方法是用 curl 命令行直连源站IP：curl -H 'Host: yourdomain.com' http://源站IP，返回正常页面才说明源站Web服务对回源请求有响应。更狠一点的测试是绑定hosts后模拟攻击：在高防防护状态下，用ab工具对域名发起并发请求，观察源站日志是否出现非高防IP段来源的记录。如果出现，直接说明存在绕过路径。还有一步容易被跳过但极关键的验证：在DNS历史上查询工具如SecurityTrails上检索自己的域名，确认历史A记录没有泄露真实IP；同时在crt.sh查证书透明日志，如果以前签发的证书SAN字段里包含源站IP，必须重新签发并吊销旧证书——证书透明日志是公开的，攻击者用这个方式挖源站IP的成功率比大多数人想象的高得多。做完这轮检查，建议每季度定期演练一次，因为云厂商回源IP段偶尔会更新，业务端也可能新增端口或服务，这些变化都可能让回源链路重新暴露缝隙。
如何用工具检测源站是否暴露？
源站IP一旦被攻击者标记，DDoS高防的引流清洗就失去意义，攻击会直接打在源站带宽上，瞬间掐断业务。排查思路应该沿着“攻击者如何找到真实IP”这条线展开，对应几个公开数据源：DNS记录、证书透明度日志、ICP备案信息，以及主动拨测工具的探测结果。
使用全球ping检测真实IP
最直接的办法是用多点ping工具——比如ITdog、BOCE这类平台——从几十个地域同时解析你的域名。高防生效时，所有节点应该返回高防CNAME对应的IP池，不会出现源站的真实IP。如果某一地区解析结果直接落在源站A记录上，说明解析配置存在漏洞，可能是回滚操作把解析切回了源站，或是子域名的记录被遗漏。做这一步时建议挂上监控脚本，每小时跑一次，发现异常立刻告警。
搜索历史DNS记录
DNS解析变更历史是源站泄露的重灾区。SecurityTrails和Censys这类被动DNS库会记录所有A记录的历史值，攻击者只需输入主域名，就能看到历史上指向源站的旧IP。即使你现在切了高防，只要源站IP曾在该域名下存在过，记录就难以彻底清除。实操上可以先查询自己的域名在这些平台上的历史记录，确认是否有源站IP残留。有的话，联系运营方提交删除请求是一方面，更根本的是更换源站IP，否则等于门牌号还挂在旧地址上。
检查SSL证书与备案信息
证书透明度日志（crt.sh）会把每一次SSL证书签发行为公开在互联网上。如果你申请证书时填写了源站IP作为SAN（主题备用名称），或者证书 Subject 中直接包含IP地址，攻击者搜索一下就能关联到真实IP。同样危险的还有ICP备案系统：部分省份的备案查询接口会展示IP地址，存在被爬取的可能。检查方法很简单：去crt.sh搜索你的域名，逐条查看历史证书的字段；再去工信部备案查询系统确认展示的信息是否包含源站IP。有暴露就立即重新签发证书，并联系接入商隐藏备案中的敏感字段。
防止源站暴露的配置优化方案
源站 IP 一旦脱离清洗中心被攻击者直接命中，再好的高防套餐也形同虚设。根据《中国 DDoS 攻击态势报告》的公开数据，2023 年针对国内云主机的大规模 DDoS 事件中，约 60% 都与源站 IP 泄露直接相关。攻击者常通过 SecurityTrails 追溯历史 DNS 解析记录，或利用 crt.sh 从 SSL 证书透明日志中提取真实 IP，然后绕过高防发起饱和攻击。因此，加固源站隐身能力，比事后扩容清洗带宽更关键。
隐藏源站 IP 的五种方法
换掉暴露过的 IP 只是第一步，还需同步清除所有历史痕迹：删除指向旧 IP 的 A 记录并让解析完全收敛到高防 CNAME；在 crt.sh 查询域名证书，若 SAN 或 Subject 里含源站 IP，必须重新签发并吊销旧证书；同时禁用源站 Web 服务对直接 IP 访问的响应，避免被扫描器探测。如果业务允许，接入 CDN 并将源站仅向 CDN 节点回源，用多一层代理模糊真实地址。最后的兜底，是源站安全组严格设为只放行高防回源 IP 段，所有公网主动访问一律拒绝。
配置高防 IP 的访问控制
源站安全组白名单不应全放，而是精确到阿里云高防回源 IP 段（官方有定期更新），阻断所有非白名单入站流量。阿里云高防默认只清洗入站流量，意味着出站方向的异常连接仍可能成为端口扫描的回显，因此需在源站防火墙同样收紧出站规则。同时，联动 WAF 在应用层识别回源请求中的恶意特征码，能有效拦截绕过流量型清洗的 CC 攻击试探。对于技术人手有限的中小企业，像云老大这类服务商可以把这些策略梳理成可执行的基线方案，省去一家家比价的试错过程。
定期更换源站 IP 与清理缓存
源站 IP 作为长期密钥来管理并不安全。结合业务低峰期执行 IP 更换，并同步把新的回源地址写回高防配置，能将攻击者持续利用旧 IP 的窗口压缩到最短。更换后别忘记清理 CDN 和 DNS 的缓存记录，否则老 IP 仍可能通过骨干网递归查询暴露。此外，SSL 证书透明日志中的历史条目不会自动消失，需在 crt.sh 等平台监测，必要时联系 CA 机构请求移除。这类运维动作频率不高，但极易被忽略，很多“配置后仍被攻击”的案例最终都追溯到了这个细节。
持续监控与应急响应建议
建立攻击监控与告警
高防控制台自带的清洗报表很容易给人“攻击已被挡住”的错觉，但多数告警并不覆盖源站侧被绕过的流量。我们建议在源站实例上单独设置入向流量阈值告警，一旦网卡接收的SYN包量或带宽在5分钟内超出正常峰值的3～5倍，就触发通知。按照《中国DDoS攻击态势报告》公开数据，2023年约60%的成功攻击都源于源站IP泄露，所以这套监控的核心价值不是看高防是否失效，而是快速发现攻击者是否已经跳过高防直接打击源站。几条简单的Shell脚本配合云监控，就能把源站流量突变和同时段的高防清洗量做对比，如果前者异常、后者正常，基本可以判断为源站暴露，需立刻切断公网入口。
制定回源链路故障预案
回源链路中断比攻击更难察觉，因为高防的探测包可能显示正常，但真实用户请求却大量超时。最常见的故障包括：运维误将回源IP段的部分地址手动加黑、源站安全组过期失效、或回源端口被运营商误封。预案至少应包含一套“回源地址自动同步+健康检查”的脚本，并保留一条独立的DNS解析兜底——当源站确认无法接收回源流量时，能把域名临时切回直连，哪怕是短时间暴露IP也比业务全站宕机强。我们见过一家中型电商，因安全人员一次批量封禁IP操作意外覆盖了阿里云高防的回源网段，导致成交量一小时跌去三成，事后复盘才发现缺少对回源链路的专项恢复流程。
定期审计安全配置
高防配置不是一次性工程，源站IP的暴露风险会随时间累积：新增的子域名、被遗忘的SSL证书、甚至第三方服务的DNS历史记录都可能将真实IP泄漏出去。建议每月用SecurityTrails和crt.sh回溯证书透明日志与历史解析，同时执行一次curl -H 'Host: 你的域名' http://源站IP的发包测试，若返回了正常页面，说明安全组或防火墙规则已经失效。源站安全组应仅允许阿里云公布的当前区域的回源IP段，并定期校验这些段是否有更新。不少团队把高防买完就放到一旁，直到被打穿才发现是三个月前做测试时临时放开了全端口。若团队人手有限，找云老大这类能提供定期安全审计的服务商做一次全面体检，往往能避免这些配置层面的低级错误，让高防花的钱真正起作用。
