20253909 2024-2025-2 《网络攻防实践》实践4报告
20253909 2025-2026-2 《网络攻防实践》第4次作业
本文记录了网络攻防课程第四次作业的完整实现过程，涵盖 ARP 缓存欺骗攻击、ICMP 重定向攻击、SYN Flood 攻击、TCP RST 攻击以及 TCP 会话劫持攻击五项实验。每项实验均从攻击原理出发，结合实际操作步骤与抓包验证，并对攻击危害与防御手段进行了系统梳理。
目录
一、实验内容
本次实验围绕 TCP/IP 协议栈重点协议的攻击技术展开，在课程提供的蜜网靶场环境中，以 Kali Linux（192.168.200.3）作为攻击机，依次完成以下五项攻击实验。实验环境的网络拓扑如下：
| 主机角色 | 主机名 | IP 地址 | MAC 地址 | 操作系统 |
|---|---|---|---|---|
| 攻击机 | Kali Linux | 192.168.200.3 | 00:0c:29:83:85:26 | Kali Linux Rolling |
| 受害机 | SEEDUbuntu9 | 192.168.200.5 | 00:0c:29:17:a4:60 | Ubuntu 9.04 |
| 靶机 | Metasploitable_ubuntu | 192.168.200.130 | 00:0c:29:0a:21:ca | Ubuntu 8.04 |
| 网关 | VMware 虚拟网关 | 192.168.200.1 | 00:50:56:fe:52:aa | — |
| 蜜网网关 | Honeywall | 192.168.200.8 | — | — |
任务一：ARP 缓存欺骗攻击——利用 ARP 协议无认证机制的先天缺陷，向目标主机持续发送伪造的 ARP 响应报文，篡改受害机二层转发路径，实现中间人（MITM）攻击。
任务二：ICMP 重定向攻击——通过伪造来自网关的 ICMP Type 5（Redirect）报文，诱使目标主机更新路由缓存，将特定目的地的流量改道至攻击机，实现网络层的流量劫持。
任务三：SYN Flood 攻击——通过向目标服务端口持续发送大量伪造源 IP 的 TCP SYN 报文，耗尽服务器的半连接队列（backlog）资源，使合法用户的连接请求无法被处理，实现拒绝服务（DoS）效果。
任务四：TCP RST 攻击——通过监听获取目标 TCP 会话的序列号信息，构造并注入携带正确序列号的伪造 RST 报文，强制重置受害机与服务端之间的合法连接。
任务五：TCP 会话劫持攻击——综合运用 ARP 毒化与协议嗅探技术，利用 Ettercap 将攻击机置于中间人位置，实时截获 Telnet 明文会话中的登录凭据与完整交互内容；并进一步使用 shijack 工具实施主动数据注入，完整还原主动型会话劫持的攻击效果。
二、实验过程
第一部分：ARP 缓存欺骗攻击
攻击原理
ARP（Address Resolution Protocol，地址解析协议）是工作在数据链路层的协议，负责将网络层的 IP 地址解析为链路层的 MAC 地址。其工作流程如下：当主机 A 需要与主机 B 通信时，若 A 的 ARP 缓存中没有 B 的 MAC 地址，A 会在局域网内广播一个 ARP Request（"谁是 IP X.X.X.X，告诉我你的 MAC"）；持有该 IP 的主机 B 单播回复一个 ARP Reply（"我是 IP X.X.X.X，我的 MAC 是 XX:XX:XX:XX:XX:XX"）；A 收到 Reply 后将 IP→MAC 的映射写入本地 ARP 缓存供后续复用。
ARP 协议的设计存在两个关键的安全缺陷：其一，ARP 协议是无状态的——主机在收到 ARP Reply 时，不会验证自己是否曾经发送过对应的 ARP Request，即便是毫无缘由收到的"主动" ARP Reply，也会无条件更新本地缓存；其二，ARP 协议无认证机制——报文中没有任何字段能够证明发送方的真实身份，任何人都可以伪造任意 IP 对应的 MAC 地址并广播出去。
攻击者正是利用这两个缺陷实施 ARP 缓存欺骗（ARP Cache Poisoning）：持续向受害机发送伪造的 ARP Reply，声称网关的 MAC 地址是攻击机自身的 MAC。受害机收到后无条件更新缓存，此后发往网关的所有流量都会被错误地转发至攻击机，攻击机由此实现中间人（Man-in-the-Middle, MITM）位置，可对流量进行窃听、篡改或转发，如下图所示：
正常情况：受害机 → 网关 → 互联网
攻击后： 受害机 → 攻击机（中间人）→ 网关 → 互联网
↑
攻击机可在此处窃听/篡改流量
本实验使用 arpspoof 工具（dsniff 套件的一部分）实施攻击，该工具通过持续发包维持 ARP 缓存的中毒状态，因为 ARP 缓存条目存在老化时间（一般为几分钟），需要定期刷入才能保持攻击效果。
实验操作
步骤 1：确认各主机网络配置
在攻击机 Kali Linux 和受害机 SEEDUbuntu9 上分别执行 ifconfig，确认 IP 地址与网络接口配置符合实验预期。
Kali Linux 攻击机 ifconfig：
图1：Kali Linux 攻击机 eth0 接口 IP 地址 192.168.200.3，子网掩码 255.255.255.128，MAC 地址 00:0c:29:83:85:26
SEEDUbuntu9 受害机 ifconfig：
图2：SEEDUbuntu9 受害机 eth6 接口 IP 地址 192.168.200.5，子网掩码 255.255.255.128，MAC 地址 00:0c:29:17:a4:60
步骤 2：记录受害机初始 ARP 缓存状态
在 SEEDUbuntu9 向靶机 192.168.200.130 发起 ping 后，执行 arp -a 查看当前 ARP 缓存，记录网关对应的真实 MAC 地址作为攻击前的基准数据：
图3：SEEDUbuntu9 ping 192.168.200.130
图4：SEEDUbuntu9 ping 192.168.200.130 全部收包，零丢包；arp -a 显示网关 192.168.200.1 对应真实 MAC 00:50:56:fe:52:aa，这是攻击前的正常状态
步骤 3：执行 arpspoof 发起 ARP 欺骗
在 Kali Linux 攻击机上切换至 root 权限，执行 arpspoof 持续向受害机发送伪造 ARP 响应：
arpspoof -i eth0 -t 192.168.200.5 192.168.200.1
图5：攻击机以 root 权限执行 arpspoof，持续向受害机 192.168.200.5 发送伪造 ARP reply，声称 192.168.200.1 is-at 00:0c:29:83:85:26
| 参数 | 值 | 含义 |
|---|---|---|
-i |
eth0 | 指定发包网卡 |
-t |
192.168.200.5 | 攻击目标（受害机 IP） |
| 最后参数 | 192.168.200.1 | 被冒充的主机（网关 IP） |
步骤 4：验证受害机 ARP 缓存已被篡改
arpspoof 持续运行期间，在受害机上再次执行 arp -a 进行对比验证：
图6：受害机再次执行 arp -a，网关 192.168.200.8 对应 MAC 已替换为攻击机 MAC 00:0c:29:83:85:26，ARP 欺骗成功
| IP 地址 | 攻击前 MAC | 攻击后 MAC | 变化说明 |
|---|---|---|---|
| 192.168.200.1（网关） | 00:50:56:fe:52:aa | 00:0c:29:83:85:26 | ✅ 已篡改为攻击机 MAC |
| 192.168.200.8 | — | 00:0c:29:83:85:26 | 新增，指向攻击机 |
| 192.168.200.120 | — | 00:50:56:e8:c9:9d | 新增条目 |
步骤 5：清空缓存验证攻击持续性
在受害机上执行 arp -d * 手动清空全部 ARP 缓存，再次执行 arp -a 查看恢复情况，验证攻击的持续效果：
图7：执行 arp -d * 清空缓存后，arp -a 显示 192.168.200.1 立刻再次被映射为攻击机 MAC 00:0c:29:83:85:26，说明 arpspoof 的持续发包使攻击效果无法被简单清除
步骤 6：Wireshark 抓包验证伪造 ARP 报文
在 Kali Linux 攻击机上打开 Wireshark，选择 eth0 接口以混杂模式开始捕获，在显示过滤器中输入 arp 进行过滤：
图8：Wireshark 主界面选择 eth0 接口（可见实时流量波形），准备开始捕获
图9：在Wireshark中选择"捕获"，选择"选项"，eth0 地址 192.168.200.3，链路层 Ethernet，混杂模式已启用
图10：Wireshark 捕获选项，eth0 地址 192.168.200.3，链路层 Ethernet，混杂模式已启用
图11：Wireshark 过滤 arp 后的抓包结果，VMware_83:85:26（攻击机）以约 1s 间隔持续向 VMware_17:a4:60（受害机）单播发送伪造 ARP reply "192.168.200.1 is-at 00:0c:29:83:85:26"；帧详情中源 MAC 为全零（00:00:00:00:00:00），确认报文为伪造
攻击危害与防御
危害分析：
ARP 缓存欺骗攻击的危害远不止于"断网"，其真正的威胁在于它可以作为多种更高级攻击的基础手段：
① 流量窃听：攻击机处于中间人位置后，可以完整地监听受害机与网关之间的所有通信内容。对于使用明文协议（HTTP、FTP、Telnet、POP3 等）的应用，用户名、密码、浏览内容等敏感信息将全部暴露。
② 内容篡改：攻击者不仅可以被动窃听，还可以主动修改转发的数据内容，例如在 HTTP 响应中注入恶意脚本，或替换软件下载链接，实现中间人篡改攻击（MITM Injection）。
③ 会话劫持跳板：ARP 欺骗是本次实验第五部分 TCP 会话劫持的前置步骤，是 Ettercap 等工具实施综合攻击的必要基础。
④ 拒绝服务：若攻击者不开启 IP 转发（ip_forward），受害机发往网关的所有流量到达攻击机后直接被丢弃，造成受害机无法访问网络，实现拒绝服务效果。
防御措施：
| 防御手段 | 实施层面 | 说明 |
|---|---|---|
| 动态 ARP 检测（DAI） | 交换机二层 | 交换机维护 IP-MAC 绑定表，对不匹配的 ARP 报文直接丢弃，是最有效的防御手段 |
| IP Source Guard | 交换机二层 | 结合 DHCP Snooping 绑定端口、MAC、IP、VLAN，防止 IP/MAC 伪造 |
| 静态 ARP 绑定 | 主机配置 | 对网关等关键设备手动绑定静态 ARP 条目，使其不会被动态更新覆盖 |
| ARP 检测工具 | 主机软件 | 使用 arpwatch、XArp 等工具监控局域网内的 ARP 变化，发现异常及时告警 |
| VLAN 隔离 | 网络架构 | 通过 VLAN 将不同信任级别的主机隔离，限制 ARP 广播域，减小攻击面 |
| 使用加密协议 | 应用层 | 即便 ARP 被欺骗，HTTPS、SSH、TLS 等加密协议仍能保证数据的机密性和完整性 |
第一部分小结
| 实验步骤 | 操作 | 结果 |
|---|---|---|
| 初始状态确认 | 受害机 arp -a | 网关 MAC 为真实值 00:50:56:fe:52:aa |
| 发起攻击 | arpspoof -i eth0 -t 192.168.200.5 192.168.200.1 | 持续发送伪造 ARP reply |
| 效果验证 | 受害机 arp -a | 网关 MAC 已替换为攻击机 MAC 00:0c:29:83:85:26 |
| 持续性验证 | 受害机 arp -d * 后再查 | 缓存立即再次被污染 |
| 流量验证 | Wireshark 过滤 arp | 捕获到攻击机以约 1s 间隔发送的伪造 ARP reply |
第二部分：ICMP 重定向攻击
攻击原理
ICMP（Internet Control Message Protocol，互联网控制报文协议）是 TCP/IP 协议族中的辅助协议，工作在网络层，主要用于传递网络错误信息和控制消息。ICMP 重定向（Redirect）是其中一种控制消息类型（Type 5），其设计初衷是：当路由器发现某主机将数据包发往了并非最优路径的下一跳时，路由器可以主动向该主机发送 ICMP Redirect 报文，通知其"去往目的地 X 有更优路由，下一跳应改为 Y"，主机操作系统收到后会更新路由缓存，后续流量走更优路径。
这一机制的安全缺陷与 ARP 如出一辙：ICMP Redirect 报文同样缺乏发送方认证，任何人都可以伪造一个声称来自路由器的 ICMP Redirect 报文发送给目标主机，而目标主机的内核在默认配置下会无条件接受该重定向建议，将路由缓存中对应目的地的下一跳更新为攻击者指定的地址。
攻击流程如下：
正常情况：受害机 → 网关（192.168.200.1）→ 互联网（163.com）
攻击过程：
攻击机监听受害机发往外网的数据包
→ 伪造 ICMP Redirect（Type=5, Code=1: Redirect for Host）
→ 报文声称来自真实网关 192.168.200.1
→ 告知受害机：去往目的主机的更优下一跳是 192.168.200.3（攻击机）
→ 受害机更新路由缓存
攻击后：受害机 → 攻击机（192.168.200.3）→ 网关 → 互联网
本实验使用 netwox 的第 86 号功能模块实施攻击，该模块可以监听指定主机的流量，并自动构造和发送伪造的 ICMP Redirect 报文。
实验操作
步骤 1：确认各主机 IP 与路由配置
Kali Linux 攻击机 ifconfig：
图12：Kali Linux 攻击机 eth0 接口 IP 为 192.168.200.3，MAC 为 00:0c:29:83:85:26
SEEDUbuntu9 受害机 ifconfig：
图13：SEEDUbuntu9 受害机 eth6 接口 IP 为 192.168.200.5，MAC 为 00:0c:29:17:a4:60
SEEDUbuntu9 受害机 route -n 查看初始路由表：
图14：SEEDUbuntu9 初始内核路由表，默认路由（0.0.0.0/0）经由网关 192.168.200.1 转发，出口接口 eth6，这是攻击前的正常状态
Kali Linux 攻击机 route -n：
图15：Kali Linux 攻击机路由表，默认网关同为 192.168.200.1，直连子网 192.168.200.0/25 via eth0
步骤 2：受害机 ping 外网，记录初始 RTT
在 SEEDUbuntu9 上执行 ping 163.com，确认外网连通性正常，并记录初始 RTT 作为对照：
图16：SEEDUbuntu9 执行 ping 163.com，解析到 59.111.160.244，初始 RTT 约 30.5 ms，流量经真实网关 192.168.200.1 正常转发
步骤 3：使用 netwox 86 发送伪造 ICMP 重定向报文
在 Kali Linux 上以 root 权限执行 netwox 86：
sudo netwox 86 -f "host 192.168.200.5" -g 192.168.200.3 -i 192.168.200.1
图17：Kali 攻击机以 root 权限执行 netwox 86，-f 指定受害机 192.168.200.5，-g 指定新网关（攻击机）192.168.200.3，-i 伪造报文发送方为真实网关 192.168.200.1
| 参数 | 值 | 含义 |
|---|---|---|
86 |
— | netwox 功能编号，构造并发送 ICMP Redirect 报文 |
-f |
host 192.168.200.5 |
监听过滤条件：仅对受害机的数据包触发重定向 |
-g |
192.168.200.3 |
New Nexthop（新下一跳）：攻击机 IP |
-i |
192.168.200.1 |
伪造的 ICMP 发送方 IP：冒充真实网关 |
步骤 4：观察受害机路由被篡改的效果
保持 netwox 运行，观察受害机 ping 输出的变化：
图18：受害机 ping 163.com 过程中，icmp_seq=61 处出现"From 192.168.200.1: icmp_seq=61 Redirect Host (New nexthop: 192.168.200.3)"，受害机内核已将目标主机的路由缓存下一跳更新为攻击机 192.168.200.3
ping 输出在 icmp_seq=61 处出现了关键的重定向通知：
From 192.168.200.1: icmp_seq=61 Redirect Host(New nexthop: 192.168.200.3)
这条信息表明，受害机收到了伪造的 ICMP Redirect 报文，内核对目标 IP 的路由缓存已被更新，新的下一跳指向攻击机 192.168.200.3，攻击机由此处于中间人位置。
攻击危害与防御
危害分析：
ICMP 重定向攻击与 ARP 欺骗的危害类似，但作用在网络层，影响范围更广：
① 精准流量劫持：ICMP Redirect 可以针对特定目的主机（Code=1: Redirect for Host）或特定目的网段（Code=0: Redirect for Network）发起，攻击者可以精细控制劫持哪些目的地的流量，比 ARP 欺骗更具针对性。
② 路由持久污染：现代操作系统会将重定向信息写入路由缓存，即便攻击停止，路由缓存条目也会在老化前持续生效（Linux 默认缓存有效期约 10 分钟），攻击效果具有一定的时间延续性。
③ 结合 DNS 欺骗放大危害：攻击者控制流量路径后，可进一步发起 DNS 欺骗，将受害机的域名解析结果指向恶意服务器，实现网页劫持、钓鱼攻击等。
防御措施：
| 防御手段 | 实施层面 | 说明 |
|---|---|---|
| 禁用 ICMP Redirect 接受 | 主机内核 | sysctl -w net.ipv4.conf.all.accept_redirects=0，禁止内核接受 ICMP 重定向报文，是最直接有效的防御 |
| 路由器禁止发送 Redirect | 路由器配置 | 在路由器上关闭 ICMP Redirect 发送功能，减少攻击面 |
| 部署 IPSEC | 网络层 | 对 IP 报文进行认证和加密，使伪造的 ICMP 报文无法通过验证 |
| 入侵检测系统（IDS） | 安全设备 | 对网络中异常的 ICMP Redirect 流量进行检测和告警 |
| 路由监控 | 主机软件 | 定期检查路由缓存是否被意外修改，发现异常及时处置 |
第二部分小结
| 实验步骤 | 操作 | 结果 |
|---|---|---|
| 初始路由确认 | 受害机 route -n | 默认网关为真实网关 192.168.200.1 |
| 外网连通确认 | 受害机 ping 163.com | RTT 约 30 ms，流量经真实网关正常转发 |
| 发起攻击 | netwox 86 -f -g -i（需 root 权限） | 持续发送伪造 ICMP Redirect 报文 |
| 攻击效果验证 | 受害机 ping 输出 | icmp_seq=61 出现 Redirect Host (New nexthop: 192.168.200.3) |
第三部分：SYN Flood 攻击
攻击原理
SYN Flood 是一种典型的拒绝服务（Denial of Service, DoS）攻击，利用 TCP 三次握手机制中的固有缺陷实施。正常的 TCP 三次握手流程为：① 客户端发送 SYN 报文；② 服务端回复 SYN-ACK 并分配资源，将连接状态记录为"半连接（Half-Open）"存入半连接队列（SYN Backlog）；③ 客户端回复 ACK，完成握手，连接进入全连接队列供应用层 accept。
SYN Flood 攻击的核心在于利用伪造源 IP 使服务端的半连接队列耗尽：
攻击流程：
攻击机以极高速率向服务端目标端口发送大量 TCP SYN 报文
→ 每个 SYN 报文的源 IP 均为随机伪造的不可达地址
→ 服务端为每个 SYN 分配资源、回复 SYN-ACK 并等待 ACK
→ 由于源 IP 不可达，ACK 永远不会到来，半连接状态持续占用直至超时
→ 半连接队列（backlog）被大量无效条目填满
→ 合法客户端的 SYN 请求无法进入队列，直接被服务端丢弃
→ 服务端对合法用户呈现"拒绝服务"状态
本实验使用 hping3 工具实施 SYN Flood 攻击。hping3 是一款支持任意 TCP/IP 报文构造与发送的命令行工具，--flood 模式下会以接近线速持续发包，--rand-source 选项使每个报文的源 IP 随机生成，使服务端无法追踪真实来源，也无法通过 IP 黑名单过滤防御。
实验操作
步骤 1：确认靶机 Web 服务正常可访问
在受害机 SEEDUbuntu9 上打开 Firefox，访问靶机 http://192.168.200.130/，确认服务端 Apache 服务正常运行，页面可正常加载：
图19：受害机 Firefox 访问 http://192.168.200.130/ ，页面正常显示 Apache 默认页"It works!"，说明靶机 80 端口 HTTP 服务在攻击前处于正常响应状态
步骤 2：使用 hping3 对靶机 80 端口发起 SYN Flood 攻击
在 Kali Linux 攻击机上以 root 权限执行 hping3，向靶机 80 端口发起 SYN Flood 攻击：
sudo hping3 -S -p 80 --flood --rand-source 192.168.200.130
图20：Kali 攻击机执行 sudo hping3 -S -p 80 --flood --rand-source 192.168.200.130，程序输出"HPING 192.168.200.130 (eth0 192.168.200.130): S set, 40 headers + 0 data bytes / hping in flood mode, no replies will be shown"，确认进入洪泛模式，以随机源 IP 持续发送 SYN 报文，不等待任何回包
| 参数 | 值 | 含义 |
|---|---|---|
-S |
— | 设置 TCP SYN 标志位 |
-p |
80 |
目标端口：HTTP 服务端口 |
--flood |
— | 洪泛模式：以最快速率持续发包，不显示回包 |
--rand-source |
— | 随机化源 IP 地址，使服务端无法识别真实来源 |
| 最后参数 | 192.168.200.130 |
攻击目标 IP（靶机） |
步骤 3：观察攻击效果——服务端响应超时
hping3 洪泛模式运行期间，在受害机 SEEDUbuntu9 上刷新 Firefox，尝试重新访问 http://192.168.200.130/，观察服务端响应状态的变化：
图21：SYN Flood 攻击进行中，受害机 Firefox 重新访问 http://192.168.200.130/ ，标签页标题显示"Loading.."，页面持续处于加载等待状态，HTTP 请求无法建立 TCP 连接，服务端已无法响应合法请求，拒绝服务效果显现
攻击效果的对比十分明显：攻击前页面瞬间加载完成（"It works!"）；攻击发起后，Firefox 进入无限加载状态（"Loading.."），新的 TCP 三次握手无法完成，HTTP 请求无从发出。这正是半连接队列被耗尽后服务端的典型表现——所有新 SYN 请求在内核层面被静默丢弃，应用层的 Apache 对此毫无感知。
攻击危害与防御
危害分析：
① 服务完全不可用：SYN Flood 可以使目标服务端口对所有合法用户彻底停止响应，是效果最直接的 DoS 攻击手段之一。与带宽耗尽型 DDoS 不同，SYN Flood 消耗的是服务器的连接状态资源（内存中的半连接队列），即便攻击流量并不大也可能造成服务瘫痪。
② 溯源困难：--rand-source 使每个攻击报文均携带不同的随机源 IP，服务端、防火墙和 IDS 均无法通过 IP 黑名单的方式阻断攻击，传统的基于源 IP 的访问控制形同虚设。
③ 低门槛高效益：hping3 单机即可对局域网内的靶机造成明显的服务中断，若结合多台攻击机（DDoS）或反射放大（SYN 报文中填入受害者 IP 作为源，让大量第三方服务器向受害者回复 SYN-ACK），攻击规模可以指数级扩大。
④ 组合攻击前导：SYN Flood 可用于使目标服务临时下线，为后续的 IP 欺骗、DNS 投毒或服务替换等攻击创造窗口期。
防御措施：
| 防御手段 | 实施层面 | 说明 |
|---|---|---|
| SYN Cookie | 操作系统内核 | sysctl -w net.ipv4.tcp_syncookies=1，服务端在半连接队列满时不再分配资源，而是用加密 Cookie 编码连接信息，只有收到合法 ACK 后才恢复资源分配，根本上消除半连接队列耗尽问题 |
| 增大半连接队列 | 操作系统内核 | sysctl -w net.ipv4.tcp_max_syn_backlog=8192，提高队列容量以容纳更多半连接，延缓攻击生效时间（治标不治本） |
| 缩短 SYN 超时时间 | 操作系统内核 | sysctl -w net.ipv4.tcp_synack_retries=1，减少 SYN-ACK 重传次数，加快无效半连接的老化清除速度 |
| 防火墙限速 | 网络设备 | 对单位时间内来自同一源 IP 的 SYN 报文数量限速（rate limit），或对 SYN 报文总速率设置阈值 |
| CDN / 流量清洗 | 网络架构 | 将流量引入专业的 DDoS 防护清洗中心，过滤异常 SYN 流量后再回源，适用于大规模攻击场景 |
| IP 源地址验证（BCP38） | 运营商网络 | 在网络边界执行 Ingress Filtering，丢弃源 IP 不合法的出站报文，从源头阻止伪造源 IP 的 SYN 报文进入互联网 |
第三部分小结
| 实验步骤 | 操作 | 结果 |
|---|---|---|
| 攻击前确认 | 受害机 Firefox 访问 http://192.168.200.130/ | 页面正常加载"It works!" |
| 发起攻击 | hping3 -S -p 80 --flood --rand-source 192.168.200.130（root 权限） | 进入洪泛模式，以随机源 IP 持续发送 SYN 报文 |
| 攻击效果验证 | 受害机 Firefox 刷新页面 | 页面无限"Loading.."，TCP 连接无法建立，服务拒绝响应 |
第四部分：TCP RST 攻击
攻击原理
TCP（Transmission Control Protocol）是面向连接、可靠传输的传输层协议。TCP 连接的生命周期中，RST（Reset）标志位用于异常终止连接——当一端收到带有 RST 标志的 TCP 报文时，会立即认为连接出错，无需等待四次挥手，直接关闭连接并释放资源。
TCP RST 攻击（TCP Reset Attack）正是利用了这一机制：攻击者通过嗅探网络流量，捕获目标 TCP 连接的五元组信息（源 IP、目的 IP、源端口、目的端口）以及当前的序列号（Sequence Number），随后伪造一个带有 RST 标志且序列号落在接收窗口内的 TCP 报文，发送给连接的任意一端。接收方的 TCP 栈在收到该报文后，不会验证发送方的身份，只会检查序列号是否在合法范围内，若合法则立即重置连接。
攻击的关键难点在于序列号的猜测：现代操作系统的 TCP 序列号初始值（ISN）是随机生成的，理论上攻击者需要猜测有效的序列号才能使 RST 报文被接受。但在局域网环境中，攻击者可以通过嗅探明文流量直接获取当前的序列号，使攻击变得极为容易。
攻击流程：
① 受害机（192.168.200.5）与服务端（192.168.200.130）建立 Telnet 连接
② 攻击机嗅探流量，获取当前 TCP 连接的序列号 N
③ 攻击机构造伪造 TCP 报文：
- 源 IP 伪造为服务端 IP
- 目的 IP 填写受害机 IP
- 序列号填写 N（落在接收窗口内）
- TCP Flags 设置为 RST
④ 受害机收到伪造 RST，认为服务端主动断开连接，立即关闭本地套接字
⑤ Telnet 会话终止，终端显示 "Connection closed by foreign host."
实验操作
步骤 1：确认服务端网络配置
在 Metasploitable_ubuntu 上执行 ifconfig，确认服务端 IP 地址：
图22：Metasploitable_ubuntu ifconfig，eth0 接口 IP 地址 192.168.200.130，MAC 地址 00:0c:29:0a:21:ca，确认服务端在线，Telnet（23/tcp）服务开放
步骤 2：受害机与服务端建立 Telnet 会话
在 SEEDUbuntu9 受害机上执行 telnet 192.168.200.130，使用凭据 msfadmin / msfadmin 登录，建立一条合法的活跃 Telnet TCP 会话：
图23：SEEDUbuntu9 telnet 192.168.200.130，成功登录 Metasploitable（Ubuntu 8.04），Telnet 会话处于活跃状态，Last login 显示 Sun Apr 12 06:59:52 EDT 2026
步骤 3：以 root 权限执行 netwox 78 发送 TCP RST
普通用户权限执行 netwox 78 会因缺少 CAP_NET_RAW 权限报错，需切换至 root：
netwox 78 -i 192.168.200.130
图24：普通用户执行 netwox 78 报错"Error 3002: Operation not permitted"；切换 root 后执行 netwox 78 -i 192.168.200.130，开始监听目标 IP 的 TCP 连接并发送伪造 RST 报文
| 参数 | 值 | 含义 |
|---|---|---|
78 |
— | netwox 功能编号，针对指定 IP 的 TCP 连接发送 RST 报文 |
-i |
192.168.200.130 |
监听目标 IP，对流经该 IP 的 TCP 连接实施 RST 注入 |
步骤 4：Wireshark 抓包验证攻击流量
在攻击机上同步开启 Wireshark 对 eth0 进行抓包，可以观察到 netwox 78 产生的大量伪造 TCP SYN 报文：
图25：Wireshark 抓包结果，大量来自随机伪造源 IP 的 TCP SYN 报文涌向 192.168.200.130:23，Seq=0，Win=1500，源 MAC 全零（00:00:00:00:00:00），为伪造报文；帧详情确认目标端口 23，攻击特征明显
从抓包结果可以看到伪造报文的典型特征：
| 字段 | 值 | 说明 |
|---|---|---|
| 源 IP | 随机（如 188.131.85.136 等） | netwox 随机伪造的源地址，使服务端 SYN-ACK 无处可达 |
| 目的 IP | 192.168.200.130 | 靶机服务端 |
| 目的端口 | 23（Telnet） | 攻击目标服务端口 |
| TCP Flags | SYN | 触发服务端半连接队列分配 |
| Seq | 0 | 伪造固定序列号 |
| 源 MAC | 00:00:00:00:00:00 | 全零 MAC，特征明显，确认为构造报文 |
步骤 5：观察受害机 Telnet 会话被强制断开
netwox 78 运行后，回到 SEEDUbuntu9 受害机，观察 Telnet 会话的状态变化：
图26：受害机 Telnet 终端输出"Connection closed by foreign host."，连接被强制重置，受害机退回本地 shell 提示符
终端输出的 Connection closed by foreign host. 是 Telnet 客户端收到 TCP RST 时的标准响应——TCP 栈在收到伪造的 RST 报文后，立即认为连接被对端强制关闭，不等待任何确认直接释放资源，整个过程从攻击者角度来看不需要任何账号密码，完全依靠报文伪造完成。
攻击危害与防御
危害分析：
① 在线服务干扰：攻击者可以针对性地断开特定用户与服务端的连接，例如针对 BGP 路由器之间的 TCP 长连接发起 RST 攻击（BGP Session Hijacking），可能导致大规模路由中断，影响范围极广。
② 隐蔽的拒绝服务：与传统 DoS 攻击相比，TCP RST 攻击不需要大带宽，只需要发送少量精确构造的报文，隐蔽性更强，难以被流量型 DDoS 防御系统检测。
③ 防火墙"中间盒子"滥用：部分防火墙（如中国的 GFW）使用 TCP RST 注入技术来强制断开特定类型的连接，这本质上是将 RST 攻击用于网络管控。
④ 实时通信破坏：对 VoIP、在线游戏、股票交易等对连接稳定性要求极高的实时应用，TCP RST 攻击可以造成严重的业务影响。
防御措施：
| 防御手段 | 实施层面 | 说明 |
|---|---|---|
| TCP MD5 签名认证 | 传输层（RFC 2385） | 对 TCP 报文头部进行 MD5 签名，接收方验证签名失败则丢弃，可有效防止 RST 注入（主要用于 BGP） |
| TCP AO（Authentication Option） | 传输层（RFC 5925） | TCP MD5 的升级版，提供更强的认证机制 |
| 随机化 ISN | 操作系统 | 使序列号难以预测，提高攻击者猜测序列号的难度（仅在非嗅探场景下有效） |
| 使用加密隧道 | 网络层 | VPN、IPSec 等隧道技术可以使攻击者无法嗅探到序列号，从根本上阻断攻击 |
| 部署 IDS/IPS | 安全设备 | 检测网络中来源可疑、未在连接记录中出现的 RST 报文并告警或拦截 |
第四部分小结
| 实验步骤 | 操作 | 结果 |
|---|---|---|
| 确认服务端 | Metasploitable ifconfig | 服务端 192.168.200.130 在线，23/tcp 开放 |
| 建立合法会话 | 受害机 telnet 192.168.200.130（msfadmin/msfadmin） | Telnet 会话建立，活跃状态 |
| 发起攻击 | netwox 78 -i 192.168.200.130（root 权限） | 监听并注入伪造 RST 报文 |
| 流量验证 | Wireshark 抓包 | 捕获大量伪造 SYN 报文（全零 MAC，随机源 IP，目标 23/tcp） |
| 攻击效果 | 受害机 Telnet 终端 | 输出"Connection closed by foreign host."，会话被强制断开 |
第五部分：TCP 会话劫持攻击
攻击原理
TCP 会话劫持（TCP Session Hijacking）是一种综合性攻击技术，其目标是在合法的 TCP 会话建立之后，攻击者通过插入伪造的数据包"接管"该会话，以合法用户的身份与服务端进行交互，或窃取会话中传输的敏感信息。
本实验采用两种互补的攻击方式：被动型会话劫持（Passive Hijacking / Sniffing）——使用 Ettercap 将自身置于中间人位置，被动截获并分析流经的会话内容，提取用户名、密码等敏感信息；主动型会话劫持（Active Hijacking / Data Injection）——在被动嗅探获取会话五元组与序列号信息后，使用 shijack 工具向活跃 TCP 会话注入伪造数据包，以合法会话参与方的身份强行插入任意内容，完全接管连接。两种方式的攻击链如下：
第一阶段：ARP 毒化（建立中间人位置）
Ettercap 对 TARGET1（受害机 192.168.200.5）和 TARGET2（192.168.200.120）
实施双向 ARP 毒化，使两端的流量均经由攻击机转发
第二阶段（被动）：流量截获（嗅探 Telnet 明文数据）
由于 Telnet 协议以明文传输所有数据（包括用户名、密码、每次按键）
攻击机的 Ettercap 可以从转发的流量中提取完整的会话内容
第三阶段（主动）：数据注入（shijack 主动接管会话）
Wireshark 从捕获的 TELNET 报文中读取受害机源端口与当前序列号
shijack 构造带合法序列号的伪造 TCP 数据段注入连接
服务端接受注入内容，会话被攻击者完全控制
Ettercap 是一款功能强大的中间人攻击框架，集成了主机扫描、ARP 毒化、协议解析、密码嗅探等多项功能，支持 GUI（图形界面）和命令行两种工作模式。本实验使用其 GUI 模式（-G 参数）进行操作，直观展示整个攻击过程。
值得注意的是，Telnet 是一个完全明文的协议——不仅密码以明文传输，连接过程中输入的每一个字符也都是独立的 TCP 报文，攻击者可以实时看到用户的全部操作，这也是 Telnet 在现代网络环境中早已被 SSH 取代的根本原因。
实验操作
步骤 1：以 GUI 模式启动 Ettercap
在 Kali Linux 上执行以下命令，以图形界面模式启动 Ettercap：
sudo ettercap -G
图27：Kali Linux 以 sudo 权限执行 ettercap -G，输入密码后进入图形界面模式
步骤 2：配置嗅探接口并启动统一嗅探
Ettercap 启动后弹出 Setup 配置界面，Primary Interface 设置为 eth0，Sniffing at startup 保持开启，点击右上角 ✔ 确认，进入统一嗅探（Unified Sniffing）模式：
图28：Ettercap Setup 配置界面，Primary Interface 选择 eth0，Sniffing at startup 已开启，点击 ✔ 启动统一嗅探
步骤 3：扫描局域网存活主机
进入主界面后，点击 ≡ → Hosts → Scan for hosts 扫描当前局域网存活主机：
图29：点击菜单 Hosts，展开子菜单准备执行主机扫描
图30：点击 Scan for hosts，Ettercap 对网段内 127 个地址逐一发起扫描
图31：扫描完成，日志显示"Randomizing 127 hosts... Scanning the whole netmask for 127 hosts... 6 hosts added to the hosts list."，共发现 6 台存活主机
步骤 4：查看主机列表并配置攻击目标
点击 Hosts → Hosts list 查看扫描到的主机列表：
图32：Ettercap Host List，共列出 8 台主机，包含网关 192.168.200.1（00:50:56:FE:52:AA）、受害机 192.168.200.5（00:0C:29:17:A4:60）等
右键点击 192.168.200.5（受害机），选择 Add to Target 1：
图33：右键 192.168.200.5 → Add to Target 1，将受害机 SEEDUbuntu9 设为 ARP 毒化目标 1
右键点击 192.168.200.120，选择 Add to Target 2：
图34：右键 192.168.200.120 → Add to Target 2，底部日志确认"Host 192.168.200.5 added to TARGET1 / Host 192.168.200.120 added to TARGET2"
步骤 5：启动 ARP 毒化中间人攻击
点击 ≡ → MITM → ARP poisoning…，在弹出对话框中勾选 Sniff remote connections.，点击 OK 启动双向 ARP 毒化：
图35：点击 MITM → ARP poisoning…，进入参数配置界面
图36：勾选 Sniff remote connections（允许嗅探远程连接），保持 Only poison one-way 不勾选（执行双向毒化），点击 OK 确认
ARP 毒化成功启动，底部日志输出确认信息：
图37：底部日志显示"ARP poisoning victims: GROUP 1: 192.168.200.5 00:0C:29:17:A4:60 / GROUP 2: 192.168.200.120 00:50:56:E5:43:06"，ARP 毒化成功，攻击机处于两个目标之间的中间人位置
步骤 6：打开连接视图，监控网络连接
点击 ≡ → View → Connections 打开连接监控视图：
图38：点击view
图39：点击connections 打开链接
图40：当前 Connections 视图中仅有若干 UDP idle 连接，尚未出现 Telnet TCP 连接，等待受害机发起 Telnet 会话
步骤 7：受害机建立 Telnet 会话
在 SEEDUbuntu9 受害机上执行 telnet 192.168.200.130，输入 msfadmin / msfadmin 完成登录：
图41：SEEDUbuntu9 执行 telnet 192.168.200.130，服务端返回登录提示，正在输入用户名 msfadmin 和密码
图42：Telnet 登录成功，进入 Metasploitable shell（msfadmin@metasploitable:~$），"1 failure since last login"提示说明此前有登录失败记录，会话处于活跃状态
步骤 8：Ettercap 截获明文凭据
受害机建立 Telnet 会话后，Ettercap Connections 视图中出现了 TCP active 连接 192.168.200.5:51701 → 192.168.200.130:23，底部日志同步打印出截获的明文凭据：
图43：Connections 视图中 192.168.200.5:51701 → 192.168.200.130:23 状态为 active，TX Bytes 27；底部日志输出"TELNET: 192.168.200.130:23 → USER: msfadmin PASS: msfadmin"，用户名与密码均以明文截获
TELNET : 192.168.200.130:23 -> USER: msfadmin PASS: msfadmin
步骤 9：查看 Connection data 完整还原会话内容
双击该条 TCP active 连接，打开 Connection data 详情页：
图44：Connection data 详情页，左侧（192.168.200.5:51701）显示受害机发送的数据流，可见明文用户名"msfadmin"和密码"msfadmin"；右侧（192.168.200.130:23）显示服务端响应，包括 Ubuntu 欢迎信息和 shell 提示符；底部日志持续显示"TELNET: 192.168.200.130:23 → USER: msfadmin PASS: msfadmin"
| 数据内容 | 来源 | 说明 |
|---|---|---|
msfadmin |
受害机（左侧数据流） | 登录用户名，逐字符明文传输 |
msfadmin |
受害机（左侧数据流） | 登录密码，逐字符明文传输 |
| Ubuntu 8.04 欢迎信息 | 服务端（右侧数据流） | 服务端返回的登录欢迎页 |
msfadmin@metasploitable:~$ |
服务端（右侧数据流） | Shell 提示符，确认登录成功 |
延伸实验：使用 shijack 工具实施主动 TCP 会话劫持
在上述被动嗅探的基础上，进一步使用 shijack 工具实施主动型会话劫持——通过向活跃 TCP 会话注入带合法序列号的伪造数据段，强行接管受害机与服务端之间的 Telnet 连接。shijack 的攻击核心是利用嗅探到的序列号构造合法 TCP 数据包并发送，无需任何账号凭据即可以会话参与方身份向服务端发送任意内容。
步骤 10：Wireshark 捕获 Telnet 流量，记录会话五元组
在 Kali Linux 攻击机上打开 Wireshark，选择 eth0 接口，在显示过滤器中输入 telnet，捕获受害机（192.168.200.5）与服务端（192.168.200.130）之间的 Telnet 数据包。由于 Ettercap 已将攻击机置于中间人位置，所有 Telnet 流量均经过攻击机转发，Wireshark 可完整捕获：
图45：Wireshark 使用 telnet 过滤器捕获到受害机（192.168.200.5）与服务端（192.168.200.130）之间的 TELNET 数据包；各帧长度为 60 字节（1 byte data），对应 Telnet 逐字符传输的典型特征；双向流量均可见，确认中间人位置建立成功
选中任意一条来自受害机（源 IP 192.168.200.5）的 TELNET 报文，在帧详情面板中展开 TCP 层，记录关键字段：
图46：Wireshark 选中第 3460 号帧（来自 192.168.200.5，共 1078 字节，包含 1024 bytes data），TCP 层详情显示源端口 36545、目标端口 23、Seq=7、Ack=75、Len=1024；以太网层源 MAC 为攻击机 00:0c:29:83:85:26，确认流量已经过攻击机转发；源端口 36545 即为后续 shijack 命令所需的受害机 TCP 源端口
| 字段 | 值 | 用途 |
|---|---|---|
| 源 IP | 192.168.200.5 | shijack 参数：受害机 IP |
| 源端口 | 36545 | shijack 参数：受害机源端口（关键） |
| 目的 IP | 192.168.200.130 | shijack 参数：服务端 IP |
| 目的端口 | 23 | shijack 参数：Telnet 端口 |
| Seq | 7 | 当前序列号，shijack 据此构造合法数据包 |
步骤 11：追踪 TCP 流，确认会话明文内容
在 Wireshark 中右键任意 TELNET 数据包，选择 追踪流 → TCP 流，还原双方完整的明文会话交互内容：
图47：Wireshark 追踪 TCP 流（tcp.stream eq 0），红色为受害机发送内容，蓝色为服务端响应；可见受害机逐字符输入命令"ls"（显示为 l、l、s、s 四个独立字符），服务端返回目录内容"vulnerable"及 shell 提示符 msfadmin@metasploitable:~$；此为 shijack 注入前的正常会话状态
步骤 12：确认受害机 Telnet 会话当前状态
切换至 SEEDUbuntu9 受害机终端，确认 Telnet 会话正处于活跃登录状态，受害机用户正常与服务端交互，对即将发生的主动劫持毫不知情：
图48：受害机（seed@seed-desktop）Telnet 会话界面：已成功连接 192.168.200.130（Ubuntu 8.04），以 msfadmin 身份登录，执行 ls 命令返回目录 vulnerable，当前 shell 提示符为 msfadmin@metasploitable:~$，受害机正常使用中，对攻击行为完全不知情
步骤 13：下载 shijack 主动会话劫持工具
在 Kali Linux 攻击机上，通过 wget 从 Packet Storm Security 下载 shijack 工具包：
wget https://dl.packetstormsecurity.net/sniffers/shijack.tgz
图49：Kali 攻击机以普通用户（ljt27@kali）执行 wget 命令，从 dl.packetstormsecurity.net 下载 shijack.tgz（468 KB），服务端返回 200 OK，以 565 KB/s 的速度在 0.8 秒内完成下载，文件成功保存为 shijack.tgz（479014 字节）
下载完成后，执行 tar -xzf shijack.tgz 解压，解压目录中包含针对不同架构预编译的二进制文件，本实验在 x86_64 Linux 环境下使用 shijack-lnx。
步骤 14：执行 shijack 发起主动 TCP 数据注入
根据步骤 10 中 Wireshark 捕获到的受害机源端口 36545，构造 shijack 命令。命令格式为：
shijack-lnx <网络接口> <受害机IP> <受害机源端口> <服务端IP> <服务端端口>
在 Kali 攻击机上以 root 权限执行：
sudo ./shijack/shijack-lnx eth0 192.168.200.5 36545 192.168.200.130 23
图50：在 Kali 攻击机终端（与 Wireshark 并排）输入 sudo ./shijack-lnx eth0 192.168.200.5 36545 192.168.200.130 23，参数依次为：监听接口 eth0、受害机 IP 及从 Wireshark 获取的源端口 36545、服务端 IP 及 Telnet 端口 23
图51：切换至 root 权限后执行 shijack-lnx，程序输出"Waiting for SEQ/ACK to arrive from the srcip to the dstip."，工具正在嗅探网络接口，等待捕获来自受害机（srcip）发往服务端（dstip）的 TCP 报文以获取当前有效序列号；括号中提示"To speed things up, try making some traffic between the two"——在受害机上执行任意操作即可触发数据包，加速序列号捕获
| 参数位置 | 值 | 含义 |
|---|---|---|
| 第 1 参数 | eth0 | 监听并发包的网络接口 |
| 第 2 参数 | 192.168.200.5 | 受害机 IP（TCP 连接源端） |
| 第 3 参数 | 36545 | 受害机 TCP 源端口（由 Wireshark 抓包获取） |
| 第 4 参数 | 192.168.200.130 | 服务端 IP（TCP 连接目标端） |
| 第 5 参数 | 23 | 服务端 Telnet 端口 |
步骤 15：Wireshark 验证主动数据注入效果
shijack 捕获到有效序列号后，立即向该 TCP 会话注入伪造数据段。回到 Wireshark，刷新 TCP 流追踪视图，观察注入前后的对比：
图52：Wireshark 追踪 TCP 流（注入后），在正常的会话内容（ls、vulnerable、msfadmin@metasploitable:~$ 等）之后，数据流末尾出现大片红色点阵区域——这是 shijack 注入的大量空字节（null bytes），接管了受害机到服务端方向的 TCP 数据流；服务端收到注入内容后无法区分真伪，会话已被攻击者完全控制，受害机原有连接同步失效
从追踪结果可以清晰看到注入的边界：正常交互的字符流结束处，紧接着出现了由 shijack 写入的大量空字节块（图中红色点阵区域）。这一块数据是以受害机的 IP 与端口为源伪造发出的，服务端的 TCP 栈验证序列号合法后无条件接受，实现了不需要账号密码、完全基于序列号的主动会话劫持。
攻击危害与防御
危害分析：
① 凭据泄露：本实验最直观的危害——用户名和密码在网络上以明文传输，攻击者无需任何暴力破解即可直接获取。一旦取得凭据，攻击者可以随时以合法用户身份登录目标系统，获取系统控制权。
② 敏感数据窃取：Ettercap 的 Connection data 视图可以完整还原会话中传输的所有内容，不仅是登录凭据，用户在 shell 中执行的所有命令、查看的文件内容、传输的数据都暴露无遗。
③ 主动注入攻击（shijack 进阶）：被动嗅探只是 TCP 会话劫持的初级形式。如延伸实验所示，攻击者可利用 shijack 等工具向活跃会话注入任意数据，例如在受害机的 Telnet 会话中悄悄执行反弹 shell、创建后门账户等操作，而受害机用户对此毫不知情，危害极大。
④ 横向移动跳板：获取一台主机的凭据后，攻击者可以利用"密码复用"现象（很多用户在多个系统使用相同密码）横向渗透至同一局域网内的其他主机。
防御措施：
| 防御手段 | 实施层面 | 说明 |
|---|---|---|
| 使用 SSH 替代 Telnet | 应用层 | SSH 对传输内容进行端对端加密，即便攻击者成功实施中间人攻击，截获的数据也是无法直接解读的密文 |
| 启用 SSH 公钥认证 | 应用层 | 相比密码认证，公钥认证即便密码被截获也无法被重放使用 |
| 网络层加密（VPN/IPSec） | 网络层 | 在局域网内部署 VPN 或 IPSec，使所有流量在传输层以下即被加密 |
| 防御 ARP 毒化（参见第一部分） | 数据链路层 | 会话劫持依赖 ARP 毒化作为前提，阻断 ARP 毒化即可釜底抽薪 |
| 802.1X 端口认证 | 数据链路层 | 交换机端口级别的身份认证，未经认证的设备无法接入网络，从根源上阻止攻击机接入局域网 |
| 多因素认证（MFA） | 应用层 | 即便密码被截获，没有第二因素（如 OTP、硬件 Key）也无法登录 |
第五部分小结
| 实验步骤 | 操作 | 结果 |
|---|---|---|
| 启动工具 | sudo ettercap -G，选择 eth0 | 图形界面模式启动，统一嗅探开始 |
| 主机发现 | Hosts → Scan for hosts | 发现 6~8 台存活主机 |
| 设置目标 | 192.168.200.5 → Target 1；192.168.200.120 → Target 2 | 攻击目标配置完毕 |
| ARP 毒化 | MITM → ARP poisoning（Sniff remote connections） | 双向毒化成功，攻击机处于中间人位置 |
| 受害机建立会话 | telnet 192.168.200.130（msfadmin/msfadmin） | Telnet 会话建立，流量经攻击机转发 |
| 截获凭据（被动） | Connections 视图 + 底部日志 | 明文截获 USER: msfadmin PASS: msfadmin |
| 查看会话详情 | Connection data 详情页 | 完整还原双方 Telnet 会话内容，包括用户名、密码、命令交互 |
| Wireshark 抓包 | 过滤 telnet，查看帧详情 | 获取受害机 TCP 源端口 36545 及当前序列号 |
| 追踪 TCP 流 | 右键 → 追踪流 → TCP 流 | 明文还原完整会话内容，注入前状态确认 |
| 确认受害机状态 | 受害机终端 ls 命令 | 会话活跃，受害机正常操作中 |
| 下载 shijack | wget shijack.tgz 并解压 | 工具就绪，shijack-lnx 可执行 |
| 主动注入（shijack） | sudo ./shijack-lnx eth0 192.168.200.5 36545 192.168.200.130 23 | 等待 SEQ/ACK 后自动注入伪造数据段 |
| 验证注入效果 | Wireshark TCP 流追踪（注入后） | 数据流末尾出现大块空字节注入，会话被主动接管 |
三、学习中遇到的问题及解决
-
问题 1：实验开始后，在 Kali Linux 攻击机上执行
ifconfig发现 eth0 的 IP 地址为192.168.200.8，而非预期的192.168.200.3。检查后发现192.168.200.8正是蜜网网关（Honeywall）所使用的 IP 地址，Kali 虚拟机与蜜网网关发生了 IP 地址冲突，导致后续所有基于 IP 的攻击实验均无法正确指定攻击机身份，必须先解决冲突。 -
问题 1 解决方案：首先确认冲突现象。
图53：ifconfig 输出显示 Kali eth0 当前 IP 为 192.168.200.8，与蜜网网关地址冲突，需手动修正为 192.168.200.3
随后编辑 /etc/network/interfaces，将 eth0 配置为静态地址 192.168.200.3，gateway 指向蜜网网关 192.168.200.8：
图54：vim /etc/network/interfaces，eth0 配置 static，address 192.168.200.3，netmask 255.255.255.128，gateway 192.168.200.8（蜜网网关）
修改配置后，在两个终端分别执行双向 arpspoof，验证攻击机 IP 已正确生效：
# 终端 1：向受害机声称网关已迁移到攻击机
arpspoof -i eth0 -t 192.168.200.5 192.168.200.1
# 终端 2：向网关声称蜜网网关已迁移到攻击机
arpspoof -i eth0 -t 192.168.200.1 192.168.200.8
图55：终端 1 执行 arpspoof -i eth0 -t 192.168.200.5 192.168.200.1，持续向受害机声称网关 is-at 攻击机 MAC 00:0c:29:83:85:26
图56：终端 2 执行 arpspoof -i eth0 -t 192.168.200.1 192.168.200.8，向网关声称蜜网网关 is-at 攻击机 MAC，完成双向 ARP 毒化
在受害机上验证：arp -a 显示相关条目已映射为攻击机 MAC，arp -d * 清空后再查缓存仍持续被刷入，说明攻击恢复正常：
图57：受害机 arp -a 显示 192.168.200.8 映射为攻击机 MAC 00:0c:29:83:85:26；arp -d * 清空后再查，网关 192.168.200.1 亦再次映射为攻击机 MAC，双向毒化持续生效
-
问题 2：通过
vim /etc/network/interfaces将 Kali 虚拟机 IP 修改为192.168.200.3并保存后，尝试执行sudo ifdown eth0 && sudo ifup eth0重启网络接口，结果提示"Error: ipv4: Address already assigned. ifup: failed to bring up eth0"，接口重启失败。检查route -n发现默认网关显示为192.168.200.8而非预期的192.168.200.1，ping 网关和外网均不通，网络完全失联。 -
问题 2 解决方案：分析原因有两点：
ifdown/ifup在地址已被内核持有时会报地址冲突无法使用；配置文件中 gateway 字段此前也存在误填，导致写入了错误的默认网关。解决分三步进行。
第一步：重新编辑 /etc/network/interfaces，将 gateway 修正为正确值 192.168.200.1：
图58：重新编辑 /etc/network/interfaces，gateway 修正为 192.168.200.1，address 192.168.200.3，netmask 255.255.255.128，保存退出
第二步：放弃 ifdown/ifup，改用 ip 命令序列手动刷新接口与路由，写入 DNS 配置：
sudo ip link set eth0 down
sudo ip addr flush dev eth0
sudo ip link set eth0 up
sudo ip addr add 192.168.200.3/25 dev eth0
sudo ip route add default via 192.168.200.1
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf
图59：ifdown/ifup 报错"Address already assigned"；改用 ip 命令序列手动重新配置地址与路由，写入 DNS 配置 nameserver 8.8.8.8
第三步：验证修复效果：
图60：修复后 ifconfig 确认 eth0 IP 为 192.168.200.3，route -n 显示默认网关已恢复为 192.168.200.1
图61：ping 192.168.200.1（网关）零丢包 RTT 约 0.13 ms，ping 8.8.8.8 RTT 约 223 ms，内外网连通性完全恢复
图62：最终 route -n 确认默认路由经 192.168.200.1 转发，直连路由 192.168.200.0/25 正常，网络完全恢复
-
问题 3：在执行 ICMP 重定向攻击时，切换至 root 后运行
netwox 86，终端提示"sudo: netwox: 找不到命令"，系统中未预装 netwox，ICMP 重定向和 TCP RST 攻击实验均无法进行。 -
问题 3 解决方案：netwox 并非 Kali Linux 默认预装工具，需手动安装。因问题 2 已恢复网络，直接通过 apt 在线安装：
sudo apt-get update
sudo apt-get install netwox
图63：以 root 权限执行 netwox 86 命令，终端报错"sudo: netwox: 找不到命令"，确认系统未安装 netwox，需手动通过 apt 安装
图64：sudo apt-get update 从中科大镜像源更新包列表（76.1 MB，耗时 37 秒）；sudo apt-get install netwox 解析依赖后新安装 netwox 和 netwag 共 2 个软件包（646 kB），输入 y 确认，安装成功
安装完成后 netwox 命令正常调用，后续 ICMP 重定向（netwox 86）和 TCP RST（netwox 78）实验均顺利执行。这个问题让我意识到，在渗透测试实验前应该提前核查所需工具的安装情况，避免在关键操作时被环境问题打断思路，影响实验节奏。
四、学习感悟、思考等
做完这次实验，我最深的感受是：教科书上的"协议缺陷"真的不是在危言耸听。以前看书的时候觉得 ARP 欺骗、ICMP 重定向这些概念都停留在理论层面，真正动手之后才发现这些攻击的门槛低得出乎意料——一行 arpspoof 命令，或者一个 netwox 模块，就能实现书上讲的所有效果。这种落差让我对"为什么要学网络安全"这件事的理解发生了很大变化。
关于 ARP 欺骗，让我印象最深的不是攻击本身，而是步骤 5 做的那个持续性验证——受害机自己用 arp -d * 清空了缓存，但几乎立刻就又被攻击机刷回来了。这个细节很有意思：协议的缺陷是结构性的，不是"重启一下就能解决"的那种问题。受害机唯一能做的事（刷新缓存）对攻击者没有任何实质性阻挠，因为攻击者只需要以更高的频率发包就行。这让我意识到，某些安全问题的根本解决方案不在于"打补丁"，而在于整个信任模型的重新设计，DAI 之所以有效，是因为它把信任的锚点从终端主机移到了交换机这个更可信的基础设施上。
关于 ICMP 重定向，这个实验让我对"路由"这件事有了新的角度。平时我们说"路由是网络层的事"，好像路由决策是固定的、客观的，但这次实验说明路由缓存是可以被外部报文动态修改的，而且修改它的门槛非常低。我在受害机 ping 输出里看到那条 Redirect Host (New nexthop: 192.168.200.3) 的时候，第一反应是觉得受害机有点"委屈"——它只是在正常上网，却被一条它根本没法辨别真伪的重定向通知改变了路由决策。这让我对"网络中的信任"有了更立体的认识：我们平时认为"理所当然"的网络行为（比如数据会走预期的路径到达目的地），背后其实依赖着一大堆未经验证的假设。
关于 SYN Flood 攻击，这次实验让我对"拒绝服务"有了最直观的体感。攻击前 Firefox 访问 192.168.200.130 页面瞬间加载完成，攻击发起后页面立刻陷入无限"Loading.."——这中间只隔了一行 hping3 命令。更值得深思的是攻击的非对称性：攻击者发出的每一个 SYN 报文只需 40 字节，而服务端却要为此分配完整的半连接资源并等待超时，这种资源消耗上的不对等使 SYN Flood 成为极具性价比的攻击手段。SYN Cookie 的设计思路让我印象深刻——它将"先分配资源再验证"改为"先验证再分配资源"，用密码学的手段打破了攻击的不对等性，这种思路的转变体现了防御者在协议层面的智慧。
关于 TCP RST 攻击，这次实验给我上了一课：TCP 连接的"可靠性"只是在正常通信双方之间的可靠性，对于第三方的恶意干扰，TCP 协议本身几乎没有任何防御手段。Connection closed by foreign host. 这行提示出现的那一刻，让我直观感受到了 TCP 状态机的脆弱——它的状态转换完全依赖报文头部的几个标志位，只要序列号对上了，它就不会怀疑这个 RST 是不是假的。从防御角度来想，TCP MD5 签名（RFC 2385）的设计思路其实就是给这个信任链补了一环，让接收方有能力验证"这个 RST 确实是对端发出来的"，但代价是通信双方需要提前共享一个密钥，部署复杂度明显上升。这种"安全与便利的权衡"是整个网络安全领域永恒的主题。
关于 Ettercap 会话劫持与 shijack 主动注入，这部分的体验感是这次实验里最强的。Ettercap 把 ARP 毒化和协议解析封装在一个图形界面里，几次鼠标点击就完成了整个攻击链，底部日志直接打印出 USER: msfadmin PASS: msfadmin，Connection data 界面里甚至能看到完整的 Telnet 交互记录。而 shijack 的延伸实验则更进一步——它揭示了被动嗅探和主动注入之间的本质差异：被动嗅探只是"旁观者"，主动注入则让攻击者真正成为了通信的参与方。Wireshark TCP 流追踪里那一大块红色点阵（注入的空字节）让我很直观地感受到：会话已经不再属于受害机了。这让我切实理解了"Telnet 为什么被废弃"这个问题——不是因为它不好用，而是因为它每一个字节都在"裸奔"，任何处于中间人位置的观察者都可以原文照录，甚至直接篡改。SSH 之所以能取代 Telnet 并长久存活，核心就在于它在建立连接时就完成了双向身份认证和密钥协商，后续所有数据都在加密通道里传输，即便攻击者截包，拿到的也是毫无意义的密文。
这次实验还让我体会到了"环境问题"在安全实验中的重要性。Kali IP 与蜜网网关冲突、netwox 未预装、ifdown/ifup 不可用这三个问题，每一个单独拿出来都不难解决，但叠加在一起、在实验进行到一半的时候突然碰到，很容易让人焦虑。事后复盘，每一个问题其实都有清晰的根因和解法，关键是要有条理地排查，而不是瞎改。网络配置尤其如此——随便改一个参数可能让另一个设置失效，最安全的方式是用 ip 命令一步步手动操作，每一步都验证结果，而不是依赖高层封装工具（如 ifdown/ifup）却不知道它在底层做了什么。
最后想说一点更宏观的思考：这五个攻击——ARP 欺骗、ICMP 重定向、SYN Flood、TCP RST、会话劫持，背后其实对应着同一个核心问题：局域网内的主机之间、主机与路由器之间，缺乏足够强的身份认证机制。ARP 信任任何声称"我是某 IP"的 MAC 地址；ICMP 信任任何声称来自路由器的重定向建议；TCP 信任任何序列号合法的 RST 报文；TCP 握手机制本身也可以被无限消耗以制造 DoS。这些设计在 ARPANET 那个年代是合理的，因为接入网络的用户默认是可信的研究人员，但放在今天的互联网上就显得格外脆弱。零信任（Zero Trust）架构之所以在近年来被越来越多的组织采用，本质上就是对"不要默认信任同一网络内的任何实体"这一原则的回归——无论在哪里，每次访问都要验证身份，每条数据都要加密传输。这不是矫枉过正，而是在充分认识了网络协议先天缺陷之后应有的应对姿态。
参考资料
- ARP 协议 RFC 826
- ICMP 协议 RFC 792
- TCP 协议 RFC 793
- TCP MD5 签名认证 RFC 2385
- TCP Authentication Option RFC 5925
- netwox 官方文档
- Ettercap 官方项目主页
- arpspoof 使用说明（dsniff 套件）
- shijack TCP 会话劫持工具（Packet Storm Security）
- hping3 官方文档
- SYN Cookie 机制说明（Linux Kernel）
- Dynamic ARP Inspection（DAI）Cisco 文档
- W. Richard Stevens. TCP/IP Illustrated, Volume 1: The Protocols[M]. Addison-Wesley, 1994.
浙公网安备 33010602011771号