1. 从被打到黑洞说起为什么超大流量攻击必须靠清洗而不是硬扛我最早接触DDoS防护时遇到过一个特别典型的场景某客户的业务凌晨三点突然收到告警入向流量从平时的2Gbps瞬间飙到180Gbps机房交换机直接被打到CPU满载BGP会话都开始不稳定了。当时的第一反应是赶紧把被攻击的IP拉进黑洞路由——确实是立刻见效攻击流量进不来了但正常用户也全被挡在外面业务直接就断了。那次之后我才彻底想明白一个问题DDoS防护的本质不是把流量挡在门外而是把攻击流量和正常流量分开。所谓流量黑洞只是把门前的大路挖断谁也别想过河而精准清洗是在洪流里架一座桥只让真正的人和货通过。高防CDN能扛住超大流量DDoS攻击核心靠的正是后者。这篇文章我想把自己在流量黑洞、精准清洗、高防CDN配置与选型方面的实操经验系统梳理一遍。内容适合三类人看一是刚接手公司安全运维、需要快速了解抗D方案的技术同学二是业务经常被打、正在纠结买高防还是自建清洗的架构师三是对DDoS防护原理好奇、想搞清楚高防CDN到底防住了什么的安全爱好者。为了把这件事说透我先给一个简单的类比。假如你开了一家实体店突然有一群人堵在门口不但拦住所有客人还往店里扔石头。流量黑洞的做法是直接关门歇业外面的人进不来里面的人也出不去。精准清洗的做法是保安从人群中识别出哪些是闹事的哪些是真正想买东西的然后把闹事的架走让正常客人继续进店。高防CDN做的事情就是训练这一批能识别闹事者的保安并且保证在闹事者非常非常多的极端情况下保安依然能维持秩序。所以我的核心观点很明确流量黑洞永远是最后手段精准清洗才是高防CDN的灵魂。在超大流量DDoS攻击面前如果你只有硬扛和黑洞这两个选项说明你的防护架构还停留在有防御的层面远没到会防御的层面。2. 高防CDN扛住超大流量攻击的底层逻辑分层清洗架构很多人把高防CDN理解成一个大带宽的流量漏斗以为只要带宽够大流量再多也能扛住。这个理解只对了一半。带宽确实是基础但带宽再大也扛不住无限流量真正让高防CDN能在超大流量攻击下存活并保障业务的是它的分层清洗架构。2.1 四层清洗先过滤掉不讲道理的流量网络层和传输层的攻击比如SYN Flood、UDP Flood、ACK Flood特征是报文本身异常。攻击者伪造源IP、疯狂发送半连接请求目的就是耗尽服务器的TCP连接表和带宽。这层清洗靠的是细粒度检测与代理机制。以SYN Flood为例高防CDN接入流量后先由清洗设备充当TCP代理SYN Proxy代替源站和客户端完成三次握手。客户端发SYN清洗节点回应SYN-ACK如果客户端是真实的会回ACK完成握手如果客户端是伪造IP它永远无法完成握手清洗节点直接丢弃。这样一来真正到达源站的TCP连接都是已经完成握手的合法连接握手风暴就被挡在了源站之外。我在实际调参时发现SYN Proxy有个关键参数cookiesSYN Cookie当SYN速率超过阈值时自动启用效果立竿见影。同时对于UDP Flood这类无连接攻击清洗节点会做UDP报文校验和深度包检测识别出NTP/SSDP反射放大报文后直接丢弃。这层防护的效率高因为判断规则简单、计算开销小适合在超大流量入口处先做一道粗筛。2.2 七层清洗过滤掉伪装得很像人的流量四层清洗挡不住HTTP Flood和CC攻击因为这类攻击用的是合法HTTP报文报文层面看不出任何异常。攻击者模拟真实浏览器的行为不断请求你的URL耗尽应用服务器的CPU和数据库连接。七层清洗在这里发挥作用核心是验证客户端是不是真人第一道是JS挑战。清洗节点给请求返回一段JavaScript正常浏览器会自动执行并携带正确Cookie继续访问攻击工具通常不执行JS自然被拦下。第二道是Cookie合法性校验。确认请求头里的Cookie是不是清洗节点下发的、是否在有效期内。第三道是浏览器指纹。通过canvas、WebGL、字体、屏幕分辨率等维度生成指纹识别出没有真实浏览器环境的请求。第四道是行为分析。比如同一IP在几毫秒内连续请求多个页面或者请求频率远高于人类操作极限都会被判定为异常。七层清洗的代价是计算资源和用户体验损耗。JS挑战会多一次会话开销对极低延时的API业务会有影响。所以我在配置时从不建议全站开启JS挑战而是只对高频访问、异常来源、疑似爬虫的请求触发。后面第4节我会详细讲具体参数怎么调。2.3 为什么需要一个先分光、再清洗、后回注的物理架构这个Field级的知识点很多文章没有讲透但恰恰是自建清洗系统和高防CDN架构差异的核心。商业高防CDN在全球有很多边缘节点流量先就近接入节点通过骨干网调度到清洗中心。清洗完之后干净流量通过专线或公网回注到源站。这个链路是流量入口—清洗池—回注通道三段式。自建清洗系统也可以参考这套思路。物理上在机房入口把流量分光分出一路给清洗设备做检测另一路作为主路当检测到攻击时通过BGP将受攻击IP的路由引到清洗设备清洗后再把干净流量回注到源站。这个架构的优点是主路不串联清洗设备设备故障时流量还能走原路不会造成单点故障。但自建这套方案成本高、运维复杂。对绝大多数团队来说更合理的是采用高防CDN服务把清洗中心这层黑盒交给专业厂商自己专注于回源链路和源站安全。我一直强调一个判断标准清理能力是否是分布式的、边缘节点到清洗中心的调度是否自动完成。如果只是一个大带宽入口加一台清洗设备那流量一旦超过设备处理能力整个方案就是摆设。3. 流量黑洞与精准清洗的核心区别何时该Drop何时该Mitigation黑洞和精准清洗是两种截然不同的处置策略很多刚接触抗D的同行容易混淆。流量黑洞通常指在被攻击IP的路由上配置丢弃规则对端直连或运营商侧黑洞把所有入向流量全部丢掉。优点是反应快、不消耗自身清洗资源缺点是完全放弃业务可用性。精准清洗则是在链路中串入清洗设备通过多维度识别把攻击流量丢弃、只放行正常流量。优点是业务不受影响缺点是清洗设备本身可能成为瓶颈且需要不断调优规则。什么场景用黑洞什么场景必须做清洗我给一个实用判断矩阵场景建议策略原因攻击流量超过防护带宽上限如1Tbps黑洞硬扛没有意义先把网络层保下来攻击流量较大但未超上限且业务必须可用清洗业务连续性优先清洗设备能扛住攻击来源单一、目标单一清洗源IP封禁封禁成本低能快速止血攻击流量中正常流量占比极低低于1%黑洞清洗投入产出比过低直接换节点或IP业务本身允许低可用性如内部系统黑洞可接受不影响核心收入和用户电商、支付、在线服务必须清洗业务中断的直接损失远大于清洗成本需要特别强调的是黑洞不一定是全局黑洞。现在很多高防CDN支持精细化的黑洞策略可以对某个源IP段做黑洞对某个协议做黑洞比如丢弃所有UDP也可以对某个端口做黑洞比如非80/443的业务端口只保住主业务端口。这种局部黑洞思路很实用能实现近似清洗的效果同时大幅降低清洗设备的压力。我在第4节会详细讲配置实践这里先给一个核心原则凡是能保住业务的场景尽量不用全局黑洞但到了峰值上限全局黑洞是必要的止损手段。这个问题不能含糊扛得住就是扛得住扛不住就要主动断臂求生千万不能抱着也许再撑一下就好了的心态最后把整个机房都拖垮。4. 高防CDN选型与配置调优我踩过的坑和验证过的参数市面上高防CDN产品功能差别不大但实际效果差异可能非常大。我把选型和配置拆成两个部分来讲这部分内容全部来自我自己的实战验证。4.1 选型阶段必须确认的五件事第一确认防护峰值是总带宽还是单节点带宽。有些产品标称1Tbps防护实际分配到每个边缘节点可能只有20Gbps。攻击流量如果集中打到一个节点单节点带宽被打满流量还是会回源防护形同虚设。选型时一定要确认总清洗能力 单节点清洗能力这两个数字。第二确认四层清洗和七层清洗是否都在防护范围内。有些低价高防产品只做四层防护HTTP Flood打过来基本不设防或者只有简单的频率限制。如果你的业务以动态API为主必须确认七层清洗能力。第三确认回源方式是公网回源、内网专线回源还是支持GRE隧道封装回源。公网回源最大的问题是源站IP暴露攻击者可以通过历史DNS解析记录挖出源站IP绕过CDN直接打源站。我在实际处理过好几起源站IP被挖出后被打挂的事件原因都是回源方式太简单。第四确认清洗节点和源站的调度逻辑。攻击发生后流量怎么从边缘节点调度到清洗中心是自动BGP引流还是需要人工切换如果是人工切换5分钟还是10分钟这个数字直接决定你的业务中断时长。第五确认控制台和API本身是否有防护能力。这个点很容易被忽略。攻击者如果通过注册账号进入你的高防CDN控制台或者通过API把你的防护策略改掉那你的防御体系就直接崩了。所以控制台必须启用强认证和MFAAPI要设置访问控制。4.2 关键参数调节我常用的几组配置逻辑这里以一套典型的高防CDN配置为例给出参数设置思路和理由。第一组连接层阈值。单IP并发连接数普通业务建议10-50。正常用户单IP发起超过50个并发TCP连接的情况极少除非是下载站、视频站需要按业务特点放宽。单IP新建连接速率SYN Rate建议1000/s以下触发源认证。超过这个值大概率是攻击流量清洗节点会自动启用SYN Proxy。SYN Cookie开启阈值当SYN包速率达到总连接数阈值的80%时启用防止握手队列被打满。第二组应用层频率限制。单IP每分钟请求数动态页面建议30-60次。如果业务是API接口建议更严格10次/分钟。URL维度限流对搜索、库存查询这类高QPS但低价值的接口设置独立阈值如100次/分钟超了就JS挑战对登录、支付这类高价值接口阈值可以放宽到200次/分钟但必须配合验证码。频率限制的惩罚机制当IP触发频率限制后不要直接403而是插入JS挑战让正常用户能继续访问攻击者则无法自动通过。这种软惩罚比硬拦截体验好得多。第三组会话和指纹策略。Cookie校验开关开启后清洗节点会校验Cookie时间戳和签名未携带合法Cookie的请求直接丢弃。浏览器指纹采集建议开启但只用于风险评分不要直接拦截否则会误伤老浏览器用户。JS挑战开关默认关闭只在触发频率限制或风险评分较高时开启。第四组地域与IP信誉策略。地域白名单如果业务明确只面向国内用户可以开启地域白名单直接丢弃海外流量。这能大幅降低清洗压力但会误伤海外真实用户建议按业务场景决定。IP信誉库对接威胁情报平台把已知恶意IP预置进黑名单清洗节点可以先丢弃这部分流量减少计算开销。运营商线路如果你的业务用户集中在移动端而又经常收到大量来自某个运营商线路的攻击流量可以考虑对该运营商线路单独设置策略比如限速或加大验证强度。第五组回源链路保护。回源端口不要使用源站默认的80/443端口改成自定义端口比如8443、9443并在源站防火墙限制只允许清洗节点IP访问该端口。这样即使攻击者挖到源站IP也没法直接对源站的Web服务发起攻击。回源带宽限速在清洗节点侧设置回源请求速率上限防止攻击流量穿透清洗节点后对源站形成二次冲击。回源节点白名单只在源站防火墙放行清洗节点的回源IP段其他来源一概拒绝。4.3 一份值得参考的配置流程下面是一套我常用的高防CDN接入和配置顺序添加防护域名绑定源站IP选择四层七层清洗模式。配置SSL证书开启HTTPS过滤否则加密流量洗不了攻击藏在TLS里很麻烦。根据业务类型设置基础频率限制和JS挑战策略。接入WAF规则开启SQL注入、XSS、命令注入等基础防护DDoS攻击经常伴随Web入侵尝试别只看流量。配置地域策略和IP信誉黑名单。做一场小规模模拟攻击测试验证清洗链路是否正常观察回源链路是否稳定。建立监控看板把入向流量、清洗丢弃率、回源QPS、源站负载四个指标放在同一张图上日常就盯着看。每季度复查一次配置基线根据业务增长调整阈值并更新IP信誉库规则。5. 一次420Gbps混合攻击的完整处置复盘理论讲再多不如一次实战复盘。说一个我印象很深的案例某在线教育平台业务高峰时段被混合攻击SYN Flood HTTP Flood 少量NTP反射放大攻击峰值约420Gbps持续两小时。目标是登录和支付接口显然攻击者知道这两块最致命。第一阶段发现与定位。攻击从下午14:00开始监控发现入向流量10分钟内从基线值飙升到100Gbps以上。我们立刻确认目标域名是登录接口然后执行严格模式切换全站开启JS挑战SYN Proxy强制启用频率限制阈值减半。第二阶段区域封禁。Flow数据一统计攻击源大量集中在境外IP和少数国内中继。因为平台本身的用户99%在国内我们果断启用了境外IP过滤规则。这一步快速把清洗压力降下来了但代价是一部分海外用户的访问瞬时中断。这在攻击高峰期是可以接受的取舍但我们在规则上加了TTL2小时后自动恢复防止攻击结束后忘记恢复导致业务异常。第三阶段回源链路隔离。我们同时把回源方式从公网切到内网专线并在源站防火墙做了清洗节点IP白名单。这一步最关键因为攻击者一旦挖到源站IP直接把源站打挂前面的清洗做得再好都白费。所有回源请求都通过清洗节点的固定IP段出来源站只认这些IP安全性提升非常明显。第四阶段动态调整清洗规则。攻击持续期间攻击者发现登录接口被守住了在15:10左右转移目标去打搜索接口和查询类接口。我们通过监控发现搜索接口QPS异常迅速把该接口纳入七层清洗范围5分钟内上线了新策略搜索接口恢复稳定。最终业务在攻击结束后正常恢复。整个过程我们只手动封了12个高置信度攻击源IP其余全部交给清洗算法自动处理。实战下来几点体会基线数据是所有判断的前提。如果平时没有积累正常QPS是多少、正常入向带宽是多少的基线攻击到来时无法判断流量是否异常更无法判断清洗策略是否生效。不要试图手动封禁攻击源IP。分布式攻击的源IP成千上万手动封禁既慢又无效应该依靠清洗设备的自动算法。人工只处理极少数高置信度的源IP。临时封禁策略一律带TTL。自动恢复机制一定要有否则攻击停止后你手动加的临时策略会变成慢性毒药。6. 没有预算买高防CDN怎么办自建防护的三层思路与成本权衡不是所有团队都买得起高防CDN。如果预算有限或者数据敏感、不允许流量经过第三方节点自建防御是必须考虑的路。自建DDoS防御我从三个层次来讲。第一层网络层自建。基础手段是BGP黑洞路由RTBH把被攻击IP在路由器上宣告为黑洞快速丢弃所有流量。更高级的是自建流量清洗设备通过分光器、BGP引流和动态规则实现自动化清洗。这一层的难点在于清洗算法需要根据攻击流量持续迭代设备处理能力会随着业务增长升级运维成本相当高。第二层系统层自建。主机上的优化和防护内核参数调优如增大syn_backlog、调整tcp_tw_reuse等、iptables规则限速限制每秒SYN包数、每分钟连接数、nginx层限流limit_req模块做IP和URL维度频率控制、fail2ban自动封禁。这些都是浅防御对付小流量攻击和蹭网爬虫够用但面对真正的超大流量攻击几乎无效。第三层架构层自建。通过多活架构、多地部署、智能调度实现分散风险。比如把业务同时部署在华北、华东、华南三个机房通过DNS或全局负载均衡分发流量攻击者想把三个机房全打挂成本会大幅上升。这是很多头部公司采用的自建思路——不依赖单点的高防能力而依赖分布式架构让攻击者很难形成集中压力。成本方面我给出一个粗略的参考部署方式预估成本适用对象基础安防产品按带宽计费每年数千到数万小型网站低防护需求高防IP/高防CDN每年数万到数十万中小型业务需要快速交付自建清洗设备软件授权硬件几十万起步加维护人力大型企业自主可控需求混合方案高防自建取决于比例弹性较大中大型业务既要效果又要可控我的态度一直是优先混合方案。把静态资源、冷数据、非核心业务放在高防CDN上把核心业务放在自建的高防节点上通过全局负载均衡在两个体系间调度流量。一部分流量被CDN分散和清洗一部分流量由自建节点处理既享受了高防CDN的快速接入和低维护成本又保住了对核心系统和核心数据的掌控力。7. 关于学校遭遇多少流量会被打挂这个热门问题的三点澄清最后说一个网上经常出现的热门疑问和本文核心主题高度关联对于一个学校要发送多少DDoS攻击才能摧毁网站必须再次强调发起DDoS攻击是违法行为任何亲测实验都是不该存在的本文只从防御和安全科普角度来谈。这个问题的前提本身就存在逻辑漏洞。摧毁一个网站需要多少流量从来不是一个固定的数字而是取决于目标的防护能力。一个裸奔的网站可能几十Gbps就扛不住了一个接入了高防CDN的网站可能需要数百Gbps甚至Tbps级别这两者的摧毁阈值天差地别。对学校网站这类目标现实情况是防护预算普遍有限、业务连续性要求相对宽松、IP和域名公开可查所以确实容易成为攻击目标。但破解这个问题的关键恰恰不是攻击要多大流量而是防御方应该怎么低成本地建设防护能力学校官网、教务系统、招生系统这几类系统的价值不同防护等级应当区分对待。招生季的教务系统挂了是大事普通展示页挂了几小时可能没人在意。哪怕预算再紧张也应该为关键系统接入高防CDN或高防IP并开启WAF基础规则。这类服务按年订阅费用并不夸张但能挡住绝大多数中小规模攻击。数据备份和应急恢复预案比任何防护设备都重要。DDoS的最终目的是让业务不可用只要你恢复得快损失就可控。不要试图依赖黑洞策略防住所有攻击。只有在确认业务短期不可用可以接受时才把黑洞作为最后手段。这其实回到了本文最开始的观点流量黑洞和高防CDN解决的是两个完全不同层次的问题。流量黑洞回答的是怎么快速止损高防CDN回答的是怎么在攻击中继续做生意。对任何追求业务连续性的组织答案都应该是后者。如果让我给一句总结性的建议那就是别把DDoS防护做成一场数字攀比防护峰值再高也不如一套能精准识别正常流量、能快速调度清洗资源、能持续验证效果的系统来得实在。真正扛住超大流量攻击的不是某个单一产品而是架构 策略 人这个完整体系。