DDoS攻击--Syn_Ack/Ack_Flood等攻击防护详解(TCP)

前言

Syn_Ack/Ack_Flood攻击属于TCP攻击，在了解Syn_Ack/Ack_Flood攻击之前，可以先看看TCP攻击详解。

---

Syn_Ack Flood 攻击:

syn_ack报文出现在连接建立的第2个报文，用来确认第一次握手的syn包。

当服务器收到syn_ack报文后会在系统里查询是否属于3次握手的范畴。如果属于则回复ack，并将连接设为连接状态。若没有查到相关信息，则回复reset。（这里window协议实现与Linux有所不同，这里仅讨论Linux）。当攻击者发送大量的syn_ack进行攻击时，服务器将会为处理这些报文而消耗大量的资源。  也许你发现这里可能还有另一种潜在的危害，就是当服务器主动外联时，发送完syn,等待synack包时，收到了攻击者发送的synack报文而导致，连接建立失败。其实严格意义上说这种情况是存在的。可这种情形发送在攻击的报文五元组匹配并且seq-ack也正确匹配的情况。概率极低，忽略不计。 

---

Syn_Ack Flood 防御:

1. 如果服务器没有主动发起连接的需求，直接将所以syn_ack包丢弃即可。
2. 如果有对外连接的需求，则可利用源认证的方式防御，具体防护原理为： 向syn_ack的源IP，端口发送syn报文，能在固定时间内返回，并且序列号匹配则说明该IP，端口确实提高了服务，加入白名单。多次未防护的加入黑名单。 

---

Ack Flood 攻击:

ACK Flood攻击是在TCP连接建立之后，所有的数据传输TCP报文都是带有ACK标志位的，主机在接收到一个带有ACK标志位的数据包的时候，需要检查该数据包所表示的连接四元组是否存在，如果存在则检查该数据包所表示的状态是否合法，然后再向应用层传递该数据包。如果在检查中发现该数据包不合法，例如该数据包所指向的目的端口在本机并未开放，则主机操作系统协议栈会回应RST包告诉对方此端口不存在。

这里，服务器要做两个动作：查表、回应ACK/RST。这种攻击方式显然没有SYN Flood给服务器带来的冲击大，因此攻击者一定要用大流量ACK小包冲击才会对服务器造成影响。按照我们对TCP协议的理解，随机源IP的ACK小包应该会被Server很快丢弃，因为在服务器的TCP堆栈中没有这些ACK包的状态信息。

如果没有开放端口，服务器将直接丢弃，这将会耗费服务器的CPU资源。如果端口开放，服务器回应RST。

可以肯定的是，ACK Flood不但可以危害路由器等网络设备，而且对服务器上的应用有不小的影响。

---

Ack Flood 防御:

利用对称性判断来分析出是否有攻击存在。所谓对称型判断，就是收包异常大于发包，因为攻击者通常会采用大量ACK包，并且为了提高攻击速度，一般采用内容基本一致的小包发送，这可以作为判断是否发生ACK Flood的依据。

但是目前已知情况来看，很少有单纯使用ACK Flood攻击，都会和其他攻击方法混合使用，因此，很容易产生误判。

一些防火墙应对的方法是：建立一个hash表，用来存放TCP连接“状态”，相对于主机的TCP stack实现来说，状态检查的过程相对简化。例如，不作sequence number的检查，不作包乱序的处理，只是统计一定时间内是否有ACK包在该“连接”(即四元组)上通过，从而“大致”确定该“连接”是否是“活动的”。

---

其他 Flood 攻击与防御

主要的攻击原理都为利用大量的无效数据包，消耗服务器资源。由于攻击报文命中五元组和序列号的概率极低，所以对正常连接破坏有限（服务器资源充足的情况下）。  

针对这些类型的攻击的处理方式也正是利用上面的特点。在连接建立的时候，利用syn_reset ，syn_cookie认证，认证通过之后，为每个tcp连接建立一个会话，保存五元组和序列号信息，只有匹配的包才转发到服务器，不匹配的丢弃。 关于上述认证的详解。

---

End