1. 为什么说“被动挨打”是体系问题，不是设备问题
在做企业的 DDoS 防护体系之前，我一直以为“主动防御”靠的是设备选型：只要买够大、够强的清洗能力，攻击来了自然扛得住。但真正经历过几轮大流量攻击之后，我才明白一个很扎心的结论——大多数企业被打得毫无还手之力，不是输在流量带宽上，而是输在响应链条上。攻击进来的一瞬间，从“发现异常”到“确认攻击”，再到“执行切换清洗”，每一步之间都卡着人的判断、群的沟通、供应商的支持。整个链条里只要有一个环节拖延，业务的损失就会成倍放大。
1.1 被动防御的典型操作，看着眼熟吗
我接触过不少公司，安全团队所谓的“DDoS 防护”其实就是这么一套组合拳：机房或者云厂商默认带了几百 G 的流量清洗，先开着；再挂一个 CDN，把域名接入进去；平时大家几乎不看流量监控，等到业务同事反馈“网站打不开”“接口超时”，才开始登录后台翻日志。
这中间有几个特别经典的被动表现：
- 靠群聊确认攻击。监控平台报警了，先截图发到群里问“大家网络卡不卡”，然后逐层确认是机房问题、线路问题还是真的被攻击了。一来一回十几分钟就没了。
- 临时找人开高防。很多小团队的清洗能力是“按需开通”的，攻击来了才去联系供应商，提交工单、审批流量调度方案，等真正把流量切过去，业务已经断了半小时。
- 只能防御一种攻击。有的团队只在大流量攻击时手动切换，面对 CC 攻击、慢连接攻击这类不需要很大带宽就能拖垮业务的攻击方式，根本识别不出来，业务自己被慢慢耗死，还没意识到是 DDoS。
说白了，被动防御的状态就是：设备是有的，但检测靠人肉，决策靠猜，切换靠临时协调。这种模式在平时看起来“好像没什么问题”，因为不被打的时候确实岁月静好。
1.2 我从被动切换到主动的分水岭
让我真正下定决心重建防护体系的，是一次很典型的“连环攻击”。先是晚上 11 点来了个短时大流量，我们按预案切到了高防 IP，业务刚恢复；结果过了 20 分钟，对方又来了一波应用层 CC，直接打到回源源站——因为我们的回源 IP 没有隐藏好，高防背后那台服务器照样被慢速请求拖垮。当天晚上我们做了五六次转移，每次以为处理完了，下一波攻击就来打另一个薄弱点。
那次之后我做了一个关键动作：把所有“靠人盯”的环节列成一张清单。检测需要哪些指标、切换由谁按什么顺序执行、清洗策略要提前布防到什么粒度、供应商的响应时限是多少、回源链路有没有保护。逐项补齐之后，我意识到主动防御不等于买更多带宽，而是把“攻击可能来打你的每一个面”都提前想清楚，给每个面配好检测、决策、执行的手段。
这就是标题里“被动挨打”和“主动防御”之间最本质的区别。被动的人想的是“这次扛过去”，主动的人想的是“下次怎么一眼就看出来、一键就切过去”。
2. 搭建主动防御体系之前的选型决策，先想清楚这三点
主动防御的第一件事不是买设备，而是回答三个问题：流量入口在哪里、核心资产暴露在哪里、清洗能力放在哪一层。很多团队一上来就选高防产品，结果发现和自己现有的网络架构冲突，流量绕了一圈才切到清洗点上，延误了最佳处理窗口。
2.1 三条路线：自建、云清洗与混合架构
我根据实际经验，把企业最常见的做法分成三条主线，各有适用场景。
| 路线 | 核心做法 | 适合场景 | 主要短板 |
|---|---|---|---|
| 自建清洗 | 在核心网络出口部署专用清洗设备，自己维护检测和引流策略 | 对数据主权要求高、流量可控的大企业 | 设备成本和运维成本高，应对超大流量时带宽需要冗余 |
| 云清洗/高防 | 通过 DNS 或 BGP 将业务流量引到清洗服务商的清洗中心，清洗后再回源 | 大多数中小企业、互联网业务 | 回源链路可能成为短板，依赖供应商的响应速度 |
| 混合架构 | 日常流量直连源站，检测到异常时才动态切换至清洗中心 | 兼顾性能和成本，适合多数成熟业务 | 调度逻辑复杂，切换失效时风险较大 |
大多数企业最终走的都是第三条路。混合架构的核心理念是“平时不绕行，战时才切换”，这和被动防御里“一直把所有流量泡在高防里”的思路不一样。日常低攻击风险时，用户访问链路短、延迟低；检测到攻击特征之后，才把流量切去清洗，既保证了业务的常态体验，又保留了防御能力。
2.2 流量调度设计：DNS、BGP 与高防 IP 怎么配合
选好了架构，真正容易出问题的是流量调度。这里有几个核心概念，我建议每个做 DDoS 防护的人都要搞清楚。
DNS 调度是最常见的切换手段。平时域名解析到源站 IP，攻击来了解析切到高防 IP 上。优势是灵活，缺点是生效时间受 TTL 缓存影响，切过去之后老客户端可能还停在源站 IP 上，继续被攻击。
BGP 引流是运营商层面的调度方式，通过路由通告把自己的 IP 段指向清洗中心，所有的流量先在清洗中心过滤一遍再回源。优点是切换速度快，对用户无感知；缺点是需要运营商配合，而且不是所有服务商都支持。
高防 IP + 隐藏源站是很多云清洗方案的常用组合。入口 IP 全部替换成高防 IP，源站 IP 只允许从清洗中心回源的流量进入。这个方案看起来简单，但必须有配套的“源站白名单”机制，否则回源端口被人扫到，攻击者绕过清洗直接打源站，一切等于白搭。
我在配置混合架构时踩过一个坑：高防策略里把所有回源 IP 都加进白名单，结果把内部办公网出口也当成回源源加进去了，某次内部运维批量拉取数据时被建立成了“CC”，差点被清洗规则误杀。所以做白名单之前，一定要把回源 IP 段边界圈清楚，规则越细，误伤越少。
3. 把“发现攻击”变成可量化的检测联动机制
主动防御和被动防御最直观的区别，体现在“能不能第一时间发现”上。被动防御靠人刷监控，主动防御靠指标说话。我个人的经验是：检测指标宁可多不可少，但一定要分层，不要把所有东西都堆在一个视图里。
3.1 网络层检测指标：SYN Flood、反射放大一网打尽
网络层的 DDoS 大多打的是带宽和连接数，检测需要关注的核心指标有这么几个：
- 入向带宽利用率。这个看的是总流量是不是突然逼近带宽上限。不过光看总量不够，还要按目的 IP 和目的端口聚合，否则大流量平均分散在很多 IP 上，很难一眼定位。
- PPS（每秒数据包数）。很多攻击不追求大带宽，而是用大量小包把设备的包处理能力打满，带宽看起来没爆，但转发已经卡死。
- 新建连接速率与 SYN 包占比。SYN Flood 最典型的特征是 SYN 包数量暴增，而对应的 SYN ACK 返回数量忽高忽低。如果一个 IP 上每秒 SYN 包数量突然增长到平时基线的几十倍，基本不用犹豫。
- 连接表中的半连接数。Linux 服务器上用
netstat或ss看 SYN_RECV 状态的连接数量，如果长时间维持在高位，说明握手队列被占满了。
采集这些指标的工具链也很成熟：网络设备可以用 sFlow/NetFlow 导出流量数据，服务器上用 Grafana + Prometheus 拉取计数器。很多团队的问题不是没有监控，而是监控阈值设得太宽，攻击流量翻了两三倍都没触发告警。我建议阈值设定基于历史基线，比如“超过日常均值三倍并持续 30 秒”就进入观察状态，“超过五倍”直接进入预案启动流程。
3.2 应用层检测：CC 攻击、慢速连接与业务特征的交叉验证
应用层攻击是主动防御里最需要“动脑子”的部分，因为它不是靠流量大小取胜，而是靠模拟正常请求来耗尽服务器资源。判定逻辑不能停留在“请求量大”，而要做特征交叉。
以典型的 CC 攻击为例，攻击者用大量代理 IP 发 HTTP 请求，如果你只盯“每 IP 请求速率”，很容易被分布式代理 IP 迷惑。我会额外看这几类特征：
- 单一 URL 的请求频次分布。正常业务下，热门接口的请求占比会呈现长尾分布，而攻击流量通常会集中在几个特定 URL 上，尤其是动态接口、搜索接口、登录接口这类耗资源的路径。
- 请求头和数据指纹。攻击工具发出的请求，User-Agent、Accept 头、Referer 的组合往往比较单一，可以把这些字段做归一化后统计。如果某类请求头组合占比异常高，大概率是攻击。
- 慢速连接。这种攻击最阴，连接建立后不发送完整请求，一点一点挤数据，把服务器的并发连接数慢慢占满。检测指标是“建立的 TCP 连接中，长时间没有传输数据的连接数量”，超过并发上限的一半就要警惕。
检测完之后，最关键的是联动。我现在的做法是：监控平台告警 → 自动核对清洗策略是否已启用 → 通知值班人确认 → 值班人一键切换调度。每一步都要有明确的时效目标，比如“告警后 3 分钟内完成切换”，这比在群里拉人讨论快得多。
4. 一次完整的 DDoS 攻防演练复盘，从“实验”里找问题
主动防御体系建好之后，最怕的就是“纸面看起来很完美，真打起来全部失效”。所以我强烈建议企业定期做 DDoS 攻防演练。要注意，所有演练都是在自己有处置权和授权的环境里做的受控实验，事前圈定范围、观测指标、恢复手段，不能把影响扩散到生产业务之外。
4.1 演练设计与分阶段执行
我第一次组织 DDoS 演练时，就定了几个原则：分阶段施压、每个阶段有明确的停止条件、所有参与人员提前知道操作边界。
演练通常按攻击类型分三阶段：
第一阶段，模拟普通突发流量。用开源压测工具向预先准备好的测试服务发起持续几分钟的高并发请求，把带宽打到总上限的 60% 左右。这个阶段检验的是：监控是否按阈值触发告警、值班人员能否在静默状态下发现异常、告警信息是否准确指向了目标 IP 和端口。
第二阶段，模拟协议型攻击。比如短时间大量 SYN 包、畸形 TCP 报文。这个阶段检验清洗设备的协议校验能力，也检验我们的清洗策略是否真的会把这部分流量丢弃，而不是“洗了但没完全洗”。
第三阶段，模拟应用层攻击。用一批可控的代理节点模拟 CC 特征，同时穿插一部分真实业务流量。这个阶段重点看区分度——也就是清洗策略能不能把攻击流量清洗掉的同时，放行真实用户请求。
每阶段之间留半小时观察窗口，记录各项指标曲线、清洗生效时间和业务恢复情况。
4.2 从指标报表里挖出真实风险
演练结束之后，光看“最终扛住了没”远远不够。我每次复盘必盯三张图：
第一张是**“切换时间轴”**。从第一波攻击流量出现到清洗策略完全生效，总共花了多长时间？这里面有多少分钟是告警延迟、多少分钟是人工确认时间、多少分钟是切换调度生效时间。大多数企业第一次演练都会发现，真正清洗只需要几秒，但前面“人肉确认”花的时间最长，往往占总时长的一半以上。
第二张是**“回源链路流量图”**。很多演练打到清洗设备上没崩，反而崩在回源链路上。因为清洗后的“干净流量”还是要一股脑回到源站，如果源站带宽本身只有 100M，而清洗后还有 200M 的“正常流量”，源站照样撑不住。所以演练里一定要看清洗设备出口到源站入口之间的带宽峰值，而不能只看入口侧被打多大。
第三张是**“业务可用性曲线”**。用拨测工具模拟用户真实访问，记录成功率与响应时间。攻击期间如果成功率下降超过 5%，或者响应时间翻倍，需要重新审视清洗策略是不是误伤了正常请求。
我记得有一次演练结束后，所有技术指标都难看但又在预期内，唯独有个问题被我们遗漏了——切换是手工做的，操作人值班到一半去上厕所，告警响了 8 分钟没人点确认。后来我把“告警确认”改成了主备双人制，还加了自动升级机制：告警超过 2 分钟无人确认，自动通知第二联系人，再超 2 分钟自动走预设切换流程。这种问题不看演练永远发现不了。
5. 从演练到常态化，运营体系怎么落地
建防护体系不是一锤子买卖，练完之后不维护，三个月后大概率又是被动挨打。我把这套体系拆成“日常、周度、月度”三个频率来运营，每个层面盯的东西不同。
5.1 日常运营要盯的三张表
日常运营我建议在监控台常驻三张表：
| 表 | 核心字段 | 盯的目的 |
|---|---|---|
| 流量健康表 | 入向带宽、出向带宽、连接数、SYN 占比、应用请求成功率 | 发现异常趋势，比阈值告警更早预警 |
| 清洗策略表 | 各清洗策略的生效状态、命中次数、误杀次数 | 确认策略没有失效，也没有在误伤业务 |
| 回源链路表 | 源站入口带宽使用率、回源连接数、回源失败次数 | 防止清洗工作正常但回源链路成为单点瓶颈 |
这三张表不需要每时每刻都盯着，但要设好自动汇总，每天早上 9 点前推送到安全群。我特别提醒一下：清洗策略表最容易被忽略。很多人把策略配置好之后就不管了，结果某次升级把策略弄失效了，或者新业务上线后端口变了，旧策略形同虚设，攻击来了才发现没生效。
5.2 踩坑记录与避雷清单
最后聊聊我建这套体系过程中踩过的坑，权当给同行排雷。
第一，别把全部鸡蛋放在一个供应商的篮子里。哪怕你的高防带宽标称 1T，也可能被某个突发的超大流量打满。我是建议至少准备两个不同服务商的清洗通道，平时走主通道，主通道扛不住时切换到备用通道。切换逻辑要在演练里测过，不然真到关键时刻连备用供应商的联系方式都要现找。
第二，清洗规则务必设置“过期时间”。攻击结束之后，临时加的封禁规则、限速规则要能自动失效或定时提醒人工清理。我见过不少团队，攻击结束后忘了关限速，结果业务恢复后正常用户也一直被限速拦着，业务方投诉了一整天才发现是规则没撤。
第三，源站的“防御纵深”比单纯的大带宽更重要。很多时候攻击没把入口打崩，而是把源站打崩了。源站服务器上至少要做三件事：隐藏真实 IP、限制单 IP 最大连接数、对动态请求做应用层限流。这几层都是纯软件层面就能做，不额外花钱，但效果非常明显。
第四，多写剧本，少临场发挥。主动防御里最重要的一环不是技术，而是“决策预演”。谁有权决定切换、谁有权联系供应商升级防护、什么时候通知业务方、什么时候对外发布公告，都要在事前定清楚。攻击发生时，每个人的动作应该是“照着剧本走”，而不是聚在群里开会讨论。
最后再分享一个我个人最大的体会：做 DDoS 主动防御这件事，最难坚持的不是上线设备、配置策略、跑通演练，而是把它变成日常习惯。流量健康表连续一个月没有异常的时候，人最容易松懈。但攻击通常就是在你最松懈的时候来的。保持检测告警灵敏、保持切换链路可用、保持策略不过期，这三件事看着不起眼，却是整个主动防御体系里真正保命的东西。
