Ch08 DDOS

常见的web,ssh,ftp等都是基于TCP协议。目前TCP协议占全网的流量达到80%，因此这也成为黑客主要攻击的类别。

TCP报文结构

一个TCP报头的标识（code bits）字段包含6个标志位：

SYN：标志位用来建立连接，让连接双方同步序列号。如果SYN＝1而ACK=0，则表示该数据包为连接请求，如果SYN=1而ACK=1则表示接受连接

FIN：表示发送端已经没有数据要求传输了，希望释放连接

RST：用来复位一个连接。RST标志置位的数据包称为复位包。一般情况下，如果TCP收到的一个分段明显不是属于该主机上的任何一个连接，则向远端发送一个复位包

URG：为紧急数据标志。如果它为1，表示本数据包中包含紧急数据。此时紧急数据指针有效

ACK：为确认标志位。如果为1，表示包中的确认号时有效的。否则，包中的确认号无效

PSH：如果置位，接收端应尽快把数据传送给应用层, 不必等缓冲区满再发送

TCP三次握手与四次挥手

TCP攻击可以简单的分为以下三类：

1. FLOOD类攻击，例如发送海量的syn,syn_ack,ack,fin等报文，占用服务器资源，使之无法提供服务。

2. 连接耗尽类攻击，如与被攻击方，完成三次握手后不再发送报文一直维持连接，或者立刻发送FIN或RST报文，断开连接后再次快速发起新的连接等，消耗TCP连接资源。 还有一类则比较巧妙，是在我们上述没有做分析的数据传输过程中的利用TCP本身的流控，可靠性保证等机制来达到攻击的目的。

3. 利用协议特性攻击：例如攻击这建好连接之后，基于TCP的流控特性，立马就把TCP窗口值设为0，然后断开连接，则服务器就要等待Windows开放，造成资源不可用。或者发送异常报文，可能造成被攻击目标奔溃

————————————————

原文链接：https://blog.csdn.net/qq_34777600/article/details/81945594

各类攻击类型与防御

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 防御:

如果服务器没有主动发起连接的需求，直接将所以syn_ack包丢弃即可。

如果有对外连接的需求，则可利用源认证的方式防御，具体防护原理为： 向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连接建立一个会话，保存五元组和序列号信息，只有匹配的包才转发到服务器，不匹配的丢弃。

原文链接：https://blog.csdn.net/qq_34777600/article/details/81948106

最主要的：Syn_Flood攻击原理：

攻击者首先伪造地址对服务器发起SYN请求（我可以建立连接吗？），服务器就会回应一个ACK+SYN（可以+请确认）。而真实的IP会认为，我没有发送请求，不作回应。服务器没有收到回应，会重试3-5次并且等待一个SYN Time（一般30秒-2分钟）后，丢弃这个连接。

如果攻击者大量发送这种伪造源地址的SYN请求，服务器端将会消耗非常多的资源来处理这种半连接，保存遍历会消耗非常多的CPU时间和内存，何况还要不断对这个列表中的IP进行SYN+ACK的重试。TCP是可靠协议，这时就会重传报文，默认重试次数为5次，重试的间隔时间从1s开始每次都番倍，分别为1s + 2s + 4s + 8s +16s = 31s,第5次发出后还要等32s才知道第5次也超时了，所以一共是31 + 32 = 63s。

也就是说一共假的syn报文，会占用TCP准备队列63s之久，而半连接队列默认为1024，系统默认不同，可 cat /proc/sys/net/ipv4/tcp_max_syn_backlog c查看。也就是说在没有任何防护的情况下，每秒发送200个伪造syn包，就足够撑爆半连接队列，从而使真正的连接无法建立，无法响应正常请求。 最后的结果是服务器无暇理睬正常的连接请求—拒绝服务。

**攻击细节：**为了提高发送效率在服务端产生更多的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小包攻击，数据包结构如下：

到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字节。

Syn_Flood防御

cookie源认证：

原理是syn报文首先由DDOS防护系统来响应syn_ack。带上特定的sequence number （记为cookie）。真实的客户端会返回一个ack 并且Acknowledgment number 为cookie+1。 而伪造的客户端，将不会作出响应。这样我们就可以知道那些IP对应的客户端是真实的，将真实客户端IP加入白名单。下次访问直接通过，而其他伪造的syn报文就被拦截。下面为防护示意图：

reset认证：

Reset认证利用的是TCP协议的可靠性，也是首先由DDOS防护系统来响应syn。防护设备收到syn后响应syn_ack,将Acknowledgement number (确认号)设为特定值（记为cookie）。当真实客户端收到这个报文时，发现确认号不正确，将发送reset报文，并且sequence number 为cookie + 1。 而伪造的源，将不会有任何回应。这样我们就可以将真实的客户端IP加入白名单。

TCP首包丢弃：

该算法利用了TCP/IP协议的重传特性，来自某个源IP的第一个syn包到达时被直接丢弃并记录状态(五元组)，在该源IP的第2个syn包到达时进行验证，然后放行。

当防御设备接到一个IP地址的SYN报文后:

1. 接受到syn报文 -> 简单比对该IP是否存在于白名单中: 存在则转发到后端，否则进行第2步

2. 不存在于白名单中 -> 检查是否是该IP在一定时间段内的首次SYN报文： 不是则进行第3步，是则进行第4步

3. 不是首次SYN报文 -> 检查是否重传报文： 是重传则转发并加入白名单，不是则丢弃并加入黑名单

4. 是首次SYN报文 -> 丢弃并等待一段时间以试图接受该IP的SYN重传报文，等待超时则判定为攻击报文加入黑名单。

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

清洗设备的硬件具有特殊的网络处理器芯片和特别优化的操作系统、TCP/IP协议栈，可以处理非常巨大的流量和SYN队列。

原文链接：https://blog.csdn.net/qq_34777600/article/details/81946514

Land攻击：自身和自身建立连接。