自主元素模型控制系统、方法及服务器受侵保护检测系统

摘要

本发明公开了自主元素模型控制系统、方法及服务器受侵保护检测系统，清晰的表达依次运用两个控制循环来实现自主管理的设计理念。其技术方案为：一种含两个控制循环的自主元素模型的控制系统，包含一个自主管理装置和两个被管装置，而自主管理装置本身包含两个不同的控制循环，每个控制循环经过“监视-分析-规划-执行”的四个步骤来实现被管装置的管理任务，更加清晰的表达依次运动两个控制循环(这两个控制循环的内容有所不同但它们仍共享同一个知识库)来实现自主管理的设计理念。本发明将自主元素模型的控制系统应用于web服务器受侵检测和保护的系统，其中智能化的部份是基于自主计算技术(即含两个控制循环的自主元素模型)来实现的。

说明书

技术领域

本发明涉及计算机软件的自主计算技术和Web技术领域，尤其涉及一种新的含两 个控制循环的自主元素模型的控制系统和控制方法，以及基于该模型控制系统来实现 智能化的Web服务器受侵检测和保护的系统。

背景技术

自主计算(autonomic computing)又称自治计算，是美国IBM公司的P.Horn于 2001年10月在Autonomic Computing：IBM’s Perspective on the State of Information  Technology一文中提出的一种新概念及参考标准。IBM将自主计算定义为“能够保证 电子商务基础结构服务水平的自我管理(self-managing)技术”。其最终目的在于使信 息系统能够自动地对自身进行管理，并维持其可靠性。

关于自主计算的定义，目前的看法尚不统一，根据Kephart的The Vision of  Autonomic Computing一文一般认为自主计算系统应该至少具有如下4个主要特性：自 配置(self-configuration)、自修复(self-healing)、自保护(self-protection)和自优化(self- optimization)。其中，自配置是指系统能够根据高层策略自动配置自己，以适应环境的变 化；自修复是指当软/硬件发生故障或异常时，系统能够自动地发现、诊断和修复故障；自 保护是指当系统遇到恶意攻击或者由于自修复措施无效而发生连串失败时，能够从整 体上保护自己，同时，它也可以根据来自传感器的相关报告预测问题，并采取措施加以预 防；自优化是指系统能够不断寻找方法来改善性能、降低消耗。

自主计算系统(autonomic computing system)由若干相互联系的自主元素(autonomic  element)组成。在策略(policy)的指导下，这些自主元素在实现内部自适应的同时(即局部 自主管理)，通过交互和协作实现整个系统的自适应(即全局自主管理)。有关细节请参 见IBM的白皮书An Architectural Blueprint for Autonomic Computing中有关 Autonomic Computing Reference Architecture的描述。

自主元素(autonomic element)是自主计算系统的基本构造块，它由一个自主管理者 (autonomic manager)和一到多个被管元素(managed element)组成。被管元素既可以是各 种内部资源，包括数据库、服务器、路由器、应用模块、Web服务或虚拟机器等，也可 以是其他自主元素，例如负责全局编排的父自主元素可以管理多个下级的子自主元 素。被管理的内部资源一般都提供标准化的接口(touchpoint)。每个touchpoint对应于 一个传感器(sensor)/效应器(effector)组。单个自主元素一方面通过自主管理者管理内部 资源，另一方面，它向外提供标准接口(传感器/效应器组)接受管理，包括接受IT管理 者指定的策略以及与其他自主元素的协作信息等。自主管理者代替了那些原本需要人 工进行的管理工作，包括状态觉察和系统配置(configuration)、修复(healing)、优化 (optimization)和保护(protection)等。自主管理者通过一个“监视(monitor)-分析 (analyze)-规划(plan)-执行(execute)”控制循环(control loop)来实现这种管理任务。虽然 该控制循环本身可以多次重复进行，但从结构上讲，一个经典的自主元素只包含一个 循环。例如：美国专利US7490095 B2 Scope and Distribution of knowledge in an  Autonomic Computing System中的FIG.1。从已有专利来看，如：US7370098B2， US7490095B2，US7542956B2和US7657779B2，均着重于自主计算技术的细化和具 体应用，而没有对自主元素模型进行裁剪和修改。

发明内容

本发明的目的在于解决上述问题，提供了一种自主元素模型的控制系统，更加清 晰的表达依次运用两个控制循环来实现自主管理的设计方案。

本发明的另一目的在于提供了一种自主元素模型的控制方法，更加清晰的表达依 次运用两个控制循环来实现自主管理的设计理念。

本发明的又一目的在于提供了一种服务器受侵检测保护系统，基于自主计算技术 即含两个控制循环的自主元素模型来实现智能化。

本发明的技术方案为：本发明揭示了一种自主元素模型的控制系统，包括自主管 理装置、第一被管装置、第二被管装置、知识库装置、第一传感器接口、第一效应器、 第二传感器接口、第二效应器，所述自主管理装置内包括第一循环控制装置和第二循 环控制装置，其中第一循环控制装置包括第一监视模块、第一分析模块、第一规划模 块、第一执行模块，第二循环控制装置包括第二监视模块、第二分析模块、第二规划 模块、第二执行模块，其中所述第一循环控制装置和所述第二循环控制装置共享所述 知识库装置。

根据本发明的自主元素模型的控制系统的一项实施例，所述第一循环控制装置包 括：

所述第一监视模块，通过所述第一传感器接口收集、聚合、关联和过滤由所述第 一被管装置发来的事件，找出需要进一步分析的症状；

所述第一分析模块，连接所述第一监视模块，对症状进行进一步观察和分析，以 做出是否需要进行调整的决定；

所述第一规划模块，连接所述第一分析模块，产生相应的调整计划，以便对所述 第一被管装置或所述第二被管装置进行调整；

所述第一执行模块，连接所述第一规划模块，执行所述第一规划模块产生的调整 计划。

根据本发明的自主元素模型的控制系统的一项实施例，所述第二循环控制装置进 一步包括：

所述第二监视模块，当所述第一监视模块不能从所述第一被管装置中收集到所有 需要的症状或信息以明确病因时，收集、聚合、关联和过滤由所述第二被管装置发来 的事件，找出进一步分析所需要的症状或信息；

所述第二分析模块，连接所述第二监视模块，根据所述知识库装置中存储的信息 对从所述第二被管装置中收集到的症状或信息进行进一步的分析，以做出是否需要进 行调整的决定，其中所述知识库装置中存储的信息包括所述第一监视模块收集到的症 状或信息；

所述第二规划模块，连接所述第二分析模块，产生相应的调整计划，以便对所述 第二被管装置进行调整；

所述第二执行模块，连接所述第二规划模块，执行所述第二分析模块产生的调整 计划。

本发明还揭示了一种自主元素模型的控制方法，在自主元素模型的控制系统上实 施，所述自主元素模型的控制系统包括自主管理装置、第一被管装置、第二被管装置、 知识库装置、第一传感器接口、第一效应器、第二传感器接口、第二效应器，自主管 理装置包括第一循环控制装置和第二循环控制装置，其中第一循环控制装置包括第一 监视模块、第一分析模块、第一规划模块、第一执行模块，第二循环控制装置包括第 二监视模块、第二分析模块、第二规划模块、第二执行模块，其中第一循环控制装置 和第二循环控制装置共享所述知识库装置。

根据本发明的自主元素模型的控制方法的一项实施例，所述控制方法包括：

第一监视模块收集、聚合、关联和过滤由第一被管装置发来的事件，找出需要进 一步分析的症状；

第一分析模块对症状进行进一步观察和分析，以做出是否需要进行调整的决定；

第一规划模块产生相应的调整计划，以便对第一被管装置或第二被管装置进行调 整；

第一执行模块执行第一规划模块产生的调整计划；

其中当第一监视模块从第一被管装置收集到所有需要的症状或信息时，一个控制 循环就能完成一个管理任务而不必进入第二个控制循环。

根据本发明的自主元素模型的控制方法的一项实施例，该控制方法还包括：

当第一监视模块不能从第一被管装置收集到所有需要的症状或信息时，第一执行 模块发出信息或请求，以便进一步从第一被管装置收集所有需要的信息，开始第二个 控制循环：

第二监视模块收集、聚合、关联和过滤由第二被管装置发来的事件，找出进一步 分析所需要的症状或信息；

第二分析模块根据知识库模块中已有的信息对从第二监视模块收集到的症状或信 息进行进一步的分析，以做出是否需要进行调整的决定；

第二规划模块产生相应的调整计划，以便对第二被管装置进行调整；

第二执行模块执行第二规划模块产生的调整计划。

本发明还揭示了一种服务器受侵检测保护系统，基于自主元素模型的控制系统， 所述服务器受侵检测保护系统包括http请求数据收集装置、http响应数据收集装置、 自主管理装置、用户接口装置、知识库服务器，其中自主管理装置包括请求控制循环 装置和响应控制循环装置，其中：

http请求数据收集装置，收集http的请求数据，在http层过滤掉请求中不需要的 数据，然后将需要的数据传送给自主管理装置；

http响应数据收集装置，收集http的响应数据，在http层过滤掉响应中不需要的 数据，然后将需要的数据传送给自主管理装置；

请求控制循环装置，检测拒绝和防止所有已知类型的恶意请求；

响应控制循环装置，修改响应中包含的非法内容；

知识库服务器，存储用于判断请求或响应是否正常的定义规则、关于请求和响应 的统计数据和动态分析信息；

用户接口装置，是系统控制台，对知识库服务器提供人工管理和干预。

根据本发明的服务器受侵检测保护系统的一项实施例，所述请求控制循环装置包 括请求监视模块、请求分析模块、请求规划模块以及请求执行模块，其中：

请求监视模块，监视用户通过互联网发送过来的http请求，根据知识库服务器提 供的定义规则，将其中的http异常请求传递给请求分析模块，将http正常请求直接发 送到服务器上的应用程序中；

请求分析模块，连接请求监视模块，根据知识库服务器提供的信息，对请求监视 模块传来的http异常请求进行分析，将分析结果存储到知识库服务器中；

请求规划模块，连接请求分析模块，根据知识库服务器提供的信息决定自主管理 装置下一步应采取的行动，并将行动步骤通知请求执行模块；

请求执行模块，连接请求规划模块，根据请求规划模块的决定实施行动。

根据本发明的服务器受侵检测保护系统的一项实施例，所述响应控制循环装置包 括响应监视模块、响应分析模块、响应规划模块、响应执行模块，其中：

响应监视模块，监视从应用程序发送回用户的http响应，基于知识服务器提供的 定义，将异常的http响应传输给响应分析模块，将正常的http响应直接通过互联网发 送给用户；

响应分析模块，连接响应监视模块，根据知识库服务器提供的信息，对从响应监 视模块传来的异常的http响应进行分析，将分析结果存储到知识库服务器中；

响应规划模块，连接响应分析模块，根据知识库服务器提供的信息，决定自主管 理装置下一步应采取的行动，并将行动步骤通知响应执行模块；

响应执行模块，连接响应规划模块，根据响应规划模块的决定而实施行动。

根据本发明的服务器受侵检测保护系统的一项实施例，在应用程序处理正常http 请求和产生正常http响应，以及应用程序再次受到某种恶意http请求和产生正常http 响应时，服务器受侵检测保护系统中仅有请求监视模块参加请求控制循环，以及响应 监视模块参加响应控制循环。

根据本发明的服务器受侵检测保护系统的一项实施例，在应用程序处理正常的 http请求和产生异常http响应时，服务器受侵检测保护系统中的请求监视模块参加请 求控制循环，响应监视模块、响应分析模块、响应规划模块、响应执行模块均参加响 应控制循环。

根据本发明的服务器受侵检测保护系统的一项实施例，在应用程序第一次处理某 种异常http请求和产生正常http响应，以及应用程序第一次处理某种异常http请求和 产生异常http响应时，服务器受侵检测保护系统中的请求监视模块、请求分析模块、 请求规划模块和请求执行模块参加请求控制循环，服务器受侵检测保护系统中的响应 监视模块、响应分析模块、响应规划模块、响应执行模块参加响应控制循环。

根据本发明的服务器受侵检测保护系统的一项实施例，当应用程序再次受到某种 恶意的http请求而立即拒绝时，服务器受侵检测保护系统中仅有请求监视模块、请求 分析模块、请求规划模块和请求执行模块参加请求控制循环，没有响应控制循环。

本发明对比现有技术有如下的有益效果。本发明提出了一种含两个控制循环的自 主元素模型的控制系统，包含一个自主管理装置和两个被管装置，而自主管理装置本 身包含两个不同的控制循环，每个控制循环经过“监视(monitor)-分析(analyze) -规划(plan)-执行(execute)”的四个步骤来实现被管装置的管理任务，这一系统 可以更加清晰的表达依次运动两个控制循环(这两个控制循环的内容有所不同但它们 仍共享同一个知识库)来实现自主管理的设计理念。本发明将自主元素模型的控制系 统应用于web服务器受侵检测和保护的系统，其中智能化的部份是基于自主计算技术 (即含两个控制循环的自主元素模型)来实现的，本发明的含两个控制循环的自主元 素模型尤其适用于主从(server-client)结构软件系统中主从双方需要同时管理的场合。

附图说明

图1a是本发明的自主元素模型的控制系统的实施例的结构图。

图1b是本发明的自主元素模型的控制方法的实施例的流程图。

图2示出了本发明的服务器受侵检测保护系统的实施例的结构图。

图3示出了本发明的服务器受侵检测保护系统处理正常http请求和正常http响应 (web应用程序正常使用情况)，以及再次受到某种恶意http请求和正常http响应(web 应用程序已有防止该种恶意请求的能力)的执行流程图。

图4示出了本发明的服务器受侵检测保护系统处理正常http请求和异常http响应 (web应用程序可能出错)的执行流程图。

图5示出了本发明的服务器受侵检测保护系统第一次处理某种异常http请求和正 常http响应(web应用程序已有防止该种的恶意请求的能力)，以及第一次处理某种异 常http请求和异常http响应(web应用程序没有防止该种的恶意请求的能力)的执行 流程图。

图6示出了本发明的服务器受侵检测保护系统再次受到某种恶意http请求而立即 拒绝(web应用程序没有防止该种恶意请求的能力)的执行流程图。

图7示出了通用的Java Web应用程序的http请求和响应的处理流程图。

图8示出了本发明的服务器受侵检测保护系统中环绕通知的处理流程图。

图9示出了本发明的服务器受侵检测保护系统中第一个控制循环(Request  Handler)的处理流程图。

图10示出了本发明的服务器受侵检测保护系统中第二个控制循环(Request  Handler)的处理流程图。

具体实施方式

下面结合附图和实施例对本发明作进一步的描述。

自主元素模型的控制系统的实施例

图1a示出了本发明的自主元素模型的控制系统的实施例。请参见图1a，本实施 例的自主元素模型的控制系统包括：自主管理装置80、第一被管装置81、第二被管装 置82、知识库装置83、第一传感器接口84、第一效应器85、第二传感器接口86、第 二效应器87。自主管理装置80包括第一循环控制装置800和第二循环控制装置802。 第一循环控制装置800和第二循环控制装置802共享知识库装置83。

第一循环控制装置800包括第一监视模块8000、第一分析模块8001、第一规划模 块8002、第一执行模块8003，这四个模块依序连接。

第一监视模块8000通过第一传感器接口84收集、聚合、关联和过滤由第一被管 装置81发来的事件，找出需要进一步分析的症状。第一分析模块8001对症状进行进 一步观察和分析，以做出是否需要进行调整的决定。第一规划模块8002产生相应的调 整计划，以便对第一被管装置81或第二被管装置82进行调整。第一执行模块8003 执行第一规划模块8002产生的调整计划。

第二循环控制装置802包括第二监视模块8020、第二分析模块8021、第二规划模 块8022以及第二执行模块8023，这四个模块之间是依序连接的。

当第一监视模块8000不能从第一被管装置81中收集到所有需要的症状或信息以 明确病因时，第二监视模块8020收集、聚合、关联和过滤由第二被管装置82发来的 事件，找出进一步分析所需要的症状或信息。第二分析模块8021根据知识库装置83 中存储的信息对从第二被管装置82中收集到的症状或信息进行进一步的分析，以做出 是否需要进行调整的决定，其中知识库装置83中存储的信息包括第一监视模块8000 收集到的症状或信息。第二规划模块8022产生相应的调整计划，以便对第二被管装置 82进行调整。第二执行模块8023执行第二分析模块8021产生的调整计划。

从结构上来说，一个经典的自主元素只包含一个控制循环，一个知识库以及一到 多个被管元素。自主管理者根据知识库提供的信息，通过一个“监视(monitor)-分析 (analyze)-规划(plan)-执行(execute)”控制循环(control loop)来实现对被管元素的管理任 务。但对于通过两个不同的控制循环对两个被管元素依此进行操作(在操作时享用一个 知识库)，来完成一个管理任务的情况，则经典的自主元素模型通常不能清晰地表达。 而上述需要实现对两个被管元素依此进行操作管理的情况，在主从(server-client)结构 软件系统中尤为普遍。为了解决现有存在的问题，本实施例提供了上述一种含两个控 制循环的自主元素模型。

本实施例的创新点在于，可以更加清晰地表达两个控制循环(两种控制循环的内容 有所不同但它们仍共享同一个知识库knowledge base)的设计理念。而模型本身也与 IBM的经典自主元素模型有很大的区别。它既不是同一种经典自主元素的简单重复(简 单重复即单个自主管理者被重复应用多次来管理不同的被管元素)，也不是两种经典 自主元素的简单相加(简单相加即两个自主元素分别拥有各自的控制循环及知识库而 都管理同一个被管元素)。

自主元素模型的控制方法的实施例

图1b示出了本发明的自主元素模型的控制方法的实施例的流程。本实施例的自主 元素模型的控制方法是建立在上述自主元素模型的控制系统的基础之上实施的。以下 是控制系统上运行的控制方法的各步骤的详细描述。

步骤S100：第一监视模块收集、聚合、关联和过滤由第一被管装置发来的事件， 找出需要进一步分析的症状。

步骤S101：第一分析模块对症状进行进一步观察和分析，以做出是否需要进行调 整的决定。

步骤S102：第一规划模块产生相应的调整计划，以便对第一被管装置或第二被管 装置进行调整。

步骤S103：第一执行模块执行第一规划模块产生的调整计划。

步骤S104：当第一监视模块从第一被管装置收集到所有需要的症状或信息时，一 个控制循环就能完成一个管理任务而不必进入第二个控制循环。

步骤S105：当第一监视模块不能从第一被管装置收集到所有需要的症状或信息 时，第一执行模块发出信息或请求，以便进一步从第一被管装置收集所有需要的信息， 开始第二个控制循环。

步骤S106：第二监视模块收集、聚合、关联和过滤由第二被管装置发来的事件， 找出进一步分析所需要的症状或信息。

步骤S107：第二分析模块根据知识库模块中已有的信息对从第二监视模块收集到 的症状或信息进行进一步的分析，以做出是否需要进行调整的决定。

步骤S108：第二规划模块产生相应的调整计划，以便对第二被管装置进行调整。

步骤S109：第二执行模块执行第二规划模块产生的调整计划。

服务器受侵检测保护系统的实施例

图2示出了本发明的服务器受侵检测保护系统的实施例的结构。请参见图2，本 实施例的服务器受侵检测保护系统是上述的自主元素模型的实用性的体现，其中智能 化的部分是基于自主计算技术即含两个控制循环的自主元素模型来实现的，这种含有 两个控制循环的自主元素模型尤其适用于主从(server-client)结构软件系统中主从双 方需要同时管理的场合。

普遍的入侵检测和防御系统是通过与已知的入侵方式进行比较，确定入侵是否发 生以及发生入侵的类型，在攻击刚刚开始的时候进行确认并进行防御。一个典型的入 侵检测和防御系统通常有四部分组成：传感器(sensor)、管理服务器(management  server)、数据库服务器(database server)和控制台(console)。

本实施例的服务器受侵检测保护系统是基于上述的自主元素模型的控制系统来实 现的，包括http请求数据收集装置210、http响应数据收集装置211、自主管理装置 200(autonomic manager)、知识库服务器209(knowledge base)和用户接口装置222。

http请求数据收集装置210和http响应数据收集装置211实质上是http servlets的 aspect程序，从模型角度看相当于两个传感器。其中http请求数据收集装置210是外 部http请求传到后首先遇到的模块，用来收集http的请求数据。而http响应数据收集 装置211用来收集http的响应数据。http请求数据收集装置210和http响应数据收集 装置211在http层过滤请求或响应中不需要的内容，然后将需要的数据传给自主管理 装置200。

由传感器来监视http请求是Web服务器入侵检测的通常采用的手段。例如埃莫西 约等人(Hermosillo et al.)设计的AproSec就是采用这种手段。而本实施例的服务器入侵 检测保护系统不仅监视http请求，而且还监视服务器的http响应。Http响应包含了从 Web应用程序发送回Web客户端的响应数据。通过分析http响应，服务器入侵检测保 护系统可以判断出服务器上的Web应用程序是否已有防止某些类型恶意攻击的能力。 因此，服务器入侵检测保护系统中的自主管理者(autonomic manager)200含有两个控 制循环，一个用于http请求，另一个用于http响应。

知识库服务器209存储了用于判断请求或响应是否正常的定义规则、关于请求和 响应的统计数据和动态分析信息。自主管理装置200中包含两个控制循环的装置：请 求控制循环装置和响应控制循环装置。根据知识库服务器209定义的规则，请求控制 循环装置用于http请求的控制循环能够检测拒绝和防止所有已知类型的恶意请求，而 响应控制循环装置用于http响应的控制循环回路可以修改响应中包含的非法内容。

请求控制循环装置包括了请求监视模块201(request monitor)、请求分析模块 202(request analyzer)、请求规划模块203(request planner)和请求执行模块204(request  executor)。请求监视模块201、请求分析模块202、请求规划模块203和请求执行模块 204之间是依序相连的关系。响应控制循环装置包括了响应监视模块205(response  monitor)、响应分析模块206(response analyzer)、响应规划模块207(response planner)和 响应执行模块208(response executor)。响应监视模块205、响应分析模块206、响应规 划模块207和响应执行模块208之间是依序相连的关系。

请求监视模块201用于监视用户通过互联网220发送过来的http请求。http请求 有两类：正常的请求和异常的请求。它们各自的定义均存放在知识库服务器209中。 基于知识库服务器209提供的定义规则，请求监视模块201对于上述两类请求分别采 取不同的行动。异常的请求将被传递给请求分析模块202作进一步分析；正常的请求 将不作任何修改而直接被送到服务器上的应用程序221(web application)去。

请求分析模块202根据知识库服务器209提供的信息，对从请求监视模块201传 来的http异常请求进行深入分析。分析的结果，将被存储到知识库服务器209中。

请求规划模块203根据知识库服务器209提供的信息，决定自主管理装置200下 一步应采取的行动并将行动步骤通知请求执行模块204。

请求执行模块204根据请求规划模块203的决定而实施具体行动。例如，在应用 程序221不能防护某种类型的恶意请求的情况下，请求执行模块204将直接向用户发 送一个http拒绝响应信号。

响应监视模块205用于监视从应用程序发送回用户的http响应。Http响应也可以 分为两类：正常的响应和异常的响应。它们的定义也均存放在知识库服务器209中。 基于知识库服务器209提供的定义，响应监视模块206对于上述两类响应分别采取不 同的行动。异常的响应将被传递给响应分析模块206作进一步分析；正常的响应将不 作任何过滤而通过互联网220被送给用户。

响应分析模块206根据知识库服务器209提供的信息，对从响应监视模块205传 来的http异常响应进行深入分析。例如检查http响应中是否包含有敏感信息(如管理员 账号信息)。响应分析模块206分析的结果，将被存储到知识库服务器209中。

响应规划模块207根据知识库服务器209提供的信息，决定自主管理装置200下 一步应采取的行动并将行动步骤通知响应执行模块208。

响应执行模块208根据响应规划模块207的决定而实施具体行动。例如，在明确 http响应中包含有非法的敏感信息情况下，响应执行模块204会先过滤掉http响应中 敏感信息，然后向用户发送一个干净的http响应信号。

图2中，知识库服务器209存储有用于判断请求或响应是否正常的定义规则；各种 关于请求和响应的统计数据和动态分析信息。例如，请求监视模块201基于知识库服 务器209提供的定义规则来判断的http请求否是正常；请求监视模块201还可以收集 某时间窗口内的所有事件数据，并将它们存储在知识库服务器209中。这些存储在知 识库中的事件数据，为请求分析模块202对http请求作进一步分析提供了丰富的参考 资料。

知识库服务器209经过较长时间的学习和积累Web应用程序和客户端之间的活动 数据，能够规定哪些是常见的请求和响应数据，哪些是异常的请求和响应数据。在此基 础上，判别出未知类型的网络攻击发生的潜在可能性，从而提醒用户加以关注。因此， 知识库是智能化的Web服务器入侵检测保护系统的重要组成部分。

图2中，基于Web的用户接口装置222是服务器入侵检测保护系统的控制台。它 本身利用了Web服务器上的Web应用程序，对自主管理装置200提供人工管理或干预。 例如：增加或更新知识库服务器209中关于恶意请求的类型或定义规则。

请参照图3，为本实施例的服务器入侵检测保护系统处理正常http请求和正常http 响应的执行流程图。图3中，请求监视模块301接收到正常的http请求，而服务器上的 Web应用程序321发送的正常http响应。其执行流程如下：

步骤331，请求监视模块301接收到http请求。

步骤332，请求监视模块301根据知识库服务器309存储的规则，判定该http请 求是正常的。

步骤333，请求监视模块301将正常的http请求传递给服务器。

步骤334，服务器发送http响应。

步骤335，响应监视模块305根据知识库服务器309存储的规则，判定该http响 应是正常的。

步骤336，响应监视模块305将正常的http响应发送给用户。

请参照图4，为本实施例的服务器入侵检测保护系统的处理正常http请求和异常 http响应的执行流程图。在图4中，请求监视模块401接收到正常的http请求，而服务 器上的Web应用程序421发送了的不正常http响应。其执行流程如下：

步骤431，请求监视模块401接收到http请求。

步骤432，请求监视模块401根据知识库服务器409存储的规则，判定该http请 求是正常的。

步骤433，请求监视模块401将正常的http请求传递给服务器。

步骤434，服务器发送http响应。

步骤435，响应监视模块405根据知识库服务器409存储的规则，判定该http响 应是异常的。

步骤436，响应监视模块405将http响应传递给响应分析模块406做进一步分析。

步骤437，响应分析模块406将分析结果存储入知识库服务器409。

步骤438，响应规划模块407通知响应执行模块408发出警告。

步骤439，响应执行模块408将过滤后的http响应及警告发送给用户。以通知用 户Web应用程序421可能出错了(malfunction)。

请参照图5，为本实施例的服务器入侵检测和保护系统在第一次受到某种已知类 型的恶意http请求，而发现被保护Web应用程序已有防止该种的恶意请求的能力的执 行流程图。在图5中，请求监视模块501接收到不正常的http请求，而服务器上的Web 应用程序521发送了的正常http响应。其执行流程如下：

步骤531，请求监视模块501接收到http请求。

步骤532，请求监视模块501根据知识库服务器509存储的规则，判定该http请 求是异常的。

步骤533，请求监视模块501将异常的http请求传递到请求分析模块502。请求 分析模块502检查是否第一次收到该种异常请求。如果是的话，则做深入分析，并将 结果记录在知识库服务器509中。然后，请求分析模块502将请求进一步传递到请求 规划模块503和请求执行模块504。

步骤534，如果该种异常http请求对Web应用程序521具有破坏性，例如，删除 一个表，该请求将被立即拒绝。

步骤535，如果该种异常http请求对Web应用程序521没有破坏性，则请求将被 传递给服务器。

步骤536，服务器发送http响应。

步骤537，响应监视模块505根据知识库服务器509存储的规则，判定该http响应 是正常的。

步骤538，响应分析模块506将分析结果存储入知识库服务器509。

步骤539，响应执行模块508将正常的http响应发送给用户。

值得注意的是，本实施例的服务器入侵检测和保护系统再次受到某种已知类型的 恶意http请求而发现被保护Web应用程序已有防止该种的恶意请求的能力的执行流程 图与图3同，故不赘画，请依旧参照图3。其执行流程如下：

步骤331，请求监视模块301接收到http请求。

步骤332，请求监视模块301根据知识库服务器309存储的信息，知道该种http 请求是恶意的，并且知道被保护Web应用程序321已有防止该种的恶意请求的能力。

步骤333，请求监视模块301将该种异常的http请求传递给服务器。

步骤334，服务器发送http响应。

步骤335，请求监视模块305根据知识库服务器309存储的规则，判定该http响应 是正常的。

步骤336，请求监视模块305将正常的http响应发送给用户。

值得注意的是，本实施例的服务器入侵检测保护系统在第一次受到某种已知类型 的恶意http请求而发现被保护Web应用程序没有防止该种的恶意请求的能力的执行流 程图与图5同，故不赘画，请依旧参照图5。

步骤531，响应监视模块501接收到http请求。

步骤532，响应监视模块501根据知识库服务器509存储的规则，判定该http请 求是异常的。

步骤533，响应监视模块501将异常的http请求传递到响应分析模块502。响应 分析模块502检查是否第一次收到该种异常请求。如果是的话，则做深入分析，并将 结果记录在知识库服务器509中。然后，响应分析模块502将请求进一步传递到响应 规划模块503和响应执行模块504。

步骤534，如果该种异常http请求对Web应用程序521具有破坏性，例如，删除 一个表，该请求将被立即拒绝。

步骤535，如果该种异常http请求对Web应用程序521没有破坏性，则请求将被 传递给服务器。

步骤536，服务器发送http响应。

步骤537，响应监视模块505根据知识库服务器509存储的规则，判定该http响应 是非法的。

步骤538，响应分析模块506将分析结果存储入知识库服务器509，并告知Web 应用程序521对该类异常http请求没有识别及防护能力。

步骤539，响应执行模块508将警告发送给用户。

请参照图6，为本实施例的服务器入侵检测保护系统在再次受到某种已知类型的 恶意http请求，而被保护Web应用程序没有防止该种的恶意请求的能力的执行流程图。 其执行流程如下：

步骤631，请求监视模块601接收到http请求。

步骤632，请求监视模块601根据知识库服务器609存储的规则，判定该http请 求是是异常的。请求监视模块601将异常的http请求传递到请求执行模块602。

步骤633，请求执行模块602进一步判定该http请求是否是恶意的，并且知道被 保护Web应用程序621没有防止该种的恶意请求的能力。

步骤634，请求执行模块604拒绝该http请求。

为了进一步说明图2中有关http请求数据收集装置和http响应数据收集装置的(其 实质是http servlets的aspect程序)210和211的工作原理，这里先介绍“通用的”Java  Web应用程序的http请求和响应的处理流程，请参照图7。图7中，一个典型的客户 和Web应用程序的交互过程如下：

步骤731，客户(Web client)710发送http请求给Web服务器。

步骤732，Web服务器将请求转换成一个HttpServletRequest类的对象。这个对象 被传给一个Web组件(component)。

步骤733734，该Web组件能与JavaBeans组件或数据库进行交互并产生动态内 容。

步骤735，该Web组件能产生一个HttpServletResponse类的对象。或者将请求传 给另一个Web组件。

步骤736，Web服务器将该对象转换成一个http响应并发送给用户。

众所周知，Java源程序的扩展名为java而AspectJ源程序的扩展名为.aj。图2中 http servlets的aspect程序210和211在具体实现中的文件名为：HttpServletAspect.aj。 它是传感器的核心。

在AOP(Aspect-Oriented Programming)中，连接点(jointpoint)是切面插入应用程序 的地方，该点能被方法(method)调用，而且也会被抛出意外。连接点是应用程序提供 给切面插入的地方，可以添加新的方法。

通知，又称处理逻辑(advice)是切面功能的实现，它通知程序新的行为。如在 logging里，logging advice包括logging的实现代码。通知(advice)在连接点(jointpoint) 处插入到应用程序中。

切点(pointcut)可以控制把哪些advice应用于连接点(jointpoint)上去，通常使用切 点通过正则表达式来把明显的名字和模式进行匹配应用。决定了那个连接点会获得通 知。

在HttpServletAspect中，定义了一个混合的切点(pointcut)名为： servletRequestExec。

public pointcut servletRequestExec()

within(HttpServlet+)&&call(*HttpServlet.do*(..))；

在上述混合切点servletRequestExec中，使用布尔操作符&&混合了两个切点 within()和call()。首先，它会识别执行代码中匹配HttpServlet+类型的每个连接 点(joint point)。换句话说，任何HttpServlet类及其子类中(即HttpServletRequest和 HttpServletRequest)的连接点都会被挑选出来。其次，它将识别每一个匹配 HttpServlet.do*方法调用(method call)的连接点，而不管其返回类型和参数是什么。 我们的目标是要找出每一在HttpServlet以及它的子类(即HttpServletRequest和 HttpServletRequest)中的执行doGet()和doPost()方法的连接点。

编写了与切点servletRequestExec匹配的环绕通知(around advice)，以及从连接 点传入该通知的上下文(context)：

void around(Object servlet，Object request，Object reponse)

：servletRequestExec()&&this(servlet)&&args(request，response)()

如上述源代码所示，切点除了servletRequestExec外，还有this()和args()。 切点this()和args()是AspectJ用来收集连接点的上下文(context)的。这样，当 切点servletRequestExec被切到时，当前的执行对象“servlet”和它的参数“request” 和“response”(即HttpServletRequest对象和HttpServletResponse对象)将被传递给环绕 通知。

请参照图8，为本实施例的Web服务器入侵检测保护系统中环绕通知(around  advice)的处理流程。它是AspectJ程序的核心。也是信息出入自主管理者的必经通道。 它包含了两个独立步骤：第一个步骤是验证的http请求。在这个过程中，一个包含原始 http请求的新的包裹响应(即wrapped response)对象被创建起来。环绕通知将原始的http 请求以及新的包裹响应对象传给自主管理者(autonomic manager)200(具体地说，就是 请求处理RequestHandler，请参见下文)做入侵检测，请参照图2。请求处理 RequestHandler的对象将保存有自主管理装置的分析结果。如果分析结果表明，原始 的http请求不应该传递给Web应用程序或者用户，则环绕通知就会将拒绝信息传达给 用户。否则，原始的请求将被传递给Web应用程序221，请参照图2。

第二个步骤是分析的http响应。请求处理RequestHandler的对象保存有自主管理 者的分析结果，如果结果表明需要检查http响应，则环绕通知将会把http响应(包含有 原http请求信息)传给自主管理装置200(具体地说，就是响应处理ResponseHandler，请 参见下文)做进一步检测。否则，http响应将不作任何修改经Internet/Intranet 220传递 给用户，请参照图2。如上所述，http响应有时需要做进一步检测，以确定Web应用 程序是否已有防止某种的恶意请求的能力。值得注意的是，在Java Servlet API中原有 的包裹响应HttpServletResponseWrapper并不提供getContent()方法以方便开发人员 提取http响应的内容。因此我们只好创建我们自己的名为WrapperResponse的包裹响 应。它是有的包裹响应HttpServletResponseWrapper的扩展，并且覆盖了原有的 getOutputStream()和getWriter()方法。由此，响应内容将会写入到WrapperResponse 的输出流中，而不是原有的HttpServletResponseWrapper中。在WrapperResponse中新 建的getContent()方法则是用来返回响应内容的。

请参照图2，服务器入侵检测保护系统中的自主管理装置200不仅检查http请求， 有时还检查Web应用程序的http响应。在具体实施中，一个处理程序(Handler)是一个 对象，是系统用于连接的monitor，analyzer，planner和executor四个模块的程序。处理 程序Handler有两种类型：RequestHandler和ResponseHandler。他们在自主管理者 (autonomic manager)200中分别处理http请求和http响应。

请参照图9，服务器入侵检测保护系统中RequestHandler(第一个控制循环)的处理 流程。自主管理者将http请求传给RequestHandler，以检查请求的数据，然后决定下 一步的行动。RequestHandler的首先为每个http请求创建一个请求监视模块的对象。 请求监视模块决定是否将原始请求传递到Web应用程序。如果是，请求监视模块对象 将返回一个true值给自主管理者。否则，该请求将被传递到请求分析模块的对象作进 一步调查。请求分析模块决定是否将请求传递到Web应用程序。如果请求被拒绝，请 求执行模块对象将产生拒绝响应。如果请求被接受，则该请求将被传递到Web应用程 序。

请参照图10，服务器入侵检测保护系统中ResponseHandler(第二个控制循环)的处 理流程。首先ResponseHandler的将为http响应创建一个响应监视模块对象。响应监 视模块则通过handlehttpContent()方法检查响应是否正常。如果是，响应监视模块对 象将返回一个true值给自主管理者，而正常http响应将被传给用户。否则，该响应将 被传递到响应分析模块对象作进一步验证。响应分析模块将把验证结果记录到的知识 库中。这一验证结果会表明Web应用程序是否对某种恶意请求已具有入侵检测和保护 的能力。另一方面，知识库也获得了更多关于被保护的Web应用程序自有防护能力的 知识。

请参照图10，响应分析模块负责对Web应用程序的http响应做深入分析。例如， 响应分析模块能够分析某个http响应中的脚本(Script)是正常的脚本还是恶意的 cross-site scripting(即XSS)。通常，一个XSS嵌入在http请求中的脚本和http响应中的 脚本没有任何不同。因此，响应分析模块可以在比较http请求和http响应脚本的基础 上来判断是否受到了XSS类的网络攻击。

请参照图10，响应执行模块是用来产生拒绝响应的。当系统再次受到某种恶意http 请求而Web应用程序已有防止该种的恶意请求的能力时，则响应执行模块不会被调用。

请参照图2，服务器入侵检测保护系统中的知识库服务器209是其重要组成部分。 知识库服务器209包括两个子模块：动态子模块和静态子模块。动态子模块主要由监 视模块201、205调用，而静态动态子模块大多数情况下供分析模块202、206使用。

动态子模块主要用以检测http请求是否异常。它由一组存储在数据库或文件中的 规则组成。这些规则定义了(根据人工输入的)已知类型的恶意http请求或(根据系统检 测的)已经经受过的网络攻击。例如，某个规则用来检测SQL注入攻击经常包含字符 串“--”和单引号。

另一方面，静态子模块由存储在数据库中的数据组成。这些数据记录了网页的 URL，入侵的类型及其它们两者间的相互关系。在运行时，请求分析模块202可以通 过向数据库执行一个查询来检查被保护Web应用程序是否有防止某种的恶意请求的 能力。而响应分析模块206则负责创建和更新这些记录。这些记录存储了响应监视模 块205和响应分析模块206验证各类Web应用程序响应的结论数据。

在具体实现中，监视模块201、205和分析模块202、206是通过DatabaseManager 类和其子类与数据库进行通信的。静态子模块通过一个DatabaseManager的对象将所 有数据存储入数据库中，并通过一个Java缓存来提高从数据库中读取数据的效率。

动态子模块的实现则是应用了复杂事件处理器(complex event processing)。更具 体地说，是Esper引擎。开发了一个名为EsperAdaptor的适配器将Esper引擎引入知 识库。Esper引擎在系统启动时被初始化。而用事件处理语言(event processing language) 写成的查询语句(可理解为复杂事件处理器中的规则)被添加到引擎的实例(instance) 中。然后两个侦听器listener()被初始化化，并插入到引擎中以接收由监视模块201、 205和分析模块202、206产生的事件。当接收到的事件满足查询语句的条件时，listener() 中的更新update()方法将被执行。而update()将根据查询语句的条件来判定它遇到了哪 一中异常以便进一步采取措施。这些进一步措施的具体步骤请参见图3到图6中的判 断框(菱形)。

以上结合附图实施例对本发明进行了详细说明。本发明的服务器受侵检测保护系 统是本发明的自主元素模型的控制系统在特定场合的一个实施。而本发明服务器受侵 检测保护系统的具体实现可以采用多种不同的方法。上述说明的实施例细节仅是基于 Aspect程序和Esper引擎开发技术来实现的。本领域中的研究技术人员可根据上述说 明对本发明做出种种变化例，例如用Drools Expert引擎来代替Esper引擎。因而，实施 例中的某些细节不应构成对本发明的限定，本发明将以所附权利要求书界定的范围作 为本发明的保护范围。