分布式拒绝服务（DDoS）攻击从未停止进化，而SYN Flood与UDP Flood依然是攻击者最钟爱的武器。这两种攻击手法成熟、工具泛滥，即使中等规模的僵尸网络也能轻易压垮一台无保护的服务器。许多运维团队在遭受攻击后才匆忙寻找清洗方案，结果往往因为架构缺陷导致业务中断时间远超预期。本文不讨论空洞的理论，而是直接聚焦于这两种攻击的防御本质与可落地的清洗方法。
攻击原理：为什么SYN Flood和UDP Flood难以抵御
要设计有效的清洗方案，必须理解攻击者如何绕过常规防护。两种攻击都利用了协议设计的弱点，但攻击路径截然不同。
SYN Flood攻击机制
TCP连接通过三次握手建立：客户端发送SYN → 服务器回复SYN-ACK → 客户端回复ACK完成握手。SYN Flood攻击中的客户端只发送大量SYN包，但不回应后续的SYN-ACK。服务器每收到一个SYN，就会在内存中分配一个半连接队列（backlog queue）并等待ACK超时。当半连接队列被填满，正常用户的连接请求将被丢弃。
关键点是：攻击者可以伪造源IP地址，使得服务器向不存在的IP发送SYN-ACK，这些响应永远石沉大海。默认的SYN超时通常为30秒到2分钟，一台普通服务器每秒处理数千个伪造SYN即可耗尽连接表。更糟糕的是，现代攻击工具还能发送随机源端口、不同TCP选项的SYN包，增加识别难度。
UDP Flood攻击机制
UDP是面向无连接的协议，服务器收到UDP包后需要处理数据并根据目的端口分发。如果目的端口未开放，很多系统会回复ICMP端口不可达消息。UDP Flood攻击就是利用这个特性：攻击者发送大量包含随机端口的高速率UDP包，消耗服务器的带宽、CPU以及网络设备的转发能力。即使你关闭了ICMP回复，服务器网卡仍需将数据包从DMA缓冲区搬运到内核协议栈进行解析，这本身就会消耗CPU中断资源。
部分UDP Flood会针对特定服务（如NTP、DNS反射放大），但更基础的暴力UDP Flood只需大流量即可堵塞链路。在DDoS防护领域，UDP Flood的清洗难点在于如何区分正常UDP流量（如DNS请求、游戏数据包）与攻击流量。
传统防护的局限：为什么防火墙和ACL常失效
早期思路是在边界防火墙上设置SYN速率限制或直接丢弃UDP包。这种做法在低速率攻击时尚可，但面对真实分布式攻击存在几个致命问题：
- 单点瓶颈：防火墙的并发连接处理能力有限，攻击流量超过其性能后会直接崩溃，导致正常流量也全部中断。
- 状态表膨胀：SYN Flood会耗尽防火墙的状态表，使其无法记录合法连接。
- 无法区分伪造IP：源IP地址可以随意伪造，基于IP的白名单或黑名单基本无效。
- UDP全丢弃代价太高：直接丢弃所有UDP流量意味着自断许多业务（如DNS、游戏、实时音视频）。
因此，现代清洗方案必须从以下三个层面重新设计：协议栈加固、流量识别分流、网络容量稀释。
清洗方案的核心技术
SYN Cookie与反向代理
SYN Cookie是操作系统内核层面的经典防御。核心思想：服务器收到SYN包时不立即分配内存资源，而是根据源IP、端口、时间戳等参数计算一个加密的Cookie并放入SYN-ACK包的序列号字段中。只有当客户端回复ACK并携带正确的Cookie时，服务器才建立连接对象。这样攻击者的伪造SYN不会占用任何连接表项。
然而SYN Cookie并非万能：它会增加CPU计算开销（尤其在Cookie验证阶段），且无法抵御应用层攻击。更关键的是，很多云服务器默认开启了SYN Cookie，但仍然被SYN Flood打垮，原因往往是攻击流量已经超过了服务器网卡的收包能力（PPS上限）。此时需要引入反向代理：在业务服务器前面部署一组专门的代理节点，代理节点使用特制的TCP栈（如通过DPDK旁路内核协议栈），能够以极高的PPS处理SYN包并验证Cookie，只将合法的TCP连接转发给后端。例如，Nginx的SYN Cookie模块可配合LVS的SYN代理功能实现第一层清洗。
流量指纹识别与行为限速
对于UDP Flood，纯协议层加固效果有限，必须借助流量特征分析。清洗设备（或云清洗中心的边缘路由器）会采集以下维度的数据：
- 源IP行为：同一源IP每秒发送的UDP包数量、包大小分布、目的端口分布。
- 会话关联：特定UDP流是否有对应的应用层回包（如DNS查询与响应应成对出现）。
- 包一致性：攻击流量常使用固定的载荷填充（如全0、全1或固定字符串）。
基于这些特征，设备可以动态生成限速规则：例如对某一源IP的UDP流进行限速，或对特定目的端口的UDP包采用挑战应答机制（发送验证数据包，只有正确响应的客户端才被视为合法）。需要注意的是，行为限速必须设置合理的阈值和回退机制，避免误杀正常用户。
全球任播清洗网络
当攻击流量超过单机柜或单数据中心的带宽上限（比如达到100Gbps以上），就必须借助分布式清洗网络。最成熟的做法是任播（Anycast）技术：将清洗中心的IP地址通过BGP同时广播至全球多个节点。当攻击发生时，流量通过路由协议自动分散到最近的清洗节点，每个节点只处理一部分攻击流量，同时进行本地清洗，再将干净流量通过隧道或直接路由回源到业务服务器。
任播的关键好处：天然抵御大流量攻击，攻击者无法针对单一IP打垮所有节点。但任播要求业务IP本身也能通过任播宣告，或者使用DNS重定向。常见的Cloudflare、Akamai等CDN厂商的DDoS防护底层就是基于任播 + 动态路由引流。
实施步骤与最佳实践
事前防御配置
在攻击发生前，应该完成以下操作：
- 操作系统加固：调整sysctl参数，开启SYN Cookie、缩短SYN超时时间（如tcp_synack_retries设为1）、增大半连接队列（tcp_max_syn_backlog）。
- 网络架构分层：在源站前部署反向代理或云清洗中心。建议使用至少两层：第一层为CDN/接入层，第二层为四层负载均衡。
- 容量规划与冗余：与ISP签署端口限速协议，确保上游在攻击时可快速将流量引入清洗池。预留备用带宽。
- 监控告警：配置基于PPS、BPS和新建连接数的阈值告警，使用NetFlow/sFlow实时捕获流量突增。
事中响应流程
攻击发生时，不要慌乱。按以下顺序操作：
- 确认攻击类型：通过抓包工具（tcpdump）或云监控确认是SYN Flood还是UDP Flood。查看SYN包是否全部来自伪造IP，UDP包是否大量发往随机端口。
- 触发清洗入口：如果是自建清洗设备，手工将流量引流至清洗集群。如果是云清洗服务，立即联系运营商开启黑洞牵引或DDoS高防模式。
- 动态调参：攻击过程中，根据误杀情况调整SYN Cookie的阈值、UDP限速的比率。对于关键业务端口（如53、443），可以暂时放行而只限制非业务端口。
- 保留攻击样本：将抓包数据保存，用于事后分析攻击源和攻击手法。
事后复盘与优化
攻击结束后，需要评估防护效果：
- 分析误杀率：查看正常用户的失败请求日志，确认是否有合法流量被拦截。调整指纹识别的参数。
- 检查性能瓶颈：清洗设备在攻击期间的CPU、内存、带宽峰值是多少？是否需要扩容？
- 更新规则库：将本次攻击的特征加入自定义规则，以便下次自动识别类似变种。
- 优化通知流程：如果攻击从发现到响应耗时过长，考虑引入自动化触发脚本（如通过API自动切换至高防模式）。
结语
SYN Flood和UDP Flood虽然历史悠久，但只要理解其底层机制并部署分层防御体系，完全可以将业务中断风险降到最低。核心原则是：不要依赖单一设备或单一策略，而是组合协议层加固、流量行为分析和分布式清洗网络。每个季度进行一次压力测试，模拟上述两种攻击场景，确保你的清洗链路在真正面临威胁时能够顺畅跑通。
延伸阅读