《入侵检测》课件第4章

第4章入侵检测标准4.1通用入侵检测框架4.2

IDWG的建议草案4.3两种标准草案之间的联系 4.1通用入侵检测框架

为了解决不同IDS之间的互操作和共存问题，1997年3月，美国国防部高级研究计划局（DARPA）开始着手CIDF标准的制定，试图提供一个允许入侵检测、分析和响应系统以及部件共享分布式协作攻击信息的基础结构。

CIDF是一套规范，它定义了IDS表达检测信息的标准语言以及IDS组件之间的通信协议。符合CIDF规范的IDS可以共享检测信息，相互通信，协同工作，还可以与其它系统配合实施统一的配置响应和恢复策略。CIDF的主要作用在于集成各种IDS使之协同工作，实现各IDS之间的组件重用，所以CIDF也是构建分布式IDS的基础。

CIDF所做的工作主要包括四部分：

（1）IDS的体系结构：阐述了一个标准的IDS的通用模型；

（2）通信机制：定义了IDS组件之间进行通信的标准协议；

（3）规范语言：定义了一个用来描述各种检测信息的标准语言；

（4）应用程序接口：提供了一整套标准的应用程序接口。该规范的主要目的是：

（1）IDS构件共享，即一个IDS的构件可以被另一个IDS构件所使用；

（2）数据共享，即通过提供标准的数据格式，使得IDS中的各类数据可以在不同系统之间传递并共享；

（3）完善互用性标准并建立一套开发接口和支持工具，以提供独立开发部分构件的能力。4.1.1

IDS的体系结构

1.组件构成

CIDF模型将IDS需要分析的数据统称为事件（Event），它既可以是网络中的数据包，也可以是从系统日志或其它途径得到的信息。

CIDF按照功能将入侵检测系统分为四个组件：事件产生器（EventGenerators）、事件分析器（EventAnalyzers）、响应单元（ResponseUnits）、事件数据库（EventDatabases），如图4.1所示。图4.1入侵检测系统组件结构（1）事件产生器:也称探测器或传感器（Sensor），它的任务是从整个计算环境中收集事件，并将这些事件转换成通用入侵检测对象（GeneralIntrusionDetectionObject，GIDO）格式传送给其它组件。

（2）事件分析器:也称检测引擎（DetectionEngine），它负责分析从其它组件收到的GIDO，并将产生的分析结果传送给其它组件。

（3）响应单元：响应单元负责处理接收到的GIDO，并根据分析结果做出反应，它可以发出切断连接、改变文件属性等强烈反应，甚至发动对攻击者的反击，也可以只是简单的报警。

（4）事件数据库：事件数据库用来存储GIDO，以备系统需要的时候查询和使用。它可以是复杂的数据库，也可以是简单的文本文件。以上CIDF模型中的四个组件代表的都是逻辑实体，一个组件可能是某台计算机上的一个进程甚至线程，也可能是多个计算机上的多个进程。

组件之间采用GIDO格式进行数据交换。GIDO是对事件进行编码的标准通用格式（由CIDF描述语言CISL定义），GIDO数据流可以是发生在系统中的审计事件，也可以是对审计事件的分析结果。由于CIDF有一个标准格式GIDO，所以这些组件也适用其它环境，只需要将典型的环境特征转换成GIDO格式，这样就提高了组件之间的消息共享和互通。

2.组件间通信的三层模型

CIDF将各组件之间的通信划分为三个层次结构，如图4.2所示。图4.2

CIDF组件的通信层次

GIDO层：为了提高组件之间的互操作性，GIDO层就如何表示各种各样的事件进行了详细的定义，制定了统一的信息表达格式。GIDO层只考虑所传递消息的语义，而不关心这些消息怎样被传递。

消息层：建立可靠的传输通道，确保被加密和认证的消息在防火墙或NAT等设备之间进行可靠传输。消息层只是负责将数据从发送方传递到接收方，而不关心传输的内容。

协商传输层：负责利用现有网络协议，规定GIDO在各个组件之间的传输机制。4.1.2

CIDF的通信机制

CIDF要实现协同工作，需要解决组件之间通信方面的两个问题：CIDF的一个组件怎样才能安全地联系到其它组件，其中包括组件的定位和组件的认证；CIDF如何保证组件之间能够安全有效地通信。为实现此目标，CIDF在匹配服务、消息层、协商机制和消息处理等方面做了规范。

1.匹配服务

为了实现组件之间更好地接洽，CIDF采用了一种称为Matchmaker（匹配器）的通信构架。它提供了一个标准的、统一的方法，使得CIDF的组件之间能互相识别和定位，让它们能够共享信息。这样极大地提高了构件之间的互操作能力，从而使入侵检测和应急系统的开发变得容易。具体而言，匹配器需要根据CIDF组件的要求，支持不同等级目录服务。匹配器还要提供灵活简便的操作配置，提供多种形式的查询。为了实现以上目标，匹配器目录服务器采用了轻量级组件查询协议LDAP，匹配器采用两种匹配架构完成组件的添加、授权/认证，并采用两种查询方式：基于特征查询和基于组件的ID查询。

目录是一种专门的数据库，它服务于各种应用程序，包括LDAP（轻量级目录访问协议）目录和基于X.500目录，这些目录都是通用的标准目录，它们不适合于特定的操作系统、应用目的。大多数人熟悉各种各样的目录，像电话簿、黄页，电视指南、购物目录和图书馆卡片目录，这一类目录归为日常目录。在计算机中的目录被称为在线目录。

1)匹配架构

匹配器的结构组件主要包括：通信模块、中间件、授权/认证模块、客户端缓存。

通信模块：实现客户端（客户端可以是任何一个CIDF组件）与匹配代理之间的通信协议,本质上，是隐藏在配置内核下的API函数。

中间件：在匹配过程中有两个任务,一个是处理从远端组件到它的客户端的输入请求，另一个是处理从它的客户端到远端组件的输出请求。授权/认证模块：从概念上讲，包含标准CIDF库的认证组件,该模块用于组件之间的彼此认证。

客户端缓存：客户端作为发起查询一方，需要缓存一定数量的最近建立的联系信息。缓存是在磁盘上进行的,每次组件执行查询协议，都会更新客户端缓存。缓存的主要目的在于灾难恢复，而不是执行，可在两种情况下使用：如果由于目录服务器不可用，造成目录查询失败，那么在本地缓存中查询；当目录查询成功，在本地缓存中存储的信息也可以用来补充增强目录查询结果，匹配器用这种方法抵御对目录内容的攻击。匹配架构的核心部分是中间件。相对于中间件，匹配器的其它组件总是处于客户端的位置，这些组件可以看做是中间件的客户端。

匹配架构支持两种配置：一种是Matchmaker客户程序自带中间件（即通信模块和中间件绑定在一起），这时中间件和客户端形成一对一的映射，如图4.3所示。图4.3

Matchmaker客户自带中间件图中描述的客户端具有本地中间件。匹配器的API函数发出的查询请求引用通信模块，通信模块直接调用中间件。

另一种配置是，Matchmaker允许中间件独立于客户存在，可以是同一主机的单独的进程，也可以完全是其它主机上的进程，如图4.4所示。在这种情况下，一个中间件可以为多个客户服务，即中间件和客户端形成一对多的映射。图4.4中间件与Matchmaker客户端分离

图4.4表示客户端与中间件在不同主机的情形。这里，查询请求通过授权/认证模块，通信模块通过网络与中间件接触。

由上述分析可知，当中间件和客户端分离的时候，通信模块完成接洽和使用中间件功能；如果通信模块和中间件绑定在一起，通信模块执行空操作。

2)目录数据格式和组织

匹配器使用轻量级目录访问协议（LightweightDirectoryAccessProtocol，LDAP）目录服务器存储目录信息。LDAP目录保留了关于用户及其计算机的信息，其存储的方式采用目录的方式，如图4.5所示。LDAP的目录是动态的。其保留的信息可以按需进行更新，LDAP目录也是分布的，这样就不容易遭到破坏。图4.5

LDAP目录结构的倒向树

LDAP信息结构类似于文件系统组织的结构，如图4.5所示。在文件系统或这种目录树结构中，可以把目录的最顶层被称为根（Root），所有的文件都置于根的下级。根下面是树枝目录（Container，或称为容器，相当于文件夹）和叶子（Leaf，相当于具体的文件和数据，在树中位于最底层的节点）。通过目录树层层展开，把树枝目录置于不同的层次上，便可以区分和组织数据。在文件系统里，树枝目录不包含数据就没有实际意义。

树枝目录是用来组织对象的，它包含了NDS的叶子对象。LDAP中存储的实际数据是对象的各种属性。有关某个部门或个人等的相关信息在目录服务器中以目录树的方式组织。在许多情况下，目录结构是组织结构的反映。它起始于组织描述，向下细划为项，如部门、资源最后到人。

LDAP信息的基本单元是项。项是指现实世界关于某对象的信息集合，在目录项内部是一组属性，这组属性描述跟该项的相关特性，如跟人相关的姓名、邮件地址、电话等，属性由一个类型域和一个或多个值组成，如图4.6中，对于MarkKadrich这个人，目录中的cn=MarkKadrich，cn表示通用名字，是属性类型，而MarkKadrich描述属性内包含的信息，是属性对应的值。图4.6目录信息树：名字空间示例

LDAP目录服务器为读密集型的操作进行了专门的优化，而并不适合存储需要经常改变的数据。为此，目录结构定义可以在以下几方面符合LDAP服务的要求：

第一，在目录分支创建方面。不为单个组件创建分支，而只为中间件创建目录分支。

叶子分支使用中间件分支，而不使用单个组件作为叶子节点。这遵从了现有的LDAP使用规范，即叶子分支要和可寻址的网络实体作关联，比如打印机或者计算机。根据匹配架构的配置情况，中间件可能与一个或多个网络实体作关联。

没有使用网络主机作为叶子节点，这避免了在叶子节点下再进一步的创建分支。第二，由目录服务器的管理员完成目录的添加。

（1）目录设计。目录中主要包括类分支、组件分支和CIDF组件信息。

①类分支。类采用分级结构。每一类都是目录中的一个分支节点。匹配器要找的每个类都有一条从目录树的根开始的特定路径与之对应，这条路径称做完整类名（fullyqualifiedcategoryname）。虽然每个类可能有多个父类，但是它的完整类名具有唯一性。②中间件分支。

对于常量级组件，中间件分支指CIDF组件运行的主机，对应匹配架构的第一种情况。而对于轻量级组件，则指中间件运行的主机，对应匹配架构的第二种情况。轻量级组件，指不能TCP会话，存储空间有限的CIDF主机。

在整个目录树中，中间件分支是叶子节点。从查询角度看，每一个使用目录的CIDF组件都要有一个中间件分支与之对应。③CIDF组件信息。

它描述了使用相应中间件进行特征查询的组件的基本信息，包括CIDF组件的主机名及入港绝对路由（从目录服务器到CIDF主机的路由，称为入港绝对路由）。（2）属性设计。

实现目录结构，需要设计相应的属性。在属性设计中，以中间件为标识的CIDF组件和客户端之间只体现查询与被查询关系，以中间件为标识的CIDF组件和类之间只体现生产或消费的关系。这里的生产和消费分别指生产GIDO数据，消费GIDO数据。

①类属性:

organizationalUnit(ou）——组织单位名称。通常使用现有的类名称，并以“ＣIＤＦ”作前缀。例如：所有在Phoenix办公室的文件服务器的“ou”如下：

ou=cidfFileservers，ou=phoenix，o=NetlifeAssociates，c=us。

superCategoryList——所有父类的名称。

subCategoryList——所有子类的名称。

registeredProducerList——注册的生产者列表，包含一组中间件分支，以该中间件分支为标识的CIDF组件都是要查询当前类的GIDO数据的生产者。

registeredConsumerList——注册的消费者列表，包含一组中间件分支，以该中间件分支为标识的CIDF组件都是要查询当前类的GIDO数据的消费者。

memberCertificate——成员认证证书，基于X.509认证的证书。②中间件分支属性：

必须包含的一个属性，cidfComponentList——CIDF组件列表，描述当前中间件服务的客户端。该属性不由当前的LDAP服务器解释。当对应匹配器架构第二种情况，列表中会有多个CIDF组件。③组件属性:

这里指CIDF组件属性，而不是匹配器组件属性,即这里描述的是中间件查询的客户端属性。

cidfInboundAbsoluteRoute——CIDF入港绝对路由，描述当前组件所在主机的入港绝对路由，即从目录服务器到CIDF主机的路由。

cidfStableComponentID——CIDF稳定组件ID，描述当前CIDF组件的标识符。

cidfProducerMemberList——CIDF生产者成员列表，当前CIDF组件是列表中列出的类的GIDO数据的生产者。

cidfConsumerMemberList——CIDF消费者成员列表，当前CIDF组件是列表中列出的类的GIDO数据的消费者。

cidfFilterExprList——CIDF过滤表达式，是一个S表达式值构成的队列。

cidfInterfaceType——CIDF接口类型。

组件的cidfStableComponentID属性、cidfInboundAbsoluteRoute属性和cidfFilterExprList作为查询时的返回值，cidfStableComponentID属性和cidfInboundAbsoluteRoute被组件查询协议用来找到对端组件。属性的cidfFilterExprList设置的查询条件可以使查询更加灵活。

例如，某CIDF组件处于一台主机，在入侵检测框架中它是检测器，产生GIDO数据并上报到上一级部门B，B部门再把收到的数据上报到分析器。那么B部门就是cidfProducerMemberList中的一个类，该组件是cidfProducerMemberList中类的GIDO生产者。

3)查询方式

匹配器使用特征查询协议和组件查询协议，分别对应基于特征查询和基于组件ID查询。

CIDF的某组件（由前述可知，在网络环境下查找组件就是找可以是组件所在的主机，为了叙述方便，称其为主机1）要与另一组件（主机2）通信时，主机1必须先通过某种查询方式对主机2进行定位（即找到到达主机2的路由），然后进行接洽。（1）路由。

CIDF组件之间可能需要穿过防火墙进行通信。一些防火墙是不透明的，要穿过不透明的防火墙通信，需要把地址包发到与防火墙关联的代理，代理再把地址包向前送到实际（或者是下一个）目的地。

一些防火墙在出港方向是透明的，而在入港方向是不透明的。

源路由：在一定的网络环境中，主机1到达对端主机2的路由称为源路由。源路由由0个（这时防火墙是透明的）或者多个代理的地址（防火墙不透明）构成，最后面跟的是目的主机的地址。CIDF源路由不同于IP源路由，CIDF源路由指定的是代理而不是IP路由器。

绝对路由：从目录服务器到CIDF主机的路由，称为入港绝对路由，如图4.7所示。

反之，从CIDF主机到达目录服务器的路由，称为出港绝对路由，如图4.8所示。图4.7入港绝对路由图4.8出港绝对路由可以通过以下步骤由主机的入港绝对路由推出主机的出港绝对路由：

①逆序入港绝对路由；

②删除第一个分支（主机自己的地址）；

③若防火墙设置为出港方向是透明的，就用填充值（对IPv4，该值是null）代替一个或者多个地址，表示相应的一跳是透明的。

可以通过以下步骤计算从主机1到达主机2的源路由：

①取得主机2的入港绝对路由（例如，从目录服务器获取）；图4.9主机1到主机2的源路由②根据主机1的入港绝对路由，计算入港绝对路由的通用前缀（即目录服务器的地址）；

③去掉主机2的入港绝对路由的前缀（即目录服务器的地址）；

④从主机1的出港绝对路由的末端去掉同样的元素（即目录服务器的地址）；

⑤把步骤3得到的绝对路由，追加到步骤4得到的出港绝对路由后面；

⑥该结果路由就是要用到的源路由，如图4.9所示。（2）基于特征查询。

基于特征查询使用特征查询协议，该协议包括认证注册授权部分和查询部分。

在每次执行查询时，首先需要对发出查询的主机进行认证。在目录服务器中，每个类分别记录了有资格参与其中的一个或多个主机（即可以读/写数据的主机）。对主机的认证由某些在匹配器以外的代理来执行，并且与主机是否激活无关。

认证过程应当创建目录中相应主机的中间件分支，如果不存在，就添加中间件分支到该类的生产者或者消费者列表，完成注册。只有当创建目录时才创建中间件分支，对已经注册过的类不需要创建中间件分支。每个中间件，应记录依赖于中间件的哪一个CIDF组件现在是激活的。这些隐含记录在协商建立的时候被刷新。

在任何情况下，授权系统的作用是证明指定的主机在类中是生产者、消费者或既是生产者又是消费者。为了避免信任目录服务作为协商来源，匹配器使用某种公钥授权系统，该系统可以是基于Ｘ.509方法或SDSI。

组件所在主机（主机1）通过出港查询获得对端组件所在主机（主机2）的入港绝对路由。出港查询中间件按照顺序执行以下步骤：

①建立和目录服务器的连接。

②和目录服务器相互认证。

③核实主机1在请求中指定的GIDO中的每个类都是经过认证的。

④如果主机1现在没有在目录中注册，就准备一个cidfComponent对象表示客户端并添加该对象到客户端中间件的目录分支的cidfComponentList。⑤出港查询中间件执行以下步骤，在目录服务器中查询GIDO中的每个类：

a.在registeredProducerList或者registeredConsumerList中找到该类的组件中间件分支列表。

b.对列表中返回的每个组件中间件分支执行以下操作：

·查询分支的cidfComponentList属性。

·对cidfComponentList列表中的每个组件，提取以下属性：

cidfInboundAbsoluteRoute、cidfProducerMemberList（如果有该属性）、cidfConsumerMemberList（如果有该属性）、cidfFilterExprList（如果有该属性）。

·比较由主机1指定的GIDO类和组件所属作为成员的类，即匹配当前组件的cidfConsumerMemberList或cidfProducerMemberList属性，需要指定算法。

·比较主机1指定过滤表达式与组件的过滤表达式属性，即匹配当前组件的cidfFilterExprList属性。需要指定算法。

·根据查询请求，当以上两步全部匹配或只有某一步结果匹配时，将得到的组件添加到需要接洽的组件集合中。

集合中可以是一个组件，也可以是多个。⑥断开和目录服务器的连接。

由上述可知，在目录中特征查询步骤如下：

①目录服务器客户端查询想要找的类，然后查找该类分支的注册生产者列表（registeredProducerList）或者注册消费者列表（registeredConsumerList）。

②目录服务器客户端在生产者列表中查找每一个中间件分支，然后查找中间件的cidfComponentList属性。

③目录服务器客户端解析返回的查询值。实际上，就是检查类成员列表和每个组件的过滤表达式，根据查询请求，如果两项属性全部匹配或者只有某一步匹配，则该组件即满足查询条件。（3）基于组件ID的查询。

基于组件的ID查询使用组件查询协议，例如，这里的CIDF组件ID指DNS主机名。

使用组件查询协议，最一般的情形是，先由特征查询，查到对方的DNS主机名和入港绝对路由。

另一种情形是，当只提供对方的DNS主机名和组件ID时，根据主机名在本地缓存找到以前存储的源路由信息，重复以上过程。

第三种情形是，当只提供对方的DNS主机名和组件ID时，从其它途径获取对方的入港绝对路由，重复以上过程。总之，对方组件可被找到的前提，是对方已经初始化，即已经注册——在“”，能找到对方的入港绝对路由。

所以，找寻主机1到达主机2的源路由，并非必须先执行特征查询协议。即假若曾经执行过对主机的特征查询，那么在缓存中就会存储主机1到达主机2的源路由，这时只需根据组件的DNS主机名等信息在缓存中查询，就可以得到相应的源路由了。

所以，组件查询协议本身，并不涉及匹配和中间件，而是使用认证/授权模块来与远端CIDF组件进行协商通信。

1）出港查询

要建立和远端组件的通信，认证/授权模块执行以下步骤：

①锁定并行的协商信息。

②核实重复联系，例如，在客户端和远端组件之间已存在的联系，默认情况下拒绝最近的重复操作，应用程序完成重复协商的处理。

③注册正在等候的协商。

④同远端组件协商通信传输选项。

⑤如果组件可达，返回给本地组件一个会话句柄，会话句柄给密钥产生器定义体定义身份，并应用于协商传输的安全参数指数。⑥允许该组件新的协商信息。

在这里，组件可达意味着该远端组件已经初始化——从“”可以获得该组件的入港路由地址包，并且目前执行的是persistentlookup查询操作。

如果远端组件拒绝请求的协商，或者中间件不能授权该组件，则拒绝。

2）入港查询

执行persistentlookup查询时，在被查询一方，即远端组件一方，为了使自己能被接洽，使用匹配器提供的设施等待接洽，以便当接洽发生的时候，本地中间件能被通知。匹配器指定的设施使用认证/授权模块执行如下操作：

①锁定并行的协商信息。

②核实重复联系，即在客户端和远端组件之间是否已存在联系，重复协商的处理由应用程序执行，默认情况下拒绝最近的重复操作。（以上两步同出港查询）

③如果组件执行的不是persistentlookup操作，则失败，这包括被查询方没有初始化的情况。④如果组件执行persistentlookup操作不匹配远端组件，则失败。这可能由于事先在本地缓存中存储的组件源路由和实际不符。查询组件，首先查询localcache找组件的hostname对应的路由信息，执行其中的路由信息。当待查路由信息变更，则执行的路由信息和实际路由不符，查询失败。

⑤注册等待的协商，协商通信传输选项。

⑥返回本地组件表示密钥产生ID和用于此次协商的传输安全指数。

⑦允许该组件新的协商信息。

当客户端拒绝请求的协商，或者中间件不能授权远端组件的时候，则查询失败。

2.消息层、协商机制和消息处理部分

1)消息格式

消息格式如图4.10所示。图4.10消息格式

(1)Version：1字节，CIDF消息层版本(取值为1代表第一版）。

(2)ControlByte：1字节，控制位，表示可靠传输、流控制和安全协商管理。

—传递消息的认可（取值1）；

—消息收到，但是因为缺少资源没有传输（取值2）；

—消息收到，但是提供的安全协商不可用（取值4）。

(3)Checksum：2字节，校验位，整个CIDF消息的校验位。

(4)NextHeader：1字节，下一个头，定义下一个消息层选项或者应用程序选项。

—应用头部：ApplicationHeader（取值1）；

—路由列表：RouteList（取值4）；

—保密头部：PrivacyHeader(取值50）；

—认证头部：AuthenticationHeader(取值51）。

(5)Length：4字节，长度，包括消息头在内的CIDF消息长度。

(6)SequenceNumber：4字节，消息序列号，用于消息确认和重复删除。

(7)TimeStamp：4字节，时间戳，用于提供CIDF通信体之间的时间同步，以及有计划地延迟传输检测（对付拒绝服务攻击）。

(8)DestinationAddress：4字节，目的地址，标识目的接受方的IP地址。

通过将选项变量（Options（variable））分别指定为路由列表选项、保密选项和认证头选项，可以构建不同的消息。当保留字段（Reservedfield）为0，接收方忽略。

其中消息选项部分使用以下格式：

（1）路由列表选项（RouteListOption）（如图4.11所示）。图4.11路由列表选项①NextHeader：1字节，定义下一个头部中消息或者应用程序的类型，和消息格式中的“NextHeader”同义。

②Length：1字节，长度，指定此选项的32位字个数，包括“nexttype”和“lengthfields”在内。

③Subtype：1字节，子类型，指定是记录路由还是源路由

—RecordedRoute（取值1）；

—SourceRoute（取值2）。④Index:1字节，索引指针。对地址队列索引，指示当前将要被处理的地址。对于源路由，指示的是CIDF下一跳的地址；对于记录路由，这是上一个传递节点的地址。

⑤RouteData：路由数据，可变长度，该域是一列Internet地址。每个地址是32位二进制位，或者是4个8位字节。对于源路由，如果index超过length，源路由就是空的，根据Destination域确定路由。对于记录路由，如果index超过length，记录路由列表就是满的。（2）保密选项（PrivacyOption）（如图4.12所示）。图4.12加密选项①KeyGeneratorIdentity：4字节，密钥产生器标识符。该值标识产生密钥的CIDF实体，该域最先是指定密钥产生器的IP地址，或者对于组播应用程序。该值是指定使用这一安全协商的组播群的组播地址。

②SecurityParametersIndex（SPI）：4字节，安全参数索引。SPI是任意的32位值，该值唯一地标识这条消息的安全关联（通过协商所建立的安全通道），与密钥产生ID有关。

③Padding:可变长度，填充位。如果要求支持加密算法的块尺寸，发送方要填充达到255个字节。要求填充是要确保在使用保密选项以后，消息以4字节边界结尾。④PadLength：1字节，填充字节数量。有效值范围是0~255。

⑤NextHeader：定义同消息格式中的“NextHeader”。（3）认证头选项（AuthenticationHeaderOption）（如图4.13所示）。图4.13认证头选项①NextHeader和Length定义同上。

②KeyGeneratorIdentity：4字节，密钥产生器标识符。该值标识产生密钥的CIDF实体，该域最先使用是指定密钥产生器的IP地址，对于组播应用程序，该值是指定使用这一安全协商的组播群的组播地址。

③SecurityParametersIndex(SPI）：4字节，安全参数索引。SPI是任意的32位值，该值唯一地标识这条消息的安全协商，与密钥产生ID有关。

④AuthenticationData(variable)：32位子变量数据，认证数据，该数据（例如数字签名）用于提供加密认证。

2)协商机制

CIDF消息层的默认传输层协议是基于UDP的可靠的CIDF消息机制。在默认的机制的基础上，通过协商来实现更高级的协议和服务。这里使用0x0CDF作为默认端口，CIDF消息层在这个端口监听到来的CIDF消息，如图4.14所示。图4.14协商选项结合协商选项中的传输选项，有三个传输选项。

（1）直接基于UDP的没有认可和重传的CIDF消息层；

（2）基于UDP的有认可和重传的CIDF消息层；

（3）直接基于TCP的面向连接的可靠的CIDF消息层。

应答方式的协商选项格式（OptionNegotiationMessageFormats）如下：

①Type：1字节，类型，指定请求的类型。对于协商消息，该值取1。

②Length：1字节，长度，指定该消息的32位字的数量，包括类型和长度域。

其中，选项请求变量（OptionRequest（variable））格式如图4.15所示。图4.15选项请求变量①Request:1字节，请求，指定请求的类型。请求类型如下：

—Want(取值1）:需要使用的服务；

—Can（取值2)：能够使用的服务。

②Length：1字节，长度。指定该选项请求的32位字数量，包括请求和长度域在内。

③Option:1字节，选项。正在被协商的选项，选项类型如下：

—Transport(取值1）；

—加密（取值2）；

—Authentication（取值3）。④Selection：1字节，选择。正在协商的选项值。

对于传输选项（Transportnegotiation）：

—None（取值0）。用于在没有可接收的选项的时候，拒绝和其它的CIDF节点通信。

—UDP（取值1)。

—ReliableUDP(取值2)。

—TCP(取值3）。

对于保密协商（Privacynegotiation）：

—None（取值0)。

—IPSEC（取值1）。

—SSL(取值2）。

—CIDF（取值3）。对于授权协商(Authenticationnegotiation）:

—None（取值0）。

—IPSEC（取值1）。

—SSL（取值2)。

—CIDF（取值3）。

现在，唯一指定的选项参数是用于传输协商的TCP/UDP端口号，其中选项参数为端口选项（如图4.16所示）。图4.16端口选项①Type：1字节，类型。指定选项参数的类型,对于端口号，该值为1。

②Length：1字节，长度。指定该消息的32位字数量，包括类型和长度域在内。

③TransportPortNumber:2字节，传输端口号。指定端口号的一方将在该端口监听随后协商地完成,通道两端选择各自的端口。

3）消息层处理

消息层处理主要由以下几个基本过程构成。

（1）标准过程。

①出港方向的消息处理。

传递CIDF消息的应用层发出请求，CIDF消息层就构建消息头，并追加消息到消息头后面。如果应用程序需要源路由，则CIDF消息层就使用源路由列表。如果应用程序要求消息使用记录的路由列表，CIDF消息层初始化记录路由列表。接下来，CIDF消息插入当前CIDF版本号，以及应用程序提供的目的地址，并把当前时间作为CIDF消息的时间戳。在CIDF消息中插入序列号。计算消息长度，并插入长度域。在消息传输之前计算并插入校验位（checksum）。校验位要在应用CIDF加密和认证机制之前插入。当使用加密或者认证机制，应用程序将根据安全协商的结果，加密并产生授权数据。如果没有安全协商，消息传输请求将会被拒绝。②入港方向的消息处理。

首先检查版本号，如果版本号无效，抛弃消息。对于保密或者认证消息，CIDF消息层将解密并认证该消息。

由于缺乏有效的安全协商，处理失败，CIDF消息层会发送回应到消息来源，回应是CIDF消息层的“header”，控制字节（ControlByte）设为4。

如果校验位（checksum）不是“0”，CIDF消息层会计算该校验位。

如果时间戳表示出现了不可预期的延迟，消息层通知应用程序。

如果目的地址不是本地CIDF节点，CIDF消息层将决定下一跳（使用源路由，如果提供的话），并调整序列号和时间戳。如果消息包含记录路由选项，CIDF消息层将会找到下一个出口的IP地址，并将由之转发。

处理完毕以后，CIDF节点将会计算校验位，并放置在Checksum域。

最后，消息层对下一跳应用保密和认证变换，并传输消息。（2）可靠的消息传输过程。

①出港方向的消息处理。

计算出来回的传输延迟并得出相应的在每个传输节点的延迟偏移值。CIDF消息层使用标准TCP算法计算出在每个传输节点的传输延迟。消息层为每个消息保留一个消息副本以备重传，并对该消息设置超时计时器。在消息被确认之前，如果计时超时，消息层就对该消息执行重传操作，最多可重传五次。

当发送方接收到确认消息以后，CIDF消息层就从重传队列中去掉相应的消息。②入港方向的消息处理。

消息层接收到消息，就向消息源发出确认消息。确认消息和原来的消息头相似，除了控制字节不同。如果消息层能把消息传到应用层，控制字节为1;否则，控制字节为2。

(3)保密过程。

①出港方向的消息处理。

消息层把CIDF应用数据封装在保密头和保密尾之间，然后把应用数据和保密尾放在一起加密。加密算法采用对称加密算法。保留原有的CIDFHeader，但是需修改NextType，以表明这是个加密的CIDF消息。如果CIDF消息层正在对消息应用保密机制，消息层应当决定对目标消息的安全协商（用来决定算法）添加必要的填充，计算填充长度并将其插入尾，接下来插入NextHead到尾，再执行对文本消息的加密转换，最后在密文产生之前插入安全协商标识符（密钥产生器标识符和SPI）。NextHead设置为50。②入港方向的消息处理。

收到含有CIDF保密头的消息，CIDF消息层查询安全协商（安全关联），之后重建CIDF应用数据。（4）CIDF认证过程。

①出港方向的消息处理。

使用认证机制，决定对消息目标的安全协商（用于决定算法），插入认证头的长度，插入nextheader到认证头，在产生密文以前插入安全协商标识符（KeyGenerator标识符和SPI），接下来执行加密转换。这里NextHead设置为51。传送一方根据完整性校验值ICV（IntegrityCheckValue）密钥和安全协商指定模式的哈希算法，计算整个消息的完整性校验值ICV，并根据ICV长度进行必要的填充。

如果privacy被选择连接到CIDF认证，则先加密，后认证，加密不包括认证数据域。②入港方向的消息处理。

收到包含有CIDF认证头的CIDF消息，CIDF消息层就查询安全协商，即根据认证头中的SPI和密钥产生器的ID计算完整性校验值ICV的算法和密钥。如果没有有效的授权头，抛弃该消息，接下来验证ICV。4.1.3

CIDF语言

为了实现软件的复用和组件之间的互操作性，CIDF定义了一种应用层的语言CISL（CommonIntrusionSpecificationLanguage，通用入侵描述语言），用来表示CIDF中的各种信息，如原始事件信息、分析结果、响应提示等。

CISL是CIDF的最核心也是最重要的内容。

要建立一个CISL并非易事，它必须能够满足以下要求：

（1）有丰富的表达能力，能够表示各种入侵行为及其相应的处理方法；（2）表达唯一，不能产生二义性；

（3）语言精确，对每一种表达的含义作出明确的定义；

（4）可分层次，不同层次的组件能够得到不同的信息；

（5）可自定义，能够解释自己需要得到的信息；

（6）高效率，尽可能少地占用系统资源；

（7）可扩展性，可以增加新的表达内容而不影响整个语言结构；

（8）语言简朴，语言可以被快速编码和解码；

（9）可移植性，语言能够支持多种操作系统平台及多种传输机制；

（10）易于实现。

1.S-表达式

为了能够满足以上要求，CISL使用了一种类似Lisp语言的S表达式，它的基本单位由语义标志符（SemanticIDentifiers，以下简称为SID）、数据和圆括号组成。例如:（HostName′′），其中,HostName为SID，表示后面的数据是一个主机名，′′为数据，括号将两者关联。

S-表达式是一种抽象的数据结构，可以由原子递归定义如下：

(1)原子是S表达式；

(2)如果a1、a2是S-表达式，则表（a1，a2）也是S表达式；

(3)有限次使用（1）、（2）所得的表达式都是S表达式，此外没有别的S表达式。

2.CISL的语法和语义

下面是一个简单的例子:

(And

（OpenApplicationSession

（When

（Time14:57:3624Feb1998）

）

（Initiator

（HostName′′）

）

（Account

（UserName′joe′）（RealName′JoeCool′）

（HostName′′）

（ReferAs0x12345678）

）

（Receiver

（StandardTCPPort23）

）

）

（Delete

（WorldUnix）

（When

（Time14:58:1224Feb1998）

）

（Initiator

（ReferTo0x12345678）

）

（FileSource

（HostName′′）

（FullFileName′/etc/passwd′）

）

）

（OpenApplicationSession

（WorldUnix）

（Outcome

（CIDFReturnCodefailed）

（Comment′/etc/passwdmissing′）

）

（When

（Time15:02:4824Feb1998））

（Initiator

（HostName′′）

）

（Account

（UserName′mworth′）

（RealName′MaryWorth′）

（HostName′′）

）

（Receiver

（StandardTCPPort23）

）

）

）粗略的翻译一下就会发现，有三个动作按顺序发生：

首先，有人用′joe′（真实名字是′JoeCool′）在′′登陆账户，登陆主机名′′。

然后，大约半分钟以后，同一个人，从′′删除了′/etc/passwd′这个文件。

最后，大约4.5分钟以后，一个用户试图在′′用′mworth′账户登陆，但没有成功。一个用户在′′进行的登陆尝试完成了初始化。在这里可以找到几种不同种类的CISL定义的7类SID，分别是：

动词SID，如Delete和OpenApplicationSession;

角色SID，如Initiator和FileDestination;

副词SID，如Outcome和When;

属性SID，如Owner;

原子SID，如UserName和Time;

指示SID，ReferTo、ReferAs;

连词SID，如And。动词SID，句子的核心是动词。通常，动词指定一个动作，但是也可以表示一个建议。例如，上个例子中，动词的例子是DELETE。一个句子必须包含至少一个动词。如果只有一个动词，必须放在顶端（例如，起始位置），这样的句子成为简单句。简单句由连词SID连接在一起，或者依附于被其它动词，这样的句子分别被称做复合句和复杂句。

角色SID，指明实体在句子中是什么角色。例如，上个例子中，角色SID是Initiator。像动词一样，角色SID起到加强S表达式的作用。这些S表达式标识描述角色。以角色SID打头的S表达式被称为角色从句。角色表达式描绘的是对象。副词SID描绘动词SID发生的时间、空间或者修改它的意思。例如,上述例子中的When和Outcome。

属性SID和角色SID一样，是描述对象的。但是，属性SID只出现在角色SID下面。用于描绘实体，这个实体和包含角色从句的实体有关系。例如，一个删除句的目标文件有所有者，以及其它的属性。这种情况下，要把目标文件在源文件从句中标识出来，例如：

（FileSource

<informationaboutthefile>

（Owner

<informationaboutthefile‘sowner>

）

）原子SID是S表达式的最基本部分，动词、副词、属性、角色SID都是原子在构成句子时，所处的位置，即原子SID把这些位置实例化。例如在一个角色SID“Initiator”中，常常可以发现原子SID用来描述和标识Initiator（初始化者）。例如，Username和IPv4Address是原子SID。原子SID把动词、副词、属性、角色SID实例化，例如，Username和IPv4Address。

连词SID，顾名思义，就是用于把句子连接起来。最常用的连词SID是“And”，如（And<Sentence1><Sentence2>），只表示把两个句子连接在一起，既不说明关于句1和句2的发生顺序，也不阐述两个句子之间的因果关系。不过，其它种类的连词SID可以表达句子之间的关系，例如“ByMeansOf”，（ByMeansOf<Sentence1><Sentence2><Sentence3>）表示句1、句2、句3都发生，并且句3是句2发生的方式，句2是句1发生的方式。

指示SID用于组合同一句子的两个或多个部分，只有两个指示SID：ReferTo、ReferAs。

这些SID，S表达式以及S表达式的组合、递归、嵌套等构成了CISL的全部表达能力，即CISL本身。在计算机内部处理CISL时，为节省存储空间和提高运行效率，必须对ASCII形式的S表达式进行编码，将其转换为二进制字节流的形式，编码后的S表达式就是GIDO。所以，GIDO是S表达式的二进制形式，是CIDF各组件统一的信息表达格式，也是组件之间信息数据交换的统一形式。

在CISL中，还对GIDO的动态追加、多个GIDO的组合，以及GIDO的头结构等进行了定义。

应用CISL可以定义所有的攻击事件、攻击模式、统计结果和相应请求。其中最难定义的是攻击事件，以下是用CISL定义的一个攻击事件的例子:

(ByMeansOf

（AcquireProxy

（WorldUnix）

（When

（Time18:27:52

25May2000UTC）

）

（Initiator

（HostName

′′）

（ReferAs

0x01010101）

）

（Proxy

（HostName

′′）

（UserName

′root′）

）

）（Attack

（Outcome

（ReturnCodesuccess）

）

（When

（Time18:27:52

25May2000UTC）

）

（Initiator

（ReferTo0x01010101）

）

（Target

（HostName

′′）

）

（AttackSpecifics

（AttackID

0x0000000100000057）

（Certainty100）

（Severity60）

）

）（And

（ConnectTCP

(When

（Time18:27:45

25May2000UTC）

）

（Initiator

（ReferTo0x01010101）

）

（Receiver

（HostName

′′）

（StandardTCPPort

79）

（ReferAs

0x0202020202）

）

）

（SendMessage）

（When

（Time18:27:52

25May2000UTC））

（Initiator

（ReferTo

0x0101010101）

）

（Receiver

（ReferTo0x02020202）

）

（Message

（ByteSize21456）

）

）

）

）这个攻击事件用语言描述如下：2000年5月25日18时27分45秒，一台域名为“”的Unix操作系统的机器受到了来自“”的缓冲区溢出攻击。攻击者在25日18时27分45秒与79号端口建立了TCP连接，并且在25日18时27分52秒发送了21456个字节的攻击数据。攻击者成功地实施了攻击，攻击的严重性为60%。4.1.4

CIDF的API接口

CIDF定义了—套API以方便开发人员使用GIDO，也为了方便底层的实现。CIDF主要定义的是和GIDO相关的编码、解码以及传输所使用的API。CIDF的API提供的调用功能使得程序员可以在不了解编码和传递过程具体细节的情况下，以一种很简单的方式构建和传递GIDO。

GIDO的生成分为两个步骤：第一，表示GIDO的树型结构；第二，将此结构编码成字节码形式。在构造树型结构时，SID被分为两组：一组把S表达式作为参数（即动词、副词、角色、连接词等），另一组把单个数据或一个数据队列作为参数（即原子SID），这样就可以把一个完整的句子表示成一棵树，每个SID表示成一个节点，最高层的SID是树根。因为每个S表达式都包含一定的数据，所以，树的每个分支末端都有表示原子SID的叶子。举例说明，假如V是个动词SID，R1和R2是角色SID，从A1到A3都是原子SID，那么这个S表达式为

（V

（R1

（A1data1）

（A2data2）

）

（R2

（A3data3）

）

）图4.17

GIDO的树型结构可以表示成如图4.17所示的树。

由于编码规则是事先定义好的，因此对一棵树进行编码只是一个深度优先遍历和对各个节点依次编码的过程。在这种情况下，可以先对V编码，然后对R1子树编码，再对R2子树编码。如果上面的句子是一个复合句的一部分，那么，每个成分句都可以从中完好地提取出来。另外，如果句子自身已经编码，要插入到复合句，不需要重新编码。

将字节码进行解码的过程跟编码的过程正好相反，在SID码的第一个字节里有一个比特位指示其需要的参数是基本数据类型，还是S表达式序列。然后，语法分析器再对后面的字节进行解释。CIDF的API并不能根据树结构构建逻辑GIDO，但提供了将树以普通GIDO的S表达式格式进行打印的功能。

CIDF的API为实现者和应用程序开发者都提供了很多的方便，它包括以下几部分内容：

GIDO编码和解码API（GIDOEncoding/DecodingAPISpecification）；

消息层API（MessageLayerAPISpecification）；

GIDO动态附加API（GIDOAddendumAPI）；

签名API（SignatureAPI）；

顶层CIDF的API（TopLevelCIDFAPI）。

每类API均包含数据结构定义、函数定义和错误代码定义等。 4.2

IDWG的建议草案

4.2.1入侵检测消息交换格式

1.数据模型需要解决的问题

数据模型需要解决以下问题：

（1）报警信息之间是有很多差异的。一些报警只描述出很少的信息量。比如，来源、目的地、名字、发生事件的时间等。而另一些报警信息提供很多的信息量，如端口或者服务、进程、用户信息等。这就要求描述这些信息的数据模型必须能灵活地适应不同的需求。（2）入侵检测环境是有差异的。一些分析器通过分析网络流量来检测攻击，其它一些分析器则使用操作系统的日志文件或者应用程序的审计信息来检测攻击。即使由同一个攻击引发的报警信息，使用不同信息源的分析器，其报警也不可能包含同样的信息。

（3）分析器的能力是有差异的。根据系统环境的不同，一些系统只装备了轻量级分析器，只能提供很少的报警信息；另一些系统安装了复杂的分析器，可以对系统做出更多的反应，从而提供更详细的警报信息。所以，为了进一步处理警报信息，数据模型必须允许使用工具对数据格式进行转换，而不是使用分析器。（4）操作环境是有差异的。根据使用的网络操作系统的不同，攻击会具有不同的特征。数据模型应该适应这些差异。

（5）商业用户是不同的。对同一种攻击，不同的用户可能会要求传递不同信息量的攻击信息，有的希望多传一点，而有的希望少传一些。

2.IDMEF数据模型

为了满足上述要求，IDWG提出了IDMEF数据模型。

针对上述的问题(1)，数据模型采用面向对象的方式，通过聚集或者子类，在保持了模型的持续性的同时，实现了模型的扩展。

为了解决问题(2)，数据模型定义的支持类能适应这些不同分析器中数据来源的差异。特别是，对于由节点、进程、服务、用户类结合在一起来表示警报的来源和目标。

对于问题(3)，数据模型定义了对基本文件类型定义（DTD）的扩展，从而既允许传递简单的警报，也可以传递复杂的警报。DTD的扩展通过子类或者新类的协助取得。对于第(4)个问题，在节点和服务类中，允许报告具有很大的灵活性。如果需要报告额外的信息，可以通过定义子类，用添加属性的方法扩展数据模型。

对于第(5)个问题，它采用面向对象的方法，在其子类规则保证了数据模型的完整性的同时，也为用户提供了灵活性。综上所述，IDMEF描述了一种表示入侵检测系统输出消息的数据模型，并且解释了使用这个模型的基本原理。该数据模型用可扩展的标识语言(XML）实现。自动的入侵检测系统能够使用IDMEF提供的标准数据格式，来对可疑事件发出警报。这种标准格式的发展将使得在商业、开放资源和研究系统之间实现协同工作的能力，同时允许使用者根据他们的强点和弱点获得最佳的实现设备。IDMEF最适合的地方是入侵检测分析器（或称为探测器）和接收警报的管理器（或称为控制台）之间的数据信道。

IDMEF数据模型以面向对象的形式表示探测器发送给控制台的警报数据。数据模型的设计目标是用一种明确的方式提供对警报的标准表示法，并描述简单警报和复杂警报之间的关系。图4.18

IDMEF的数据模型图在IDMEF数据模型中，实体被定义为类。IDMEF包括的类主要有IDMEFMessage类、Alert类、Heartbeat类、Core类、Time类和Support类。这些类还可以再细分为许多子类，以表示更确切的消息。

IDMEF本身并不对收到的警报信息进行分类和鉴别处理，这一工作是由分析器来完成的。例如，当用户机器的某一端口收到大量的数据包时，一个分析器可能将其确定为一个具有多目标的单一攻击，而另一个分析器可能将其确定为来自同一个源的多次攻击。只有一个分析器决定了发送的警报类型，数据模型才能规定怎样对这个警报进行格式化。下面对主要的类进行介绍。

1)IDMEF-Message类

所有的IDMEF消息都是IDMEFMessage类的实例。IDMEFMessage类是IDMEF数据模型以及IDMEFDTD的最顶层类，它由两个子类构成：Alert类和Heartbeat类。

IDMEF-Message类只有一个属性：version。该属性用来标示IDMEFMessage规定的版本，应用程序必须指定该值为“1.0”。

2)Alert类

一般来讲，每当分析器探测到预先设定寻找的事件后，就发送一个消息给他的管理器。根据分析器的需要，报警消息可以对应于一个或者多个被检测到的事件。报警和相应的外部事件异步进行。

一个Alert消息由几个复合类组成，如图4.19所示。这里只对ToolAlert类、CorrelationAlert类和OverflowAlert类进行阐述，其它复合类稍后阐述，Analyzer、Source、Target、Classification、AdditionalData见Core类部分；CreateTime、DetectTime、AnalyzerTime见Time类部分；Assessment见Assessment类部分。图4.19

Alert类

Alert类只有一个属性：messageid。该属性作为告警信息的唯一标识符，字符串型(string)。

（1）ToolAlert类。

该类携带与攻击工具或者恶意程序（如木马）相关的附加信息，以供可以识别这些工具的分析器使用。它把一些警报信息集合在一起，以显示“这些告警都是因为使用这种工具而产生的。”ToolAlert由三个集合类构成，如图4.20所示。图4.20

ToolAlert类构成ToolAlert的聚集类如下：

Name：描述把警报归类到一起的原因。例如，这些告警都是因为使用这种工具而产生的，用Name指出特定工具的名称。

Command：攻击被要求执行的命令或操作。例如，BackOrificeping。

Alertident：与这个警报有关的警报标识符列表。因为警报标识符在该分析器发出的警报中具有唯一性，Alertident的Analyzerid属性应被用于标识产生警报的分析器。如果不提供Analyzerid，警报就被认为来自发送ToolAlert的同一个分析器。（2）CorrelationAlert类。

该类携带与报警信息的相互关系有关的信息。它把一些报警信息集合在一起，以显示“所有这些报警都是相关的”。CorrelationAlert类由两个集合类构成，如图4.21所示。

CorrelationAlert类的聚集类如下：

Name:把警报归类到一起的理由。例如，某种关联方法。

Alertident：与该警报有关的警报标识符列表。图4.21

CorrelationAlert类（3）OverflowAlert类。

该类携带与缓冲区溢出攻击（Overflow）相关的附加信息，可以向分析器提供溢出攻击的细节。它由三个复合类构成，如图4.22所示。

ＯverflowAlert类的聚集类如下：

Program：Overflow攻击要执行的程序。

Size:按字节计算溢出的大小。例如，攻击者发送的字节数量。

Buffer：溢出数据本身的部分或者全部，取决于分析器的捕获能力。图4.22

OverflowAlert类

3)Heartbeat类

分析器使用Heartbeat消息向管理器指示当前的状态。Heartbeat需要定期发送，即每隔10分钟或者每1小时发送一次。管理器从分析器接收到Heartbeat消息，表明分析器是开启的并正在运行；缺乏Heartbeat消息（或者更可能的情况，缺乏连续消息）表明分析器或者它的网络连接已经失败。

所有的管理器都必须支持Heartbeat消息的接收，但是这些消息的使用是可选的。管理器软件的开发人员应当允许根据每个分析器的情况设置使用或者不用Heartbeat消息。

Heartbeat消息由几个复合类构成，如图4.23所示。图4.23

Heartbeat类

Heartbeat类有一个属性：messageid，可选参数，Heartbeat的唯一标识符。

Heartbeat类的聚集类构成：

Analyzer类、AdditionalData在后面的Core类部分介绍；CreateTime、AnalyzerTime在Time类部分介绍。

HeartbeatInterval:Heartbeat消息的产生时间间隔，以秒为单位。

Analyzer类、AdditionalData在后面的Core类部分介绍。

CreateTime、AnalyzerTime在Time类部分介绍。

4)Core类

Core类是Alerts类和Heartbeats类的主要部分，包括Analyzer、Source、Target、Classification和AdditionalData，如图4.24所示。图4.24

Core类（1）Analyzer类。

该类鉴别出产生Alert或者Heartbeat消息的分析器。对应于每一个分析器Alert或者Heartbeat消息，只可能有一个分析器，那就是产生Alert或者Heartbeat消息的分析器。分析器构成见图4.25。图4.25

Analyzer类构成Analyzer类的聚集类包括：Node类、Process类和Analyzer类，在随后描述。

Analyzer类有八个属性：

Analyzerid：可选参数，分析器的唯一标识符。

Name：可选参数，比Analyzerid更易于理解。

Manufacturer：可选参数，Analyzer软件或者硬件的生产厂家。

Model：可选参数，Analyzer软件/硬件的款式名称/型号。

Version：可选参数，Analyzer软件/硬件的版本号。

Class：可选参数，Analyzer软件/硬件的种类。

Ostype：可选参数，操作系统名称。

Osversion：可选参数，操作系统版本。（2）Classification类。

该类提供报警的Name或其它信息，以供管理器决定这是什么报警。这个