谈谈IDS的检测与规则

2009-12-14 02:11| 发布者: admin| 查看: 12| 评论: 0|原作者: 仙之剑缘

本文粗略和基础地对IDS的检测过程和规则作了介绍，并以Snort为实例，同时介绍如何用逆向推理的方法来判断IDS的规则定义。

一、简介
在网络安全越来越受到各种各样人的重视之后，入侵检测（Intrusion Detection）
也得到了很多发展。跟随防火墙，入侵检测系统（IDS）目前成为了又一个火热的产品。但是，入侵检测技术，包括主动防御技术都不成熟，因此，各种IDS的检测性能参差不齐。
在技术还没有成熟的环境下，各种思想也得到发挥。比如基于模型推理检测技术、神经网络的检测、专家系统等等，这些技术都努力让入侵检测更有效，更智能，但是，目前绝大多数商业的IDS 都还是使用跟开放的snort一样的最简单包模式匹配技术。

二、CIDF模型
典型的CIDF 模型
Common Intrusion Detection Framework (CIDF)阐述了一个入侵检测系统（IDS）的通用模型，是当前IDS 的典型结构。它将一个入侵检测系统分为以下组件：
n 事件产生器（Event generators）
n 事件分析器（Event analyzers）
n 响应单元（Response units ）
n 事件数据库（Event databases ）
CIDF 将入侵检测系统需要分析的数据统称为事件（event）,它可以是基于网络的入侵检测系统中网络中的数据包，也可以是基于主机的入侵检测系统从系统日志等其他途径得到的信息。它也对于各部件之间的信息传递格式、通信方法和标准API 进行了标准化。事件产生器的目的是从整个计算环境中获得事件，并向系统的其他部分提供此事件。事件分析器分析得到的数据，并产生分析结果。响应单元则是对分析结果作出作出反应的功能单元，它可以作出切断连接、改变文件属性等强烈反应,甚至发动对攻击者的反击，也可以只是简单的报警。事件数据库是存放各种中间和最终数据的地方的统称，它可以是复杂的数据库，
也可以是简单的文本文件。
在CIDF模型中的四个组件中，应该说事件数据库是更重要的核心。事件产生器、分析器的不同只是采集和分析的效率，比如，很多厂商的IDS 都采用更多的协议分析模块来加强数据的分析能力。而事件库则很明显地体现了IDS的检测能力（不是性能），也同检测引擎有密切关系，因为通常的误报和漏报都同事件定义明确相关。（当然，检测引擎本身的性能也很重要）

三、模式匹配
由于IDS 目前还处于发展期，规范标准等都相对缺乏，因此，就出现了各种各样的IDS测试，而实际上，这些测试都在很大程度上来测试IDS 的事件库。事实上，为通过这些测试，IDS厂商也都会根据测试调整自身的事件集。
通过事件的定义，我们可以分析IDS对事件的检测能力，也可以判断IDS厂商对入侵技术的理解实力，从另一方面，也可以来发展IDS的躲避技术，或者开发让IDS发疯的垃圾事件产生器（如stick）。正因为这两方面的原因，多数商业的IDS都不开放自身的事件定义，即便某些IDS的事件就来自开放的snort。
其实，目前的IDS 不管厂商如何宣传，它们产生事件报警的本质都是模式匹配，所谓的协议分析（有的称为协议解析）也就是用来提高匹配的效率，或者有的提供命令解释器来模拟某些协议的命令语法，这样来提高IDS的反躲避能力。
IDS的模式匹配即通过对数据包的分析，并匹配自身的规则库，如果能够匹配就产生事件报警或者保留准备更多相关情况的分析，否则就丢弃（即便是属于攻击）。模式匹配并不仅仅局限于字符串的匹配，包括下面的匹配类型：
n 协议匹配。通过协议分析模块，将数据包按照协议分析的结果对协议相应的部分进行检测。比如，TCP包的标志位，协议异常等。
这是snort中一条事件定义：alert tcp $EXTERNAL_NET any -> $HOME_NET
any (msg:"SCAN NULL";flags:0; seq:0; ack:0; reference:arachnids,4;
classtype:attempted-recon; sid:623; rev:1;)其中就对TCP 的flags、
seq、ack进行了协议位置的匹配。
协议匹配需要对特定协议进行分析，Snort对IP/TCP/UDP/ICMP进行了分析，
但是没有对应用协议分析。高层的应用协议分析，可以显著地提高匹配的效率，比如对TDS 协议的分析能够准确地定位账号和密码位置。
n 字符串匹配。目前这是大多数IDS 最主要的匹配方式，事件定义者根据某个攻击的数据包或者攻击的原因，提取其中的数据包字符串特征。通常IDS 经过协议分析后，进行字符串的匹配。
比如：Snort 中的一条事件定义，alert tcp $EXTERNAL_NET any ->
$HTTP_SERVERS $HTTP_PORTS (msg:"WEB-ATTACKS ps command attempt";
flow:to_server, established; uricontent:"/bin/ps"; nocase;
sid:1328; classtype:web-application-attack; rev:4;)，该事件中要进
行匹配的字符串就是"/bin/ps"。
字符串匹配主要就是算法问题，因为IDS 的规则多数属于字符串匹配，因此优秀的字符串匹配算法也能够显著提高IDS的效率，比如Boyer-Moore、Aho-Corasick、
Set-wise Boyer-Moore 算法。
n 大小匹配，或者长度匹配。多数情况下，这也应该属于字符串匹配的一种，不过，这种匹配方式对数据包中某段数据的长度而不是对具体的字符串进行匹配。比如，通过数据长度限制来对缓冲区溢出攻击进行检测。
比如：alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:"WEB-IIS ISAPI .ida attempt"; uricontent:".ida?"; nocase;
dsize:>239; flow:to_server,established; reference:arachnids,552;
classtype:web-application-attack; reference:bugtraq,1065;
reference:cve,CAN-2000-0071; sid:1243; rev:6;)
其中的关键字dsize 就是对数据包的负载进行匹配，如果请求的命令总长度大于239，那么就检测出一条.ida溢出企图的事件。
n 累积匹配，或者量匹配。通过对某些事件出现的量（次数或者单位时间次数）来产生新的事件，比如，某个IP在1分钟内报出了100条CGI 事件，那么就属于一次CGI扫描事件。
n 逻辑匹配，或者是集合匹配。一些有更强事件检测能力的IDS，通过对不同类型的事件组合来进行判断，从而获得新的事件。少数IDS 对多种事件的组合来构成逻辑推理，增强检测的智能。
累积匹配和逻辑匹配都是建立在对初级事件检测基础上进行的，都是通过将原始事件的某些组合来构成新的事件，因此不可能出现在老式IDS 架构中，除非其中增加对事件的多次分析过程。

四、Snort的检测过程
下面分析Snort 的1.9 的数据包检测处理过程，并以次来了解现在主流IDS 通过软件方法是如何提高性能的。
Snort 1.9.0 src,下面是snort 1.9.0 程序对数据包的检测处理大致过程:
程序初始化InitSetPktProcessors，设定包处理器
void *InterfaceThread(void *arg)
通过pcap_loop 获得数据包Packet *p
对数据包进行预处理int Preprocess(Packet * p)
进入检测函数int Detect(Packet * p)
选择规则树准备开始分类作匹配EvalPacket（）
检查协议switch(p->iph->ip_proto)
case IPPROTO_TCP:
case IPPROTO_UDP:
case IPPROTO_ICMP:
default:
设置RuleTreeNode *rtn_idx
设置是否有端口，如果有，那么根据端口检查
先从头部进行匹配并选择Rule Tree Node（RTN），
int EvalHeader(RuleTreeNode*, Packet*,int)
从源代码分析的过程，snort将规则集组成树形结构RTN以及RTN下的OTN。这个树形结构基本就是这样的：
程序先进行的就是选择规则树的工作，即在由RTN 构成的链中确定一个匹配的RTN，RTN是对IP、ICMP、TCP、UDP以及可能用到的端口进行的分类，一个RTN包含类似下面的内容：
当选定一个RTN之后，就从该节点向下对OTN进行匹配，OTN是规则中更详细的匹配内容，一个RTN 基本包含类似下面的内容：

RTN—RTN—RTN—RTN
OTN OTN OTN OTN
OTN OTN OTN OTN
OTN OTN

然后对RT树下Optional Tree Node (OTN)作进一步匹配
int EvalOpts(OptTreeNode * List, Packet * p)
Src ANY
Dst HOME_NET
Protocol TCP
Src_P ANY
Dst_P 80
flag:A
content:".ida"

Snort 主要进行的是协议匹配、字符串匹配和长度匹配，而检测引擎中没有两次或者多次匹配的过程，也就是累计匹配和逻辑匹配，因此它不能检测分布事件，不能确定哪些事件是成功的，也不能检测流量异常，而只能通过端口协议字符串等来检测那些具有字符串数据特征的特定拒绝服务攻击工具的事件，这可以从snort 的DDOS 规则集看得出来。当然Portscan和Stream4等预处理器的增加为snort在累计匹配和逻辑匹配上有一些表现，比如，Portscan预处理器可以跟踪端口扫描事件的速率问题。
单从Snort 提供的规则也可以得到上面的结果，因为规则中所体现的基本都是对IP、ICMP、TCP、UDP 这样的三、四层上的协议进行了解析，而对更上面的协议，比如第七层的应用协议等基本没有作协议分析（除了数据的Request 部分），这些规则中也主要进行的前三种方式的单包匹配。
当然这里的重点不是在匹配算法上，而更看重整个检测的结构和过程。首先能够看到的问题就是snort 的规则树形结构过于简单，也就造成可能某些RTN下的OTN链比较庞大；
没有对高层协议分析也是一个大问题，因为，协议分析可以更有效地定位匹配位置，加快匹配速率。因此，现在很多IDS 将规则树更平坦，尽量让深度和宽度不失调，同时进行高层协议分析，这一代的IDS结构也就基本如此了。同时，有些IDS 采用多层引擎的方式，来实现和加强累计匹配和逻辑匹配的检测能力。其实现在Snort 的结构发展也基本是对这些问题的解决和发展。
五、关于规则定义
因为负责任的事件定义需要对入侵进行详细分析，这些入侵的分析基本结果都很相近，比如溢出攻击的长度，某种攻击中的数据特征等，因此，可能各个厂商的事件大同小异。但是，可能就是这些小小的差别就能看出不少端倪。
虽然多数商业IDS 的事件定义是不公开的，但是可以通过构造类似特征来猜测，并逆向推理真实的事件定义内容。因为IDS都总是使用上面介绍的匹配方法来作检测的。
逆向推理技术，是建立在对IDS规则定义和对攻击的熟悉基础上，具体步骤是：
1、通过真实的攻击获得报警，并捕获相关的数据；
2、通过数据包重放，缩小被报警的数据包范围，并确定触发事件的数据包；
3、假设我们就是IDS的事件定义者，会怎么定义事件才能够有效；
4、在2、3的基础上构造数据包，通过不断调整数据包的内容；
5、再次触发事件；
6、获得大致的真实规则定义情况。
通常的IDS 规则定义都是有规律可循的，下面举的例子仅仅作为引子。
比如，木马规则其实是一种非常头痛的事情，因为现在的木马通常都是可以改变端口的，可能有些就根本不还有很特别的字符串特征。最粗劣的木马规则是仅仅以某种木马使用的端口来作特征。下面以Netbus 为例。
第一种规则定义：
alert tcp $EXTERNAL_NET any -> $HOME_NET 12345 (msg:"BACKDOOR
netbus backdoor"; flow:to_server,established;)
该规则仅仅指定目的端口为TCP 12345 的即为netbus 后门，这样即便是Telnet
HOST 12345 也会触发该事件，极大地增加了误报的可能。
第二种规则定义：
而这样的规则则相对来说好得多，它同时对端口和字符特征进行匹配：
alert tcp $EXTERNAL_NET any -> $HOME_NET 12345 (msg:"BACKDOOR
netbus getinfo"; flow:to_server,established;
content:"GetInfo|0d|";)
可能多数IDS 对该事件都是这样定义，但是，这条事件也存在很大的局限，因为，如果黑客将木马的通讯端口改为TCP 1234而不是用默认的TCP 12345，那么该规则也就实效了。
第三种规则定义：
由于端口并不是肯定的共性，因此，可能存在这样的定义，它只进行字符串匹配，因为，该字符串是所有Netbus Getinfo 的特征。
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"BACKDOOR netbus
getinfo"; flow:to_server,established; content:"GetInfo|0d|";)
但是这种定义方式也会提高误报率，因为只要包含"GetInfo|0d|"就可以触发该事件。
要逆向推理判断IDS是如何定义该规则的，可以作下面的测试：
n 如果仅仅连接TCP 12345 就触发事件，那么就是第一种定义；
(结论：IDS比较白痴，实在不感恭维)
n 如果对TCP 12345端口发送"GetInfo|0d|"，触发事件，那么就是第二种定义
方法；
(结论：IDS趋向于稳重和传统，但针对性有限)
n 如果对非TCP 12345端口的其他端口（最好不对已分配了的端口，比如21，80
等）发送"GetInfo|0d|"可以触发事件，则采用的是第三种规则定义；
（结论：IDS显得比较自信和大胆，但过于大胆）
从这个例子，也可以得出多数TCP规则定义的特点：
n 以端口为特征
n 以标志位或者协议的字段为特征
n 以某个数据段为字符串特征

通过对这三种特征的组合构成规则的定义。其中字符串特征同IDS 引擎有关，比如，是否能指定字符串匹配的起始或终止位置等。
Reference:
1. 《Increasing Performance in High Speed NIDS - A look at Snort’sInternals》 By Neil Desai. [2002-3]
2. 《Fast Content-Based Packet Handling for Intrusion Detection》ByMike Fisky, George Varghese. [2001-5]

收藏分享邀请

		自动登录	找回密码
密码			注册

谈谈IDS的检测与规则

最新评论

相关分类

下级分类