基于数据挖掘的入侵检测系统毕业设计

生产实习设计（论文）

基于数据挖掘的入侵检测系统

院系：计算机科学系

专业：计算机科学与技术学号：2007210487

姓名：刘兵

指导老师：李源

(1):目录

摘要………………

前言………………

1. 选题背景及研究现状

2. 本文研究内容

3. 全文组织结构

第一章入侵检测系统概述………………

1.1 入侵检测的概念

1.2 入侵检测的模型建立方法

1.3 入侵检测的技术分类

1.3.1 基于统计方法的入侵检测技术

1.3.2 基于神经网络的入侵检测技术

1.3.3 基于专家系统的入侵检测技术

1.3.4 基于模型推理的入侵检测技术

1.4 入侵检测系统分类

1.4.1 基于主机的入侵检测系统

1.4.2 基于网络的入侵检测系统

第二章Win32 API编程技术………………

2.1 Win32 API概论

2.2 跨进程API Hook

2.2.1 API Hook理论

2.2.2 API Hook的实现

2.2.3 跨进程理论

2.2.4 跨进程的实现和几点注意

2.2.5 在跨进程API Hook时可能用到的其他技术

第三章利用数据挖掘技术的入侵检测系统模型………………

3.1 传感器

3.2 通信器

3.3 检测器

3.4 数据仓库

3.5 报警器

第四章系统主要模块研究………………

4.1 传感器部分

4.2 基于数据挖掘的模型生成器部分算法研究

4.2.1 问题描述

4.2.2 归一化处理

4.2.3 聚类算法

4.2.4 实时检测入侵

第五章系统性能分析………………

第六章全文总结及展望………………

致谢

参考文献

(2):摘要

在允许各种网络资源以开放方式运作的前提下，入侵检测系统成了确保网络安全的一种必要手段。入侵检测就是发现或确定入侵行为存在或出现的动作，它实际上是一种信息识别与检测技术，而从以数据为中心的观点看，入侵检测本身就是一个数据分析过程。在许多相关的领域，如欺诈检测和故障管理中，数据挖掘已经取得了成功的应用。于是，研究数据挖掘方法在入侵检测领域中的应用，自然就成为一个热门话题。

本文研究和设计了一种基于数据挖掘的主机入侵检测系统，介绍了它的体系结构，并说明了其传感器、通信器、检测器和数据仓库等基本组件的构成。另外介绍了Windows下部分传感器实例以及监测器中模型生成器使用的数据挖掘的聚类算法。最后讨论了当前存在的几个问题和今后的研究方向。

关键词入侵检测数据挖掘基于主机异常检测体系结构

(3):前言

1. 选题背景及研究现状

随着网络技术和网络规模的不断发展,网络入侵的风险性和机会也越来越多，这些入侵有的是针对计算机系统和软件的漏洞，有的是针对网络系统本身的安全缺陷，但是它们都对主机和网络造成了破坏，网络安全已经成为人们无法回避的问题，因此为了保护现在越来越多的敏感信息，入侵检测技术得到了越来越多的重视。

入侵检测按照监测对象的不同一般可分为两类：基于主机的和基于网络的。但是当将基于网络的入侵检测系统整合到一个保护系统中时，一般都需要使用基于主机的入侵检测系统。尽管目前大部分的攻击都是通过网络来实现的，但是所有这些攻击都来自于主机(攻击者自己的或者是被其破坏控制的主机)，而且有些攻击是产生并保持在主机系统中的。

基于网络的入侵检测有以下几点缺陷：第一，因为它是监测网络数据的，而网络数据可以看成是代表用户行为的，但是不一定能代表用户行为所造成的后果；第二，几乎不可能将所有的网络数据全部接收到；第三，即使将所有的网络数据全部接收到也不能检测到所有的入侵；第四，数据加密会使网络入侵检测失效；另外基于网络的入侵检测可能会遗漏一些系统级的攻击。而基于主机的入侵检测可以很方便地收集在该主机上所有用户的行为及这些行为造成的后果，并且在做基于主机的数据收集和分析时可以不用担心网络上的海量数据，因此研究基于主机的入侵检测系统仍然是非常必要的。

基于主机的入侵检测系统，不管是对于单用户或多用户的操作系统来说，要想找到一个满足所有要求的解决方案是不可能的。因此在这里研究一种基于数据挖掘的主机入侵检测系统，这种技术利用了现有的比较成熟的数据挖掘技术和一种比较健壮以及轻量的数据收集系统来构造一个强有力的基于主机的入侵检测系统。

当今数据库的容量已经达到上万亿的水平(T)--- 1,000,000,000,000 个字节。从而形成一个新的挑战：在这被称之为信息爆炸的时代，信息过量几乎成为人人需要面对的问题。随着数据的急剧膨胀，数据的时效性和复杂性远远超过了当前信息处理的能力，人们不可回避地遇到了信息灾难问题：一是信息过量，难以消化；二是信息真假，难以辨识；三是信息安全，难以保证；四是信息形式不一致，难以统一处理。在数据生产、传输能力远远大于数据分析能力的今天，人们被数据淹没，人们却饥饿于知识。面对这一严峻挑战，数据挖掘和知识发现(Data Mining and Knowledge Discovery，简称DMKD)技术应运而生，并得以蓬勃发展，越来越显示出其强大的生命力。

数据挖掘(Data Mining)就是从大量的、不完全的、有噪声的、模糊的、随机的数据中，提取隐含在其中的、人们事先不知道的、但又是潜在有用的信息和知识的过程。还有很多和这一术语相近似的术语，如从数据库中发现知识(KDD)、数据分析、数据融合(Data Fusion)以及决策支持等。人们把原始数据看作是形成知识的源泉，就像从矿石中采矿一样。原始数据可以是结构化的，如关系数据库中的数据，也可以是半结构化的，如文本、图形、图像数据，甚至是分布在网络上的异构型数据。发现知识的方法可以是数学的，也可以是非数学的;可以是演绎的，也可以是归纳的。发现的知识可以被用于信息管理、查询优化、决策支持、过程控制等，还可以用于数据自身的维护。因此，数据挖掘是一门很广义的交叉学科，它汇聚了不同领域的研究者，尤其是数据库、人工智能、数理统计、可视化、并行计算等方面的学者和工程技术人员。

2. 本文研究内容

如前所述，入侵检测作为一门新兴的交叉学科提出了很多具有挑战性的研究课题，其涉及的内容、研究的方向广泛而又丰富。本文的研究工作主要围绕以下入侵检测领域中的数据挖掘方法展开。本文的创新点主要包括以下几个方面：

非监督异常检测方法：基于聚类技术提出了一种能处理不带标识且含异常数据样本的训练集数据的网络入侵检测方法。对网络连接数据作归一化处理后，通过构造该数据集对应的数据场，根据其势场分布的局部最大值找到聚类中心，并以3B邻域为限考虑各数据点的分类情况。完成样本数据的类划分后，根据正常类比例N来确定异常数据类别并用于网络连接数据的实时检测。结果表明，该方法有效地以较低的系统误警率从网络连接数据中检测出新的入侵。λ

跨进程APIλHook：众所周知Windows应用程序的各种系统功能是通过调用API函数来实现。API Hook就是给系统的API附加上一段小程序，它能监视甚至控制应用程序对API 函数的调用。所谓跨进程也就是让自己的程序来控制别人程序的API调用了。

3. 全文组织结构

前言概要地阐述了论文的基本情况和研究背景，介绍了入侵检测的主要研究内容和当前的研究现状，还简要介绍了本文的主要研究内容。

第一章介绍了入侵检测研究的背景和入侵检测的概念，并对入侵检测技术的原理和现有入侵检测系统的系统构成及所采用的技术进行了详细的分析。

第二章介绍了Windows下系统监控所涉及到的技术，包括API编程，DLL注入等。尤其大胆的提出API Hook的应用。

第三章系统的描述了基于数据结构技术的主机入侵检测系统的系统模型设计，有别于常规的主机入侵检测系统，是本文创新的意义与重点。

第四章研究了API Hook以及数据挖掘技术在主要2个模块中的应用，尤其是数据挖掘技术的算法研究，是作者学习、研究的重点。

第五章根据提出的设计方案及体系结构，进行了系统性能的估算与模拟测试。

第六章总结了这一段时间的研究情况，列举了研究中存在的问题，并探讨了进一步研究的方向。

(4):第一章入侵检测系统概述

入侵检测系统(IDS，Intrusion Detection System)用来识别针对计算机系统和网络系统，或者更广泛意义上的信息系统的非法攻击，包括检测外界非法入侵者的恶意攻击或试探，以及内部合法用户的超越使用权限的非法行动。

入侵检测技术是计算机安全技术中的重要部分，它从计算机系统中的若干关键点收集信息，并分析这些信息，检测计算机系统中是否有违反安全策略的行为和遭到袭击的迹象。入侵检测系统在几乎不影响计算机系统性能的情况下能对计算机系统进行实时监测，并对系统提供针对内部攻击、外部攻击和误操作的实时保护。入侵检测技术通过对入侵行为的过程与特征的研究，使安全系统对入侵事件和入侵过程能做出实时响应。入侵检测技术扩展了系统管理远的安全管理能力(包括安全审计、监视、进攻识别和响应)，提高了信息安全基础结构的完整性。

1.1 入侵检测的概念

入侵(Intrusion)的定义：任何试图危害资源的完整性、可信度和可获取性的动作。

入侵检测(Intrusion Detection)：按Webster辞典定义，即发现或确定入侵行为存在或出现的动作。就是检测入侵的方法，如发现闯入系统的入侵者或滥用系统资源的非法用户。也可更具体的定义为发现、跟踪并记录计算机系统或计算机网络中的非授权行为，或发现并调查系统中可能为试图入侵或病毒感染所带来的异常活动。

在允许各种网络资源以开放方式运作的前提下，入侵检测系统(Intrusion Detection Systems)成了确保网络安全的一种新的手段，且这种手段的实现方式也与入侵的出现一样在不断地翻新。IDS一般不是采取预防措施以防止入侵事件的发生，而是通过对包括计算机系统及网络用户行为的监控，实现如下目标：识别入侵者，识别入侵行为，检测和监视已成功的安全突破，为对抗入侵及时提供重要信息，阻止事件的发生和事态的扩大。IDS解决安全问题是基于如下假设的：系统是不安全的，但违反安全策略的行为(即入侵)是能够通过监控和分析系统及用户行为而被检测到的。

1.2 入侵检测的模型建立方法

以建立入侵模型的方法分类，入侵检测可分为异常检测与滥用检测。

异常入侵检测指能根据异常行为和使用计算机资源检测出来的入侵。通过对审计数据的训练学习，从中发现正常使用行为模式，以定量的统计方式描述可接受的行为特征，并由测试数据和正常行为模式的偏差捕获到异常，以区分非正常的、潜在的入侵性行为。存在一个如何识别异常行为的问题。建立的威胁模型包括外部闯入、内部渗透和不当行为。

其主要前提条件是将入侵性活动作为异常活动的子集。理想情况是两集合相同。异常入侵检测要解决的主要问题就是构造异常活动集并从中发现入侵性活动子集，其方法依赖于异常模型的建立。异常检测是通过观测到的一组测量值偏离度来预测用户行为的变化，然后做出决策判断的检测技术。

通过检查与正常行为相违背的行为，异常检测能够发现一些新的未知的入侵行为，但不可避免的将会有更高的误报率。所以在实际系统中异常检测的结果往往都要提交给系统管理员进行继续跟踪与分析。

滥用检测是指根据已知系统和应用软件的弱点及其攻击模式的特征进行编码，并通过与审计数据的匹配来检测入侵。与异常检测不同，滥用检测直接检测不利的或不可接受的行为。其主要假设是具有能够精确地按某种方式编码的攻击，并可以通过捕获攻击及重新整理、确认入侵活动是基于同一安全隐患进行攻击的入侵方法的变种。指通过按预先定义好的入侵模式以及观察到入侵发生的情况进行模式匹配来检测。

滥用检测具有较低的误报率(false positive rate)，但它不能检测出新出现的一些入侵行为，故漏报率(false negative rate)也较高。

1.3 入侵检测技术分类

入侵的检测实际上是一种信息识别与检测技术。因此，传统的信息识别技术也可以用到入侵检测中来。不过，和通常的信息识别和检测相比，入侵检测有其独特之处。在入侵检测中，不但信息的先后次序十分重要，信息产生的时间也要作为一个重要的变量输入到识别系统之中，如DoS攻击，完全是依靠短时间内大量网络活动来耗尽系统资源的。此外，入侵检测比一般的信息识别有更强的上下文和环境相关性，不同环境下，有完全不同的结果。这两点是实现网络入侵检测所必需的。

前面提到过，入侵分析是入侵检测的核心，入侵检测技术主要研究的就是对入侵行为分析和判定，即入侵分析技术。目前主要的入侵检测技术有：

1.3.1 基于统计方法的入侵检测技术

基于统计方法的入侵检测技术，就是入侵分析采用基于统计的检测规则的方法的一种检测技术。它基于对用户历史行为的建模，以及先验的证据或模型的基础，实时地检测用户对系统的使用情况，根据系统内部保存的用户行为的概率统计模型进行检测，实时检测系统是否有异常的用户行为，依此来判断系统是否遭到入侵。也就是说，系统根据用户以前的历史行为记录来决定用户当前的行为是否合法。系统根据用户的历史行为，生成每个用户的统计行为模型(即行为习惯)。当用户改变他的行为习惯时，这种“异常”就会被检测出来。通常记录的行为有：

一般项目：例如登录的时间、地点，CPU资源的申请及占用情况，I/O的使用通道和频率，常用目录的建立和删除，文件的读写等。

特定项目：例如用户习惯用的编辑器和编译器，最常用的系统调用，经常访问的网络站点，用户口令文件的存取。

1.3.2 基于神经网络的入侵检测技术

由于用户行为的复杂性，要想准确地把当前的用户行为和用户行为概率统计模型进行匹配是相当困难的，因而基于统计方法的入侵检测技术存在着一些天生的弱点。错发的警报往往来自于对统计数据的统计算法所基于的不准确的假设。因此人们利用和发展神经网络技术来进行入侵检测。

神经网络较好地解决了传统的基于统计的分析方法所面临的以下几个难题：

难于建立确切的统计分布：统计方法基本上依赖于用户行为的主观假设，错发警报常由这种假设所导致。λ

难于实现方法的普适性：适用于某类用户行为的检测措施一般无法适用于另一类用户。λ算法实现比较昂贵：由于上一条原因，即基于统计的算法对不同类型的用户行为不具有自适应性，因此算法比较复杂而且庞大，导致算法上的昂贵。而神经网络技术不存在这个问题，实现的代价较小。λ

系统臃肿难于剪裁：由于采用统计方法检测具有大量用户的计算机网络系统，将不得不保留大量的用户行为信息，导致系统的臃肿和难于剪裁。而基于神经网络的技术能够回避这一缺点，根据实时检测到的信息有效地加以处理做出入侵可能性的判断。λ

目前，神经网络技术提出了对于基于传统统计的入侵检测技术的改进方向，但尚不十分成熟，所以传统的统计方法仍将继续发挥作用，也仍然能为发现用户的异常行为提供相当有参考价值的信息。

1.3.3 基于专家系统的入侵检测技术

基于专家系统的入侵检测技术，就是根据网络安全专家对可疑行为的分析经验而形成一套推理规则，然后在此基础之上构建入侵检测专家系统，由此专家系统自动进行对所涉及的入侵行为进行分析工作。

所谓专家系统是基于一套有专家经验事先定义的规则的推理系统，例如，在数分钟之内某个用户连续进行登录，失败超过规定次数可以被认为是一次入侵行为。类似的规则在统计系统中也有，同时基于规则的专家系统或推理系统也有其局限性，因为作为这类系统的基础的推理规则一般都是根据已知的入侵手段来进行安排和策划的，而对网络系统的最危险的威胁则主要来自未知的入侵手段。实现一个基于规则的专家系统是一个知识工程问题，而且其功能应当能够随着经验的积累而利用其自学习能力进行规则的扩充与修正。

专家系统对历史数据的依赖性总的来说比基于统计的检测系统较少，因此系统的适应性比较强，可以较灵活地适应不同的安全策略和检测需求。

1.3.4 基于模型推理的入侵检测技术

入侵者在入侵一个系统时往往具用一定的行为程序，如猜测口令的程序，这种行为程序构成了某种具有一定行为特征的入侵行为模型。根据这种模型所代表的入侵意图的行为特征，可以实时地检测出恶意的入侵企图(尽管入侵并不一定都是恶意的)。用基于模型推理的方法人们能够为某些行为建立特定的模型，从而能够检测具有特定行为的某些入侵活动。根据假设的入侵脚本，这种系统就能检测出非法的用户行为。一般为了准确判断，要为不同的入侵者和不同的系统建立特定的入侵脚本。

当然，上述的几种方法都有各自的优缺点，并不能彻底地解决入侵检测问题，所以最好是综合地利用各种方法强化网络系统的安全程度以增加入侵成功的难度，同时根据系统本身特

点辅助以较适合的入侵检测技术。

1.4 入侵检测系统分类

入侵检测系统根据其检测数据来源分为两类：基于主机(Host-based)的入侵检测系统和基于网络(Network-based)的入侵检测系统。基于主机的入侵检测系统从单个主机上提取系统数据(如审计记录等)作为入侵分析的数据源，而基于网络的入侵检测系统从网络上提取数据(如网络链路层的数据帧)作为入侵分析的数据源。通常来说基于主机的入侵检测系统只能检测单个主机系统，而基于网络的入侵检测系统可以对本网段的多个主机系统进行检测，多个分布于不同网段上的基于网络的入侵检测系统可以协同工作以提供更强的入侵检测能力。图1.1给出了一个同时包含基于主机与基于网络的两种机制的入侵检测结构框图。

图1.1 入侵检测系统结构框图

1.4.1 基于主机的入侵检测系统

基于主机的入侵检测系统的检测目标是主机系统和系统本地用户，原理是根据主机的审计数据和系统日志发现可疑事件。该系统通常运行在被监测的主机或服务器上，实时检测主机安全性方面诸如操作系统日志文件、审核日志文件、应用程序日志文件等的情况，其效果依赖于数据的准确性以及安全事件的定义。可见这种类型的IDS是利用主机操作系统及应用程序的审核踪迹作为输入的主要数据源来检测入侵。基于主机的入侵检测系统被设计成检测IDS代理所驻留的宿主机，如图1.2所示，这种IDS可以检测到网络协议栈的高层数据，也可检测到被监视主机上的本地活动，诸如：文件修改和用户帐户的建立。

图1.2 基于主机的入侵检测系统

在图1.2的客户－服务器通信模式下，客户机对服务器上的访问活动将被服务器日志所记载。IDS代理检测这些记录用户活动信息的日志文件，将它们与事先知道的用户正常行为模式进行匹配。基于主机的IDS有两种主要类型：基于应用和基于操作系统。

基于应用的IDS在应用层搜集信息。应用层的例子有：数据库管理软件、Web服务器或防火墙等产生的日志文件。这种方式可以更好地获取在系统上用户活动(如可以利用特定应用的特点来监视用户活动)，但也存在应用层的脆弱性会破坏监视和检测的弱点。

基于操作系统的IDS搜集在特定系统上的活动信息，这些信息可以是操作系统产生的审计踪迹，它也包括系统日志、其它操作系统进程产生的日志以及那些在标准操作系统的审计和日志中没有反映的系统对象的有关内容。这种方式可以监控对系统访问的主体和对象，并且可以将可疑的活动映射到特定的用户ID上。同样，操作系统的脆弱性也会破坏IDS监视与入侵分析的完整性，同时基于操作系统的IDS必须建立在特定的操作系统平台上，这就增加了开销。

基于主机的入侵检测系统具有检测效率高，分析代价小，分析速度快的特点，能够迅速并准确地定位入侵者，并可以结合操作系统和应用程序的行为特征对入侵进行进一步分析、响应。比如，一旦检测到有入侵活动，我们可以立即使该用户的帐号失效，用户的进程中断。基于主机的入侵检测系统尤其对于独立的服务器及应用构造简单，易于理解。也只有这种检测方式能检测出通过控制台的入侵活动。目前很多是基于主机日志分析的入侵检测系统。但基于主机的IDS也有其不足之处：首先它在一定程度上依赖于系统的可靠性，它要求系统本身应该具备基本的安全功能并具有合理的设置，然后才能提取入侵信息；即使进行了正确的设置，对操作系统熟悉的攻击者仍然有可能在入侵行为完成后及时地将系统日志抹去，从而不被发觉；并且主机的日志能够提供的信息有限，有的入侵手段和途径不会在日志中有所反映，日志系统对网络层的入侵行为无能为力，例如利用网络协议栈的漏洞进行的攻击，通过ping命令发送大数据包，造成系统协议栈溢出而死机，或是利用ARP欺骗来伪装成其他主机进行通信等等，这些手段都不会被高层的日志记录下来。在数据提取的实时性、充分性、可靠性方面基于主机日志的入侵检测系统不如基于网络的入侵检测系统。

1.4.2 基于网络的入侵检测系统

基于网络的入侵检测系统搜集来自网络层的信息。这些信息通常通过嗅包技术，使用在混杂模式的网络接口来获得。

图1.3 基于网络的入侵检测系统

从图1.3可以看出，基于网络IDS位于客户端与服务端的通信链路中央，它可以访问到通信链路的所有层次。因此，这种IDS可以监视和检测网络层的攻击(如SYN洪流)。

理论上，网络监视可以获得所有的网络信息数据，它在没有特定的审计或日志机制的情况下，也可以获得数据；只要时间允许，可以在庞大的数据堆中提取和分析需要的数据；可以对一个子网进行检测，一个监视模块可以监视同一网段的多台主机的网络行为；可以通过增加代理来监视网络，不会影响现存的数据源，不改变系统和网络的工作模式，也不影响主机性能和网络性能；处于被动接收方式，很难被入侵者发现，隐蔽性好；可以从底层开始分析，对基于协议攻击的入侵手段有较强的分析能力。

基于网络的入侵检测系统的主要问题是监视数据量过于庞大并且它不能结合操作系统特征来对网络行为进行准确的判断；如果网络数据被加密，IDS就不能扫描协议或内容。

就如防盗系统一样，基于网络的IDS系统通常放置于企业内部网与外部网的访问出口上(如路由器、MODEM池)，能够监控从协议攻击到特定环境攻击的范围很广的网络攻击行为，对于监控网络外部用户的入侵和侦察行为非常理想。基于主机的IDS 适合于那些以数据或应用服务器为中心的网络系统，并对那些已取得系统访问权限的用户对系统的操作进行监控。究竟是在哪个层次上部署IDS 需要根据使用者自身的安全策略来决定。

由于基于网络的入侵检测方式具有较强的数据提取能力，因此目前很多入侵检测系统倾向于采用基于网络的检测手段来实现。

(5):第二章 Win32 API编程技术

Win32 API作为Microsoft 32位平台(包括：Windows 9x，Windows NT3.1/4.0/5.0，WindowsCE)的应用程序编程接口，它是构筑所有32位Windows平台的基石，所有在Windows平台上运行的应用程序都可以调用这些函数。

从事Windows应用程序开发，离不开对Win32 API函数的调用。只有充分理解和利用API 函数，才能深入到Windows的内部，充分挖掘系统提供的强大功能和灵活性。

2.1 Win32 API 概论

在Windows程序设计领域处于发展初期时，Windows程序员可使用的编程工具唯有API 函数。这些函数在程序员手中犹如"积木块"一样，可搭建出各种界面丰富、功能灵活的应用程序。不过，由于这些函数结构复杂，所以往往难以理解，而且容易误用。

实际上，程序员要想开发出更灵活、更实用、更具效率的应用程序，必然要涉及到直接使用API函数。虽然类库和控件使应用程序的开发容易得多，但它们只提供Microsoft Windows 的一般功能，对于一些比较复杂和特殊的功能来说，单使用类库和控件是难以实现的，必须直接使用API函数来编写。API函数是构筑整个Windows框架的基石，只有充分理解和利用API函数，才能深入到Windows的内部，充分发挥各种32位平台的强大功能和灵活性，才能成功地扩展和突破类库、控件和可视开发环境的限制。

Win32 API即为Microsoft 32位平台的应用程序编程接口(Application Programming Interface)。所有在Win32平台上运行的应用程序都可以调用这些函数。

使用Win32 API，应用程序可以充分挖掘Windows的32位操作系统的潜力。Mircrosoft 的所有32位平台都支持统一的API，包括函数、结构、消息、宏及接口。使用Win32 API 不但可以开发出在各种平台上都能成功运行的应用程序，而且也可以充分利用每个平台特有的功能和属性。

在具体编程时，程序实现方式的差异依赖于相应平台的底层功能的不同。最显著的差异是某些函数只能在更强大的平台上实现其功能。例如，安全函数只能在Windows NT操作系统下使用。另外一些主要差别就是系统限制，比如值的范围约束，或函数可管理的项目个数等等。

标准Win32 API函数可以分为以下几类：

窗口管理λ

窗口通用控制λ

Shell特性λ

图形设备接口λ

系统服务λ

国际特性λ

网络服务λ

由于我们的系统是处于Windows平台下，相应的就要研究Windows平台下的系统监控程序设计的常用技术。由于监控程序是针对每个进程的，每个进程都有自己的地址空间，它们之间不能任意访问，为了监视每个进程的API函数调用情况，就需要各个进程和监控程序进行通信。

2.2 跨进程API Hook

众所周知Windows应用程序的各种系统功能是通过调用API函数来实现。API Hook就是给系统的API附加上一段小程序，它能监视甚至控制应用程序对API函数的调用。所谓跨进程也就是让自己的程序来控制别人程序的API调用了。

2.2.1 API Hook理论

通过对Win32 PE文件的分析，我们知道在PE文件中的IMPORT TABLE内存储着API函

数的很多信息。其中包括API的函数名，调用地址等等。而操作系统在执行PE文件时会先将其映射到内存中。在映射的同时还会把当前版本操作系统中API函数的入口地址写入IMPORT TABLE中一组与API调用相关的结构体内，用于该应用程序的API调用。当应用程序调用API时，他会在自己内存映像里寻找API的入口地址，然后执行CALL指令。如此一来，通过修改应用程序内存映像的IMPORT TABLE中API函数的入口地址，就可以达到重定向API的目的。将API地址改为我们自己函数的地址，这样我们的函数就可以完成对API 的监视和控制了。

2.2.2 API Hook的实现

/*1*/HANDLE hCurrent = GetModuleHandle(NULL);

/*2*/IMAGE_DOS_HEADER *pidh;

/*3*/IMAGE_NT_HEADERS *pinh;

/*4*/IMAGE_DATA_DIRECTORY *pSymbolTable;

/*5*/IMAGE_IMPORT_DE脚本OR *piid;

/*6*/pidh = (IMAGE_DOS_HEADER *)hCurrent;

/*7*/pinh = (IMAGE_NT_HEADERS *)((DWORD)hCurrent + pidh->e_lfanew);

/*8*/pSymbolTable = &pinh->OptionalHeader.DataDirectory[1];

/*9*/piid =(IMAGE_IMPORT_DE脚本OR *)((DWORD)hCurrent + pSymbolTable->VirtualAddress);

/*10*/do {

/*11*/ IMAGE_THUNK_DATA *pitd,*pitd2;

/*12*/ pitd = (IMAGE_THUNK_DATA *)((DWORD)hCurrent + piid->OriginalFirstThunk); /*13*/ pitd2 = (IMAGE_THUNK_DATA *)((DWORD)hCurrent + piid->FirstThunk);

/*14*/ do {

/*15*/ IMAGE_IMPORT_BY_NAME *piibn;

/*16*/ piibn = (IMAGE_IMPORT_BY_NAME *)((DWORD)hCurrent + *((DWORD *)pitd)); /*17*/ PROC *ppfn = (PROC *)(pitd2->u1.Function);

/*18*/ if (!strcmp("MessageBoxW",(char *)piibn->Name)) {

/*19*/ oldMsg = (MsgBox无效)(ppfn);

/*20*/ DWORD addr = (DWORD)MyMessage;

/*21*/ DWORD written = 0;

/*改变内存读写状态*/

/*22*/ DWORD oldAccess;

/*23*/

VirtualProtect(&pitd2->u1.Function,sizeof(DWORD),PAGE_WRITECOPY,&oldAccess);

/*24*/ APIAddress = (DWORD)&pitd2->u1.Function;

/*向内存映像写入数据*/

/*25*/ WriteProcessMemory(GetCurrentProcess(),&pitd2->u1.Function, &addr,sizeof(DWORD), &written);

/*26*/ }

/*27*/ pitd++;pitd2++;

/*28*/ } while (pitd->u1.Function);

/*29*/ piid++;

/*30*/} while (piid->FirstThunk + piid->Characteristics

+ piid->ForwarderChain + piid->Name + piid->TimeDateStamp);

分析:

(1) 寻觅IMPORT TALBE

在/*1*/中使用GetModuleHandle(NULL)来返回当前进程在内存中映像的基地址。但这个值在文档中仅仅被描述为“a module handle for the specified module”，虽然他确实是进程内存映像的基地址。如果不太放心的话也可以使用GetModuleInformation函数来获得基地址，只不过要额外包含psapi.h和psapi.lib了。

在/* 6 */里先找到IMAGE_DOS_HEADER结构，起始地址就是映像的基地址。

/*7*/通过IMAGE_DOS_HEADER给出的PE文件头的偏移量，找到IMAGE_NT_HEADERS 结构。顺藤摸瓜，IMAGE_NT_HEADERS里的OptionalHeader中的DataDirectory数组里的第二个元素正是指向我们想要的IMPORT TABLE的地址。

在/*9*/中将其转化为一个IMAGE_IMPORT_DE脚本OR的结构指针存入piid中。

(2) 替换的API函数入口地址

在/*12*/和/*13*/中分别取得OriginalFirstThunk和FirstThunk结构，用于以后得到API函数的名称和入口地址。

/*10*/的do循环遍历每一个IMAGE_IMPORT_DE脚本OR结构也就是应用程序引用的每个DLL。

在/*14*/的循环中遍历DLL中的IMAGE_THUNK_DATA结构来一一查询API的信息。

/*16*/中将OriginalFirstThunk转换为IMAGE_IMPORT_BY_NAME结构用于获得API函数的名称进行比对。

/*18*/找到MessageBoxW函数之后，在/*19*/保存其原始入口地址便于以后恢复时使用。在/*23*/需要用VirtualProtect改变一下内存区域的读写性，因为一般应用程序的映像都是只读的，直接写入会造成一个非法访问的异常出现。

在/*25*/我们写入自己函数的地址。

这样就基本完成一个API函数的重定向。

(3) 其他

恢复函数的API入口地址相对比较简单。只要把保存的值再写回去就可以了。上面的程序中/*24*/我用APIAddress保存了存有MessageBoxW入口地址的地方的地址，便于以后调用WriteProcessMemory恢复时使用。

2.2.3 跨进程理论

我们要用自己的函数来替代别人程序里的API函数，但我们的函数与别人的程序处于不同的进程空间内。不同的进程空间是不能相互调用函数的。因此我们要想办法把自己的函数放入别人的进程空间去。这时我们就需要使用DLL injection技术了。

简而言之，DLL injection就是想办法让对方的进程加载我们的一个DLL程序，把需要替换的函数放在我们这个DLL里。如此一来，我们的函数就进入了别人的进程空间了。DLL injection方法很多，我在这里使用SetWindowsHookEx函数来达到目的。主要有这几个原

因：1，不用重新启动系统，调试方便。2，可以利用消息循环机制进行两个进程之间的通信，可以较好的掌握Hook的状态，便于安装与卸载。

SetWindowsHookEx之所以能完成DLL injection是因为它要给一个应用程序某个环节加上一个Hook,而Hook就要有Hook Procedure也就是Hook函数。如果这个Hook函数在一个DLL中，那么系统就会把这个DLL加载到SetWindowsHookEx的目标进程上。从而也就达到了我们DLL injection的目的了。当然这里我们会用WH_GETMESSAGE的Hook进行injection,因为这个Hook可以用来监视目标进程的消息循环方便我们的进程与目标进程通信。

2.2.4 跨进程的实现和几点注意

/* DllPart.Dll */

#include

#include

#include

#include

无效def (WINAPI *MsgBox无效)(HWND,LPCWSTR,LPCWSTR,UINT);

MsgBox无效oldMsg; /*API原入口地址*/

DWORD APIAddress; /*存储API入口地址的地方的地址*/

int WINAPI MyMessage(HWND hWnd ,LPCWSTR M1,LPCWSTR M2, UINT M3) {

/*这是用来替换的函数*/

return oldMsg(hWnd,buf,M2,MB_OK);

}

const char szApp[] = "DllPart.dll";

HHOOK hHook; /*Hook的句柄*/

HMODULE hInst; /*DLL 模块句柄，用于SetWindowsHookEx函数*/

HWND hTarget; /*目标窗口句柄*/

/*DLL 入口*/

BOOL WINAPI DllMain(HINSTANCE inst, DWORD reason, LPVOID lpvReserved)

{

hInst = inst;

switch (reason) {

case DLL_PROCESS_ATTACH:

/*调试信息，表示DLL已经加载*/

MessageBox(NULL,"DLL_PROCESS_ATTACH",szApp,MB_OK);

break;

case DLL_PROCESS_DETACH:

/*调试信息，表示DLL已经卸载*/

MessageBox(NULL,"DLL_PROCESS_DETACH",szApp,MB_OK);

break;

}

return true;

}

/*显示GetLastError的信息*/

void showerr(const char *m) {

char message[255];

FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM,0,GetLastError()

,MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),message,255, 0); MessageBox(NULL,message,m,MB_OK);

}

//-----------------------

void UnHookApi() {

/*卸载API Hook用*/

}

void HookApi() {

/*加载API Hook同上面介绍的函数一样*/

}

//-----------------------

/*用于WH_GETMESSAGE的Hook Procedure*/

LRESULT CALLBACK GetMsgProc(int nCode,WPARAM wParam, LPARAM lParam) { if (nCode == HC_ACTION) {

MSG *msg = (MSG *)lParam;

if (msg->message == WM_CHAR) {

if (msg->wParam == 'h') HookApi();

if (msg->wParam == 'u') UnHookApi();

}

}

return CallNextHookEx(hHook,nCode,wParam,lParam);

}

extern "C" __declspec(dllexport) SetAPIHook(HWND handle) {

DWORD ThreadId = GetWindowThreadProcessId(handle, NULL);

hTarget = handle;

MessageBox(NULL, "Enabling CallWndProc Hook", szApp, MB_OK);

hHook = SetWindowsHookEx(WH_GETMESSAGE,GetMsgProc,hInst,ThreadId);

if (hHook) {

MessageBox(NULL,"Hook OK!", szApp, MB_OK);

} else {

showerr("SetWindowsHookEx");

}

}

extern "C" __declspec(dllexport) UnHookAPIHook() {

MessageBox(NULL, "Disenabling CallWndProc Hook", szApp, MB_OK);

if (UnhookWindowsHookEx(hHook)) {

MessageBox(NULL,"UnHook OK!", szApp, MB_OK);

} else {

showerr("UnHookWindowsHookEx");

}

}

分析:

几个需要注意的问题:

SetAPIHook和UnHookAPIHook是我们自己进程调用的用来加载WH_GETMESSAGE Hook 的函数。由于程序要用LoadLibrary加载这个Dll因此这两个函数要用__declspec(dllexport)修饰，使其成为导出函数，才能被GetAddressProc函数找到。加上extern "C"是让编译器使用C语言编码方式。因为C++编译器会进行Dynamic Binding(C++函数重载的实现),将函数的参数类型附加到名称上。是函数的导出名看起来像SetAPIHook@XYTZX之类的,不利于GetAddressProc进行引用。因此使用extern "C"让编译器不使用Dynamic Binding，自然使用extern"C"的函数也就不能被重载了。

不要忘记在GetMsgProc最后要调用CallNextHookEx函数，保证Hook链的完整性。

一定要在Hook Procedure中调用HookApi和UnHookApi函数，因为保存API入口地址的地方在目标进程中，必须在目标进程的进程空间内完成卸载操作，不能在UnHookAPIHook或是SetAPIHook函数中调用，因为UnHookAPIHook是我们的进程调用的，因此在我们的进程空间中。在这里使用UnHookApi会造成一个非法访问的错误。而使用HookApi会给自己的DLL加上API Hook。

SetWindowsHookEx的最后参数是ThreadId不是Handle,因此要通过调用GetWindowThreadProcessId转换一下。

2.2.5 在跨进程API HOOK时可能用到的其他技术

(1) 主进程与目标进程的信息交互和共享

由于使用了WH_GETMESSAGE钩子我们可以利用Windows消息机制实现进程间通讯。需要注意的是应该使用PostThreadMessage来发送让WH_GETMESSAGE得到的消息而不是SendMessage或者PostMessage,因为后两个是用来给窗口发送消息的。而我们的WH_GETMESSAGE是Hook在线程上面的，因此需使用PostThreadMessage.

传递不太大的数据可以使用WM_COPYDATA消息来进行。同样也应该注意，如果使用MFC 的窗口过程获得消息就需要用SendMessage发送了。

如果传递较大的数据或者希望数据共享比较方便可以开辟共享内存来进行数据共享。这里简单分析一下使用共享内存的代码：

HANDLE hMap;

switch (reason) {

case DLL_PROCESS_ATTACH:

/*创建/打开共享内存区域*/

hMap = CreateFileMapping((HFILE *)0xFFFFFFFF, NULL, PAGE_READWRITE, 0, sizeof(GLOBALDATA), ID_MAP);

pg_data = (GLOBALDATA*)MapViewOfFile(hMap,FILE_MAP_ALL_ACCESS,0 ,0 ,0);

if (!pg_data) {

MessageBox(NULL,"无法建立共享内存，程序终止！",szApp,MB_OK);

if (hMap) {

CloseHandle(hMap);

hMap = NULL;

return 0;

}

pg_data->hInst = hInst;

showerr("共享内存映像文件");

showerr("DLL装载中...",FALSE);

break;

case DLL_PROCESS_DETACH:

if (pg_data) {

UnmapViewOfFile(pg_data);

pg_data = NULL;

}

if (hMap) {

CloseHandle(hMap);

hMap = NULL;

}

break;

}

上面的代码通过CreateFileMapping建立共享区域。将其第一个参数设置为0xFFFFFFFF使其能创建一个内存共享区域而不是文件。并标记为可读写的(PAGE_READWRITE).其大小为我们定义的结构体GLOBALDATA的大小。最后的ID_MAP是一个用来标示这个区域的字符串。打开或者创建完共享区域后，我们用MapViewOfFile来获得这个区域的地址。之后就可以直接使用pg_data来操作共享区域了。不要忘记在DLL退出的时候安全的删除共享区域释放内存。

(2) 消息等待与安全卸载

在卸载WH_GETMESSAGE钩子之前必须先把目标程序的API调用恢复正常。不能再调用UnHookApi之后就立刻调用UnhookWindowsHookEx，因为很有可能UnHookApi还没来得急完成API入口地址的恢复操作，WH_GETMESSAGE钩子就已经被卸载了。因此需要等待一段时间，等UnHookApi完成了恢复操作在调用UnhookWindowsHookEx，以防错误发生。extern "C" __declspec(dllexport) void UnHookAPIHook() {

/*向目标线程发送消息进行API UNHOOK*/

PostThreadMessage(pg_data->idTarget,WM_DISABLEAPIHOOK,(WPARAM)GetCurrentThr eadId(),0);

showerr("WM_DISABLEAPIHOOK");

/*等待目标进程返回WM_UNHOOKOK消息，确认可以将WH_GETMESSAGE的HOOK去掉*/

MSG Msg;

do {

GetMessage(&Msg,NULL,0,0);

}while(Msg.message != WM_UNHOOKOK);

UnhookWindowsHookEx(pg_data->hHook);

PostThreadMessage(pg_data->idTarget,WM_DISABLEAPIHOOKOK,(WPARAM)GetCurrent ThreadId(),0);

showerr("UnHookWindowsHookEx");

}

上面的代码中我们使用一个含有GetMessage的循环来等待消息的到达，一旦UnHookApi 完成他就会发送WM_UNHOOKOK消息。等我们接收到消息确认一切安全了在来卸载WH_GETMESSAGE钩子。

(3) 弄清消息对象

我们一定要清楚代码是在主程序进程空间中执行的还是在目标程序进程空间中执行的。像上面的UnHookAPIHook函数就是通过主程序调用的，因此在主程序进程空间中执行。这样一来用来恢复目标程序API信息的UnHookApi完成后就应该向主程序发送消息，而不是目标程序。

(4) 目标进程加载了其他DLL

如果目标进程动态加载了其他的DLL文件，我们必须监视LoadLibrary函数，保证DLL中的API入口地址也被正确修改，防止出现混乱的情况。我从LoadLibrary获得DLL的路径用于GetModuleHandle来取得他的ImageBase的地址。

(6):第三章利用数据挖掘技术的入侵检测模型架构

本系统由四个主要的模块组成：传感器(Sensor Component) 、检测器(Detector Component) 、通信器(Communication Component)以及数据仓库(Data Warehouse Component)，如图3.1所示。

图3.1 基于数据挖掘的主机入侵检测系统的体系结构

该系统的设计与传感器的数据格式和模型的表示无关，其中每一个数据可以包含任意数量的属性，而每一个属性也可以是连续的或是离散的，可以是数字的或是符号的。在这个框架中，检测模型的生成算法利用了数据挖掘算法，当然也可以使用任意其他能够从包含入侵的训练集中获取模型的算法，如统计方法和神经网络方法等。为了处理这种多样型，在这个框架中使用了XML编码，这种编码能够很方便地转换为CIDF或IDMEF(Intrusion Detection Message Format)格式，以便各个组件间能够很方便地交换数据和模型。而通信器的作用就像是一个数据交换机，各模块间所有的通信数据都通过通信器来传递。

3.1 传感器

在现有的操作系统环境下，可以很方便地在系统的底层捕获系统内所有的活动。在这个系统中，传感器是由一系列轻量(Lightweight)的审计程序构成。这些审计程序在操作系统的后台运行以收集审计的信息并将之送到通信器中。例如在Windows环境下，利用Win32的“钩子(Hook)”程序可以简单地实现这个功能，它可以进入数据流并将之截取然后送到通信器中。在该系统中传感器可以看成是被监控的主机的一个接口，因此在该系统中可以不用理会审计程序是怎样工作的。

从传统的客户/服务器的角度来看，传感器是一个客户程序。多个审计程序必须能够以一种表面上是无缝的方式在系统中一起正常地工作。同时各审计程序也必须是彼此互相独立的，并且和主系统也是相互独立的，各审计程序的运行和停止不应该影响到其他程序的运行，也不应该影响整个系统的性能。

3.2 通信器

通信器主要起着一个帮助数据交换的作用。它主要包括传感器管理器、数据仓库管理器、检测器管理器、报警器管理器四个部分。传感器管理器的作用主要是将传感器送来的原始审计数据用XML编码进行格式处理，然后将格式化的数据送往数据仓库和检测器管理器。数据仓库管理器的作用有两点：一是处理格式化的数据，包括存储进数据仓库中和从数据仓库中取出；二是处理入侵检测的模型，包括对模型的存储、检索和更新。检测器管理器的作用有以下几点：一是处理格式化的数据，包括对实时数据送到实时检测引擎中和将从数据仓库中提取的数据送到检测模型生成器；二是处理检测模型，包括将检测模型生成器生成或更新的模型送往数据仓库管理器和将从数据仓库中提取的模型送到检测模型分发器；三是处理报警信息，主要是将实时检测引擎送出的报警信息送到报警器管理器。报警器管理器的作用主要是一方面将报警信息送到数据仓库中存储，另一方面将报警信息送出以对入侵进行处理。为了提高整个系统的自适应能力，一开始通信器在一个指定的端口监听是否有新的审计程序加入系统，这样就可以在系统运行时增加或减少审计程序。

3.3 检测器

检测器是整个系统的核心，包括检测模型生成器，检测模型分发器和实时检测引擎。

检测模型生成器是一个离线的程序，它利用数据仓库中存储的审计数据，使用多种模型生成算法非实时地产生入侵模型，因此可以看出它是一个黑匣子，是整个系统的一个插件。其

输入是数据的训练集，输出是可疑行为的模型，而不同的模型生成算法需要不同的训练集。因此在本系统中，检测模型生成器是可以通过通信器对数据仓库中的数据进行任意查询的。整个模型生成的过程就是一个数据挖掘的过程。

检测模型分发器的作用就是将检测模型分发到实时检测引擎中，以保证实时检测引擎中的检测模型始终是最新的。在实时检测的环境下，实时检测引擎不可能经常查询数据仓库来更新检测模型，因为这样做的效率非常低下，并且在系统中，实时检测引擎同样也需要是一个轻量的程序，因此将检测模型分发器分离出来，它将自动地将更新的模型传送给实时检测引擎，这样会大大提高整个系统的效率。

3.4 数据仓库

数据仓库主要是用来集中存储数据和模型。这样的一个好处就是不同的组件可以异步地处理存储在一个数据库中的同一块数据，比方说离线的训练和人工地做标记。同一种类型的组件，例如多个审计程序也可以同时处理数据。而相关的数据库的特性也为有效处理数据提供了方便。数据仓库还可以将来源不用的传感器的数据整合。总而言之，数据仓库是整个系统的根本立足点。

3.5 报警器

报警器的主要任务是在接到入侵的报警报告后采取相应的措施来处理入侵，比如关闭端口、断开连接等，可以人工地进行，也可以自动地进行。

(7):第四章系统主要模块研究

4.1 传感器部分

这一部分便可以灵活、自由地应用第二章所描述的Win32 API以及跨进程API HOOK技术实现，进行收集日志、调用信息以及进程见通讯。

在Windows中可以利用Windows的特性和自身提供的一些功能实现下面这几种传感器：Windows事件日志传感器、软件使用监视传感器、netstat传感器和注册表传感器。Windows事件日志传感器的功能主要是收集日志。在Windows NT中可以设置系统记录多种日志，其中包括应用、安全和事件日志，在设置后Windows自己就会监视系统的各种状况并写入日志中，因此可以开发一个程序来监听系统日志，它将系统日志送到通信器中，并在系统日志增加了新记录后捕获到日志的更新，将更新的记录截取并送到通信器中。

软件使用监视传感器的功能主要是收集系统调用的信息。在Windows下可以利用钩子程序将用户在本机上应用程序和系统程序的使用情况完全收集起来，并送到通信器中。Netstat传感器主要是利用Windows提供的netstat工具来收集在本机上建立的网络连接的信息。Netstat命令可以提供在本机上所有开放的端口的信息。可以设计一个程序每隔一段时间定时地执行netstat命令，并将结果输出，但是这样会加重系统的负担，在一个比较繁忙的系统中，几天的记录就有可能会有几个G的大小。因此可以优化该程序，让程序在第