入侵检测系统简介
当越来越多的公司将其核心业务向互联网转移的时候，网络安全作为一个无法回避的问题呈现在人们面前。传统上，公司一般采用防火墙作为安全的第一道防线。而随着攻击者知识的日趋成熟，攻击工具与手法的日趋复杂多样，单纯的防火墙策略已经无法满足对安全高度敏感的部门的需要，网络的防卫必须采用一种纵深的、多样的手段。与此同时，当今的网络环境也变得越来越复杂，各式各样的复杂的设备，需要不断升级、补漏的系统使得网络管理员的工作不断加重，不经意的疏忽便有可能造成安全的重大隐患。在这种环境下，入侵检测系统成为了安全市场上新的热点，不仅愈来愈多的受到人们的关注，而且已经开始在各种不同的环境中发挥其关键作用。
本文中的“入侵”（Intrusion）是个广义的概念，不仅包括被发起攻击的人（如恶意的黑客）取得超出合法范围的系统控制权，也包括收集漏洞信息，造成拒绝访问（Denial of Service）等对计算机系统造成危害的行为。
入侵检测（Intrusion Detection），顾名思义，便是对入侵行为的发觉。它通过对计算机网络或计算机系统中得若干关键点收集信息并对其进行分析，从中发现网络或系统中是否有违反安全策略的行为和被攻击的迹象。进行入侵检测的软件与硬件的组合便是入侵检测系统（Intrusion Detection sys tem,简称IDS）。与其他安全产品不同的是，入侵检测系统需要更多的智能，它必须可以将得到的数据进行分析，并得出有用的结果。一个合格的入侵检测系统能大大的简化管理员的工作，保证网络安全的运行。
具体说来，入侵检测系统的主要功能有：
a.监测并分析用户和系统的活动；
b.核查系统配置和漏洞；
c.评估系统关键资源和数据文件的完整性；
d.识别已知的攻击行为；
e.统计分析异常行为；
f.操作系统日志管理，并识别违反安全策略的用户活动。
由于入侵检测系统的市场在近几年中飞速发展，许多公司投入到这一领域上来。ISS、axent、NFR、cisco等公司都推出了自己相应的产品（国内目前还没有成熟的产品出现）。但就目前而言，入侵检测系统还缺乏相应的标准。目前，试图对IDS进行标准化的工作有两个组织：IETF的Intrusion Detection Working Group (idwg)和Common Intrusion Detection Framework (CIDF)，但进展非常缓慢，尚没有被广泛接收的标准出台。
入侵检测系统模型
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）,它可以是网络中的数据包，也可以是从系统日志等其他途径得到的信息。
事件产生器的目的是从整个计算环境中获得事件，并向系统的其他部分提供此事件。事件分析器分析得到的数据，并产生分析结果。响应单元则是对分析结果作出作出反应的功能单元，它可以作出切断连接、改变文件属性等强烈反应，也可以只是简单的报警。事件数据库是存放各种中间和最终数据的地方的统称，它可以是复杂的数据库，也可以是简单的文本文件。
在这个模型中，前三者以程序的形式出现，而最后一个则往往是文件或数据流的形式。
在其他文章中，经常用数据采集部分、分析部分和控制台部分来分别代替事件产生器、事件分析器和响应单元这些术语。且常用日志来简单的指代事件数据库。如不特别指明，本文中两套术语意义相同。
IDS分类
一般来说，入侵检测系统可分为主机型和网络型。
主机型入侵检测系统往往以系统日志、应用程序日志等作为数据源，当然也可以通过其他手段（如监督系统调用）从所在的主机收集信息进行分析。主机型入侵检测系统保护的一般是所在的系统。
网络型入侵检测系统的数据源则是网络上的数据包。往往将一台机子的网卡设于混杂模式（promisc mode）,监听所有本网段内的数据包并进行判断。一般网络型入侵检测系统担负着保护整个网段的任务。
不难看出，网络型IDS的优点主要是简便：一个网段上只需安装一个或几个这样的系统，便可以监测整个网段的情况。且由于往往分出单独的计算机做这种应用，不会给运行关键业务的主机带来负载上的增加。但由于现在网络的日趋复杂和高速网络的普及，这种结构正受到越来越大的挑战。一个典型的例子便是交换式以太网。
而尽管主机型IDS的缺点显而易见：必须为不同平台开发不同的程序、增加系统负荷、所需安装数量众多等，但是内在结构却没有任何束缚，同时可以利用操作系统本身提供的功能、并结合异常分析，更准确的报告攻击行为。《Next Generation Intrusion Detection in High-Speed Networks》对此做了描述，感兴趣的读者可参看。
入侵检测系统的几个部件往往位于不同的主机上。一般来说会有三台机器，分别运行事件产生器、事件分析器和响应单元。HereLine将前两者合在了一起，因此只需两台。在安装IDS的时候，关键是选择数据采集部分所在的位置，因为它决定了“事件”的可见度。
对于主机型IDS，其数据采集部分当然位于其所监测的主机上。
对于网络型IDS，其数据采集部分则有多种可能：
（1）如果网段用总线式的集线器相连，则可将其简单的接在集线器的一个端口上即可；
（2）对于交换式以太网交换机，问题则会变得复杂。由于交换机不采用共享媒质的办法，传统的采用一个sniffer来监听整个子网的办法不再可行。可解决的办法有：
a.交换机的核心芯片上一般有一个用于调试的端口（span port），任何其他端口的进出信息都可从此得到。如果交换机厂商把此端口开放出来，用户可将IDS系统接到此端口上。
优点：无需改变IDS体系结构。
缺点：采用此端口会降低交换机性能。
b.把入侵检测系统放在交换机内部或防火墙内部等数据流的关键入口、出口。
优点：可得到几乎所有关键数据。
缺点：必须与其他厂商紧密合作，且会降低网络性能。
c.采用分接器（Tap），将其接在所有要监测的线路上。
优点：再不降低网络性能的前提下收集了所需的信息。
缺点：必须购买额外的设备(Tap)；若所保护的资源众多，IDS必须配备众多网络接口。
d.可能唯一在理论上没有限制的办法就是采用主机型IDS。
通信协议
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的具体实现，请参看 《Intrusion Alert Protocol - IAP》，其中给出了非常详尽的说明。这里我们主要讨论一下设计一个入侵检测系统通信协议时应考虑的问题：
1．分析系统与控制系统之间传输的信息是非常重要的信息，因此必须要保持数据的真实性和完整性。必须有一定的机制进行通信双方的身份验证和保密传输（同时防止主动和被动攻击）。
2. 通信的双方均有可能因异常情况而导致通信中断，IDS系统必须有额外措施保证系统正常工作。
入侵检测技术
对各种事件进行分析，从中发现违反安全策略的行为是入侵检测系统的核心功能。从技术上，入侵检测分为两类：一种基于标志（signature-based），另一种基于异常情况(anomaly-based)。
对于基于标识的检测技术来说，首先要定义违背安全策略的事件的特征，如网络数据包的某些头信息。检测主要判别这类特征是否在所收集到的数据中出现。此方法非常类似杀毒软件。
而基于异常的检测技术则是先定义一组系统“正常”情况的数值，如CPU利用率、内存利用率、文件校验和等（这类数据可以人为定义，也可以通过观察系统、并用统计的办法得出），然后将系统运行时的数值与所定义的“正常”情况比较，得出是否有被攻击的迹象。这种检测方式的核心在于如何定义所谓的“正常”情况。
两种检测技术的方法、所得出的结论有非常大的差异。基于异常的检测技术的核心是维护一个知识库。对于已知得攻击，它可以详细、准确的报告报告出攻击类型，但是对未知攻击却效果有限，而且知识库必须不断更新。基于异常的检测技术则无法准确判别出攻击的手法，但它可以（至少在理论上可以）判别更广范、甚至未发觉的攻击。
如果条件允许，两者结合的检测会达到更好的效果。
linux下的实现
系统框架
HereLine是一个在linux下运行的基于标识检测的网络IDS。从逻辑上分为数据采集、数据分析和结果显示三部分，符合CIDF的规范。
从实现结构上看，HereLine分成三个应用程序，它们分别是：
1．数据收集及分析程序(watcher) ；2.告警信息收集程序(listener)；3.告警信息显示程序(console)。watcher是数据采集和数据分析的合体；listener接收watcher发出的告警信息，并将接到的信息存储为日志；console为管理员提供了更友好的观察日志的图形界面。
同大多数商业IDS一样，HereLine采用了分布式的结构。运行HereLine建议采用两台PC机，一台运行watcher,另一台运行listener和console.
与其他同类程序相比，HereLine的优点主要有：
1.提供了完整的框架，可以灵活的应用于各种环境并扩充；
2.采用数据分析与告警程序分离，便于在大规模的网络环境下集中管理；
3.已经实现了对分片的处理，解决了利用分片逃避检查的问题；
4.数据分析部分不完全依赖已有攻击程序，而是分析其核心特征以察觉其变种攻击；但同时依靠已有攻击程序的细节来评估判别的准确性。以上设计增加了告警的可靠性。
各部分的实现流程及重要问题说明
数据采集部分
watcher采用了linux2.2内核中提供的PF_PACKET类型的socket（并未采用libpcap提供的API接口） ,直接从链路层获取数据帧。（直接采用操作系统提供的接口主要是考虑高效性，但为了将来的移植问题，以后仍然可能会改为使用libpcap库提供的函数接口。）根据linux的要求，建立这样的一个socket需要root权限,即uid=0。从packet socket读到的数据是链路层格式的数据，但经过处理（socket函数的第二个参量SOCK_DGRAM表示要去掉第二层的数据头，第三个参量ETH_P_IP表示只接收ipv4的数据包）后，缓冲区内的内容是个完整的IP包（未经任何其它处理）。分析工作交由数据分析程序去做。
数据采集部分还做了一项工作就是将网卡置于混杂模式，这样可以监听到整个网段的数据。
HereLine的这种实现，实际是通过socket将数据拷贝到应用层。这种结构比较灵活与安全（应用程序崩溃不会导致系统崩溃），但频繁的应用态与核心态的转换浪费了CPU。还有一种办法就是采用linux中的模组（modular）的办法，将IDS作为内核的一部分。《Building Into The Linux Network Layer 》提供了一个内核中的sniffer的框架。可以利用其结构实现嵌入内核的、更加高效的入侵检测系统。HereLine可以很容易的转移到这种方式，但考虑到其对操作系统稳定性的影响和调试的难度，目前未采用。
需要指出的是，watcher只是监听数据包，并不参与操作系统协议栈的处理。如果操作系统被攻击导致拒绝服务，watcher也将无法运行。因此，首先要保证起所运行的系统是安全的。有些商业入侵检测系统（如NFR）将数据采集部分放在专门的、经过改进的、高度安全的系统之上，以保证IDS这一系统中的重要程序正常工作。对于HereLine本身来说，建议采用增加了stackguard功能的gcc编译器，减少潜在的缓冲区溢出（buffer overflow）漏洞。
watcher将数据读到缓冲区之后，首先将其封装为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中定义了指向协议头的指针，子程序可根据这些指针快速的定位数据头位置。
数据分析
数据分析部分事实上与数据采集部分作为一个进程(watcher)存在,主要是为了简化程序设计的复杂性。在得到数据帧之后，watcher模拟操作系统的TCP/IP堆栈对数据进行处理并与已知攻击行为的特征进行比较，从中发现异常行为，并向控制台告警。
在分析的过程中，首先对数据包进行协议分析、过滤，根据协议、端口等信息将数据包送到不同的检测流程（如只有HTTP协议的包才进行CGI检查），这样使检查的过程尽量缩短，提高了程序的工作效率。当进入相应的检测流程后，则按照线性的顺序工作。
数据分析部分设计为模拟TCP/IP堆栈的流程处理数据包，从中发现异常行为（如分片重合、异常标志等）。这样主要是为了减少误报与漏报，从攻击的核心特征发现它，而不是象许多其他系统那样，只检查攻击包的表面特征。HereLine中包括了IP分片处理，包括了TCP状态转换。通过这种结构，可以准确的判别诸如teardrop等碎片攻击的各种变种。
对一些常见攻击手法的描述和处理方法见附录1。
HereLine目前可以处理以下攻击：
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
若识别出有异常行为，则向控制台告警（采用类似IAP的协议）。HereLine此时分出一个单独的进程处理与控制台的交互，而原进程则继续处理新的数据包。
控制台
控制台部分分为两个程序，listener和console。 listener绑定6543端口（目前似乎没有和其他程序冲突），接收从分析程序发出的分析结果和其他信息，并根据其类型转化到不同文件存储。此时的文件为用户可读。其实watcher和listener两者便已经形成了一个完整的IDS。
console为一用GTK+图形库编制的一个窗口程序，目的主要是给用户一个更方便友好的界面来浏览警告信息。
因为listener已经将报警信息以明文格式存储，因此也可以采用将其转换成HTML文件，用浏览器查看。当然也可以采用windows应用程序。因HereLine不是一个商业软件，对界面的考虑并不多。
HereLine的日志采用了类似UNIX系统日志的格式，包括time（事件发生时间）,host（被攻击的主机名或IP）,watcher（发现此攻击的watcher的名字或IP）,event（攻击的具体描述）这些项。各项之间用空格分开，每个记录用一行，每项之中不能有空格，若有，用下划线代替（以上语法约定均是为了方便处理）。下面是一个例子：
Feb_27_20:30:31 172.18.172.18 watcher01 Port_Scan_From_evil.com
Feb_27_20:31:07 web_server watcher02 OS_fingerprint_from_12.18.1.1
在设计日志格式时我曾经考虑过许多方案，主要是想分出更多的项，如记录两端的端口信息，加入可信度和计数，这样在以后可以很方便的排序和查找，但最终还是采用了这种简单的格式。其原因主要是各种不同的事件需要记录的项千差万别，唯一又共性的便是time,host,watcher这三项，其余之处可都放到event项中去说明。我可以举一个例子：攻击的源地址似乎应该单列出来，但是现在假冒源地址进行的攻击实在太普遍了，land攻击便将源地址设为与被攻击者相同，此时记录源地址没有任何意义；syn flood往往随机的生成源地址，如果因源地址不同而单列出一个记录的话，只会使日志迅速膨胀，而其记录的内容与只简单记录发生了syn flood没有多大区别。
设计日志时还有一大问题便是连续不断的相同攻击会产生大量相同的日志，HereLine对此采取的办法也与UNIX的syslogd相同：设立一专门的计数器count，每当有新的事件出现的时候先比较是否与上一事件重名，若不重名则马上记录（保证报警的迅速），否则对计数器加一，直到有不重名的事件发生才真正写日志，此时记录的event项的内容为：
The_last_messages_repeated_$count_times
除生成日志告警外，系统不采取任何其他行动，是否采取相应的措施由系统管理员自行决定。
由于时间关系，程序完成的不是很完善，有很多跟理想的有一些差别：
（1）无法灵活的升级：所有的入侵检测部分都以编译后的程序的形式提供（可以高效处理,但同时失去了灵活性）用户必须完全或部分更新原有程序才能实现升级。以后应该采用类似脚本语言的办法。
（2）所处理的攻击数还需有很大的提高。
（3）控制台程序尚没有加入对采集分析程序的控制，也没有加入对分析结果作进一步处理的功能（如排序、过滤、查找等）。
（4）磁盘定额：对日志过大以后的情况尚没有人为规定，不过目前可以用linux自身的quato功能实现（写满一定磁盘定额后覆盖）。
（5）集中控制:控制台应该加入配置watcher的功能（如暂停其某项检测）。
（6）无法动态的载入和卸载检测规则。（很快会加入）
（7）未采用IAP：现在watcher与listener的通信仍采用明文传输，这种局面急需改变。但IAP设计的过于复杂，且是否会成为标准尚不明朗，所以暂时可能先设计一个简单点的协议来实现加密和验证。
IDS系统面临的一个矛盾便是性能与功能的折衷。对数据进行全面复杂的检验，对实时性的要求构成了很大的挑战。
由于仅仅进行了开发，没有对HereLine进行性能测试，对HereLine而言，其可能影响性能的有三个地方：内核到应用层的转换（涉及数据拷贝）；数据分析（大量的数据匹配操作）；记录日志（IO操作）。