DoS 拒绝服务攻击
目标
掌握 DoS 攻击的基本原理和应用,分析一次工具发出的 UDP Flood 攻击。尝试使用 WindowsXP 编程实现 SYN Flood 攻击。
本篇文章为实验记录,仅供交流学习使用,切勿违法应用,所有文中提到的工具不提供下载。
原理
- DoS 攻击,又叫做拒绝服务攻击,是能导致合法用户不能正常访问网络服务的行为。其升级版本为 DDoS(分布式拒绝服务攻击)。DoS 攻击分为很多种,本次实验用到的是 SYN Flood。
- 正常 TCP 请求需要经过三次握手过程,请求端(A)发送包含 SYN 标识的 TCP 报文,请求与服务端建立连接→服务端(B)返回一个 SYN+ACK 报文,表示接受客户端连接请求→客户端(A)返回确认报文 ACK,双方确认连接建立。若请求端发送 SYN 包后,随即掉线,服务端会不停重试,再次尝试向 A 机发送 SYN+ACK 报文,等待一段时间后,丢弃连接,大量半开连接会消耗很多系统资源。
- SYN Flood 攻击通过虚假的数据包,造成目标保存大量半开 TCP 连接,消耗很多系统资源,正常的请求不能得到响应,造成拒绝服务攻击。
步骤和关键技术
所有实验的监测机均为运行着 win10 机器,ip 地址为 192.168.235.1,其运行着 wireshark
攻击工具进行的 UDP flood 攻击
本部分实验中,攻击机为运行 winxp 的机器,ip 地址为 192.168.235.136。 被攻击机为运行 win2000 的机器,ip 地址为 192.168.235.133。 首先确立目标,在被攻击机上运行 netstat -an
,在打开的 udp 端口列表中,选择 137 端口为目标。

在攻击机上打开 udp flooder 软件,指定 ip 和 port,发送信息随便写一些内容,长度设为 30 秒,点击 Go 开始攻击,此过程中同时开启主机的 wireshark 软件开始抓包。


速度并没有设的很快。
自己编程实现 SYN flood 攻击
本次实验中,我选择了基于 socket 的实现。编程环境为 winxp,测试环境为 win2000。攻击机为运行 win2000 的机器,ip 地址为 192.168.235.141。被攻击机为运行 win2000 的机器,ip 地址为 192.168.235.133,开启了 21 号端口(ftp 服务)。源码见附件
数据和分析
分析攻击工具进行的 UDP Flood 攻击


被攻击机把这个工具传输的数据包解析为 NBNS 协议。在攻击包中可以看到自己传输进去的信息,包的状态是被分割的且包是错误的形成的。可以看到,UDP Flood 主要是向目标机传送大量垃圾的错误协议包,从而打乱目标机的正常通信。


分析自己编程实现的 SYN Flood 攻击
在目标机上开启 FTP 服务。确认 21 号 tcp 端口开启。


在攻击机上运行攻击程序,发现目标机的 cpu 使用率飙升至满值,操作上也变得很卡。本来很顺畅的 ping 过程也受到了影响,开始存在掉包现象。关掉攻击后,系统 cpu 回复正常,网络回复正常。





观察 ftp 服务器的日志,可以看到有大量伪造 ip 源同本服务器建立了连接。

下面分析 wireshark 抓包情况,可以看到,攻击机使用假地址 10.168.150.*
向目标机发送了大量 SYN 请求,每次都使用不同的端口。[后来源码改成了 128.1.*.*
,本质不影响]




其中一个包体如截图所示,这个包体的 SYN 标志位被置为 1。说明 270 号端口欲与服务器的 21 号端口建立连接。
观察整个发包过程,发现一开始服务器还可以响应一些连接。RST 连接数目较少。后来(可能也触发了一些保护机制:发送窗口被设为 0 了),服务器开始重置连接,不停回应 RST+ACK(而不是 SYN flood 的现象 SYN+ACK)。


很不容易发回了一个 SYN+ACK 包,还被自己 RST 掉了。


SYN+ACK 包就是一个普通的三步握手中第二步的过程。
后来发现,编程时随机端口范围指定太大了,导致服务器忙于 RST 其他的端口而不发动重试。将端口范围调整至 80~90 后,出现了重试包。但这不是服务端的…… 本来就不存在的 “伪造 IP” 端自己发动了一次重试?看来应该不是端口范围的问题……


我个人也没有想到是编程源码的问题还是服务端 / 客户端防火墙设置问题……
由于这个问题没能解决,也无法复现出服务端向客户端发送 SYN+ACK 包没有得到回应后,再次发动重试,从而建立了一个 “半连接” 的现象。因此,也无从再进一步分析。
收获
了解了一些常见的拒绝服务攻击原理,使用 wireshark 分析其中的两种拒绝服务攻击,进一步理解 DoS 攻击。