SNMPv3实验与报文分析
一、SNMPv3工作原理
1.1 SNMPv3工作模式
SNMPv3采用客户机/服务器模式。如下图1所示。
由图可知SNMP管理站可向代理发送普通请求(如GetRequest、GetNextRequest等)，代理收到请求之后返回一个响应。
SNMP可向其他的管理站发送通告请求，接收到通告请求的管理站需返回相应的通告响应给管理站。
SNMP代理可向管理站发送告警，接受告警的管理站不需要返回响应。
SNMPv3主要使用数据认证和数据加密作为其安全机制。前者防止SNMP消息再传输过程中被篡改以及阻拦由伪造的SNMP实体发来的SNMP消息，后者则防止SNMP消息再传输过程中被窃听。
下面是安全子系统对去往报文的加密和认证服务：
假设报文处理模型要生成安全等级是认证且加密的报文，则：
报文处理模型调用generateRequestMsg原语，将参数输入给USM，USM通过访问MIB库中的usmUserTable和计算，获得该用户的加密密钥**(encryptKey)、加密协议(privParameters)、认证密钥(authKey)和认证协议(authParameters)，利用 encryptData 原语调用加密模块对scopedPDU**进行加密。
加密模块返回被加密的scopedPDU和privParameters的字节串。
USM将加密模块的输出填到报文格式之中，利用authenticateOutgoingMsg原语调用认证模块对整个报文签发认证。USM通过generateRequestMsg原语的OUT参数向报文处理模型返回经过加密和认证的整个消息、消息长度和安全参数
而USM对到来报文则进行如下步骤：
报文处理模型利用processIncomingMsg原语向USM发出请求，将IN参数输入给USM，USM根据UserName和AuthoritativeEngineID获得该用户的解密密钥**(decryptKey)和认证密钥(authKey)**
利用authticateIncomingMsg原语调用认证模块，对报文进行认证检查，USM再利用decryptData原语调用加密模块对报文进行解密，并输出解密后的scopedPDU
USM通过processIncomingMsg原语的OUT参数向报文处理模块返回经过认证检查和解密的scopedPDU、UserName和AuthoritativeEngineID等信息
在上述过程中，任何一个服务原语的调用失败，都将导致整个处理过程的失败。整体过程如下图所示：
1.2 SNMP的组织结构
SNMPv3的实体主要有三种类型，管理站、代理以及代理服务器。其框架结构如图2所示。
SNMP实体是由一个SNMP引擎和多个应用程序组成。引擎是SNMP实体的核心部分，负责提供各版本SNMP消息的处理功能，主要包括发送、接受、认证、加密与访问控制等。应用程序是SNMP实体的上层部分，负责提供高层对SNMP消息的发送与接收功能。
引擎分配器模块(调度器)负责SNMP消息的发送与接受，能够并发地处理多个版本的SNMP报文。消息处理子系统负责SNMP消息的分析与处理，它包括了SNMPv1、SNMPv2c、SNMPv3等报文处理模型，分别处理不同版本的报文。安全子系统负责SNMP消息的认证与加密，其中包含了一个或多个安全模块，每个模块由不同的协议和模型组成，以便提供各种不同的安全服务。访问控制子系统通告一个或多个访问控制模型提供授权服务，即确定是否允许访问一个管理对象，或者是否可以对某个管理对象实施特殊的管理操作。
SNMP数据以一种标准化的层次结构进行布置，这种结构的大部分都留给将来扩充，而特定厂商添加的部分则被本地化以避免冲突。命名的层次结构由MIB（Management Information Base，管理信息库）组成，它是描述通过SNMP协议可访问的数据的结构化文本文件。MIB 包括了对特定数据变量的说明，数据变量被称为OID（Object Identifier，对象标识符）。
SNMP 层次结构非常像一个文件系统。不过，它是用点号（.）作为分隔符，每个节点被赋予了一个数字而不是名字。为了易于引用，还可以给节点赋予文字名称，但这种命名其实只是为了高层应用方面而已，而不是层次结构的一项功能。
1.3 SNMPv3相对于前2代的改进
SNMP v3 在前面的版本上增加了安全能力和远程配置能力，SNMPv3结构为消息安全和VACM（View-based Access Control Model）引入了USM（User-based Security Model）。这个结构支持同时使用不同的安全机制，接入控制，消息处理模型。SNMP v3 也引入使用SNMP SET命令动态配置 SNMP agent而不失MIB对象代表agent配置。
USM（基于用户的安全模型）
USM引入了用户名和组的概念，可以设置认证和加密功能。认证用于验证报文发送方的合法性，避免非法用户的访问；加密则是对NMS和Agent之间传输的报文进行加密，以免被窃听。通过有无认证和有无加密等功能组合，可以为NMS和Agent之间的通信提供更高的安全性。
VACM（基于视图的访问控制模型）
VACM技术定义了组、安全等级、上下文、MIB视图、访问策略五个元素，这些元素同时决定用户是否具有访问的权限，只有具有了访问权限的用户才能管理操作对象。在同一个SNMP实体上可以定义不同的组，组与MIB视图绑定，组内又可以定义多个用户。当使用某个用户名进行访问的时候，只能访问对应的MIB视图定义的对象。
有三个可能的安全级别: noAuthNoPriv, authNoPriv, 和 authPriv.
noAuthNoPriv 级别指明了没有认证或私密性被执行.
authNoPriv 级别指明了认证被执行但没有私密性被执行.
authPriv 级别指明了认证和私密性都被执行.
auth—认证 支持MD5 or SHA;
priv—加密 支持DES or RSA;
二、设计思路
由于Win10对MIB Browser兼容性不太好，故在VMware下建立win7虚拟机在win7环境下运行MIB Browser（客户端程序，manager），再在VMware下建立centos7虚拟机运行net-snmp（服务端程序，agent）。两虚拟机均采用桥接的方式，并关闭防火墙，使得两台机器在同一子网下且可进行互相通讯。两机器IP地址如下：
win 7：
centos7：
首先关闭防火墙，命令如下：systemctl enable snmpd.service
接下来测试两虚拟机的连通性，测试结果如下：
三、网络拓扑结构
如上图所示，直接将2个虚拟机通过桥接相连。
四、实验过程
4.1 Agent端（Centos7）:
4.1.1 下载安装并查看net-snmp
4.1.2 配置SNMPv3用户
首先停用snmp服务，然后，通过net-snmp-create-v3-user命令增加一个新的SNMPv3的用户，同时配置认证密码及加密密钥。
这里创建了一个名为dl，使用MD5进行认证以及使用DES进行加密，auth-password作为认证密码，encrypt-password作为加密密码。
4.1.3 验证服务
首先开启SNMPv3服务，命令如下：
$ service snmpd start
$ service snmpd status
出现如下图所示结果，证明开启成功。
然后进行可验证，命令如下：
$ snmpwalk -v 3 -u [用户名] -a MD5 -A [认证密码] -l authPriv -x DES -X [加密密钥] localhost
输入命令后可看到如下图所示结果，证明SNMPv3顺利运行。
4.2 Manager端（Win 7）:
4.2.1 MIB Browser基础配置
首先设置agent ip为192.168.10.113，然后选择SNMP协议为SNMPv3，在协议选择时，添加/选择用户为dl，配置认证算法、密码和加密算法、密钥，如下图所示：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-yC0Yvtcy-1592385258399)(
根据在Centos7中添加的用户信息进行填写，Authentication Protocol中选择MD5，
Privacy Protocol选择DES。密码内容分别为auth-password、encrypt-password。
五、结果分析与展示
5.1 结果展示
使用MIB Browser连接被管对象（Centos7），成功连接，结果如下：
可以看到，由MIB发出Request，由Centos7返回Synchronize和Response消息。来回的信息中可以看到Authentication Protocol, Privacy Protocol以及Security Level等相关信息。
打开MIB Browser与centos7建立连接前，打开Wireshark,捕获相关报文，SNMPv3报文如下：
5.2 报文分析
首先，我们先来看看SNMPv3的消息格式如下：
这里以get-request及其对应report为例。
5.2.1 get-request报文：
上图中，高亮部分即为SNMPv3部分。由于SNMPv3依然使用BER编码规则，因此，报文整体格式仍为TLV格式**（下文中为图方便，将INTEGER简记为int,将Octect String 简记为string）**
| 十六进制数据 | 含义 |
|---|---|
| 30 | T 表示 SEQUENCE类型（即SNMP报文整体为SEQUENCE类型） |
| 38 | L 表示 后面总共有3*16+8= 56 个字节的内容 |
| 02 01 03 | T L V int型长度为1 ，值为3。对应到SNMPv3中可知，这里是代表version为3 |
| 30 | T 表示 SEQUENCE类型 ，这里指msgGlobalData为一个SEQUENCE |
| 0e | L 表示该子报文总共有14个字节 |
| 02 01 38 | TLV int型 值为38 表示 Message ID 为38 |
| 02 03 00 ff f0 | TLV int型 表示 msgMaxSize：65520 |
| 04 01 04 | TLV 表示对应的是msgFlags：04 |
| 02 01 03 | TLV 表示对应的msgSecurityModel：USM(3) |
| 04 10 | 引擎ID |
| 30 0e | T L SEQUENCE类型 长14个字节 |
| 04 00 | T L string型，长度为0，没有内容，表示msgAuthoritativeEngineID 缺失 |
| 02 01 00 | TLV int型长度为1，值为0，表示msgAuthoritativeEngineBoots值为0 |
| 02 01 00 | TLV int型长度为1，值为0，表示msgAuthoritativeEngineTime值为0 |
| 04 00 | TL string型，长度为0，没有内容，表示msgUserName暂无 |
| 04 00 | TL string型，长度为0，没有内容，表示msgAuthenticationParameters 暂无 |
| 04 00 | TL string型，长度为0，没有内容，表示msgPrivacyParameters暂无 |
| 30 11 | T L SEQUENCE类型 长17个字节 |
| 04 00 | TL string型，长度为0，没有内容，表示contextEngineID暂无 |
| 04 00 | TL string型，长度为0，没有内容，表示contextName暂无 |
| a0 0b | T L Get-Request类型PDU 长度为11个字节 |
| 02 01 37 | TLV int型，长度为1 表示request-id：55 |
| 02 01 00 | TLV int型，长度为1 表示error-status为0 |
| 02 01 00 | TLV int型，长度为1 表示error-index为0 |
| 30 00 | TL SEQUENCE类型，长度为0 表示variable-bindings：0 items |
5.2.2 report报文：
分析方法与get-request一致。与get-request不同的是，在report中回复了get-request报文中的一些空缺，如：
| 新增内容 | 对应报文 |
|---|---|
| msgAuthoritativeEngineID | 80 00 1f 88 80 0c cf 1b 79 0b 3d e3 5e 00 00 00 00 |
| contextEngineID | 80 00 1f 88 80 0c cf 1b 79 0b 3d e3 5e 00 00 00 00 |
| variable-bindings | 30 0f 06 0a 2b 06 01 06 03 0f 01 01 04 00 41 01 03 |
其中，新增的variable-bindings的报文有2部分（即SEQUENCE中含2个子报文），第一部分报文类型为06**（OBJECT IDENTIFIER）**，长度为0a（10），值为 1.3.6.1.6.3.15.1.1.4.0，第二部分报文类型为41（APPLICATION 1 ）,1个字节长，值为3。
六、遇到问题与解决办法
-
创建snmpv3用户时，设置认证密码太短
如下图所示，最开始设置密码时，用短小密码，能成功创建用户，但开始Snmp服务时会出错。
解决办法：将认证密码加长即可。