1. 项目缘起：一次安全审计引发的“明文”惊魂

那天下午，我正在帮一个客户做网络设备的例行安全审计。客户用的是清一色的锐捷交换机，规模不小，几十台设备构成了他们办公和生产网络的核心。审计流程很常规，登录设备，show running-config，把配置备份下来，然后逐条检查，看看有没有弱密码、默认配置、不必要的服务端口开着。当我用show run命令把其中一台核心交换机的配置完整显示在屏幕上，准备复制粘贴到文本分析工具里时，我的目光扫过几行熟悉的配置，心里“咯噔”一下。

我看到了类似这样的配置片段：

enable secret level 15 5 $1$mF$U4zrE6N7DqQwSxYv.123456 snmp-server community public ro snmp-server community private rw

问题就出在这里。第一行的enable secret命令，后面跟着的那一串以“5 $1$”开头的字符，是锐捷交换机对特权密码（enable password）进行MD5加密后的密文，这个没问题，是安全的做法。但紧接着的两行snmp-server community配置，后面的public和private这两个团体字（community string），竟然就这么赤裸裸地以明文形式躺在配置文件里！这就像你把家门钥匙藏在花盆底下，还在花盆上贴了张纸条写着“钥匙在花盆底下”一样。任何一个能通过合法或非法手段看到这份配置文件的人，无论是通过console口、telnet、ssh登录后查看，还是配置文件意外泄露，都能立刻获取到这两个SNMP的“通行证”。

这还不是最要命的。我下意识地又敲了一条命令：show privilege。这条命令通常用来显示当前用户的权限级别。然而，在锐捷交换机的某些版本里，这条命令的输出可能会“附赠”一些额外信息——它有时会把所有级别（比如1级和15级）的密码，无论是否加密，都显示出来。如果管理员配置的是较弱的加密类型（比如type 7，一种可逆的简单加密），或者在某些特定场景下，这些密码甚至可能以可读的形式呈现。那一刻，我后背有点发凉。这意味着，我们自以为安全的设备管理，可能从配置文件的层面就存在着巨大的安全隐患。密码和SNMP团体字，这些最核心的认证凭据，正在以明文或弱加密的形式“裸奔”。这次审计发现的不是某个高深的漏洞，而是一个基础但普遍、且极易被忽视的配置安全问题。它促使我决定，必须把这个问题彻底搞清楚，并找到一套可靠的加固方案。

2. 锐捷交换机密码体系与显示机制的深度拆解

要解决“显示明文”的问题，首先得弄明白锐捷交换机是怎么处理和管理密码的。这不仅仅是知道几条命令，而是要理解其背后的逻辑和不同场景下的表现。

2.1 密码的“三重门”：配置、存储与显示

锐捷交换机的密码，主要涉及三个环节：你输入配置命令的那一刻、密码在设备配置文件（running-config/startup-config）中的存储形态、以及你通过show命令查看时的显示形式。这三个环节的安全状态可能完全不同。

当你使用enable password或username命令配置密码时，可以通过0、5、7等参数指定加密方式。例如：

• enable password 0 ruijie：后面的“ruijie”是明文。这是最危险的方式，密码在配置文件中就是enable password 0 ruijie。
• enable password 7 094F471A1A0A：使用思科兼容的Type 7加密。这是一种简单的、可逆的加密算法，安全性极低，网上有大量现成的工具可以瞬间解密。在配置文件中存储为密文，但安全性形同虚设。
• enable secret 5 $1$mF$U4zrE6N7DqQwSxYv.123456：使用MD5哈希算法（对应数字5）。这是一种单向散列，理论上无法从这串字符反推出原始密码。这是推荐的安全做法。

关键在于，你配置时使用的加密类型，决定了它在配置文件中的存储形态。但“显示”环节可能独立于存储。show running-config命令默认会“忠实”地显示配置文件中的内容。如果你配的是Type 7密文，它显示密文；如果你配的是明文（type 0），它就直接显示明文。然而，一些其他的show命令，或者特定条件下的show run，可能会触发设备进行“解释”或“还原”显示，这就导致了风险。

2.2show privilege命令的“越权”行为与风险场景

show privilege命令的本意是显示当前用户的权限级别。但在部分锐捷交换机的老旧版本或特定软件版本中，这条命令存在一个设计缺陷或“特性”：它会尝试列出所有用户级别的密码信息。在某些情况下，为了提供“完整信息”，它可能会将经过Type 7加密的密码解密后显示，或者直接显示未加密的密码。

风险场景模拟：

1. 一个低权限用户（如level 1）通过Telnet登录了设备。
2. 他执行了show privilege命令。
3. 命令输出中，除了显示他当前是level 1，可能还会附带一行类似The password for privilege level 15 is: admin123的信息。
4. 攻击者就此获得了最高权限（level 15）的密码。

即使密码是用MD5加密的（type 5），show privilege通常不会显示明文，但它仍然可能暴露密码的哈希值。虽然MD5不可逆，但攻击者可以利用彩虹表进行碰撞攻击，如果原始密码不够复杂，仍有被破解的风险。这个命令因此成为了一个潜在的信息泄露点。在实际运维中，应尽量避免非授权用户能执行此命令，并升级到已修复此问题的软件版本。

2.3 SNMP团体字：被遗忘的“明文重灾区”

如果说密码还可能有一层加密的外衣，那么SNMP（简单网络管理协议）的团体字（Community String）在很多网络设备上，长期以来就是“裸奔”的状态。团体字的作用类似于密码，用于认证网络管理系统（NMS）对设备的访问权限。ro表示只读，rw表示读写。

在锐捷交换机上，配置SNMP团体字的典型命令就是：

snmp-server community public ro snmp-server community private rw

这里的public和private就是明文团体字。它们会原封不动地保存在配置文件中，并通过show run命令直接显示。这带来了巨大的风险：

1. 信息泄露：任何能访问配置的人都能获得团体字。
2. 网络侦察：攻击者利用public这样的默认或常见只读团体字，可以扫描整个网段，获取设备接口信息、路由表、ARP表等，绘制网络拓扑。
3. 配置篡改：如果读写（rw）团体字如private被获取，攻击者可以直接修改设备配置，例如关闭端口、篡改路由、添加后门账户等，造成网络中断或沦陷。
4. 攻击跳板：在某些情况下，通过SNMP读写权限，攻击者甚至能上传恶意文件或触发某些操作，将交换机作为攻击内网其他系统的跳板。

SNMP v1和v2c协议本身就不支持加密，团体字在网络传输中也是明文。因此，在设备配置文件中明文存储，使得风险从“协议固有缺陷”延伸到了“静态配置泄露”，危害加倍。

3. 实战加固：从配置源头扼杀明文泄露

理解了风险所在，加固就有了明确的方向。我们的目标是在配置、存储、显示三个环节都尽可能消除明文。

3.1 密码安全配置最佳实践

彻底弃用不安全的密码配置方式，全面转向强哈希加密。

1. 禁用明文密码（Type 0）：绝对不要使用enable password 0或username ... password 0这种形式。在全局配置模式下，可以设置强制使用加密服务：service password-encryption。但请注意，这个命令默认只会将明文密码加密成脆弱的Type 7格式，并不能自动生成MD5哈希。它主要防止你敲入的明文在配置中可见，但防不住专业的解密工具。因此，它不能替代下面第2步。

2. 强制使用MD5哈希（Type 5）：对于特权密码（enable password），唯一正确的姿势是使用enable secret命令。这个命令会自动采用MD5（或更安全的算法，取决于平台和版本）进行哈希处理。

   Ruijie(config)# enable secret YourStrongPassword@2024

   执行后，show run里看到的将会是一串MD5哈希值，而不是你的密码。对于本地用户密码，也应使用secret关键字而非password。

   Ruijie(config)# username admin secret YourAdminPass#123

3. 定期更新密码：即使使用了强哈希，也应定期更换密码，特别是当有管理员离职或权限变更时。可以通过编写脚本批量更新，或在设备上手动修改。

4. 权限分级与AAA认证：不要所有人都用同一个enable密码。结合AAA（认证、授权、记账）服务，使用RADIUS或TACACS+服务器进行集中认证。为不同角色的管理员分配不同的权限级别（privilege level），并通过ACS服务器动态下发。这样，设备本地可以不保存任何高级别密码，从根本上杜绝泄露。

3.2 封堵show命令的信息泄露漏洞

对于show privilege等命令可能泄露信息的问题，采取防御性配置。

1. 升级操作系统：首先查询设备型号和当前软件版本（show version），访问锐捷官网，查看该型号的最新稳定版软件。新版本通常会修复已知的信息泄露类漏洞。在业务允许的维护窗口内进行升级。

2. 限制命令执行权限：通过权限级别控制，将敏感的show命令（如show running-config、show privilege、show tech-support等）划分到较高的权限级别（例如level 15），并确保只有高级管理员才有该级别的权限。对于通过AAA认证的用户，可以在RADIUS/TACACS+服务器上精细控制其可执行的命令集。

3. 审计与监控：在日志服务器或网管系统上，集中收集和分析设备的syslog。可以设置告警规则，当有用户执行show privilege等敏感命令时，立即产生告警，以便管理员及时核查。

3.3 SNMP团体字安全强化方案

SNMP的安全加固需要从协议版本、访问控制和加密传输多方面入手。

1. 弃用SNMP v2c，迁移至SNMP v3：这是最根本的解决方案。SNMP v3提供了基于用户的安全模型（USM），支持认证（验证消息来源）和加密（保护数据内容）功能。

   • 认证：使用SHA或MD5算法，确保数据包来自合法用户且未被篡改。
   • 加密：使用DES或AES算法，对传输的数据进行加密，防止窃听。 配置示例：

   ! 创建SNMPv3组，定义安全级别（auth为认证，priv为加密） snmp-server group MyGroup v3 priv ! 创建SNMPv3用户，关联到组，并指定认证和加密密码 snmp-server user admin MyGroup v3 auth sha AuthPass123 priv aes 128 PrivPass456

   这样，在配置文件中看到的将是用户名和经过处理的密码信息，而不是明文团体字。网管系统也需要相应配置为SNMPv3模式。

2. 如果必须使用SNMP v2c（兼容老旧网管）：

   • 使用复杂团体字：避免使用public、private、admin等默认或常见词汇。使用包含大小写字母、数字、特殊字符的长字符串，例如Rj@Switch-Read-0nly-2024!。
   • 严格限制访问源：使用ACL（访问控制列表）限定只有网管服务器的IP地址才能使用SNMP团体字进行访问。

     ! 定义一个ACL，允许网管服务器IP ip access-list standard SNMP-ACL permit host 192.168.1.100 ! 应用ACL到SNMP团体字 snmp-server community ComplexReadOnlyString ro SNMP-ACL

   • 最小权限原则：绝大多数监控场景只需要只读（ro）权限。严格审查并限制读写（rw）团体字的使用范围和IP。

3. 禁用不必要的SNMP服务：如果某些交换机纯粹作为接入层使用，没有纳入网管系统监控，可以直接全局关闭SNMP服务。

   no snmp-server

4. 排查、验证与长效运维机制

配置完成后，不能假设万事大吉，必须进行严格的验证，并建立长效的运维检查机制。

4.1 安全配置验证清单

实施加固后，请按照以下清单逐一验证：

注意：验证show privilege时，务必用一个非15级的低权限账号进行测试，模拟攻击者视角。如果输出中包含密码信息，说明漏洞仍存在，需检查设备版本或权限配置。

4.2 自动化巡检脚本构思

对于拥有数十上百台锐捷交换机的环境，手动逐台检查是不现实的。可以编写一个简单的自动化脚本（使用Python的Paramiko或Netmiko库），定期登录设备执行上述安全检查命令，并解析输出结果。

脚本的核心逻辑是：

1. 读取设备IP、凭据清单。
2. 依次登录设备。
3. 执行关键检查命令（如show run \| include enable\|username\|snmp-server，show privilege）。
4. 分析返回的文本：
   • 检测是否存在enable password 0/7。
   • 检测是否存在明文的snmp-server community行且没有ACL限制。
   • 检测show privilege输出中是否包含密码关键词。
5. 生成报告，标记出存在风险的设备和具体问题，并发送邮件告警。

这样的脚本可以部署在运维服务器上，每天或每周定时运行，将安全巡检从“救火式”变为“预防式”。

4.3 配置备份与版本管理中的安全考量

即使设备本身配置安全了，备份出来的配置文件如果管理不当，也会成为泄密源头。

1. 加密存储备份文件：使用secure copy（SCP）或secure FTP（SFTP）协议将配置文件备份到服务器，确保传输过程加密。在备份服务器上，对存储配置文件的目录或文件本身进行加密（如使用GPG）。
2. 访问权限控制：严格限制能访问备份服务器和配置文件仓库的人员权限。遵循最小权限原则。
3. 配置文件脱敏：在将配置文件导入知识库、工单系统或给第三方技术支持时，必须进行脱敏处理。编写脚本，自动将配置文件中所有enable secret后的哈希值、username ... secret后的哈希值、SNMP团体字等敏感信息替换为<REMOVED>或类似的占位符。
4. 使用版本控制系统：将脱敏后的配置文件纳入Git等版本控制系统管理。这样不仅能追溯配置变更历史，还能通过分支和Pull Request流程对配置修改进行代码审查，进一步确保变更的安全性和合规性。

网络设备的安全是一个动态的过程，而非一劳永逸的设置。从锐捷交换机密码和SNMP团体字明文显示这个具体问题切入，我们实际上梳理了一套从协议理解、安全配置、漏洞排查到自动化运维的设备安全加固方法论。最深的体会是，真正的安全往往藏在那些最基础、最容易被习惯性忽略的配置细节里。定期审视你的show running-config，用攻击者的眼光去看待每一行配置，你会发现很多“房间里的大象”。