简介西南科技大学网络攻防与对抗课程实验三的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 广播可见范围出网能力实验风险桥接模式物理局域网内所有主机正常高可能污染真实网络NAT 模式仅当前虚拟子网内的虚拟机正常经虚拟网关转发低隔离性好仅主机模式仅同虚拟子网内虚拟机无外网极低但很多实验场景不适用桥接模式下虚拟机的网卡直接接在物理交换机的广播域里攻击机发送的伪造 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 地址子网掩码网关虚拟网关VMware NAT 服务192.168.137.1255.255.255.0无攻击机Kali Linux192.168.137.10255.255.255.0192.168.137.1靶机Windows 10192.168.137.20255.255.255.0192.168.137.1靶机建议把静态 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 一下靶机和网关。顺便确认靶机能解析网关的 MACarp -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.confecho 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 21 sudo arpspoof -i eth0 -t 192.168.137.1 192.168.137.20 /tmp/spoof_gw.log 21 后台运行的日志文件里会记录每条 ARP 应答的发送信息排错时很有用。查看方式tail -f /tmp/spoof_target.log3.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。输出对比大概是这个样子条目实验前欺骗生效后192.168.137.100:50:56:xx:xx:xx00: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 被 CtrlC 结束之后靶机的 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_IP192.168.137.1 GW_MAC00: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 网关延迟恢复正常才算收工。一次实验翻车不算什么搞乱环境还查不出原因才是浪费一晚上的真正原因。希望这份避坑思路能帮你在做实验三时少走几趟弯路。本文还有配套的精品资源点击获取