问题背景
公司内网有 32 台交换机、2 台防火墙和 4 台 UPS，统一由 Zabbix 监控。这套监控是五年前搭的，走 SNMPv2c，团体名沿用了厂商默认的 public（只读）和 private（读写）。当时的理由很朴素：SNMP 只在内网用，管理网段也不对办公网开放，没必要搞得太复杂。
管理网段是 10.10.0.0/24，办公网段是 10.20.x.0/24，中间由核心交换机路由。理论上办公终端能 ping 到管理地址，但大家默认“能通不代表能随便访问”，没有在设备上做过任何 SNMP 访问控制。这个假设在季度安全巡检时被打破了。
故障现象
- 安全巡检工程师在办公网一台普通终端上执行
snmpwalk -v2c -c public 10.10.0.1，直接读出了核心交换机的系统信息、接口列表和 ARP 表。 - 继续用
private尝试，33 台设备中有 6 台返回了读写权限，理论上可以通过snmpset修改接口状态、VLAN 描述等对象。 - 交换机 syslog 里出现大量来自办公网段地址的 SNMP 请求，源地址不是监控服务器
10.10.5.20。 - 巡检报告把“网络设备 SNMP 默认团体名可读写”定为高危，要求限期整改。
- 监控本身没有异常，Zabbix 曲线一切正常——这也解释了为什么这个问题多年没被发现：从运维视角看，SNMP 一直是“好用”的。
排查过程
第一步复现。在受控的办公终端上执行 snmpget -v2c -c public 10.10.0.1 1.3.6.1.2.1.1.1.0，返回设备型号和固件版本；再走 1.3.6.1.2.1.4.22（ARP 表），能把管理网段和服务器的 IP-MAC 对应关系完整拉出来。这说明不是扫描器误报，默认团体名确实可用。
第二步查设备配置。Cisco 设备上看 show running-config | include snmp-server community，Huawei/H3C 设备上看 display current-configuration | include snmp-agent community，结果很统一：只读团体名 public、读写团体名 private，后面没有跟 ACL 编号。也就是说，任何能路由到管理网段的地址都可以访问 SNMP。
第三步确认网络路径。核心交换机上管理 VLAN 与办公 VLAN 之间是三层互通，没有 ACL 限制 UDP 161；防火墙的策略也只管出口，不管内网东西向。办公终端 ping 管理地址能通，SNMP 自然也能通。
第四步评估影响面。在获得授权的前提下，从一台跳板机对管理网段做 UDP 161 探测，并用常见默认团体名尝试：33 台设备中 27 台响应 public，6 台响应 private。响应内容足以画出网络拓扑、定位服务器、识别设备型号和固件版本——这些都是攻击者做横向移动前最想要的信息。
第五步确认监控依赖。Zabbix 的 SNMP 接口配置里写的就是 public，来源地址 10.10.5.20。这意味着整改不能直接改团体名了事，必须同步改监控，否则会引发大面积“设备不可达”告警。
解决方案
整改分两步：先止血，再治本。
止血（当天完成）：删除所有设备的读写团体名 private，只保留只读；把只读团体名改成强随机字符串；在每台设备上给 SNMP 绑定 ACL，只允许监控服务器 10.10.5.20 和跳板机访问 UDP 161。监控侧同步更新凭据，分批次改，每批改完立即验证 Zabbix 数据恢复。
治本（两周内完成）：升级到 SNMPv3 的 authPriv 模式，认证用 SHA-256，加密用 AES，彻底避免团体名明文传输。监控模板、设备账号和凭据管理同步调整；不支持 v3 的老设备保留“强团体名 + ACL + 只读”作为补偿措施，并列入淘汰计划。
| 方案 | 安全性 | 改造成本 | 适用场景 |
|---|---|---|---|
| SNMPv2c 强团体名 + 管理 ACL | 中：团体名仍明文，可被嗅探；ACL 限制来源后风险可控 | 低：改设备配置和监控凭据即可 | 不支持 v3 的老旧设备过渡 |
| SNMPv3 authPriv | 高：认证加加密，凭据不在网络上裸奔 | 中：设备、监控模板、账号体系都要改 | 主流设备的目标态 |
| 关闭 SNMP 改用 Agent | 高：不暴露 UDP 161 | 高：需安装和维护 Agent | 可装 Agent 的服务器类设备 |
另外补一条管理面收口：把设备管理地址统一放进独立管理 VLAN，在核心交换机上拒绝办公网段直接访问 UDP 161/162，只放行监控服务器和跳板机。这样即使某台设备漏配 ACL，办公终端也无法直接摸到 SNMP。
根因分析
直接根因是 网络设备沿用默认 SNMP 团体名 public/private，且管理面没有 ACL，任何能路由到管理网段的终端都能读取甚至修改设备配置。
更深一层，是把“默认值”当成了“配置”。设备出厂带 public，装上监控能用，就没人再问这个值意味着什么。SNMPv2c 的团体名本质上是明文密码，抓包就能看到；private 更是直接给了写权限。再叠加“内网可信”的假设——管理网段对办公网三层可达，却不做任何访问控制——默认值就从“方便”变成了“敞开的门”。
还有一层是监控视角的盲区：Zabbix 只关心数据有没有采到，不关心采集通道是否安全；安全巡检只看报告里的端口和口令，很少去 snmpwalk 一下网络设备。两套体系各看一半，问题就一直悬在中间。
预防措施
- 设备入网基线增加“默认团体名/默认口令”检查项，
public、private、admin一律视为不合格，验收后才允许上线。 - 管理面强制 ACL：SNMP、SSH、HTTPS 管理入口只允许监控服务器和跳板机，办公网段默认拒绝。
- 新设备优先 SNMPv3 authPriv；存量设备制定分批升级计划，不能升级的写入风险台账。
- 每季度做一次授权内的 SNMP 自测：从办公网和跳板机各试一次，确认只有预期来源能读。
- 配置变更纳入审计，团体名、ACL、SNMP 用户变更要留记录，避免整改后又被临时需求改回去。
总结
监控协议也是攻击面。SNMP 让运维“看得见”设备，也让任何能访问 UDP 161 的人看得见同一批设备——包括 ARP 表、接口拓扑和固件版本。默认团体名不是配置，是欠账；内网也不是安全边界，只是攻击者少走几步路的地方。把管理面收进 ACL 和独立 VLAN，把 SNMPv2c 换成 authPriv，做的其实是一件事：让“能监控”和“谁都能看”彻底分开。