DDOS渗透与攻防(二)之SYN-Flood攻击

系列文章

DDOS渗透与攻防(一)之拒绝服务攻击概念介绍

SYN-Flood攻击

1.SYN-Flood拒绝服务攻击

(1).攻击协议原理介绍说明_Syn-Flood

SYN Flood (SYN洪水) 是种典型的DoS (Denial of Service，拒绝服务) 攻击。效果就是服务器TCP连接资源耗尽，停止响应正常的TCP连接请求。

说到原理，还得从TCP如何建立连接(Connection)讲起。通信的双方最少得经过3次成功的信息交换才能进入连接全开状态(Full-Open)，行话叫建立TCP连接的3次握手(TCP three-way handshake)。

假设连接发起方是A，连接接受方是B，即B在某个端口（Port）上监听A发出的连接请求。如下图所示，左边是A，右边是B。

A首先发送SYN（Synchronization）消息给B，要求B做好接收数据的准备；B收到后反馈SYN-ACK（Synchronization-Acknowledgement） 消息给A。

这个消息的目的有两个：
(1) 向A确认已做好接收数据的准备
(2) 同时要求A也做好接收数据的准备

此时B已向A确认好接收状态，并等待A的确认，连接处于半开状态（Half-Open），顾名思义只开了一半；A收到后再次发送ACK(Acknowledgement)消息给B，向B确认也做好了接收数据的准备，至此三次握手完成，“连接”就建立了，实际上只是双方都按对方的要求进入了可以接收消息的状态。以上彼此要求对方确认的“状态”主要是双方将要使用的消息序号(SequenceNum)，TCP为保证消息按发送顺序抵达接收方的上层应用，需要用消息序号来标记消息的发送先后顺序的。

TCP是“双工”(Duplex)连接，同时支持双向通信，也就是双方同时可向对方发送消息，其中SYN和SYN-ACK消息开启了A→B的单向通信通道（B获知了A的消息序号）；SYN-ACK和ACK消息开启了B→A单向通信通道（A获知了B的消息序号）。

以上讨论的是在双方诚实可信，网络正常的理想状况下建立连接。但实际情况是，网络可能不稳定会丢包，使握手消息不能抵达对方，也可能是对方故意不按规矩来，故意延迟或不发送握手确认消息。假设B通过某TCP端口提供服务，B在收到A的SYN消息时，积极的反馈了SYN-ACK消息，使连接进入半开状态，因为B不确定自己发给A的SYN-ACK消息或A反馈的ACK消息是否会丢在半路，所以会给每个待完成的半开连接都设一个Timer，如果超过时间还没有收到A的ACK消息，则重新发送一次SYN-ACK消息给A，直到重试超过一定次数时才会放弃。

做好人是要付出代价的，B为帮助A能顺利连接，需要分配内核资源维护半开连接，那么当B面临海量的大忽悠A时，如上图所示，SYN Flood攻击就形成了。攻击方A可以控制肉鸡向B发送大量SYN消息但不响应ACK消息，或者干脆伪造SYN消息中的Source IP，使B反馈的SYN-ACK消息石沉大海，导致B被大量注定不能完成的半开连接占据，直到资源耗尽，停止响应正常的连接请求。

(2).利用脚本实现syn_flood攻击：

攻击脚本：syn_flood.py
环境准备：

# 安装Scapy到Debian, Ubuntu或Linux Mint 或kaliapt-getinstall python3-scapy
# 安装Scapy到Fedora或CentOS/RHEL
yum install scapy
说明：在CentOS/RHEL上，你首先需要启用EPEL仓库

# 防火墙需要进行配置，阻止RST包发出
iptables -A OUTPUT -p tcp --tcp-flags RST RST -d192.168.110.14 -j DROP
#说明：发一个包释放一个连接，这种达不到攻击郊果，要构成攻击效果可以通过iptables限止发送RST包

攻击命令：

python syn-flodd.py 192.168.110.14 338920

我们使用脚本对192.168.110.14的远程连接端口发起线程为20的攻击

wireshark抓包演示：

192.168.110.14:3389端口占用情况

可以清楚的看到我们发动的syn_flood攻击