网络管理 SNMP [转]

自：http://home.xjtu.edu.cn/teacher/yager/translation.html

8．1 什么是网络管理

结束了本课前七章 的学习后，我们明白了网络是由很多复杂的、相互作用的硬件和软件组成的---从链路、桥、路由器、主机以及其他组成网络物理组件的设备，到许许多多控制和 协调这些设备的协议（在硬件和软件中的）。当成百甚至上千的这些组件组织在一起而形成网络的时候，下列事件就不足为奇了：这些组件会否偶尔发生故障，网络 元素会否被错误地配置，网络资源会否被超负荷使用，甚至网络组件简单地“坏掉”（例如，一条光缆会否被切断，一听苏打水会否洒落在路由器上）。网络管理员 的工作就是使网络“正常运转”，管理员必须要对这些灾祸做出反应（最好是能避免）。有着潜在的成千上万的网络组件分布于一个广泛的区域，网络运作中心（NOC）的网络管理员很显然需要工具来监视、管理和控制网络。在这一章里，我们将考察网络管理员完成这一工作所使用的体系结构、协议以及信息库等。

在深入网络管理本身之前，我们先来考虑一些“现实世界”中没有网络的情形，这些可作为例证的复杂系统中包含了许许多多相互作用的组件，必须由一位管理员对这些组件进行监视、管理和控制。发电厂（至少象大众媒体在诸如电影《中国症》 里描述的一样）有一个控制室，各种仪表、量具以及指示灯监控着远端阀门、管道、容器和其他工厂组件的状态（温度、压力、流量）。这些监控设备让操作员能监 控工厂的许多组件，还可能在出现麻烦的时候对操作员发出警告（如著名的红色警戒闪烁灯）。工厂操作员就能采取行动从而控制这些组件。类似地，飞机驾驶仓让 飞行员能监视和控制组成飞机的许多组件。在这两个例子里，“管理员”监视远端设备并分析数据，确保它们可操作并且在已经规定的限度内操作（例如，一个核电站的心线融化不是紧迫的，或者飞机没有耗尽燃油），对系统内部或者系统环境的改变做出相应的调整从而相对地控制系统，并且积极地管理系统（例如，通过探测趋势或者反常行为，以允许在严重问题出现之前做出行动）。类似的意义下，网络管理员能监视、管理和控制她/他所委托的系统。

在网络发展的早些时候，那时的计算机网络更大程度上是研究性的，而不是现在被每天数以万记的人所使用的关键基础设施，“网络管理”是没有听说过的事情。如果谁遇到网络问题，他可能会运行一系列的ping命令来对问题发生的源头定位，修改系统设置，然后重新启动硬件或者软件，或者给远端的同事打电话叫他这样做。（RFC 789记载了这方面非常可读的讨论 1980年10月27日，ARPAnet的第一起重大“瘫痪”，那时候还远远没有网络管理工具的出现。）随着公众的因特网和私有的局域网从小网络成长为巨大的全球化基础设施，更为系统地管理网络中这些众多的硬件和软件组件也日益成为越来越重要的需要了。

为了使我们对网络管理的学习更加生动，我们从一个简单的例子开始。图8.1展现了一个小的网络，由三个路由器和一些主机以及服务器组成。即使是在如此简单的一个网络中，许多情形下网络管理员还是会极大地需要从合适的网络管理工具得益：

·主机或路由器的网络接口卡错误。通过合适的网络管理工具，一个网络实体（例如，路由器A）可能报告给网络管理员它的一个接口发生了故障。（这当然比愤怒的用户给NOC打 电话说网络连接发生故障要更为可取！）通过事先探测接口的问题并且在接口卡失效之前重置它，一名积极地监控网络和分析网络流量的网络管理员可能真正给就要 被激怒的用户以很深刻的印象。可以这样做到，例如，管理员注意到将要发生错误的接口所送出的帧发生校验和错误明显增多。

·主机监视。这里，网络管理员或许周期性地检查是否所有的网络主机都正常运行并且可控。再一次地，网络管理员或许能通过于用户报告之前对问题（主机故障）的积极回应，从而给网络用户以深刻的印象。

·监视流量以帮助分配资源。 一名网络管理员可能会监视源到端的流量模式并且注意，例如，通过交换各局域网段之间的服务器，跨多个局域网的流量能大大减少。想象一下，不增加新的设备花 费而能更好地工作，对大家来说是多么高兴（尤其是那些高级管理员们）。类似地，通过监视连接利用率，一名网络管理员会知道一个局域网段，或者连向外部的连 接是否过载了，因此应该禁止掉高带宽的连接（令人吃惊地，增加的花费）。为了避免高带宽的连接带来严重的冲突，网络管理员可能也会自动地被告知，某个连接 上的冲突水平超过了给定的阈值。

·检测路由表中的快速变化。路由突变 路由表中频繁的改变 可能预示着路由的不稳定性以及不正确的路由配置。当然，不恰当地配置了路由器的网络管理员希望他/她在网络崩溃之前能自己发现错误。

·监视SLA。随着SLA（服务级协商）的来临 定义了特殊工作规律和网络供应商遵守这些规律的可接受水平 过去的几年里，人们对流量监视的兴趣大大地增加了 [Laren 1997 ; Huston 1999a]。Uunet以及AT&T 是众多网络供应商中对其客户认可SLA的两家 [UUNet 1999 ; AT&T SLA 1998]。这些SLA包括服务获得（中断期）、延迟、总量以及中断通知需要。很清楚地，如果网络供应商同其客户之间的服务协议中包含了工作效应考核，那么测量和管理工作对网络管理员来说就显得非常重要。

·入侵检测。一名网络管理员希望适时知道网络流量来自于或者将流向一个可疑的源地址（例如，主机或者端口号）。类似地，一名网络管理员想要检测（并且多数情况下是过滤掉）某些具有已知攻击特征形式的数据包（例如，源地址路由包，或者大量的指向某个主机的SYN包）。

国际标准化组织（ISO）已经建立了一个网络管理模型，这一模型使得上述有趣的情形能被置于一个更为结构化的框架中。其中定义了网络管理的五个方面：

·工作情况管理。工作情况管理的目标是定量、测量、报告、分析并且控制不同网络组件的工作情况（例如，利用率，总量）。这些组件既包括独立设备（例如，链路、路由器以及主机），也包括端到端的抽象概念，例如通过网络的一条路径。我们不久将会看到，诸如简单网络管理协议（SNMP）[RFC 2570]这样的协议标准将在因特网工作情况管理中起到重要的作用。

·差错管理。差错 管理的目标是记载、检测以及回应网络中的错误情况。差错管理和工作情况管理之间的界限是非常模糊的。我们可以把差错管理看作网络错误转化的立即处理（例 如，连接、主机或者路由器硬件或软件中断），而工作情况管理则是在更长远的意义上，面对变化的流量需要以及偶尔的网络设备故障，提供工作情况可接受的水 平。与工作情况管理一样，SNMP协议也在差错管理中扮演着中心的角色。

·配置管理。配置管理允许网络管理员跟踪所管理的网络上的设备，并且配置这些设备的硬件和软件。

·帐户管理。帐户管理允许网络管理员指定、记录并且控制用户和网络资源的设备访问权限。使用定额、基于使用的分配以及资源访问优先权的分配都在帐户管理下。

·安全管理。安全管理的目标是根据某个已经定义好的策略来控制网络资源的访问权限。我们在7.5节中所学习到的密钥分发中心和认证中心都是安全管理的组件。我们将在8.4节中学习到运用防火墙来监视和控制指向某个网络的外部访问，这是另一个关键的组件。

在这一章中，我们将仅仅涉猎到网络管理的初步知识。我们的焦点将有意识地缩小 我们将仅仅考察网络管理的基础结构 总体的体系结构、网络管理协议以及网络管理员能“使网络正常运行”的信息基础。我们将不涉及网络管理员的做出决定的过程，而他必须计划、分析并且对传送到NOC的管理信息做回应。在这一领域中有许多论题，诸如差错识别和管理 [Katzela 1995 ; Medhi 1997]、主动异常检测 [Thottan 1998]、报警关联 [Jakobson 1993]等，更多的还在考虑中。我们也不会涉及服务管理的更为宽泛的主题 [Saydam 1996] 诸如带宽、服务容量以及其他满足企业任务指定服务需求的计算/通信资源的提供。在后一领域，TMN [Glitho 1995 ; Sidor 1998]和TINA [Hamada 1997]两个标准是就这一领域而发布的更大并且更为达成一致的标准（因而有争议地认为它们更拖沓）。例如，TINA被描述为“涵盖了服务和资源的管理以及部分分布式进程环境的公共目标、原理和概念的集合”[Hamada 1997]。清楚地，所有这些主题都可以独立成章，并且需要花费我们很多远离计算机网络技术领域的研究。所以，如前文所述，我们更为谦逊的目标是涉猎一些重要的“nuts and bolts”基础结构，通过它，网络管理员使信息比特平稳地流动。

一个经常问的问题是“什么是网络管理？”我们上面的讨论已经涉及了网络管理的需要，并且列举了网络管理的一些应用。我们将用一个单句（虽然是一个相当长的冗长的句子）来总结这一节的内容，给出网络管理的定义 [Saydam 1996]：

“网络管理包括了硬件、软件以及人力元素的分配、集成和协调，以期监视、测试、轮询、配置、分析、评估和控制网络及其元素资源，达到实时、最优化工作以及合理代价下的服务质量需求。”

很绕口，但却是很奏效的定义。在以下的几节中，我们将为这一好似光骨头一般的网络管理定义加入一些肉来。

8．2 　网络管理基础结构

我们已经在前面几 接里看到，网络管理需要有能力去“监视、测试、登记、配置、……和控制”网络中的硬件和软件组件。因为网络设备是分布式的，这就在最低限度上需要网络有能 力能从远端实体得到数据（例如，为了达到监视的目的）并且有能力实施远端实体的改变（例如，为了控制）。一个人类的模拟将证明有用于理解网络管理基础结 构。

设想你是一个拥有全世界范围分支 机构的大组织首领。确保你组织里这些分支机构正常地运作是你的工作。你会怎么做？最少，你要定期地从你的分支机构获得数据，其形式可能是报告以及各种各样 的活动量、产量和预算的测量。你会偶尔（但不是经常）被明确地告知分支机构出现了问题；想爬上公司高位（或许是想得到你的职位）的分支机构的经理可能会发 送给你毫无用处的报告，展现出事情在他/她 那里是如何如何的顺利。你从你收到的报告中筛选，希望能在任何地方都找到顺利运作的记录，但是毫无疑问地发现了很多值得你注意的问题。你可能同出问题的分 支机构经理建立一个单独的对话，为了理解问题而收集更多的数据，然后向那位经理下达一个执行命令（“立即做这样的更改！”）。

这一非常普通的人类世界里的情形所隐含的意义就是一个控制组织的基础结构 老板（你）、被控制的远端机构（分支机构办公室）、你的远端代理（分支机构经理）、通信协议（为了传送标准的报告和数据，以及单独对话）和数据（报告内容和活动量、产量、预算的测量值）。每一个人类组织管理的这些部分都在网络管理里有相应的对等物。

网络管理系统的体系结构在概念上和简单的人类组织管理是一致的。网络管理领域有其自身的术语，描述了网络管理体系结构的不同部分，这里我们将采纳这些术语。如图8.2所示，一个网络管理体系结构中有三个重要的组件：管理实体（我们上一个例子中的老板 你）、被管理设备（分支机构）以及网络管理协议。

管理实体是一个应用程序，典型地是一个在网络运作中心（NOC）集中起来的网络管理所运行的循环程序，及其操纵者。管理实体是网络管理活动的集中点，它控制收集、处理、分析，并且/或者显示网络管理数据。正是在这里，控制网络行为的指令被驱动；也正是在这里，人类的网络管理员同网络设备打交道。

一个被管理设备是被管理的网络中安置的网络装备（包括其软件）的一部分。在人类组织管理里就是那些分支机构。被管理设备可能是主机、路由器、桥、集线器、打印机或者调制解调设备。在一个被管理的设备里，可能会有很多所谓的被管理对象。这些被管理的对象是被管理设备中真正的硬件部分（例如，一块网络接口卡），以及这些硬件和软件的配置参数设定（例如，一个跨域路由协议，RIP）。在我们人类组织管理的例子里，被管理对象可能会是分支机构里的某个部门。这些被管理对象的部分信息被收集到一个管理信息库（MIB）中；我们将会看到这些信息值对管理实体而言是可以得到的（许多情况下还是可以设置的）。在我们的人类组织管理的例子里，MIB对应的是那些在分支机构和公司本部之间交换的大量数据（活动量、产量、预算的测量值，而最后一项是能被管理实体设定的！）。我们将在8.3节学习MIB的详细知识。最后，同样安置在每一个被管理设备中的是网络管理代理，它是被管理设备中运行的一个进程，负责与管理实体通信，并且依照管理实体的命令和控制对被管理设备实施本地操作。网络管理代理在人类组织管理例子里是分支机构的经理。

网络管理体系结构的第三个部分是网络管理协议。 这一协议在管理实体和被管理设备之间运行，允许管理实体查询被管理设备的状态并通过其代理间接地对这些设备实施操作。当意外事件（例如组件错误或者强行超 过工作值）发生时，代理可以使用网络管理协议来通知管理实体。注意到，网络管理协议自己本身并不能管理网络，这一点很重要。实际上，它提供了一个网络管理 员可以用来管理（“监视、测试、登记、配置、分析、评估和控制”）网络的工具。这是一个细微的，但是重要的区分。

尽管网络管理的基础结构在概念上很简单，人们却常常陷入网络管理语言词汇的泥沼：“管理实体”、“被管理设备”、“管理代理”和“管理信息库”。例如，在网络管理语言词汇里，简单的主机监视这一情形，“管理代理”位于“被管理设备”并且定期地被“管理实体”查询 简单的一个概念，但是语言上却非常拗口。所幸，保持人类管理组织的例子并且把它平行地同网络管理比较，会在我们本章的进行中很有帮助。

我们上面对网络管理体系结构的讨论很普遍，并且广泛地运用于许多网络管理标准以及近几年提出的尝试中。网络管理标准在二十世纪八十年代开始成熟，出现了最为重要的[Miller 1997 ; Subramanian 2000]两个标准OSI CMISE/CMIP（the Common Management Information Service Element / Common Management Information Protocol）[Piscatello 1993 ; Stallings 19993 ; Glitho 1998] 和因特网SNMP（Simple Network-Management Protocol）[Stallings 1993 ; RFC 2570, Stallings 1999 ; Rose 1996] （原文误为the Common Management Service Element，译者注）。两者都是独立地为指定提供产品和网络而设计的。因为SNMP很快地设计出来了，并且在最需要网络管理的时候进行了部署，SNMP得到了广泛的使用和接受。今天，SNMP已经成为应用和部署最广泛的网络管理框架。我们将在后续小节中详细叙述SNMP。

8．3 　因特网网络管理框架

与其名字SNMP（简单网络协议）所暗示的相反，因特网网络管理是非常复杂的，不仅仅是简单的一个在管理实体和其代理之间移动管理数据的协议，它已经复杂到远远不能用“简单”二字来表达了。当前的因特网标准管理框架可以追溯到简单网关监视协议，SGMP [RFC 1028]。SGMP是由一群大学网络研究者、使用者和管理者设计的，他们使用SGMP的经验使得他们仅仅用了几个月的时间就完成了设计、实现和部署SNMP [Lynch 1993] 这比今天那些持续很久的标准化进程要快很多。从那时候起，SNMP从SNMP v1 发展到SNMP v2，至今的SNMP v3 [RFC 2507]，于1999年四月发布。

描述任何网络管理的框架时，不可避免地要阐述如下问题：

·什么（从语义学观点来看）是被监视的？网络管理员实施的控制操作又是什么形式？

·被报告和/或被交换的信息的具体形式是什么？

·交换这些信息的通信协议是什么？

回顾我们前几节的人类组织管理模 型。老板和分支机构需要在用于报告分支机构状况的活动量、产量、预算的测量值上达成一致。类似地，他们需要在老板的行动上达成一致（例如，裁减预算、命令 分支机构经理改变公司某些方面的运作，或者炒掉职员然后关闭分支机构）。在更底层的细节上，他们需要在报告这些数据的格式上达成一致。例如，用什么流通货 币（美圆，欧圆？）在报告预算？用什么单位来测量产量？尽管这些是不重要的细节，它们仍然必须被双方同意。最后，信息在总部和分支机构之间传送的方式 （即，他们的通信协议）必须指定。

因特网网络管理框架涉及了上面提出的问题。这一框架包含如下四个部分：

·网络管理对象的定义，即MIB对象。在因特网网络管理框架中，管理信息是以被管理对象的集合来表达的，这些对象组成了虚拟的信息储存，即管理信息库（MIB）。一个MIB对象或许是一个计数器，如记录路由器中所丢弃的含错误IP报文头的IP数据包数目；或者以太网接口卡中记录载波错误；描述性信息，例如DNS服务器上运行的软件版本；状态信息，例如一个特定的设备在功能上是否正确；或协议指定的信息，例如通往目标的指定路由路径。MIB对象就这样定义由被管理结点维护的管理信息。相关的MIB对象由所谓的MIB模型集中在一起。在我们人类组织管理的模型中的MIB定义的是分支机构和总部之间传送的信息。

·数据定义语言，被称做SMI（管理信息结构），它定义了数据类型，一个对象模型，和改写管理信息的规则。MIB对象在这一数据定义语言中被指定。在我们人类组织管理模型中的SMI是用来定义所交换信息的具体格式。

·协议，SNMP，用来在管理实体和代理之间传送信息和命令，代理置于被管理网络设备中代表该管理实体执行命令。

·安全和管理能力。这些能力的附加表现在SNMP v3对SNMP v2的主要提升上。

因特网网络管理体系结构就是这样设计和建模的，采用协议独立的数据定义语言以及MIB，并且使用MIB独立的协议。有趣的是，这一建模的体系结构最初是用来方便地把一个基于SNMP的网络管理转变成国际标准化组织（ISO）定义的网络管理框架，后一网络管理体系结构是SNMP最初的竞争者 这一转变当然没有发生。事后，SNMP的设计模型允许通过三个修改演化，独立地改动上面所讨论的SNMP四个主要部分。很明显，为这一模型作出的决定是正确的，即使是为了错误的原因！

在随后的四个小节中，我们将更详细地讨论因特网网络管理框架中的四个主要部件。

8.3.1 管理信息结构：SMI

管理信息结构，SMI（这一网络管理框架的命名很古怪，从它的名字根本得不到其功能的提示），是用来定义置于被管理网络实体中的管理信息的语言。这样一个定义语言需要确保网络管理数据的语法和语义是良定义的并且不是模棱两可的。注意，SMI并不定义被管理网络实体中数据的特定实例，而是用来指定这一信息的语言。描述SNMP v3中SMI的文档（非常令人感到混淆的是，这一版本是SMI v2）有 [RFC 2578 ; RFC 2579 ; RFC 2580]。我们以自底向上的方法来考察一下SMI，从SMI的基础数据类型开始。我们将看到被管理对象是如何在SMI里描述的，相关的被管理对象是如何组成模型的。

SMI基础数据类型

RFC 2578指定了SMI MIB模型定义语言中的基本数据类型。尽管SMI是基于ASN.1（抽象语法标记）[ISO 1987 ; ISO X..680 1998]对象定义语言的（参见8.4节），还是加入了足够的SMI指定数据类型，故SMI应该被看作一个数据定义语言。RFC 2578定义的11种基本数据类型如表8.1所示。除了这些梯状对象之外，也可以加入表状结构，在MIB对象的有序集合中使用SEQUENCE OF构造；详见RFC 2578。

SMI高级结构

除了这些基础的数据类型以外，SMI数据定义语言同样提供了高级语言结构。

OBJECT-TYPE构造是用来指定被管理对象的数据类型、状态以及语义的。从集合意义上讲，这些被管理对象包含存在于网络管理核心的管理数据。在不同的因特网RFC里，将近有10,000种已定义的对象 [RFC 2570]。OBJECT-TYPE构造有四个子句。SYNTAX子句定义与对象相关的指定数据类型。MAX-ACCESS子句指定被管理对象是否能被读、写、创建或者将其值包含在一个声明中。STATUS子句表示对象定义是否是当前的并且有效的，作废的（这种情况下该对象不应该被实现，其定义只包含历史性的目的）还是不推荐的（作废了，但是是可以同老的实现相互操作）。DESCRIPTION子句包含了对该对象的人类可读文本定义，这一“文档”记录了被管理对象的目的，并且应该提供需要实现被管理对象的所有语义信息。

作为OBJECT-TYPE构造的一个例子，考虑RFC 2011里ipInDelivers对象定义。这一对象定义了一个32位的计数器，用于跟踪被管理结点接收并且成功转发到上层协议的IP报文数目。这一定义的最后一行和该对象的名字有关，我们将在后续一节中讨论这一主题。

ipInDelivers OBJECT-TYPE

SYNTAX Counter32

MAX-ACCESS read-only

STATUS current

DESCRIPTION

“The total number of input datagrams

successfully delivered to IP user-protocols

(including ICMP).”

: : = { ip 9 }

MODULE-IDENTITY构造允许相关的对象组织在一个“模型”里。例如，RFC 2011指定的MIB模型定义了被管理对象（包括ipInDelivers），实现管理因特网协议（IP）和相关的因特网消息控制协议（ICMP）。RFC 2012 指定了TCP的MIB模型，RFC 2013指定了UDP的MIB模型。RFC 2021定义了RMON远程监视的MIB模型。除了包含模型里被管理对象的OBJECT-TYPE定义外，MODULE-IDENTITY构造还包含若干子句，以说明该模型作者的联系信息，最后一次更新的日期，修改历史，以及该模型的文本描述。作为例子，考虑管理IP协议的模型定义：

ipMIB MODULE-IDENTITY

LAST-UPDATE “9411010000z”

ORGANIZATION “IETF SNMPv2 Working Group”

CONTACT-INFO

“ Keith McCloghrie

Postal: Cisco Systems, Inc.

170 West Tasman Drive

San Jose, CA 95134-1706

US

Phone: +1 408 526 5260

E-mail: [email protected]”

DESCRIPTION

“The MIB module for managing IP and ICMP

implementations, but excluding their

management of IP routes.”

REVISION “9103310000z”

DESCRIPTION

“The initial revision of this MIB module was

part of MIB-II.”

: : = { mib-2 48 }

NOTIFICATION-TYPE构造是用来指定与“SNMP v2 - Trap”和“InformationRequest”消息有关的信息，后者是由代理或管理实体产生的；见8.3.3小节。这一信息包含了一个文本的DESCRIPTION，描述该消息发送的时间，以及消息产生时候需要包含的一系列值；详见RFC 2578。

MODULE-COMPLIANCE构造定义了代理必须实现的模型中被管理对象的集合。

AGENT-CAPABILITIES构造指定了代理的能力，并且和对象及事件发布定义相关。

8.3.2 管理信息库：MIB

如前所述，管理信息库，MIB，可以被认为是一个虚拟的信息储存，它把握的被管理对象的值在集合意义上表现着当前网络“状态”。这些值可能被查询并且/或者被设置，管理实体发送SNMP消息到被管理结点中的代理，并由代理代表管理实体执行命令。被管理对象由前面讨论过的OBJECT-TYPE SMI构造，并用MOUDLE-IDENTITY构造加入到MIB模型中。

IETF还在忙着标准化与路由器、主机和其他网络设备相关的MIB模型。它包括了某一特定硬件的基本标识数据，和该设备所在网络的接口及协议的管理信息。随着SNMP v3的发布（1999年中），共有接近100种基于标准的MIB模型和更大数量的提供者指定（私有的）MIB模型。和所有这些标准一样，IETF需要一种方法来标识和命名标准化的模型，模型中指定的被管理对象也同样。IETF并没有从新刻画，而是采纳了一个已标准化并且被国际标准化组织（ISO）付诸实施的对象标识（命名）框架。就如同许多标准体的情形一样，ISO有其标准化对象标识框架的“伟大计划” 用来标识网络中所有可能标准化的对象（例如，数据格式、协议或者一段信息），并且做到与网络标准组织（例如，因特网IETF、ISO、IEEE或ANSI）、设备制造商或网络用户无关。一个事实上很宏大的目标！ISO采纳的对象标识框架是ASN.1（抽象语法标记）[ISO 1987 ; ISO X.680 1998] 对象定义语言的一部分，我们将在8.4节中探讨。标准化的MIB模型有其自身的*****。

如图8.3所示，对象得名于ISO命名框架的层次结构。注意，每一个树分支点都同时有一个名称和一个数字（圆括弧中表示）；由于标识树中有名称或数字序列指定点到树根的路径，树中的每一个点都可以这样被标识化。一个有趣但不完整的非官方文献，描述基于网络利用的遍历对象标识树（使用志愿者提供的树分支点信息），可以在[Alvestrand 1997]中找到。

这一层次的顶部是国际标准化组织（ISO）和国际电信联盟电信标准部（ITU-T）这样两大使用ASN.1的标准组织，以及这两家组织结合在一起的一个树分支。在ISO这条分支下，我们可以找到所有ISO标准（1.0）入口，以及不同ISO成员国家（1.2）标准体发布的标准入口。尽管没有在图8.3中表示，在（ISO ISO-成员体，也称做1.2）下我们可以找到USA（1.2.840），其下是一系列的IEEE、ANSI和公司指定的标准。这些包括RSA（1.2.840.11359）和微软（1.2.840.113556），下面是各种各样微软产品的微软文件格式（1.2.840.113556.4），诸如Word（1.2.840.113556.4.2）。但是我们这里是对网络感兴趣（而不是微软的Word文件），所以我们还是把注意力转移到标有1.3的分支上来，ISO可识别的成员体所发布的标准。这些标准包括美国国防部（6）（其下可以找到因特网标准），开放软件基础（22），航空组织SITA（69），北约标识体（57），以及许多其他的组织。

在Internet这一分支下（1.3.6.1），一共有七个类别。在private分支下（1.3.6.1.4），我们可以找到一个列表[IANA 1999]，列表记录了超过4,000个注册了因特网数字分配授权（IANA）[IANA 1999]的私有公司的私人企业代码和名字。在management（1.3.6.1.2）和MIB-2（1.3.6.1.2.1）分支下，我们可以找到标准化MIB模型的定义。好家伙 ISO名字域到了我们这个角落已经是很长一段路了！

标准化MIB模型

图8.3中树的最低一层显示了一些重要的面向硬件的MIB模型（system和interface）以及和某些最重要的因特网协议相关的一些MIB模型。RFC 2400列出了所有的标准化MIB模型。尽管与MIB相关的那些RFC阅读起来干涩且冗长，但却很有指导意义（即，象吃蔬菜一样，是“对你有益”的），考察一些MIB模型的定义可以知道一个模型中信息的类型。

被管理对象顺着system这条线下来，包含了被管理设备的通用信息；所有被管理设备必须支持系统MIB对象。表8.2定义了system组中的这些对象，和RFC 1213中定义的一样。

表8.3定义了MIB模型中的被管理实体端的UDP协议被管理对象。

8.3.3 SNMP协议运作和转移定位

简单网络管理协议第二版（SNMP v2）[RFC 1905]是用来在管理实体和代表管理实体执行命令的代理之间传送MIB 信息的。SNMP最常见的用法是在一个请求-应答模式下：SNMP v2管理实体发送请求给SNMP v2代理，代理接收到请求，执行一些动作，然后对请求发送回应。典型地，一个请求会用来查询（恢复）或者修改（设置）和被管理设备相关的MIB对象值。SNMP第二个常见的用法是代理来发送一条自发的消息，如熟知的陷阱消息，给管理实体。陷阱消息是改变MIB对象值出现异常情形时，用来通知管理实体的。我们前面在第8.1节中看到了网络管理员可能需要接收陷阱消息，例如，当接口坏掉的时候，一条连接上的冲突达到了预先定义的等级，或者其他一些值得注意的事件发生。注意，轮询（请求-应答交互）和陷阱之间是有很多区别的；见课后习题。

SNMP v2定义了七种类型的消息，通常称做协议数据单元 PDU，如表8.4所示。PDU的格式如图8.4所示。

·GetRequest、GetNextRequest和GetBulkRequest三个PDU是从管理实体发送到代理的，用来请求代理端被管理设备的一个或多个MIB对象的值。其值被请求的MIB对象的对象标识符是在PDU变量绑定部分指定的。GetRequest、GetNextRequest和GetBulkRequest相互区别在与它们的数据请求颗粒度不同。GetRequest可以请求强行设定MIB值；多重GetNextRequest可以用来序列化列表中的MIB对象；GetBulkRequest允许返回一个大的数据块，以避免发送多重GetRequest和GetNextRequest消息时超负荷的出现。所有三种情况下代理以一个Response PDU来应答，其中包含了对象标识符和相关值。

·SetRequest PDU是管理实体用来向被管理设备中一个或多个MIB对象设置值的。代理用Response PDU的“noError”错误状态标志应答，以确认该值被真正设定。

·InformRequest PDU用于一个管理实体将MIB信息通知给另一个处在接收MIB信息远端的管理实体。接收信息的管理实体用Response PDU的“noError”错误状态标志应答来确认InformRequest PDU的接收。

·SNMP v2最后的PDU类型是陷阱消息。陷阱消息是异步产生的，即，不是在应答接收请求时产生，而是应答管理实体需要注意的事件发生时产生。RFC 1907定义了熟知的陷阱类型，包括设备的冷启动和热启动，链路时断时续，找不到相邻节点，和认证失败事件等。接收到的陷阱请求不需要管理实体的应答。

给定了SNMP v2的请求-应答特性后，还有必要注意，即使SNMP PDU能够以许多不同的传输协议载送，典型的协议还是采用UDP数据报。事实上，RFC 1906声称UDP是“优先选取的传输定位”。因为UDP是不可靠的传输协议，请求或应答是否能被预期的目的地接收是没有保障的。PDU的Request ID域是管理实体用来对发向代理的请求记数的；代理应答时从接收到的请求中提取出Request ID。这样，Request ID域可以被管理实体用来检测丢失的请求或回答。若在给定时间没有收到相应的回答，则由管理实体来决定是否重新发送请求。特别地，SNMP标准并没有指定任何特殊的重新发送过程，也没有指定重新发送需要优先执行。它仅要求管理实体“需要有责任地执行，考虑重新发送的频率和持续时间”。这里，当然，启发我们思考一个“负责的”协议应该如何做！

8.3.4 安全和管理

SNMP v3的设计者曾说，“SNMP v3可以认为是SNMP v2加上了安全和管理的能力”[RFC 2570]。当然，SNMP v3在SNMP v2之上有所改变，但是没有比在管理和安全方面的改变更明显的地方了。在SNMP v3中，安全的中心角色极其重要，因为缺乏足够安全的SNMP只能主要用来监视而不是控制（例如，SetRequest在SNMP v1中很少使用）。

随着SNMP三个版本的日渐成熟，其功能发展了但是，好家伙，SNMP相关的标准文档也多了起来。明显的事实是先甚至有RFC[RFC 2571]“描述了表述SNMP管理框架的体系结构”！尽管“描述框架”的“体系结构”这一提法可能会把人的脑子搞糊涂，RFC 2571的目标还是令人钦佩的 介绍一个公共语言来描述SNMP v3的代理或管理实体的功能和行为。SNMP v3实体的体系结构是直接的，概览一下这一体系结构可以帮助我们巩固对SNMP的理解。

所谓的SNMP应用程序包含一个命令产生器，通知接收器和代理服务转发器（所有这些都可以在典型的管理实体中找到）；一个命令应答器和通知溯源器（两者可以在典型的代理中找到）；可能还有其他应用程序。命令产生器产生GetRequest、GetNextRequest、GetBulkRequest和SetRequest等我们在8.3.3节中探讨过的PDU，并将接收到的应答处理给这些PDU。命令应答器在代理中接收、处理和回答（）代理所接收到的GetRequest、GetNextRequest、GetBulkRequest和SetRequest 等PDU。通知溯源器应用程序在代理中产生陷阱PDU；这些PDU最终在通知接收器应用程序中被管理实体接收到。代理服务转发器应用程序转发请求、通知和应答PDU。

在使用正确的传输协议发送之前，SNMP应用程序发送的PDU接下来通过SNMP“引擎”。图8.5显示了由命令产生器应用程序产生的PDU是如何首先进入SNMP版本定义的发送模型的。然后PDU被消息处理系统处理，PDU在这里被包装上一个含有SNMP版本号、消息ID和消息大小信息的消息头。如果需要加密或者认证，消息头会有相应的域来表示；详见RFC 2571。最后，SNMP消息（应用程序产生的PDU加上消息头信息）发送到正确的传输层协议上。运载SNMP消息优先选取的传输层协议是UDP（即，SNMP消息被视作UDP数据报的数据内容运送），SNMP优先选取的端口号是161端口。162端口用于陷阱消息。

我们前面看了SNMP消息不仅可以用来监视，还可以用来控制（例如，通过SetRequest命令）网络元素。清楚地，入侵者可以截获SNMP消息，并且/或者产生自己的SNMP包，以致网络管理基础结构可能会成为网络的危险处。这样，SNMP消息安全地传送就成为关键。令人惊奇地，仅仅是在最近的SNMP版本中，安全才获得了应该的重视。SNMP v3提供了加密、认证、防止回放攻击（见7.2和7.3节）和访问控制。SNMP v3安全性被称做基于用户的安全[RFC 2547]，因为传统概念上有一个由用户名识别的用户，它与诸如口令、密钥值或者访问权限等安全信息相关联。

·加密。SNMP PDU可以用数据加密标准（DES）以密码块链接模式加密；见7.2节对DES的讨论。注意，由于DES是共享密钥的系统，用户加密数据的密钥必须被接收实体知晓才能对数据解密。

·认证。SNMP结合了哈希函数，诸如我们在7.4节所学的MD5算法，并用一个密钥值来提供认证和防止篡改。其手段，被称做HMAC（散列的消息认证码）[RFC 2104]在概念上是非常简单的。假设发送者有一个SNMP PDU，m，它想发给接收者。这个PDU可能已经被加密了。同样假设发送者和接收者都知道一个共享密钥，K，这个密钥并不需要同加密PDU的密钥一样。发送者要把m发给接收者。然而，它并不随之发送一个简单的消息完整性编码（MIC） MIC(m)是在m的基础上计算出的（见7.4.2节），可以防止篡改；取而代之的是发送者附上m的共享密钥来计算MIC MIC(m, K)于结合在一起的PDU和密钥上。然后这一值MIC(m, K)（而不是密钥！）和m一起发送。当接收者接收到m，它附加上密钥K然后计算MIC(m, K)。如果这一算出的值和发送的MIC(m, K)值匹配，接收者就不仅知道了消息没有被篡改，也知道了消息是由知道K值的发送者发送的，即，可信任的，已认证的发送者。操作上，HMAC实际上执行了“附加-散列”操作两次，每次用稍微修改了的密钥值；详见RFC 2104。

·防止回放。回顾我们在第七章中的讨论，即时数可以用来防卫回放攻击。SNMP v3采纳了一种相关的手段。为了确保接收到的消息不是某个早期消息的重放，接收者要求发送者在每条消息中包括一个基于接收者方的计数器值。这一计数器功能上是一个即时数，反映了接收者的网络管理软件自上次重启以来的时间以及自上次配置以来的重启次数。只要接收到的消息中计数器值与接收者的计数器中实际值有一点不同，消息就可以被看做非重放的而被接受，这样才会对它认证或解密。详见RFC 2574。

·访问控制。SNMP v3提供了一个基于视图的访问控制[RFC 2575]，它可以控制什么样的网络管理信息可以被什么样的用户查询和/或设置。一个SNMP实体在本地配置数据区（LCD）保留着访问权力和方针的信息。LCD的分区自身被视作管理对象也是可访问的，在基于视图的访问控制模型配置MIB[RFC 2575]中定义，这样就能被管理以及在远端通过SNMP产生了。

8．4 　ASN.1

在这本书中我们讨论了很多计算机网络领域里有趣的话题。这一节是关于ASN.1，或许，不能在有趣话题的top-10列表中列出。象蔬菜一样，关于ASN.1的知识和表示服务的方面更宽泛的文献是“对你有益”的一些东西。ASN.1是一个源于ISO的标准，用在许多和因特网相关的协议中，尤其是在网络管理的领域。例如，我们在3.2节中看到SNMP中的MIB变量和ASN.1不可解开地结合在一起。所以尽管本节关于ASN.1的材料可能非常干涩，读者得充满希望地保持着本节材料很重要的信心。

为了在这里激发我们的讨论，考虑 接下来的思考经验。假设某人能可靠地从他的计算机内存中直接拷贝数据到另一台远端的计算机内存。如果他可以做到这一点，通信问题就“解决”了吗？这一问题 的答案取决于他对“通信问题”的定义。肯定地，一个完美的内存到内存的拷贝能正好是一台机器到另一台机器实现位和字节的通信。但如此精确的位和字节的拷贝 意味着当接收方的计算机上运行着的软件访问到这一数据时，它能看到与发送方计算机内存中存储的相同的值吗？这一问题的答案是“没有必要”！问题的要点在于 不同的计算机体系结构，不同的操作系统，不同的编译器对数据的存储和表达都有不同的习惯。如果数据要在多计算机中通信和存储（这种情形在每一个通信网络中 都存在），这一数据表达问题必须清楚地解决。

作为这一问题的一个例子，考察如下简单的一个C代码片段。这一结构在内存中会如何放置呢？

Struct {

char code;

int x;

} test;

test.x = 259;

test.code = ‘a’;

图8.6的左边显示了这一数据在某个假设的体系结构上可能的存储分布：一个单一的字节内存区域存放了字符’a’，接着是一个16位字内存区域存放了整数值259，以最高有效字节优先存储。数据在另一台计算机中内存存储分布如图8.6的右边所示。字符’a’之后的整数值是以最低有效字节优先存储的，并且开始于16位字的边界。当然，如果谁逐个区域地在这两个计算机的内存中拷贝，并且用同样的结构定义去访问这些存储值，他将看到两台计算机上有不同的结果！

不同的体系结构有不同的内部数据格式这一事实是真实的并且是随处可见的问题。不同格式的整数存储这一特殊的问题由于太普遍而有了一个名字。“Big-endian”顺序存储整数是将最高有效字节优先存储（放在较低的地址）。“Little-endian”顺序存储则是最低有效字节优先。Sun SPARC和Motorola处理器采用Big-endian方式，而Intel和DEC Alpha处理器采用的是Little-endian方式。作为一个插曲，术语Big-endian和Little-endian来自Jonathan Smith的《Gulliver’s Travels》一书，书中两队人独断地坚持用两种不同的方式做一件简单的事情（所幸，这一比拟在计算机体系机构圈子里是清晰的）。一队在Lilliput陆地上的人坚持从鸡蛋大的那头打破它（“big-endian”），另一队人则坚持从小的那一头打破鸡蛋。这一分歧是后来国内战争和反抗的原因。

现已知不同的计算机存储和和表示数据的方法是不同的，网络协议如何处理这一问题呢？例如，如果一个SNMP代理要发送一个包含已接收的UDP包的整数记数的Response消息给管理实体，它要怎样表示这一整数值呢 用Big-endian还是Little-endian？一个可选方案是代理按照管理实体中存储整数的顺序发送整数字节。另一个可选的方案是代理按照自己的存储顺序并让管理实体对其重新排序，如果必要的话。任何一种选择都需要发送者或接收者知道对方的整数表示格式。

第三个选择是使用一个与机器、操作系统、语言都无关的方法来描述整数和其他数据类型（即，一个数据描述语言）和一套规则，规定每种数据类型在网络上传输的法则。当接收到给定类型的数据时，它是以一种已知的格式收到的，因而能转变成任何一种需要的特定机器格式。我们在8.3节中所学的SMI和ASN.1都采纳了这第三种选择。在ISO的术语中，这两个标准描述了一种表达服务 为把一种特定机器格式的信息传输和翻译成另一种。图8.7表现了一个真实世界的表达问题；任何接收者都不能理解通信中交流的必要意图 说话者喜欢什么。如图8.8所示，表达服务可以解决这一问题：通过将意图翻译为一种普遍理解的（被表达服务理解），与人无关的语言，再将这一信息发送给接收者，然后再翻译为接收者可以理解的语言。

表8.5显示了一些ASN.1定义的数据类型。回顾我们早期学习SMI的时候遇到的INTEGER、OCTET STRING和OBJECT IDENTIFIER数据类型。因为这里我们的目标（可怜的）不是完全地介绍ASN.1，我们将建议读者阅读标准或者打印好的或在线的书籍[Larmouth 1996]对ASN.1数据类型和允许定义结构数据类型的构造器诸如SEQUENCE和SET的描述。

除了提供一个数据描述语言以外，ASN.1还提供基础编码规则（BER），指定了用ASN.1数据描述语言定义的对象实例是如何通过网络发送的。BER采纳了所谓的TLV（Type, Length, Value）手段来对传送数据编码。对每一个要发送的数据项，数据类型、数据项长度、和数据项的实际值以上述顺序传送。采用这一简单的习惯，接收到的数据就能自己标识。

图8.9显示了在一个简单的例子中两个数据项是如何发送的。这个例子里，发送者想要把字符串‘smith’和随后的十进制数259（等于二进制的00000001 00000011，或者字节值1跟着是3）假设是用Big-endian顺序。传送流中的第一个字节的值是4，表示随后的数据类型是OCTET STRING；这表现的是TLV编码中的T。传送流中第二个字节包含了OCTET STRING的长度，这个例子中是5。传送流中第三个字节开始了长度为5的OCTET STRING；包含了为首的字母’s’的ASCII表示。下一个数据项的T、L和V是2（INTEGER类型的标记值）、2（即，整数的长度是2）和两字节的Big-endian表示的十进制值259。

在我们上面的讨论中，我们仅仅触及了ASN.1小而简单的一个子集。学习更多关于ASN.1的资料包括ASN.1标准的文档有[ISO 1987, ISO X.680 1998]，Philippe Hoschka’s ASN.1主页[Hoschka 1997]，和[Larmouth 1996]。

8．5 　防火墙

为了激发第七章中安全的需要，我们注意到因特网不是一个非常“安全”的地方 很多没有做好的工作“在那里”导致闯入网络的频率达到了发出警告的程度。（要看攻击报告的总结，可以在CERT协调中心[CERT 1999]。要看对近300种已知攻击的防火墙讨论，我们这里讨论的主题，并且为反攻而设计，参见[Newman 1998]。）因此，网络管理员必须关心，不仅是保持比特流畅通地在他们的网络上通过，还要保障他们的网络基础设施不受到外界的威胁。

我们已经看到，为了实现安全网络管理功能，SNMP v3提供了认证、加密、和访问控制。尽管这是重要的（当然，网络管理员不希望别人得到访问网络管理功能的），它仅仅是网络管理员安全考虑的一小部分。除了监视和控制网络组件，网络管理员也希望排除掉被管理网络中不期望出现的流量（即，入侵者）。这便是防火墙到来的地方。一个防火墙是硬件和软件的结合，它广义上将组织的内部网和因特网隔离开来，允许一些包通过并阻止另一些包。组织使用防火墙是为了如下的一个或多个目的：

·防止入侵者干扰每天都运行着的内部网。一个组织的竞争者 或者就是某些因特网上的找乐子的无赖 可以对一个没有安全防护的网络造成威胁。在拒绝服务攻击中，一个入侵者独占了一个关键的网络资源，使内部网（在其网络管理员手中）瘫痪。拒绝服务攻击的例子是所谓的SYN洪水[CERT 2000]，攻击者发送造好的TCP连接建立字段给一个特定的主机。这个主机为每个连接开辟额外的缓冲区，几分钟之内就没有了TCP缓冲区来提供给“诚实的”TCP连接。

·防止入侵者删除或者修改内部网中存放的信息。例如，一个入侵者可以试图在Web服务器上扰乱某个组织的公众形象 一次成功的攻击可以在几分钟内被数以千记的人看到。攻击者也可能从提供因特网商务的Web服务器得到顾客购物卡信息（参见7.7节）。

·防止入侵者获得机密信息。多数组织有存放在计算机上的机密信息。这些信息包含了商业机密、产品研发计划、市场战略、员工个人记录和财务分析等。

最简单的防火墙由包过滤器组成。更复杂的防火墙还包括了包过滤器和应用网关的结合，接下来的两小节将讨论这一话题。

8.5.1 包过滤

一个组织典型地有一个连接其内部网到其ISP（进而通向更大的公众因特网）的路由器。所有离开和进入内部网的流量都经过这个路由器。大多数路由器制造商提供了过滤选择：打开这些选择时，路由器便成为带过滤器的路由器。如名字所暗示，一个过滤器让一些报文通过路由器而过滤掉另一些报文。典型的过滤决定基于：

·数据来源的IP地址（假设的）。

·IP目的地址。

·TCP或者UDP源或者目标端口。

·ICMP消息类型。

·使用TCP的SYN或者ACK位创建连接的数据报文。

作为一个简单的例子，一个过滤器可以设置为阻止所有的UDP字段以及所有的Telnet连接。这样的配置防止了外部人员使用Telnet登录到内部主机，内部人员使用Telnet登录到外部主机，和进入或离开内部网的“奇怪的”UDP流量。路由器过滤掉UDP流量是通过阻止所有IP中协议域的值为17（对应UDP）的报文；它过滤掉所有的Telnet连接是通过阻止所有TCP字段（每一个是封装在报文中的）中源端口或目的端口是23的包（对应Telnet）。过滤掉所有UDP流量是公司流行的策略 这让许多主流的音频和视频流提供者很是苦恼，因为他们的产品流默认是通过UDP协议的。过滤掉Telnet连接也很流行，因为它能阻止外部入侵者登录到内部机器。

过滤策略也能基于连接的地址和端口号。例如，可以转发所有Telnet包（23端口）除了那些走向或者来自特殊IP地址列表的。这一策略允许列表中的主机使用Telnet连接。高度推荐拒绝掉所有有内部IP源地址的报文 即，声称来自内部，但实际上是来自外部的数据包。这些数据包通常是地址欺骗攻击的一部分，并且攻击者假装是来自内部机器的。不幸的是，基于这一策略控制外部地址不能防止外部主机声称自己是另外的外部主机。

过滤还可以基于TCP ACK字段是否设置。如果组织希望让其内部的客户端连接到外部服务器，又想阻止外部客户端连接到内部服务器的话，这一技巧很有用。回顾3.4节，每一个TCP连接的第一个字段都把ACK位设置为0，而连接中所有其他的字段的ACK位都被置为1。这样，如果组织希望阻止外部客户初始化连接到内部服务器上，简单地过滤掉所有ACK位设为0的字段就行了。这一策略杀掉了所有源于外部的TCP连接，但是允许源于内部的连接。

现在假设组织不想关闭所有来自外部的连接，而仅仅想关闭掉来自外部的Telnet连接。这可以通过阻止目的端口是23的进入组织的包，或者源端口是23的离开组织的包。

8.5.1 应用网关

过滤器让组织能对IP和TCP/UDP进行粗略的过滤，包括IP地址，端口号以及应答位。我们看到，基于IP地址和端口号的过滤能允许内部客户端Telnet到外部，并阻止外部客户端Telnet到内部。但是如果组织希望在内部受限制的人员中提供Telnet服务呢？这样的工作超出了过滤器的范围。事实上，内部用户的身份不是在IP/TCP/UDP包头中，而是在应用层的数据里。

为了有一个更好层次的安全，防火墙必须把过器和应用网关结合起来。应用网关能跨越IP/TCP/UDP包头，并且真正地基于应用层数据作出策略决断。一个应用网关是一个指定应用的服务器，所有应用数据（进入或离开的）必须通过它。多个应用网关能在同一个主机上运行，但每一个网关是一个独立的服务器进程。

为了得到一些应用网关的详细信息，让我们来设计一个防火墙，它只允许受限制的内部用户Telnet到外部，并且阻止所有的外部客户端Telnet到内部来。这样的方针可以通过实现一个包过滤器（在路由器中）和一个Telnet应用网关来做到，如图8.10所示。路由器的过滤器配置为组织所有Telnet连接，除了那些IP地址是应用网关的。这样一个过滤器配置使所有外出的Telnet连接都得通过G。当一个内部用户希望Telnet到外面的时候，它首先和应用网关建立一个Telnet会话。网关中运行的一个应用程序监听到Telnet会话，提示用户输入用户名和口令。当用户提供了这些信息以后，应用网关检验用户是否有Telnet到外面的权限。如果没有，网关就终止掉这次从内部用户到网关的Telnet连接。如果用户有权限，网关（1）提示用户输入他想连接的外部主机的主机名，（2）在网关和外部主机之间建立一个Telnet会话，（3）将从用户发出的所有数据转发给外部主机，并且把外部株距发向用户的所有数据转发给用户。这样，Telnet网关不仅扮演了用户认证的角色，还同时作为Telnet服务器和Telnet客户端。注意过滤器是允许（2）步骤的，因为是网关向外部建立的Telnet连接。

内部网络经常有多个应用网关，例如，Telnet网关、HTTP网关、FTP网关和e-mail网关。实际上，一个组织的邮件服务器（见2.4节）和Web缓存（见2.6节）都是应用网关。

应用网关并不是没有缺点。首先，不同的应用需要不同的应用网关。其次，或者

·当用户作请求时，客户端软件必须知道如何同网关联系而不是同外部服务器联系，并且必须知道如何告诉应用网关其想要连接的外部主机；

或者

·用户必须明确地通过应用网关连接到外部服务器。

总结本节，我们指出，防火墙并不是包治所有安全问题的良药。它们在同外界通信的程度和安全等级之间引入了一个对半的协定。因为过滤器不能阻止IP地址和端口号欺骗，过滤器通常采用全部通过或者什么也不通过的策略（例如，禁止所有的UDP流量）。网关可能有软件上的BUG，留给攻击者来穿透它。同样，防火墙也无能为力于内部用户对外界的无线通信。

8．6 总结

我们网络管理的学习，真正对所有的网络，现在完成了！

在这关于网络管理的最后一章中，我们开始于提供恰当的工具给网络管理员 其职责是保持网络“up and running” 以用来监视、测试、登记、配置、分析、评估和控制网络的运作。我们比拟了复杂系统的管理，如电厂、喷气飞机、和人类组织，以帮助激发这一需求。我们看到，网络管理系统体系结构有五个关键组件 （1）一个网络管理者，（2）一组被管理的远端（就网络管理者而言）设备，（3）这些设备上的管理信息库（MIB），包含设备状态和操作的数据，（4）报告MIB信息和在网络管理者控制下执行命令的远端代理，（5）网络管理者和远端设备之间的通信协议。

我们然后进入了因特网网络管理框架的细节，特别是SNMP协议。我们看到了SNMP是如何作为网络管理体系结构五个关键组件的例子，并且花费了不少的时间考察MIB对象，SMI 指定MIB的数据定义语言，和SNMP协议自身。注意SMI和ASN.1是不可分割地结合在一起的，ASN.1在ISO/OSI七层参考模型的表示层中起到重要的作用，我们然后简单地考察了一下ASN.1。或许比ASN.1自身细节更重要的是，我们提及到的网络中机器特定的数据格式之间的翻译。某些网络明确地知道这一重要性而提供了表示层，而这一层在因特网协议栈中是不存在的。最后，我们以对防火墙的讨论而总结了这一章 一个处于网络管理和网络安全边缘的话题。我们看到了包过滤和应用网关是如何用在提供网络某个保护级别以防止不期望的入侵者，或许会让网络管理员在得知了网络对那些入侵者来说相对安全以后，晚上能睡得好些。

同样也值得注意，我们没有涉及很多网络管理方面的话题 例如差错识别和管理、主动异常检测、警报关联和服务管理的诸多文献（例如，反对网络管理的）。尽管重要，这些话题自己就可以写成书了，我们建议读者阅读8.1节中提到的参考资料。