3 snmp 服务存在可写口令漏洞解决方法

上周帮一个客户做内网渗透测试，服务法扫描完直接傻眼——三台核心交换机全开着SNMP，写口community string居然是令漏“private”。不是洞解默认的“public”，但也好不到哪去。决方用snmpwalk试了一下，服务法能读能写。写口这意味着什么？令漏攻击者可以改路由表、关接口、洞解甚至改设备配置。决方客户还觉得内网安全得很，服务法说“又没对外暴露”。写口

SNMP可写口令漏洞这事，令漏说大不大，洞解说小不小。决方它不像RCE那么炸裂，但架不住它普遍。很多运维图省事，配SNMP时直接上“private”或者“rw”这种弱口令，甚至干脆用“public”给读写权限。Cisco、H3C、华为的设备默认都这样，厂商文档里也经常拿“private”当例子。结果就是全网设备裸奔。

先搞清楚怎么判断有没有问题

拿snmpwalk扫一下就知道。命令很简单：

snmpwalk -v 2c -c private 192.168.1.1

如果返回一大堆OID和值，说明能读。再试试写操作，用snmpset改个无关紧要的OID，比如sysContact：

snmpset -v 2c -c private 192.168.1.1 sysContact.0 s "test"

要是返回“Timeout”或者“No Such Object”，那写不了。但要是返回了新的值，恭喜你，中招了。我见过最离谱的是某医院内网，核心交换机SNMP写权限开着，community string是“admin123”。用snmpset直接把某个VLAN接口shutdown了，整个科室断网。恢复花了二十分钟，运维还以为是硬件故障。

怎么解决？分三步走，但别死板

第一步，改community string。别用“public”、“private”、“rw”、“admin”这些。用随机字符串，长度至少16位，大小写加数字加符号。比如“Kx9#mP2$vL5@nQ8”。注意，SNMPv1和v2c的community string是明文传输的，抓包就能看到。所以改强口令只是第一步，不是终点。

第二步，限制访问源IP。ACL里只允许网管服务器的IP访问SNMP端口。其他一律deny。这招最有效，因为就算口令泄露，攻击者也连不上。具体配置看设备型号，Cisco是access-list加snmp-server community后面跟ACL号。华为是acl加snmp-agent community read acl。别嫌麻烦，配一次管几年。

第三步，能升v3就升v3。SNMPv3支持认证和加密，比v2c安全得多。配置稍微复杂点，要建用户、设认证密码和加密密码。但值得。我经手的项目里，凡是升了v3的，后面再也没出过SNMP相关的漏洞。不过有些老设备不支持v3，那就只能靠前两步硬扛。

一个真实案例的细节

去年某制造企业，内网有台UPS的SNMP卡，community string是“public”，而且可写。攻击者通过它改了UPS的关机阈值，导致市电波动时UPS直接切断了服务器电源。生产系统停了四个小时。后来查日志，发现SNMP写操作记录里有一串陌生的IP。运维说“没想到UPS也能被黑”。

这事之后，我养成了一个习惯：每次做内网评估，先扫SNMP。用onesixtyone或者nmap的snmp-brute脚本，几分钟就能出结果。扫出来可写的，直接标高危。别管它是什么设备，打印机、UPS、摄像头、交换机，只要SNMP可写，就是入口。

几个容易踩的坑

改完community string，记得同步改网管软件里的配置。不然监控直接挂掉，运维会来找你麻烦。还有，有些设备改完SNMP配置后需要重启SNMP进程，不是重启设备。命令一般是“no snmp-server community xxx”再重新加。别直接reload，生产环境扛不住。

另外，别以为内网就安全。我见过太多内网横向移动的案例，攻击者先拿下一台办公PC，然后扫内网SNMP，找到可写的设备，改配置当跳板。SNMP漏洞往往不是入口，但它是很好的跳板。

最后说一句：SNMP可写口令这事，本质上是运维便利性和安全性的冲突。图省事用“private”，迟早出事。花半小时改配置，比事后救火划算得多。