做接入网维护的人大概都碰过这种场面某一层楼好几个用户同时反映网一会儿通一会儿断登到H3C接入交换机上看CPU不高、端口没告警、链路也没闪断但打一条display arp会发现某个IP对应的MAC地址每隔十几秒就跳一次严重的还会看到网关IP 的MAC被改成了某台终端的MAC。这就是ARP欺骗最典型的表现也是今天要聊的H3C ARP防护典型配置要解决的场景。这篇文章不打算把ARP协议从头讲一遍然后贴几行命令收尾。我更想按实际部署的顺序来讲先想清楚ARP这种协议天生缺哪根弦再对应到H3C设备上的三类防护手段——静态绑定、ARP Detection、报文合法性检查与限速每一类都说清楚它拦的是什么、配置落在哪一层、开下去会带来什么副作用最后把我自己在现网和模拟器上踩过的几个坑完整复盘一遍。不管你是刚接手接入层的新手还是准备给一个园区网做整体的ARP防护加固都能直接拿走配置和排查思路。1. ARP防护到底在防什么把信任模型说清楚1.1 ARP协议没有身份校验这是所有攻击的起点ARP的工作方式可以用一句话概括我问谁是10.0.0.1谁答应我就信谁。主机要发数据给同一网段的另一台机器先在ARP缓存里查有没有对应的MAC没有就广播一个ARP请求谁手里有这个IP谁就单播回一个ARP应答。问题在于收到响应的一方根本不去验证这个应答是不是真的来自那台设备也不会验证对应关系是否和之前学到的一致——只要收到就覆盖缓存里的旧表项。这种无条件信任的设计在当年是很合理的因为ARP诞生的年代同一根同轴电缆上的机器彼此都认识。但放到今天任何一个接入端口后面的终端都可以伪造源IP、源MAC甚至是网关的IP向全网广播ARP应答。交换机作为二层设备默认只做转发和学习MAC不会去看ARP报文里的内容是否自洽这就是所有ARP类攻击的土壤。理解了这一点防护思路就清楚了既然协议自己不校验那就必须由网络设备来替它校验。校验的依据有两个来源——人工配置的绑定关系和DHCP分配的合法关系后面讲的静态绑定和ARP Detection本质上就是这两种依据的落地方式。1.2 现网里最常见的四类ARP异常及其表征不是所有网卡都叫ARP攻击。搞清楚现象对应的具体类型才能选对防护手段。下面这张表是我按实际处理过的故障整理的现象列的描述你可以直接拿去对号入座。异常类型典型现象对业务的直接影响网关仿冒用户看到网关IP的MAC变了或全楼同时断网大范围断网所有出网流量被劫持中间人仿冒两台主机互相以为对方是自己同网段内被窃听、被篡改用户无感知ARP泛洪交换机CPU升高终端频繁刷新ARP表交换机转发性能下降接入侧丢包地址冲突型两台机器抢同一个IP互相顶掉表项单点终端反复掉线表现为闪断网关仿冒的杀伤力最大因为它一次性把整个VLAN的出网流量都收走了很多整层断网的报障最后查下来都是这个。ARP泛洪则容易被误判成交换机性能不行其实是被某个中毒终端或扫描工具打满了。地址冲突型最容易被当成电脑问题甩锅实际上是有人手工配了静态IP去抢DHCP地址池里的地址。注意这四类的处置手段并不通用。静态绑定对网关仿冒有效但对泛洪无效而限速能压住泛洪却管不了伪造源MAC。开工前先确认是哪一类。1.3 H3C设备上可用的三类防护手段与选型判断H3C在Comware平台上提供的ARP防护能力大致可以归成三档从管得最死但最麻烦到管得最松但最省事静态绑定类arp static、端口级user-bind把IP和MAC钉死。最硬但终端一换网卡就要改配置。动态检测类基于DHCP Snooping的ARP Detection让交换机拿DHCP分配记录当合法名单逐个比对配合arp detection validate做报文合法性检查。适合终端多、变动频繁的办公网。减害类ARP源抑制、接口ARP限速。不解决谁在骗谁只解决别把交换机打瘫。选型上我的判断标准很朴素终端IP是静态分配还是DHCP分配。静态IP为主的环境比如生产网、监控网直接上静态绑定简单可靠DHCP为主的环境办公网、宿舍网、无线一定要上ARP Detection否则维护成本会把人力吃光。两者混用的环境就得让静态绑定表也能参与ARP Detection的比对这一点后面第3章会具体讲。2. 静态绑定方案最笨但最硬的防线2.1 arp static 命令的写法与表项优先级静态ARP表项的配置在系统视图下完成命令格式是# 系统视图 [H3C] arp static 10.10.20.1 0000-5e00-0101 20 GigabitEthernet1/0/1这条命令把10.10.20.1永久绑定到0000-5e00-0101并指定它从VLAN 20 的GigabitEthernet1/0/1口进来。参数里vlan-id和接口这两项很多人在配的时候会省略觉得反正IP和MAC对上了就行。我建议不要省原因有两个一是完整的表项能让你事后一眼看出这台设备物理上挂在哪里排查时省事二是某些版本里省略接口会导致表项在接口震荡时不参与相关联动。静态表项的优先级高于动态学习这点很关键。也就是说一旦10.10.20.1有了静态表项不管攻击者怎么广播ARP应答交换机都不会用动态学到的内容覆盖它。这是静态绑定最核心的价值。日常查看和维护[H3C] display arp static [H3C] display arp all [H3C] reset arp dynamicreset arp dynamic只清动态表项静态的不会动这个在排查表项被污染的时候很有用——先清一遍动态表项看几秒后正确的MAC能不能回填就能判断攻击是否还在持续。2.2 端口级IPMAC绑定 user-bind 的实测效果arp static是全局表项粒度是IP。如果你想让策略跟着物理端口走H3C提供的另一个命令是user-bind配在接口视图下[H3C] interface GigabitEthernet1/0/5 [H3C-GigabitEthernet1/0/5] user-bind ip-address 10.10.20.5 mac-address 0000-0000-0105 [H3C-GigabitEthernet1/0/5] quit这条绑定的含义是这个口只允许这组IP和MAC的组合通信其他组合的报文会被丢弃。它在思路上和端口安全接近但粒度是IPMAC而不是纯MAC。特别注意它加上vlan参数的形式[H3C-GigabitEthernet1/0/5] user-bind ip-address 10.10.20.5 mac-address 0000-0000-0105 vlan 20我个人更推荐带上VLAN。原因很实际如果是多VLAN混插的端口比如接小交换机不指定VLAN的话终端把IP配到别的VLAN里也能通等于留了个后门。实际部署时这两种静态手段经常是搭配用的网关和关键服务器用arp static锁死普通终端用user-bind按端口锁。全量用user-bind的代价是端口迁移不方便——用户换个工位就得改配置所以我在宿舍网、政务网这类人机固定的环境里才推荐全量上。2.3 静态方案什么时候不该用说实话静态绑定被滥用的场景比被漏用的场景多得多。下面这三种情况我建议别硬上静态终端流动性高的场景会议室、访客区、开放办公位人一换电脑你的配置就全废。无线场景无线终端在AP之间漫游MAC不变但接入端口一直在变user-bind绑端口毫无意义。终端数量超过几百台且没有自动化工具靠手工敲user-bind改一次配置就是一场灾难而且极易敲错。还有一种情况容易被忽略虚拟化环境。服务器上跑虚拟机虚拟机的MAC可能由平台动态生成重启后会变。这种情况下静态绑定要把虚拟机的MAC生成策略一起考虑进去否则每次迁移都要跟着改交换机配置。3. ARP Detection让交换机拿DHCP Snooping表当花名册3.1 为什么必须先有DHCP SnoopingARP Detection有些资料按思科的叫法写成DAIDynamic ARP Inspection原理一致的核心逻辑是交换机不指望自己去判断谁真谁假而是从DHCP Snooping绑定表里读一份IP—MAC—VLAN—端口的合法清单收到ARP报文就拿去比对对不上就丢。那为什么DHCP Snooping是前提因为这份清单只有一个权威来源——DHCP服务器分配地址时产生的租约记录。DHCP Snooping的作用是在交换机上截听DHCP交互过程把分配结果记成表项。没有它交换机手里就是空的ARP Detection自然无从比对。配置顺序上一定是先DHCP Snooping、后ARP Detection。反过来的话ARP Detection会因为拿不到表项而把所有报文都判为非法直接造成大范围断网。[H3C] dhcp snooping enable [H3C] vlan 20 [H3C-vlan20] dhcp snooping enable [H3C-vlan20] quit [H3C] interface GigabitEthernet1/0/24 [H3C-GigabitEthernet1/0/24] dhcp snooping trust [H3C-GigabitEthernet1/0/24] quit这里的dhcp snooping trust配在连接DHCP服务器的上行口上。它的含义是这个方向来的DHCP报文是可信的不用检查。如果实际环境中DHCP服务器在核心交换机上、经由上行链路到达接入交换机那上行口就是这个位置。3.2 三个校验开关分别拦什么arp detection validate后面可以跟三个参数它们检查的维度完全不同很多人以为开了就是全开其实是按需勾选参数检查内容拦住的攻击类型src-mac以太网帧源MAC是否等于ARP报文里的发送端MAC伪造源MAC的ARP应答dst-mac以太网帧目的MAC是否等于ARP报文里的目标MAC伪造目的地址的定向欺骗ipARP报文里的源/目标IP是否为非法地址0.0.0.0、组播地址等畸形报文配置形式是[H3C] arp detection validate src-mac ipip和src-mac这两项我基本是默认必开的。它们拦的都是报文本身就自相矛盾的情况不会误伤正常终端风险极低。dst-mac稍微特殊一点ARP请求报文里的目标MAC本来就是全0所以这一项对请求报文不生效主要作用于应答报文。在终端类型混杂、有老设备的环境里我见过开dst-mac之后个别设备不通的案例所以一般是先在部分楼层试点稳了再推全量。3.3 信任端口怎么划一个最容易划错的地方ARP Detection生效后交换机上所有端口默认都是非信任端口进来的ARP报文要接受比对。而arp detection trust配在哪些口上直接决定防护效果和业务连续性。需要配成信任的口有三类上行口接核心/汇聚的口从核心过来的ARP报文如果被比对很可能因为接入交换机没有对应表项而被丢掉。连接网关的口网关设备通常不参与DHCP Snooping它自己的ARP报文不在绑定表里。连接其他交换机、服务器区聚合的口这些位置的设备通常是静态IP同样不在绑定表里。[H3C] interface GigabitEthernet1/0/24 [H3C-GigabitEthernet1/0/24] arp detection trust [H3C-GigabitEthernet1/0/24] quit注意信任端口配错是ARP Detection故障的头号原因。表现是上行方向一切正常但跨交换机通信异常或者能ping通网关但访问不了其他网段。上线前一定把拓扑画出来逐个端口确认别凭印象配。3.4 一套可以直接照抄的接入层配置把上面几段拼起来一个典型的办公网接入交换机配置长这样假设业务VLAN 20上行口为 GigabitEthernet1/0/24终端接1到20口# 全局开启 [H3C] dhcp snooping enable [H3C] arp detection enable [H3C] arp detection validate src-mac ip # 业务VLAN [H3C] vlan 20 [H3C-vlan20] dhcp snooping enable [H3C-vlan20] quit # 上行口双重信任 [H3C] interface GigabitEthernet1/0/24 [H3C-GigabitEthernet1/0/24] dhcp snooping trust [H3C-GigabitEthernet1/0/24] arp detection trust [H3C-GigabitEthernet1/0/24] quit终端口不需要额外配置默认就是非信任状态会自动参与比对。如果这个楼道里有一台老式打印机用的静态IP不在DHCP绑定表里那有两种处理方式一是把那个口单独配成arp detection trust二是用user-bind把它的IPMAC补进绑定关系里。我倾向后者因为前者等于在那个口上把防护关了。另外提醒一句user-bind这样的静态绑定表项同样能被ARP Detection引用这也是为什么我说静态和动态两套方案不是对立的而是可以叠加的。4. 报文合法性检查、源抑制与限速三种减害手段4.1 arp detection validate 与 arp check 的区别这两个命令名字很像作用完全不同我在现场见过有人把arp check enable当成ARP Detection的开关来配结果防护一点没生效。arp check enable管的是ARP表项学习这一个动作开启后设备在学到ARP表项时会检查报文的合法性避免把明显异常的条目写进ARP缓存。它配在接口视图下[H3C] interface GigabitEthernet1/0/20 [H3C-GigabitEthernet1/0/20] arp check enable而arp detection validate是在报文转发路径上做校验不合法直接丢包比不学习表项要强硬得多。两者的关系可以这么理解arp check是我不记这个账arp detection validate是这张假钞我直接没收。实际部署里我一般两个都开但优先级上先把ARP Detection配好arp check作为补充。光靠arp check挡不住攻击因为攻击者伪造的报文可能完全合法、只是内容不真实——这种情况下只能靠绑定表来判。4.2 ARP源抑制解决的是ARP泛洪打到CPU前面说过ARP类攻击里有一种纯粹是量的问题某个终端或者扫描工具疯狂发ARP请求目标IP范围很广交换机的CPU被ARP处理占满正常转发受到影响。这类攻击用绑定关系是拦不住的因为每个报文看起来都合法只是不该有这么多。H3C的ARP源抑制ARP source suppression就是对付这个的。原理是设备统计同一源IP向同一目的IP发起的ARP请求次数如果短时间内超过阈值就认为这个源在发起攻击在一段时间内不再向该目的IP发送它的ARP请求。[H3C] arp source-suppression enable [H3C] arp source-suppression limit 20limit的取值需要根据环境调。默认值比较保守在小规模网络里够用如果是终端密集的宿舍楼正常终端本身也会产生一定量的ARP请求阈值设太小会把正常请求也压掉表现为偶尔第一次访问要慢一拍。我一般从默认值起步上线后观察一段时间CPU和用户反馈再调。提示源抑制是丢请求而不是回响应所以它对用户的影响是首次访问延迟而不是完全不通。如果用户反映打开网页要等几秒才出内容又找不出别的原因可以去查一下这个阈值是不是设得太严。4.3 接口ARP限速的阈值怎么定比源抑制更粗粒度的一层是接口级ARP限速。它不区分源和目的只统计这个口上收到的ARP报文速率超了就丢。[H3C] arp rate-limit enable [H3C] interface GigabitEthernet1/0/10 [H3C-GigabitEthernet1/0/10] arp rate-limit 30 [H3C-GigabitEthernet1/0/10] arp rate-limit log enable [H3C-GigabitEthernet1/0/10] quit阈值怎么定我的做法是按端口下挂的终端数量估算而不是拍脑袋。一台正常终端在稳定状态下ARP活动主要是缓冲老化后的重新解析量级很低出现异常时中毒、扫描、IP冲突会瞬间拉高几个数量级。所以阈值只要卡在正常水平之上、异常水平之下就能起作用。端口下挂终端数建议阈值量级说明1台接入单个用户较低正常几乎不产生突发10到20台接小交换机中等需要留出地址老化的峰值余量一台AP或者一组服务器较高或关闭限速终端多且行为不规律容易误伤arp rate-limit log enable一定要开否则限速生效了没人知道。日志里会记录是哪个口触发了限速这个信息在定位到底是谁在发包的时候非常关键。不同Comware版本里这个值的默认和取值范围有差异敲之前用?确认一下别照着旧文档硬抄。5. 上线后的翻车现场ARP防护引发的典型故障排查链路防护配完不是结束而是麻烦的开始。下面这三个现象是我这些年遇到频率最高的我把排查过程完整写出来你可以照着这个顺序走。5.1 现象一地址能拿到网关ping不通这是最经典的一种。用户反映网络图标是正常的IP地址看着也拿到了但就是上不了网。这种描述听起来像路由问题但如果你刚配过ARP Detection八成是它。排查顺序是这样的先在接入交换机上display arp看网关有没有学到如果网关的ARP表项是空的或者MAC不对问题就在二层。然后display ip source binding看绑定表里有没有这台终端如果没有说明它的ARP报文被当成非法丢弃了。再往下的判断是这台终端的IP是怎么来的如果是手工配的静态IP那它本来就不在DHCP绑定表里被丢掉是正常的——这就是静态IP终端上不了网的根因。处理方式是给它配上user-bind或者把那个接入口临时设为arp detection trust验证一下。如果终端是DHCP获取的绑定表里却没有那要看display dhcp snooping interface确认上行口的信任配置是否正确。上行口没配信任DHCP应答就被丢弃交换机自然也记不下绑定表项——现象就是DHCP请求发出去了但一直拿不到地址或者拿到的地址没有表项。5.2 现象二个别终端每隔几分钟掉一次线这种闪断最难查因为故障窗口短等你登上设备它已经恢复了。我的经验是先区分是链路层抖动还是ARP表项被顶掉。判断方法很直接在故障终端上持续观察ARP表如果看到它的网关MAC周期性变化那就是ARP表项被顶掉。这时候要在接入交换机上查是谁在发这个IP的ARP应答[H3C] reset arp dynamic [H3C] display arp | include 10.10.20清一遍动态表再立刻看出现两次相同IP不同MAC的就是冲突双方。如果这两个MAC都接在你的设备上那基本可以断定是有人在手工配IP抢地址。还有一种情况是VRRP或者网关组切换导致的这种不是攻击是正常的协议行为但现象很像。区分方法是看MAC是不是虚拟网关的MAC以及是否和主备切换日志时间对上。这个坑我在双网关组网的环境里踩过一开始以为是ARP攻击查了半小时才发现是主备在来回切。5.3 现象三IRF/堆叠下部分端口防护失效堆叠IRF环境下有个很隐蔽的问题信任端口只在主设备上配了从设备上没配。因为IRF对外是一台逻辑设备配置看起来是全局的但涉及物理端口的策略必须逐成员设备确认。表现是挂在成员设备2上的终端ARP防护时好时坏或者干脆不生效。排查的关键动作是[H3C] display arp detection [H3C] display arp detection statistics interface GigabitEthernet2/0/1第二条命令里的槽位号是成员设备编号这一条能直接告诉你某个物理口上到底拦了多少报文。如果某个成员设备的所有端口计数都是0那要么是没流量要么是策略没下发到那台成员。同样的坑在链路聚合上也存在。聚合口的成员口如果被当成普通接入口处理信任配置只配在聚合口上而不落成员口跨设备转发时就会出问题。我的习惯是配完以后用display this在成员口上逐个确认一遍别只看聚合口。5.4 排查用的display与抓包组合拳把上面零散的思路整理成一张排查用的对照表出问题时可以按这个顺序过一遍现象优先怀疑第一手命令拿不到地址上行口信任配置display dhcp snooping interface拿到地址不通绑定表缺失或被误拦display ip source binding网关MAC变化ARP欺骗仍在持续reset arp dynamicdisplay arp首次访问慢源抑制阈值过严display arp source-suppression某成员设备失效IRF端口策略未下发display arp detection statistics如果命令看下来还是不确定就上抓包。抓包的位置很关键在接入交换机的上行口抓能同时看到来自核心和来自终端的ARP报文对比两边的内容就能判断是谁在伪造。抓包时过滤条件直接用arp就行别抓全量否则文件大到你打不开。6. 从一台接入交换机到整网部署次序与验证方法6.1 建议的部署次序先核心后接入还是反过来这个问题的答案取决于你的目标是稳妥还是见效快。我在实际项目里的做法是先从一台接入交换机的单个VLAN试点验证通过后再横向铺开最后在核心侧加固。理由是这样的ARP Detection的绝大部分配置和验证工作都在接入侧核心侧主要是提供DHCP服务器和网关改动量小。如果反过来先动核心一旦接入侧策略没配好故障面是整个园区回滚也麻烦。试点阶段建议挑一个影响面小的楼层观察一到两天重点看两点正常用户的ARP解析延迟有没有变化绑定表条目数量是否和实际在线终端数吻合。绑定表条目数是很好的健康指标。如果一个VLAN下有200台终端在线绑定表里只有80条那说明有120台终端的ARP报文根本没被正常处理要么是DHCP Snooping没生效要么是这些终端用了静态IP。6.2 用模拟攻击验证防护是否真的生效配完不验等于没配。验证的方法很简单找一台同网段的测试机构造一个伪造的ARP应答看防护有没有拦住。最直观的判断依据是正常情况下不应该通的事现在确实不通了。具体可以这样验证先在测试机上手工改IP为同网段另一个已在线终端的IP看会不会把对方的表项顶掉。如果防护生效测试机发出的ARP报文会被丢弃对方的通信不受影响如果没生效对方会立刻断线。这个测试一定要在业务低峰期做而且测试完立刻把IP改回来。另一个验证点是看统计计数。display arp detection statistics这类命令会给出门限内被拦下的报文数。如果这个数字一直是0而测试机确实发出了伪造报文那就说明策略没落在正确的端口上。6.3 模拟器与真机的差异HCL实操提醒很多人在H3C Cloud Lab上做ARP防护实验经常会遇到设备起不来启动设备失败之类的问题尤其在Windows 11上更常见。这类问题多半和虚拟化环境、镜像文件完整性有关不是配置本身的问题这里不展开。真正需要提醒的是模拟器上的配置结论不能直接照搬到现机。两个原因一是模拟器上DHCP Snooping和ARP Detection的表项生成逻辑可能简化你看到的绑定表可能是手工加的而不是动态学的二是模拟器里没有真实终端验证ARP欺骗需要自己构造报文很容易构造成格式本身就不合法结果被arp detection validate拦下来你会误以为是绑定表起了作用。我的建议是模拟器上只验证配置能不能敲通、命令层级对不对、表项能不能正常生成真正的策略效果验证放到现机的测试VLAN里做。6.4 无线本地转发场景下的ARP防护落点最后说一个容易漏的场景。无线网络里如果采用集中转发无线终端的报文要经过ACARP处理也就在AC那一侧接入交换机的端口上看不到这些终端的ARP如果采用本地转发终端流量直接从AP所在的接入交换机出去ARP防护的落点就回到了接入交换机的AP接入端口上。这两种模式对ARP防护的影响很实际集中转发模式下接入交换机上的ARP Detection对无线用户几乎不起作用因为报文根本不在这一层出现本地转发模式下AP接入口要作为特殊的信任端口来考虑因为AP下面挂着一堆用户用普通的终端口策略去处理很容易把整个AP下的用户一起拦住。我的处理原则是集中转发靠AC侧做终端准入和ARP相关策略接入交换机这一层只做有线侧的防护本地转发则要把AP接入口单独拿出来设计不要和普通终端口混在一套策略里。这个边界如果一开始没划清楚后面无线用户报障会非常麻烦因为你会在有线侧的日志里完全找不到线索。最后再分享一个我在配置管理上的小习惯每次做完ARP防护下发都把display current-configuration里相关段落导出来存一份同时在拓扑图上标注信任端口的位置。这样三个月后有人报某个口不通你不至于要去翻当时的记录——ARP防护这东西真正难的不是配而是半年后还能想起来当时为什么这么配。