SNMP学习 SNMPv3 VACM（视图访问控制模型）

目录:

☆ SNMPv3视图访问控制模型

☆ SNMPv3报文格式

☆ VACM参数

☆ Context Table

☆ Security To Group Table

☆ Access Table

☆ View Tree Family Table

☆ Overall Picture

☆ 小结

☆ 参考资源

--------------------------------------------------------------------------

☆ SNMPv3视图访问控制模型

本文是介绍SNMPv3新安全特性的第二篇。前面我们介绍了基于用户的安全模型USM以

及如何完成SNMPv3报文的鉴别、加密、解密。这次我们介绍基于视图的访问控制模型

VACM(View-based Access Control Model)，RFC 2575定义了VACM，它提供对MIB的访

问控制。

一个SNMP实体的访问控制子系统负责检查对指定MIB的某种类型的访问是否被允许。

你将会看到，VACM引入的概念相当复杂、混乱。SNMPv1和SNMPv2c采用community

string来划分MIB范围、确定访问权限等等。而VACM允许更加严谨的动态的访问控制

模型，易于管理员配置。

☆ SNMPv3报文格式



SNMPv3的报文格式变得适合使用USM这样的安全模型以及VACM这样的访问控制模型。

msgVersion

报文的SNMP版本号，比如1、2或3

msgID

msgID用于在manager和agent之间对应请求和响应消息。响应报文中的msgID必须

与请求报文中的msgID一致。

msgMaxSize

msgMaxSize指明了"发送者"所能接收的来自其它SNMP engine的最大消息长度。

msgFlags

msgFlags就一个字节，指明如何处理消息。比如，msgFlags中有两个bits用于指

明报文是否需要验证、加密。

msgSecurityModel

SNMPv3被设计成多种安全模型并存。msgSecurityModel指明该消息使用的安全模

型。这样接收实体就知道该采用哪种安全模型。

msgSecurityParameters

这是一个字节数组，对应安全模型相关数据。这些数据仅由msgSecurityModel指

定的安全模型定义、使用。介绍USM时，已经看到如何利用这个域对SNMPv3报文

进行鉴别、加密、解密。

scopedPDU

scopedPDU包含常规PDU以及一些鉴别信息，这些鉴别信息指明处理PDU时的唯一

上下文，上下文是可配置的。

☆ VACM参数

VACM在进行访问控制时会用到msgFlags、msgSecurityModel以及scopedPDU域。

msgFlags用于确定消息的安全级别，比如noAuthNoPriv、authNoPriv或authPriv。

msgSecurityModel指明消息所用安全模型。scopedPDU包含上下文以及被管理对象的

OIDs，具体有如下域:

contextEngineID

contextEngineID唯一标识一个SNMP实体，该实体在特定上下文内可以访问一个

被管理对象的实例。

contextName

PDU数据所属上下文的唯一名字，这个是可配置的。

PDU(数据)

SNMP协议数据单元。参看RFC 1905了解SNMP PDUs更多信息。

这三个参数被传递给isAccessAllowed()函数，该函数是VACM的唯一入口点，在此决

定访问是否被允许。PDU中每一个变量都要接受检查，如果其中一个变量不可访问，

就向主调者返回错误，处理将终止。VACM定义了四个表，每个表负责不同方面的访问

控制，它们均可通过VACM MIB远程修改。

☆ Context Table

这里所谓的上下文实际定义了一个SNMP实体所能访问的被管理对象集合。换言之，用

一个名字代表被管理对象子集。可能一个对象位于多个上下文中，可能一个SNMP实体

被允许访问多个上下文。vacmContextTable用于存放所有本地可访问上下文，其关键

字为contextName，每个表项含有:

vacmContextName

一个唯一的可读字符串，用于命名一个上下文。会在vacmContextTable中搜索

scopedPDU里的contextName。如未找到匹配，拒绝访问并返回noSuchContext。

反之继续访问控制检查。

☆ Security To Group Table ----user和group的关系

groupName针对一组principals定义一种访问控制策略。principal是对SNMP实体的细

化，代表来自SNMP实体的一个具体用户操作。组中可有零个或多个元素(principal)。

securityName与msgSecurityModel构成复合关键字，至多确定一个组。于是，一个通

信受特定securityModel保护的特定principal只能属于一个组。

vacmSecurityToGroupTable用于存放组信息，其复合关键字为securityModel和

securityName，每个表项含有:

vacmSecurityModel

指定SNMPv3安全模型，比如USM

vacmSecurityName

代表一个principal的名字，格式与安全模型无关。对于USM，securityName就是

userName。

vacmGroupName

一个可读字符串，标识该表项所属组。

首先根据msgSecurityModel对SNMPv3报文进行鉴别、解密，获取securityName。然后

securityName与msgSecurityModel构成复合关键字，在表中匹配搜索。如果没有找到

匹配表项，拒绝访问并返回noSuchGroupName。否则返回相应的groupName，继续访问

控制检查。

☆ Access Table ------group和view的关系

vacmAccessTable存放各组的访问权限。为了确定是否允许访问，必须从表中选取表

项，根据其中相应的viewName进行后续访问控制检查。一个组可能对应着多种访问权

限，最终只选取最大安全化的那个表项。就是说，最高安全、最长contextPrefix匹

配的表项被选中。参看vacmAccessTable MIB描述了解更多信息。该表靠groupName、

contextPrefix、securityModel以及securityLevel进行索引，每个表项含有:

vacmGroupName

组名，有访问权限对应之。

vacmAccessContextMatch

如果设置为exact，contextName必须与vacmAccessContextPrefix精确匹配。如

果设置为prefix，contextName只需与vacmAccessContextPrefix前面几个字符匹

配即可。

vacmAccessContextPrefix

contextName将与之做比较

vacmAccessSecurityModel

为了获取这种访问权限而必须使用的securityModel

vacmAccessSecurityLevel

为了获取这种访问权限而必须使用的最小securityLevel。安全级别的顺序是

noAuthNoPriv < authNoPriv < authPriv

vacmAccessReadViewName

读访问所用的权威MIB viewName。如果该值为空串，表示没有任何活动视图被配

置成可读的。

vacmAccessWriteViewName

写访问所用的权威MIB viewName。如果该值为空串，表示没有任何活动视图被配

置成可写的。

vacmAccessNotifyViewName

notify访问所用的权威MIB viewName。如果该值为空串，表示没有任何活动视图

被配置成允许notify访问的。

检查该表时所用contextName是通过vacmContextTable检查的有效contextName。所用

groupName来自检查vacmSecurityToGroupTable时的返回值。securityModel来自消息

中的msgSecurityModel，securityLevel来自msgFlags。如果最终未匹配出一个访问

权限，则拒绝访问并返回noAccessEntry。

一旦匹配出一个访问权限，与之对应的适当的viewName将被选取出来，使用哪个

viewName根据PDU中SNMP操作决定。GET和NEXT操作使用vacmAccessReadViewName，

SET操作使用vacmAccessWriteViewName。TRAP操作使用vacmAccessNotifyViewName。

如果相应viewName未被配置，拒绝访问并返回noSuchView。

最后，如果匹配出一个访问权限也选取了适当的viewName，访问控制检查继续进行。

☆ View Tree Family Table ---view表

vacmViewTreeFamilyTable存放MIB views。一个MIB view由一颗OID子树和一个掩码

共同定义。

对于每个给定OID，当下列两点同时满足时，被认为属于一个特定MIB view:

1) OID至少与OID子树一样长

2) OID & 掩码 == OID子树 & 掩码

掩码是可配置的，如果它在测试中比OID或OID子树短，隐式认为不足部分为均为1。

所以，如果一个view subtree family的掩码为空(长度为零)，意味着这个掩码为全

1，对应一颗单一的OID子树。

例如，假设定义了如下一些MIB视图

(A) subtree: 1.3.6.1.2.1

mask: 1 1 1 1 1 1

(B) subtree: 1.3.6.1.2.1.1.1

mask: 1 1 1

(C) subtree: 1.3.6.1.2.1.2

mask: none

(D) subtree: 1.3.6.1.2.1.1

mask: 1 1 0 1 0 1 1

(E) subtree: 1.3.6.1.2.1.2

mask: 1 1 0 1 0

(F) subtree: 1.3.6.1.2.1

mask: 1 1 0 1 0 1

根据如上MIB view检查来自如下一些OID，以确定这些OID是否是否属于某个MIB视图。

由于掩码的存在，一个OID可能位于多个MIB视图，也可能不属于任何视图。

1.3.6.1.2.1 belongs to: A, F

1.2.6.1.2.1.1 belongs to: none of them

1.3.6.1.3.1 belongs to: F

1.3.4.1.4.1.2 belongs to: E, F

1.3.6.1.2.1.1.1.0 belongs to: A, B, D, F

1.3.6.1.2 belongs to: none of them

所有的MIB views都保存在vacmViewTreeFamilyTable中，该表靠viewName和OID子树

索引。注意，VACM MIB定义了一个旋锁vacmViewSpinLock，当多个SNMP Manager通过

VACM MIB修改该表时，就会用到vacmViewSpinLock。其用法与usmUserSpinLock的用

法是一样的，参看<<SNMP/MIB系列(12)--SNMPv3用户安全模型>>。该表中每个表项包

含:

vacmViewTreeFamilyViewName

一个字符串，MIB视图名

vacmViewTreeFamilySubtree

一颗OID子树，与vacmViewTreeFamilyMask一道定义一颗或多颗MIB视图子树

vacmViewTreeFamilyMask

掩码，与vacmViewTreeFamilySubtree一道定义一颗或多颗MIB视图子树

vacmViewTreeFamilyType

指明vacmViewTreeFamilySubtree与vacmViewTreeFamilyMask一道定义的MIB视图

子树是包含在MIB view内，还是排除在MIB view外。

这里用来索引vacmViewTreeFamilyTable的viewName来自vacmAccessTable中的权威视

图名。根据MIB view检查来自PDU的OID。如果OID不属于任何MIB view，拒绝访问并

返回notInView。反之，允许访问并返回accessAllowed。

☆ Overall Picture

VACM定义的访问控制算法稍微有点复杂、难于理解。下面这张流程图演示了前述四张

表各自的输入输出。securityModel与securityName决定who，contextName决定where，

securityModel与securityLevel决定how，viewType(比如read、write或notify)决定

why。被管理对象的OID决定what，被管理对象实例决定which。

--------------------------------------------------------------------------

☆ 小结

VACM概览使你理解如何针对SNMPv3报文进行访问控制管理。

配置每个VACM表时应该特别小心。一点微小的错误配置可能导致一个巨大的安全漏洞，

比如潜在允许对敏感数据进行非法访问。应该先在一个测试用网络环境中测试你的配

置，确认无误后再应用到实际网络环境中去。

SNMPv3框架确保了安全子系统和访问控制子系统的模块化，虽然目前USM与VACM分别

被用做安全模块以及访问控制模块，但你可以实现自己的安全模块以及访问控制模块。

将来IETF可能会更新这些模块。无论如何，SNMPv3框架确保新旧模块之间可以平滑过

渡。

☆ 参考资源

1) SNMPv3 - View Access Control Model by Eric Davis <ead@pobox.com>

2) SNMPv3: RFCs 2570, 2571, 2572, 2573, 2574, 2575

3) SNMP, SNMPv2, SNMPv3, and RMON 1 and 2 (Third Edition)

by William Stallings. Addison-Wesley Publishing Company.

4) Understanding SNMP MIBs by David Perkins and Evan McGinnis.

Prentice Hall PTR.