抗 DDoS 的核心黑白名单、限速、流量牵引技术对比分析做运维这些年我经历过最绝望的一次深夜值班就是业务被 DDoS 打到完全失联机房交换机上黑洞路由一敲全网段流量直接丢弃业务方在群里连环 问我为什么用户也进不来了。那一刻我才真正意识到DDoS 防御不是买台高防设备就能高枕无忧而是一场和攻击流量抢时间、抢带宽、抢资源调度能力的攻防战。而这场攻防战里最基础也最容易被忽视的三板斧就是黑白名单、限速、流量牵引。这篇文章不聊那些花里胡哨的厂商宣传只讲这三项技术各自的原理、适用边界、选型思路以及在真实场景里怎么搭配使用。先说一个我踩过的坑刚接手公司线上业务时我一度以为黑白名单是万能的。攻击来了加 IP 黑名单扫到恶意源封禁了事。结果某次遇到分布式反射放大攻击源 IP 成千上万而且全是伪造的黑名单根本封不过来业务照样被打趴。后来换用限速策略在接入层对 UDP 流量做速率限制情况有所缓解但真正解决问题还是靠流量牵引到清洗中心把攻击流量在远端过滤掉。所以这三项技术不是谁替代谁的关系而是从单点封禁到资源博弈再到流量调度的层层递进。下面按我的实际使用体验把黑白名单、限速、流量牵引逐一拆开讲最后再给出一套完整的选型对比和组合方案。1. 黑白名单最基础的访问控制但别把它当成万能药黑白名单大概是所有网络防护手段里最直观的一种了。它的核心逻辑就是让谁进、不让谁进——白名单是只允许名单里的源访问黑名单是拒绝名单里的源访问。实现层面可以放在防火墙、负载均衡、WAF、CDN 边缘节点甚至业务代码里但不同位置的拦截效果和成本差别非常大。1.1 黑名单的真正短板分布式与伪造源黑名单最典型的应用场景是封禁已知的恶意 IP。比如你在 Nginx 日志里发现某个 IP 在疯狂刷登录接口直接deny掉几秒钟就能止血。这种打法在小规模、有明确源 IP 的攻击下非常有效规则简单、开销极小。但放到真实的 DDoS 场景里黑名单有三个硬伤第一攻击源是分布的。现在的 DDoS 基本靠僵尸网络动辄几万到几十万个源 IP而且很多来自被入侵的家用路由器、摄像头等 IoT 设备地理分布极散你根本没可能在攻击发生前就把它们全部列进名单。第二源 IP 可以是伪造的。尤其是 UDP 反射放大攻击攻击者用伪造的源 IP 发送小流量请求到放大服务器如 NTP、DNS、Memcached放大服务器把大流量响应发到伪造的源地址也就是你的业务 IP。这种情况下你看到的攻击源其实是无辜的放大服务器封禁它们不仅没用还可能误伤正常服务。第三黑名单有更新延迟。从攻击开始到日志分析出恶意 IP再到同步到所有防护节点这个时间窗口里业务已经在被打了。对于只需几分钟就能打垮小带宽业务的攻击来说黑名单的响应速度完全跟不上。1.2 白名单的正确打开方式内网、API 与高价值接口白名单的适用场景比很多人想得更广但它不是用来对抗 DDoS 的而是用来减少暴露面的。我的经验是白名单适合用在以下几个地方管理端口比如 SSH、数据库端口、运维跳板机公网只允许办公室出口 IP 访问其他一概拒绝内部 API比如服务间调用、回调接口通过白名单限制来源省得被扫描器天天探测高价值业务接口比如支付回调、短信发送接口只允许特定来源调用可以从根上防止恶意刷接口。白名单的优点非常突出规则确定、性能开销小、误判率低。但它不适合公网大范围用户访问的场景毕竟你不能预知所有真实用户的 IP。所以我的结论是白名单做收缩暴露面黑名单做已知威胁封禁两者互补但都不能独立承担 DDoS 防御。1.3 黑白名单在实践中的注意事项如果你准备在生产环境配置黑白名单有几个点值得留意。第一黑名单的封禁粒度要设计好。是封 IP、封 IP 段还是封地域封 IP 段容易误伤很多用户是动态 IP整个段里可能有正常用户封地域又挡不住国内攻击源。我一般建议按IP 优先、地域兜底的方式先封明确恶意 IP如果某个地域来源的攻击占比极高且业务本身不依赖该地域才考虑加地域策略。第二黑白名单的生效层级要想清楚。在源站防火墙封虽然能挡住进入源站的流量但攻击流量已经消耗了你的接入带宽治标不治本。这就是为什么很多人发现明明封了 IP 业务还是卡因为带宽被打满了封禁动作根本来不及救带宽。所以对 DDoS 来说黑名单一定要尽量下层到靠近攻击源的位置比如 CDN 边缘、清洗节点而不是只做在源站。第三白名单千万别做死在代码里写死 IP 的蠢事。我见过有同事把公司出口 IP 硬编码在配置文件里结果运维换了一条宽带线路所有人都连不上管理后台了排查了半天才发现是出口 IP 变了。白名单要集中管理、支持动态更新最好能跟运维的资产管理联动。2. 限速与攻击流量博弈资源用让出带宽换保住可用性限速与黑白名单最大的区别在于黑白名单是拦限速是让。当攻击流量大到你无法全部丢弃时你可以通过限制单位时间内通过的流量或连接数把损失控制在业务能承受的范围内。用一个不太严谨但很好懂的说法限速不是不让你进门而是让你排队慢慢进。2.1 限速的常见维度带宽、连接数、请求速率限速在 DDoS 防御中一般从三个维度来做带宽限速限制某个源 IP、某个协议或某个端口的最大带宽。比如对 UDP 流量设置 500Mbps 上限超过部分直接丢。适合应对 UDP Flood 这种大流量型攻击。连接数限制限制单 IP 并发连接数或新建连接速率。比如设置单 IP 最多 1000 个并发连接超过的丢弃或拒绝。适合应对 SYN Flood、CC 攻击这种消耗连接资源的攻击。请求速率限制限制单 IP 每秒请求数。这个在 Web 层最常用比如 Nginx 的limit_req模块对登录、查询类接口做 QPS 限制。适合应对 HTTP Flood即 CC 攻击。这三者不是互斥的往往要组合使用。我的经验是网络层优先限带宽和连接数应用层优先限请求速率而且限速阈值要留出足够的业务余量否则正常业务的高峰流量也会被误伤。2.2 限速的真正难点阈值怎么定限速说起来简单做起来最头疼的是阈值设置。设太小正常用户会被误伤业务直接自残设太大攻击流量照样能把资源耗尽限速形同虚设。我通常的做法是分三步先观察一周以上的正常流量峰值取一个 P95 甚至 P99 值作为基线再把限速阈值设置为基线的 1.5~2 倍给突发流量留余量最后上线后持续观察限速触发次数如果频繁触发说明阈值偏低业务真有那么大的流量需要上调。但这只是单维度 IP 的限速实际攻击往往是叠加的。比如 SYN Flood 来了单 IP 的连接数限制可能立刻被触发但攻击者会不断换源 IP 或者直接伪造 IP这时候单 IP 限速就失效了。所以分布式场景下还需要配合总连接数限制总带宽限制这样的聚合维度限速也就是对某个接入设备、某个端口下的全局流量做整体限制超过阈值后按比例丢弃或随机丢弃。说白了就是保可用性优先——宁可丢一部分正常用户也不能让业务整体不可用。2.3 限速与业务体验之间的平衡限速最大的代价是误伤正常用户所以设计时一定要想清楚丢谁和丢多少的问题。目前在业内比较常见的做法是先按会话状态区分还没完成 TCP 三次握手的半连接、已建立连接但出现异常行为的会话优先丢然后再对已建立的正常会话尽量保活不轻易断。举个例子我们曾经对一个 API 网关做全局 QPS 限制一开始简单粗暴地限制每秒总请求数结果用户高并发抢购时大量正常请求也被限掉了业务方差点要打人。后来改成分级限速按接口重要程度分级核心交易接口给高配额非核心查询接口给低配额再结合限流算法的平滑特性令牌桶而不是固定窗口才做到既防攻击又不误伤正常用户。注意限速不是一次性配置就完事。攻击流量会变化业务流量也有昼夜峰值限速规则要支持动态调整有条件的话最好能联动监控系统自动调参。纯手工运维在真实攻防中根本反应不过来。3. 流量牵引把攻击流量引走让清洗节点替源站挨打前面说的黑白名单和限速本质上都是在本地做防御依赖源站的带宽和算力。但遇到超大流量攻击时源站接入带宽就那么点流量一上来本地做什么都晚了。这时候必须换思路不在原地硬扛而是把流量引走。流量牵引的原理可以这么理解正常情况下用户流量直接到达源站 IP攻击流量也是直接打源站 IP。牵引要做的是通过路由协议一般是 BGP把目的 IP 的流量通告到清洗中心或高防节点让流量先经过清洗设备过滤掉攻击流量后再把干净流量回注到源站。相当于给流量加了一道绕行关卡。3.1 静态牵引与动态牵引怎么判断要不要牵引流量牵引按触发方式分两类静态牵引是提前配置好的攻击来了自动生效无需人工干预。适合业务架构固定、牵引条件明确的场景比如某些高防 IP 产品流量默认先到高防机房清洗再回源。动态牵引则是通过监控触发检测到流量异常超过阈值后自动通告路由把流量切到清洗中心。这种方式更省成本因为平时流量还是直连源站体验更好、延迟更低只有被攻击时才切换到清洗链路。动态牵引的关键在于异常检测的准确性。我经历过一次误牵引事故监控系统把业务方做压测的大流量误判为攻击自动触发了牵引结果业务公网 IP 的流量全被切到清洗中心清洗规则又把压测的正常请求给过滤了导致业务指标大跌。所以动态牵引的阈值、检测算法、切换条件一定要跟业务方充分对齐宁可延迟触发也不要乱触发。3.2 回注方式策略路由回注与隧道回注牵引完成之后清洗中心要把正常流量送回源站这一步叫做回注或回程。回注做不好清洗完了流量也回不来业务照样不可用。最常见的回注方式有两种策略路由回注和隧道回注。策略路由回注适用于源站和清洗中心二层或三层直连的场景清洗中心把干净流量直接通过下一跳发给源站简单直接但如果源站 IP 和清洗中心之间的链路也堵了回注流量照样进不去。隧道回注更适合跨地域、跨运营商的场景比如源站部署在 A 地移动机房清洗中心在 B 地电信机房那就需要在源站和清洗中心之间建立 GRE 隧道或 VxLAN 隧道清洗后的流量通过隧道送到源站。隧道回注可以绕过拥堵链路但要额外处理 MTU 问题隧道封装会增大报文可能导致分片配置不好反而引发丢包。3.3 流量牵引和 Anycast大厂为什么爱用 Anycast聊流量牵引就绕不开 Anycast。这是目前大型云厂商和 CDN 厂商最常用的 DDoS 缓解手段之一。Anycast 的原理是多个地域的节点发布同一个 IP 段路由协议BGP会自动把用户流量调度到距离最近的节点。攻击流量也一样会被分散到多个节点每个节点只承受一部分攻击流量整体抗压能力成倍提升。你可以在全球部署几十个 Anycast 节点攻击流量再大分摊到每个节点后也能扛得住。对我们这些非大型厂商的用户来说直接部署 Anycast 不太现实但可以使用云厂商提供的 Anycast 防护 IP 或高防 CDN。这类产品的底层就是 Anycast 清洗集群攻击流量在全国或全球范围内被分散吸收源站看到的压力小很多。不过 Anycast 也有个坑因为流量被调度到最近的节点而源站可能只在一个地域回源链路就变成了清洗节点 - 源站的专线或隧道配置复杂度会明显上升。我见过有团队用了 Anycast 高防后回源链路没配置好导致回源流量比原来还慢用户投诉变多。所以决定用 Anycast 前一定要先梳理好源站的回源链路和带宽规划。4. 网络层与应用层不同攻击类型下三类技术的分工聊完三项技术各自的原理和边界你会发现一个事实DDoS 不是单一类型的攻击它是一族攻击的总称。不同攻击类型应对的技术栈完全不同。这里我按网络层和应用层两条线梳理三类技术在不同攻击下的分工。4.1 网络层大流量攻击带宽耗尽型典型代表是 UDP Flood、ICMP Flood、DNS/NTP/SSDP 反射放大。这类攻击的特点是流量极大、以耗尽带宽为目标常见攻击规模从几十 Gbps 到几 Tbps 不等。应对优先级是流量牵引最优先靠清洗中心或 Anycast 把大流量摊薄限速作为第二道防线在清洗节点上对特定协议的流量做限速黑白名单在这个场景里作用有限只能在明确知道部分源 IP 时做辅助过滤。举个实际例子某个客户的业务带宽是 1Gbps某天凌晨遭受 200Gbps 的 NTP 反射放大攻击。如果不做牵引1Gbps 带宽瞬间被打满业务完全不可用黑名单和限速在本地做再多也没用。这时只有把流量牵引到清洗中心在清洗端把 UDP 123 端口NTP 协议的大流量识别并丢弃再把干净流量回注给源站业务才能活下来。4.2 连接耗尽型攻击SYN FloodSYN Flood 不算超大流量攻击它的核心是消耗你的连接表资源。攻击者发送海量 SYN 包但不完成三次握手导致源站半连接队列被占满正常用户无法建立 TCP 连接。应对这类攻击限速和黑白名单都能发挥一定作用通过限制半连接数量、限制单 IP 新建连接速率可以有效防护小规模的 SYN Flood同时识别出反复发送 SYN 而不完成握手的源 IP加入黑名单丢弃后续包。但大规模分布式 SYN Flood 就复杂了攻击源伪造 IP 时黑名单失效只能靠清洗中心的 TCP 协议栈来代答SYN-ACK完成握手验证后再转发给源站这本质上已经属于流量牵引 协议栈清洗的范畴。4.3 应用层攻击HTTP Flood / CC 攻击应用层攻击CC 攻击最狡猾因为它的流量特征和正常用户请求几乎一样带宽占用不高但能把应用服务器、数据库连接数打满让业务动弹不得。CC 攻击的应对重点有两个一是限速这是最立竿见影的可以用 WAF 规则、Nginx 限速、接口维度 QPS 限制等把高频请求的源 IP 或会话限制住二是验证挑战比如 JS 挑战、CAPTCHA、滑块验证用于区分真人访问和脚本攻击。黑白名单在 CC 攻击里辅助作用比较大因为 CC 攻击的源 IP 往往是真实 IP不像网络层伪造成本那么高识别出恶意源后直接拉黑能快速减轻后续压力。需要特别说明的是应用层攻击的防御策略不能只靠单一设备。我见过有人在 Nginx 配了一堆限速规则和封禁规则但攻击者只要一天换一批代理 IP规则就废了。所以 CC 防护要规则 验证 行为分析联动这套体系展开讲又是一篇文章这里先记住一个原则应用层防护的终点不是流量控制而是用户身份验证。4.4 四层与七层云厂商高防产品的设计逻辑如果你用过云厂商的高防 IP会发现它们普遍把四层防护和七层防护分开卖。四层高防主要处理网络层和传输层攻击七层高防则在四层基础上叠加 WAF 能力处理 HTTP 层面的攻击。这里面的架构逻辑就是四层防护靠流量牵引 清洗集群 协议栈优化把大流量攻击挡在外面七层防护则要把流量上送到七层清洗集群做 HTTP 解析、CC 识别、规则匹配再决定放行还是拦截。两者叠加时流量路径会更长延迟会有额外增加。所以业务对延迟敏感时要谨慎决定是否开启七层防护。5. 选型对比与组合方案不买最贵的只买最合适的把三类技术放在一起做横向对比可以更直观地看出各自的能力边界。对比维度黑白名单限速流量牵引核心思路有选择地放行/拦截限制单位时间内的流量/请求把流量引导到清洗节点处理主要作用位置应用层、接入层、边缘节点接入层、清洗节点、应用层路由层、网络边界、清洗中心适用攻击类型已知源 IP 的攻击、扫描探测连接耗尽型、CC 攻击、小规模流量攻击大流量带宽耗尽型攻击误伤概率中黑名单封段容易误伤高阈值设置不当会自伤低清洗算法决定响应速度快秒级生效快配置即时生效中依赖检测触发和路由收敛部署成本低防火墙/WAF 即可低到中需要调参高需要清洗中心/高防资源单独抗大流量攻击能力几乎无效有限受限于本地带宽有效核心手段从这个表可以清楚地看到三项技术的能力是互补的单独拿出来都不足以构成完整的 DDoS 防御体系。真实生产环境里我的经验是搭一套纵深防御组合第一层边缘 CDN 或云 WAF利用 CDN 的节点分散流量同时在边缘做黑白名单和限速把一部分攻击拦截在最外层。第二层高防 IP 或流量牵引当边缘扛不住时通过 BGP 牵引把流量切到清洗中心做协议栈和流量特征清洗。第三层源站自研防护在源站保留黑白名单、连接数限制、应用层限速规则作为最后一道兜底。这三层之间不是静止的而是动态配合的。我见过比较好的实践是用自动化编排工具把高防产品的攻击告警、流量监控数据、清洗触发状态打通攻击超过边缘阈值时自动开启高防清洗清洗稳定后再自动切回直连。这样可以最大限度减少人工介入时间也能避免长期走高防链路带来的额外延迟。提示选型时不要只盯着最大防护能力这个指标。很多人买高防只看防御峰值不看清洗节点与源站之间的链路质量结果攻击倒是防住了正常用户访问延迟却高得离谱。对高防方案一定要做回源链路和回注链路的质量评估最好用攻击演练来验证真实效果而不是只看厂商宣传页上的数字。6. 攻击演练与效果验证理论说得再好不打一仗不知道深浅最后我想专门聊一下攻击演练。这是很多团队最容易忽略的一环——买了高防设备、配了限速规则、做了黑白名单就以为 DDoS 防御已经到位了。等你真挨打时才发现规则没生效、牵引没触发、回注链路是堵的那就晚了。我强烈建议每季度至少做一次 DDoS 攻击演练方法也很成熟在业务低峰期用测试工具对业务 IP 发起模拟攻击逐步加大流量观察防护链路在不同阶段的表现。整个过程要记录几个关键指标检测触发时间从攻击开始到监控系统发出告警用了多久牵引切换时间从告警到流量实际切到清洗中心用了多久清洗有效率清洗掉多少攻击流量干净流量回注是否正常业务可用性演练期间源站 CPU、带宽、错误率的变化曲线。这些指标能帮你判断一套 DDoS 防御体系到底是不是纸面防御。我自己就通过演练发现过三个问题一是源站防火墙的会话表太小清洗后的正常流量一多直接把会话表打满二是回注隧道的 MTU 设置不对大包被丢弃导致业务偶发卡顿三是监控阈值设得太高攻击已经持续十分钟才触发牵引而这类分布式攻击十分钟足以让业务完全瘫痪。这些问题不演练永远发现不了。若条件有限没法做真实攻击演练起码要做链路验证用大文件下载测试牵引后业务带宽是否正常用长连接测试清洗后的连接稳定性再人工检查一遍黑白名单、限速阈值和业务峰值的匹配度。把基础项验证到位真出事时至少不会犯低级错误。在国内做业务尤其是涉及金融、政务、游戏、电商这类对可用性要求极高的行业等保合规通常也会对 DDoS 防护能力提出明确要求这本身也是推动团队把防御体系落地的一个动力。但合规只是底线真正的目标应该是让业务在被攻击时依然能保住核心功能可用。黑白名单、限速、流量牵引这三类技术正是达成这个目标最基本的根基把它们的定位和能力边界吃透你才不至于在大流量攻击来临时手忙脚乱也更清楚每一分安全预算该花在什么地方。