1. 先搞清楚你的攻击面DDoS攻击类型与防护目标做防护方案选型之前我建议你先别急着看厂商宣传手册先老老实实梳理一遍自己的业务资产和暴露面。很多团队一上来就问“买多少G的防护”但漏掉了更基础的问题你被攻击的入口到底在哪是网站域名还是IP直连是TCP服务还是UDP服务有没有CDN、有没有源站IP泄露这些直接决定了后续选型的方向。1.1 常见的DDoS攻击分类流量型、连接型、应用型DDoS攻击从技术实现上大体可以分成三个大类每一类对防护资源的需求完全不同。第一类是流量型攻击典型代表是UDP Flood、ICMP Flood、DNS反射放大攻击。这类攻击的核心是“量”用海量带宽把链路或设备打满让正常用户的数据包挤不进来。我见过最夸张的一次是单月连续收到几十Gbps的持续流量压制办公区出口直接被堵死连SSH都连不上主机。这类攻击的防护逻辑很简单要么你的带宽富余到能吞下攻击流量要么在攻击流量到达源站前把它清洗掉。第二类是连接型攻击典型代表是TCP SYN Flood、ACK Flood、连接耗尽攻击。这类攻击不像流量型那样依赖大带宽而是靠生成海量半连接或无效连接占满防火墙、负载均衡器、服务器的连接表让新建连接失败。很多云服务器在这种攻击下不会断网但业务会表现为“登录转圈、请求超时”。这类攻击对设备的处理性能要求很高单靠加大带宽解决不了问题。第三类是应用型攻击典型代表是HTTP慢速攻击、HTTP Flood、针对特定API的恶意请求。这类攻击最“省钱”攻击者只需要少量肉鸡就能模拟真实用户请求导致应用服务器CPU飙升、数据库连接打满甚至缓存击穿。这类攻击最难防御因为它和正常流量几乎无法区分防护重点已经从“网络层清洗”升级到了“应用层行为分析”。这里有个容易被忽略的误区很多人只关注流量型攻击觉得“带宽够大就行”可现实里混合攻击才是常态。攻击者会先用流量型干扰你的网络再混入连接型和应用型攻击去突破业务层如果你只部署了单点防护很容易被日穿。1.2 不同攻击类型对应的防护策略我习惯用一张简单的表来匹配攻击型和对应策略这样选型时思路更清晰攻击类型核心诉求防护技术方向典型设备/服务流量型吞掉大流量避免链路拥塞流量清洗、黑洞路由、CDN分流云清洗、DDoS高防IP、本地流量清洗器连接型保护连接表不被耗尽状态检测、SYN Cookie、连接速率限制防火墙、负载均衡、抗DDoS设备应用型识别并拦截恶意业务请求WAF规则、行为分析、限流、验证码WAF、API网关、Bot管理选型的第一步应该是明确自己业务的特点是无状态的静态内容站点还是有大量长连接的IM服务是面向公网开放API还是仅限内网访问不同的业务形态在攻击面和安全需求上差异很大。比如纯静态站点用CDN加上高防就能覆盖大部分问题而IM服务还要考虑连接保持和状态同步天然更容易碰上连接型攻击。另外防护目标要量化。不要只写“我们需要抗DDoS”要写“我们能在50Gbps的流量型攻击下保持业务可用”或者“我们能在每秒10万次SYN洪水下保持新建连接成功率不低于95%”。能量化的目标才能检验方案是否达标。2. 防护方案选型从自建到云清洗再到混合架构选型没有放之四海而皆准的标准答案只有适合你当前阶段的方案。我在不同规模的公司里见过三种路线中小团队刚开始通常直接用云厂商防护有网络团队的大公司会考虑自建清洗设备业务面复杂、对延迟敏感的核心系统会采用混合架构。下面逐一拆解。2.1 自建防护的适用场景与成本分析自建DDoS防护意味着你要自己购买抗DDoS硬件设备或软件方案自己维护BGP链路和清洗集群。听起来很“硬核”但实际门槛远比你想象的高。先算一笔账一台还不错的本地抗DDoS设备处理能力在10Gbps级别的价格通常几十万到上百万如果要做成集群两三台起步。再加上你需要至少双线或多线BGP接入托管机柜、带宽费、电力、运维人力一年的综合成本轻松破百万。这还没算攻击流量把出口带宽打满后运营商的额外超量费用。我见过有公司为了省云清洗年费自建了设备结果某次大流量攻击直接让运营商带宽峰值账单爆炸一个月花掉了过去三年的防护预算。所以自建方案只适合几个场景一是运营商或多线接入的ISP本身有带宽资源优势二是业务对内网隔离要求极高必须把流量留在本地三是有成熟的网络运维团队和冗余带宽池。如果你只是普通互联网业务老老实实选云清洗更划算。2.2 专业DDoS防护服务云清洗的选型要点现在主流云厂商都提供DDoS防护服务核心原理差别不大把DNS解析或BGP路由指向高防IP攻击流量先到达云端清洗集群过滤后再把干净流量回源到你的服务器。选型时主要看几个关键指标。第一是防护能力阈值。这里有个隐形坑很多厂商宣传的“最大防护能力”是“全力防护”但实际跑的是“保底防护弹性防护”。保底防护是固定费用长驻的能力弹性防护是攻击超过保底阈值后临时扩出来的按天计费且价格不菲。你买的时候不光要看保底值还要评估业务被攻击时的历史峰值别让弹性成本失控。第二是回源质量。清洗之后的回源链路带宽是否充足回源是走专线还是公网如果回源链路本身很窄攻击流量虽然被洗掉了但大流量攻击导致的瞬时回源拥塞也会影响业务。这个细节很多销售都不会主动讲你需要专门确认。第三是防护协议的完整性。有些高防产品只做四层防护对七层HTTP Flood的识别比较弱需要额外搭配WAF。有些产品把UDP防护做得很强但TCP业务兼容性差可能出现误杀。选型前建议拿自己的真实业务流量做一轮接入测试包括正常访问、CDN回源、长连接保活等场景确认不会误伤正常用户。再补充一点高防IP不是万能钥匙。如果你源站IP泄露攻击者直接打源站IP高防IP就成了摆设。常见的泄露途径包括DNS历史记录、邮件头信息、后端API直连、第三方接口回调等。所以不管选哪个厂商都必须做好源站隐藏和访问白名单控制。2.3 混合架构的权衡与部署位置所谓混合架构一般是本地设备做第一层粗过滤云清洗做第二层深度清洗再结合CDN、WAF等形成多层防护。它在延迟和成本之间做了一个相对折中的选择。为什么有人愿意用混合架构主要因为一些核心业务对延迟敏感全部流量绕到云端清洗远距离转发会增加几十毫秒延迟部分金融交易类或实时对战类业务接受不了。混合架构把“近源清洗”放在本地把“大流量攻击”引流到云端可以让正常小流量不绕路遇到大高峰才自动切云。需要注意的是混合架构的切换逻辑非常考验运维能力。要配置好BGP引流策略、黑洞路由阈值、云清洗API联动最好能实现自动化切换否则攻击来了手动切来不及。我曾经见过一个团队本地设备被打瘫后还在用手工修改DNS记录结果金贵的三分钟恢复窗口全浪费在等待上。如果你没有足够成熟的自动化运维能力混合架构可能会成为负担而不是优势。3. 关键技术架构与部署实践选型定了接下来就是架构落地。这一段是方案的骨架也是很多资料里最语焉不详的部分。我会把流量清洗、高可用网络拓扑、参数调优这几个关键环节讲清楚。3.1 流量清洗中心的工作原理不管自建还是云清洗流量清洗中心的基本逻辑是相通的。简单来说就是“引流、检测、清洗、回注”。引流环节把目标IP的流量通过BGP路由或者DNS方式导入清洗设备。常见的手法是在汇聚路由器上发布更精确的路由条目或在负载均衡器上把流量镜像给检测设备。核心是不要把所有流量全部导入清洗设备只导需要保护的那部分控制设备压力。检测环节需要兼顾速度和准确性。基于流量镜像的旁路检测是主流方式通过NetFlow/sFlow采样或BGP FlowSpec做实时分析。检测算法一般先用粗粒度特征如包速率、源IP数量、协议分布判断是否发生攻击再用细粒度规则如IP信誉、行为基线定位攻击特征。目的是快速识别攻击并生成清洗规则。清洗环节则执行规则。常见手段包括丢包丢弃符合攻击特征的包、限速对异常源IP限制速率、会话验证如SYN Cookie、载荷检测针对应用层攻击。这里最关键的是清洗粒度要动态调整规则太宽会把正常流量误杀太窄又漏过攻击。我建议配置两级策略全局默认策略覆盖常见攻击类型白名单策略保护VIP客户或核心业务源IP。回注环节把清洗过的干净流量重新送回源站网络常见方式是二层回注或策略路由回注。回注链路必须保证足够的带宽冗余否则清洗完的流量还在半路上拥堵业务照样不可用。3.2 高可用网络架构设计BGP引流与负载均衡联动高可用架构的精髓在于“不让单点成为故障源”。我推荐至少采用以下设计思路。第一边界冗余。至少两个运营商出口通过BGP对接。正常状态下两个出口均摊流量当一边遭到攻击时通过BGP路由策略把流量切到另一边。这里需要提前和运营商谈好带宽峰值不然出现大流量攻击时运营商直接黑洞你只能干瞪眼。第二清洗设备集群化。不要把清洗工作压在单台设备上。用多台设备组成集群前面做负载均衡分发中间做健康检查把故障节点自动摘除。配置静态ECMP等价多路径也能做到类似效果但不如专业的健康检查灵活。第三DNS与BGP联动。对于HTTP业务可以在CDN层做规则当检测到异常流量时把域名解析切换到高防IP攻击结束后再切回源站。这个过程必须自动化最好通过脚本或云API完成不要依赖人工。我自己的习惯是写一个监控脚本每隔30秒拉一次攻击检测数据如果超过阈值就自动修改DNS记录实测恢复时间能控制在1分钟以内。下面是一个简化版的高可用拓扑组织思路用户流量 | -- 边界路由器BGP | | | v | 流量检测/清洗集群多台 | |(干净流量) | v | 核心交换机 | | | v | 负载均衡器SLB/Nginx/LVS | | | v | 应用服务器集群注意在边界路由器上要配置黑洞路由的兜底逻辑当攻击流量超过清洗能力上限时宁可本地黑洞保护整体网络也不要让攻击流量打爆所有链路。黑洞是最后的止损手段不是优选方案。3.3 关键参数配置与调优心得参数调优是防护落地里最见功夫的部分。我挑几个高频参数分享一些实际经验。TCP SYN Flood防护的参数重点是SYN Cookie阈值和半连接数阈值。一般而言可以按正常业务峰值的1.5到2倍作为触发阈值。比如你的业务高峰期每秒新建连接2000个阈值就设在3000-4000左右。这个值不能一刀切要结合服务器性能迭代调整。我见过设太低的案例业务稍微做活动就误触发导致大量正常用户连接失败。UDP Flood防护参数重点是UDP包长和速率限制。很多游戏类、音视频类服务天然就有不少UDP流量如果统一限制过低会误伤。建议做源IP信誉和会话关联分析只对异常高频、无会话关系的UDP包进行丢弃和限速。应用层防护参数重点是限流和跳转验证。对普通登录接口可以设置单IP每分钟调用次数限制比如30次/分钟并结合IP信誉库。对高危接口如支付、修改密码可以加滑块验证码或二次校验。这里务必注意限流策略要区分“人”和“机”避免把真实用户当机器人拦截。我踩过的一个坑是连接超时时间的设置。默认很多设备TCP超时时间较长如30秒在SYN Flood攻击时半连接表会被快速撑满。后来我把超时时间压到10秒并开启SYN Cookie防御效果立竿见影。当然超时太短也会导致高延迟网络下的正常连接被误杀需要根据业务实测调整。4. 实操要点从接入到运营的完整闭环方案落地只是开始更核心的是日常运营和应急处置。很多团队把DDoS防护当成“买了就安全”结果攻击来了手忙脚乱。下面讲讲我的一些实操经验。4.1 防护策略配置与管理配置防护策略时我推荐先做“收敛”再“放开”。所谓收敛是先把默认策略都打开特别是常见的SYN Flood、UDP Flood、ICMP Flood防护保证基础安全观察一段时间业务没有异常后再逐步放开被误伤的部分。不要一上来就精细化很容易漏配。策略分级管理也很关键。可以给VIP客户或核心业务单独配置白名单策略绕过部分清洗规则给普通用户配置标准策略给可疑IP配置黑名单策略。这三层策略要有优先级通常是白名单大于黑名单特殊规则大于默认规则。另外策略变更留痕是必须的。每次修改防护策略记录操作人、变更时间、变更逻辑。很多企业出问题时追溯不到原因往往就是策略变更没有记录。哪怕只是临时改一个阈值也建议在投产环境外先验证再发布。4.2 监控、告警与攻击溯源防护系统需要具备多层监控能力。底层看带宽和包量中间看连接数和规则命中数上层看业务本身的可用性指标比如HTTP请求成功率、响应延迟。我建议至少部署一套基础监控如PrometheusGrafana一套业务拨测如云拨测或自建探针当出现攻击迹象时能从业务指标快速关联到网络指标。告警阈值的设定要防止两个极端。阈值过低白天一个很小的流量抖动就会触发大量告警团队变成“狼来了”状态久而久之没有人在意告警阈值过高攻击已经打满带宽才告警失去预警意义。我的经验是把告警分成两级第一级是“可疑”阈值设为正常峰值的30%以上但未造成业务影响通知到值班人第二级是“危险”超过峰值50%或已经开始丢包通知到全体运维和值班负责人。攻击溯源是很多团队忽略的事其实很值得做。清洗设备或云平台会保留攻击流量的采样数据比如源IP、目的IP、源端口、目标端口、包特征。攻击结束后及时基于这些数据做一次溯源分析概括出攻击类型、峰值、持续时间、攻击源分布输出一份简短报告。这有助于后续调整防护策略也能用来向上级汇报安全投入的价值。4.3 压测与攻防演练的重要性没有经过压测的防护系统就像没试过车的发动机你不知道它真实工况如何。我强烈建议每个季度做一次小规模攻防演练半年做一次大规模压测。压测要注意合规不要拿真实公网IP去打除非有专门授权的测试环境建议使用测试域名和低风险的回源地址也可以租用第三方压测服务。压测前要和云厂商提前确认避免被误认为是恶意攻击。压测内容至少要包含4层流量型攻击、4层连接型攻击、7层HTTP Flood。观察防护系统是否按预设策略生效、清洗后回源流量是否稳定、业务响应延时是否回归正常。压测后一定要复盘哪些参数没生效哪些规则误杀了哪些链路成了瓶颈。我自己经历过一次压测当时发现高防IP对新上线的一个UDP端口协议支持很差所有UDP包都被拦截了导致测试客户端大量报错。后来联系云厂商调整清洗策略才恢复。这个隐患如果不做压测根本发现不了等真实业务上线后被攻击就麻烦了。5. 常见问题排查与避坑指南实话说DDoS攻防里很难有“一次部署永无烦恼”的完美方案踩坑才是常态。我整理了工作中高频出现的问题和解法希望能帮你省一些试错时间。5.1 典型故障场景与排查思路场景一攻击期间业务大面积报错但源站服务器负载很低。排查思路先看是不是清洗设备把正常流量也丢弃了。检查清洗规则中是否有过于宽泛的源IP段限制、协议限制、速率限制。可以用源站服务器的访问日志反查看负载均衡器收到的请求量是否骤降。如果正常流量根本没到源站说明问题出在清洗侧或回源链路。场景二源站IP被打瘫痪尽管已经接入了高防。排查思路首先确认攻击流量是否仍直接打源站IP。查DNS记录是否全部指向高防查历史DNS记录是否有源站IP暴露查后端业务是否有绕过防护直接外联的端口。最有效的兜底方案是更换源站IP并确保新IP不做解析、不走邮件、不出现在第三方目录里。场景三连接型攻击没打满带宽但应用依然不可用。排查思路这种情况大概率是代理层或负载均衡器的连接表被打满。登录到负载均衡器上查看连接数、半连接数、内存使用情况确认是否因为连接超时时间过长、SYN Cookie未开启、连接复用配置不对导致。如果是Nginx可以调大worker_connections参数建议配置开启HTTP keepalive复用和回调池复用减少新建连接的压力。场景四攻击结束后业务仍然恢复不过来。排查思路攻击结束后可能存在“冷却效应”。比如连接表里残留大量半连接或应用服务器上存在大量TIME_WAIT连接新连接进不来。常规解法是清空连接表、重启负载均衡器或调整内核参数如tcp_max_tw_buckets、tcp_fin_timeout。更推荐在防护设备上配置“攻击结束自动恢复到默认策略”避免持续限制正常流量。5.2 容易忽略的细节DNS、CDN、证书与代理层很多人只关注高防IP本身却忽略联动组件这里补充几个经常被忽视的点。DNS是不可忽视的第一道门。如果你的DNS解析本身就暴露了大量源站IP攻击者能做“源站IP探测”再大的高防也防不住。建议使用专门的安全DNS服务开启DNSSEC同时不要在DNS解析记录里使用过于具体的A记录映射到源站。最稳妥的方式是CDN和高防配合让源站IP彻底不可见。CDN能扛一部分流量型攻击。当攻击流量针对的是页面静态资源时CDN节点直接消化掉了回源站的压力很小。但要注意CDN和WAF的规则要和DDoS防护联动比如在攻击时自动切换不同缓存策略避免动态请求全量回源加重源站压力。SSL/TLS证书在应用层攻击里容易成为瓶颈。因为HTTPS握手本身就要消耗大量CPU针对握手过程的攻击可以轻易打满源站的SSL解密能力。如果业务对HTTPS依赖很深建议在负载均衡器前置启用TLS终止和会话复用不要把解密压力都留给应用服务器。调优时也要关注证书链的完整性和协议版本尽量减少不必要的TLS协商开销。代理层Nginx/Haproxy的“健康检查”也可能被利用。部分防护系统对健康检查请求不设限攻击者伪造大量健康检查请求打入代理层导致代理误判后端全部故障自动摘除节点。解决办法是设置健康检查的独立端口或特定User-Agent并将其加入白名单。5.3 快速速查表攻击迹象与对应动作我把平时经常用到的判断依据整理成了一个速查表遇到问题时先对照这个表快速定位再深入排查现象可能原因优先动作带宽突然打满Ping不通流量型攻击联系运营商黑洞/启用高防清洗用户大量连接超时但带宽正常连接型攻击检查连接表、开启SYN Cookie服务器CPU高企请求量暴增应用型攻击限流、启用WAF规则、加验证码特定接口报Blocked清洗规则误杀查看清洗日志加白名单回源链路拥塞高防回源带宽不足联系云厂商扩容回源链路业务恢复慢连接表残留/内核参数问题清连接表调tcp_fin_timeoutDDoS防护不是一次性买断的服务它是一个持续迭代、动态调整的过程。我个人在实际操作中最深的一条体会是真正决定防护成败的不是设备堆得有多高而是你对自身业务特征和异常流量信号的理解深度。有些团队买了很好的设备却在攻击来临时因为规则没调好、监控没看到、切换没自动化而一败涂地有些团队设备一般但配合了扎实的日常演练和清晰的决策流程反而能稳住局面。最后再分享一个小技巧给防护系统每个季度做一次“健康体检”不用太复杂就三条——拉一次性能报表看清洗能力余量做一次策略审计看配置是否还符合当前业务开展一次小规模模拟攻击看联动是否顺畅。坚持做下来绝大部分突发攻击都能在十分钟内完成发现、调度和恢复。希望这篇经验整理能给你带来一些有用的参考价值。
DDoS防护方案选型与部署实战：从攻击类型到混合架构
1. 先搞清楚你的攻击面DDoS攻击类型与防护目标做防护方案选型之前我建议你先别急着看厂商宣传手册先老老实实梳理一遍自己的业务资产和暴露面。很多团队一上来就问“买多少G的防护”但漏掉了更基础的问题你被攻击的入口到底在哪是网站域名还是IP直连是TCP服务还是UDP服务有没有CDN、有没有源站IP泄露这些直接决定了后续选型的方向。1.1 常见的DDoS攻击分类流量型、连接型、应用型DDoS攻击从技术实现上大体可以分成三个大类每一类对防护资源的需求完全不同。第一类是流量型攻击典型代表是UDP Flood、ICMP Flood、DNS反射放大攻击。这类攻击的核心是“量”用海量带宽把链路或设备打满让正常用户的数据包挤不进来。我见过最夸张的一次是单月连续收到几十Gbps的持续流量压制办公区出口直接被堵死连SSH都连不上主机。这类攻击的防护逻辑很简单要么你的带宽富余到能吞下攻击流量要么在攻击流量到达源站前把它清洗掉。第二类是连接型攻击典型代表是TCP SYN Flood、ACK Flood、连接耗尽攻击。这类攻击不像流量型那样依赖大带宽而是靠生成海量半连接或无效连接占满防火墙、负载均衡器、服务器的连接表让新建连接失败。很多云服务器在这种攻击下不会断网但业务会表现为“登录转圈、请求超时”。这类攻击对设备的处理性能要求很高单靠加大带宽解决不了问题。第三类是应用型攻击典型代表是HTTP慢速攻击、HTTP Flood、针对特定API的恶意请求。这类攻击最“省钱”攻击者只需要少量肉鸡就能模拟真实用户请求导致应用服务器CPU飙升、数据库连接打满甚至缓存击穿。这类攻击最难防御因为它和正常流量几乎无法区分防护重点已经从“网络层清洗”升级到了“应用层行为分析”。这里有个容易被忽略的误区很多人只关注流量型攻击觉得“带宽够大就行”可现实里混合攻击才是常态。攻击者会先用流量型干扰你的网络再混入连接型和应用型攻击去突破业务层如果你只部署了单点防护很容易被日穿。1.2 不同攻击类型对应的防护策略我习惯用一张简单的表来匹配攻击型和对应策略这样选型时思路更清晰攻击类型核心诉求防护技术方向典型设备/服务流量型吞掉大流量避免链路拥塞流量清洗、黑洞路由、CDN分流云清洗、DDoS高防IP、本地流量清洗器连接型保护连接表不被耗尽状态检测、SYN Cookie、连接速率限制防火墙、负载均衡、抗DDoS设备应用型识别并拦截恶意业务请求WAF规则、行为分析、限流、验证码WAF、API网关、Bot管理选型的第一步应该是明确自己业务的特点是无状态的静态内容站点还是有大量长连接的IM服务是面向公网开放API还是仅限内网访问不同的业务形态在攻击面和安全需求上差异很大。比如纯静态站点用CDN加上高防就能覆盖大部分问题而IM服务还要考虑连接保持和状态同步天然更容易碰上连接型攻击。另外防护目标要量化。不要只写“我们需要抗DDoS”要写“我们能在50Gbps的流量型攻击下保持业务可用”或者“我们能在每秒10万次SYN洪水下保持新建连接成功率不低于95%”。能量化的目标才能检验方案是否达标。2. 防护方案选型从自建到云清洗再到混合架构选型没有放之四海而皆准的标准答案只有适合你当前阶段的方案。我在不同规模的公司里见过三种路线中小团队刚开始通常直接用云厂商防护有网络团队的大公司会考虑自建清洗设备业务面复杂、对延迟敏感的核心系统会采用混合架构。下面逐一拆解。2.1 自建防护的适用场景与成本分析自建DDoS防护意味着你要自己购买抗DDoS硬件设备或软件方案自己维护BGP链路和清洗集群。听起来很“硬核”但实际门槛远比你想象的高。先算一笔账一台还不错的本地抗DDoS设备处理能力在10Gbps级别的价格通常几十万到上百万如果要做成集群两三台起步。再加上你需要至少双线或多线BGP接入托管机柜、带宽费、电力、运维人力一年的综合成本轻松破百万。这还没算攻击流量把出口带宽打满后运营商的额外超量费用。我见过有公司为了省云清洗年费自建了设备结果某次大流量攻击直接让运营商带宽峰值账单爆炸一个月花掉了过去三年的防护预算。所以自建方案只适合几个场景一是运营商或多线接入的ISP本身有带宽资源优势二是业务对内网隔离要求极高必须把流量留在本地三是有成熟的网络运维团队和冗余带宽池。如果你只是普通互联网业务老老实实选云清洗更划算。2.2 专业DDoS防护服务云清洗的选型要点现在主流云厂商都提供DDoS防护服务核心原理差别不大把DNS解析或BGP路由指向高防IP攻击流量先到达云端清洗集群过滤后再把干净流量回源到你的服务器。选型时主要看几个关键指标。第一是防护能力阈值。这里有个隐形坑很多厂商宣传的“最大防护能力”是“全力防护”但实际跑的是“保底防护弹性防护”。保底防护是固定费用长驻的能力弹性防护是攻击超过保底阈值后临时扩出来的按天计费且价格不菲。你买的时候不光要看保底值还要评估业务被攻击时的历史峰值别让弹性成本失控。第二是回源质量。清洗之后的回源链路带宽是否充足回源是走专线还是公网如果回源链路本身很窄攻击流量虽然被洗掉了但大流量攻击导致的瞬时回源拥塞也会影响业务。这个细节很多销售都不会主动讲你需要专门确认。第三是防护协议的完整性。有些高防产品只做四层防护对七层HTTP Flood的识别比较弱需要额外搭配WAF。有些产品把UDP防护做得很强但TCP业务兼容性差可能出现误杀。选型前建议拿自己的真实业务流量做一轮接入测试包括正常访问、CDN回源、长连接保活等场景确认不会误伤正常用户。再补充一点高防IP不是万能钥匙。如果你源站IP泄露攻击者直接打源站IP高防IP就成了摆设。常见的泄露途径包括DNS历史记录、邮件头信息、后端API直连、第三方接口回调等。所以不管选哪个厂商都必须做好源站隐藏和访问白名单控制。2.3 混合架构的权衡与部署位置所谓混合架构一般是本地设备做第一层粗过滤云清洗做第二层深度清洗再结合CDN、WAF等形成多层防护。它在延迟和成本之间做了一个相对折中的选择。为什么有人愿意用混合架构主要因为一些核心业务对延迟敏感全部流量绕到云端清洗远距离转发会增加几十毫秒延迟部分金融交易类或实时对战类业务接受不了。混合架构把“近源清洗”放在本地把“大流量攻击”引流到云端可以让正常小流量不绕路遇到大高峰才自动切云。需要注意的是混合架构的切换逻辑非常考验运维能力。要配置好BGP引流策略、黑洞路由阈值、云清洗API联动最好能实现自动化切换否则攻击来了手动切来不及。我曾经见过一个团队本地设备被打瘫后还在用手工修改DNS记录结果金贵的三分钟恢复窗口全浪费在等待上。如果你没有足够成熟的自动化运维能力混合架构可能会成为负担而不是优势。3. 关键技术架构与部署实践选型定了接下来就是架构落地。这一段是方案的骨架也是很多资料里最语焉不详的部分。我会把流量清洗、高可用网络拓扑、参数调优这几个关键环节讲清楚。3.1 流量清洗中心的工作原理不管自建还是云清洗流量清洗中心的基本逻辑是相通的。简单来说就是“引流、检测、清洗、回注”。引流环节把目标IP的流量通过BGP路由或者DNS方式导入清洗设备。常见的手法是在汇聚路由器上发布更精确的路由条目或在负载均衡器上把流量镜像给检测设备。核心是不要把所有流量全部导入清洗设备只导需要保护的那部分控制设备压力。检测环节需要兼顾速度和准确性。基于流量镜像的旁路检测是主流方式通过NetFlow/sFlow采样或BGP FlowSpec做实时分析。检测算法一般先用粗粒度特征如包速率、源IP数量、协议分布判断是否发生攻击再用细粒度规则如IP信誉、行为基线定位攻击特征。目的是快速识别攻击并生成清洗规则。清洗环节则执行规则。常见手段包括丢包丢弃符合攻击特征的包、限速对异常源IP限制速率、会话验证如SYN Cookie、载荷检测针对应用层攻击。这里最关键的是清洗粒度要动态调整规则太宽会把正常流量误杀太窄又漏过攻击。我建议配置两级策略全局默认策略覆盖常见攻击类型白名单策略保护VIP客户或核心业务源IP。回注环节把清洗过的干净流量重新送回源站网络常见方式是二层回注或策略路由回注。回注链路必须保证足够的带宽冗余否则清洗完的流量还在半路上拥堵业务照样不可用。3.2 高可用网络架构设计BGP引流与负载均衡联动高可用架构的精髓在于“不让单点成为故障源”。我推荐至少采用以下设计思路。第一边界冗余。至少两个运营商出口通过BGP对接。正常状态下两个出口均摊流量当一边遭到攻击时通过BGP路由策略把流量切到另一边。这里需要提前和运营商谈好带宽峰值不然出现大流量攻击时运营商直接黑洞你只能干瞪眼。第二清洗设备集群化。不要把清洗工作压在单台设备上。用多台设备组成集群前面做负载均衡分发中间做健康检查把故障节点自动摘除。配置静态ECMP等价多路径也能做到类似效果但不如专业的健康检查灵活。第三DNS与BGP联动。对于HTTP业务可以在CDN层做规则当检测到异常流量时把域名解析切换到高防IP攻击结束后再切回源站。这个过程必须自动化最好通过脚本或云API完成不要依赖人工。我自己的习惯是写一个监控脚本每隔30秒拉一次攻击检测数据如果超过阈值就自动修改DNS记录实测恢复时间能控制在1分钟以内。下面是一个简化版的高可用拓扑组织思路用户流量 | -- 边界路由器BGP | | | v | 流量检测/清洗集群多台 | |(干净流量) | v | 核心交换机 | | | v | 负载均衡器SLB/Nginx/LVS | | | v | 应用服务器集群注意在边界路由器上要配置黑洞路由的兜底逻辑当攻击流量超过清洗能力上限时宁可本地黑洞保护整体网络也不要让攻击流量打爆所有链路。黑洞是最后的止损手段不是优选方案。3.3 关键参数配置与调优心得参数调优是防护落地里最见功夫的部分。我挑几个高频参数分享一些实际经验。TCP SYN Flood防护的参数重点是SYN Cookie阈值和半连接数阈值。一般而言可以按正常业务峰值的1.5到2倍作为触发阈值。比如你的业务高峰期每秒新建连接2000个阈值就设在3000-4000左右。这个值不能一刀切要结合服务器性能迭代调整。我见过设太低的案例业务稍微做活动就误触发导致大量正常用户连接失败。UDP Flood防护参数重点是UDP包长和速率限制。很多游戏类、音视频类服务天然就有不少UDP流量如果统一限制过低会误伤。建议做源IP信誉和会话关联分析只对异常高频、无会话关系的UDP包进行丢弃和限速。应用层防护参数重点是限流和跳转验证。对普通登录接口可以设置单IP每分钟调用次数限制比如30次/分钟并结合IP信誉库。对高危接口如支付、修改密码可以加滑块验证码或二次校验。这里务必注意限流策略要区分“人”和“机”避免把真实用户当机器人拦截。我踩过的一个坑是连接超时时间的设置。默认很多设备TCP超时时间较长如30秒在SYN Flood攻击时半连接表会被快速撑满。后来我把超时时间压到10秒并开启SYN Cookie防御效果立竿见影。当然超时太短也会导致高延迟网络下的正常连接被误杀需要根据业务实测调整。4. 实操要点从接入到运营的完整闭环方案落地只是开始更核心的是日常运营和应急处置。很多团队把DDoS防护当成“买了就安全”结果攻击来了手忙脚乱。下面讲讲我的一些实操经验。4.1 防护策略配置与管理配置防护策略时我推荐先做“收敛”再“放开”。所谓收敛是先把默认策略都打开特别是常见的SYN Flood、UDP Flood、ICMP Flood防护保证基础安全观察一段时间业务没有异常后再逐步放开被误伤的部分。不要一上来就精细化很容易漏配。策略分级管理也很关键。可以给VIP客户或核心业务单独配置白名单策略绕过部分清洗规则给普通用户配置标准策略给可疑IP配置黑名单策略。这三层策略要有优先级通常是白名单大于黑名单特殊规则大于默认规则。另外策略变更留痕是必须的。每次修改防护策略记录操作人、变更时间、变更逻辑。很多企业出问题时追溯不到原因往往就是策略变更没有记录。哪怕只是临时改一个阈值也建议在投产环境外先验证再发布。4.2 监控、告警与攻击溯源防护系统需要具备多层监控能力。底层看带宽和包量中间看连接数和规则命中数上层看业务本身的可用性指标比如HTTP请求成功率、响应延迟。我建议至少部署一套基础监控如PrometheusGrafana一套业务拨测如云拨测或自建探针当出现攻击迹象时能从业务指标快速关联到网络指标。告警阈值的设定要防止两个极端。阈值过低白天一个很小的流量抖动就会触发大量告警团队变成“狼来了”状态久而久之没有人在意告警阈值过高攻击已经打满带宽才告警失去预警意义。我的经验是把告警分成两级第一级是“可疑”阈值设为正常峰值的30%以上但未造成业务影响通知到值班人第二级是“危险”超过峰值50%或已经开始丢包通知到全体运维和值班负责人。攻击溯源是很多团队忽略的事其实很值得做。清洗设备或云平台会保留攻击流量的采样数据比如源IP、目的IP、源端口、目标端口、包特征。攻击结束后及时基于这些数据做一次溯源分析概括出攻击类型、峰值、持续时间、攻击源分布输出一份简短报告。这有助于后续调整防护策略也能用来向上级汇报安全投入的价值。4.3 压测与攻防演练的重要性没有经过压测的防护系统就像没试过车的发动机你不知道它真实工况如何。我强烈建议每个季度做一次小规模攻防演练半年做一次大规模压测。压测要注意合规不要拿真实公网IP去打除非有专门授权的测试环境建议使用测试域名和低风险的回源地址也可以租用第三方压测服务。压测前要和云厂商提前确认避免被误认为是恶意攻击。压测内容至少要包含4层流量型攻击、4层连接型攻击、7层HTTP Flood。观察防护系统是否按预设策略生效、清洗后回源流量是否稳定、业务响应延时是否回归正常。压测后一定要复盘哪些参数没生效哪些规则误杀了哪些链路成了瓶颈。我自己经历过一次压测当时发现高防IP对新上线的一个UDP端口协议支持很差所有UDP包都被拦截了导致测试客户端大量报错。后来联系云厂商调整清洗策略才恢复。这个隐患如果不做压测根本发现不了等真实业务上线后被攻击就麻烦了。5. 常见问题排查与避坑指南实话说DDoS攻防里很难有“一次部署永无烦恼”的完美方案踩坑才是常态。我整理了工作中高频出现的问题和解法希望能帮你省一些试错时间。5.1 典型故障场景与排查思路场景一攻击期间业务大面积报错但源站服务器负载很低。排查思路先看是不是清洗设备把正常流量也丢弃了。检查清洗规则中是否有过于宽泛的源IP段限制、协议限制、速率限制。可以用源站服务器的访问日志反查看负载均衡器收到的请求量是否骤降。如果正常流量根本没到源站说明问题出在清洗侧或回源链路。场景二源站IP被打瘫痪尽管已经接入了高防。排查思路首先确认攻击流量是否仍直接打源站IP。查DNS记录是否全部指向高防查历史DNS记录是否有源站IP暴露查后端业务是否有绕过防护直接外联的端口。最有效的兜底方案是更换源站IP并确保新IP不做解析、不走邮件、不出现在第三方目录里。场景三连接型攻击没打满带宽但应用依然不可用。排查思路这种情况大概率是代理层或负载均衡器的连接表被打满。登录到负载均衡器上查看连接数、半连接数、内存使用情况确认是否因为连接超时时间过长、SYN Cookie未开启、连接复用配置不对导致。如果是Nginx可以调大worker_connections参数建议配置开启HTTP keepalive复用和回调池复用减少新建连接的压力。场景四攻击结束后业务仍然恢复不过来。排查思路攻击结束后可能存在“冷却效应”。比如连接表里残留大量半连接或应用服务器上存在大量TIME_WAIT连接新连接进不来。常规解法是清空连接表、重启负载均衡器或调整内核参数如tcp_max_tw_buckets、tcp_fin_timeout。更推荐在防护设备上配置“攻击结束自动恢复到默认策略”避免持续限制正常流量。5.2 容易忽略的细节DNS、CDN、证书与代理层很多人只关注高防IP本身却忽略联动组件这里补充几个经常被忽视的点。DNS是不可忽视的第一道门。如果你的DNS解析本身就暴露了大量源站IP攻击者能做“源站IP探测”再大的高防也防不住。建议使用专门的安全DNS服务开启DNSSEC同时不要在DNS解析记录里使用过于具体的A记录映射到源站。最稳妥的方式是CDN和高防配合让源站IP彻底不可见。CDN能扛一部分流量型攻击。当攻击流量针对的是页面静态资源时CDN节点直接消化掉了回源站的压力很小。但要注意CDN和WAF的规则要和DDoS防护联动比如在攻击时自动切换不同缓存策略避免动态请求全量回源加重源站压力。SSL/TLS证书在应用层攻击里容易成为瓶颈。因为HTTPS握手本身就要消耗大量CPU针对握手过程的攻击可以轻易打满源站的SSL解密能力。如果业务对HTTPS依赖很深建议在负载均衡器前置启用TLS终止和会话复用不要把解密压力都留给应用服务器。调优时也要关注证书链的完整性和协议版本尽量减少不必要的TLS协商开销。代理层Nginx/Haproxy的“健康检查”也可能被利用。部分防护系统对健康检查请求不设限攻击者伪造大量健康检查请求打入代理层导致代理误判后端全部故障自动摘除节点。解决办法是设置健康检查的独立端口或特定User-Agent并将其加入白名单。5.3 快速速查表攻击迹象与对应动作我把平时经常用到的判断依据整理成了一个速查表遇到问题时先对照这个表快速定位再深入排查现象可能原因优先动作带宽突然打满Ping不通流量型攻击联系运营商黑洞/启用高防清洗用户大量连接超时但带宽正常连接型攻击检查连接表、开启SYN Cookie服务器CPU高企请求量暴增应用型攻击限流、启用WAF规则、加验证码特定接口报Blocked清洗规则误杀查看清洗日志加白名单回源链路拥塞高防回源带宽不足联系云厂商扩容回源链路业务恢复慢连接表残留/内核参数问题清连接表调tcp_fin_timeoutDDoS防护不是一次性买断的服务它是一个持续迭代、动态调整的过程。我个人在实际操作中最深的一条体会是真正决定防护成败的不是设备堆得有多高而是你对自身业务特征和异常流量信号的理解深度。有些团队买了很好的设备却在攻击来临时因为规则没调好、监控没看到、切换没自动化而一败涂地有些团队设备一般但配合了扎实的日常演练和清晰的决策流程反而能稳住局面。最后再分享一个小技巧给防护系统每个季度做一次“健康体检”不用太复杂就三条——拉一次性能报表看清洗能力余量做一次策略审计看配置是否还符合当前业务开展一次小规模模拟攻击看联动是否顺畅。坚持做下来绝大部分突发攻击都能在十分钟内完成发现、调度和恢复。希望这篇经验整理能给你带来一些有用的参考价值。
