分类： 网络与安全
2010-04-17 21:25:09
值得注意的是，IETF规定IDS对其它设备交互的方式采用XML格式存储和传输，和SOAP似乎有些相似，XML跨平台跨语言结构清晰等优点使它的应用范围越来越广，几乎达到了无处不用XML的程度。
1. 入侵检测消息交换
(1) 建立连接
使用IDXP传输数据的入侵检测实体被称为IDXP对等体。对等体只能成对出现，这些对等体通过BEEP会话中的一个或多个BEEP信道进行数据传输。对等体可能是管理器或分析器。
在分析器和管理器之间很可能是多对多的关系。即一个分析器可以和多个管理器通信，同样，一个管理器也可以和多个分析器通信；在不同的管理器之间也可以是多对多的关系。所以，一个管理器可以通过多个中间管理器接收大量的来自分析器的报警信息。但是，各个分析器之间禁止建立IDXP连接，避免重复报警情况的发生。
IDXP对等体之间通过打开一个BEEP信道进行通信。在打开BEEP信道之前，需要首先建立BEEP会话，然后就安全特性等问题进行协商。BEEP安全轮廓协商成功后，再经互相确认应答，然后开始IDXP交换。
对等体"Alice"和"Bob"建立IDXP交换的过程
Alice Bob
------------------- 建立连接(1) -------------------->
<---------------------- 问候 ------------------------>
<------------------ 启动安全轮廓(2) ----------------->
<---------------------- 问候 ------------------------>
<------------------- 启动 IDXP(3) ------------------->
备注:
(1) "Alice"建立一个到'Bob'的连接, 并触发交换二者BEEP问候消息。
(2) 两个实体协商BEEP安全轮廓。
(3) 两个实体协商IDXP轮廓。
在一对IDXP对等体之间可以存在多个代理，这些代理可能是因为管理的需要。比如透过防火墙进行受限访问，或是将公司各部门分析器的数据转发到公司总管理器。
在使用代理转发数据时，会使用BEEP协调轮廓建立一个应用层的隧道。隧道轮廓(详细见"RFC3620 - The TUNNEL profile")即在此时发挥作用。在创建应用层隧道时，必须建立一个作为协调轮廓的隧道，并且该隧道轮廓需要进行SASL认证。隧道建立完成后，BEEP安全轮廓才可以提供IDXP协商时需要的各项安全特性。
对等体"Alice"和"Bob"通过代理服务器建立IDXP交换
Alice proxy1 proxy2 Bob
----- 建立连接 ---->
<------ 问候 ------->
---- 启动隧道 ----->
--- 建立连接(1) ---->
<------- 问候 ------->
----- 启动隧道 ----->
----- 建立连接 ----->
<------- 问候 ------->
----- 启动隧道 ----->
<---- <确认>(2) -----
<------ <确认> ------
<----- <确认> ------
<--------------------------- 问候 ---------------------------->
<----------------------- 启动安全轮廓 ------------------------>
<--------------------------- 问候 ---------------------------->
<------------------------- 启动 IDXP ------------------------->
备注:
(1) 收到"Alice"启动隧道的消息后，"proxy1"并没有立即返回确认消息，而是先试图和"proxy"连接以建立隧道。同样的，"proxy2"也不会立即给"proxy1"返回确认消息。
(2) "Bob"的确认信息首先到达"proxy2"并且与之启动隧道，然后确认消息会传递下去最终返回给"Alice"，最终"Alice"和"Bob"之间就成功建立了应用层的隧道。
(2) 数据传输
在一对入侵检测实体通过BEEP会话进行通信时，会使用IDXP轮廓打开一个或多个BEEP信道。如果需要，可以用IDXP轮廓建立更多的BEEP会话，以提供额外的信道。但是在多数情况下，还是应该在已有的BEEP会话中添加新的信道，尽量避免用新建BEEP会话的方式添加信道。
在每条信道中，对等体都是以客户端/服务器形式进行通信。客户端和服务器的角色扮演决定于建立BEEP会话的发起者和监听者。即发起者为客户端，监听者为服务器。
+----------+ +----------+
| | | |
| |******** BEEP 会话 *******| |
| | | |
| 分析器 | ------- IDXP 轮廓 -----> | 管理器 |
| (客户端) | | (服务端) |
| | | |
| |**************************| |
| | | |
+----------+ +----------+
在一个BEEP会话中使用多个BEEP信道的方式对IDXP对等体之间传输数据的分类和优先级的管理非常有利。例如，管理器"M1"向"M2"发送报警数据时，可以将不同类型的信息使用单独的信道进行传输。"M1"在这些信道中扮演了客户端的角色，"M2"则对接收到的报警信息根据其不同类型进行相应处理。
+----------+ +----------+
| | | |
| |**************** BEEP 会话 *****************| |
| | | |
| | ----- IDXP 轮廓, 基于网络的报警信息 -----> | |
| 管理器 | | 管理器 |
| M1 | ----- IDXP 轮廓, 基于主机的报警信息 -----> | M2 |
| (客户端) | | (服务端) |
| | -------- IDXP 轮廓, 其它报警信息 --------> | |
| | | |
| |********************************************| |
| | | |
+----------+ +----------+
(3) 断开连接
在一些情况下(如处理过程中出现错误)，IDXP对等体可以关闭某个IDXP信道。要关闭某条信道，需要在零号信道上发送一条"关闭"的指令，并且指明所关闭的信道。如果想要关闭整个BEEP会话，只需在零号信道上发送一条要求"关闭"零信道的指令即可。
由于应用层隧道和BEEP安全轮廓会经常使用，所以凡是包含IDXP信道的BEEP会话将会一直存活下去。同时，为了避免IDXP信道被反复的建立，系统会一直保持这些IDXP信道的连接，即使当前已经没有数据在上面传输。建议当IDXP对等体在合适的时候，手动关闭并重建BEEP会话。
(4) 可信模型
在以上的模型中，BEEP安全轮廓是建立在IDXP对等体之间从而实现的端到端安全，而无需对中间代理建立信任。因此，只有在安全轮廓下经过协商后的IDXP对等体之间是相互信任的，而代理始终被看作是不可信的。
2. 入侵检测消息交换格式
(1) IDMEF数据模型
IDMEF数据模型的各主要部分关系如图1所示（这里省略了事件指示器和属性）。
图1: 数据模型
IDMEF消息的最高层类是"IDMEF-Message"，其它各类型消息都是该类的子类。目前IDMEF定义了两种消息："Alerts"和"Heartbeats"。其中这两个消息各自携带不同的子类，各子类又描述了更加详细的信息。
需要注意的是，数据模型并没有指明警报信息如何分类和识别。例如，端口扫描这一行为，它可能被分析器识别为一次单点对多目标的攻击，同时被另一分析器识别为多次的单点攻击。所有，只有在分析器确定了报警类型之后，数据模型才能确定如何对报警数据进行格式化。
(2) 示例
IDMEF数据模型最终是以XML形式实现，XML跨平台、跨语言以及强扩展性的特点保证了IDS设备之间共享信息时良好的兼容性。
下面用实例说明IDMEF对报警信息封装的格式。这些例子只是为说明用，不具备代表性。
基于网络检测到的某次泪滴攻击报警信息
|
|
基于网络检测到的某个端口扫描行为（注意
|
|
3. 参考资料
1. RFC4765 - The Intrusion Detection Message Exchange Format (IDMEF)
2. RFC4767 - The Intrusion Detection Exchange Protocol (IDXP)
