DDOS渗透与攻防(二)之SYN-Flood攻击
系列文章
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 或kali
apt-get install python3-scapy
# 安装Scapy到Fedora或CentOS/RHEL
yum install scapy
说明:在CentOS/RHEL上,你首先需要启用EPEL仓库
# 防火墙需要进行配置,阻止RST包发出
iptables -A OUTPUT -p tcp --tcp-flags RST RST -d 192.168.110.14 -j DROP
#说明:发一个包释放一个连接,这种达不到攻击郊果,要构成攻击效果可以通过iptables限止发送RST包
攻击命令:
python syn-flodd.py 192.168.110.14 3389 20
我们使用脚本对192.168.110.14的远程连接端口发起线程为20的攻击
wireshark抓包演示:
192.168.110.14:3389端口占用情况
可以清楚的看到我们发动的syn_flood攻击