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。

六、遇到问题与解决办法

1. 创建snmpv3用户时，设置认证密码太短

   如下图所示，最开始设置密码时，用短小密码，能成功创建用户，但开始Snmp服务时会出错。

解决办法：将认证密码加长即可。