SNMP 华中师范大学计算机系

华中师范大学计算机系 钟义杰 陈晓明 谢双一 肖德宝

随着Internet在全球范围内的飞速增长,如何管理和监视这个全球网络成为越来越重

要的研究课题。在Internet的管理框架中,简单网络管理协议SNMP(Simple Network Man

agement Protocol)扮演了主要角色,它是TCP/IP协议家族的重要成员。本文在追踪国际

上有关网络管理最新动态的基础上,着重讨论SNMP v3的最新发展,包括SNMP的历史及发展

现状、SNMP v3的框架结构、SNMP v3的报文处理(Message Handling)和SNMP v3的PDU处

理(PDU Handling)。

SNMP的历史与现状

1. SNMP的诞生

早在十年前,负责Internet标准化工作的国际性组织IETF(Internet Engineering T

ask Force)意识到单靠人工是无法管理以爆炸速度增长的Internet。于是经过一番争论

,最终决定采用基于OSI的CMIP(Common Management Information Protocol)协议作为In

ternet的管理协议。为了让它适应基于TCP/IP的Internet,大量的繁琐的修改是必须的,

修改后的协议被称作CMOT(Common Management Over TCP/IP)。但CMOT的出台遥遥无期,

为了应急,IETF决定把现有的SGMP (Simple Gateway Monitoring Protocol)进一步开发

成一个临时的替代解决方案。这个在SGMP基础上开发的临时解决方案就是著名的SNMP,它

有以下特点:

· 简单性:顾名思义,SNMP非常简单,容易实现且成本低;

· 可伸缩性:SNMP可管理绝大部分符合Internet标准的设备;

· 扩展性:通过定义新的"被管理对象"即MIB,可以非常方便地扩展管理能力;

· 健壮性(Robust):即使在被管理设备发生严重错误时,也不会影响管理者的正常工

作。

SNMP出台后,在短短几年内得到了广大用户和厂商的支持。在实践中,它确实显示出

能管理绝大部分与Internet相连的设备的强大能力。现今的数据通信设备生产厂家都把

他们的产品缺省地兼容SNMP。由此可见,SNMP是在当时出现的恰当的解决方案(the righ

t solution at the right moment)。

无论是谁,即使是IETF自己也没有预料到SNMP会如此成功,以致于1992年取消了用CM

OT代替SNMP的原定计划,这正是"有心栽花花不发,无意插柳柳成荫"。SNMP已经成为Inte

rnet网络管理的最重要的标准。初版简单网络管理协议具体内容可参看以下的SNMP v1的

RFC文本:

RFC 1140 - IAB Official Protocol Standards

RFC 1147 - Tools for Monitoring and Debugging

TCP/IP

Internets and Interconnected Devices

[superceded by RFC 1470〗

RFC 1155 - Structure and Identification of Man-

agement

Information for TCP/IP based internets.

RFC 1156(H)- Management Information Base

Network

Management of TCP/IP based

internets

RFC 1157 - A Simple Network Management

Protocol

RFC 1158 - Management Information Base Network

Management of TCP/IP based

internets: MIB-II

RFC 1161 (H)- SNMP over OSI

RFC 1187 - Bulk Table Retrieval with the SNMP

RFC 1212 - Concise MIB Definitions

RFC 1213 - Management Information Base for

Network Management of

TCP/IP-based internets: MIB-II

RFC 1215(I)- A Convention for Defining Traps for

use with the SNMP

RFC 1224 - Techniques for Managing

Asynchronously-Generated Alerts

RFC 1270(I)- SNMP Communication Services

RFC 1303(I)- A Convention for Describing

SNMP-based Agents

RFC 1470(I)- A Network Management Tool Catalog

RFC 1298 - SNMP over IPX (已作废,见RFC 1420)

RFC 1418 - SNMP over OSI

RFC 1419 - SNMP over AppleTalk

RFC 1420 - SNMP over IPX (被RFC 1298代替) 注:H即historic历史的,已作废;I即

informational非正式的。

2.第二版简单网络管理协议SNMP v2

SNMP如同TCP/IP协议簇的其他协议一样,并没有考虑安全问题,因此许多用户和厂商

提出了修改初版SNMP、增加安全模块的要求。于是,IETF于1992年雄心勃勃地开始了SNM

Pv2的开发工作。它宣布计划中的第二版将有以下改进:

· 提供验证、加密和时间同步机制,提高安全性;

· GETBULK操作提供一次取回大量数据的能力,用更有效的方式传递管理信息;

· 建立一个层次化的管理体系。增加Manager-to-Manager之间的信息交换机制,从

而支持分布式的管理体系;增加中级(子)管理者(Middle-Level Manager or Sub-Manage

r),分担主管理者的任务,增加远程站点的局部自主性。

1993年,SNMP v2成为提案标准(proposed standard),即RFC14xx系列,此时有多个研

究小组开始建造SNMP v2原型系统的项目。在实施过程中,他们发现SNMP v2比人们原先的

预想复杂多了,失去了Simple的特点。1994年,当一个问题摆在IETF面前,即是否有足够多

的支持使SNMP v2升级成为草案标准(Draft Standard)时,一场关于SNMP v2复杂性的大讨

论轰轰烈烈地开始了。讨论的焦点集中在所谓的可管理的模型上面,即实现SNMP v2安全

模型的数据应该怎样被管理。在这个模型中,引入了"Parties"和"Context"的概念,它们

标识了在每个要发送的报文中应该包括的内容。在如何实现这个模型的问题上,出现了两

种不同意见,即通常所说的SNMP v2*和SNMP usec(SNMP v2u)。双方各持已见,任何一方都

没有足够的支持成为下一版标准,当开发计划的结束时间到来时,IETF只好把几乎所有与

安全相关的内容从SNMP v2中去掉,从而形成现在看到的最终的SNMP v2草案标准,即RFC 

19xx系列。SNMP v2中最初没有报文的定义,后来又出现了SNMP v2C (Community-based 

SNMP v2)作为SNMP v2的补充,它增加了v2的报文定义,但与v1的报文非常类似。

SNMP v2的开发最终还是失败了,IETF解散SNMP v2工作组,决定把统一SNMP v2*和SN

MP v2u的工作留给SNMPng (next generation)即现在的SNMP v3去做。

第二版简单网络管理协议具体内容可参看以下SNMP v2的RFC文档:

Historical Standard(历史的RFC14xx系列提案标准):

RFC 1441 - Introduction to SNMP v2

RFC 1442 - SMI For SNMP v2

RFC 1443 - Textual Conventions for SNMP v2

RFC 1444 - Conformance Statements for SNMP v2

RFC 1445 - Administrative Model for SNMP v2

RFC 1446 - Security Protocols for SNMP v2

RFC 1447 - Party MIB for SNMP v2

RFC 1448 - Protocol Operations for SNMP v2

RFC 1449 - Transport Mappings for SNMP v2

RFC 1450 - MIB for SNMP v2

RFC 1451 - Manager to Manger MIB

RFC 1452 - Coexistence between SNMP v1 and

SNMP v2

Draft Standard(RFC19xx系列草案标准):

RFC 1902 - SMI for SNMP v2

RFC 1903 - Textual Conventions for SNMP v2

RFC 1904 - Conformance Statements for SNMP v2

RFC 1905 - Protocol Operations for SNMP v2

RFC 1906 - Transport Mappings for SNMP v2

RFC 1907 - MIB for SNMP v2

RFC 1908 - Coexistence between SNMP v1

and SNMP v2

Experimental Standard(实验提案):

RFC 1901 - Introduction to Community-based

SNMP v2

RFC 1901 - An Administrative Infrastructure

for SNMP v2

RFC 1910 - User-based Security Model for

SNMP v2SNMP v3的框架结构

1.SNMP v3现状

尽管SNMP v2的开发结束了,但人们对安全的需求仍然存在。1997年4月,IETF成立了

SNMP v3工作组,决心完成v2未完成的事业。v3将统一v2*和v2u中的概念和技术思想,并不

考虑增加新的功能,而是回到SNMP v1 Simple的老路上,他们的目标是:

· 尽量利用现有的成果,尤其是v2*和v2u;

· 达到SET安全标准的要求;

· 尽可能简单;

· 支持大规模的网络;

· 定义一个可以长久使用的框架;

· 尽量使之沿着标准化的大道前进。

SNMP v3工作组的工作重点是安全、可管理的体系结构和远程配置。他们计划于199

8年4月提交所有的说明书给IESG以成为提案标准(proposed standard)。

2.SNMP v3的框架结构

SNMP v3的协议文本集框架如图1所示:

@@0236000.JPG;图1 SNMP v3的协议文本集@@

在图1中,标注了"*"的文本表示现在还未写,准备将来其它文本完成后才动笔,它们是

:Document Roadmap文本路标,用来指示文本变化状况;Applicability Statement适用性

声明,用来说明SNMP v3的适用环境;Coexistence and Transition共存与过渡,用来说明

SNMPv3如何与v1、v2及其它版本的共存与过渡问题。

在报文处理模块中,传输映射文本定义了SNMP报文在传输过程中的映射关系,它沿用

了v2的RFC1906,未作变动;报文处理与调度文本定义了报文格式和MIB模块,在其中SNMP 

v3定义了一种全新的报文格式以适应安全管理的需要。安全文本描述SNMP v3中的安全模

型以及这个模型所对付的安全威胁、它的目标、所用协议、用于安全管理的MIB模块,它

还允许报文级别的安全参数的远程配置,如密码的远程修改。

在PDU处理模块中,访问控制文本说明了如何决定是否允许访问一个被管对象,它还定

义了一个MIB块,用来远程配置访问控制的策略;协议操作文本定义了关于处理PDU的协议

操作;应用程序文本定义了支持这些协议操作的应用程序。

在信息模型这个模块中,SMI管理信息文本定义MIB的结构;正文规范文本定义供SMI使

用的新类型;一致性声明文本说明了可接受的最低限度的实现和实际中取得的实现。

在MIB模块中,SNMP v3可使用各种不同格式的MIB。信息模型和MIB模块实际还是使用

以前的协议文本,SNMP v3并未作任何改动。而真正改动体现在报文处理和PDU处理两大模

块中,它们大量采用SNMP v2历史版本RFC 14xx中的概念和技术思想。最终实现的SNMP v

3将只涉及到安全。其余部分仍沿用以前版本的定义(主要是RFC 19xx系列的SNMP v2)。

3.SNMP v3与安全管理

SNMP v3相对于v2(RFC 19xx系列)主要增加了安全特性。在网络管理系统中,常见的

安全威胁有如下几种类型:

· 修改信息(Modification of Information):某些非授权的SNMP实体可以对传输过

程中的由合法的SNMP实体产生的报文进行修改,用这样的方法来进行非授权的管理操作(

如修改某个对象的值),因此,协议应该能够验证收到的报文是否在传输过程中被修改过。

· 伪装(Masquerade):没有授权的用户可能冒充别的合法用户的身份识别(identit

y)来取得授权,因此,协议应该能够验证报文发送者的真实性。

· 报文流的改变(Message Stream Modification):由于SNMP是基于无连接的UDP之

上的,报文的延迟、重发以及顺序的改变都是可能的。某些破坏者可能会故意将报文延迟

,重发以及改变报文流的顺序以达到破坏目的。

· 泄密(Disclosure):破坏者可能会截获传输中的报文,窃取其中的保密内容。

要对付以上的安全威胁,实现安全的管理,通常经由以下两个阶段:

· 传送/接收报文的过程

· 在处理报文内容的过程

这两个阶段分别对应于报文处理和PDU处理模块,因此在SNMP v3中的安全是指在报文

级别实现的安全,而访问控制则对应于在协议操作级别实现的安全。由两者共同实现安全

的管理框架。

 

SNMP v3的报文处理(Message Handling)

1.报文处理

在SNMP v3中,通过对报文的处理来完成实体间的服务。它描述了这样几个子系统:调

度子系统、报文处理子系统、安全子系统。图1显示出了报文处理模块的结构框图。

@@0261700.JPG;图1 报文处理模块的结构@@

图1中,调度者(Dispatcher)是SNMP引擎中一个关键的部分,每个引擎中只有一个调度

者。它的功能是由它的3个模块所决定的,即调度PDU给各种应用程序;调度任务能够解决

多种报文版本的报文处理子系统;同时还定义了SNMP和传输之间的映射。对于这个子系统

来说,当它发送和接收SNMP报文时,收集关于SNMP报文的统计信息和被管对象中的engine

的行为,使它们能够访问远程实体。

报文处理子系统(message processing subsystem)是引擎的一部分。它定义了报文

格式和MIB模型。该子系统由不同的版本报文处理模块所组成,且这几种模块相互独立。

一个引擎可包含一个或多个报文处理模块。该系统与调度子系统相联系,用于支持发送和

接收SNMP报文的多版本。

由图1可以看出,发送一个报文,首先应用程序发出一个PDU,再加上构成一个报文的其

它数据单元,由调度模块将这个报文传送给所对应的版本报文处理模块进行处理,并且通

过安全模块的安全检查之后,报文就形成了。这样,通过传输映射将该报文发送出去。对

于接收过来的报文,大体上就是其逆过程。

2.报文格式

对待一个SNMP v3的报文,它有如下的格式:

@@0261701.JPG;表1@@

其中,msgVersion字段的值被设成snmp v3(3),用来标识SNMP的版本号为v3。而msgG

lobalData又由四部分组成:

S msgID(0～231-1):用在两个SNMP实体间来协同请求报文和回答该请求,以避免使用

其它任何未完成的变量作为msgID。这样可以防止重发。通常来说,设定msgID的值的策略

是用SNMP Engine Boots的低段作为msgID的高段,而msgID的低段则单调增长其值。

msgMaxsize(484～231-1):表示发送报文所能支持的最大报文长度。

msgFlags(一个字长):用来表示其发送的报文的安全等级(LoS)。

msgSecurityModel:由于v3的报文子系统支持用于提供安全服务的多个安全模块并发

存在,这个字段被发送者用来标识使用哪个安全模块来处理产生或接收的报文。

msgSecurityParameters(字串):用于在发送和接收报文中安全模块间的通信。该字

段的数据归安全模块所独用,并且其内容和格式由安全模式所定义。

msgData字段可以是一段明文或一段字串所组成的密码文。采取哪种方式取决于msg

Flags中所定义的安全等级。如果是一段明文,则由contextID、contextname和一段数据

所组成,contextID用来标识目标实体的引擎号,而contextname则被本地处理模块LPM(Lo

cal processing module)所使用。

在实际的应用中,报文常常有不同的类型,它们是:request、inform、Response、Tr

ap和Report,另外,在SNMP v3中,对于无论是接收还是发送报文时,通常使用sendPDUHand

le这样的句柄来完成子系统间的任务的处理。

3.报文的安全处理

上面谈到了对报文安全检查的处理。实际上,安全检查指的是两个不同的阶段,一是

对报文的传送和接收的安全考虑,另一个是指对报文内容处理时的安全。这两个阶段在S

NMP v3中由不同的模块所完成,前者是由常说的安全模块,即USM(user-base security m

odel)模块所处理,后者是由LPM模块(Local processing model)所处理。现在先谈谈基于

使用者模块的安全处理。

众所周知,在网络中存在着不同程度的安全威胁。基于这些安全威胁问题和相对于v

2等版本的兼容性,SNMP v3对于安全所提出的目标是:

S 保证每个接收的报文在网络的传送中不被修改,提供验证;

S 提供接收报文用户的身份证明;

S 防止泄密;

S 保证所接收的SNMP报文的当前性。

对于这些目标的设计,一种缺省的安全处理模块是USEC模块,它能够提供验证和加密

功能,目前,SNMP v3所默认的验证协议是HMAC-MD5和HMAC-SHA,加密协议是CBC-DES。为了

保证所传送的报文的有效性,常有三个过程,首先一个是由验证模块对报文进行的验证;由

时间模块对报文进行时戳处理;由保密模块进行报文加密。一个接收的报文进行安全检查

,示意图如图2所示:

@@0261702.JPG;图2 接收报文的安全检查示意图@@

图2中,三个过程的选择依赖于其安全等级(LoS),由图2可以看出,LoS有三个选择:

使用验证、时间同步和加密机制;

使用验证和时间同步机制;

不进行任何机制检查。

这三种情况的LoS由所处理的报文中msgFlags字段所定义选择。msgFlags最低bit位

为1表示实行验证机制,次低bit位为1表示实行加密机制。另外,这三个机制所实行的安全

服务功能着重点也不一样。图3示出了三种不同的机制情况。

@@0261703.JPG;图3 三种不同的机制情况@@

对于验证模块,它包含与验证有关的信息,否则为Null,利用算法计算出一个验证用的

密钥,在处理发送出去的报文时,指针移到报文中需要插入验证参数的地方,通过验证算法

查询到有关该用户姓名和引擎Id的密钥,填入该报文。这个密钥长为128bit。接收报文时

,首先将这个密钥从报文中提出来,然后重新生成一个新密钥,比较两个密钥是否相同从而

达到验证的目的。

对于时间同步模块,为了保证报文不被重发,延迟和改发,SNMP v3中常把涉及通信的

一方引擎认为是授权的SNMP 引擎.当一个报文包合一个期望得到回答的有效载荷时,报文

的接收者被认为是授权的引擎(如Get、Set),否则把其发送者认为不是授权的(如Trap、

Response)。在这种设定的基础上,每个SNMP 引擎包含三个object:SnmpEngineId,SnmpE

ngineBoots和SnmpEngineTime,每个引擎在它自已的实体中总是认为是授权的,而那些非

授权的引擎必须与那些授权的SNMP 引擎同步。SnmpEngineBoots和SnmpEngineTime结合

起来提供其引擎的时间指示,确保时间变量在其时间窗口中是当前时间。

对于加密模块,为了保证数据有效,需要加密算法,常常对其报文中的scoped-PDU进行

加密。并且通过一个秘密的值和时间变量(即SnmpEngineBoots和SnmpEngineTime)结合起

来创建一个加密密钥和一个初始化向量。这个秘密的值由那些授权的SNMP 引擎所共享。

三个模块具体工作过程如图4所示:

@@0261704.JPG;图4 三个模块具体工作过程@@

对于另外一个阶段,即LPM模块的安全处理,通过对contextname、groupname和LoS对

所管理的信息控制其访问权利。

经过这一系列的检查后,报文将返回调度模块,经过传输映射,将这报文形式映射到传

输层的格式。

SNMP v3的PDU处理(PDU Handling)

由SNMP v3框架所知,一个SNMP v3引擎由四个部分组成:一个调度者(dispatcher),报

文处理子系统,安全子系统和访问控制子系统。SNMP v3利用他们提供的服务来完成PDU的

操作,其中访问控制子系统负责检查某一个访问对于一个特定管理对象是否被允许,出于

以上的考虑,IETF的SNMP v3工作组对于访问控制子系统,设计了一个特别定义的模块:基

于视图的访问控制模块(view-based Access control Model1),该模块通常对一个SNMP管

理单元在处理SNMP的取回或修改请求报文申请时,进行访问控制,此外,当有一个证实报文

产生时(如InformRequest报文)和SNMP v2-Trap报文时,也必须进行访问控制。访问控制

模块为SNMP v3的应用程序定义了一组服务调用接口和元素,用来检查访问权限。

(1)本地配置数据库(LCD)中

为了对一个管理实体(SNMP entity)进行访问控制,就必须将其访问权限和策略放在

一个数据库中,通常将其放在SNMP引擎的本地配置数据库(LCD)中;另外,为了对本地设备

数据库(LCD)进行设置,把LCD与一个管理对象同等看待,并可被访问。

(2)访问控制模块元素(element of access control)

为了在基于视图访问控制模块中进行访问控制,定义了一系列元素以提供访问控制功

能,它们是组(Group)、安全级(securitylevel)、上下文(context)、MIB视图(MIBViews

)、访问控制策略(Access Policy)。

Groups:表示一组具有相同访问控制权限的Securityname集合。

Securitylevel:安全级,不同组对应于不同安全级,例如:noAuthnopriv(无验证无加

密),authnoPriv(验证但无加密),authPriv(验证且加密)。

context:一个上下文是指可被一个SNMP单元能访问的管理信息集合,管理信息的某一

项可对应不止一个上下文;而一个管理单元可以具有访问多个上下文的能力,在访问控制

模块中通过定义一个Vacm ContextTable来列出可用的上下文。

MIBViews:MIB视图,为了严格限制对管理信息限制的访问,将其访问限制在管理信息

中的某一部分,提出了MIB视图,由于MIB的树形结构,可以很便利地定义MIB视图,将其访问

限制在MIB的一个子树的访问。

Access Policy:访问策略,代表对管理信息的访问权限,分为read-view(从MIB中读一

个对象),write-view(向MIB中写一个对象),notify-view表示验证一个对象。

(3)过程元素(element of procedure)

访问控制模块通过对SNMP v3应用程序提交一组过程来调用基于控制模块,实现对访

问权限的检查。为了调用访问控制的服务,访问控制模块提供一个抽象服务接口给应用程

序。它的抽象服务原语定义如下:

statusInformation = ——成功或失败success or

errorIndication

isAccessAllowed(

securityModel

—— Security Model in use

securityName

—— principal who wants access

securityLevel

—— Level of Security

viewType

—— read, write, or notify view

contextName

—— context containing variable Name

variableName

—— OID for the managed object )

对于statusInformation,若成功返回值为AccessAllowed,失败返值则为errorIndi

cation。其中errorIndication值如下:

notInView

——表示有一个寻找的MIB视图访问

被拒绝或者Variable name被设

置,或者MIB需一个特别说明的

视图类型。

noSuchView ——对于找到MIB视图中特定察看类

型不在定义中。

noSuchContext ——在VacmContextTable中无此Con-

texname。

noGroupName ——在VacmSecurityGroupTable中无此

Group。

noAccessEntry ——因为在VacmAccess中设有对con-

textName、groupName、securiyModel

和securityLevel皆满足的条目。

otherError

——用来说明已产生错误。

(4)访问控制的实现

@@0261705.JPG;图5 作出访问控制判决的Vacm模块示意图@@

图5说明了Vacm模块如何作出访问控制判决的实现过程。

1)输入为:

(a)securityModel ——正在使用的安全模型;

(b)securityName ——需要进行访问的委托对象;

(c)securityLevel——安全级别;

(d)viewType——读、写或通知;

(e)contextName——包含变量名的上下文;

(f)variableName——被管对象的OID;

——由以下对象组成:

Sobject-type (m);

Sobject-instance (n)。

2)"who"通过(a)securityModel和(b)securityName作索引,在VacmSecurityToGroup

Table中找到相应条目即GroupName(x)。

3)"where"由context Name表示,"how"由securityModel和securityLevel表示,再加

上在(2)中找到的Groupname,联合起来在VacmAccessTable中找到一个单独保持3个MIB视

图的条目。

4)"Why"通过view Type(d)挑选合适MIB视图,即从(3)的结果中找出一个索引在Vacm

ViewFamilyTable中选择被view Name包括或排除了variable Name的条目。

5)"what"表示为管理数据类型,"which"表示为特定实例,皆为variable Name(f),将

其在(5)中所获条目中检查来决定是否允许查看MIB。

处理isAccess Allowed service 请求过程,过程与图5所示大致相同,只不过在出现

错误时需将一个表示该错误的值赋给errorIndication,并返回调用模块。

(5)安全上的考虑

当Vacm模块被调用时,应先确保调用模块在安全级的验证和加密均已通过。当从vie

w Family Tree表中增删一个条目,最好按Vacm view Family Table定义中描述条款做,以

免一个不预期的访问修改了表中单元。安全管理者在Vacm Access Table中最好将noAut

hnopriv从 authPriv和authnoPriv隔离开。

结束语

随着网络规模和复杂性的增加,网络管理更注重管理效率和管理安全,并朝着分布式

方向发展。第三版的简单网络管理协议SMMP v3正是适应这种客观需求而产生的,参加SN

MP v3工作组的成员大多是来自工业界的代表,如BMC Software、Cabletron、Cisco sys

tem、IBM、Secure Computing、SNMP Research、Trusted Information System等,这些

公司都是来自最接近用户的产业界、了解用户的需求,即在"简单"的基础上保证系统的安

全,因此,有理由预言,SNMP v3前景远大。为了让读者尽早地接触到具有里程碑意义的最

新版简单网络管理协议SNMP v3, 特撰此文介绍,以满足网络管理工作者的需要。