企业官网建设流程全解析

简介：西南科技大学网络攻防与对抗课程实验三的ARP欺骗实验报告，面向需要完成验证型实验或学习网络攻防基础的高校学生。报告基于Cain与Winpcap工具，完整还原了双虚拟机攻防环境下的ARP欺骗流程，从地址解析协议原理、攻击者与被攻击主机的网络配置，到扫描MAC地址、添加欺骗规则、启动攻击，再到telnet与ftp抓包验证和ARP缓存对比，均有分步记录。文中还整理了服务配置、工具操作中的常见踩坑点与排错思路，对初次使用Cain的读者尤其有帮助，可作为课程报告模板或实验复现手册。读者按文档操作即可复现完整的欺骗与嗅探过程，从而更直观地理解局域网通信的安全弱点。资源共1个文件，为doc格式实验报告，压缩包大小1.99MB，内容涵盖实验目的、环境工具、详细步骤、讨论分析、自评及关键命令，结构紧凑便于查阅。已有2380人学习下载，适合网络攻防与对抗相关课程的预习、作业和复习场景。

1. ARP 欺骗实验到底在练什么：链路层攻击的第一课

做网络攻防实验的都知道，ARP 欺骗是这个方向里第一个能“看得见摸得着”的攻击手法。我第一次抓包看到网关 MAC 地址在几秒钟之内反复变化的时候，第一反应是网线松了，后来才发现是有人在同一个二层网段里发伪造的 ARP 应答。西南科技大学网络攻防与对抗这门课把 ARP 欺骗放到实验三，这个顺序是有道理的：协议脆弱性、中间人攻击的流量走向、抓包验证、环境恢复，这些基本功在后续的 DHCP 欺骗、DNS 欺骗实验里全都会再用到。

这门实验解决的是一个很具体的问题：在不做任何加密的情况下，局域网里的流量凭什么相信“谁跟我说网关是谁，我就信谁”。ARP 协议只做了 IP 到 MAC 的映射，却没做身份认证，于是任何人都可以冒充网关。通过这个实验，你能亲手复现一次标准的中间人攻击，看到流量是怎么绕路经过攻击机转发的，也搞清楚为什么静态 ARP 绑定到现在依然是很多内网的安全基线。适合正在上网络攻防课程的学生、准备参加网络攻防演练的初学者，以及要从零开始排查内网异常 ARP 告警的运维同学。

2. 搭建实验环境：VMware 网卡模式选型与两台机器的 IP 规划

2.1 为什么用 NAT 模式而不是桥接模式

做 ARP 欺骗实验，第一个决定实验成败的不是命令，而是 VMware 的网卡模式。很多人在这一步翻车，直接把 ARP 欺骗发到了真实局域网里。

三种模式的核心差异在于 ARP 广播能“看到”谁。

桥接模式下，虚拟机的网卡直接接在物理交换机的广播域里，攻击机发送的伪造 ARP 应答会抵达宿主机所在局域网的所有主机。你本来只想骗实验靶机，结果整个网段的主机都可能把网关 MAC 缓存成攻击机的 MAC，严重的会把宿舍或者实验室的网络打瘫。我见过最夸张的一次，是有人用桥接模式做 ARP 欺骗，半个实验室都上不了网。

NAT 模式为什么可以放心用？因为 VMware 在宿主机里虚拟出了一个独立的二层网段，所有 ARP 广播都限制在 VMnet8 这个虚拟交换机内部，物理局域网里的真实主机完全感知不到。网关 192.168.137.1 是虚拟出来的 NAT 网关，你欺骗它、或者欺骗网段里的其他虚拟机，都不会影响到宿主机和物理网络。

那么如何确认自己的 NAT 网段？在宿主机上打开命令行执行ipconfig，找到“VMware Network Adapter VMnet8”这个适配器，它的 IPv4 地址就是你当前 NAT 网段的出接口地址。网段通常是 192.168.137.0/24 或 192.168.147.0/24，不同 VMware 版本和宿主机环境会有差异。注意这个地址不是网关地址，网关一般是该网段的 .1 地址。

2.2 攻击机和靶机的静态 IP 规划

我这里按最常见的拓扑来搭：攻击机用 Kali Linux，靶机用 Windows 10。如果你手头只有两台 Linux 虚拟机，同样可以做，只是验证阶段的命令不太一样。

先把三台设备的地址规划好。以下 IP 以 VMware 默认 NAT 网段为基准。

靶机建议把静态 IP 配好而不是依赖 DHCP。原因很简单：实验过程中你要反复用arp -a检查网关 MAC 有没有变化，如果 DHCP 租约变了或者网卡重新协商了，你会分不清是实验效果还是网络抖动。静态 IP 让变量最小化，出了问题时排查链路也简单得多。

攻击机上确认网卡设备名。Kali 里执行ip addr show，找到 IP 为 192.168.137.10 的那个接口，记下接口名。VMware 虚拟机通常是eth0，但某些新版本 Kali 会出现ens33或者ens160。后面所有命令里的-i参数都要跟着实际接口名走，写错了 arpspoof 会静默失败，非常坑。

靶机是 Windows 的话，进入“控制面板 → 网络连接 → 以太网适配器 → 属性 → Internet 协议版本 4”，填入上表的 IP。实验期间建议临时关闭 Windows 防火墙，因为后续要用arp -a和浏览器访问测试页面，防火墙有时候会干扰验证步骤，关闭能省去很多无关变量。

2.3 实验开始前的连通性自检

IP 配好之后，先做一遍连通性检查。这一步很多人跳过，结果实验做到一半发现靶机根本 ping 不通网关，还以为是 ARP 欺骗生效了。

在靶机上执行：

ping 192.168.137.1 -t

这个命令持续 ping 虚拟网关。正常情况下延迟应该是 1 到 2 毫秒，而且稳定。在攻击机上也同样 ping 一下靶机和网关。

顺便确认靶机能解析网关的 MAC：

arp -a

输出里应该能看到192.168.137.1对应的 MAC 地址是 VMware 的虚拟网卡 MAC，通常以00:50:56或00:0c:29开头。把这个 MAC 抄下来，它是后面判断欺骗是否生效的基准值。

提示：不同 VMware 版本的默认 NAT 网段可能不同，不要照抄 192.168.137.0/24 就完事。以宿主机上 ipconfig 查到 VMnet8 适配器的实际网段为准。

3. 用 arpspoof 发起双向欺骗：最小命令与转发参数

3.1 先打开 IP 转发：不开会变成断网攻击

ARPC 欺骗本身只是修改对端的 ARP 缓存表。如果你只做欺骗、不转发流量，那效果就是靶机把数据包都发给了攻击机，但攻击机又不知道往哪儿送，于是靶机直接断网。很多同学第一次做实验，看到靶机断网就以为成功了，其实只做了一半。

要把中间人攻击的完整链路搭起来，必须先让攻击机开启 IP 转发，这样攻击机收到靶机的数据包之后，可以当作路由器转发给真正的网关。

# 立即开启 IPv4 转发，无需重启 echo 1 > /proc/sys/net/ipv4/ip_forward # 验证是否生效，输出 1 表示已开启 cat /proc/sys/net/ipv4/ip_forward

这里要理解 IPC 转发的作用。/proc/sys/net/ipv4/ip_forward是内核的网络栈开关，0 表示不转发非本机目的地址的 IP 包，1 表示允许转发。攻击机上开启后，内核会把收到但目的 IP 不是自己的数据包，按照路由表重新送出去。这条命令是临时的，重启后失效，如果需要持久化，写入/etc/sysctl.conf：

echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf sysctl -p

注意，开启 IP 转发之前，攻击机自己的网卡也会收到大量 ARP 包，但那是以太网层的事，和 IP 转发没有关系，不用纠结。

3.2 arpspoof 两条命令：同时欺骗靶机和网关

arpspoof 是 dsniff 工具包里的经典工具，Kali 默认不自带，先安装：

sudo apt update && sudo apt install -y dsniff

安装完成后，打开两个终端窗口，或者用&把两个进程放到后台。下面是完整的最小命令：

# 终端 1：欺骗靶机，让靶机认为攻击机就是虚拟网关 sudo arpspoof -i eth0 -t 192.168.137.20 192.168.137.1 # 终端 2：欺骗网关，让网关认为攻击机就是靶机 sudo arpspoof -i eth0 -t 192.168.137.1 192.168.137.20

第一条命令的含义是：向目标 192.168.137.20（靶机）持续发送 ARP 应答，宣称“192.168.137.1（网关）的 MAC 地址是攻击机的 MAC”。第二条命令相反：向目标 192.168.137.1（网关）发送 ARP 应答，宣称“192.168.137.20（靶机）的 MAC 地址是攻击机的 MAC”。

参数解释如下：

• -i eth0：指定使用哪块网卡发送 ARP 包。必须和攻击机真实接口名一致，写错了命令不会报错，但包根本没发出去。
• -t 目标IP：指定要欺骗的主机。默认不写-t时会对整个网段广播欺骗，实验环境里不要这么干。
• 最后的192.168.137.1：要伪装成的 IP。向目标宣称这个 IP 归属攻击机。

如果你用的是两个终端，两个命令分别在前台运行，日志会滚动显示发送的包。用后台方式运行的话，注意把输出重定向到日志文件，不然关闭终端时进程会收到 SIGHUP 直接退出。

sudo arpspoof -i eth0 -t 192.168.137.20 192.168.137.1 > /tmp/spoof_target.log 2>&1 & sudo arpspoof -i eth0 -t 192.168.137.1 192.168.137.20 > /tmp/spoof_gw.log 2>&1 &

后台运行的日志文件里会记录每条 ARP 应答的发送信息，排错时很有用。查看方式：

tail -f /tmp/spoof_target.log

3.3 为什么只骗一个方向不行

这是 ARP 欺骗实验里最值得想清楚的一个问题。很多同学只执行了第一条命令，欺骗了靶机，然后发现靶机浏览网页没有任何变化，就以为实验失败。

原因是 TCP 是双向通信。靶机发出的数据包确实到了攻击机，但攻击机转交给网关之后，网关回复的数据包是直接发给靶机的真实 MAC 地址的。为什么？因为网关没有被欺骗，它的 ARP 缓存里，靶机的 IP 对应的是靶机真实的 MAC。于是回包绕过了攻击机，整个会话在传输层就乱套了。

更准确地说，单方向欺骗不是没效果，而是效果表现为异常而非可控的中间人。靶机如果正在和别人通信，它发出的包被攻击机截获，但回包不经过攻击机，会导致连接频繁重置。看起来像是网络不稳定，而不是你控制了流量。

双向欺骗的意义在于，让靶机和网关两边的 ARP 缓存都指向攻击机。靶机发往网关的包给了攻击机，攻击机转发给网关；网关发往靶机的包也给了攻击机，攻击机再转发给靶机。这样一来，以太网层的数据包全部流经攻击机，所以你说“网络攻防演练里最常见的中间人劫持，十次有八次是 ARP 欺骗打底”，这话并不夸张。

双向欺骗命令都跑起来之后，可以先不急着抓包，在靶机上重新查看一下 ARP 缓存：

arp -a

如果看到网关 192.168.137.1 对应的 MAC 变成了攻击机 Kali 的 MAC（前面你在攻击机ip addr里看到的那个），说明欺骗已经生效。

4. 用 Wireshark 验证欺骗生效：三个可复现判据

4.1 判据一：攻击机网卡上持续出现 ARP 应答

第一个判据最直接。arpspoof 本质上是持续发送 ARP 应答包，所以在攻击机的网卡上抓包，应该能看到大量 ARP 数据包。用 tcpdump 快速验证一下：

sudo tcpdump -i eth0 -n arp -c 20

正常输出长这样：

08:12:33.123456 ARP, Request who-has 192.168.137.20 tell 192.168.137.1, length 28 08:12:33.126789 ARP, Reply 192.168.137.1 is-at 00:0c:29:aa:bb:cc, length 28 08:12:33.129123 ARP, Request who-has 192.168.137.1 tell 192.168.137.20, length 28 08:12:33.132456 ARP, Reply 192.168.137.20 is-at 00:0c:29:aa:bb:cc, length 28

注意看 Reply 包里的is-at地址，攻击机的 MAC 在同一时间出现在两个不同的 IP 条目下面。这就是 ARP 缓存污染的现场证据。用 Wireshark 看更直观，显示过滤器填：

arp.opcode == 2

可以看到攻击机的 MAC 地址频繁出现在源 MAC 字段中，并且目标地址始终是靶机或网关。正常情况下一个网段的 ARP 流量是非常稀疏的，只有新设备接入或者缓存过期时才有零星包。如果 Wireshark 里 ARP 包以每秒几个甚至几十个的频率刷屏，基本可以确认欺骗进程在正常工作。

4.2 判据二：靶机上网关的 MAC 被替换

第二个判据是从靶机的视角确认，这是实验报告里最有说服力的截图。

Windows 靶机上执行：

arp -a

对比实验前记录的基准值。实验前网关 192.168.137.1 的 MAC 是 VMware 虚拟网卡的地址（记作00:50:56:xx:xx:xx），实验开始后应该变成攻击机 Kali 的 MAC（记作00:0c:29:yy:yy:yy）。

输出对比大概是这个样子：

如果你靶机用的是 Linux，查看命令是：

ip neigh show 192.168.137.1

输出的lladdr字段应该同样变成攻击机的 MAC。Linux 下还可以用arp -n查看。

这里有个细节：靶机可能不会立即更新 ARP 缓存。因为 Windows 的 ARP 缓存有老化机制，通常几十秒到几分钟不等。如果 arpspoof 已经跑了一会儿，但arp -a看到的还是旧 MAC，可以先主动清掉缓存再观察：

arp -d 192.168.137.1

清掉之后，靶机要重新解析网关的 MAC，这时候 arpspoof 会在靶机发出 ARP 请求后立刻送上伪造应答，新缓存会直接写入攻击机的 MAC。

4.3 判据三：抓到一个穿越攻击机的明文 HTTP 请求

前两个判据只证明了 ARP 缓存被劫持，还没证明流量真的经过攻击机。第三个判据是完整实验链路的验证：在攻击机上抓到一条来自靶机的 HTTP 明文请求。

做法是在攻击机上启动 Wireshark，抓取 eth0 网卡流量，然后在靶机上用浏览器访问一个 HTTP 协议的测试页面，注意不要访问 HTTPS 站。例如浏览器访问http://example.com或实验网内搭的任意 HTTP 服务。

然后回到攻击机的 Wireshark，显示过滤器填：

http.request

如果实验链路是通的，会看到一条条 HTTP GET 请求，源 IP 是 192.168.137.20（靶机），目的 IP 是目标网站的服务器地址。这证明靶机发出的应用层请求确实经过攻击机网卡，中间人链路完全打通。

这一步要特别注意：HTTPS 流量是加密的，Wireshark 里只能看到 TLS 握手包，看不到明文 HTTP。如果你访问的是 HTTPS 网站，看不到 HTTP 明文属于正常现象，不代表实验失败。正确做法是访问明文 HTTP 站点，或者直接在实验网内起一个 HTTP 服务：

# 在任意一台和靶机同网段的机器上启动 HTTP 服务 python3 -m http.server 80

然后用靶机访问该机器的 IP，同样能抓到 GET 请求。

提示：验证完成后立即关闭 HTTP 抓包页面，不要在真实网络中模拟登录场景，ARP 欺骗实验只应该在隔离的虚拟环境里进行。

5. ARP 欺骗实验避坑指南：五个翻车现场与处置

5.1 桥接模式把整个宿舍网打挂了

这不是段子，是我见过的真实案例。现象是不管 arpspoof 怎么跑，实验报告里写的“清空 ARP 缓存后恢复正常”完全不灵，靶机恢复了，但实验室里其他几台电脑也开始间歇性断网。

原因是虚拟机网卡用了桥接模式，攻击机和宿主机处于同一个物理二层网络里。arpspoof 向网关和目标主机持续发送伪造 ARP 应答，这些包在物理局域网里广播，所有主机的 ARP 缓存都被污染了。

解决方式很直接：把网卡改成 NAT 模式，确保 ARP 包只存在于虚拟网段内。改完模式后，攻击机和靶机的 IP 可能要重新获取，因为 VMware 的 NAT 网段和桥接网段不一样。

5.2 网卡名写错，arpspoof 看着在跑其实没发包

现象是命令执行之后没有任何报错，终端一直停留在一个空行或有输出但靶机 ARP 表纹丝不动。

原因大概率是-i参数后面的接口名写错了。Kali 的网卡接口名在不同版本、不同硬件平台下可能是eth0、ens33、ens160、wlx...，如果你从网上随便抄了一段命令，接口名很可能对不上。

解决方式：先执行ip addr show，找到攻击 IP 对应的接口名，再原样填进-i参数。如果用的是 Wi-Fi 网卡做实验，还有可能触发网卡的 AP 隔离或者无线驱动层面的 ARP 过滤，效果不稳定，建议用有线虚拟网卡。

5.3 靶机 arp -a 一直看不到 MAC 变化

现象是 arpspoof 持续在跑，攻击机抓包也能看到自己发的 ARP 应答，但靶机上执行arp -a看到的网关 MAC 始终是原来的值。

原因有两类。第一类是靶机上装了 ARP 防护类安全软件，拦截了来自非网关 IP 的 ARP 应答。第二类是 Windows 对 ARP 缓存更新做了保护，如果网卡接收到的 ARP 应答里的发送方 MAC 和当前缓存不一致，会忽略掉或者在短时间内不更新。

解决方式：先确认是不是安全软件在拦，实验环境可以把安全软件临时退出，或者换一台干净的 Linux 虚拟机做靶机。如果是 Windows 自身的缓存保护，先执行arp -d 192.168.137.1清掉条目，然后立刻在靶机上持续 ping 网关制造 ARP 解析需求，再重复查看arp -a。ping 命令保持运行的同时观察，比单纯刷新要有效得多。

5.4 开了 IP 转发之后靶机还是上不了网

现象是 IP 转发已经确认开启，两条 arpspoof 命令都在跑，但靶机打开网页转圈、ping 外网不通。

我遇到过的原因有三个。第一个是两条命令里有一条约了，常见的是把靶机和网关 IP 写反了，导致两边都在冒充网关，中间的转发链路就断了。第二个是网关 IP 根本不是你写的 192.168.137.1，不同 VMware 版本 NAT 网关可能不一样，先回到宿主机确认再跑。第三个是攻击机上启用了反向路径过滤，也就是 rp_filter，内核会丢弃那些“按理说不应该从该接口进来”的包，即使开了 IP 转发也一样丢。

排查方式：

# 检查 rp_filter，输出 1 需要关掉 cat /proc/sys/net/ipv4/conf/all/rp_filter # 临时关闭 echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter

关闭 rp_filter 之后重新跑两条 arpspoof 命令，再在靶机上测试上网，这个坑就过去了。

5.5 实验结束忘了清理，靶机网络一直延迟抖动

现象是关闭了 arpspoof 之后靶机可以上网了，但延迟明显比实验前高，或者某些网页要刷新好几次才能打开。

原因很简单：arpspoof 被 Ctrl+C 结束之后，靶机的 ARP 缓存里网关 MAC 仍然是攻击机的地址，直到缓存老化前，靶机所有发往网关的包都会送到攻击机网卡上。攻击机已经不再转发这些包，只能丢包，所以网络表现为延迟抖动和部分请求失败。

解决方式：实验收尾时按顺序执行三条命令。先杀掉 arpspoof 进程，再关闭 IP 转发，最后清理靶机的 ARP 缓存。

# 攻击机上执行 sudo pkill arpspoof echo 0 > /proc/sys/net/ipv4/ip_forward # 靶机上执行，刷新所有 ARP 条目 arp -d *

做完这三步，再在靶机上 ping 网关，延迟应该恢复成实验前的 1 到 2 毫秒。

6. 从欺骗到防御：静态 ARP 绑定加一个网关 MAC 巡检脚本

做完攻击之后把防御手段补上，实验报告才算完整。这里给两个能实际落地在本机上的防护手段，不涉及路由器配置，适合在实验环境里验证。

6.1 静态 ARP 绑定：体验一次“骗不动”的网关

静态 ARP 绑定就是把网关的 IP 和 MAC 手工绑定到系统 ARP 缓存里，系统不再接受对这个条目的更新。

Windows 靶机上以管理员身份执行：

netsh interface ipv4 set neighbors 以太网 192.168.137.1 00-50-56-xx-xx-xx

把以太网换成你的实际网卡名称，MAC 换成实验前记录的网关真实 MAC。绑定后执行arp -a，类型会从“动态”变成“静态”。

Linux 靶机上执行：

sudo arp -s 192.168.137.1 00:50:56:xx:xx:xx

绑定完成后再跑 arpspoof，你会发现无论攻击机发多少伪造应答，靶机的arp -a都纹丝不动，网关 MAC 永远是真实值。这就是为什么很多内网安全基线里都要求对核心网关设备做静态 ARP 绑定——它不能防御所有攻击，但至少把最容易做的中间人劫持给堵住了。

6.2 10 行脚本盯住网关 MAC 变化

静态绑定适合单机验证，不适合批量维护。日常排在内网里，更实用的方式是写一个小脚本周期检查网关 MAC，变化了就告警。下面是我常用的版本：

#!/bin/bash # 网关 IP 与预期真实 MAC，按实际环境修改 GW_IP="192.168.137.1" GW_MAC="00:50:56:xx:xx:xx" while true; do NOW_MAC=$(ip neigh show $GW_IP | awk '{print $5}') if [ "$NOW_MAC" != "$GW_MAC" ]; then echo "[!] $(date '+%F %T') 网关 MAC 异常: $NOW_MAC" fi sleep 2 done

逻辑说明：ip neigh show $GW_IP输出网关当前的邻居表条目，awk '{print $5}'提取第五列的 MAC 地址。每两秒取一次值，和预期真实 MAC 做比对，不一致就打印带时间戳的告警。把sleep改成 1，响应会更快，但也会更频繁调用ip命令，2 秒是平衡值。

这个脚本只是读缓存里的条目，不会主动发 ARP 请求，所以能安静地观察变化。把它放在攻击机上配合实验复现很合适：跑起来之后启动 arpspoof，脚本立刻会刷出告警，实验结束后手动绑定静态 ARP 或等缓存到期，脚本又自动恢复安静。

做这个实验给我留下最深的一个习惯是：结束攻击之前先按 5.5 的顺序清理环境，确保靶机 ping 网关延迟恢复正常才算收工。一次实验翻车不算什么，搞乱环境还查不出原因才是浪费一晚上的真正原因。希望这份避坑思路能帮你在做实验三时少走几趟弯路。

本文还有配套的精品资源，点击获取