DDoS防护方案

转自：http://netsecurity.51cto.com/art/201211/368930.htm

深刻浅出DDoS攻击防护应对篇：DDoS防护方案

谈到DDoS防护，首先就是要知道到底遭受了多大的攻击。这个问题看似简单，实际上却有不少鲜为人知的细节在里面。

防护基础

攻击流量到底多大

谈到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-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 Second）是100×106 / (8 * (64+8+12)) = 148809，1000Mbit的网络，能支持的最大PPS是1488090。

SYN Flood防护

前文描述过，SYN Flood攻击大量消耗服务器的CPU、内存资源，并占满SYN等待队列。相应的，咱们修改内核参数便可有效缓解。主要参数以下：

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_max_syn_backlog = 8192

net.ipv4.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的攻击方法，则是对此种防护方法的反击，其中优劣由双方的硬件配置决定

tcp_max_syn_backlog则是使用服务器的内存资源，换取更大的等待队列长度，让攻击数据包不至于占满全部链接而致使正经常使用户没法完成握手。net.ipv4.tcp_synack_retries是下降服务器SYN+ACK报文重试次数，尽快释放等待资源。这三种措施与攻击的三种危害一一对应，完彻底全地对症下药。但这些措施也是双刃剑，可能消耗服务器更多的内存资源，甚至影响正经常使用户创建TCP链接，须要评估服务器硬件资源和攻击大小谨慎设置。

除了定制TCP/IP协议栈以外，还有一种常见作法是TCP首包丢弃方案，利用TCP协议的重传机制识别正经常使用户和攻击报文。当防护设备接到一个IP地址的SYN报文后，简单比对该IP是否存在于白名单中，存在则转发到后端。如不存在于白名单中，检查是不是该IP在必定时间段内的首次SYN报文，不是则检查是否重传报文，是重传则转发并加入白名单，不是则丢弃并加入黑名单。是首次SYN报文则丢弃并等待一段时间以试图接受该IP的SYN重传报文，等待超时则断定为攻击报文加入黑名单。

首包丢弃方案对用户体验会略有影响，由于丢弃首包重传会增大业务的响应时间，有鉴于此发展出了一种更优的TCP Proxy方案。全部的SYN数据报文由清洗设备接受，按照SYN Cookie方案处理。和设备成功创建了TCP三次握手的IP地址被断定为合法用户加入白名单，由设备假装真实客户端IP地址再与真实服务器完成三次握手，随后转发数据。而指定时间内没有和设备完成三次握手的IP地址，被断定为恶意IP地址屏蔽必定时间。除了SYN Cookie结合TCP Proxy外，清洗设备还具有多种畸形TCP标志位数据包探测的能力，经过对SYN报文返回非预期应答测试客户端反应的方式来鉴别正常访问和恶意行为。

清洗设备的硬件具备特殊的网络处理器芯片和特别优化的操做系统、TCP/IP协议栈，能够处理很是巨大的流量和SYN队列。

HTTP Flood防护

HTTP Flood攻击防护主要经过缓存的方式进行，尽可能由设备的缓存直接返回结果来保护后端业务。大型的互联网企业，会有庞大的CDN节点缓存内容。

当高级攻击者穿透缓存时，清洗设备会截获HTTP请求作特殊处理。最简单的方法就是对源IP的HTTP请求频率作统计，高于必定频率的IP地址加入黑名单。这种方法过于简单，容易带来误杀，而且没法屏蔽来自代理服务器的攻击，所以逐渐废止，取而代之的是JavaScript跳转人机识别方案。

HTTP Flood是由程序模拟HTTP请求，通常来讲不会解析服务端返回数据，更不会解析JS之类代码。所以当清洗设备截获到HTTP请求时，返回一段特殊JavaScript代码，正经常使用户的浏览器会处理并正常跳转不影响使用，而攻击程序会攻击到空处。

DNS Flood防护

DNS攻击防护也有相似HTTP的防护手段，第一方案是缓存。其次是重发，能够是直接丢弃DNS报文致使UDP层面的请求重发，能够是返回特殊响应强制要求客户端使用TCP协议重发DNS查询请求。

特殊的，对于受权域DNS的保护，设备会在业务正常时期提取收到的DNS域名列表和ISP DNS IP列表备用，在攻击时，非此列表的请求一概丢弃，大幅下降性能压力。对于域名，实行一样的域名白名单机制，非白名单中的域名解析请求，作丢弃处理。

慢速链接攻击防护

Slowloris攻击防护比较简单，主要方案有两个。

第一个是统计每一个TCP链接的时长并计算单位时间内经过的报文数量便可作精确识别。一个TCP链接中，HTTP报文太少和报文太多都是不正常的，过少多是慢速链接攻击，过多多是使用HTTP 1.1协议进行的HTTP Flood攻击，在一个TCP链接中发送多个HTTP请求。

第二个是限制HTTP头部传输的最大许可时间。超过指定时间HTTP Header尚未传输完成，直接断定源IP地址为慢速链接攻击，中断链接并加入黑名单。

企业级防护

互联网企业防护DDoS攻击，主要使用上文的基础防护手段，重点在于监控、组织以及流程。

监控须要具有多层监控、纵深防护的概念，从骨干网络、IDC入口网络的BPS、PPS、协议分布，负载均衡层的VIP新建链接数、并发链接数、BPS、PPS到主机层的CPU状态、TCP新建链接数状态、TCP并发链接数状态，到业务层的业务处理量、业务连通性等多个点部署监控系统。即便一个监控点失效，其余监控点也可以及时给出报警信息。多个点信息结合，准确判断被攻击目标和攻击手法。

一旦发现异常，当即启动在虚拟防护组织中的应急流程，防护组织须要囊括到足够全面的人员，至少包含监控部门、运维部门、网络部门、安所有门、客服部门、业务部门等，全部人员都须要2-3个备份。流程启动后，除了人工处理，还应该包含必定的自动处理、半自动处理能力。例如自动化的攻击分析，肯定攻击类型，自动化、半自动化的防护策略，在安全人员到位以前，最早发现攻击的部门能够作一些缓解措施。

除了DDoS到来之时的流程等工做以外，更多的工做是在攻击到来以前。主要包含CDN节点部署、DNS设置、流程演习等。对于企业来讲，具有多个CDN节点是DDoS防护容量的关键指标。当一个机房承担不住海量数据时，能够经过DNS轮询的方式，把流量引导到多个分布节点，使用防护设备分头处理。所以DNS的TTL值须要设置得足够小，可以快速切换，每一个CDN节点的各类VIP设置也须要准备充分。

在虚拟化时代，各类用户的不一样业务共处在相同的物理机平台，遭受DDoS攻击的可能性愈来愈高，并且一个用户被攻击可能牵扯到大量的其余用户，危害被显著放大，所以防护显得尤其重要。阿里云的虚拟化业务，平均天天遭受约20起DDoS攻击，最大流量达到接近20Gbit/s，全部这些攻击都在15分钟内自动处理完成，让客户远离DDoS的威胁，专心发展业务。

总地来讲，对DDoS防护，主要的工做是幕后积累。台上十分钟，台下十年功，没有充分的资源准备，没有足够的应急演练，没有丰富的处理经验，DDoS攻击将是全部人的噩梦。