日志及报警系统
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
--日志及报警子系统(logging/alerting subsystem)
入侵检测系统的输出结果系统的必要特征是实时性和多样性,前者指能够在检测到入侵行为的同时及时记录和报警,后者是指能够根据需求选择多种方式进行记录和报警。一个好的NIDS,更应该提供友好的输出界面或发声报警等等。
Snort是一个轻量级的NIDS,它的另外一个重要功能就是数据包记录器,所以该子系统主要提供了方式:
1.--fast model :采取TCPDUMP的格式记录信息
2. readable model :按照协议格式记录,易于用户查看。
3.alert to syslog: 向syslog发送报警信息。
4.alert to text file :以明文形式记录报警信息。
值得提出的是,snort考虑到用户需要高性能的时候,即网络数据流量非常大,可以将数据包信息进行压缩从而实习快速的报警。
3.-- 程序结构
1)--snort的整体结构
snort作为优秀的公开源代码的入侵检测系统范例,其整个程序结构清晰,构思巧妙,我们对于其版本1.6.3的源码进行了深入的分析。Snort共有64个c文件和h文件,首先介绍程序的整体结构,其流程图如下:
其中最为关键的函数就是ProcessPacket(),--其流程图如下:
2)--数据结构--
snort的主要数据结构就是几个链表,上述已经提及,snort组织规则库的巧妙之处就是按照规则的处理动作来划分成三个链表,其中每个链表又按照协议类型:TCP,IP和ICMP分成三个链表,所以所有的规则都会被分配到这个三个链表中。链表中的成员就是描述每条规则的结构——RuleTreeNode,该结构中的一个重要成员就是记录该规则的处理函数链表——RuleFpList,一条规则有时候需要调用多个处理函数来进行分析。该结构中的另外一个重要成员就是规则选项的结构,该结构同样包括该规则的选项信息以及其处理函数链表。值得提出的是,并不是每一条规则都分配一个RuleTreeNode结构,因为很多规则的选项前的头部分是相同的,只需要根据不同的规则选项链取不同的选项函数处理链表。基本整体的结构如图n所示,所有链表的初始化都是在捕获数据包前进行的。
除以上链表外,snort还定义了预处理、输出的关键字和处理函数链表,设计链表的主要意图是为了实现插件的思想,即用户何以根据需求添加删除预处理的功能模块。其只要的数据结构如下:
typedef struct _PreprocessKeywordNode
{
char *keyword;
void (*func)(char *);
} PreprocessKeywordNode;
// 预处理关键字信息结构。
typedef struct _PreprocessKeywordList
{
PreprocessKeywordNode entry;
struct _PreprocessKeywordList *next;
} PreprocessKeywordList;
file://预处理关键字链表。
typedef struct _PreprocessFuncNode
{
void (*func)(Packet *);
struct _PreprocessFuncNode *next;
} PreprocessFuncNode;
file://预处理函数链表。
所有链表的初始化都是在捕获数据包前进行初始化的,一旦链表都已建立完毕,开始捕数据包,每收到一个数据包都会现首先调用预处理程序链表中的函数进行处理后,其次按照默认地顺序遍历AlertList,PassList和LogList三个链表。遍历时首先根据数据包的协议类型定位规则链表,其次调用递归函数进行规则的逐一匹配,即首先匹配规则头,若匹配则继续递归匹配规则选项,若不匹配,直接匹配下一条规则。为了加快遍历的速度,snort在规则选项中的”content”内容匹配时调用了Boyer-Moore算法。
4.--改进
1.--背景
我们认为snort已经具备了NIDS的基本功能,由于它本身定位在一个轻量级的入侵检测工具,尽管与商业的入侵检测工具比起来,它的规则语言略显简陋,在报警方式和图形化使用界面上也显露出不足之处,但是程序的整体结构清晰,规则语言简单实用并提供插件的功能支持,用户可以添加自己的检测规则和处理函数,这对于规则库的及时更新有着极为现实的意义。
通过分析,与商业的NIDS相比,SNORT 1.6.3没有设置对IP 分片包的处理功能,即对于例如“Teardrop”和“Ping of Death”两类利用非法IP分片包进行的攻击无法检测:
?--teadrop——该攻击是针对很多操作系统的TCP/IP协议栈没有正确处理已分段的IP包的重组。其特征是发送2个或更多特别的分段IP数据报。第一个包是偏移量为0的段,数据段(分段长度)字节是N,并设置了MF位,第二个包是最后一个分段(MF==0),但它的偏移量小于N,所有造成两个分段重叠了。为了重组这些包,有弱点的系统就会在TCP/IP栈中分配非常大的空间,因此导致目标系统因为内存耗尽而停止响应或者重启。
?--Ping of Death——该攻击的特正是向攻击目标发送大量的ICMP分片数据包,当这些数据包重组时其数据段已经大于65535个字节,系统会因为无法处理这种数据包而造成拒绝服务或者重启。
?--
2.--方案
3.--实现