深入浅出DDoS攻击防御应对篇：DDoS防御方案.doc

深入浅出DDoS攻击防御应对篇：DDoS防御方案(1)谈到DDoS防御，首先就是要知道到底遭受了多大的攻击这个问题 看似简单，实际上却有很多不为人知的细节在里面ad m防御基础攻击流量到底多大谈到DDoS防御，首先就是要知道到底遭受了多大的攻击这个问题看似简单，实际上却有很多不为人知的细节在里面以SYNFlood为例，为了提高发送效率在服务端产生更多的 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-frame gap）其中前导码占8字节（byte ），即64比特位前导码前面的7 字节都是 10101010， 1 和 0 间隔而成但第八个字节就变成了 10101011，当主机监测到连续的两个 1 时，就知道后面开始是数据了 在网络传输时，数据的结构如下：|8字节前导码|6字节目的MAC地址|6字节源MAC地址|2字节上层协 议类型|20字节IP头|20字节TCP头|6字节以太网填充|4字节CRC 佥验 |12 字节帧间距 |也就是说，一个本来只有40字节的SYN包，在网络上传输时占的带 宽，其实是 84 字节有了上面的基础， 现在可以开始计算攻击流量和网络设备的线速问题了当只填充IP头和TCP头的最小SYN包跑在以太网络上时，100Mbit的网络，能支持的最大 PPS( Packet Per Seco nd)是 100X 106 / (8* (64+8+12)) = 148809 , 1000Mbit 的网络，能支持的最大 PPS是1488090。

SYN Flood 防御前文描述过，SYN Flood攻击大量消耗服务器的CPU内存资源，并 占满SYN等待队列相应的，我们修改内核参数即可有效缓解 主要 参数如下：net.ipv4.tcp_syncookies = 1net.ipv4.tcp_max_syn_backlog = 8192net.ipv4.tcp_synack_retries = 2分别为启用SYN Cookie、设置SYN最大队列长度以及设置SYN+ACK 最大重试次数SYN Cookie 的作用是缓解服务器资源压力启用之前，服务器在接到SYN数据包后，立即分配存储空间，并随机化一个数字作为SYN号发送SYN+AC数据包然后保存连接的状态信息等待客户端确认 启 用 SYN Cookie 之后，服务器不再分配存储空间，而且通过基于时间 种子的随机数算法设置一个SYN号，替代完全随机的SYN号发送完 SY N+AC确认报文之后，清空资源不保存任何状态信息直到服务器 接到客户端的最终ACK包，通过Cookie检验算法鉴定是否与发出去 的SYN+AC报文序列号匹配，匹配则通过完成握手，失败则丢弃当 然，前文的高级攻击中有SYN混合ACK勺攻击方法，则是对此种防御 方法的反击，其中优劣由双方的硬件配置决定tcp_max_syn_backlog 则是使用服务器的内存资源，换取更大的等待 队列长度，让攻击数据包不至于占满所有连接而导致正常用户无法完 成握手。

net.ipv4.tcp_synack_retries 是降低服务器 SYN+AC报文重试次数， 尽快释放等待资源 这三种措施与攻击的三种危害一一对 应，完完全全地对症下药但这些措施也是双刃剑，可能消耗服务器 更多的内存资源，甚至影响正常用户建立TCP连接，需要评估服务器 硬件资源和攻击大小谨慎设置除了定制TCP/IP协议栈之外，还有一种常见做法是 TCP首包丢弃方 案，利用TCP协议的重传机制识别正常用户和攻击报文 当防御设备 接到一个IP地址的SYN报文后，简单比对该IP是否存在于白名单中， 存在则转发到后端如不存在于白名单中，检查是否是该 IP 在一定 时间段内的首次SYN报文，不是则检查是否重传报文，是重传则转发 并加入白名单，不是则丢弃并加入黑名单是首次SYN报文则丢弃并 等待一段时间以试图接受该IP的SYN重传报文，等待超时则判定为 攻击报文加入黑名单首包丢弃方案对用户体验会略有影响， 因为丢弃首包重传会增大业务 的响应时间，有鉴于此发展出了一种更优的 TCPProxy 方案所有的 SYN数据报文由清洗设备接受，按照 SYN Cookie方案处理和设备 成功建立了 TCP三次握手的IP地址被判定为合法用户加入白名单， 由设备伪装真实客户端 IP 地址再与真实服务器完成三次握手，随后 转发数据。

而指定时间内没有和设备完成三次握手的 IP 地址，被判 定为恶意 IP 地址屏蔽一定时间 除了 SYNCookie 结合 TCPProxy 外， 清洗设备还具备多种畸形TCP标志位数据包探测的能力，通过对 SYN 报文返回非预期应答测试客户端反应的方式来鉴别正常访问和恶意 行为清洗设备的硬件具有特殊的网络处理器芯片和特别优化的操作系统、TCP/IP协议栈，可以处理非常巨大的流量和 SYN队列HTTP Flood 防御HTTP Flood 攻击防御主要通过缓存的方式进行，尽量由设备的缓存 直接返回结果来保护后端业务大型的互联网企业，会有庞大的 CDN 节点缓存内容当高级攻击者穿透缓存时，清洗设备会截获 HTTP请求做特殊处理 最简单的方法就是对源IP的HTTP请求频率做统计，高于一定频率的IP 地址加入黑名单这种方法过于简单，容易带来误杀，并且无法 屏蔽来自代理服务器的攻击，因此逐渐废止，取而代之的是 JavaScript 跳转人机识别方案HTTPFIood是由程序模拟HTTP青求，一般来说不会解析服务端返回 数据，更不会解析JS之类代码因此当清洗设备截获到HTTP青求时, 返回一段特殊 JavaScript 代码，正常用户的浏览器会处理并正常跳 转不影响使用，而攻击程序会攻击到空处。

DNS FIood 防御DNS攻击防御也有类似HTTP的防御手段，第一方案是缓存其次是 重发，可以是直接丢弃DNS报文导致UDP层面的请求重发，可以是返 回特殊响应强制要求客户端使用 TCP协议重发DNS查询请求特殊的，对于授权域DNS的保护，设备会在业务正常时期提取收到的 DNS域名列表和ISP DNS IP列表备用，在攻击时，非此列表的请求 一律丢弃，大幅降低性能压力对于域名， 实行同样的域名白名单机 制，非白名单中的域名解析请求，做丢弃处理慢速连接攻击防御SIowIoris 攻击防御比较简单，主要方案有两个第一个是统计每个TCP连接的时长并计算单位时间内通过的报文数 量即可做精确识别一个TCP连接中，HTTP报文太少和报文太多都是不正常的，过少可能是慢速连接攻击，过多可能是使用 HTTP 1.1协议进行的HTTPFIood攻击，在一个TCP连接中发送多个HTTP请求第二个是限制HTTP头部传输的最大许可时间超过指定时间 HTTPHeader 还没有传输完成，直接判定源 IP 地址为慢速连接攻击，中断 连接并加入黑名单企业级防御互联网企业防御DDoS攻击，主要使用上文的基础防御手段，重点在 于监控、组织以及流程。

监控需要具备多层监控、纵深防御的概念，从骨干网络、 IDC 入口网络的BPS PPS协议分布，负载均衡层的 VIP新建连接数、并发连 接数、BPS PPS到主机层的CPU犬态、TCP新建连接数状态、TCP并 发连接数状态， 到业务层的业务处理量、 业务连通性等多个点部署监 控系统即使一个监控点失效， 其他监控点也能够及时给出报警信息 多个点信息结合，准确判断被攻击目标和攻击手法一旦发现异常， 立即启动在虚拟防御组织中的应急流程， 防御组织需 要囊括到足够全面的人员， 至少包含监控部门、 运维部门、网络部门、 安全部门、 客服部门、 业务部门等，所有人员都需要 2-3 个备份流 程启动后，除了人工处理，还应该包含一定的自动处理、 半自动处理 能力例如自动化的攻击分析，确定攻击类型，自动化、 半自动化的 防御策略， 在安全人员到位之前， 最先发现攻击的部门可以做一些缓 解措施除了 DDoS到来之时的流程等工作之外，更多的工作是在攻击到来之 前主要包含CDN节点部署、DNSS置、流程演习等对于企业来说， 具备多个CDN节点是DDoS防御容量的关键指标当一个机房承担不 住海量数据时，可以通过DNS轮询的方式，把流量引导到多个分布节 点，使用防御设备分头处理。

因此 DNS勺TTL值需要设置得足够小， 能够快速切换，每个CDN节点的各种VIP设置也需要准备充分在虚拟化时代， 各种用户的不同业务共处在相同的物理机平台， 遭受 DDoS攻击的可能性越来越高，而且一个用户被攻击可能牵扯到大量 的其他用户，危害被显著放大，因此防御显得尤为重要 阿里云的虚 拟化业务，平均每天遭受约 20起DDoS攻击，最大流量达到接近 20Gbit/s ，所有这些攻击都在 15 分钟内自动处理完成，让客户远离 DDoS的威胁，专心发展业务总地来说，对DDoS防御，主要的工作是幕后积累台上十分钟，台 下十年功，没有充分的资源准备，没有足够的应急演练， 没有丰富的 处理经验，DDoS攻击将是所有人的噩梦。