以下是小编收集整理的入侵检测系统（IDS）简介，本文共8篇，希望对大家有所帮助。本文原稿由网友“shoven”提供。
篇1：入侵检测系统（IDS）简介
第一章 入侵检测系统概念
当越来越多的公司将其核心业务向互联网转移的时候，网络安全作为一个无法回避的问题呈现在人们面前，传统上，公司一般采用防火墙作为安全的第一道防线。而随着攻击者知识的日趋成熟，攻击工具与手法的日趋复杂多样，单纯的防火墙策略已经无法满足对安全高度敏感的部门的需要，网络的防卫必须采用一种纵深的、多样的手段。与此同时，当今的网络环境也变得越来越复杂，各式各样的复杂的设备，需要不断升级、补漏的系统使得网络管理员的工作不断加重，不经意的疏忽便有可能造成安全的重大隐患。在这种环境下，入侵检测系统成为了安全市场上新的热点，不仅愈来愈多的受到人们的关注，而且已经开始在各种不同的环境中发挥其关键作用。
本文中的“入侵”（Intrusion）是个广义的概念，不仅包括被发起攻击的人（如恶意的 ）取得超出合法范围的系统控制权，也包括收集漏洞信息，造成拒绝访问（Denial of Service）等对计算机系统造成危害的行为。
入侵检测（Intrusion Detection），顾名思义，便是对入侵行为的发觉。它通过对计算机网
络或计算机系统中得若干关键点收集信息并对其进行分析，从中发现网络或系统中是否有违反安全策略的行为和被攻击的迹象。进行入侵检测的软件与硬件的组合便是入侵检测系统（Intrusion Detection System,简称IDS）。与其他安全产品不同的是，入侵检测系统需要更多的智能，它必须可以将得到的数据进行分析，并得出有用的结果。一个合格的入侵检测系统能大大的简化管理员的工作，保证网络安全的运行。
具体说来，入侵检测系统的主要功能有（[2]）：
a.监测并分析用户和系统的活动；
b.核查系统配置和漏洞；
c.评估系统关键资源和数据文件的完整性；
d.识别已知的攻击行为；
e.统计分析异常行为；
f.操作系统日志管理，并识别违反安全策略的用户活动。
由于入侵检测系统的市场在近几年中飞速发展，许多公司投入到这一领域上来，
除了国外的ISS、axent、NFR、cisco等公司外，国内也有数家公司（如中联绿盟，中科网威等）推出了自己相应的产品。但就目前而言，入侵检测系统还缺乏相应的标准。目前，试图对IDS进行标
准化的工作有两个组织：IETF的Intrusion Detection Working Group (idwg)和Common Int
rusion Detection Framework (CIDF)，但进展非常缓慢，尚没有被广泛接收的标准出台。
第二章 入侵检测系统模型
2.1 CIDF模型
Common Intrusion Detection Framework (CIDF)（www.gidos.org/）阐述了一个入侵检测系统（IDS）的通用模型。它将一个入侵检测系统分为以下组件：
l事件产生器（Event generators）
l 事件分析器（Event analyzers
l 响应单元（Response units ）
l 事件数据库（Event databases ）
CIDF将IDS需要分析的数据统称为事件（event）,它可以是网络中的数据包，也可以是从系统
日志等其他途径得到的信息。
事件产生器的目的是从整个计算环境中获得事件，并向系统的其他部分提供此事件。事件分析器分析得到的数据，并产生分析结果。响应单元则是对分析结果作出作出反应的功能单元，它可以作出切断连接、改变文件属性等强烈反应，也可以只是简单的报警。事件数据库是存放各种中间和最终数据的地方的统称，它可以是复杂的数据库，也可以是简单的文本文件。
在这个模型中，前三者以程序的形式出现，而最后一个则往往是文件或数据流的形式。
在其他文章中，经常用数据采集部分、分析部分和控制台部分来分别代替事件产生器、事件分析器和响应单元这些术语。且常用日志来简单的指代事件数据库。如不特别指明，本文中两套术语意义相同。
2.2 IDS分类
一般来说，入侵检测系统可分为主机型和网络型。
主机型入侵检测系统往往以系统日志、应用程序日志等作为数据源，当然也可以通过其他手段（如监督系统调用）从所在的主机收集信息进行分析。主机型入侵检测
篇2：入侵检测系统IDS测试与评估
随着入侵检测系统的广泛应用，对入侵检测系统进行测试和评估的要求也越来越迫切，开发者希望通过测试和评估发现产品中的不足，用户希望测试和评估来帮助自己选择合适的入侵检测产品。本文根据目前的相关研究，介绍了入侵检测系统测试评估的标准、指标，方法步骤、数据来源、环境配置、测试评估的现状以及其中存在的一些问题。
1、引言
随着人们安全意识的逐步提高，入侵检测系统（IDS）的应用范围也越来越广，各种各样的IDS也越来越多。那么IDS能发现入侵行为吗？IDS是否达到了开发者的设计目标？什么样的IDS才是用户需要的性能优良的IDS呢？要回答这些问题，都要对IDS进行测试和评估。
和其他产品一样，当IDS发展和应用到一定程度以后，对IDS进行测试和评估的要求也就提上日程表。各方都希望有方便的工具，合理的方法对IDS进行科学。公正并且可信地测试和评估。对于IDS的研制和开发者来说，对各种IDS进行经常性的评估，可以及时了解技术发展的现状和系统存在的不足，从而将讲究重点放在那些关键的技术问题上，减少系统的不足，提高系统的性能；而对于IDS的使用者来说，由于他们对IDS依赖程度越来越大，所以也希望通过评估来选择适合自己需要的产品，避免各IDS产品宣传的误导。IDS的用户对测试评估的要求尤为迫切，因为大多数用户对IDS本身了解得可能并不是很深入，他们希望有专家的评测结果作为自己选择IDS的依据。
总地来说，对IDS进行测试和评估，具有以下作用：
・有助于更好地刻划IDS的特征。通过测试评估，可更好地认识理解IDS的处理方法、所需资源及环境；建立比较IDS的基准；领会各检测方法之间的关系。
・对IDS的各项性能进行评估，确定IDS的性能级别及其对运行环境的影响。
・利用测试和评估结果，可做出一些预测，推断IDS发展的趋势，估计风险，制定可实现的IDS质量目标（比如，可靠性、可用性、速度、精确度）、花费以及开发进度。
・根据测试和评估结果，对IDS进行改善。也就是发现系统中存在的问题并进行改进，从而提高系统的各项性能指标。
本文首先介绍了测试评估IDS性能的标准，然后介绍了测试评估的方法步骤，并且介绍测试评估的具体指标、所需的数据源、测试评估环境配置与框架，最后介绍了测试评估现状以及其中存在的一些问题。
2、测试评估IDS性能的标准
根据Porras等的研究，给出了评价IDS性能的三个因素：
・准确性（Accuracy）：指IDS从各种行为中正确地识别入侵的能力，当一个IDS的检测不准确时，就有可能把系统中的合法活动当作入侵行为并标识为异常（虚警现象）。
・处理性能（Performance）：指一个IDS处理数据源数据的速度。显然，当IDS的处理性能较差时，它就不可能实现实时的IDS，并有可能成为整个系统的瓶颈，进而严重影响整个系统的性能。
・完备性（Completeness）：指IDS能够检测出所有攻击行为的能力。如果存在一个攻击行为，无法被IDS检测出来，那么该JDS就不具有检测完备性。也就是说，它把对系统的入侵活动当作正常行为（漏报现象）。由于在一般情况下，攻击类型、攻击手段的变化很快，我们很难得到关于攻击行为的所有知识，所以关于IDS的检测完备性的评估相对比较困难。
在此基础上，Debar等又增加了两个性能评价测度：
・容错性（Fault Tolerance）：由于IDS是检测入侵的重要手段／所以它也就成为很多入侵者攻击的首选目标。IDS自身必须能够抵御对它自身的攻击，特别是拒绝服务（Denial-of-Service）攻击。由于大多数的IDS是运行在极易遭受攻击的操作系统和硬件平台上，这就使得系统的容错性变得特别重要，在测试评估IDS时必须考虑这一点。
・及时性（Timeliness）：及时性要求IDS必须尽快地分析数据并把分析结果传播出去，以使系统安全管理者能够在入侵攻击尚未造成更大危害以前做出反应，阻止入侵者进一步的破坏活动，和上面的处理性能因素相比，及时性的要求更高。它不仅要求IDS的处理速度要尽可能地快，而且要求传播、反应检测结果信息的时间尽可能少。
3、IDS测试评估的方法步骤
前面我们已经讨论了IDS测试评估的性能指标，具体测试主要就是围绕这些指标来进行。大部分的测试过程都遵循下面的基本测试步骤：
・创建、选择一些测试工具或测试脚本。这些脚本和工具主要用来生成模拟的正常行为及入侵，也就是模拟IDS运行的实际环境。
・确定计算环境所要求的条件，比如背景计算机活动的级别。
・配置运行IDS。
・运行测试工具或测试脚本。
・分析IDS的检测结果。
美国加州大学的Nicholas J．Puketza等人把测试分为三类，分别与前面的性能指标相对应，即入侵识别测试（也可以说是IDS有效性测试）。资源消耗测试、强度测试。入侵识别测试测量IDS区分正常行为和入侵的能力，主要衡量的指标是检测率和虚警率。资源消耗测试（Resource Usage Tests）测量IDS占用系统资源的状况，考虑的主要因素是硬盘占用空间、内存消耗等。强度测试主要检测IDS在强负荷运行状况下检测效果是否受影响，主要包括大负载、高密度数据流量情况下对检测效果的检测。
4、测试评估IDS的性能指标
在我们分析IDS的性能时，主要考虑检测系统的有效性、效率和可用性。有效性研究检测机制的检测精确度和系统检测结果的可信度，它是开发设计和应用IDS的前提和目的，是测试评估IDS的主要指标，效率则从检测机制的处理数据的速度以及经济性的角度来考虑，也就是侧重检测机制性能价格比的改进。可用性主要包括系统的可扩展性、用户界面的可用性，部署配置方便程度等方面。有效性是开发设计和应用IDS的前提和目的，因此也是测试评估IDS的主要指标，但效率和可用性对IDS的性能也起很重要的作用。效率和可用性渗透于系统设计的各个方面之中。本节从检测的有效性、效率以及可用性角度，对测试评估IDS的性能指标进行分析讨论。
4.1 检测率、虚警率及检测可信度
检测率是指被监控系统在受到入侵攻击时，检测系统能够正确报警的概率。虚警率是指检测系统在检测时出现虚警的概率。检测可信度也就是检测系统检测结果的可信程度，这是测试评估IDS的最重要的指标。
实际的IDS的实现总是在检测率和虚警率之间徘徊，检测率高了，虚警率就会提高；同样虚警率降低了，检测率也就会降低。一般地，IDS产品会在两者中取一个折衷，并且能够进行调整，以适应不同的网络环境。美国的林肯实验室用接收器特性（ROC，Receiver Operating Characteristic）曲线来描述IDS的性能。该曲线准确刻画了IDS的检测率与虚警率之间的变化关系。ROC广泛用于输入不确定的系统的评估。根据一个IDS在不同的条件（在允许范围内变化的阈值，例如异常检测系统的报警门限等参数）下的虚警率和检测率，分别把虚警率和检测率作为横坐标和纵坐标，就可做出对应于该IDS的ROC曲线。ROC曲线与IDS的检测门限具有对应的关系。
在测试评估IDS的具体实施过程中，除了要IDS的检测率和虚警率之外，往往还会单独考虑与这两个指标密切相关的一些因素，比如能检测的入侵特征数量、IP碎片重组能力、TCP流重组能力。显然，能检测的入侵特征数量越多，检测率也就越高。此外，由于攻击者为了加大检测的难度甚至绕过IDS的检测，常常会发送一些特别设计的分组。为了提高IDS的检测率降低IDS的虚警率，IDS常常需要采取一些相应的措施，比如IP碎片能力、TCP流重组。因为分析单个的数据分组会导致许多误报和漏报，所以IP碎片的重组可以提高检测的精确度。IP碎片重组的评测标准有三个性能参数：能重组的最大IP分片数；能同时重组的IP分组数；能进行重组的最大IP数据分组的长度，TCP流重组是为了对完整的网络对话进行分析，它是网络IDS对应用层进行分析的基础。如检查邮件内容。附件，检查FTP传输的数据，禁止访问有害网站，判断非法HTTP请求等。这两个能力都会直接影响IDS的检测可信度。
4.2 IDS本身的抗攻击能力
和其他系统一样，IDS本身也往往存在安全漏洞。若对IDS攻击成功，则直接导致其报警失灵，入侵者在其后所作的行为将无法被记录。因此IDS首先必须保证自己的安全性。IDS本身的抗攻击能力也就是IDS的可靠性，用于衡量IDS对那些经过特别设计直接以IDS为攻击目标的攻击的抵抗能力。它主要体现在两个方面：一是程序本身在各种网络环境下能够正常工作；二是程序各个模块之间的通信能够不被破坏，不可仿冒。此外要特别考虑抵御拒绝服务攻击的能力。如果IDS本身不能正常运行，也就失去了它的保护意义。而如果系统各模块间的通信遭到破坏，那系统的报警之类的检测结果也就值得怀疑，应该有一个良好的通信机制保证模块间通信的安全并能在出问题时能够迅速恢复。
4.3 其他性能指标
延迟时间。检测延迟指的是在攻击发生至IDS检测到入侵之间的延迟时间。延迟时间的长短直接关系着入侵攻击破坏的程度。
资源的占用情况。即系统在达到某种检测有效性时对资源的需求情况。通常，在同等检测有效性的前提下，对资源的要求越低，IDS的性能越好，检测入侵的能力也就越强。
负荷能力。IDS有其设计的负荷能力，在超出负荷能力的情况下，性能会出现不同程度的下降。比如，在正常情况下IDS可检测到某攻击但在负荷大的情况下可能就检测不出该攻击。考察检测系统的负荷能力就是观察不同大小的网络流量、不同强度的CPU内存等系统资源的使用对IDS的关键指标（比如检测率、虚警率）的影响。
日志、报善、报告以及响应能力。日志能力是指检测系统保存日志的能力、按照特定要求选取日志内容的能力。报警能力是指在检测到入侵后，向特全部件、人员发送报警信号的能力以及在报警中附加信息的能力。报告能力是指产生入侵行为报告、提供查询报告、创建和保存报告的能力。响应能力是指在检测到入侵后进一步处理的能力，这包括阻断入侵、跟踪入侵者、记录入侵证据等。
系统的可用性。主要是指系统安装、配置、管理、使用的方便程度，系统界面的友好程度，攻击规则库维护的简易程度等方面。
总之，IDS是个比较复杂的系统，对IDS进行测试和评估不仅和IDS本身有关，还与应用IDS的环境有关。测试过程中涉及到操作环境、网络环境、工具、软件、硬件等方面。我们既要考虑入侵检测的效果如何，也要考虑应用该系统后它对实际系统的影响，有时要折衷考虑这两种因素，
5、对IDS进行测试评估一利用的相关数据
对IDS进行测试评估，也就是让IDS对进入到受保护系统的数据进行检测，以确定检测系统能否发现其中的入侵。要测试评估IDS，最准确的数据当然是根据实际运行环境产生的数据，但这通常是行不通的。因为各机构的数据中都包含一些隐私信息，他们不愿公开这些数据，并且即使有机构愿意公开自己的数据，也不大适合用来做通用测试，因为特定机构的数据都带有明显的特有的一些特性，具有一定的局限性，可重复性也不好。为此，在具体测试的时候，大都采用一些测试工具。通过这些工具来生成IDS的测试数据。
测试评估数据的生成需要满足下面几个条件，即数据的生成必须能自动完成，不需要人为的干预；要具有一定的可重复性，也就是说需要时可以产生相同的数据；要有一定的健壮性，可在无人监控的条件下，可运行较长时间。
测试评估IDS的数据包括两部分，一部分是训练数据，另外一部分是实际测试数据。这两部分数据中都包括正常数据和入侵数据。只有在正常数据的背景下，对IDS的测试评估结果才是客观和全面的。入侵行为在背景数据的掩护下，被检测系统发现的机率会大大降低。而IDS也可能将正常的流量行为误判为攻击，产生虚警。训练数据用来帮助IDS建立正常行为的模型，调整IDS各参数的设置。在训练数据中，入侵数据是明确标明的。测试数据用来对检测系统进行测试，其中的入侵数据没有标明。
通常使用下面三种方法生成既包含正常通信数据又有攻击的可公用的数据：抓取正常情况和被受控攻击时的运行通信数据。由于隐私和安全问题这显然行不通；从实际运行数据中清除秘密信息。并在其中加入攻击，这也行不通，因为很难清除秘密信息；在一个内部网中重建正常通信和攻击数据，这是我们采用的方法。
重建正常通信和攻击数据也就是仿真用户操作、模拟入侵。仿真用户操作即生成用户各种各样的正常使用模式，这些模式帮助基于异常检测的IDS建立正常行为的模型，并且以用户正常模式数据作为检测入侵的背景通信数据，对于确定IDS正常运行时的检测率和虚警率是非常必要的。模拟入侵应尽可能地覆盖多种类型，新的攻击只在测试数据一出现。设计攻击要考虑很多问题。要分析攻击的机制，并在测试系统中试验以便于分析和调节。分析要确定攻击在测试环境中能否工作，是否需要新软件或服务的支持。设计新奇的攻击以用来发现未利用的系统或网络漏洞。下面对用户正常模式的仿真和入侵仿真分别进行讨论。
目前，大多采用下面三种方法来仿真网络用户行为，即通用会话生成工具、测试软件包和录制重放实际数据。通用会话生成工具方法基于有限自动机来生成用户所有可能的操作。每种操作都有一定的操作规程，比如FTP操作，首先它要完成TCP三步握手初始化连接，然后要输入用户名和密码，用户名密码通过之后再浏览FTP服务器上的内容、下载或者上传，所有操作完成后离开服务器，结束TCP会话。根据这种通用规程，就可生成通用的会话，模拟用户操作。但是，这种方法只适用于测试有限的命令集，比如可仿真FTP客户，但不能仿真shell客户，并且这种仿真存在一些问题，因为用户操作的顺序和服务器端的响应都是不确定的，仿真并不能完全模拟用户的操作状况。操作系统开发商自带测试软件包是比较简单的模拟方法，通常用于测试评估操作系统服务的性能和应用服务软件是否按设计说明来实现。但是这种测试不能给出用户进行什么样的操作，只能告诉我们系统对正常请求的响应行为。录制重放方法是记录各种用户正常活动的数据，然后在测试平台上重放用户的活动过程。这种方法要求用户活动记录要足够多。
用户正常行为的仿真主要包括网络流量仿真、主机正常使用仿真。大多数的网络IDS或者网络IDS的大部分都工作于网络层或网络层之上，它们对网络上的数据分组根据不同的协议进行相应的分析。因此，在仿真网络流量时，要仿真各种协议的各种应用的流量。通常，对实际流量进行分析，经统计计算，得到各个协议按时间的流量概率分布，以此为模型，分别仿真各个协议的流量。
主机的使用可以分为两个部分：主机所提供的网络服务的使用和主机的直接使用，即用户在主机上执行命令。相应的主机正常使用的仿真要分为两部分，即主机网络服务正常使用的仿真和主机直接使用的仿真。对主机提供的网络服务的正常使用进行仿真，可以采用两种方法。一是遍历法，即找出某个服务允许的所有正常使用模式，再由仿真程序，按这些模式依次对该服务进行访问。二是实际采样法，取得真实网络环境中某个服务的实际使用情况数据，分析出现的使用模式，再根据分析结果建立仿真模型进行仿真。此方法与网络流量仿真的方法类似。这两种方法各有优缺点、仿真实现中，应根据被仿真服务的具体情况进行选择。由于用户的行为因工作性质不同，会有很大差别，所以主机直接使用的仿真应将用户分为不同的种类（比如管理员、普通用户），根据不同的用户类型编写不同的脚本，实现主机直接使用的仿真。由于不同用户使用习惯变化很大，并且即使同一用户使用习惯也带有很大的随机性，这使得仿真的难度大大增加。在实际测试评估IDS时，一般只是仿真主机正常使用的一个具有代表性的子集。
攻击仿真是评估环境的核心，也是对IDS进行测试的关键。攻击仿真要尽可能多地搜集各种攻击方法。由于各种攻击的数量过于庞大，不可能对所有的攻击都进行仿真。参考软件测试领域中的等价划分方法（equivalence partitioning），在进行攻击仿真时，一般先将攻击分类，然后选择每种类别中典型的攻击方法进行仿真试验。选择好攻击类型后，在仿真时根据入侵者进行攻击的步骤进行仿真。在构造攻击数据时还要注意新式攻击。攻击方式隐秘的攻击、并行进行的攻击等方面。相对于旧式攻击、攻击方式明显的攻击以及串行进行的攻击而言，这些攻击方式对检测结果的影响可能会更大。
目前，测试数据所采用的格式大多采用Tcpdump数据格式和BSM数据格式，由于Windows系统广泛应用，Windows NT的日志格式也逐渐考虑进来。在测试数据方面，麻省理工学院林肯实验室的数据比较完备，它包括一定时间的训练数据和用于最后实际测试的检测数据。用于网络流量仿真的工具有Anzen公司开发的nidsbench以及加利福尼亚大学开发的入侵检测测试平台。nidsbench包括tcpreplay和fraqrouter两部分。tcpreplay的功能是将tcpdump复制的数据分组重放，还原网络的实际运行状态；而fraqrouter的功能是通过构造一系列躲避IDS检测的攻击以测试检测系统的正确性和安全性。加利福尼亚大学的IDS软件测试平台使用 Tcl-DP（TooL Command Language Distributed Programming）工具开发实现。它共包含四组命令：基本的会话命令集、同步命令集、通信命令集、记录重放命令集。这些命令集分别用来仿真入侵者的基本操作，按指定要求产生事件，实现并发进程的通信以及记录用户会话期间的操作命令序列再重放这些记录。此外，麻省理工学院林肯实验室也开发了非实时IDS性能评估工具，该工具可动态重放大量的数据。
6、测试评估IDS的环境配置与框架
在测试评估IDS时，很少会把IDS放在实际运行的网络中，因为实际网络环境是不可控的，并且实际网络环境的专用性也太强，很难对IDS进行准确的系统测试。所以一般要构建专用的网络的环境。
受保护系统模拟主机正常运行状况，网络负载生成器模拟内部网之间以及内部网与外部网之间的网络通信。攻击模拟用来模拟入侵者发起的攻击。IDS即为待检测的系统。由于有时实际的网络环境很大，有很多安装各种各样操作系统、应用软件的主机服务器，要求测试环境完全按照实际网络进行配置并不是很实际，所以在测试中一般采用虚拟主机技术。通常使用一些软件工具或者编写可自动运行的脚本来模拟各种主机的各种行为，相当于在一台物理主机上运行多台虚拟主机，每个虚拟主机模拟不同硬件上运行的不同操作系统、不同应用程序。一般来说，受保护主机要包含运行常用操作系统（比如Windows、Linux、SunOS）的主机。内部网网络负载生成器要模拟内部的网络流量以及内部的攻击，而外部位网络负载生成器要模拟外部的网络流量（比如访问Web页面，下载文件）以及外部的攻击。实际构建测试环境的过程是个复杂过程，它直接关系到评测的成功与否。
7、IDS测试评估现状以及存在的问题
虽然IDS及其相关技术已获得了很大的进展，但关于IDS的性能检测及其相关评测工具、标准以及测试环境等方面的研究工作还很缺乏。
Puketza等人在1994年开创了对IDS评估系统研究的先河，在他们开发的软件平台上可以实现自动化的攻击仿真。Debar等在IDS实验测试系统的研究中，指出在评估环境中仿真正常网络流量是一件非常复杂而且耗时的工作。林肯实验室在19、进行的两次IDS离线评估，是迄今为止最权威的IDS评估。在精心设计的测试网络中，他们对正常网络流量进行了仿真，实施了大量的攻击，将记录下的流量系统日志和主机上文件系统映像等数据，交由参加评估的IDS进行离线分析。最后根据各IDS提交的检测结果做出评估报告。目前美国空军罗马实验室对IDS进行了实时评估。罗马实验室的实时评估是林肯实验室离线评估的补充，它主要对作为现行网络中的一部分的完整系统进行测试，其目的是测试IDS在现有正常机器和网络活动中检测入侵行为的能力以及IDS的响应能力及其对正常用户的影响。IBM的Zurich研究实验室也开发了一套IDS测评工具。此外，有些 工具软件也可用来对IDS进行评测。
目前，市场上以及正在研发的IDS很多，各系统都有自己独特的检测方法。攻击描述方式以及攻击知识库，还没有一个统一的标准。这大大加大了测试评估IDS的难度，因为很难建立一个统一的基准，也很难建立统一的测试方法。
测试评估IDS中存在的最大问题是只能测试已知的攻击。在测试评估过程中，采用模拟的方法来生成测试数据，而模拟入侵者实施攻击面临的困难是只能掌握已公布的攻击，而对于新的攻击方法就无法得知。这样的后果是，即使测试没有发现IDS的潜在弱点，也不能说明IDS是一个完备的系统。不过，可以通过分类选取测试例子，使之尽量覆盖许多不同种类的攻击，同时不断更新入侵知识库，以适应新的情况。
并且，由于测试评估IDS的数据都是公开的，如果针对测试数据设计待测试IDS，则该IDS的测试结果肯定比较好，但这并不能说明它实际运行的状况就好。
此外，对评测结果的分析使用也有很多问题。理想状况是可以自动地对评测结果进行分析，但实际上很难做到这一点。对IDS的实际评估通常既包含客观的也包含主观的，这和IDS的原始检测能力以及它报告的方式有关。分析人员要在IDS误报时分析为什么会出现这种误报，在给定的测试网络条件下，这种误报是否合理等问题。评测结果的计分方式也很关键，如果计分不合理的话，得出的评测结果可信度也就不可能很高。比如，如果某个IDS检测不出某种攻击或对某种正常行为会产生虚警，则同样的行为都产生同样的结果，正确的处理方法是应该只计一次，但这很难把握，一旦这种效果被多次重复考虑的话，该IDS的评测结果肯定不是很理想，但实际上该人侵检测总体检测效果可能很好。
8、小结
入侵检测作为一门正在蓬勃发展的技术，出现的时间并不是很长；相应地对IDS进行评测出现得更晚。它肯定有很多不完善和有待改进的地方，这需要进一步的研究。其中几个比较关键的问题是：网络流量仿真、用户行为仿真、攻击特征库的构建、评估环境的实现以及评测结果的分析。
近几年来，我国的入侵检测方面的研究工作和产品开发也有了很大的发展。但对入侵检测评估测试方面的工作还不是很多。各入侵检测产品厂家基于各方面的原因，在宣传时常常夸大其词，而IDS的用户对此往往又不是很清楚，所以迫切需要建立起一个可信的测试评估标准。这对开发者和用户都有好处。
篇3：六步评估ips/ids入侵检测
对国内众多企业用户来说，两年来入侵检测与防护（ids/ips）设备已经脱离了原有的奢侈形象，成为了企业不可或缺的标准配置，为此，本报特别整理了企业的网管人员、it 经理及信息主管在选购此类设备时的评估标准，以飨读者。
环境决定部署
企业部署防火墙之后，是否还需要进一步提升安全防护能力呢？答案是肯定的。虽然，防火墙称得上是安全防护的防线，同时部署防火墙也是对依靠互联网扩展业务的企业的基本要求。但是，仅有一道防线的城池仍非固若金汤。
当前的应用系统发展与web更加紧密，从办公系统到交易系统，这种趋势日益明显。在这样的背景下，大多数传统的防火墙对于企业网络的安全，已经无法实施100%的控制，对于合法内容中混入的可疑流量、dos攻击、蠕虫病毒、间谍软件等威胁，几乎没有有效的反击措施。
据了解，在，仅拒绝服务（dos）攻击导致的平均损失就高达150万美元，同 年相比增长了五倍。
从全球的统计数字来看，垃圾邮件、邮件病毒、邮件攻击已经成为了当前企业网的主要威胁，同时其影响力还在不断扩大。特别是夹杂在“合法”邮件中的非法信息，令企业网络处于危险的潜在威胁之中。
例如将木马病毒隐藏在看似合法的smtp邮件中，并随时准备对企业关键信息发起攻击，已经成为近期的主流。因此，各大企业都在利用入侵检测与防护系统为网络建构多层防护体系，其中juniper idp、radware defensepro、mcafee intrushield都是国内应用较多的产品。
六项准则
入侵检测与防护系统能够保护企业免受重大安全威胁和经济损失，进而保护企业的生存。但企业在选择和部署网络安全解决方案时，也要考虑成本效益的因素，因此找出利弊的平衡点尤为重要。
为有效评估入侵检测与防护系统，可以将评估标准划分为六个方面。
1.全面保护
对于任何安全系统而言，入侵检测与防护系统提供的全面保护应该能够准确识别威胁并有效保证网络的安全。但是，许多产品在这方面先天不足络邮件传输存在固有的复杂性，包括支持大量网络层协议(如ip、tcp、udp、icmp等) 和应用层协议(如http、ftp、smtp、dns、pop3、imap等)，这些都为攻击者提供了无数可供利用的漏洞。
juniper的工程师认为，除了这种固有的复杂性外，攻击者还可以采取不同的形式和手段，并可随意选择攻击时间进行攻击。如果系统不支持其中的一种协议或攻击类型，就会忽略并遗漏这种攻击，从而使企业网络及其重要信息处于失去保护的状态。为了对付攻击者，安全设备必须能够处理并有效防护所有类型邮件中潜在的攻击。
2. 准确性
准确性是高品质、高效率入侵检测与防护系统的关键。要实现高度的准确性，系统必须能够跟踪所有网络通信、理解每个通信的意图，然后针对攻击企图准确地做出安全决策。如果系统准确性不够，就可能检测不到攻击，而合法邮件也可能因被视为攻击行为而发出告警。
国内主要
关 键 字：入侵检测
篇4：网络入侵检测系统实现
互联网也同时带给我们无数的宝贵资源，只等我们去开发、利用，开放源代码软件(Open Source Software)便是其中之一，免费可得的软件发布形式，使其具有广大的用户群;众多志愿者的协同开发模式使其具有卓越的兼容性;大量的网上社区弥补了缺少商业服务的不足。本文试图论述利
用互联网上免费可得的开放源代码软件实现一个完整的网络入侵检测系统的过程。
系统概述
本系统采用三层分布式体系结构：网络入侵探测器、入侵事件数据库和基于Web的分析控制台。为了避免不必要的网络流量，本例将网络入侵探测器和入侵事件数据库整合在一台主机中，用标准浏览器异地访问主机上的Web服务器作为分析控制台，两者之间的通信采用HTTPS安全加密协议传输。
由于实现本系统所需的软件较多，有必要在此进行简要的说明：
Snort
功能简述：网络入侵探测器;
正式网址：www.snort.org/
软件版本：1.8.6
Libpcap
功能简述：Snort所依赖的网络抓包库;
正式网址：www.tcpdump.org/
软件版本：0.7.1
MySQL
功能简述：入侵事件数据库;
正式网址：www.mysql.org/
软件版本：3.23.49
Apache
功能简述：Web服务器;
正式网址：www.apache.org/
软件版本：1.3.24
Mod_ssl
功能简述：为Apache提供SSL加密功能的模块;
正式网址：www.modssl.org/
软件版本：2.8.8
OpenSSL
功能简述：开放源代码的SSL加密库，为mod_ssl所依赖;
正式网址：www.openssl.org/
软件版本：0.9.6d
MM
功能简述：为Apache的模块提供共享内存服务;
正式网址：www.engelschall.com/sw/mm/
软件版本：1.1.3
PHP
功能简述：ACID的实现语言;
正式网址：www.php.net/
软件版本：4.0.6
GD
功能简述：被PHP用来即时生成PNG和JPG图像的库;
正式网址：www.boutell.com/gd/
软件版本：1.8.4
ACID
功能简述：基于Web的入侵事件数据库分析控制台;
正式网址：www.cert.org/kb/aircert/
软件版本：0.9.6b21
ADODB
功能简述：为ACID提供便捷的数据库接口;
正式网址：php.weblogs.com/ADODB
软件版本：2.00
PHPlot
功能简述：ACID所依赖的制图库;
正式网址：www.phplot.com/
软件版本：4.4.6
上述软件都是开源软件，可以直接登录相应软件的正式网站，下载源代码，
此外，需要特别说明的一点是虽然本例中网络入侵检测系统所采用的系统平台是Solaris 8 for Intel Platform，但是在其它种类的系统平台上，如Linux 、OpenBSD以及Windows 等，其具体的实现步骤大同小异，因此就不在另行说明了。
三、安装及配置
在正式进行软件安装之前，请检查系统，确保拥有符合ANSI标准的C/C++编译器等软件开发工具。
1、安装MySQL
首先，以超级用户的身份登录系统，创建mysql 用户和mysql用户组;
然后，以mysql身份登录，执行下列命令：
$gzip -d -c mysql-3.23.49.tar.gz | tar xvf -
$cd mysql-3.23.49
$./configure
$make
$make install
这样，就按照缺省配置将MySQL安装在/usr/local目录下。然后将源代码树中的缺省配置文件my.cnf拷贝到/etc目录下。接下来，以超级用户身份执行源码树中scripts目录下的可执行脚本文件mysql_install_db来创建初始数据库。用/etc/init.d/mysql.server命令启动数据库服务器后，使用/usr/local/bin/mysqladmin程序来改变数据库管理员的口令。
[1] [2] 下一页
篇5：建新手入门入侵检测系统
根据CIDF规范，我们从功能上将入侵检测系统划分为四个基本部分：数据采集子系统、数据分析子系统、控制台子系统、数据库管理子系统，
具体实现起来，一般都将数据采集子系统(又称探测器)和数据分析子系统在Linux或Unix平台上实现，我们称之为数据采集分析中心;将控制台子系统在Windows NT或2000上实现，数据库管理子系统基于Access或其他功能更强大的数据库，多跟控制台子系统结合在一起，我们称之为控制管理中心。本文以Linux和Windows NT平台为例介绍数据采集分析中心和控制管理中心的实现。
第一步 获取Libpcap和Tcpdump
审计踪迹是IDS的数据来源，而数据采集机制是实现IDS的基础，否则，巧妇难为无米之炊，入侵检测就无从谈起。数据采集子系统位于IDS的最底层，其主要目的是从网络环境中获取事件，并向其他部分提供事件。目前比较流行的做法是：使用Libpcap和Tcpdump，将网卡置于“混杂”模式，捕获某个网段上所有的数据流。
Libpcap是Unix或Linux从内核捕获网络数据包的必备工具，它是独立于系统的API接口，为底层网络监控提供了一个可移植的框架，可用于网络统计收集、安全监控、网络调试等应用。
Tcpdump是用于网络监控的工具，可能是Unix上最著名的Sniffer了，它的实现基于Libpcap接口，通过应用布尔表达式打印数据包首部，具体执行过滤转换、包获取和包显示等功能。Tcpdump可以帮助我们描述系统的正常行为，并最终识别出那些不正常的行为，当然，它只是有益于收集关于某网段上的数据流(网络流类型、连接等)信息，至于分析网络活动是否正常，那是程序员和管理员所要做的工作。Libpcap和Tcpdump在网上广为流传，开发者可以到相关网站下载。
第二步 构建并配置探测器，实现数据采集功能
1. 应根据自己网络的具体情况，选用合适的软件及硬件设备，如果你的网络数据流量很小，用一般的PC机安装Linux即可，如果所监控的网络流量非常大，则需要用一台性能较高的机器。
2. 在Linux服务器上开出一个日志分区，用于采集数据的存储。
3. 创建Libpcap库。从网上下载的通常都是Libpcap.tar.z的压缩包，所以，应先将其解压缩、解包，然后执行配置脚本，创建适合于自己系统环境的Makefile，再用Make命令创建Libpcap库。Libpcap安装完毕之后，将生成一个Libpcap库、三个include文件和一个Man页面(即用户手册)。
4. 创建Tcpdump。与创建Libpcap的过程一样，先将压缩包解压缩、解包到与Libpcap相同的父目录下，然后配置、安装Tcpdump。
如果配置、创建、安装等操作一切正常的话，到这里，系统已经能够收集到网络数据流了。至于如何使用Libpcap和Tcpdump，还需要参考相关的用户手册。
第三步 建立数据分析模块
网上有一些开放源代码的数据分析软件包，这给我们构建数据分析模块提供了一定的便利条件，但这些“免费的午餐”一般都有很大的局限性，要开发一个真正功能强大、实用的IDS，通常都需要开发者自己动手动脑设计数据分析模块，而这往往也是整个IDS的工作重点。
数据分析模块相当于IDS的大脑，它必须具备高度的“智慧”和“判断能力”。所以，在设计此模块之前，开发者需要对各种网络协议、系统漏洞、攻击手法、可疑行为等有一个很清晰、深入的研究，然后制订相应的安全规则库和安全策略，再分别建立滥用检测模型和异常检测模型，让机器模拟自己的分析过程，识别确知特征的攻击和异常行为，最后将分析结果形成报警消息，发送给控制管理中心，
设计数据分析模块的工作量浩大，并且，考虑到“道高一尺，魔高一丈”的 手法日益翻新，所以，这注定是一个没有终点的过程，需要不断地更新、升级、完善。在这里需要特别注意三个问题：
① 应优化检测模型和算法的设计，确保系统的执行效率;
② 安全规则的制订要充分考虑包容性和可扩展性，以提高系统的伸缩性;
③ 报警消息要遵循特定的标准格式，增强其共享与互操作能力，切忌随意制订消息格式的不规范做法。
第四步 构建控制台子系统
控制台子系统负责向网络管理员汇报各种网络违规行为，并由管理员对一些恶意行为采取行动(如阻断、跟踪等)。由于Linux或Unix平台在支持界面操作方面远不如常用的Windows产品流行，所以，为了把IDS做成一个通用、易用的系统，笔者建议将控制台子系统在Windows系列平台上实现。
控制台子系统的主要任务有两个：
① 管理数据采集分析中心，以友好、便于查询的方式显示数据采集分析中心发送过来的警报消息;
② 根据安全策略进行一系列的响应动作，以阻止非法行为，确保网络的安全。
控制台子系统的设计重点是：警报信息查询、探测器管理、规则管理及用户管理。
1.警报信息查询：网络管理员可以使用单一条件或复合条件进行查询，当警报信息数量庞大、来源广泛的时候，系统需要对警报信息按照危险等级进行分类，从而突出显示网络管理员需要的最重要信息。
2.探测器管理：控制台可以一次管理多个探测器(包括启动、停止、配置、查看运行状态等)，查询各个网段的安全状况，针对不同情况制订相应的安全规则。
3.规则库管理功能：为用户提供一个根据不同网段具体情况灵活配置安全策略的工具，如一次定制可应用于多个探测器、默认安全规则等。
4.用户管理：对用户权限进行严格的定义，提供口令修改、添加用户、删除用户、用户权限配置等功能，有效保护系统使用的安全性。
第五步 构建数据库管理子系统
一个好的入侵检测系统不仅仅应当为管理员提供实时、丰富的警报信息，还应详细地记录现场数据，以便于日后需要取证时重建某些网络事件。
数据库管理子系统的前端程序通常与控制台子系统集成在一起，用Access或其他数据库存储警报信息和其他数据。该模块的数据来源有两个：
① 数据分析子系统发来的报警信息及其他重要信息;
② 管理员经过条件查询后对查询结果处理所得的数据，如生成的本地文件、格式报表等。
第六步 联调，一个基本的IDS搭建完毕
以上几步完成之后，一个IDS的最基本框架已被实现。但要使这个IDS顺利地运转起来，还需要保持各个部分之间安全、顺畅地通信和交互，这就是联调工作所要解决的问题。
首先，要实现数据采集分析中心和控制管理中心之间的通信，二者之间是双向的通信。控制管理中心显示、整理数据采集分析中心发送过来的分析结果及其他信息，数据采集分析中心接收控制管理中心发来的配置、管理等命令。注意确保这二者之间通信的安全性，最好对通信数据流进行加密操作，以防止被 或篡改。同时，控制管理中心的控制台子系统和数据库子系统之间也有大量的交互操作，如警报信息查询、网络事件重建等。
联调通过之后，一个基本的IDS就搭建完毕。后面要做的就是不断完善各部分功能，尤其是提高系统的检测能力。
篇6：SNORT入侵检测系统2
10.安装 Snort2.4.4 10.1建立snort配置文件和日志目录 #mkdir /etc/snort #mkdir /var/log/snort #tar -zxvf snort-2.4.4.tar.gz #cd snort-2.4.4 #./configure --with-mysql=/usr/local/mysql
10.安装 Snort2.4.410.1建立snort配置文件和日志目录
#mkdir /etc/snort
#mkdir /var/log/snort
#tar -zxvf snort-2.4.4.tar.gz
#cd snort-2.4.4
#./configure --with-mysql=/usr/local/mysql
#make
#make install
注意，我在编译snort时出现“ERROR! Libpcre header not found, go get it from”的错误，这是因为少安装了一个lib的库，如果谁出现了这样的问题，就到ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/ 下载最新的pcre库进行安装。
方法： #tar -zxvf pcre-6.7.tar.gz
#./configure
#make
#make check
#make install
10.2安装规则和配置文件
#cd /etc/snort/
#tar ?zxvf /ruanjian/snortrules-snapshot-2.4.tar.gz
#cd /etc/snort/rules (在snort安装目录下)
#cp *.conf /etc/snort/.
#cp *.config /etc/snort/.
#cp *.map /etc/snort/.
10.3修改snort.conf (/etc/snort/snort.conf)
var HOME_NET 172.17.4.0/24 (修改为你的内部网网络地址)
var RULE_PATH ./rules 修改为 var RULE_PATH /etc/snort/
改变记录日志数据库:
log与alert数据库要分别建，否则snort启动当有事件发生时候要出错
output database: log, mysql, user=root password=your_password dbname=snort host=localhost
output database: alert, mysql, user=root password=your_password dbname=snort host=localhost
安装DB表:(在schemas 目录)
/usr/local/mysql/bin/mysql -u root -p 11.安装配置Web接口 安装JPGraph2.1.1 #cp jpgraph-2.1.1.tar.gz /home #cd /home #tar -xzvf jpgraph-2.1.1.tar.gz #mv jpgraph-2.1.1 jpgraph 安装ADODB: #cp adodb480.gz /home #cd /home #tar -xzvf adodb480.gz 安装配置Acid: #cp acid-0.9.6b23.tar.gz /home #cd /home #tar -xvzf acid-0.9.6b23.tar.gz #cd /home/acid/ 编辑acid_conf.php,修改相关配置如下: $DBlib_path = “/home/adodb”; $DBtype = “mysql”; $alert_dbname = “snort”; $alert_host = “localhost”; $alert_port = “”; $alert_user = “root”; $alert_password = “xiangqian”; $archive_dbname = “snort”; $archive_host = “localhost”; $archive_port = “”; $archive_user = “root”; $archive_password = “xiangqian”; $ChartLib_path = “/home/jpgraph/src”; 运行snort把数据写入mysql # snort -c /etc/snort/snort.conf 进入web界面: yourhost/acid/acid_main.php 点“Setup Page”链接 ->Create Acid AG 访问yourhost/acid将会看到ACID界面，
篇7：杂谈入侵检测防御系统
几乎所有当前市场上的网络入侵检测系统都是基于一种被动数据收集方式的协议分析，我们可以预见，这种方式在本质上是有缺陷的，
毫无疑问，这样的入侵检测系统会监视整个网络环境中的数据流量，并且总是与一种预定义的可疑行为模式来进行对照，甚至所谓的入侵行为分析技术也只是简单地从单位时间状态事件技术上做了些组合工作，事实上离真正实用的复杂 入侵行为的剖析和理解还有很远的距离。
对于这种检测技术的可靠性，我们可以通过自定义的三种可行性很强的攻击方式来验证――插入攻击、逃避攻击和拒绝服务攻击。我们可以看到，当一个入侵者实施了这样的入侵策略以后，所谓的入侵检测系统便妥协了。我们的结论是这种入侵检测系统不是放之四海而皆准的，除非它们从根本上被重新设计过。
真正实用的入侵检测系统的存在价值就是能够察觉 的入侵行为并且进行记录和处理，当然，人们也会根据自己的需求提出需要强大的日志记录策略、入侵诱导等等。
不同的入侵检测系统存在不同的入侵分析特征。一个企图检测Web入侵的系统可能只会考虑那些常见的恶意HTTP协议请求；同样道理，一个监视动态路由协议的系统可能只会考虑网络是否存在RIP欺骗攻击等等。目前国内市场上的大部分入侵检测系统使用同一个入侵行为定义库，如著名的SNORT特征库，这说明我们在技术挖掘方面的投入还不够，事实上我国在基础研究设施的投入上也存在严重不足。
入侵检测系统现在已经成为重要的安全组件，它有效地补充和完善了其他安全技术和手段，如近乎快过时的基于协议和端口的防火墙。入侵检测系统为管理人员提供相应的警告信息、报告可能发生的潜在攻击，从而抵挡了大部分“只是对系统设计好奇”的普通入侵者。
世界上已经开发出了很多种入侵检测系统，我们可以用通用的入侵检测体系结构（CIDF:Common Intrusion Detection Framework）来定义常见的入侵检测系统的功能组件。这些功能组件通常包括事件产生器、分析引擎、存储机制、攻击事件对策。
许多入侵检测系统在设计之时就仅仅被考虑作为警报器。好在多数商业化的入侵检测系统配置了可用的防御性反攻击模块，起码可以切断TCP连接或动态地更改互动防火墙过滤规则。这样就可以阻止 沿着同一路径继续他的攻击行为。一些入侵检测系统还配置了很好的攻击诱骗模块，可以为系统提供进一步的防护，也为进一步深入研究 行为提供了依据。
对于比较普遍的两种入侵检测模式--基于网络的入侵检测和基于主机的入侵检测，我们可以这样考虑：基于主机的入侵检测系统对于特定主机给予了定制性的保护，对于发生在本地的、用户级的、特征性比较明显的入侵行为有防范作用。但是，这种模式对于发生在网络传输层的入侵通常是无可奈何的，想让应用级特征比较强的系统同时把系统级和网络底层技术实现得比较完善是不太现实的。虽然我们可以看到在伟大的Linux系统上实现了Lids，毕竟象Solaris，NT这样的系统，我们能够了解的只是皮毛。
基于网络的入侵检测系统需要监视整个网络的流量，匹配可疑行为特征。它的技术实现通常必须从网络和系统的底层入手，而且它同时保护的是网络上的一批主机，无论它们使用的什么系统。基于网络的入侵检测系统显然不会关心某一台主机之上正在进行着什么操作，只要这些操作数据不会扩散到网络上来。因为网络入侵检测系统是以行为模式匹配为基础的，我们可以断定它有匹配失误的可能，有因为不能确定某种行为是入侵而将其放行的可能。那么当一个“聪明”的入侵者骗过了这种系统，顺利地进入一台主机，该系统的厄运开始了。
被动的网络监视器通常利用网络的混杂模式工作，它们直接从网络媒介获得网络中数据包的拷贝，而不考虑这些包本来是不应该被它们接收的。当然，这种被动的网络底层协议分析总是“安静地”存在于网络的某个地方，它只是根据网络媒介提供的这种特征，在其他主机不知不觉的时候将网络数据拷贝一份。同时，需要考虑到，根据引擎端实现平台的不同，各平台实现的网络数据包捕获机制的不同，在混杂模式下丢包的程度是不同的。事实上，对于大多数还需要从内核读取数据的应用级包过滤系统，只能考虑以更快的方式把数据读取到用户空间，进而发送给其它进程。 这样处理的化，要求从技术上增加用户空间的缓冲区尺寸，如在BSD(BPF)的系统上，能够利用BIOCSBLEN ioctl调用来增加缓冲区尺寸。
入侵检测系统地最重要的特征莫过于其检测的“精确性”。因此IDS要对捕获到的数据包进行详细的分析，所以对IDS的攻击就是针对IDS在分析数据时的弱点和漏洞。
网络IDS捕获到网络上传输的数据包并进行分析，以便知道一个对象对另一个对象做了什么。IDS总是通过网络上交换的数据包来对终端系统上发生的信息行为进行判断。假设一个带有错误UDP校验和的IP数据包，大多数操作系统会丢弃这样的数据。某些比较陈旧的系统也可能会接受。IDS需要了解每一个终端系统的具体情况，否则IDS按照自己的方式构造出来的逻辑在终端系统上的应用会有不同。某些操作系统有可能会接受一个明显存在问题的数据包，如允许一个有错误的校验和的IP包。当然，IDS如果不进行分辨，必然会丢掉这些本来终端系统会接受的数据。
就算IDS系统知道网络都有些什么操作系统，它也没有办法通过查看一个包而知道是否一个终端系统会接受这个包。原因很简单，CPU耗尽、内存不足都可能导致系统发生丢包现象。
IDS全部的信息来源就是它捕获到的数据包。但是，IDS应该多了解一些关于终端系统的网络行为，应该了解终端系统如何处理各种网络数据。但是，实际上，这是不可能的。
在处理所谓的拒绝服务攻击时，存在两种常见的情况：某些IDS系统在自己处于停机状态时，可以保持网络正常的信息流通，这种属于“fail-open”型；另一种则是“fail-closed”型，即当IDS系统出现问题时，整个网络也随之瘫痪了。
网络检测系统是被动的。它们不控制网络本身，也不会以任何方式维护网络的连接。如果一个IDS系统是fail-open的，入侵者通过各种手段使IDS资源不可用了，那时IDS就没有任何防范入侵的作用了。正是因为这样，IDS系统加强自身抗拒绝服务攻击的能力显得极为重要。
当然，许多攻击方式讨论的都是针对基于嗅探模式的IDS系统。这些类型的攻击都企图阻止协议分析，阻止特征模式匹配，阻止IDS获得足够信息以得出结论。
针对入侵检测系统弱点的攻击探讨
有时IDS系统会接受终端系统丢弃了的数据包。因为IDS认为终端系统接受并且处理了这些数据，而事实上终端系统由于种种原因丢弃了这些数据包。一个入侵者就可以利用这一点，制造那种他所想要入侵的主机会丢弃而IDS系统将接受并作出判断的数据包，以使IDS与终端系统得到不同的结论。
我们可以把这种攻击称为“插入式”攻击。道理很简单，假设一个入侵者发往终端系统的数据是attack，但是，他通过精心构造在数据流中加入了一个多余的t。对于终端系统而言，这个t是被丢掉不被处理的；而对于IDS系统而言，它得到的最终上下文关系是atttack，这个结论使IDS认为这次行为并没有对终端系统形成攻击而不作处理，事实上，终端系统已经接受了attack数据。
现在让我们来分析一下这种方式的攻击如何阻止特征分析。特征分析通常的方式是根据固定模式判断某个特定的字串是否被存在于一个数据流中，例如，对待一个phf的HTTP攻击，IDS通常检查这个字串的存在与否，“GET /cgi-bin/phf?”, IDS系统判断这种情况很容易，只需要简单的子串搜索功能便可以做到，然而，但是，如果一个入侵者通过插入式攻击的思想在这次HTTP请求中增加了这样的内容，GET /cgi-bin/pleasedontdetectthisforme?,里面同样包含了phf,但是在IDS看来，味道已经不一样了。
插入式攻击的的结果就是IDS系统与终端系统重组数据后得到了不一样的内容。通常，插入式攻击在IDS没有终端系统处理数据那么严格的时候都存在。可能好的解决方法就是让IDS系统在处理网络中需要重组的数据的时候，作出严格的判断和处理，尽可能地与终端系统处理地效果一个样。可是，引来了另外一个问题，这便是另一种攻击方式，相对地叫做“逃避式“攻击模式。
相对的，有些数据包是IDS不会接受的，而终端系统却会对这些数据作出处理。当然，IDS由于不接受某些包，而会导致与这些数据相关的上下文关系无法了解。
问题的现象是因为IDS在对数据包进行审核处理的时候过于严格，使得往往某些数据在终端系统而言，是要进行接受重组处理的，而在IDS本身，仅仅是不作处理，导致许多攻击在这种严格的分析引擎的鼻子地下躲过。
逃避式攻击和插入式攻击都有效地愚弄了模式匹配引擎系统。结果都是入侵者使得IDS与终端系统接受处理了不同的数据流，在逃避式攻击中，终端系统比IDS接受了更多的内容而遭受攻击。
还是上面的phf的例子，入侵者发送了一个HTTP请求，使得原本的GET /cgi-bin/phf？在IDS处理的结论中变成了GET /gin/f，当然，这个结论对于大多数IDS系统来说，几乎没有任何意义。
从技术上来看, 插入式和逃避式这两种对付检测系统的方式也不是这容易就被入侵者所利用，因为实现这种攻击要求入侵具备相当的知识面和实践能力。
现在的许多网络协议是简单的并且容易分析的。比如一个普通的网络分析器就能够容易的判断一个UDP DNS请求的目的。
其它的一些协议则复杂的多，在得出实际传输的内容之前，需要对许多单个的数据包进行考虑。这样的话，网络监视器必须总是监视内容的数据流，跟踪包含在数据流中的信息。例如，为了解析出一个TCP连接中发生了什么，必须重组这次连接中的整个数据流。
象TCP这样的协议，允许在IP最大包尺寸范围内的任意大小的数据被包含于每一个分散的数据包中，数据可以无序地到达目的地，每个数据包都具有一个序列号来表明自己在数据流中的位置。TCP数据流的接受者有责任重新按照序列号进行数据包的重新排序和组合，并解析出数据发送者的意思。这有一套TCP的数据重组机制来完成。
在IP层，IP也定义了一种自己的机制，叫做“碎片“，这种机制允许主机把一个数据包切分为更小的数据分片。每一个片都有一个标记，标记自己原来属于原始数据包的什么相对位置，叫做”偏移值“。IP实现允许接受这样的IP碎片包，并且根据偏移值来重组原始数据包。
插入式攻击通过增加一些数据包到数据流中导致终端系统重组很困难。 入的数据包能够改变数据流的先后顺序，进而阻止IDS正确地处理紧跟着的正确的数据包。包的插入重叠了老的数据，在IDS系统上重写了数据流。某些情况下，插入数据包，改变了数据流原来的意思。
逃避式攻击则是导致IDS系统在进行流重组的时候错过了其中的部分关键内容，被IDS忽略的数据包可能对于数据流的顺序来说是至关重要的；IDS系统可能在逃避式攻击之后不知道该如何对这些数据下结论了。许多情况下，入侵者产生整个躲避IDS系统检测的数据流是相对简单的。
插入式和逃避式IDS攻击都不是很容易防范的，除非IDS通过了第二信息源的配合，能够对当前监视的网络拓扑结构以及对作为被监视对象的终端系统所能够接收什么样的数据包进行跟踪分析，否则问题依然存在，这是目前必须要提出来的对被检测网络的诠释技术，尽可能通过配合第二信息源的方式，让IDS对它所检测的网络中的终端系统以及网络实际环境有一个成熟的了解.
如果一个攻击能够造成实现插入任意的IP数据包，那么，插入一个UDP或者ICMP也是没有问题的。所以可以看出IDS系统在IP层实现对这两种入侵手段的免疫将是很重要的。
一个最容易的让终端系统丢弃IP数据包的方式是让数据包具有不正确的IP头部信息。如RFC731定义。入侵者所使用的这些头部信息有问题的数据包在现实中可能会遇到问题，除非攻击对象IDS系统处在同一个局域网之内，例如如果version域不是4，而是其他的值，这种数据包实际上是不会被路由的。当然，对于其他的一些域值，比如IP包长度或者IP头长度，一个不规范的长度将阻止IDS系统正确定位IP中的传输层的位置等。
在IP头域信息中，最容易被忽略的是校验值。似乎对于一个IDS系统去校验每一个捕获的IP数据包的校验是没有必要的。然而，一个带有病态的校验值的数据报对于大多数IP实现来说都是不会被处理的。一个IDS系统在设计的时候考虑到有问题的校验了么？如果没有考虑到校验的必要性，那么很难避免“插入式“攻击。
TTL域表示了一个数据包在到达目的系统的过程中需要经过多少路由器。每一次，一个路由器转发一个数据包，数据包所带的TTL信息将会被消耗。TTL消耗尽时，包也被丢弃了。所以，入侵者可以构建一个TTL的值，使得发送的数据包刚好可以到达IDS系统，但是TTL刚好耗尽了，数据本来应该到达的目标却没有到。
相类似的另一个问题与IP头部的DF标志有关。DF标志置位使得转发设备即便是在包超出标准大小尺寸的时候也不要对数据进行IP分片，紧紧通知简单的丢弃掉这些包。
这两个不明确的问题的解决要求IDS系统能够了解它所监视的网络拓扑结构。
IP校验和问题很好解决；一个IDS系统可以假设如果校验和是错误的，那么数据包将会被目标系统所不接受。而IP的选项域的存在又导致一些不同的可能性。
许多操作系统可以配置为自动拒绝源路由数据包。除非IDS了解是否一个源路由数据包的目标主机拒绝这样的数据包，否则不可能正确处理这样情况。
对IP数据包中的源路由项进行检查或许是一个明显的必要。然而，其他的一些选项也是必须应该考虑的。例如，“timestamp“选项要求特定的数据包的接受者在数据包里放置一个时间戳标记。如果这个选项出现问题，处理事件戳选项的代码将强迫丢弃这个包。如果IDS没有如同终端系统那样核实时间戳选项的话，便存在问题。
同一个LAN上的入侵者能够指引链路层的数据帧到IDS系统，不必允许作为IP目标的主机看到这个包。如果一个入侵者知道了IDS的MAC地址，他便能将他的欺骗包发往IDS系统，LAN上的其他系统不会处理这个数据包，但是，如果IDS不检查接受到的数据包的MAC地址，它是不会知道发生了什么情况的。
逃避式攻击则是导致IDS系统在进行流重组的时候错过了其中的部分关键内容，被IDS忽略的数据包可能对于数据流的顺序来说是至关重要的；IDS系统可能在逃避式攻击之后不知道该如何对这些数据下结论了。许多情况下，入侵者产生整个躲避IDS系统检测的数据流是相对简单的。
因为终端系统将重组IP碎片，所以IDS系统能够进行IP碎片重组也是重要的。一个不能正确的重组碎片的IDS系统将是容易受到攻击的，入侵者仅仅通过人工生产碎片的攻击方式便可以愚弄IDS。IP碎片的数据流通常有序到达。但是，协议允许碎片以任何次序到达。一个终端系统必须能够重组无序到达的数据包分片。
一个IDS系统如果不能处理IP碎片无序到达这种情况的话，也是存在问题的；一个入侵者能够故意捣乱他的碎片来逃避IDS检测。而且IDS必须在全部的碎片都被接收到以后才进行碎片重组。当然了，接收到的分片必须被存储下来，直到分片流可以被重组为一个完整的IP数据包。如果一个入侵者利用分片的形式来对网络进行flooding攻击，那么IDS系统通常会资源耗尽。每个终端系统也必须处理这个问题。许多系统根据TTL来丢弃分片，而避免这种由于大量碎片请求造成的内存不足。
许多入侵者能够刻意地通过构造病态的IP分片躲避传统的包过滤器，他们使用的是尽可能小的分片包，因为单个的分片所包含的数据不足以达到过滤规则对应的匹配长度。
另外，出现的问题是重叠的分片处理问题，可能性是这样的，具有不同尺寸的分片先后到达系统，并且分片的数据位置处于重叠状态，既是说，如果一个分片迟于另外一个分片达到系统，两个分片对于重组参数来说是同一个，这时新到的数据可能会覆盖掉已经先到达的老的一些数据。
这便又提出了一个问题，如果一个IDS系统没有能够以它所监视和保护的终端系统处理分片的方式处理分片包的话，可能面对同一个数据分片流，IDS系统将重组出与终端系统得到的玩全不同的数据包。一个了解这种IDS与终端系统之间矛盾的入侵者可能会采用这种入侵方式。
对于重叠分片的取舍是更加复杂的，对于这些有冲突的分片数据是否被采纳往往取决于他们所在的位置，而根据不同的操作系统对IP碎片重叠情况的不同处理也不一样。有些情况，新的数据被承认而有的时候则是旧的数据被承认，系统选择丢弃新的数据。当然，IDS不能正确分析这种情况，将面临“逃脱式”攻击。
就此问题而言，终端系统的IP驱动程序同样会有问题。或许正是因为IP碎片重组的困难和复杂性才使得出现了那么多不正确的处理方式。所以，除非一个IDS系统准确的知道它所监视的系统都是以何种方式来实现IP驱动的，否则要想精确地重组得到每一个终端系统都接受的数据是不可能的，
例如：Windows NT在处理重叠分片时，总是保留最先到达系统并且被接受的数据包。这与BSD4.4刚好相反。
IP包的选项域是应该被考虑到的。当一个IP包被分片时，来自于原始数据包的选项域信息是否应该被携带到全部的分片中去。RFC791声明某些IP选项如（security）将出现在每一个分片里，而其他的一些必须只出现在第一个分片中。
对于严格的IP实现将丢弃那些具有不正确选项的分片。但是事实上许多系统不是这样处理的。如果IDS没能象终端系统那样精确的处理这种情况的话，将也会面临前面提到的两类攻击。
在面向连接的协议中，象TCP这样的连接协议使用了序列号机制，这种机制提供了一种确认方法。可是，对于无连接协议，这种相对严格的确认机制却是没有的；可以看到，一个入侵DNS的破坏者其实可以是来自任何地方，因为就目前的Ipv4协议，可以简单就伪造出源通讯地址。看来，IDS系统的管理者对于IDS系统给出的网络地址的准确性是应该仔细考虑的。
事实上，被IDS检测到的大部分攻击是通过TCP连接的。所以，IDS对TCP会话数据流的重组能力成为关键问题。但是，到目前为止，我们可以肯定，IDS的这种数据重组能力应该与终端系统重组数据包的方式相一致。对于正常的TCP连接，就像一次由远程登录发起的连接，这很容易做到的。
IDS系统为了能够重建TCP连接会话的信息，TCP片段使用的序列号信息是必须知道的。我们可以把这种IDS去判断当前连接的可用序列号的过程叫“同步”。当然，在判断序列号时出现问题，可以叫“失去同步”。
当IDS系统在一次TCP连接中失去序列号同步了，就不能够对这次连接的信息数据进行有效的跟踪和重组了。在许多情况下，IDS系统由此不能够再接着处理这一次连接中的任何数据信息。所以，入侵者通常把让IDS系统“失去同步”作为一个主要攻击目标。
TCP标准定义了一个流控制机制，用来阻止建立连接的一方发送过多的数据到连接的另外一方；IDS追踪TCP连接的每一方的window域的值。TCP也允许数据流中发送所谓的OOB数据（带外数据），它利用了定义的紧急指针选项。
对于网络中的终端系统，与之相关的每次连接的状态信息的收集处理是没有问题的，每种TCP实现必须管理自己的TCB――TCP会话控制块，以便理解那一次建立的连接情况。一个网络IDS系统也必须能够维护它所监视的每一次连接对应的TCB。
任何网络IDS系统都定义了针对所探测到的新的TCP连接而产生TCB的机制，同时也对那些不再有关的连接进行释放和消除工作。
在讨论IDS的TCP问题中，我们独立地分析三个方面，可以看到，在IDS处理这三种情况时可能出现问题。首先是TCB产生，通过它，IDS决定对一个新探测到的TCP连接产生TCB；其次是数据流重组，IDS根据它所维护地TCB信息对数据流进行重组，当然这一步受到上一步地关联；再者是TCB拆卸，IDS通过它撤销一个TCB。
通过分析可以看到，“插入式”攻击的实现将影响到以上提到的几个方面，插入式攻击使得IDS系统分不清到底什么数据事实上到达了终端系统。比如在数据流重组上下文关系中，数据插入式攻击使得一次可靠的TCP会话监视几乎成为不可能的事；所以说IDS能够针对插入式攻击做处理是非常重要的也是很难实现的。
对于IP协议，可以有几种不同的方法可以实现往IDS系统中插入数据包，而对于TCP，问题会复杂一些，但是同样有一些手段能够导致IDS去主动丢弃某些特定的数据包，以达到入侵者的目的，无论如何，如果一个IDS系统不能够以它所监视的终端相同的方式来处理TCP包的话，对待”插入式“将受到威胁。
在一次TCP交互中，如果接收方对应回应了一个信息，那么一个TCP片段就是被认可的，我们进一步可能分析回应的是RST信息还是ACK信息。IDS能够通过对这些认可信息的辨识判断一个片段是否是存在问题的
包含在TCP包里面的数据能够被提取出来进行重组，而不去考虑TCP的头域的某些部分。
这种不严格的处理方式使得 “插入式“攻击手段得以成功，所以，在处理TCP数据的时候，先严格考虑TCP头域的信息可用性显得很重要了。
一个极易被忽略的头域是“CODE“，这个头域决定了TCP片段中发送的信息的类型。这个域是一系列二进制标志位。可以看到，某些标志位的组合是不正常的，通常在网络中导致包被丢弃掉。另外，许多TCP实现就不去接收没有ACK位被设置的TCP片段中的数据信息。
根据TCP的标准定义，TCP应该接受包含在SYN类型片段中的数据信息。而对这种定义的理解却变成了多种味道，导致一些TCP实现没有正确地处理这类信息。如果一个IDS系统没能考虑SYN数据，那么一个随便的“逃避式”攻击就可以对它进行威胁；反之，如果这个IDS系统能够很好地考虑SYN数据了，在针对某些没有正确实现这种定义的终端系统的时候，它显得当不住入侵者刻画的“插入式”攻击。
另外，经常被忽略的TCP输入处理问题是校验和，全部的TCP实现被强制性地要求验证网络校验，许多IDS系统不能做这种检查；所以通过构建有错误校验值的TCP片段就可以简单地插入数据包到IDS系统。
就像处理IP的选项域一样，IDS能够正确的处理TCP的选项域也是十分重要的。可是不幸的是，由于TCP的选项域某些内容被产生和利用的时间还比较短，如timestamp、windows scale这些选项；另外对于何时TCP的选项能够出现在连接的上下文中，TCP标准有专门的规定。某些选项在某些连接状态或许就是不可用或者是非法的。
RFC1323[13]中介绍了两个TCP的选项，这两个选项被设计来增加TCP在高速环境下的可靠性和性能。但是规定这些选项仅仅可以出现在非SYN的分段之中。
因为某些TCP实现会拒绝包含了这些没有见过的选项的非SYN片段，所以IDS也不可盲目的都接受这些有选项的数据包。另外，也有一些终端系统通过忽略这些选项，继续处理这些数据包；所以，可见IDS必须清楚地知道终端系统是如何处理各种数据包的，才能以相对于特定的终端系统正确的处理方式来进行处理而避免如插入和逃避式攻击。
RFC1323 定义了的另外一个叫做PAWS的概念，全称是“protection against wrapped sequence numbers”。使用PAWS的系统将会跟踪分段中的timestamps选项；根据分段中的timestamps响应值判断数据包是否被丢弃，一个入侵者可以很简单的产生一个人工的timestamp值，目的是使得支持PAWS的TCP堆栈不用作出进一步的处理就丢弃这个数据包。
IDS不仅仅需要知道是否终端系统支持PAWS，而且还需要知道终端系统对于timestamps的threshold的值是什么。如果没有这些信息，IDS将会错误地处理不正确地TCP片段，或者对一个片段的合法性作出错误的猜测。
如前面提到的三点，一个IDS系统TCB创造策略决定了IDS如何开始记录一次给定的TCP连接的数据信息，比如象序列号等。这使得IDS可以同步一次需要监视的TCP会话。
然而TCB创造是个麻烦的问题。可以用多种方法可以被利用来判断何时打开一个TCB，但是，这些方法中的每一个似乎证明都是有问题的。TCB创造建立一次连接的初始化状态，包括了连接序列号等信息；通过对IDS的TCB的欺骗行为，入侵者能够破坏那些与这一次被利用的连接具有相同连接参数的将来产生的连接。
作为一个概念，TCB创造对TCP的三次握手是重要的，它其实是一种在主动客户端和被动服务端之间的TCP包的交流。三次握手建立某次连接的初始序列号，还要同时考虑其它的重要的连接参数，如时间戳参数。
通常，在终端系统的TCP实现上，除非三次握手成功，否则TCB建立不起来，也没有必要考虑那么多。没有三次握手，交互的两端没有双方承认的用于继续交换数据的序列号，数据交流是建立不起来的。
但是，在IDS系统中就存在不一样的地方了。IDS或许仅仅通过包含在SYN包中的序列号来判断序列号，或者也可以完全依赖于三次握手给出的信息。当然，如果可能的话，其他方法也可以利用。通常，IDS没有必要在打开一个TCB之前等待完整的TCP三次握手。我们企图概括出一些直接的IDS建立需要的TCB的机制，在一些典型的IDS系统中可以看到。
首先，IDS的设计人员必须作出的决定是是否他的IDS要依赖于完整的三次握手来建立起TCB初始化。一个依赖于三次握手的IDS系统不会记录那些它没有检测到握手信息的数据包的数据。
这有几个较明显的不足，事实上IDS将错失那些它没有发现三次握手的TCP连接。IDS将仅仅能够看到它准备好监视以后产生的连接信息，同样，上面谈到的“逃脱式“攻击将发挥作用，入侵者只要能够让IDS不能发现三次握手就可以绕过IDS检测而入侵终端系统。
为了能够正确的处理TCP的一些扩展特征，例如PAWS，IDS系统必须分析三次握手，三次握手决定了是否某些TCP选项在连接中是合法的。否则，对于IDS要保护某些操作系统如BSD，将会受到“插入式”攻击的威胁。
对于这种要求具备完整的三次握手信息的IDS系统，除非它检测到了并且接受了全部的用于握手的三个数据包，否则它不记录连接数据。当然，我们知道，这三个包当中，有两个来自主动客户端，仅仅有一个来自被动的服务器端，故而，对于对服务器的攻击，攻击的主动权掌握在入侵者手里。使用TCP的术语来说就是，IDS系统直到真正的连接进入了ESTABLISHED状态以后，才开始对连接数据进行记录。
如前所述，由于“逃脱式”入侵技术的存在，这类要求完全建立三次握手的IDS系统是受到威胁的，主要是因为被动造成的IDS丢弃数据包现象使得入侵者的入侵数据逃脱了IDS的监视而到达终端系统。
那种要求至少有部分三次握手信息产生的IDS系统也是需要检测到有某种握手信息后才开始对连接数据进行记录的。三次握手可以使得TCB具有足够的初始化信息，我们也将看到为了同步数据流而盲目地产生TCB而出现的问题，完全地三次握手也使得入侵者哄骗IDS产生失效地TCB的可能性减小了。
然后产生的问题是“三次握手的哪一个部分在IDS产生对应的TCB之前是需要被检测到的？”.一个IDS系统在检测到一个客户端初始连接请求的SYN包时，能够产生一个TCB，或者当IDS检测到服务器返回了一个SYN＋ACK时。在具有一个内外包过滤器作为屏障时，入侵者欺骗服务器的响应是困难的；因此对于一次连接的产生，服务器的SYN+ACK响应是更可靠些的。如果一个入侵者不能欺骗服务器响应，SYN+ACK也包含了正确的连接序列号，IDS将更准确地初始化TCB。
一个IDS系统唯一能够知道一次连接被欺骗的指示是客户端返回给服务器SYN+ACK数据包，这个ACK确认了服务器的初始序列号。如果一个IDS仅仅利用了部分握手信息打开TCB，那么入侵者可以哄骗它为不存在的连接打开TCB。
IDS并不是一个网络连接的积极参与者，通过完整的三次握手而打开TCB可以推断出一次连接的初始状态。当然，IDS完全可以不用考虑三次握手的数据包，对于正常的连接仅仅检测ACK的数据包就可以工作了。
对于一个IDS系统最困难的事应该是对一个TCP连接上被交换的数据流进行精确的重新组合了。当然对于不同的终端系统来说，这些都有精确的定义。
就像对IP碎片重叠的解决，许多操作系统的TCP重组代码中还存在许多不一致的地方，例如，WindowsNT系统往往通过承认重叠数据中老的数据来解决，而4.4BSD系统按照RFC的规定，通常通过承认重叠数据中新的数据来解决。当然，还是一样的，除非IDS系统知道它所监视的网络中的各个系统是如何来处理这些包含了冲突分段的数据流的，否则将不能正确的监视某些类型的终端系统。
这些问题对于大多数连接来说没有表现出些什么问题；正常连接中的大部分TCP分段是顺序地达到，并没有恶意地欺骗性地TCP分段 入到指定地连接流中企图去捣乱IDS系统。然而，在真实地网络中，一个企图逃避IDS监视地入侵者能够使得IDS在监视TCP流的时候尽可能的困难，他们通常会利用现在协议的种种矛盾和限制来达到目的。
存在于IDS的TCP重组代码中问题可能会仅仅当IDS系统接受了某些病态序列的输入的时候才看得出来。大多数时间，IDS看起来都是正在正确的重组着TCP流的。
IDS系统TCB的拆卸策略决定了何时IDS系统停止记录一次连接的数据。TCB的拆卸是必需的，因为跟踪状态信息是很消耗资源的；一个IDS系统如果没有很好地释放TCB占用的资源的话，一个入侵者将会利用这个弱点轻易耗尽IDS资源，只需要作一些无意义的洪流攻击直到IDS不能再跟踪新的连接。
在TCP中，连接在收到明确的要求关闭请求后关闭。两个TCP的信息(RST和FIN)被明确地利用来中断一次连接。除了连接双方的意外中断以外，TCP连接仅仅通过这些信息来中断。TCP明确提出了这些方式，所以IDS利用这些信息来判断何时关闭一次TCB也是合乎逻辑的。
TCP提供了一种周期性交换信息的机制，用来确认连接的双方依然处于连接状态，但是并没有被普遍地利用，同时也需要付出太长的时间来知道一次处于睡眠状态的连接正在被使用。所以，IDS在处理这些没有被明确中断的连接时，也是容易收到洪流攻击的。
对于基于模式匹配的情况，必然要维护上下文的完整性和相关性，如果IDS系统被欺骗而关闭了一个依然处于连接状态的TCB，对于IDS来说，输入流突然中断。一个入侵者能够导致这种TCB不正常中断，而阻止TCB进一步跟踪他的行为，使得入侵者的进一步的攻击信号通过网络到达终端，而这一次连接的TCB已经失效了，模式匹配引擎已经接收不到入侵的进一步上下文关联信息。
另一方面, 对于一个事实上已经关闭的连接，IDS系统不能够成功地拆卸相对应的TCB的话，也是一个脆弱点；一旦端对端的TCP连接被正常关闭，连接参数就能够被重新利用于新的具有完全不同序列号的连接（技术实现上，系统必须等待一段时间才重用连接参数，但是并不是所有的系统都等待）。如果没有同步恢复技术的话，这将导致IDS对于整个连接都将不可分析。
对于IDS系统，判断何时停止跟踪一次连接的一个可能的方式是：监听TCP的表示连接正在被关闭的控制信息。这样做允许一个IDS系统很快恢复那些用于事实上已经中断了的连接的资源，同时也防止了新连接使用同样的连接参数引来的异步问题。不幸的是，因为某些连接中断请求信息可能被控制在入侵者手里，所以完全信任这些信息也是有风险的。
TCP提供了两个连接拆卸消息，第一个信息考虑“顺序的”连接拆卸，连接的两端承认连接的终止并且确信他们所传输的数据在连接关闭之前已经传输完毕。第二个信息是由于某些错误意外终止连接。
借助于FIN消息，TCP提供了顺序地拆卸连接的方法。一个发送FIN消息的系统表示它已经结束发送数据了，并且准备关闭这次连接。当FIN消息被确认了，连接的每一端发送一个消息来结束连接。
每一次连接直到连接的双方都发送一个FIN消息，并且彼此确认了对方的消息之后被关闭。一个入侵者必须构造看起来是从服务器发出的伪造数据包来欺骗这类FIN的连接关闭机制。
对于IDS系统，仅利用FIN消息来判断中断连接TCB是不足够的。TCP提供了一种方式，利用RST消息来通报连接的另一端连接已经关闭了。RST分段不被通过ACK消息验证；如何知道一个RST消息已经被终端系统接受，唯一的方法是观察是否终端系统继续在此连接上发送数据，而在IDS系统中，这样做的唯一的方法是在观察到一个RST消息之后等待连接超时；然而，这样做意味着一个IDS系统可能潜在地、错误地关闭一个处于睡眠状态的连接。
RST带来的问题由于终端系统的TCP实现bugs而显得更加严重。一个RST消息在技术上来讲，仅仅在具有正确的序列号信息才是可用的，具有错误的序列号的RST消息应该被忽略掉。但是，问题是并不是所有的操作系统都检查RST消息中的序列号信息。
利用TCP连接拆卸消息的另外一个方法是在连接变为睡眠状态一段极限时间规定为超时。这样将阻止IDS被错误的TCP拆卸消息所愚弄，同时也潜在地简单化了IDS的TCP代码。
当然，这也有代价――依赖于超时机制的TCB拆卸的系统是容易被欺骗的，某些攻击者，专门利用了IDS将因为超时而关闭一个TCB的弱点，刻意在一次连接中等待IDS超时。
目前针对IDS种种弱点刻意进行的攻击都不是容易防范的，除非IDS系统通过了第二信息源的配合，能够对当前监视的网络拓扑结构以及对作为被监视对象的终端系统所能够接收和处理什么样的数据包进行跟踪分析，否则问题依然存在
篇8：快速了解ids和ips的区别有哪些入侵检测
正如我们大家所知道的那样，互联网的无处不在已经完全改变了我们所知道的网络，过去完全孤立的网络现在连接到了全世界。这种无处不在的连接使企业能够完成过去不可想象的任务。然而，与此同时还存在一个黑暗面。互联网变成了网络犯罪分子的天堂。这些网络犯罪分子利用这种连接向企业发起了数量空前的多的攻击。当互联网最初开始流行的时候，企业开始认识到它们应该使用防火墙防止对它们实施的攻击。防火墙通过封锁没有使用的tcp和udp端口发挥作用。虽然防火墙在封锁某些端口的攻击是有效的，但是，有些端口对于http、smtp和pop3通信是有用的。为了保证这些服务工作正常，对这些常用的服务的对应的端口必须要保持开放的状态。问题是， 已经学会了如何让恶意通信通过这些通常开放的端口。
为了应付这种威胁，一些公司开始应用入侵检测系统(ids)。ids的思路是监视经过你的防火墙的全部通信并且查找可能是恶意的通信。这个思路在理论上是非常好的，但是，在实际上，ids系统由于某些原因的影响工作得并不好。
早期的ids系统通过查找任何异常的通信发挥作用。当检测到异常的通信时，这种行动将被记录下来并且向管理员发出警报。这个过程很少出现问题。对于初始者来说，查找异常通信方式会产生很多错误的报告。经过一段时间之后，管理员会对收到过多的错误警报感到厌烦，从而完全忽略ids系统的警告。
ids系统的另一个主要缺陷是它们仅监视主要的通信。如果检测到一种攻击，它将提醒管理员采取行动。人们认为ids系统采取的这种方法是很好的。总之，由于ids系统会产生很多的错误报告，你真的愿意让ids系统对合法的网络通信采取行动吗?
在过去的几年里，ids系统已经有了很大的进步，
目前，ids系统的工作方式更像是一种杀毒软件。ids系统包含一个名为攻击签名的数据库。这个系统不断地把入网的通信与数据库中的信息进行比较。如果检测到攻击行动，ids系统就发出这个攻击的报告。
比较新的ids系统比以前的系统更准确一些。但是，这个数据库需要不断地更新以保持有效性。而且，如果发生了攻击并且在数据库中没有相匹配的签名，这个攻击可能就会被忽略。即使这个攻击被检测到了并且被证实是一种攻击，ids系统除了向管理员发出警报和记录这个攻击之外没有力量做出任何事情。
这就是入侵防御系统(ips)的任务了。ips与ids类似，但是，ips在设计上解决了ids的一些缺陷。
对于初始者来说，ips位于你的防火墙和网络的设备之间。这样，如果检测到攻击，ips会在这种攻击扩散到网络的其它地方之前阻止这个恶意的通信。相比之下，ids只是存在于你的网络之外起到报警的作用，而不是在你的网络前面起到防御的作用。
ips检测攻击的方法也与ids不同。目前有很多种ips系统，它们使用的技术都不相同。但是，一般来说，ips系统都依靠对数据包的检测。ips将检查入网的数据包，确定这种数据包的真正用途，然后决定是否允许这种数据包进入你的网络。
正如你所看到的，ids和ips系统有一些重要的区别。如果你要购买有效的安全设备，如果你使用ips而不是使用ids，你的网络通常会更安全。
关 键 字：入侵检测
- 计量检测管理系统2023-06-11
- 网吧入侵文章2025-03-15
- 某网站安全检测系统的一个EOP 0Day2023-02-02
- SLKM入侵初步认识2022-12-11
- 网络语言入侵学生作文2023-05-10
- 入侵时小细节的讨论2023-02-18
- 0day交易网成功入侵事件2023-03-29
- 万圣节作文800字：万圣节，鬼怪入侵2024-05-28
- 病毒入侵小学生作文300字2025-05-30
- 大灰狼入侵小学四年级作文2025-09-28