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 主动防御这件事最难坚持的不是上线设备、配置策略、跑通演练而是把它变成日常习惯。流量健康表连续一个月没有异常的时候人最容易松懈。但攻击通常就是在你最松懈的时候来的。保持检测告警灵敏、保持切换链路可用、保持策略不过期这三件事看着不起眼却是整个主动防御体系里真正保命的东西。