“蓝色妖姬”通过精心收集，向本站投稿了8篇正确区分网络及主机入侵检测系统，下面小编为大家带来整理后的正确区分网络及主机入侵检测系统，希望大家喜欢!
- 目录
篇1：正确区分网络及主机入侵检测系统
入侵检测系统中最普遍的两种产品是基于网络的网络入侵检测系统(NIDS)和基于主机的主机入侵检测系统(HIDS)，那么，NIDS与HIDS到底区别在哪里?用户在使用时该如何选择呢?
先来回顾一下IDS的定义：所谓入侵检测，就是通过从计算机网络或计算机系统中的若干关键点收集信息并对其进行分析，从中发现网络或系统中是否有违反安全策略的行为和遭到袭击的迹象，并对此做出适当反应的过程。而入侵检测系统则是实现这些功能的系统。
这个定义是ICSA入侵检测系统论坛给出的。不难看出，IDS应该是包含了收集信息、分析信息、给出结论、做出反应四个过程。在IDS发展初期，想要全部实现这些功能在技术上是很难办到的，所以大家都从不同的出发点，开发了不同的IDS。
一般情况下，我们都按照“审计来源”将IDS分成基于网络的NIDS和基于主机的HIDS，这也是目前应用最普遍的两种IDS，尤以NIDS应用最为广泛。大部分IDS都采用“信息收集系统-分析控制系统”结构，即由安装在被监控信息源的探头(或代理)来收集相关的信息，然后按照一定方式传输给分析机，经过对相关信息的分析，按照事先设定的规则、策略等给出反应。
核心技术有差别
HIDS将探头(代理)安装在受保护系统中，它要求与操作系统内核和服务紧密捆绑在一起，监控各种系统事件，如对内核或API的调用，以此来防御攻击并对这些事件进行日志;还可以监测特定的系统文件和可执行文件调用，以及Windows NT下的安全记录和Unix环境下的系统记录。对于特别设定的关键文件和文件夹也可以进行适时轮询的监控。HIDS能对检测的入侵行为、事件给予积极的反应，比如断开连接、封掉用户账号、杀死进程、提交警报等等。如果某用户在系统中植入了一个未知的木马病毒，可能所有的杀病毒软件、IDS等等的病毒库、攻击库中都没有记载，但只要这个木马程序开始工作，如提升用户权限、非法修改系统文件、调用被监控文件和文件夹等，就会立即被HIDS的发现，并采取杀死进程、封掉账号，甚至断开网络连接。现在的某些HIDS甚至吸取了部分网管、访问控制等方面的技术，能够很好地与系统，甚至系统上的应用紧密结合。
HIDS技术要求非常高，要求开发HIDS的企业对相关的操作系统非常了解，而且安装在主机上的探头(代理)必须非常可靠，系统占用小，自身安全性要好，否则将会对系统产生负面影响。HIDS关注的是到达主机的各种安全威胁，并不关注网络的安全。
因为HIDS与操作系统紧密相联，美国等发达国家对于HIDS技术都是严格控制的，而独自进行有关HIDS系统的研发，成本非常高，所以国内专业从事HIDS的企业非常少。国内市场上能见到的HIDS产品只有：理工先河的“金海豚”、CA的eTrust(包含类似于HIDS的功能模块)、东方龙马HIDS(纯软件的)、曙光GodEye等屈指可数的几个产品,而且能支持的操作系统也基本上都是Solaris、Linux、Wondows 2000非常少的几个。
NIDS则是以网络包作为分析数据源。它通常利用一个工作在混杂模式下的网卡来实时监视并分析通过网络的数据流，其分析模块通常使用模式匹配、统计分析等技术来识别攻击行为。一旦检测到了攻击行为，IDS的响应模块就作出适当的响应，比如报警、切断相关用户的网络连接等。与SCANER收集网络中的漏洞不同，NIDS收集的是网络中的动态流量信息，
因此，攻击特征库数目多少以及数据处理能力，就决定了NIDS识别入侵行为的能力。大部分NIDS的处理能力还是100兆级的，部分NIDS已经达到1000兆级。NIDS设在防火墙后一个流动岗哨，能够适时发觉在网络中的攻击行为，并采取相应的响应措施。
目前市场上最常见的入侵检测系统，绝大多数大都是NIDS，比如东软NetEye、联想网御、上海金诺KIDS、启明星辰天阗、NAI McAfee IntruShied、安氏LinkTrust等等。
HIDS与NIDS虽然基本原理一样，但实现入侵检测的方法、过程和起到的作用都是不相同的，他们区别主要如上表所示。
性能和效能标准不同
在衡量IDS性能和效能的有关标准方面，HIDS和NIDS也有很大的不同。
HIDS由于采取的是对事件和系统调用的监控，衡量它的技术指标非常少，一般用户需要考虑的是，该HIDS能够同时支持的操作系统数、能够同时监控的主机数、探头(代理)对主机系统的资源占用率、可以分析的协议数，另外更需要关注的是分析能力、数据传输方式、主机事件类的数目、响应的方式和速度、自身的抗攻击性、日志能力等等，一般我们采购HIDS需要看的是研发企业的背景、该产品的应用情况和实际的攻击测试。
而NIDS就相对比较简单。NIDS采取的基本上都是模式匹配的形式，所以衡量NIDS的技术指标可以数量化。对于NIDS，我们要考察的是：支持的网络类型、IP碎片重组能力、可以分析的协议数、攻击特征库的数目、特征库的更新频率、日志能力、数据处理能力、自身抗攻击性等等。尤其要关注的是数据处理能力，一般的企业100兆级的足以应付;还有攻击特征库和更新频率，国内市场常见的NIDS的攻击特征数大概都在1200个以上，更新也基本上都是每月，甚至每周更新。采购NIDS需要注意的是漏报和误报，这是NIDS应用的大敌，也会因各开发企业的技术不同有所不同，所以，在采购时最好要做实际的洪水攻击测试。
HIDS和NIDS这两个系统在很大程度上是互补的，许多机构的网络安全解决方案都同时采用了基于主机和基于网络的两种入侵检测系统。实际上，许多用户在使用IDS时都配置了基于网络的入侵检测，但不能保证检测并能防止所有的攻击，特别是一些加密包的攻击，而网络中的DNS、Email和Web服务器经常是攻击的目标，但是，它们又必须与外部网络交互，不可能对其进行全部屏蔽，所以，应当在各个服务器上安装基于主机的入侵检测系统。因此，即便是小规模的网络结构，也常常需要基于主机和基于网络的两种入侵检测能力。
应用领域分化明显
在应用领域上，HIDS和NIDS有明显的分化。NIDS的应用行业比较广，现在的电信、银行、金融、电子政务等领域应用得最好。由于我国的主要电信骨干网都部署了NIDS，所以的大规模DoS攻击时，我们的骨干网并没有遭到破坏，而且以此为契机，NIDS迅速地推广到各个应用领域，甚至可以说，“NIDS的应用是沿着防火墙走的”。
但在NIDS的应用过程中，最大的敌人就是误警和漏警。漏警不影响应用环境的可用性，只是用户的投资失误;而误警则有可能导致警报异常、网络紊乱，甚至应用的瘫痪。误警很多时候是设置不当造成的，许多用户简单把这些都归结为检测错误率(False Positives)，这是不正确的。由于技术的发展，NIDS的检测错误率实际上已经很低了，我们要努力做的是与用户一起，深入理解应用，科学的配置，这才能有效减少误警率。所有说，应用不仅是NIDS厂商的事情，真正的主角应该是用户。
篇2：网络入侵检测系统实现
互联网也同时带给我们无数的宝贵资源，只等我们去开发、利用，开放源代码软件(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 2000等，其具体的实现步骤大同小异，因此就不在另行说明了。
三、安装及配置
在正式进行软件安装之前，请检查系统，确保拥有符合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] 下一页
篇3：建新手入门入侵检测系统
根据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就搭建完毕。后面要做的就是不断完善各部分功能，尤其是提高系统的检测能力。
篇4：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界面，
篇5：杂谈入侵检测防御系统
几乎所有当前市场上的网络入侵检测系统都是基于一种被动数据收集方式的协议分析，我们可以预见，这种方式在本质上是有缺陷的，
毫无疑问，这样的入侵检测系统会监视整个网络环境中的数据流量，并且总是与一种预定义的可疑行为模式来进行对照，甚至所谓的入侵行为分析技术也只是简单地从单位时间状态事件技术上做了些组合工作，事实上离真正实用的复杂 入侵行为的剖析和理解还有很远的距离。
对于这种检测技术的可靠性，我们可以通过自定义的三种可行性很强的攻击方式来验证――插入攻击、逃避攻击和拒绝服务攻击。我们可以看到，当一个入侵者实施了这样的入侵策略以后，所谓的入侵检测系统便妥协了。我们的结论是这种入侵检测系统不是放之四海而皆准的，除非它们从根本上被重新设计过。
真正实用的入侵检测系统的存在价值就是能够察觉 的入侵行为并且进行记录和处理，当然，人们也会根据自己的需求提出需要强大的日志记录策略、入侵诱导等等。
不同的入侵检测系统存在不同的入侵分析特征。一个企图检测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系统通过了第二信息源的配合，能够对当前监视的网络拓扑结构以及对作为被监视对象的终端系统所能够接收和处理什么样的数据包进行跟踪分析，否则问题依然存在
篇6：入侵检测系统（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分类
一般来说，入侵检测系统可分为主机型和网络型。
主机型入侵检测系统往往以系统日志、应用程序日志等作为数据源，当然也可以通过其他手段（如监督系统调用）从所在的主机收集信息进行分析。主机型入侵检测
篇7：网络入侵检测系统研究论文
网络入侵检测系统研究论文
1网络信息安全技术的发展
1.1加密
对于计算机网络中的加密，其实就是比较基本的一种安全机制，是使用数学函数来处理不加密的一些关键信息，并且完成信息加密的这样过程。依据不一样的密钥分发方法，还有达成加密机制分为两种类型，其中包括有私钥加密以及公钥加密。这是能够用来数据传输以及存储中，还能够避免一些不授权者的非法读取的信息。然而，它无法在前面的信息加密之前或者是之后来加密保护，而是要依赖于密钥的一个管理技术。
1.2数字签名
数字前面关键就在于可以提供拒绝识别功能，也就是说，第三方没有办法去伪造发件人去完成数据的发送，所以说发送方在发送具体数据之后没法否认。数字签名一般来说使用公钥来完成，对于签名者来说可以通过用密钥加密，并且验证方能够用签名者的公钥来完成解密签名数据操作，并且能够确定接收到的信息是否是错误的。
1.3防火墙系统
防火墙系统也就是把安全战略转化为安全控制操作，对于不一样的信任级别或者是不一样的安全级别网络设置具体安全边界，检查网络数据包或者是具体服务的一些请求，可以较为有效地控制内部网络或者是外部网络间访问或者是数据的传输，进而能够完成保护内部网络信息不会因未经授权的用户限制了内部这些用户的访问限制。不过对于防火墙系统来说，也是有局限性：诸如防火墙无法在没有经过防火墙入侵，也就是系统可以绕过性攻击。防火墙很难实现防范恶意攻击或者是一些内部用户的误操作行为发生。对于防火墙的配置和管理等等都比较复杂，容易导致安全漏洞的发生。
2入侵检侧系统的分类
2.1基于主机的入侵检测系统及特点
对于主机的入侵检测系统能够把一个主机上面得到数据作为计算机网络安全中入侵系统分析的数据源，另外基于网络的入侵检测系统能够从互联网中得到一些数据来当成是数据源。一般来说基于主机的这样入侵检测系统只可以检测到一个主机的系统，但是基于网络的入侵检测系统能够检测多个主机系统，对于较多分布在不同网段的基于网络的入侵检测系统能够一起工作，从而实现更加强大的入侵检测的效果。计算机网络安全系统中，对于主机的入侵检测系统检测模块位于被保护系统，利用提取这些运行数据且对入侵分析来完成入侵检测的具体功能。主机的入侵检测系统现在的不足有，这个入侵检测取决于整个系统的可靠性，它需要系统本身有基本的安全特性，然后你可以提取这些入侵信息。
2.2基于网络的入侵检测系统
计算机网络的入侵检测系统可以利用网络监视来完成数据的提取。在工作中，局域网通常使用以太网协议。对于这个协议期间主机子网无线的数据传输方法，没一台的主机能够发送数据包，还可以通过子网完成广播，其实就是说，对于每一台主机发送以及接收数据能够收到同一子网内的其他主机数据。在通常的环境中，每个到来的主机网卡的`数据包会先完成过滤，一般到目标地址是本机或者是广播地址的数据包接收缓冲区，把其他的这些数据包丢弃，所以说，在通常的情况下，主机的网络性能就是关心和自己有关的一些数据包，不过设置网卡接收模式正确过滤策略能够完成网卡过滤方式的变动，使网卡再接收所有的数据包这一时期之后，不管这些包的最后目标是否是主机。对于卡的接收模式被叫做混合模式，大多数卡将提供这些设置，所以说，必要时，合理设置网卡可以通过这段时间的所有信息的交流，完成网络监控的效果。
3网络入侵检测系统需要解决的关键技术
3.1入侵检测模块间的协作
入侵检测模块的合作关键就是对不同检测模块之间数据共享的解析，同时对模块间增强功能，利用合作可以达成工作时无法实现的具体功能。分布式网络入侵检测系统的框架结构、功能模块的异构性，数据检测系统还有探测器分布在网络的情况，同时继承这些不同的开发人员研制，用不同的具体检测机制，还有入侵检测功能模块运行在各异的系统以及不一样的检测子系统，还要去考虑它们之间的这些数据共享以及协作等等，还需要去提供分布式数据采集、并且利用数据接口来完成不一样的检测器之间的互操作性，考虑分布在整个组织在分布式入侵检测系统和探测器测试结果融合技术。对于分布式数据共享也应该是对收集到的数据格式完成一个转换，从而能够保证这些数据的可用性。这些关键是涉及到网络入侵检测系统的一些功能模块之间的合作机制还有技术，其中包括计算机网络安全中入侵检测系统的具体通信机制，数据预处理和数据融合技术以及功能模块间的协作机制等等。
3.2入侵检测数据分析的层次性
即使对于各种入侵检测系统概念是一样的：不过整体来说都是通过探测器还有分析仪和用户界面来构成的。入侵检测系统在特定方法的基础上，通过分析数据和收集数据，这些方面是非常不同的。每一种的入侵检测系统的分析数据源上有水平，从入侵检测系统基于应用程序跨多个网络入侵检测系统，来完成这些分析数据以及监控的能力逐渐增强，范围也不断地扩大，并且这入侵检测系统数据可以是源于水平不高于它的入侵检测系统的输出。其实就是代表，入侵检测系统检测的具体结果以及输出能够在水平不低于其入侵检测系统使用和进一步的具体分析。
4结语
计算机网络安全中的入侵检测系统是非常关键的环节，能够有效弥补防火墙存在的不足，是有效的防护技术，在对计算机网络以及计算机系统中的一些关键点收集信息并解析。通过监视主机系统或者是网络上每个用户活动，进而去发现网络或者是系统中存在的违反安全策略入侵行为。通常来说入侵检测系统是根据数据源分为基于主机和网络这两种形式，本课题探究的入侵检测技术关键是误用入侵检测和异常检测。计算机入侵检测系统已经收到了广泛的重视，不过入侵检测技术现在还是在发展过程。所以本课题中对计算机网络安全中入侵检测技术进行了全面多角度探究。
篇8：网络入侵检测初步探测
网络入侵检测初步探测!
经过精心配置的Win2000服务器可以防御90%以上的入侵和渗透，但是，就象上一章结束时所提到的：系统安全是一个连续的过程，随着新漏洞的出现和服务器应用的变化，系统的安全状况也在不断变化着；同时由于攻防是矛盾的统一体，道消魔长和魔消道长也在不断的转换中，因此，再高明的系统管理员也 不能保证一台正在提供服务的服务器长时间绝对不被入侵，所以，安全配置服务器并不是安全工作的结束，相反却是漫长乏味的安全工作的开始，本文我们将初步探讨Win2000服务器入侵检测的初步技巧，希望能帮助您长期维护服务器的安全。入侵的检测主要还是根据应用来进行，提供了相应的服务就应该有相应的检测分析系统来进行保护，对于一般的主机来说，主要应该注意以下几个方面：
1。基于80端口入侵的检测
WWW服务大概是最常见的服务之一了，而且由于这个服务面对广大用户，服务的流量和复杂度都很高，所以针对这个服务的漏洞和入侵技巧也最多。对于NT来说，IIS一直是系统管理员比较头疼的一部分，不过好在IIS自带的日志功能从某种程度上可以成为入侵检测的得力帮手。IIS自带的日志文件默认存放在System32/LogFiles目录下，一般是按24小时滚动的，在IIS管理器中可以对它进行详细的配置。
我们假设一台WEB服务器，开放了WWW服务，你是这台服务器的系统管理员，已经小心地配置了IIS，使用W3C扩展的日志格式，并至少记录了时间(Time)、客户端IP(Client IP)、方法(Method)、URI资源(URI Stem)、URI查询(URI Query)，协议状态(Protocol Status)，我们用最近比较[/size]流行的Unicode漏洞来进行分析：打开IE的窗口，在地址栏输入：127。0。0。1/scripts/。。%c1% 1c。。/winnt/system32/cmd。exe?/c+dir默认的情况下你可以看到目录列表，让我们来看看IIS的日志都记录了些什么，打开Ex010318。log(Ex代表W3C扩展格式，后面的一串数字代表日志的记录日期)：07：42：58 127。0。0。1 GET /scripts/。。\\。。/winnt/system32\\cmd。exe /c+dir 200上面这行日志表示在格林威治时间07：42：58(就是北京时间23：42：58)，有一个家伙(入侵者)从127。0。0。1的IP在你的机器上利用Unicode漏洞(%c1%1c被解码为\\，实际的情况会因为Windows版本的不同而有略微的差别)运行了cmd。exe，参数是/c dir，运行结果成功(HTTP 200代表正确返回)。
大多数情况下，IIS的日志会忠实地记录它接收到的任何请求(也有特殊的不被IIS记录的攻击，这个我们以后再讨论)。但是，IIS的日志动辄数十兆、流量大的网站甚至数十G，人工检查几乎没有可能，唯一的选择就是使用日志分析软件，用任何语言编写一个日志分析软件(其实就是文本过滤器)都非常简单。
告诉大家一个简单的方法，比方说你想知道有没有人从80端口上试图取得你的Global。asa文件，可以使用以下的命令：find Global。asa ex010318。log /i。这个命令使用的是NT自带的find。exe工具，可以轻松的从文本文件中找到你想过滤的字符串，Global。asa是需要查询的字符串，ex010318。log是待过滤的文本文件，/i代表忽略大小写。因为我无意把这篇文章写成微软的Help文档，所以关于这个命令的其他参数以及它的增强版FindStr。exe的用法请去查看Win2000的帮助文件，
无论是基于日志分析软件或者是Find命令，你都可以建立一张敏感字符串列表，包含已有的IIS漏洞(比如+。htr)以及未来将要出现的漏洞可能会调用的资源(比如Global。asa或者cmd。exe)，通过过滤这张不断更新的字符串表，一定可以尽早了解入侵者的行动。
需要提醒的是，使用任何日志分析软件都会占用一定的系统资源，因此，对于IIS日志分析这样低优先级的任务，放在夜里空闲时自动执行会比较合适，如果再写一段脚本把过滤后的可疑文本发送给系统管理员，那就更加完美了。同时，如果敏感字符串表较大，过滤策略复杂，我建议还是用C写一个专用程序会比较合算。
2。基于安全日志的检测
通过基于IIS日志的入侵监测，我们能提前知道窥伺者的行踪(如果你处理失当，窥伺者随时会变成入侵者)，但是IIS日志不是万能的，它在某种情况下甚至不能记录来自80端口的入侵，根据我对IIS日志系统的分析，IIS只有在一个请求完成后才会写入日志，换言之，如果一个请求中途失败，日志文件中是不会有它的踪影的(这里的中途失败并不是指发生HTTP400错误这样的情况，而是从TCP层上没有完成HTTP请求，例如在POST大量数据时异常中断)，对于入侵者来说，就有可能绕过日志系统完成大量的活动。而且，对于非80 Only的主机，入侵者也可以从其它的服务进入服务器，因此，建立一套完整的安全监测系统是非常必要的。
Win2000自带了相当强大的安全日志系统，从用户登录到特权的使用都有非常详细的记录，可惜的是，默认安装下安全审核是关闭的，以至于一些主机被黑后根本没法追踪入侵者。所以，我们要做的第一步是在管理工具-本地安全策略-本地策略-审核策略中打开必要的审核，一般来说，登录事件与账户管理是我们最关心的事件，同时打开成功和失败审核非常必要，其他的审核也要打开失败审核，这样可以使得入侵者步步维艰，一不小心就会露出马脚。仅仅打开安全审核并没有完全解决问题，如果没有很好的配置安全日志的大小及覆盖方式，一个老练的入侵者就能够通过洪水般的伪造入侵请求覆盖掉他真正的行踪。通常情况下，将安全日志的大小指定为50MB并且只允许覆盖7天前的日志可以避免上述情况的出现。
除了安全日志，系统日志和应用程序日志也是非常好的辅助监测工具，一般来说，入侵者除了在安全日志中留下痕迹(如果他拿到了Admin权限，那么他一定会去清除痕迹的)，在系统和应用程序日志中也会留下蛛丝马迹，作为系统管理员，要有不放过任何异常的态度，这样入侵者就很难隐藏他们的行踪。
3。文件访问日志与关键文件保护
除了系统默认的安全审核外，对于关键的文件，我们还要加设文件访问日志，记录对它们的访问。
文件访问有很多的选项：访问、修改、执行、新建、属性更改一般来说，关注访问和修改就能起到很大的监视作用。
例如，如果我们监视了系统目录的修改、创建，甚至部分重要文件的访问(例如cmd。exe，net。exe，system32目录)，那么，入侵者就很难在不引起我们注意的情况下安放后门。要注意的是，监视的关键文件和项目不能太多，否则不仅增加系统负担，还会扰乱日常的日志监测工作。关键文件不仅仅指的是系统文件，还包括有可能对系统管理员和其他用户构成危害的任何文件，例如系统管理员的配置、桌面文件等等，这些都是有可能被用来窃取系统管理员资料和密码的。
4。进程监控
进程监控技术是追踪木马后门的另一个有力武器，90%以上的木马和后门是以进程的形式存在的。作为系统管理员，了解服务器上运行的每个进程是职责之一(否则不要说安全，连系统优化都没有办法做)。做一份每台服务器运行进程的列表非常必要，能帮助管理员一眼就发现入侵进程，异常的用户进程或者异常的资源占用都有可能是非法进程。除了进程外，dll也是危险的东西，例如把原本是exe类型的木马改写为dll后，使用rundll32运行就比较具有迷惑性。
★ 计量检测管理系统
★ 试验检测管理系统
★ 经典入侵招数
★ 跨站入侵技术详解
★ 入侵几种方法介绍
正确区分网络及主机入侵检测系统（精选8篇）
