DDoS流量牵引应急预案

DDoS流量牵引，本质不是防御，而是“转移”。当攻击流量大到把入口带宽塞满时，在本地防火墙做任何拦截都是徒劳的，因为数据包已经把路堵死了。所以，应急预案的核心思路是：把攻击流量引到一个能“吞下”大流量的地方去清洗，再把干净流量回注到源站。这个动作必须在几分钟内完成，否则业务就等同于瘫痪。下面直接拆解一套可落地的应急流程。

很多人搞混了“清洗”和“牵引”。牵引是路由层面的调度，清洗是报文层面的过滤。应急预案首先要解决的是路由调度问题。当监测到目标IP入向流量瞬间超过带宽阈值的90%，或者业务响应超时、连接数暴增时，不要犹豫，立刻启动牵引。牵引的底层技术主要有三种：BGP引流、DNS引流和GRE隧道回注。BGP引流最干净，通过向清洗中心宣告更精确的主机路由，利用AS-Path最短优先原则把流量“骗”过去。DNS引流适合HTTP/HTTPS业务，把A记录改到清洗中心的高防IP。GRE隧道则负责把清洗后的干净流量加密送回源站，避免在回程路上被二次污染。预案里必须写清楚：你们用的是哪一种，切换的精确命令是什么，回切的触发条件是什么。

第一步，监测告警与研判。不要依赖单一维度的告警。把NetFlow/sFlow采样数据、SNMP带宽监控、业务层健康检查三者做“与”逻辑判断。如果只有带宽告警但业务正常，可能是突发正常流量；如果带宽正常但业务卡死，可能是CC攻击或慢速连接耗尽。只有三者同时报警，才定性为DDoS攻击。预案里要规定：谁有权限在5分钟内完成研判并下令切换。这个人必须是技术负责人，且备岗至少两人。

第二步，执行牵引切换。如果是BGP牵引，运维人员需要登录边界路由器，执行预先写好的Route-Map策略，将受攻击的/32主机路由指向清洗中心的下一跳，并设置Community值以便清洗中心识别。这个操作不能临时拼凑，必须提前把配置脚本写好、审核好、放在路由器Flash里。如果是DNS牵引，需要立刻在权威DNS上把受攻击域名的A记录TTL改成60秒，并指向高防IP。注意，如果源站用了CDN，牵引时要先把CDN回源链路切断，改为直连清洗中心，否则CDN节点可能先被压垮。

第三步，清洗策略部署。流量到了清洗中心，不代表就安全了。清洗设备需要根据业务特征开启防护策略。对于SYN Flood，开启源认证和SYN Cookie；对于UDP反射放大，直接丢弃特定端口的UDP分片；对于HTTP Flood，启用JS挑战和人机验证。最关键的一步是“白名单”保护：把支付回调、API合作方、办公网出口等关键IP段提前录入清洗中心的白名单，宁可放过也不可错杀。很多事故不是攻击打死的，是清洗策略误杀正常用户导致业务中断。

第四步，持续监控与回切。牵引后，源站的压力应该立刻下降，但清洗中心的流量会飙升。这时要盯两个指标：清洗中心的丢包率和源站回注链路的延迟。如果清洗中心本身被超过最大防护量打穿，需要立刻升级到更高防护节点，也就是“云清洗”的层层递进机制。攻击停止后，不能立刻回切，因为攻击者常常在回切瞬间发起二次打击。预案规定：攻击流量低于带宽阈值的30%并持续15分钟以上，才执行回切。回切顺序是：先切DNS或BGP路由，观察5分钟无异常，再逐步放开CDN或防火墙的严格策略。

一份能用的应急预案，绝对不能只有文字描述，必须包含具体的参数表。第一，阈值定义：入口带宽利用率超过85%持续3分钟，或每秒新建连接数超过正常峰值的5倍，或单个源IP的并发连接数超过5000。第二，联系人矩阵：清洗中心供应商的7x24小时值班电话、内部网络组、安全组、业务组负责人的手机和即时通讯账号，且每季度更新一次。第三，设备信息：边界路由器的管理IP、AS号、BGP邻居IP、MD5认证密码（加密存储）、清洗中心宣告的网段。第四，切换命令：精确到复制粘贴即可执行的级别，包含检查命令和回滚命令。例如：

! 执行牵引：将192.168.1.1/32指向清洗中心下一跳10.0.0.1
ip route 192.168.1.1 255.255.255.255 10.0.0.1 tag 666
! 检查路由是否生效
show ip route 192.168.1.1
! 回滚命令：删除静态路由
no ip route 192.168.1.1 255.255.255.255 10.0.0.1

这些命令必须经过离线测试，确保在高压环境下不会因为一个拼写错误导致全网路由震荡。

单靠本地清洗设备，只能扛小流量攻击。一旦攻击流量超过本地出口带宽，本地清洗设备就成了摆设。所以现代应急预案必须设计“本地加云端”的混合牵引架构。平时流量走本地，本地清洗设备处理1Gbps以下的攻击。当本地清洗设备检测到攻击流量超过800Mbps（假设本地带宽1Gbps），自动通过API调用云端清洗服务，同时本地边界路由器开始向云端清洗中心建立GRE隧道或修改BGP宣告。这个切换过程对业务来说应该是无感知的，因为云端清洗中心早就和你的源站建立了BGP Peer。这里有个细节：云端清洗中心回注流量时，源站防火墙必须放行来自清洗中心IP段的GRE封装包，否则干净流量会被防火墙丢弃，造成“牵引成功但业务仍然不通”的尴尬局面。预案里必须包含防火墙策略同步的步骤。

现在大部分业务都是HTTPS加密的，流量牵引面临证书问题。如果直接把HTTPS流量牵引到清洗中心，清洗设备没有你的私钥，就无法解密流量做深度检测，只能做四层过滤，这会漏掉大量应用层攻击。解决方案有两种：一是把私钥托管到清洗中心，但这有合规风险。更推荐的做法是“SSL卸载前置”：在源站前端部署反向代理或专门的SSL卸载网关，清洗中心只做四层转发，把解密后的HTTP流量在源站内部网络传输。如果必须要在清洗中心做七层防护，那就需要在清洗中心部署你的证书，并确保清洗中心具备HSM或密钥管理能力。预案里要明确：牵引前后，SSL证书是否需要同步、私钥如何传输、传输过程是否加密。

DNS牵引看似简单，改个A记录就行，但里面坑很多。第一个坑是TTL缓存。如果原记录TTL是86400秒，攻击发生时你改了记录，全国递归DNS服务器还在用缓存里的旧IP，攻击流量会继续打向源站。所以平时就要把可能受攻击的域名TTL设为60或120秒，牺牲一点DNS查询性能换取快速切换能力。第二个坑是CNAME冲突。如果你的域名同时用了CDN和WAF，DNS记录可能是CNAME到CDN，CDN再CNAME到源站。牵引时如果直接改A记录，会导致CDN配置失效，甚至引发证书不匹配。正确做法是：在CDN控制台把回源地址直接改为清洗中心的高防IP，而不是动DNS。第三个坑是子域名遗漏。主站域名牵引了，但攻击者可能同时攻击API子域名、静态资源子域名、WebSocket子域名。预案里必须列出所有对外暴露的子域名，并确保它们都能在5分钟内完成牵引。

清洗后的干净流量如何回到源站，是牵引成败的最后一公里。最常用的方式是GRE隧道或VxLAN隧道。但单条隧道有单点风险，万一隧道对端设备故障，干净流量回不来，业务照样中断。预案必须设计隧道冗余：至少建立两条到不同清洗中心节点的GRE隧道，并运行BFD协议做快速故障检测。一旦主隧道中断，50毫秒内切换到备隧道。如果源站是多线机房，还要考虑回注流量的路径优化。比如电信的清洗节点回注流量到联通的源站，可能出现跨运营商延迟大或丢包。这时需要清洗中心具备多线回注能力，或者源站提前和清洗中心拉好专线。这些物理链路的准备，是应急预案里最容易忽视但又最致命的部分。

没有经过实战检验的预案等于废纸。但DDoS演练不能只在纸面上推演，必须做“盲测”：在不通知运维团队具体时间的情况下，由安全负责人模拟一次攻击，触发告警，看团队能否在规定时间内完成牵引。盲测过程中一定会暴露问题：比如某人手机静音没接到告警、切换命令少了一个参数、清洗中心的白名单漏了关键IP。每次盲测后必须输出整改报告，更新预案版本号。建议每季度做一次全链路盲测，每月做一次路由切换的桌面推演。另外，清洗中心的供应商也可能掉链子。预案里要包含供应商的SLA条款和升级机制：如果清洗中心30分钟内无法压制攻击，必须立即切换到备用供应商，这要求源站同时和两家清洗中心保持BGP Peer连接。

当牵引流程成熟后，可以更进一步，把牵引变成一种主动防御手段。通过部署“诱饵IP”或“蜜罐网段”，在公网上故意暴露一些看似重要但实际不承载业务的IP地址。一旦这些诱饵IP收到攻击流量，立刻自动触发牵引机制，把攻击流量引向清洗中心分析，同时把真正的业务IP保护起来。这样做的好处是，攻击者还没摸到真实业务，就已经被清洗中心捕获并分析攻击特征，这些特征可以同步到边界防护设备，形成联动封禁。这种思路把应急预案从“被动挨打后转移”升级为“主动诱骗后反制”，是DDoS防御体系成熟度的标志。

DDoS流量牵引应急预案的终极目标，不是让攻击消失，而是让攻击对业务的影响趋近于零。实现这个目标，靠的不是某个单点技术，而是路由调度、清洗策略、隧道冗余、DNS优化、人员响应这五个环节的精密咬合。每一个环节都写清楚、练到位、持续迭代，才能在真正的攻击洪流面前，做到切换不慌、业务不断。