IDS分析及其在Linux下的实现.doc

毕业设计（论文）：入侵检测系统（IDS）分析及其在linux下的实现 第 21 页 共2 1 页
目 录

第一章 入侵检测系统简介 2
第二章 入侵检测系统模型 3
2.1 CIDF模型 3
2.2 IDS分类 3
2.3 通信协议 5
2.4入侵检测技术 5
第三章 LINUX下的实现 6
3.1系统框架 6
3.2各部分的实现流程及重要问题说明 7
3.2.1数据采集部分 7
3.2.2数据分析 8
3.2.3控制台 10
3.3未完成部分 12
3.4 性能参考 12
第四章 存在的问题 13
第五章 结论 15
附录 16
A.常见攻击手段及其分析 16
B.waRcher源程序 19
参考文献 20
第一章 入侵检测系统简介

当越来越多的公司将其核心业务向互联网转移的时候，网络安全作为一个无法回避的问题呈现在人们面前。传统上，公司一般采用防火墙作为安全的第一道防线。而随着攻击者知识的日趋成熟，攻击工具与手法的日趋复杂多样，单纯的防火墙策略已经无法满足对安全高度敏感的部门的需要，网络的防卫必须采用一种纵深的、多样的手段。与此同时，当今的网络环境也变得越来越复杂，各式各样的复杂的设备，需要不断升级、补漏的系统使得网络管理员的工作不断加重，不经意的疏忽便有可能造成安全的重大隐患。在这种环境下，入侵检测系统成为了安全市场上新的热点，不仅愈来愈多的受到人们的关注，而且已经开始在各种不同的环境中发挥其关键作用。
本文中的“入侵”（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 Intrusion Detection Framework (CIDF)，但进展非常缓慢，尚没有被广泛接收的标准出台。
第二章 入侵检测系统模型
2.1 CIDF模型
Common Intrusion Detection Framework (CIDF)（http://www.gidos.org/）阐述了一个入侵检测系统（IDS）的通用模型。它将一个入侵检测系统分为以下组件：
l 事件产生器（Event generators）
l 事件分析器（Event analyzers
l 响应单元（Response units ）
l 事件数据库（Event databases ）

CIDF将IDS需要分析的数据统称为事件（event）,它可以是网络中的数据包，也可以是从系统日志等其他途径得到的信息。
事件产生器的目的是从整个计算环境中获得事件，并向系统的其他部分提供此事件。事件分析器分析得到的数据，并产生分析结果。响应单元则是对分析结果作出作出反应的功能单元，它可以作出切断连接、改变文件属性等强烈反应，也可以只是简单的报警。事件数据库是存放各种中间和最终数据的地方的统称，它可以是复杂的数据库，也可以是简单的文本文件。
在这个模型中，前三者以程序的形式出现，而最后一个则往往是文件或数据流的形式。
在其他文章中，经常用数据采集部分、分析部分和控制台部分来分别代替事件产生器、事件分析器和响应单元这些术语。且常用日志来简单的指代事件数据库。如不特别指明，本文中两套术语意义相同。
2.2 IDS分类
一般来说，入侵检测系统可分为主机型和网络型。
主机型入侵检测系统往往以系统日志、应用程序日志等作为数据源，当然也可以通过其他手段（如监督系统调用）从所在的主机收集信息进行分析。主机型入侵检测系统保护的一般是所在的系统。
网络型入侵检测系统的数据源则是网络上的数据包。往往将一台机子的网卡设于混杂模式（promisc mode）,监听所有本网段内的数据包并进行判断。一般网络型入侵检测系统担负着保护整个网段的任务。
不难看出，网络型IDS的优点主要是简便：一个网段上只需安装一个或几个这样的系统，便可以监测整个网段的情况。且由于往往分出单独的计算机做这种应用，不会给运行关键业务的主机带来负载上的增加。但由于现在网络的日趋复杂和高速网络的普及，这种结构正受到越来越大的挑战。一个典型的例子便是交换式以太网。
而尽管主机型IDS的缺点显而易见：必须为不同平台开发不同的程序、增加系统负荷、所需安装数量众多等，但是内在结构却没有任何束缚，同时可以利用操作系统本身提供的功能、并结合异常分析，更准确的报告攻击行为。参考文献[7]对此做了描述，感兴趣的读者可参看。
入侵检测系统的几个部件往往位于不同的主机上。一般来说会有三台机器，分别运行事件产生器、事件分析器和响应单元。waRcher将前两者合在了一起，因此只需两台。在安装IDS的时候，关键是选择数据采集部分所在的位置，因为它决定了“事件”的可见度。
对于主机型IDS，其数据采集部分当然位于其所监测的主机上。
对于网络型IDS，其数据采集部分则有多种可能：
（1）如果网段用总线式的集线器相连，则可将其简单的接在集线器的一个端口上即可；
（2）对于交换式以太网交换机，问题则会变得复杂。由于交换机不采用共享媒质的办法，传统的采用一个sniffer来监听整个子网的办法不再可行。可解决的办法有：
a.交换机的核心芯片上一般有一个用于调试的端口（span port），任何其他端口的进出信息都可从此得到。如果交换机厂商把此端口开放出来，用户可将IDS系统接到此端口上。
优点：无需改变IDS体系结构。
缺点：采用此端口会降低交换机性能。

b.把入侵检测系统放在交换机内部或防火墙内部等数据流的关键入口、出口。
优点：可得到几乎所有关键数据。
缺点：必须与其他厂商紧密合作，且会降低网络性能。
c.采用分接器（Tap），将其接在所有要监测的线路上。采用分接器的网络结构如下：

优点：再不降低网络性能的前提下收集了所需的信息。
缺点：必须购买额外的设备(Tap)；若所保护的资源众多，IDS必须配备众多网络接口。

d.可能唯一在理论上没有限制的办法就是采用主机型IDS。
2.3 通信协议
IDS系统组件之间需要通信，不同的厂商的IDS系统之间也需要通信。因此，定义统一的协议，使各部分能够根据协议所致订的的标准进行沟通是很有必要的。
IETF目前有一个专门的小组Intrusion Detection Working Group (idwg)负责定义这种通信格式，称作Intrusion Detection Exchange Format。目前只有相关的草案（internet draft），并未形成正式的RFC文档。尽管如此，草案为IDS各部分之间甚至不同IDS系统之间的通信提供了一定的指引。
IAP(Intrusion Alert Protocol)是idwg制定的、运行于TCP之上的应用层协议，其设计在很大程度上参考了HTTP，但补充了许多其他功能（如可从任意端发起连接，结合了加密、身份验证等）。对于IAP的具体实现，请参看 [9]，其中给出了非常详尽的说明。这里我们主要讨论一下设计一个入侵检测系统通信协议时应考虑的问题：
1． 分析系统与控制系统之间传输的信息是非常重要的信息，因此必须要保持数据的真实性和完整性。必须有一定的机制进行通信双方的身份验证和保密传输（同时防止主动和被动攻击）。
2. 通信的双方均有可能因异常情况而导致通信中断，IDS系统必须有额外措施保证系统正常工作。
2.4入侵检测技术
对各种事件进行分析，从中发现违反安全策略的行为是入侵检测系统的核心功能。从技术上，入侵检测分为两类：一种基于标志（signature-based），另一种基于异常情况(anomaly-based)。
对于基于标识的检测技术来说，首先要定义违背安全策略的事件的特征，如网络数据包的某些头信息。检测主要判别这类特征是否在所收集到的数据中出现。此方法非常类似杀毒软件。
而基于异常的检测技术则是先定义一组系统“正常”情况的数值，如CPU利用率、内存利用率、文件校验和等（这类数据可以人为定义，也可以通过观察系统、并用统计的办法得出），然后将系统运行时的数值与所定义的“正常”情况比较，得出是否有被攻击的迹象。这种检测方式的核心在于如何定义所谓的“正常”情况。
两种检测技术的方法、所得出的结论有非常大的差异。基于异常的检测技术的核心是维护一个知识库。对于已知得攻击，它可以详细、准确的报告报告出攻击类型，但是对未知攻击却效果有限，而且知识库必须不断更新。基于异常的检测技术则无法准确判别出攻击的手法，但它可以（至少在理论上可以）判别更广范、甚至未发觉的攻击。
如果条件允许，两者结合的检测会达到更好的效果。
第三章 linux下的实现
3.1系统框架
waRcher是一个在linux下运行的基于标识检测的网络IDS。从逻辑上分为数据采集、数据分析和结果显示三部分，符合CIDF的规范。
从实现结构上看，waRcher分成三个应用程序，它们分别是：
1．数据收集及分析程序(agent) ；2.告警信息收集程序(listener)；3.告警信息显示程序(console)。agent是数据采集和数据分析的合体；listener接收agent发出的告警信息，并将接到的信息存储为日志；console为管理员提供了更友好的观察日志的图形界面。三者的关系如下图所示：
同大多数商业IDS一样，waRcher采用了分布式的结构。运行waRcher建议采用两台PC机，一台运行agent,另一台运行listener和console.
一个典型的运行waRcher的环境为：

与其他同类程序相比，waRcher的优点主要有：
1.提供了完整的框架，可以灵活的应用于各种环境并扩充；
2.采用数据分析与告警程序分离，便于在大规模的网络环境下集中管理；
3.已经实现了对分片的处理，解决了利用分片逃避检查的问题；
4.数据分析部分不完全依赖已有攻击程序，而是分析其核心特征以察觉其变种攻击；但同时依靠已有攻击程序的细节来评估判别的准确性。以上设计增加了告警的可靠性。
3.2各部分的实现流程及重要问题说明
3.2.1数据采集部分
Agent采用了linux2.2内核中提供的PF_PACKET类型的socket（并未采用libpcap提供的API接口） ,直接从链路层获取数据帧。（直接采用操作系统提供的接口主要是考虑高效性，但为了将来的移植问题，以后仍然可能会改为使用libpcap库提供的函数接口。）根据linux的要求，建立这样的一个socket需要root权限,即uid=0。从packet socket读到的数据是链路层格式的数据，但经过处理（socket函数的第二个参量SOCK_DGRAM表示要去掉第二层的数据头，第三个参量ETH_P_IP表示只接收ipv4的数据包）后，缓冲区内的内容是个完整的IP包（未经任何其它处理）。分析工作交由数据分析程序去做。
数据采集部分还做了一项工作就是将网卡置于混杂模式，这样可以监听到整个网段的数据。
waRcher的这种实现，实际是通过socket将数据拷贝到应用层。这种结构比较灵活与安全（应用程序崩溃不会导致系统崩溃），但频繁的应用态与核心态的转换浪费了CPU。还有一种办法就是采用linux中的模组（modular）的办法，将IDS作为内核的一部分。[10]提供了一个内核中的sniffer的框架。可以利用其结构实现嵌入内核的、更加高效的入侵检测系统。WaRcher可以很容易的转移到这种方式，但考虑到其对操作系统稳定性的影响和调试的难度，目前未采用。
需要指出的是，agent只是监听数据包，并不参与操作系统协议栈的处理。如果操作系统被攻击导致拒绝服务，agent也将无法运行。因此，首先要保证起所运行的系统是安全的。有些商业入侵检测系统（如NFR）将数据采集部分放在专门的、经过改进的、高度安全的系统之上，以保证IDS这一系统中的重要程序正常工作。对于waRcher本身来说，建议采用增加了stackguard功能的gcc编译器，减少潜在的缓冲区溢出（buffer overflow）漏洞。
agent将数据读到缓冲区之后，首先将其封装为sbuff结构，当数据在程序中传递时，均采用此结构。其定义为：
struct sbuff
{
union{
struct tcphdr *tcph;
struct udphdr *udph;
struct icmphdr *icmph;
struct igmphdr *igmph;
} h;

union{
struct iphdr *iph;
} nh;

unsigned char *data;
} ;
sbuff中定义了指向协议头的指针，子程序可根据这些指针快速的定位数据头位置。
3.2．2数据分析
数据分析部分事实上与数据采集部分作为一个进程(agent)存在,主要是为了简化程序设计的复杂性。在得到数据帧之后，agent模拟操作系统的TCP/IP堆栈对数据进行处理并与已知攻击行为的特征进行比较，从中发现异常行为，并向控制台告警。
在分析的过程中，首先对数据包进行协议分析、过滤，根据协议、端口等信息将数据包送到不同的检测流程（如只有HTTP协议的包才进行CGI检查），这样使检查的过程尽量缩短，提高了程序的工作效率。当进入相应的检测流程后，则按照线性的顺序工作。
数据分析部分设计为模拟TCP/IP堆栈的流程处理数据包，从中发现异常行为（如分片重合、异常标志等）。这样主要是为了减少误报与漏报，从攻击的核心特征发现它，而不是象许多其他系统那样，只检查攻击包的表面特征。waRcher中包括了IP分片处理，包括了TCP状态转换。通过这种结构，可以准确的判别诸如teardrop等碎片攻击的各种变种。
对一些常见攻击手法的描述和处理方法见附录1。

waRcher目前可以处理以下攻击：
1.land
2.winnuke
3.ping of death
4.source routing
5.若干种CGI攻击
6.各种OS detection
7.各种类型的端口扫描
8.syn flood
9.smurf
10.teardrop及其所有变种
11.jolt

数据采集部分与数据分析部分（即agent程序）的整体流程图为：

若识别出有异常行为，则向控制台告警（采用类似IAP的协议）。WaRcher此时分出一个单独的进程处理与控制台的交互，而原进程则继续处理新的数据包。
3.2.3控制台
控制台部分分为两个程序，listener和console。 listener绑定6543端口（目前似乎没有和其他程序冲突），接收从分析程序发出的分析结果和其他信息，并根据其类型转化到不同文件存储。此时的文件为用户可读。其实agent和listener两者便已经形成了一个完整的IDS。
console为一用GTK+图形库编制的一个窗口程序，目的主要是给用户一个更方便友好的界面来浏览警告信息（下图）。

因为listener已经将报警信息以明文格式存储，因此也可以采用将其转换成HTML文件，用浏览器查看。当然也可以采用windows应用程序。因waRcher不是一个商业软件，对界面的考虑并不多。
WaRcher的日志采用了类似UNIX系统日志的格式，包括time（事件发生时间）,host（被攻击的主机名或IP）,agent（发现此攻击的agent的名字或IP）,event（攻击的具体描述）这些项。各项之间用空格分开，每个记录用一行，每项之中不能有空格，若有，用下划线代替（以上语法约定均是为了方便处理）。下面是一个例子：
Feb_27_20:30:31 172.18.172.18 agent01 Port_Scan_From_
Feb_27_20:31:07 web_server agent02 OS_fingerprint_from_12.18.1.1
在设计日志格式时我曾经考虑过许多方案，主要是想分出更多的项，如记录两端的端口信息，加入可信度和计数，这样在以后可以很方便的排序和查找，但最终还是采用了这种简单的格式。其原因主要是各种不同的事件需要记录的项千差万别，唯一又共性的便是time,host,agent这三项，其余之处可都放到event项中去说明。我可以举一个例子：攻击的源地址似乎应该单列出来，但是现在假冒源地址进行的攻击实在太普遍了，land攻击（具体描述见附录）便将源地址设为与被攻击者相同，此时记录源地址没有任何意义；syn flood往往随机的生成源地址，如果因源地址不同而单列出一个记录的话，只会使日志迅速膨胀，而其记录的内容与只简单记录发生了syn flood没有多大区别。
设计日志时还有一大问题便是连续不断的相同攻击会产生大量相同的日志，waRcher对此采取的办法也与UNIX的syslogd相同：设立一专门的计数器count，每当有新的事件出现的时候先比较是否与上一事件重名，若不重名则马上记录（保证报警的迅速），否则对计数器加一，直到有不重名的事件发生才真正写日志，此时记录的event项的内容为：
The_last_messages_repeated_$count_times
除生成日志告警外，系统不采取任何其他行动，是否采取相应的措施由系统管理员自行决定。
3.3未完成部分
此章所描述的功能与最终理想的程序有所出入（主要是由于时间关系有些部分尚未完成），具体差别有：
（1）无法灵活的升级：所有的入侵检测部分都以编译后的程序的形式提供（可以高效处理,但同时失去了灵活性）用户必须完全或部分更新原有程序才能实现升级。以后应该采用类似脚本语言的办法。
（2）所处理的攻击数还需有很大的提高。
（3）控制台程序尚没有加入对采集分析程序的控制，也没有加入对分析结果作进一步处理的功能（如排序、过滤、查找等）。
（4）磁盘定额：对日志过大以后的情况尚没有人为规定，不过目前可以用linux自身的quato功能实现（写满一定磁盘定额后覆盖）。
（5）集中控制:控制台应该加入配置agent的功能（如暂停其某项检测）。
（6）无法动态的载入和卸载检测规则。（很快会加入）
（7）未采用IAP：现在agent与listener的通信仍采用明文传输，这种局面急需改变。但IAP设计的过于复杂，且是否会成为标准尚不明朗，所以暂时可能先设计一个简单点的协议来实现加密和验证。

3.4 性能参考
IDS系统面临的一个矛盾便是性能与功能的折衷。对数据进行全面复杂的检验，对实时性的要求构成了很大的挑战。
对waRcher而言，其可能影响性能的有三个地方：内核到应用层的转换（涉及数据拷贝）；数据分析（大量的数据匹配操作）；记录日志（IO操作）。
IDS的测试还没有客观的标准。由于内部流程不同，不同的测试数据会产生不同的效果（假设以丢包率，CPU利用率为标准）。且由于程序一直处于开发阶段，尚还没有对waRcher的某一稳定版本进行性能测试。但根据以前防火墙测试的经验，性能的瓶颈往往在日志的记录上（大量磁盘读写），所以应通过尽量减少日志数量的办法来提高IDS的性能。

第四章 存在的问题
尽管有众多的商业产品出现，与诸如防火墙等技术高度成熟的产品相比，入侵检测系统还存在相当多的问题。这一章我们便要讨论一下对其进行威胁的主要因素，值得注意的是，这些问题大多是目前入侵检测系统的结构所难以克服的（包括waRcher），而且这些矛盾可能越来越尖锐。
以下便是对入侵检测产品提出挑战的主要因素[3]：
1.攻击者不断增加的知识，日趋成熟多样自动化工具，以及越来越复杂细致的攻击手法。
下图是CERT每年处理的安全事件（纵坐标）的统计：

不难看出，安全问题正日渐突出，尤其是2000年初出现了对诸如Yahoo，ebay等著名ICP的攻击事件。IDS必须不断跟踪最新的安全技术，才能不致被攻击者远远超越。

2.恶意信息采用加密的方法传输。
网络入侵检测系统通过匹配网络数据包发现攻击行为，IDS往往假设攻击信息是通过明文传输的，因此对信息的稍加改变便可能骗过IDS的检测。TFN现在便已经通过加密的方法传输控制信息。还有许多系统通过VPN（虚拟专用网）进行网络之间的互联，如果IDS不了解其所用的隧道机制，会出现大量的误报和漏报。

3.必须协调、适应多样性的环境中的不同的安全策略。
网络及其中的设备越来越多样化，即存在关键资源如邮件服务器、企业数据库，也存在众多相对不是很重要的PC机。不同企业之间这种情况也往往不尽相同。IDS要能有所定制以更适应多样的环境要求。

4.不断增大的网络流量。
用户往往要求IDS尽可能快的报警，因此需要对获得的数据进行实时的分析，这导致对所在系统的要求越来越高，商业产品一般都建议采用当前最好的硬件环境（如NFR4.1.1要求最少主频500以上的机器）。尽管如此，对百兆以上的流量，单一的IDS系统仍很难应付。可以想见，随着网络流量的进一步加大（许多大型ICP目前都有数百兆的带宽），对IDS将提出更大的挑战，在PC机上运行纯软件系统的方式需要突破。

5.广泛接受的术语和概念框架的缺乏。
入侵检测系统的厂家基本处于各自为战的情况，标准的缺乏使得其间的互通几乎不可能。

6.不断变化的入侵检测市场给购买、维护IDS造成的困难。
入侵检测系统是一项新生事物，随着技术水平的上升和对新攻击的识别的增加，IDS需要不断的升级才能保证网络的安全性，而不同厂家之间的产品在升级周期、升级手段上均有很大差别。因此用户在购买时很难做出决定，同时维护时也往处于很被动的局面。

7.采用不恰当的自动反应所造成的风险。入侵检测系统可以很容易的与防火墙结合，当发现有攻击行为时，过滤掉所有来自攻击者的IP的数据。但是，不恰当的反应很容易带来新的问题，一个典型的例子便是：攻击者假冒大量不同的IP进行模拟攻击，而IDS系统自动配置防火墙将这些实际上并没有进行任何攻击的地址都过滤掉，于是形成了新的拒绝访问攻击（DOS）。
8.对IDS自身的攻击。
和其他系统一样，IDS本身也往往存在安全漏洞。如果查询bugtraq的邮件列表，诸如Axent NetProwler,NFR,ISS Realsecure等知名产品都有漏洞被发觉出来。若对IDS攻击成功，则直接导致其报警失灵，入侵者在其后所作的行为将无法被记录。（这也是为什么安全防卫必须多样化的原因之一。）

9.大量的误报和漏报使得发现问题的真正所在非常困难。
采用当前的技术及模型，完美的入侵检测系统无法实现。参考文献[1]中提到了若干种逃避IDS检测的办法，这种现象存在的主要原因是：
IDS必须清楚的了解所有操作系统网络协议的运作情况，甚至细节，才能准确的进行分析，否则[1]中提到的insertion,evasion的问题便无法解决。而不同操作系统之间，甚至同一操作系统的不同版本之间对协议处理的细节均有所不同。而力求全面则必然违背IDS高效工作的原则。

10.客观的评估与测试信息的缺乏。

11.交换式局域网造成网络数据流的可见性下降，同时更快的网络使数据的实时分析越发困难。
第五章 结论
未来的入侵检测系统将会结合其它网络管理软件，形成入侵检测、网络管理、网络监控三位一体的工具。强大的入侵检测软件的出现极大的方便了网络的管理，其实时报警为网络安全增加了又一道保障。尽管在技术上仍有许多未克服的问题，但正如攻击技术不断发展一样，入侵的检测也会不断更新、成熟。同时，正如本文一开始便提到的，网络安全需要纵深的、多样的防护。即使拥有当前最强大的入侵检测系统，如果不及时修补网络中的安全漏洞的话，安全也无从谈起。附录
A.常见攻击手段及其分析
1.Land (CERT CA-97.28):
描述：伪造IP地址，并将源、目的地址及端口设成相同值，某些路由器设备及一些操作系统遇到此种情况不能正常工作。
检测：检查TCP或UDP包的源、目的地址、端口信息是否相同即可发觉。
2.winnuke
描述：向139端口发出带有OOB标志（tcp urgent）的数据包,早期的95 ，及NT（如果没有相应的补丁）会立即当机。
检测：检查tcp的端口和urgent指针可以轻松发现此种攻击。

3.ping of death (CERT CA-96.01)
描述：正常的ping程序发出的数据段大小为32 （windows）或56（linux）bytes，此种攻击则使用特大的数据包，如65537 bytes.这种长度的数据包超出了单个IP包的大小(最多65536 bytes)，必须用分片处理，而许多早期的系统没有对这种情况进行处理，往往造成系统崩溃。

检测：检查icmp数据包的长度，超过一定范围的数据包一定是恶意的行为。

4.source routing
描述：IP选项（IP option）中有源路由功能，由发送方指定传输路径，但这种功能除进行调试外，几乎没有任何实际应用。而攻击者可以利用此功能来逃避网络中的一些检查点（如绕开防火墙）。
检测：查看IP选项（头长度大于20字节时）。
5.CGI 攻击:
描述：有许多cgi脚本文件存在安全漏洞（包括众多的asp bug），如果系统中有这种程序，入侵者可以轻易获得重要的文件，或通过缓冲区溢出造成更大危害。
已知的有漏洞的cgi程序非常多，如Count.cgi，phf,glimpse,handler, htmlscript,icat,info2www，nph-test-cgi,pfdispaly,phf,php,php.cgi test-cgi,webdist,webgais,websendmail等。
常见的asp 漏洞有：showcode.asp，及通过追加小数点或用%20代替小数点等漏洞阅读ASP文件源代码等漏洞。
检测：检查数据段中的字符串，可以对已知的漏洞进行察觉。

6.OS detection:
描述：在攻击发起之前，攻击者会尽可能的收集对方系统的信息,检测出对方操作系统的类型甚至版本尤为重要。nmap和queso等工具均可通过发送各种异常的数据包，并通过观察系统的不同反映来准确的鉴定远端的操作系统类型。详细的描述请参见参考文献[14]。
检测：因为其发出的数据包本身便比较特殊，通过观察此特征可检查此类行为。如queso利用了TCP中未定义的标志。nmap向端口发出只有FIN标记的TCP数据包.
7.扫描：
描述：包括端口扫描和icmp sweep，入侵者在攻击之前往往用此种办法收集远端系统的信息。
检测：端口扫描时往往大范围的检测端口的状态，在端口范围中往往有许多是关闭的，试图对这种端口建立连接往往是扫描行为。

8.syn flood (CERT CA-96.21)
描述：TCP连接的建立需三次握手，客户首先发SYN信息，服务器发回SYN/ACK，客户接到后再发回ACK信息，此时连接建立。若客户不发回ACK，则SERVER在timeout后处理其他连接。攻击者可假冒服务器端无法连接的地址向其发出SYN，服务器向这个假的IP发回SYN/ACK，但由于没有ACK发回来，服务器只能等TIMEOUT。大量的无法完成的建立连接请求会严重影响系统性能。

检测：如果某一地址短时间内发出大量的建立连接的请求且请求失败，则证明此IP被用来做Syn flood 攻击。（具体的源IP地址往往不能说明任何问题）
9.smurf (CERT CA-98.01)
描述：伪造被攻击者的IP向广播地址连续的发出icmp-echo包，当众多机器返回信息时（实际是返回了受害者），过量的信息会使被攻击者负载上升，甚至造成拒绝服务。

检测：如果在网络内检测到目标地址为广播地址的icmp包。证明内部有人发起了这种攻击（或者是被用作攻击，或者是内部人员所为）；如果icmp包的数量在短时间内上升许多(正常的ping程序每隔一秒发一个ICMP echo请求)，证明有人在利用这种方法攻击系统。
10．Teardrop(CERT CA-97.29)
描述：许多系统在处理分片组装时存在漏洞，发送异常的分片包会使系统运行异常，teardrop便是一个经典的利用这个漏洞的攻击程序。其原理如下（以linux为例）：
发送两个分片IP包，其中第二个IP包完全与第一在位置上重合。如下图：

在linux(2.0内核)中有以下处理:当发现有位置重合时（offset2<end1）,将offset向后调到end1（offset2=end1）, 然后更改len2的值：
len2=end2-offset2;
注意此时len2变成了一个小于零的值，在以后处理时若不加注意便会出现溢出。
检测：组装时检查len2的值便可，这样可以发现所有的变种（如newtear）。
11．Jolt2
描述：jolt2是2000年五月份出现的新的利用分片进行的攻击程序，几乎可以造成当前所有的windows平台（95,98,NT,2000）死机。原理是发送许多相同的分片包，且这些包的offset值(65520 bytes)与总长度(48 bytes)之和超出了单个IP包的长度限制（65536 bytes）。
检测：组装时检查这种超出IP包最长限度的情况。

以上只是举出了一些攻击的例子，我认为对于入侵检测而言，可将其分为四类：
1.检查单IP包首部（包括tcp、udp首部）即可发觉的攻击：如winnuke,ping of death，land,部分OS detection，source routing等。
2.检查单IP包，但同时要检查数据段信息才能发觉的攻击：如利用cgi漏洞，和大量的buffer overflow攻击。易于察觉，但最好设为选用，由用户在性能、安全两者之间进行折衷。
3.通过检测发生频率才能发觉的攻击：如扫描，syn flood,smurf等。需要维持一个额外的状态信息表，且因为结论是通过统计得来的，有误判漏判的可能。检测难度不是很大，但也要考虑对性能的影响。
4.利用分片进行的攻击：如teadrop,nestea，jolt等。此类攻击利用了分片组装算法的种种漏洞。若要检查此类漏洞，必须提前作组装尝试（在IP层接受或转发时，而不是在向上层发送时）。分片不光可用来进行攻击，还可用来逃避未对分片进行组装尝试的IDS的检测。

B.waRcher源程序
附在最后。

参考文献
[1]《Insertion, Evasion, and Denial of Service:Eluding Network Intrusion Detection》
Thomas H. Ptacek tqbf@
Timothy N. Newsham newsham@
Secure Networks, Inc.
January, 1998

[2]《An Introduction to Intrusion Detection& ASSESSMENT》
ICSA, Inc.

[3]《State of the Practice of Intrusion Detection Technologies》
Julia Allen， Alan Christie， William Fithen， John McHugh，Jed Pickel ，
Ed Stoner等
January 2000

[4]《IDS Buyer’s Guide》
ICSA lab

[5]《IDS FAQ》
Robert Graham (nids-faq@RobertG)
March 21, 2000

[6]《Network Based Intrusion Detection-A review of technologies》
DENMAC SYSTEMS, INC
NOVEMBER 1999

[7]《Next Generation Intrusion Detection in High-Speed Networks》
Network Associates

[8]《Intrusion Detection Message Exchange Requirements》
Internet-Draft Internet Engineering Task Force
Wood, M. Internet Security Systems
October, 1999

[9]《Intrusion Alert Protocol - IAP》
Internet Draft Internet Engineering Task Force
Gupta Hewlett-Packard
March 31, 2000

[10]《Building Into The Linux Network Layer 》
kossak <[e-mail]>, lifeline <[e-mail]>
Phrack Magazine Vol. 9 , Issue 55 , 09.09.99 , 12 of 19

[11]《Watcher》
hyperion 〈hyperion@〉
Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 11 of 15

[12]《Designing and Attacking Port Scan Detection Tools》
solar designer 〈solar@〉
Phrack Magazine Volume 8, Issue 53 July 8, 1998, article 13 of 15

[13]《The Art of Port Scanning》
Fyodor 〈fyodor@〉
Phr