简介：网络剪刀手NetCut是一份围绕局域网设备连接控制与ARP协议原理的科普型资料，面向网络管理员、共享网络用户及网络安全初学者，用于了解如何识别同一局域网内的设备、临时限制终端联网，并认识相关操作的安全边界与合规要求。压缩包共2个文件，以1个txt文本说明和1个html网页介绍为主，整体约3KB，内容轻量，便于快速浏览与留存查阅，已有211人学习。资料从NetCut的工作机制切入，说明其通过伪造ARP响应重定向流量、实现瞬时断网与自动恢复，并梳理设备识别、连接断开、保护模式、网络诊断等功能，同时讨论带宽占用、公共Wi-Fi隐私、课堂秩序等应用场景及滥用风险。读者可据此建立对ARP协议和局域网管理工具的基本认知，理解网络干预的伦理与法律边界，适合作为入门科普和操作前的风险提示参考。

1. 局域网里网突然断了：先认清楚"网络剪刀手"在剪什么

前几年在一个封闭办公区做网络排查，行政反馈"整排工位半小时内轮流掉线，拔一下网线再插上就好，过一会又不行"。我上去先抓了五分钟包，屏幕上密密麻麻全是 ARP 应答，同一个 MAC 地址反复宣称自己是网关。问题不在宽带，也不在路由器，而是有人在同一个广播域里用类似网络剪刀手的工具，把别人的出口"剪"掉了。这类工具的原理并不玄学，本质就是伪造 ARP 应答，让目标主机把网关的 MAC 记成攻击机的 MAC，流量走到一半就断。这篇内容按攻防复现的路子写：先拆断网链路是怎么被切断的，再给能照着跑的隔离环境验证步骤，然后重点讲现场怎么判断、怎么取证、接入层怎么加固。新手能照着命令查，熟手能看到每一步背后的判断依据和边界。

2. 断网链路拆解：ARP 应答为什么能一击致命

2.1 从"网卡灯还亮着、页面就是转圈"说起

判断一次断网属于哪一层，我的习惯是先看现象组合。网卡灯亮、交换机口没 down、本机ping同网段的其他主机能通，但ping网关不通，浏览器转圈、DNS 解析超时、curl卡在连接建立阶段——这四个现象叠在一起，基本可以把问题锁在二层到三层的交界处，也就是 ARP 这一层。

原因在于以太网转发靠的是 MAC，不是 IP。主机要往外网发包，第一步是查自己的 ARP 缓存：网关 IP 对应哪个 MAC。缓存里有，就直接把帧的目的 MAC 填成网关 MAC 发出去；缓存里没有，就广播一个 ARP 请求问"谁是网关"，谁先应答就信谁。这里的关键在于 ARP 天生无状态、无认证：主机收到一个 ARP 应答，哪怕自己压根没发过对应的请求，多数实现也会直接更新缓存。这就是所有 ARP 类攻击的共同地基。

断网型的剪刀手利用的正是这一点。攻击机周期性向目标发送 ARP 应答，内容是"网关 IP 对应我这台机器的 MAC"。目标的缓存被改写后，所有出网流量都发到攻击机的网卡上。攻击机如果不做转发，流量到这里就断了——表现出来就是"网还在、就是上不去"。如果攻击机顺手开了转发，那就从断网升级成中间人，风险高一个量级。

2.2 攻击能成立的三个必要条件

我把这类攻击能不能成立拆成三个条件，判断现场时逐条对照，基本不会跑偏。

第一个条件是同广播域。攻击机和目标必须处在同一个二层网络里，中间不能隔三层设备。同一台接入交换机下的不同端口、同一个无线 SSID 下的不同客户端，都属于同一个广播域。跨网段、跨 VLAN 的场景，单纯的 ARP 伪造打不过去，得先有别的入口。

第二个条件是目标缓存可被覆盖。绝大多数操作系统对未经请求的 ARP 应答是接受的，差别只在更新策略：有的只更新已存在的表项，有的会新建表项。这个差别决定了攻击是"改一条已有记录"还是"塞一条新记录"，但对结果影响不大。

第三个条件是网络里没有 ARP 校验机制。接入交换机如果开了动态 ARP 检测（DAI），会拿 ARP 包里的源 IP 和 MAC 去比对 DHCP Snooping 绑定表，对不上就丢弃并记日志。没开这个，或者上联口没设成信任口，伪造包就能长驱直入。我在做加固评估时，这三条里只要有任意一条不成立，优先级的判断就完全不一样。

2.3 隔离实验环境里验证一次：把过程拆成可观测的步骤

要理解这套链路，光看原理不够，得在隔离环境里跑一遍，看清楚每一步的可观测点。我给自己的规矩是：只在完全隔离的虚拟网段里做，网卡指向虚拟网络，宿主机不接生产网。

环境准备很简单：两台虚拟机接同一个 host-only 网段，一台当靶机，一台当"攻击机"，网关地址用虚拟网段里的保留地址。先确认靶机能正常访问网关，再确认攻击机能ping通靶机。这三步没做扎实，后面所有现象都是假的。

验证脚本用 scapy 写，重点在参数含义，不在跑通：

# 仅在自有或已授权的隔离实验网中使用 # 目的：验证接入层 ARP 防护（DAI / 端口安全）是否真的生效 from scapy.all import ARP, Ether, sendp import time IFACE = "eth0" # 实验网卡，必须指向隔离网段，别指向物理网卡 GATEWAY = "192.168.56.1" # 实验网段的网关地址 TARGET = "192.168.56.101" # 实验靶机地址 FAKE_MAC = "02:00:00:00:00:01" # 本地管理位为 1 的测试 MAC，避免撞上真实设备 pkt = Ether(dst="ff:ff:ff:ff:ff:ff") / ARP( op=2, # 2 表示 ARP reply，主动宣告，不经过 request psrc=GATEWAY, # 冒充的源 IP：网关 hwsrc=FAKE_MAC, # 冒充的源 MAC：测试用假 MAC pdst=TARGET, # 只针对靶机，把影响面压到最小 hwdst="ff:ff:ff:ff:ff:ff" # 广播投递，绕过靶机已有的缓存项 ) end = time.time() + 20 # 持续时间，够看清交换机和靶机的反应即可 while time.time() < end: sendp(pkt, iface=IFACE, verbose=False) time.sleep(2) # 2 秒一次，维持缓存不老化

几个参数的取舍值得说清楚。op=2是主动应答，不是请求，这是整个验证的核心——不发请求直接塞应答，正好对应真实场景里的行为。hwdst用广播地址而不是靶机 MAC，是为了让包一定能被网卡收下，不依赖靶机已有的缓存表项。FAKE_MAC特意选了本地管理位为 1 的地址段，好处是万一实验网里混进了真实设备，也不会和厂商标识冲突。DURATION只给 20 秒，是因为验证目的只是看交换机日志和靶机 ARP 表的变化，不需要长时间挂着。

跑的同时在靶机上盯住这条命令：

# 每 12 秒采样一次网关的 ARP 记录，观察 MAC 是否发生变化 for i in $(seq 1 10); do date +%T; arp -n 192.168.56.1; sleep 12; done

防护生效时，这条记录全程不变，交换机的 DAI 日志里会出现源 IP/MAC 不匹配的丢弃记录。防护没生效时，采样结果里会看到网关 MAC 被换成了那个测试 MAC，同时靶机的ping开始大面积超时。两种结果对应两种完全不同的结论，这就是我说的"看清楚可观测点"。

2.4 从攻击视角反推：哪些环节留下了痕迹

理解完链路，反过来想：如果我是防守方，哪些环节必然留痕。我把可观测点列成四类。

一是靶机 ARP 缓存的异常变化。正常网络里，网关的 IP-MAC 映射可能几个月都不变一次；被改写时，往往在几十秒内反复抖动。二是交换机上的大量 ARP 应答。正常终端之间很少互发 ARP 应答，一个端口在短时间内刷出成百上千个 ARP reply，是很强的信号。三是 MAC 地址冲突告警。有些交换机会检测同一 MAC 出现在多个端口，或者同一 IP 对应多个 MAC。四是终端侧的网络质量指标。断网型攻击下，TCP 三次握手会反复重传，DNS 查询超时的比例会突然拉高，这些在终端的连接统计里都能看出来。

这四类痕迹里，第一类和第二类最好抓，也最不容易误判。第三类依赖设备能力，老交换机可能没有。第四类适合做辅助证据，单独拿出来说服力不够。我在实际排查里，一般先用前两类定位，再用第四类做交叉验证。

3. 现场排查：三条命令锁定"是不是被人剪了线"

3.1 先分层：物理、IP、DNS 各查一遍

遇到"上不了网"的报障，我不会一上来就怀疑攻击。先按层排除：看网卡状态和速率协商，ethtool eth0确认链路是 1000M 全双工而不是莫名其妙掉到 10M 半双工；看 IP 配置，ip addr确认地址、掩码、网关都在；再看路由，ip route确认默认路由指向网关而不是被人改过。这三步五分钟内能做完，能挡掉大量低级故障。

接着做分层连通性测试。ping同网段另一台主机，通不通；ping网关，通不通；ping一个公网 IP 地址（不带域名），通不通；nslookup一个域名，解析得出来吗。我习惯把这四个结果按顺序记下来，哪一步断掉，指向的原因就很清楚了。同网段通、网关不通，指向二层 ARP；网关通、公网 IP 不通，指向网关侧或上层；公网 IP 通、域名解析失败，指向 DNS。

这里有个容易被忽略的细节：ARP 缓存被污染时，ping网关的表现往往不是立刻全丢，而是"前几个包通、后面全超时"或者"通一个丢三个"。因为缓存里可能还残存着正确的表项，或者攻击包的发送间隔刚好卡在缓存老化附近。看到这种不稳定的丢包模式，我会立刻往 ARP 方向想。

3.2 ARP 表比对：网关的 MAC 是不是换人了

定位到二层之后，第一步动作是比对网关的 MAC。这里必须有一个基准值——要么是你在故障前记下的，要么是去网关设备上直接查到的。没有基准值，看到一个 MAC 地址也无从判断对错，这是很多人排查卡住的地方。

查本机缓存用arp -n或ip neigh show。关键是看那条网关记录的状态字段和 MAC 值。状态是REACHABLE说明最近确认过，STALE说明可能老化，FAILED说明解析失败。如果同一个网关 IP 在几分钟内对应过两个不同的 MAC，基本可以判定缓存被人改写过。

# 连续采样网关记录，输出时间戳和当前 MAC，便于事后对时间线 for i in $(seq 1 20); do printf '%s ' "$(date +%T)" ip neigh show 192.168.56.1 sleep 10 done

这个采样脚本的价值在于"连续"两个字。单次看一条记录，只能看到结果；连续采样，能看到变化过程。我在一次现场里就是靠这个抓到了 MAC 在 30 秒内来回切换三次的规律，进而算出攻击包的发送间隔，反过来验证了判断。

交换机侧也可以查。接入交换机一般有 MAC 地址表，show mac address-table一类的命令能看到某个 MAC 挂在哪个端口。如果网关 MAC 出现在一个明显不该出现的用户端口上，那就是很直接的证据。这个操作需要设备权限，现场不一定有，但值得提前和网络管理员对齐。

3.3 抓包看特征：谁在频繁发 ARP 应答

有镜像口的情况下，抓包是最直接的证据来源。没有镜像口，也可以在怀疑被攻击的主机上直接抓，因为攻击包是发给它的，本机网卡一定能收到。

# 只抓 ARP 应答方向，带链路层信息，限 200 个包避免刷屏 tcpdump -i eth0 -n -e 'arp and arp[6:2] = 2' -c 200

过滤表达式里的arp[6:2] = 2是取 ARP 头的操作码字段，值为 2 表示应答。加上-e是为了打印源和目的 MAC，这一步很关键——只看 IP 看不出问题，看清"谁在宣称自己是网关"才是关键。正常的 ARP 应答，源 MAC 就是网关设备的 MAC；伪造的应答，源 MAC 会是一个陌生的地址。

抓到包之后看三个特征。第一个是发送源 MAC 是否等于网关真实 MAC。第二个是发送频率，正常终端的 ARP 应答是事件驱动的，一天也没几个；伪造行为往往是秒级的周期性发送。第三个是应答里的源 IP 和源 MAC 的对应关系，是不是和已知的绑定表一致。

还有一个更省事的办法是长期开着 ARP 监控。Linux 上有 arpwatch 一类的工具，检测到 IP-MAC 映射变化会记录并告警，日志里带着时间戳和两个 MAC 值。这类工具不需要人盯着，适合放在关键网段长期跑。我在几个长期维护的办公网里都部署了，价值不在于抓现行，而在于出事时能翻出"第一次异常发生在几点几分"，这个时间点对定位是哪台机器出问题极其有用。

3.4 把证据固定成一条时间线

抓到异常之后，我一般会花十分钟把证据整理成一条时间线：几点几分第一次出现异常 ARP、持续多久、涉及哪些 IP 和 MAC、同期终端侧的丢包和重传情况。这条时间线的用处有两个：一是给非技术人员解释时能说清楚，二是和自己的判断互相印证。

整理的时候注意区分"现象"和"推断"。ARP 缓存的 MAC 发生了变化，这是现象；有人用网络剪刀手一类的工具在做 ARP 伪造，这是推断。推断要有依据，比如发送频率、广播域范围、是否伴随流量中断，这些都能支撑结论。混着写，事后复盘时自己都分不清哪些是事实。

4. 防御加固：从接入交换机到终端的三层拦法

4.1 接入层：把伪造包挡在端口上

接入层是最有效的拦截点，因为攻击包必须从某个物理端口或无线 AP 进来。这里有三项配置值得优先做。

第一项是 DHCP Snooping。它建立起一张"IP-MAC-端口-VLAN"的绑定表，记录哪个 IP 是从哪个端口通过 DHCP 拿到的。这张表本身不拦包，但它是后面 DAI 的基础。上联口要设成信任口，用户口设成非信任口，否则合法 DHCP 应答也会被丢。

第二项是动态 ARP 检测（DAI）。它拿每个 ARP 包的源 IP 和源 MAC 去比对绑定表，不匹配就丢弃并记日志。开了这个之后，上面那种伪造应答在交换机入口就被拦掉了，靶机的缓存根本不会被改写。需要注意的是，静态配置 IP 的终端不在绑定表里，要么给它们建静态绑定，要么单独放行，不然会误伤。

第三项是端口安全。限制每个接入端口允许学习的 MAC 数量，比如一个工位口只允许一个 MAC，超了就告警或者直接 err-disable。这一项对付"一台机器接多个 MAC 到处扫"的场景特别有效。

! 通用接入交换机配置示意（命令名以实际设备为准） dhcp-snooping enable arp-inspection enable interface uplink-0/1 dhcp-snooping trust arp-inspection trust ! 上联口必须信任，否则网关的 ARP 也会被丢 interface user-0/10 port-security enable port-security max-mac 1 ! 工位口通常只接一台终端 arp-inspection untrust ! 用户口默认不信任

这三项配置的落地顺序有讲究：先开 DHCP Snooping 观察一段时间，确认绑定表覆盖了绝大多数终端，再开 DAI。反过来先开 DAI，绑定表是空的，会把所有人的 ARP 都当异常丢掉，整个网段直接瘫痪。这是我见过的最典型的翻车方式之一。

4.2 终端侧：静态绑定和加密通道

接入层配置不一定能立刻推动，终端侧的自救手段就更实用。

最直接的是静态 ARP 绑定。把网关的 IP-MAC 映射写成永久表项，系统就不会再接受针对这条记录的更新。Windows 上用netsh interface ipv4 add neighbors一类的命令，Linux 上用ip neigh add ... nud permanent，macOS 上用arp -s。写死之后，伪造的应答改不动这条记录，断网攻击对你的效果会大幅下降。代价是网关换设备或换 MAC 的时候要手动改，所以适合网关稳定的场景，不适合经常做设备替换的环境。

第二是开防火墙的出站规则。部分终端安全产品会做 ARP 欺骗检测，发现有异常应答就告警。这类功能的效果参差不齐，别指望它兜底，但作为早期预警还是有用的。

第三是加密通道。断网型攻击只是让你上不去网，中间人型攻击才会读你的内容。所有关键业务走 HTTPS、SSH 这类加密通道，能把中间人带来的信息泄露风险压到很低。这一点我在给非技术同事做培训时反复强调，因为它的成本最低、收益最稳。

4.3 无线场景：同一 SSID 下的二层仍然是通的

无线环境容易被误判。很多人觉得连了 Wi-Fi、加了密码，同一网络里的人就互相隔离了。实际情况是，WPA2/WPA3 加密的是空口这一段链路，同一个 SSID 下的客户端之间，二层依然是互通的，ARP 伪造照样能做。真正起作用的是 AP 上的客户端隔离功能（也叫 AP isolation、client isolation），开了之后客户端之间的二层流量直接被 AP 拦掉。

所以无线侧的加固顺序应该是：先确认 AP 开了客户端隔离，再考虑接入认证的强度。前者直接解决同网段互攻的问题，后者解决的是"谁能连进来"的问题，两个维度不能互相替代。我在评审无线方案时，会把"客户端隔离是否开启"作为第一个问题问，因为这一项的投入产出比最高。

4.4 一份可以照着排优先级的加固清单

加固项很多，落地时得排优先级。我一般按"覆盖面 × 实施成本 × 误伤风险"三个维度来排，下面这张表是我实际用过的排序：

排序逻辑很简单：先做覆盖所有人、成本低、风险可控的项，再做覆盖面小但价值高的项。P0 里的两项如果只能做一件，我选无线客户端隔离，因为无线环境的人员流动最大、最难靠物理管控。

5. 复现与排查中的五个坑：现象、原因和补救

5.1 实验网一开，整层楼跟着掉线

现象：在工位上做验证，脚本刚跑起来，周围同事陆续报障，说自己上不了网。

原因：虚拟机的网卡桥接到了物理网卡，虚拟网段和办公网混在同一个广播域里。脚本里那个"冒充网关"的应答，实际上也发到了真实网络里，把同事的 ARP 缓存一起改了。

解决：做这类验证，网卡必须指向 host-only 或内部网络，绝不桥接物理网卡。跑之前用ip addr和ip route确认本机所在网段，确认网关地址不是生产网关。我现在养成一个习惯：脚本第一行先打印IFACE对应的网段，和自己预期的对不上就直接退出，不给"手滑"留机会。

5.2 靶机 ARP 表改了，但网还是通的

现象：采样显示网关 MAC 已经被替换成测试 MAC，但靶机ping外网依然正常，看起来攻击没生效。

原因：攻击机和靶机之间还有其他路径，或者靶机的缓存里同时存在多条记录，系统按最长前缀或最新表项选了一条正确的。也可能是验证脚本只发了应答但没持续，缓存很快被正常的免费 ARP 覆盖回去了。

解决：先确认广播域里是否只有这两台机器，把其他虚拟网卡、虚拟网桥全部断开。再把发送间隔缩短到缓存老化时间的一半以内，保证覆盖是持续的。最后在靶机上连续采样而不是单次查看，确认 MAC 变化是稳定持续的，而不是闪了一下就恢复。

5.3 抓包抓不到任何异常 ARP

现象：明明终端在上不了网，tcpdump抓了半天，一个可疑的 ARP 应答都没有。

原因：抓包位置不对。交换机不会把别人的单播流量泛洪到你的端口，如果攻击包是单播发给受害者的，你在第三台机器上根本看不到。另一种情况是攻击用了其他手段，比如伪造 DHCP 或者直接发 ICMP 重定向，压根不走 ARP。

解决：把抓包点挪到受害主机本机上，或者申请一个镜像口。同时把过滤条件放宽，先看全部 ARP，再看 ICMP，最后看 DHCP，一层层排除。别一上来就用窄过滤条件，容易把真正的线索过滤掉。这个坑我踩过一次，白白多查了两个小时。

5.4 静态绑定做完，照样掉网

现象：网关的 IP-MAC 已经写成永久表项，理论上不会被改写，但终端依然周期性断网。

原因：静态绑定只保护了"网关"这一条记录。如果攻击方伪造的是同网段其他关键设备（比如 DNS 服务器、内网应用服务器）的 ARP，或者伪造的是受害者自己的 IP 造成地址冲突，静态绑定挡不住。还有一种可能是攻击方走的是 DHCP 伪造，直接给你发一个错误的网关地址。

解决：静态绑定要覆盖所有关键基础设施，不只是网关。同时检查本机的 IP 配置是不是 DHCP 获取的，如果是，确认 DHCP 应答来源是否可信。排查时把"哪一条 ARP 记录在变"列全，不要只盯网关一条。

5.5 用了监控工具，告警一堆但全是误报

现象：部署 ARP 监控之后，每天几十条告警，看下来全是正常的设备更换和虚拟化迁移，真正的问题被淹没。

原因：监控工具的判定逻辑是"IP-MAC 映射变化就告警"，但虚拟化环境、双网卡绑定、负载均衡设备天然就会让映射频繁变化。没有做白名单，误报率必然高。

解决：先跑一周的观察模式，把所有正常的映射变化整理成白名单，再开告警。白名单要按"设备 + 端口"的粒度做，不能只按 MAC 做，否则设备换端口又会误报。另外把告警分级：同一条记录在 60 秒内变化超过三次才算高危，一天变化一次的直接降级成日志。这套规则调完之后，误报能压到很低，告警才有参考价值。

6. 把结论落成一张自查表：下次断网先看这五行

真到了现场，脑子里装的原理再多，也不如一张能照着填的表。我在几次排查之后固定下来一套流程，每次遇到"局域网内集体或轮流断网"，按这五行往下走，绝大多数情况十五分钟内能定性。

这张表里第 2 行最容易被跳过，也最不该跳过。单次看 ARP 表只能看到一个快照，看不出"变化"这件事；而 ARP 伪造的全部特征，恰恰藏在变化里。我现在到任何一台机器上排查，第一件事都是跑一段连续采样，把输出存成文件，后面所有判断都基于这份采样，而不是基于某一次arp -a的输出。

还有一个细节值得单独说：验证防护是否真的生效，不要靠"感觉网变稳了"。正确做法是在隔离环境里把第 2 章那段脚本再跑一遍，看交换机的丢弃计数有没有涨、靶机的 ARP 表有没有变。防护配置写完不做验证，等于没配——我曾经因为上联口忘了设信任，导致整栋楼的 ARP 都被 DAI 丢掉，事后复盘才发现配置项只写了一半。从那以后，我每次改完接入层防护，都强制走一遍"改配置 → 隔离环境验证 → 观察日志 → 再上生产"这四步，一步都不省。

这份资源的价值不在于"点一下就能断谁的网"，而在于它把 ARP 欺骗这条链路做成了可以随手复现的东西。拿它当验证环境，去测自己的接入交换机到底有没有拦住伪造应答，比看十篇文档都管用。希望帮到你。

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