DDoS防御方案分析和总结.docxVIP

PAGE PAGE 1 / 5 攻击流量到底多大 谈到 DDoS 防御，首先就是要知道到底遭受了多大的攻击。这个问题看似简单，实际上却有很多不为人知的细节在里面。 以 SYN Flood 为例，为了提高发送效率在服务端产生更多的 SYN 等待队列， 攻击程序在填充包头时，IP 首部和 TCP 首部都不填充可选的字段，因此 IP 首部长度恰好是 20 字节，TCP 首部也是 20 字节，共 40 字节。 对于以太网来说，最小的包长度数据段必须达到 46 字节，而攻击报文只有40 字节，因此，网卡在发送时，会做一些处理，在 TCP 首部的末尾，填充 6 个 0 来满足最小包的长度要求。 这个时候，整个数据包的长度为 14 字节的以太网头，20 字节的 IP 头，20 字节的 TCP 头，再加上因为最小包长度要求而填充的 6 个字节的 0，一共是 60 字节。 但这还没有结束。以太网在传输数据时，还有 CRC 检验的要求。网卡会在发送数据之前对数据包进行 CRC 检验，将 4 字节的 CRC 值附加到包头的最后面。这个时候，数据包长度已不再是 40 字节，而是变成 64 字节了，这就是常说的 SYN 小包攻击，数据包结构如下： |14 字节以太网头部|20 字节 IP 头部|20 字节 TCP|6 字节填充|4 字节检验| |目的 MAC|源 MAC|协议类型| IP 头|TCP 头|以太网填充| CRC 检验| 到 64 字节时，SYN 数据包已经填充完成，准备开始传输了。攻击数据包很小，远远不够最大传输单元（MTU）的 1500 字节，因此不会被分片。那么这些数据包就像生产流水线上的罐头一样，一个包连着一个包紧密地挤在一起传输吗？事实上不是这样的。 以太网在传输时，还有前导码（preamble）和帧间距（inter-framegap）。其中前导码占 8 字节（byte），即 64 比特位。前导码前面的 7 字节都是 1010， 1 和 0 间隔而成。但第八个字节就变成了 101011，当主机监测到连续的两个 1 时，就知道后面开始是数据了。在网络传输时，数据的结构如下： |8 字节前导码|6 字节目的 MAC 地址|6 字节源 MAC 地址|2 字节上层协议类型|20 字节 IP 头|20 字节 TCP 头|6 字节以太网填充|4 字节 CRC 检验|12 字节帧间距| 也就是说，一个本来只有 40 字节的 SYN 包，在网络上传输时占的带宽，其实是 84 字节。 有了上面的基础，现在可以开始计算攻击流量和网络设备的线速问题了。当只填充 IP 头和 TCP 头的最小 SYN 包跑在以太网络上时，100Mbit 的网络，能支持的最大 PPS（Packet PerSecond）是 100×106/(8* (64+8+12))=148809， 1000Mbit 的网络，能支持的最大 PPS 是。 SYN Flood 防御 前文描述过，SYN Flood 攻击大量消耗服务器的 CPU、内存资源，并占满SYN 等待队列。 相应的，我们修改内核参数即可有效缓解。主要参数如下： 4.tcp_syncookies = 1 4.tcp_max_syn_backlog = 8192 4.tcp_synack_retries = 2 分别为启用 SYN Cookie、设置 SYN 最大队列长度以及设置 SYN+ACK 最大重试次数。 SYN Cookie 的作用是缓解服务器资源压力。启用之前，服务器在接到SYN 数据包后，立即分配存储空间，并随机化一个数字作为 SYN 号发送 SYN+ACK 数据包。然后保存连接的状态信息等待客户端确认。启用 SYN Cookie 之后，服务器不再分配存储空间，而且通过基于时间种子的随机数算法设置一个SYN 号， 替代完全随机的 SYN 号。发送完 SYN+ACK 确认报文之后，清空资源不保存任何状态信息。直到服务器接到客户端的最终 ACK 包，通过 Cookie 检验算法鉴定是否与发出去的 SYN+ACK 报文序列号匹配，匹配则通过完成握手，失败则丢弃。 当然，前文的高级攻击中有 SYN 混合 ACK 的攻击方法，则是对此种防御方法的反击，其中优劣由双方的硬件配置决定 4.tcp_synack_retries 是降低服务器 SYN+ACK 报文重试次数，尽快释放等待资源。这三种措施与攻击的三种危害一一对应，完完全全地对症下药。但这些措施也是双刃剑，可能消耗服务器更多的内存资源，甚至影响正常用户建立TCP 连接，需要评估服务器硬件资源和攻击大小谨慎设置。 除了定制 TCP/IP 协议栈之外，还有一种常见做法是 TCP 首包丢弃方案，利用 TCP 协议的重传机制识别正常用户和攻击报文。当防御设备接到一个 IP 地