作者:Eric Davis <ead@pobox.com>
整理:小四 <scz@nsfocus.com>
主页:http://www.nsfocus.com
日期:2003-01-03
标题: SNMP/MIB系列(13)--SNMPv3视图访问控制模型
原作: <<SNMPv3 - View Access Control Model>>
作者: Eric Davis <ead@pobox.com>
翻译: NSFocus Security Team <security@nsfocus.com>
主页: http://www.nsfocus.com
维护:
日期: 2002-05-09 23:21
更新: 2002-05-10 23:37
--------------------------------------------------------------------------
目录:
--------------------------------------------------------------------------
☆ SNMPv3视图访问控制模型
本文是介绍SNMPv3新安全特性的第二篇。前面我们介绍了基于用户的安全模型USM以
及如何完成SNMPv3报文的鉴别、加密、解密。这次我们介绍基于视图的访问控制模型
VACM(View-based Access Control Model),RFC 2575定义了VACM,它提供对MIB的访
问控制。
一个SNMP实体的访问控制子系统负责检查对指定MIB的某种类型的访问是否被允许。
你将会看到,VACM引入的概念相当复杂、混乱。SNMPv1和SNMPv2c采用community
string来划分MIB范围、确定访问权限等等。而VACM允许更加严谨的动态的访问控制
模型,易于管理员配置。
☆ SNMPv3报文格式
--------------------------------------------------------------------------
authentication
--------------------------------------------------------------------------
SNMPv3的报文格式变得适合使用USM这样的安全模型以及VACM这样的访问控制模型。
msgVersion
msgID
msgMaxSize
msgFlags
msgSecurityModel
msgSecurityParameters
scopedPDU
☆ VACM参数
VACM在进行访问控制时会用到msgFlags、msgSecurityModel以及scopedPDU域。
msgFlags用于确定消息的安全级别,比如noAuthNoPriv、authNoPriv或authPriv。
msgSecurityModel指明消息所用安全模型。scopedPDU包含上下文以及被管理对象的
OIDs,具体有如下域:
contextEngineID
contextName
PDU(数据)
这三个参数被传递给isAccessAllowed()函数,该函数是VACM的唯一入口点,在此决
定访问是否被允许。PDU中每一个变量都要接受检查,如果其中一个变量不可访问,
就向主调者返回错误,处理将终止。VACM定义了四个表,每个表负责不同方面的访问
控制,它们均可通过VACM MIB远程修改。
☆ Context Table
这里所谓的上下文实际定义了一个SNMP实体所能访问的被管理对象集合。换言之,用
一个名字代表被管理对象子集。可能一个对象位于多个上下文中,可能一个SNMP实体
被允许访问多个上下文。vacmContextTable用于存放所有本地可访问上下文,其关键
字为contextName,每个表项含有:
vacmContextName
☆ Security To Group Table
groupName针对一组principals定义一种访问控制策略。principal是对SNMP实体的细
化,代表来自SNMP实体的一个具体用户操作。组中可有零个或多个元素(principal)。
securityName与msgSecurityModel构成复合关键字,至多确定一个组。于是,一个通
信受特定securityModel保护的特定principal只能属于一个组。
vacmSecurityToGroupTable
securityName,每个表项含有:
vacmSecurityModel
vacmSecurityName
vacmGroupName
首先根据msgSecurityModel对SNMPv3报文进行鉴别、解密,获取securityName。然后
securityName与msgSecurityModel构成复合关键字,在表中匹配搜索。如果没有找到
匹配表项,拒绝访问并返回noSuchGroupName。否则返回相应的groupName,继续访问
控制检查。
☆ Access Table
vacmAccessTable存放各组的访问权限。为了确定是否允许访问,必须从表中选取表
项,根据其中相应的viewName进行后续访问控制检查。一个组可能对应着多种访问权
限,最终只选取最大安全化的那个表项。就是说,最高安全、最长contextPrefix匹
配的表项被选中。参看vacmAccessTable MIB描述了解更多信息。该表靠groupName、
contextPrefix、securityModel以及securityLevel进行索引,每个表项含有:
vacmGroupName
vacmAccessContextMatch
vacmAccessContextPrefix
vacmAccessSecurityModel
vacmAccessSecurityLevel
vacmAccessReadViewName
vacmAccessWriteViewName
vacmAccessNotifyViewName
检查该表时所用contextName是通过vacmContextTable检查的有效contextName。所用
groupName来自检查vacmSecurityToGroupTable
中的msgSecurityModel,securityLevel来自msgFlags。如果最终未匹配出一个访问
权限,则拒绝访问并返回noAccessEntry。
一旦匹配出一个访问权限,与之对应的适当的viewName将被选取出来,使用哪个
viewName根据PDU中SNMP操作决定。GET和NEXT操作使用vacmAccessReadViewName,
SET操作使用vacmAccessWriteViewName。TRAP操作使用vacmAccessNotifyViewName
如果相应viewName未被配置,拒绝访问并返回noSuchView。
最后,如果匹配出一个访问权限也选取了适当的viewName,访问控制检查继续进行。
☆ View Tree Family Table
vacmViewTreeFamilyTable存放MIB views。一个MIB view由一颗OID子树和一个掩码
共同定义。
对于每个给定OID,当下列两点同时满足时,被认为属于一个特定MIB view:
1) OID至少与OID子树一样长
2) OID & 掩码 == OID子树 & 掩码
掩码是可配置的,如果它在测试中比OID或OID子树短,隐式认为不足部分为均为1。
所以,如果一个view subtree family的掩码为空(长度为零),意味着这个掩码为全
1,对应一颗单一的OID子树。
例如,假设定义了如下一些MIB视图
根据如上MIB view检查来自如下一些OID,以确定这些OID是否是否属于某个MIB视图。
由于掩码的存在,一个OID可能位于多个MIB视图,也可能不属于任何视图。
所有的MIB views都保存在vacmViewTreeFamilyTable中,该表靠viewName和OID子树
索引。注意,VACM MIB定义了一个旋锁vacmViewSpinLock,当多个SNMP Manager通过
VACM MIB修改该表时,就会用到vacmViewSpinLock。其用法与usmUserSpinLock的用
法是一样的,参看<<SNMP/MIB系列(12)--SNMPv3用户安全模型>>。该表中每个表项包
含:
vacmViewTreeFamilyViewNa
vacmViewTreeFamilySubtre
vacmViewTreeFamilyMask
vacmViewTreeFamilyType
这里用来索引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。
--------------------------------------------------------------------------
securityModel
--------------------------------------------------------------------------
☆ 小结
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)
4) Understanding SNMP MIBs by David Perkins and Evan McGinnis.