SNMPv1 和 SNMPv2c：不安全！！！
SNMP 最初被开发时，包含称为“社区字符串”的明文“密码”。SNMP 协议的前两个版本（SNMPv1 和 SNMPv2c）包含这些明文密码，如以下屏幕转储所示：
# snmpget -d -v 2c -c demopublic test.net-snmp.org sysContact.0
Sending 47 bytes to UDP: [157.185.82.8]:161->[0.0.0.0]:0
0000: 30 2D 02 01 01 04 0A 64 65 6D 6F 70 75 62 6C 69 0-.....demopubli
0016: 63 A0 1C 02 04 78 8E 32 C9 02 01 00 02 01 00 30 c....x.2.......0
0032: 0E 30 0C 06 08 2B 06 01 02 01 01 04 00 05 00 .0...+.........
Received 102 byte packet from UDP: [157.185.82.8]:161->[0.0.0.0]:47960
0000: 30 64 02 01 01 04 0A 64 65 6D 6F 70 75 62 6C 69 0d.....demopubli
0016: 63 A2 53 02 04 78 8E 32 C9 02 01 00 02 01 00 30 c.S..x.2.......0
0032: 45 30 43 06 08 2B 06 01 02 01 01 04 00 04 37 4E E0C..+........7N
0048: 65 74 2D 53 4E 4D 50 20 43 6F 64 65 72 73 20 3C et-SNMP Coders <
0064: 6E 65 74 2D 73 6E 6D 70 2D 63 6F 64 65 72 73 40 net-snmp-coders@
0080: 6C 69 73 74 73 2E 73 6F 75 72 63 65 66 6F 72 67 lists.sourceforg
0096: 65 2E 6E 65 74 3E e.net>
SNMPv2-MIB::sysContact.0 = STRING: Net-SNMP Coders <[email protected]>
这显然是一个问题，因此后来开发了 SNMPv3 来保护协议。
SNMPv3：确保安全
RFCS 3410-3419中记录了 SNMPv3，它定义了 SNMPv3 的模块化方法。
这种模块化方法很重要，因为它被设计为允许协议在将来需要或首选其他类型的安全性时进行适应。
SNMP V3的架构图如下：
使用安全的SNMP
包括用于保护 SNMP 的选项，下面将详细介绍：
| 选项 | 描述 |
|---|---|
| SNMPv1或SNMPv2c | 完全不提供安全性。受到一切支持。 |
| 带有USM的SNMPv3 | 原始SNMPv3安全模型。大多数设备支持。 |
| 带有TLS或DTLS的SNMPv3 | 通过TLS和DTLS隧穿SNMP。希望很快会受到大多数设备的支持。 |
| SSH上的SNMPv3 | 通过SSH建立SNMP隧道（Net-SNMP不支持100％） |
| 通过Kerberos的SNMP | 使用Kerberos保护SNMP（甚至更少支持） |
我们应该怎么选？
当然，选择最适合的情况！建议如下：
- 如果完全使用 Net-SNMP 产品或支持TLS的产品：在（D）TLS上使用SNMPv3
- 如果与旧版 SNMPv3 设备通信：请使用SNMPv3 / USM
- 如果仅与 SNMPv1 / SNMPv2c 设备通信：使用 v1/v2c
带有 USM 的 SNMPv3
原始的 SNMPv3 规范包括基于用户的安全模型(USM: User-Based Security Model )，该模型通过允许管理员使用各种安全凭证定义“用户”来保护协议。这对确保协议的安全起了很大的作用（尽管，Wes Hardaker（Net-SNMP的创始人）在博客条目中提供文档，但 SNMPv3 / USM 仍然存在一些问题。运营商还发现，保护 SNMPv3 / USM 需要“另外”密码数据库来维护，这在操作上很麻烦。
SNMPv3 / USM 已被广泛实施，大多数现代的“好的”设备都将支持它。
有关将 SNMPv3 / USM 与 Net-SNMP 工具包一起使用的详细信息，请参见SNMPv3 / USM教程。
隧道SNMPv3
有关SNMP安全性的最新IETF活动已在SNMP集成安全模型（ISMS）工作组中完成。与其决定像USM那样创建另一个安全系统，不如确定用户希望在他们已经知道和理解的协议上建立SNMP隧道。这是通过创建以下新的RFC来完成的：
- RFC5590-用于简单网络管理协议的传输子系统
- RFC5591-简单网络管理协议（SNMP）的传输安全模型
- RFC5592-用于简单网络管理协议（SNMP）的安全Shell传输模型
- RFC5608-简单网络管理协议（SNMP）传输模型的远程身份验证拨入用户服务（RADIUS）用法。
- RFC5953-简单网络管理协议（SNMP）的传输层安全性（TLS）传输模型。
这些 RFC 提供了通过 SSH，TLS 和 DTLS 隧道传输 SNMPv3 数据包的框架。SSH 协议使用现有的 SSH 身份验证和加密方法（例如 SSH 密钥和/或用户名和密码）来保护其流量。TLS 和 DTLS 协议使用 X.509 证书来保护其流量。
Net-SNMP 5.6 包含对通过 TLS 和 DTLS 使用 SNMP 的强大支持。
有关在 TLS 和 DTLS 上设置和使用 SNMP 的详细信息，请参见《使用TLS》教程。
Net-SNMP 5.6 还包含对在 SSH 上使用 SNMP 的最小支持，但是由于缺少可用的 SSH服务器端库，因此支持受到限制，并且在连接到 OpenSSH sshd 服务器时通过专门的外壳“ hack”实现。
有一个关于使用可用 SSH 的性能影响的信息在这里。
Kerberos SNMPv3
Wes Hardaker 和 Ken Horstein 开始在 IETF 中工作，以为 SNMPv3 实现 kerberos 安全模型。尽管 Net-SNMP 包含此功能的原型实现，但该工作从未在 IETF 或 Net-SNMP 实现内完成，并且尚未为实际使用做好准备。