前阵子客户机房半夜被打监控大屏哗啦啦弹了几十条红色告警入向带宽直接顶到机房物理上限交换机CPU都快烧起来了。我爬起来打开路由器一看几十万个源IP在疯狂发包防火墙上的那几条手工封禁规则就像拿水枪去灭森林大火根本无济于事。那天晚上我们最后是靠临时把业务切到云端清洗节点才缓过来。事后复盘时我一直在想如果早点把黑白名单、限速、流量牵引这三套手段组合起来用是不是根本不用半夜折腾这么久这篇东西就是基于这类实战经历把抗DDoS的三个核心手段掰开揉碎讲清楚黑白名单负责什么、限速怎么调才不误伤、流量牵引的代价和收益是什么以及它们之间怎么配合。适合正在做运维、搞安全或者准备等保测评、被领导问“网站被打了怎么办”的同行参考。我不讲厂商PPT里那种漂亮话只讲现场怎么落地。1. DDoS 攻击的套路与防御的整体思路1.1 攻击面的拆除从带宽打满到连接耗尽很多人一提DDoS就想到“大流量”但真实攻击远不止这一种。我按现场观察的经验把常见攻击拆成三类因为防御手段的选择首先取决于攻击属于哪一类。第一类是带宽耗尽型。典型的是UDP Flood、ICMP Flood、DNS Query Flood这类无限放大流量。攻击者用伪造源IP的UDP小包打向受害者或者利用DNS放大反射目的只有一个把你的入口带宽打满。带宽一旦满了正常用户的TCP三次握手都完成不了业务表现就是“完全连不上”。这一类攻击的特点是不讲道理流量大就是王道。第二类是连接耗尽型。SYN Flood是最经典的例子攻击者发大量TCP SYN包但不完成握手把服务器的半连接队列灌满。这时候正常用户发起的连接请求会被内核直接丢弃。还有一种ACK Flood打的是会话表或状态检测设备的处理能力。这一类攻击未必占用很大带宽但会把中间设备和服务器“忙死”。第三类是应用层攻击也就是常说的CC攻击。攻击者模拟正常用户逻辑不断请求某个消耗较高的业务接口比如搜索、导出、登录接口。带宽不高连接数也不算离谱但是业务线程池、数据库连接、后端计算资源被拖垮。慢速攻击Slowloris也属于这一类它把HTTP请求头一点一点地发给服务器占住连接不放。这类攻击最阴险因为流量特征和真实用户几乎一样。区分这三类攻击有什么用直接决定你是该上黑白名单、限速还是流量牵引。带宽打满你在应用层做多少规则都白搭因为流量根本进不来连接耗尽单纯限速效果有限你得限制并发和半连接应用层攻击靠流量牵引也不解决问题因为流量量级不大需要更精细的识别和拦截。1.2 防御体系的层次三种手段各守一段我习惯把DDoS防御体系理解成“边缘、接入、应用”三层的三道闸门。这个分层思路比纠结具体设备更重要。边缘层是运营商机房入口、云清洗中心这一级。这里距离攻击源更近处理大流量最划算。流量牵引就是在这一层做文章检测到攻击流量后把原本要打到源站IP的流量通过路由策略引到清洗设备或者黑洞里去。这一层带宽大、设备专用对付上百Gbps的攻击都不怕但代价是部署成本高、牵一发动全身。接入层是自建的防火墙、路由器、负载均衡设备。黑白名单和限速主要在这一层起作用。防火墙用精确的IP和端口规则过滤已知攻击源负载均衡和网关设备限制并发数、限速转发。这一层的好处是自主可控、成本适中但设备处理能力有限流量超过设备阈值它也扛不住。应用层是Web服务器、WAF、业务代码这一级。这一层最贴近业务能识别“请求里带不带恶意特征”“这个用户是不是真人”黑白名单的高级玩法、验证码、人机校验、动态限速都在这里落地。应用层的优势是精准劣势是它本身也是被攻击的对象一旦前面两道闸门失守应用层会被连带打垮。三层不是替代关系是接力关系。我见过不少团队只在一层使劲比如只买了高防IP就以为万事大吉结果应用层CC没防住或者只部署了WAF结果带宽被UDP Flood打爆WAF一个包都来不及看。真正的抗DDoS是三层协同边缘牵引解决“流量太大”接入层限速解决“资源耗尽”应用层黑白名单解决“精准识别”。2. 黑白名单最基础的访问控制手段2.1 黑白名单不是配置几个IP那么简单黑白名单是很多人理解的DDoS防御的“起点”但它远不是“封几个IP放几个IP”那么简单。在DDoS语境下白名单意味着只允许来自已知可信IP或IP段的流量进入其余的一律拒绝。黑名单则是把已经确认的攻击源IP或IP段加入拒绝列表再有流量来就直接丢弃。白名单的典型场景是后台管理系统、API对接、内部办公系统这类访问者范围明确的服务。比如一个企业内部的OA系统只允许办公室出口IP访问那就直接只放行那一个IP段外部流量连握手都到不了Web服务器效率极高。黑名单的场景则是你从日志里看到某个IP在持续高频请求某个接口确认是攻击源那就封掉它代价极小且精准。但黑白名单在真实DDoS防御里有个根本性矛盾白名单太严格会挡住真实用户只适合特定场景黑名单看似灵活却永远追不上攻击源的变化。现在攻击者手里动辄几十万上百万的肉鸡IP每秒钟都在换源人工把IP往列表里加的速度永远赶不上自动化的扫描速度。所以我对黑白名单的定位是它是一把“手术刀”不是一面“盾牌”。它适合精准切除已知病灶不适合单独对抗大规模未知攻击。2.2 黑白名单的实操要点从单IP到网段、从静态到动态先说说最基本的手工封禁。在Linux服务器上用iptables封一个IP很容易iptables -A INPUT -s 1.2.3.4 -j DROP iptables -A INPUT -s 5.6.7.0/24 -j DROP但这里有个坑绝大多数人只会封单个IP可攻击者往往用的是同一个云厂商或者同一个地区的IP段。只封单个IP等于隔靴搔痒你得学会封网段。怎么判断该封哪个段抓包看源IP分布如果10个攻击IP里8个都属于同一个C段直接封那个C段效果立竿见影。第二个坑是IP黑白名单规则多了以后防火墙性能会肉眼可见地下降。传统iptables规则是线性匹配的几百条规则时每条连接都要从头到尾查一遍流量大时CPU占用直线飙升。这时候得用ipset把IP集合加载到内核哈希表里匹配复杂度从O(n)降到O(1)ipset create blocklist hash:net ipset add blocklist 1.2.3.0/24 iptables -A INPUT -m set --match-set blocklist src -j DROP第三手工维护黑白名单是低效的。我在实际项目中更推荐“自动封禁联动”流量检测系统发现异常后通过API自动把攻击源IP写入防火墙黑名单攻击停止后自动解除整个过程不需要人盯着。这种动态黑白名单配合限速能兜住很多“半自动化攻击”。比如检测到某个IP在10秒内发起超过50次请求且成功率极低就判定为扫描行为自动拉黑24小时效果比人工快得多。2.3 黑白名单的局限为什么单靠它守不住DDoS如果攻击者只有100个固定IP黑白名单完全够用。但真实的DDoS攻击源往往是动态变化的。僵尸网络里的肉鸡分布在全球各地IP五花八门而且攻击者还会故意用伪造源IP的反射式攻击黑名单里记录的源IP根本不是真实攻击者。这时候就算你封了十万个IP攻击流量也依然畅通无阻。黑白名单还有一个隐蔽的问题是误判。黑名单还好最多是把某个地区的正常用户误伤白名单如果配置失误比如漏掉了某个正常业务模块的服务器IP那整个业务就直接瘫痪了。我处理过一个客户把白名单配成了只允许办公网访问结果线上的用户订单接口全被拒了排查了大半天才发现是白名单里少加了一个短信服务商的IP。所以我在项目里的原则是黑白名单只做“第一层过滤”和“最后精准清理”中间的大规模防御交给限速和流量牵引。你封禁一个IP的成本是秒级但攻击源变化也是秒级真正能拉开防御差距的是后面这两种技术。3. 限速策略让流量“慢下来”也能挡住攻击3.1 限速的核心机制令牌桶与漏桶的日常类比限速的本质是给流量设定一个“红线”超过红线的请求要么排队、要么丢弃、要么降级处理。它和黑白名单的区别在于黑白名单是“是/非”判断限速是“多/少”控制。DDoS攻击的流量特征是“突然暴涨且持续”限速的作用就是在“暴涨”的那一刻把超出业务承受能力的部分拦在外面。实现限速的算法很多最常用的是令牌桶和漏桶。打个比方令牌桶就像是银行柜台系统按固定速率往桶里放令牌每分钟放比如100个。每个请求到来时必须拿走一个令牌才能被处理令牌用完就只能排队或等待下个周期。桶的容量burst决定了短时间内允许的突发量相当于柜台外面能站多少人排队等候。漏桶算法则像是一条固定速度的传送带不管上游一下子倒进来多少包裹传送带都按每秒30件的速度往前走多出来的包裹只能堆在入口。相比令牌桶漏桶对突发流量的容忍更差但输出速度绝对平稳。在Web服务器上具体配置时nginx的limit_req用的就是令牌桶思路。下面这个配置把每个IP的请求速率限制在每秒5次允许突发10次limit_req_zone $binary_remote_addr zonereq_limit:10m rate5r/s; server { location /api/ { limit_req zonereq_limit burst10 nodelay; } }这里有个容易踩的坑burst参数如果设大了等于是给攻击者开了一个“大后门”。比如rate5r/s、burst100那攻击者瞬间发100个请求还是会被放行虽然总量有限但足以拖垮一些单机应用。burst要结合业务实际情况来定我一般建议不超过rate的2倍。3.2 不同层级的限速方案从SYN到HTTP全链路限速不只是在nginx上做。一个完整的分层限速方案应该覆盖网络层、传输层和应用层。网络层限速一般做在硬件路由器或交换机上用police动作直接丢弃超出设定速率的流量。这种方案的优点是处理性能极高不占用服务器CPU缺点是配置粒度粗没法区分“这个IP是真人还是攻击者”。它主要用于保护链路带宽防止某个方向上的大流量把整个链路打死。传输层限速针对的是连接数和SYN请求速率。比如在入口防火墙上限制每个源IP每秒新建TCP连接数不超过20超过就丢弃限制并发连接数不超过100。这类规则对SYN Flood特别有效能在握手阶段就把大量伪造连接请求拦截掉。Linux内核里改半连接队列长度也是一种办法但那是“被动挨打”只能增加一点缓冲治标不治本。应用层限速就是我们最常见的QPS限制和并发限制。除了nginx的limit_req之外还常用limit_conn限制单IP并发连接数limit_conn_zone $binary_remote_addr zoneconn_limit:10m; server { limit_conn conn_limit 10; }这行配置的意思是同一个IP最多同时占用10个连接多余的直接拒绝。对防止CC攻击爬虫大量占住连接很有效。再配合验证码当某个IP请求频率超过正常阈值时不是直接返回403而是要求它完成一个JavaScript挑战或滑动验证把真人用户和脚本区分开。这样既不会误伤真人也能让低成本的攻击脚本知难而退。3.3 限速的调优经验别让你的“盾牌”变成“自杀开关”限速最大的风险是误伤正常用户。我见过最典型的案例运维拍脑袋把QPS上限设成50结果活动期间真实用户一拥而上直接触发限速整站报错用户全跑了。做限速一定要先看业务基线数据不要凭感觉。怎么设定阈值方法是观测正常情况下的峰值指标比如过去30天同时刻的QPS、并发连接数、单用户请求频率取P95甚至P99分位值再乘以1.5到3倍作为限速阈值。这样正常业务即使有突发也不会被误伤攻击流量要想突破阈值得付出比正常用户高出数倍的代价。还有一个经验是“限速不等于一刀切拒绝”。更好的做法是分梯度处理超出阈值1倍返回429并降级处理超出2倍启用验证码超出5倍才真正丢包。这种“先礼后兵”的策略体验感好得多特别是对电商、游戏这类有突发流量特征的业务。另外我建议限速规则要区分业务接口的敏感程度。登录接口、短信接口、搜索接口这类“肥接口”要单独限速且阈值更紧静态资源接口则基本不限。否则你用同一个限速策略管所有接口攻击者只要挑一个不常限速的接口打防御就算破了。4. 流量牵引把攻击流量引到“清洗池”里4.1 流量牵引的原理路由级手术当攻击流量大到防火墙和服务器都扛不住的时候继续在本地硬扛就是“螳臂当车”。流量牵引的思路很直接不动你的源站而是通过路由层面的操作把发往你IP的流量“搬”到另一个地方去处理。这个地方可以是黑洞路由也可以是专门的清洗设备或云清洗中心。黑洞路由是最粗暴也最有效的牵引方式。操作是在路由器上把受害IP的下一条指向null0接口到达的数据包直接被内核丢弃。效果立竿见影攻击流量瞬间消失代价是正常业务也跟着一起“消失”了。所以黑洞路由永远只能是救急手段不能是常态化方案。更高级的牵引是通过BGP协议实现。你的网络如果和上游运营商建立了BGP会话当攻击发生时可以向外宣告一个更精确的路由比如把某个攻击IP段指向清洗设备让去往该IP段的大流量自动流到清洗设备。清洗设备把攻击流量识别并过滤掉再把剩下的干净流量通过GRE隧道回注到你的源站。这就是完整的“清洗回注”流程。Anycast清洗是另一种思路适合有多个机房节点的场景。多个节点同时宣告同一个IP全球的流量根据BGP自动分散到不同机房攻击流量被天然分摊。单个节点即使被打瘫其他节点还能继续提供服务攻击者需要同时打所有节点才能成功难度大幅提高。4.2 流量牵引的三种落地方式对大多数中小团队来说最实用的流量牵引方式是云清洗服务也就是通常说的“高防IP”。原理很简单你的源站IP对外隐藏对外暴露的是高防IP。攻击流量打向高防IP清洗中心先扛住过滤器把攻击包剥掉再把剩余正常请求转发给你的源站。部署时要改DNS解析或让流量先经过高防节点过程不复杂但要注意高防IP的清洗能力上限和费用之间的平衡。自建清洗体系则适合有独立机房和自治域的企业。核心是在骨干路由器上配置RTBH远程触发黑洞或Sinkhole机制。RTBH的意思是由检测系统远程触发路由器把攻击IP引流到黑洞或指定检测设备自动化程度高几分钟内完成切换。Sinkhole则是把攻击流量引到一个专门用来“接受攻击”的服务器上便于分析和追踪攻击源。第三种是运营商联动牵引。有些攻击量级超出了自建出口的承受范围这时候需要和运营商提前约定在攻击发生时按预案把流量导入运营商侧清洗平台。关键是要提前把BGP会话、牵引预案、恢复流程都测试过不能等到攻击发生时才联系运营商。我见过太多团队没有提前做联调真出事时运营商侧配合流程走了一天业务早就被打停了。4.3 流量牵引的坑牵引并不是按一下按钮那么简单第一个坑是误伤。牵引是把整段IP的流量都引走如果清洗设备没有足够的带宽和过滤能力或者清洗策略太激进正常用户的请求也会被一起丢掉。我踩过一次某个客户把所有流量牵引到云端清洗忘记调整清洗阈值结果正常搜索引擎抓取、监控探针这些“低俗流量”全部被当成攻击清洗掉导致业务数据同步中断最后还要人工加白名单恢复。第二个坑是回注延迟。清洗后的干净流量要通过隧道回注源站这条回注链路的带宽必须预留。很多团队只盯着入口带宽忽略了回注带宽结果攻击是抗住了正常业务反而因为回注链路拥塞而变慢。第三个坑是路由震荡。BGP牵引配置错误或频繁触发会让上游路由不断更新严重的会引发全网路由抖动。所以牵引操作必须配合自动化检测系统并且设置“冷静期”——攻击停止后不要立刻撤销牵引观察一段时间再恢复防止攻击者反复拉扯路由状态。5. 黑白名单、限速、流量牵引的深度对比5.1 核心对比一张表看清三种技术的边界很多人在选型时经常问“到底哪种技术最好”实际上答案永远是“看场景”。我把三种技术在几个关键维度上的差异整理成一张表方便对照对比维度黑白名单限速流量牵引工作原理精确匹配IP/特征速率与连接数控制路由级流量搬移响应速度秒级到分钟级毫秒级秒级到分钟级路由收敛时间精准度高能精确到IP中按速率批量处理低以IP段为粒度误伤概率低白名单场景除外中突发流量易误伤高牵引期间整段受影响资源消耗小中大需额外带宽和设备部署成本低中高日常维护规则量大时易失控需持续基于基线调参需测试和预案应对攻击类型IP固定的CC/扫描连接耗尽、高频请求带宽耗尽的大流量攻击主要风险追不上动态攻击源参数不准会误杀误伤正常业务、路由风险延迟数值上限速的毫秒级是设备本地处理的速度黑白名单封禁要等检测系统下发规则所以严格说是秒级到分钟级。流量牵引最慢但它的优势不是快而是“能装下别人装不下的流量”。5.2 不同攻击场景下的选择顺序面对攻击时我通常按这个思路决定优先用哪种手段如果攻击带宽已经接近甚至打满链路不用犹豫先流量牵引。再好的黑白名单和限速在链路被占满时也没有出手机会因为攻击包已经堵在门口了。牵引到清洗中心或黑洞先把链路释放出来。如果攻击是SYN Flood这类耗尽连接型的流量不算太大优先做传输层限速限制新建连接速率、控制半连接队列同时在防火墙上封禁高频发起SYN的源IP。这种组合能快速止血又不会误伤太多正常用户。如果攻击是应用层CC流量量级小但请求特征明显重点做应用层限速和动态黑白名单。比如设置单IP QPS阈值超的弹验证码检测到某个IP持续请求高消耗接口直接加入黑名单。如果是混合攻击典型场景是攻击者先用大流量打你带宽同时用小流量CC打你接口那必须三层联动边缘层牵引清洗大流量接入层限速保正常连接应用层黑白名单和验证码挡CC。这种场景最能体现三种技术协同的价值。5.3 推荐架构自动化分层防御链路我把实战中最有效的架构总结成一条自动化链路核心原则是“能在外层解决的绝不打到内层”。最外层是检测与牵引层。流量分析系统NTA/NetFlow持续监测入向流量一旦判断带宽占用或连接数超过阈值自动触发牵引策略把流量导向云清洗中心或黑洞设备。同时把攻击特征同步给下游防火墙。这里的关键是检测系统必须能区分“正常业务高峰”和“攻击流量”我建议用基线学习加人工确认的双机制避免半夜误判把业务牵引到黑洞里。中间层是防火墙和负载均衡。清洗后的流量回注到接入层时防火墙按动态黑名单继续拦截漏网的攻击源负载均衡对所有流量进行限速整形保证到达Web服务器的流量是平稳且可预测的。这一层的目标是“即使有少量漏网攻击流量也不能让它干扰正常业务”。最内层是应用层。WAF检查应用层攻击特征Web服务器在Nginx层做QPS和并发限制再配合验证码机制兜底。如果最内层看到某个IP频繁触发限速规则就把它的特征反馈给中间层防火墙动态升级为黑名单。这样黑白名单不是“死规则”而是被检测系统喂养的活规则。这套架构跑起来之后我可以告诉你一个真实的数字一个中型的电商业务源站在遭遇80Gbps UDP Flood加并发CC混合攻击时从检测到牵引再到恢复业务整体时间可以控制在3到5分钟内源站本身基本无感知。对比之前纯靠本地防火墙硬扛效果好了一个量级。6. 常见问题与排查技巧实录6.1 常见问题速查表先放一张速查表都是我被问过最多的问题直接按症状查方案。问题现象可能原因排查思路牵引后业务丢包率仍然很高回注链路带宽不足或清洗策略过严检查回注链路利用率调宽清洗阈值必要时增加回注带宽黑名单封了IP攻击还在持续攻击源IP动态变化封禁速度跟不上放弃人工维护上自动封禁联动并配合限速兜底限速上线后正常用户报错阈值设置过低误伤了正常突发流量参考业务基线调高阈值用验证码替代直接拒绝攻击流量不大但网站很卡不是带宽问题是连接数或应用线程耗尽查并发连接数、半连接队列、后端线程池状态做完等保测评后被要求做DDoS防护等保2.0明确要求可用性防护能力在边界部署流量检测与清洗设备留存攻击处置日志多大流量能打瘫一个普通网站取决于链路带宽和防护冗余通常达到业务总带宽1.5倍并持续几十秒就能造成服务不可用最后一个问题对应很多刚入门的朋友都关心的“攻击量级评估”一个普通的IDC机房链路带宽如果是1Gbps那么攻击流量超过1Gbps就已经能造成卡顿超过1.5Gbps持续几分钟基本可以确认服务不可用。如果是云上业务要看云厂商给的基础防护带宽和是否开启高防量级评估逻辑是一样的攻击流量超过防护能力服务就会出问题。6.2 攻击发生时的实战排查流程攻击发生的那一刻最忌讳的是慌了神到处点鼠标。我建议按固定步骤走第一步先看三个数入向带宽、并发连接数、源站CPU负载。这三个数能直接告诉你攻击属于哪个层面。带宽爆了是带宽耗尽型连接数爆了是连接耗尽型带宽不高但CPU飙了多半是应用层攻击。第二步抓包看五元组特征。登录防火墙或服务器抓10秒的流量观察源IP是否分散、目标端口是否集中、包大小是否均匀。如果源IP极其分散且目标端口只有80基本可以断定是TCP层DDoS如果源IP集中在少数几个网段且请求的是特定URL那就是CC攻击。这个判断决定了你接下来是去配置防火墙规则还是去调Nginx限速。第三步快速止血。大流量攻击优先牵引哪怕先用黑洞路由把业务停了也要先把链路保下来再慢慢恢复中等流量攻击直接封禁加限速应用层攻击开验证码并动态拉黑。第四步是恢复后的复盘。别以为业务恢复了就结束了。保存攻击期间的抓包文件、流量报表、防火墙日志和规则变更记录花半小时把这些数据整理成报告。复盘的核心不是“谁攻击了我们”而是“我们的防御链路哪里产生了延迟下一次怎么做到更快”。关于测试补充一句验证防护策略效果请使用合法压测工具并只在自有环境下进行。比如用wrk、JMeter压自己的Web服务用tcpreplay回放流量验证防火墙规则但绝不要对未授权的目标发起任何流量测试这条红线必须守住。我个人的体会是黑白名单、限速和流量牵引这三者单独拿出来都不算新鲜但把它们串成一条“检测-牵引-限速-封禁-复盘”的完整链路才是抗DDoS真正难的地方。黑白名单帮你精准切除已知病灶限速帮你抑制异常流量蔓延流量牵引为你争取到宝贵的生存空间。每次攻击都是一次压力测试每扛过一次你对自己的系统边界就会更清楚一些。下一次告警再来的时候你就知道该动哪个开关而不是半夜爬起来对着电脑发呆。