多域名业务DDoS防护实战：攻击面失控、方案选型与应急响应全解析

大概在去年这个时候我们多域名业务的线上服务就吃过一次DDoS攻击的亏。当时被打的不是主站而是一个几乎没人管的活动老域名——流量不大也没接入任何防护。攻击流量一路冲过来因为这个老域名和主站共用同一套DNS解析和源站集群结果整个业务的可用性在几分钟内全部崩掉。那次之后我才彻底想明白一件事多域名业务的DDoS安全防护和单域名是完全两种玩法。这篇文章就把我这两年的实战经验拆开讲一讲希望能帮到正在为多域名体系做防护方案的同行。1. 多域名业务在DDoS攻击下的真实困局1.1 为什么域名一多攻击面就失控单域名架构下你的防护逻辑很简单把所有流量引到一个入口在这个入口上做清洗源站IP藏好基本就稳了。但多域名业务不是这样。首先域名数量直接拉高了暴露面。一个业务线可能有主域名、活动域名、短链域名、CDN回源域名、内部管理域名甚至还有几百个子域名。攻击者不需要打穿你花了最多钱保护的主站他们只需要找一个防护薄弱的旁系域名。这个域名只要和主站共享DNS、共享源站、共享回源链路那就是一个天然的跳板。其次不同域名的归属可能分散在不同部门、不同云账号下。我见过不少企业市场部注册个域名自己接了个便宜CDN技术部的核心业务挂了高防两边各自为政。你以为自己在做安全防护实际上防护是碎片化的攻击者随便挑一个最弱的点打进来所有域名的业务都会被影响。还有一个容易被忽略的点很多域名的二级、三级子域名是自动泛解析的。攻击者不用知道你有哪些子域名直接对泛解析域名随机拼接前缀就能形成大量的请求流量。这种流量特征非常像正常用户访问而且分散到不同子域后任何一个子域的监控指标都看不出异常但从整体看已经在缓慢消耗你的带宽和连接数。1.2 被攻击时最容易出现的连锁反应多域名最怕的不是某一个域名挂掉而是一条链路被击穿后引发的雪崩。以我们那次事故为例攻击流量主要打的是老域名的DNS查询和443端口连接。因为老域名的DNS记录和主站在同一个云解析服务上高并发的DNS请求直接拖垮了云解析商的整体响应。主站域名虽然没被攻击但用户访问时DNS解析超时一样进不来。这就是典型的“共享基础设施”灾难你防住了目标防不住目标周边的公共组件。再往下走如果攻击流量穿透到了源站那就更麻烦。多域名共用的源站集群通常是一组负载均衡后面的几台机器CPU、连接数、带宽任何一个指标被打满所有域名全部遭殃。更恶心的是CC攻击不会直接打爆带宽它是慢吞吞地把你的连接池和PHP-FPM进程耗完等你发现时半数的机器已经进入了不可用状态。另外还有一个容易被忽视的连锁反应是防护策略的误伤。多域名业务里不同域名的用户群体、访问特征差异很大有的域名是API接口请求频率极高有的是官网流量平稳还有的是下载站瞬时流量很大。如果你把一套限速策略套到所有域名上极大概率会把正常用户给拦了。我见过一个客户因为统一设置了IP并发数限制导致办公网出口的所有人访问他们家API全部失败企业客户投诉电话被打爆。1.3 多域名防护的三大认知误区误区一只给主域名投入防护。攻击者不蠢他们知道你主域名有高防所以会挑你的子域名、活动域名、老域名下手。防护的投入必须覆盖所有互联网可达的域名至少要把入口层统一管理起来。误区二把“接入CDN”等同于“接入DDoS防护”。CDN本身有缓存加速能力对静态资源攻击有一定缓解作用但面对大流量DDoS或者针对源站的CC攻击CDN只靠缓存是扛不住的。CDN是防护链条里的一环不是全部。误区三不做容量规划等攻击来了再说。多域名业务的特点就是流量分散、特征复杂如果没有平时的容量基数和流量画像攻击发生时你连“现在的流量是正常值的几倍”都判断不出来更谈不上判断是否已经进入攻击状态。2. 防护架构选型自建、云清洗还是混合方案2.1 三条主流路线分别适合什么场景目前多域名业务做DDoS防护主流方案无非是三种自建防护、云清洗DDoS高防IP/高防包、混合方案。自建防护是买硬件清洗设备比如流量清洗器、防火墙部署在机房入口骨干线路出现攻击流量时通过BGP引流把流量导向清洗设备过滤后再回注。这条路线的最大优势是可控性强策略、调度、数据全在自己手里不依赖第三方。但缺点也很现实——成本极高。一台像样的清洗设备动辄几十万起步还要养专门的网络团队去维护BGP调度、路由策略、设备版本升级。除非你的业务体量已经大到每月带宽成本百万级否则自建很难回本。云清洗是目前中小型多域名业务的主流选择。本质上是把流量调度到安全厂商的清洗机房由对方的Anycast网络帮你把攻击流量分散到多个节点清洗完再把干净流量回源。你不需要自购设备按防御峰值或者按实际清洗流量付费弹性很好。缺点在于回源链路和配置黑盒出了问题你得依赖厂商的响应速度。混合方案则是“自建云清洗”的组合通常是大企业的选择。平时流量走本地机房只有检测到攻击流量达到阈值时才自动把流量切到云端清洗。这样可以兼顾成本与防护能力但对团队水平要求很高你要懂BGP、懂策略路由、懂自动化调度还要能接受切换时的短暂抖动。方案成本防护上限运维要求适用规模自建防护高硬件人力取决于设备性能高超大流量场景云清洗中按量付费厂商网络决定通常T级别低中小型多域名业务混合方案高本地云端联动上限最高很高大型企业、金融、政务2.2 我的选型判断框架我自己的选型逻辑比较看重四个方面清洗能力、调度延迟、协议兼容性、运维成本。清洗能力看两个数字带宽清洗能力bps和包清洗能力pps。很多厂商宣传口径是“T级别防护”但你要问清楚T是带宽的T还是包速率的T。对小包攻击来说pps比bps更重要很多设备带宽没打满但每秒上亿个包就把设备的CPU打死机了。选型时至少要保证云清洗节点的pps能力是你日常峰值的几十倍以上。调度延迟决定了你遇到攻击时多长时间能开始清洗。DNS引流几秒钟到几十秒BGP引流大流量时可能需要几十秒。这个延迟不适合在攻击发生后做决策所以调度最好是自动的厂商的检测系统发现流量超过阈值自动把域名切到清洗节点。尽量选能做到秒级切换的。协议兼容性主要看你对TCP/UDP/WebSocket/QUIC的支持要求。很多老牌高防对TCP协议支持很稳但对UDP和WebSocket的清洗策略比较弱甚至误杀正常的长连接流量。如果你的业务有实时音视频、游戏对战类场景这些一定要在选型时问清楚不能只看宣传材料标称的“全协议支持”。运维成本不只是钱还有人力。多域名业务的常态是域名新上线、域名下线、流量模型变化、加白名单、调策略。如果防护平台没有开放的API你没法把域名接入、策略调整这些动作自动化每个操作都要去后台点半天那这个方案再便宜我都不推荐。2.3 多域名统一接入的设计思路选型确定之后接下来要做的是把多个域名统一到一个防护入口上而不是每个域名各接一套。常规做法是设计一张“域名-防护策略”映射表由统一的接入层网关接收所有域名的DNS解析再根据域名把流量分发到对应的防护策略组。具体到云高防产品里通常体现为“高防IP域名绑定防护策略集”的组合。你可以把一个高防IP绑定多个域名每个域名关联独立的防护策略。这样有几个非常实际的好处第一源站只需要对这一个高防IP做白名单回源源站入口管理成本大幅下降第二攻击者无论打哪个域名流量都会被汇聚到同一个清洗节点清洗效果更集中第三日常策略变更只需要在接入层批量配置不需要逐个域名改源站。统一接入之后别忘了一个细节域名和证书的关系。多域名业务最常见的证书方案是泛域名证书或者SAN证书。高防节点在终止SSL时需要支持导入这些证书否则你的HTTPS流量会在清洗节点被断开。我当时在选型清单里专门加了一条是否支持泛域名证书和多证书绑定。有些厂商表面说支持实际操作时只允许一对一绑定多域名一多就非常痛苦。3. 流量调度与源站隔离把主动权握在自己手里3.1 用DNS智能解析做第一道分流安全防护的前提是不影响正常业务。DNS智能解析在这里的作用就是让不同来源、不同状态的用户走到不同的路径上。我当时的设计是分三个流量池默认池走高防IP静态资源池走CDN内网管理池只允许白名单IP访问。域名解析在DNS层按来源地域、运营商、访问类型做策略分发。比如境外用户统一解析到CDN节点境内用户解析到高防IPAPI域名直接解析到高防IP但开启更严格的WAF规则静态资源域名解析到CDN由CDN回源时再走高防IP。这样做的价值在于攻击流量虽然也会解析到高防IP但经过清洗后进入源站的比例就低了很多而正常的静态资源请求根本不会打到源站直接CDN就缓存返回了源站的负载压力会小很多。多域名业务里至少40%的流量是静态资源这个分流做得好你的源站规模可以比单域名业务小很多还不容易挂。DNS调度还有一个隐藏好处你可以通过修改TTL来加速切换。平时把TTL设成300秒甚至600秒遇到攻击切换解析时把TTL临时调低到30秒能在几分钟内让大部分客户端重新解析到新的防护节点。这个技巧在应急时非常管用。3.2 源站IP隐藏的关键细节源站IP一旦暴露清洗得再干净也没用。攻击者会绕过高防直接打你的源站IP这时候你的高防IP形同虚设。多域名业务的源站IP隐藏比单域名要多做几步。单域名你只需要保证回源地址是高防IP段。多域名呢你有多个域名的回源请求会打到同一组源站其中一个域名配置失误源站IP就可能泄露。我踩过一次实实在在的坑某个域名回源时WAF把真实的客户端IP放在了X-Forwarded-For头里源站收到请求后记录日志日志平台恰好又是公网可达的结果攻击者通过日志接口反查到了源站IP。这件事之后我们做了三条整改第一回源链路上所有代理节点高防、CDN、WAF都必须把源IP头替换成清洗节点自身的IP不允许透传真实源IP给源站。第二源站安全组只放行高防回源IP段和办公网运维IP其余IP一律拒绝。第三对公网可访问的日志、监控、管理后台做强制内网访问。还有一个很容易漏掉的点SSL证书的证书透明度日志CT Log不会暴露源站IP但如果你在证书里绑定了源站域名或者IP的SAN那就等于把源站信息写在证书里供人查询。发证书时建议只绑定被防护的域名不要顺手绑定源站的内部域名。3.3 跨可用区冗余与自动切换单点的高防IP在极端情况下也可能被打到上限。多域名业务因为域名众多流量分布广更容易同时遭遇多路攻击。这决定了防护架构必须做冗余。我之前给一个电商客户做方案时要求至少选两个不同城市的高防节点分别对应不同运营商。DNS层面做两个A记录配合健康检查实现自动切换某个高防节点IP的可用性探针连续失败三次就自动把解析流量切到另一个节点。这个机制看起来简单但有个关键参数要调好——健康检查的目标不能是源站本身而应该是清洗节点。因为清洗节点挂了不代表源站挂反之亦然。如果健康检查直接探源站会出现源站正常但清洗节点异常时DNS错误地把流量切走的情况反而把“可用”变成“不可用”。另外高防IP背后的源站最好也做跨可用区部署。源站至少分布在两个机房当某个机房的网络被大流量冲击到拥塞时负载均衡能通过健康检查自动把流量切到另一机房。这里有一个容易被忽略的点切换时不要忘了重新触发各域名的DNS解析缓存。很多客户端和运营商Local DNS会缓存旧的解析结果你源站切了但用户可能还在访问旧源站地址结果一样是打不开。我的做法是切换源站IP时同时把域名TTL临时调到最低并尽可能提前一天发布公告引导用户关掉本地DNS缓存重试。4. 缓存层与访问控制的纵深防御设计4.1 CDN/WAF在防护链路中扮演的角色很多人的理解是“上了高防就不需要CDN了”这不对。高防解决的是网络层和传输层的大流量清洗CDN解决的是应用层的流量卸载和加速WAF解决的是七层攻击的语义过滤。三者是叠加关系不是替代关系。以我们的架构为例流量入口经过高防清洗后按域名规则分流静态资源和图片走CDN节点由CDN缓存直接返回动态API请求进WAF做协议合规检查只有确实需要回源的请求才打到源站。这样的好处极其明显——源站收到的请求量可能是攻击流量的几十分之一防护压力大减。具体数据上我们的官网域名曾经被打过一次七层CC攻击。攻击特征很明显固定User-Agent、固定请求路径、高频滚动刷新。WAF在入口直接拦截了95%的请求序列剩余的5%因为共享来源IP或特征不典型进入了源站但源站的限速模块也把它们挡在了业务逻辑之外。整个攻击过程源站的最大QPS只比平时高了一倍完全在承受范围内。4.2 多维度的流量特征过滤七层防护的精髓在于别看单条请求要看请求集合的模式。多域名业务用户行为复杂单IP限速很容易误伤所以更靠谱的做法是多维度组合过滤。我总结了一套比较实用的过滤优先级地域维度如果业务本身只服务国内用户可以直接在高防策略里把境外IP段的请求降权或拒绝。大部分攻击肉鸡分布全球境外IP请求占比异常高本身就是攻击信号。协议栈指纹合法浏览器的TLS握手指纹JA3/JA4和HTTP头部顺序相对固定。攻击工具通常不具备浏览器特征可以利用这个指纹库做动态封禁。频率维度不要只看请求次数要看“单位时间内新建连接数与活跃连接数的比值”。正常用户的浏览器会复用连接Keep-Alive而攻击脚本常常是每请求新建一个连接。这个比值一高基本可以断定是CC攻击。行为路径正常用户访问网站时有页面引用链、停留时长、滚动行为攻击者通常是固定路径直刷。WAF可以配置“三步校验”首次请求返回JS挑战通过后种Cookie带Cookie的请求才能访问业务接口业务接口对Cookie时效做强制校验。这套组合下来我们几乎没有出现过一次因为防护策略误杀正常用户的事故。唯一需要注意的就是在初始配置阶段要开启“观察模式”把告警日志打开跑一周观察有多少正常流量被标记为风险。如果没有明显的误杀再切换到拦截模式。4.3 限速与挑战机制的最终兜底就算前面全被绕过源站侧也一定要有兜底策略。这个兜底不是追求拦截所有攻击流量而是保证源站在极端流量下不死。推荐在源站前置的负载均衡上做三层限速单IP连接速率限制默认按业务特性定阈值比如普通官网50次/分钟API网关300次/分钟。单IP并发连接数限制通常设置为100左右超过直接丢弃新连接。源站整体并发限制给源站设置一个最大并发连接数超过后新请求排队或快速失败返回503。三层限速的意义在于即使高防清洗漏进来一部分流量也不会直接打垮源站。排队机制还可以保证正常用户的请求在攻击期间依然能被处理只是响应慢一些而不是整个服务不可用。另外在“快速失败”的响应里建议返回带有Retry-After头的状态码这样正常用户的客户端会主动等待重试而不是反复刷新加重压力。5. 监控告警与应急响应的实操链路5.1 多域名场景下的告警指标配置单域名业务的告警很简单带宽、QPS、CPU、连接数差不多够了。多域名业务必须要按域名的维度拆分监控和告警。我建议至少给每个域名建立四类指标视图第一类是网络层指标入向带宽、出向带宽、PPS。这是判断是否遭遇大流量攻击的首要依据。注意这里不能只看“总带宽”要看重点域名和整体流量的分布。多域名业务有个问题某个冷门域名被打的时候总带宽可能还没达到告警阈值。所以一定要给每个域名设置独立的带宽环比告警比如5分钟内的带宽如果达到了过去7天同时段的5倍就触发告警。第二类是四层指标SYN报文比例、TCP新建连接数、UDP流量占比。SYN比例超过70%且新建连接数突增基本就是SYN Flood。UDP流量占比异常升高则要考虑UDP反射放大攻击。这些指标要比带宽指标敏感得多通常攻击开始后30秒内就能发现。第三类是七层指标HTTP请求错误率、请求延迟P95、WAF拦截量。请求延迟P95突然翻倍可能说明源站已经被边缘流量拖累WAF拦截量骤增说明正在被扫描或探测。第四类是业务指标登录成功率、订单创建成功率、核心API调用量。这些指标最能反映“用户体感”也是我判断要不要提前切走流量、调配资源的核心依据。5.2 攻击发现后的灰度封禁流程很多人喜欢“发现问题就全面封禁”这是最省事也最容易出事的方式。正确的流程应该是灰度收紧。我们的标准响应流程是这样的第一步先确认攻击目标的集中度。看被攻击的域名占总请求量的比例、攻击来源IP是否集中在少数几段如果目标明确直接对目标域名做高防清洗级别提升同时开启WAF严格模式。第二步封禁来源。先封境外可疑IP段再封已知IDC机房IP段肉鸡大多在IDC最后封“高频异常IP”单IP请求速率超过正常用户均值100倍的。每一步封禁后观察5-10分钟确认误伤情况再决定是否继续加码。第三步如果攻击还没停结合业务情况考虑启用验证码或JS挑战机制对所有访问到业务核心路径的用户强制做验证。这个方法对真人几乎无感但对自动化攻击是毁灭性打击。第四步最后的兜底仍然是提升到“快速失败”模式当源站并发连接数达到危险阈值时对新请求直接返回503。虽然这会影响部分用户访问但能保住源站不被打死为后续恢复争取时间。5.3 攻击结束后的复盘清单攻击结束不等于安全响应结束复盘才是真正提升防护水平的关键。复盘时至少要回答这几个问题攻击从哪个域名进来的为什么这个域名没有更早触发告警攻击流量与正常情况下需要分得的资源差距是多少攻击持续期间我们的调度和清洗策略哪个环节出现了延迟下次如何把延迟降到最低我会把每次攻击的样本流量抓包保存下来整理成“攻击特征库”配置到WAF和高防策略里。同时更新每个域名的流量基线和告警阈值——因为每次攻击后正常流量也会增加基线不更新下次告警就会更迟钝。这里还有一个团队协作层面的经验多域名业务的响应不是安全团队一个人的事。必须有业务运维在场因为封禁策略可能误伤业务必须有网络工程师在场因为可能要协调运营商做黑洞或流量调度必须有客服值班人员因为可能会有用户集中反馈访问异常。响应流程里提前约定好这些岗位的对接人攻击发生时才不会乱。6. 多域名防护里最容易忽略的暗坑6.1 证书更新引发的高防回源断连很多人不知道大部分高防的清洗节点在转发HTTPS流量时会做“单向认证”或“双向认证”。如果你的证书更新了但高防节点上还是旧证书那攻击流量会被清洗正常请求却也会因为TLS握手失败全被断开。我曾经在一次统一的泛域名证书轮换中漏掉了一个商城域名的旧证书在高防节点上的部署结果商城域名静默故障了整整两天直到有用户反馈下单失败才发现。后来我把证书更新做成了强制流程证书更新前在所有高防、CDN、WAF节点同步新证书更新后自动跑一遍各域名的HTTPS探测确认握手正常才算完成。6.2 泛解析带来的防护漂移泛解析域名在方便运维的同时也直接让“按域名配置防护策略”这件事变得尴尬。攻击者可以对泛解析下的任意子域名发起请求每个子域名的请求量都不算高但如果几千个子域名同时被扫总流量就非常可观。对这种情况只靠单域名策略是防不过来的。我们选择在WAF层级做兜底所有泛解析子域名的请求必须经过严格的主机头校验只放行在业务白名单里的具体子域名其他一律拒绝。对于“主机头不存在”的请求直接返回403极大减少了泛解析漂移带来的无效流量。6.3 回源透传真实源IP的坑前面讲源站隐藏时提过这里再展开多说一句。很多WAF/CDN产品在默认配置下会把客户端IP放在X-Forwarded-For或者CF-Connecting-IP头里这本来是为了让源站做业务分析。但在多域名体系里一旦某个域名的日志平台接入公网访问入口攻击者就能顺着这些头信息找到源站的真实IP。所以我的建议是两套方案二选一要么在回源节点强制把所有自定义请求头剥离源站只看到清洗节点的IP要么在源站的日志平台前面加一层严格的内网访问控制并且日志平台不要绑定公网IP只做内网解析。千万别觉得自己“业务量小没人会盯上”被盯上往往就是一瞬间的事。6.4 预算有限时的优先级排序不是所有团队都有充足的预算做全套防护。如果你就三五个人服务器只有几台该怎么排序我的建议是“保主链路降暴露面”。优先给核心业务域名接入DDoS高防和WAF源站只对高防回源IP开放把泛解析关闭非必需的DNS记录全部下线减小暴露面静态资源全部切到CDN别让静态请求打源站。等业务有盈利空间了再逐步把边缘域名纳入统一防护。还有一个省钱的小技巧很多云厂商的高防是按“域名保底带宽”来计费的。你可以把多个域名共享一个高防IP和保底套餐虽然清洗能力共用但总价比单独买要低30%-40%。前提是你的源站和DNS都做了统一接入设计否则共享IP也管理不起来。6.5 与运营商、安全厂商的协同机制DDoS防护里最被动的一种情况是攻击流量大到运营商为了保住大局直接把你整个IP段做了黑洞路由——流量全部丢掉你的服务彻底不可用。这个级别的事故只靠云厂商的清洗是不够的。所以如果你的业务达到了一定规模一定要提前和IDC、运营商建立联系确认攻击流量超过多少时他们会采取什么动作。同时把你自己的云清洗厂商的应急联系方式做成置顶卡片分发给团队。遇事不要指望在线工单、也不要把任何希望寄托在“自动升级到专家团队”上直接电话联系安全值班工程师告诉他们攻击特征和需要调整的接口是最快的止血路径。我在多域名防护这条路上踩过的坑远比写出来的多。每次遇到问题我都会重新审视一遍“接入层-调度层-清洗层-源站层”这条链路看看还有哪个环节不够自动、不够快、不够稳。防护这件事没有一劳永逸攻击手法会变、业务形态会变、流量画像也会变只有把“监控-响应-复盘-更新”这套循环跑起来才能真正护住这一堆域名背后的生意。如果你也在做多域名业务的防护建议先别急着买最贵的高防套餐先把你的域名清单、流量基线和源站暴露面梳理清楚。防护的起点从来不是设备而是你知道自己的家底到底有什么、在哪里。