论坛: 黑客进阶 标题: 入侵检测专题 复制本贴地址    
作者: quest [quest]    版主   登录
本专题主要讨论关于入侵检测的一些内容:包括简单的入侵检测名词解释、复杂到入侵检测系统开发,都可以进行讨论。为了保证本专题的质量和为了让更多阅读本帖的人能方便些,故对此帖进行销定,各位有好文章可以把文章post到quest@hainan.net,不便之处还请见谅。



―――――――――――――――――――――――――――――――――――


    一、什么是入侵检测      
    二、入侵检测的分类          
    三、入侵检测的方法    
    三、入侵检测的方法   

[此贴被 TomyChen(quest) 在 05月22日22时55分 编辑过]

地主 发表时间: 05/05 10:30

回复: quest [quest]   版主   登录
//先骂一下netdemon:置顶帖不能回帖,做专题不好做。这个问题一定要改,置顶帖无法修改这个也是个问题

PDR名词解释
PDR即:Protection(保护)、Detectioon(检测)、Response(响应)是入侵检测的一种模型最早是由ISS公司提出的,后来还出现了很多“变种”,包括ISS公司自己也将其改为PADIMEE,即:Policy(策略)、Assessment(评估)、Design(设计)、Implementation(执行)、Management(管理)、Emergency Response(紧急响应)、Education(教育)等七个方面。
这里我们主要就PDR做一个简单的介绍。
1. 保护
保护是安全的第一步(书上都这么说,我觉得也是)。
・安全规则的制定:在安全策略的规则的基础上再做细则。
・系统充安全的配置:针对现有的网络环境的系统配置,安装各种必要的补丁,提高安全策  略级别。
・安全措施的采用:安装防火墙(软/硬)。
2. 检测
采取各式各样的安全防护措施并不意味着网络系统的安全性就得到了100%的保障,网络状况是变化无常的,昨日刚刚提供的补丁,可能今天就会被发现该补丁存在漏洞。面临这样的问题更多的是要采取有效的手段对网络进行实时监控。
・异常临视:系统发生不正常情况。如:服务停止,无法正常登陆,服务状态不稳定等。
・模式发现:对已知攻击的模式进行发现。
3.响应
在发现了攻击企图或者攻击之后,需要系统及时地进行反应:
・报告:无论系统的自动化程度多高,都需要管理员知道是否有入侵事件发生。
・记录:必须将所有的情况记录下来,包括入侵的各个细节以及系统的反映(尽最大可能)。
・反应:进行相应的处理以阻止进一步的入侵。
・恢复:清除入侵造成的影响,使系统正常运行。
响应所包含的告与取证等非技术因素删除,实际上的响应就意味着进一步防护。





B1层 发表时间: 05/05 10:34

回复: quest [quest]   版主   登录
了解你的敌人―统计    [本文出自安全焦点:xfocus.net]

Honeynet Project http://project.honeynet.org/ http://www.xfocus.net/honeynet/ 
Last Modified: 22 July, 2001 
在过去的几年里,Honeynet Project已经收集和归档了backhat的活动信息,我们尽我们最大的能力来记录和捕获对Honeynet每一个探测,攻击,和使用。这些原始的数据有很高价值。我们重点会放在两个部分,第一,我们打算演示Blackhat团体是怎样活动的。不管你是谁,你是不安全的,我们的目标是让你认识到这些威胁的存在。其二,为了对一些早期警告和预报内容的进行测试,通过鉴别方法和倾向,可能预测在攻击发生之前的攻击和进行一定程度的对抗。我们使用Honeynet Project采集到的数据测试这种理论。 

The Collected Data
Honeynet Project维护着8个高度控制和完全监视的网络,我们收集和归档了2000年4月到2001年2月这段时期中网络的每一个攻击,Honeynet有8个IP地址组成,使用本地ISP提供的单一ISDN连接,这种连接类型类似与大多数家庭用户或者小型商业用户。实际上,Honeynet位于其中一Project成员空余的卧室中。在那段时期,Honeynet中存在3个系统,其中包括如下:Solaris Sparc, WinNT, Win98, 和 Linux Red Hat操作系统。 

Honeynet网络是用来捕获数据的网络,是一些使用普通的网络操作系统,如:Red Hat Linux 或者 Windows NT并在默认下配置的情况下实现的。Honeynet既没有对企图来标榜Honeynet也没有企图来"引诱"攻击者。理论上来说这个站点只会有很少的活动迹象,就想我们没有广告任何服务和系统。 

Honeynet数据有价值的地方是Honeynet减少了主动错误信息(false positives)和被动错误信息(false negatives)所产生的问题。主动错误信息(false positives)指的是当组织由于恶意活动而被通知警报时候,经检查其实没有任何事情发生,而当这个组织持续的被主动错误信息(false positives)所触发警报,他们开始忽略他们的警报系统和数据采集,导致警告系统人为的无效。举个例子,MAIL入侵探测系统警告管理员系统被攻击,可能是一般已知的攻击被探测到,但是,这个警告可能是由一封包含对这个已知漏洞的警告并包含了攻击者所需的源代码来通知管理员的邮件错误触发的,或者可能是网络监视通信程序SNMP或者ICMP错误触发的。主动错误信息(false positives)对于大多数组织机构来说是是一项持续的挑战。Honeynet通过不包含任何实际的产品通信所触发的信息来减少这个问题,即不安装任何相关应用产品。因为Honeynet网络没有实际用途,它只是为了捕获未授权的活动,这表示任何信息包的进入和离开Honeynet都很本能的认为是有嫌疑的(因为没有任何应用平台),就简化了数据捕获和进程分析,减少主动错误信息(false positives)的产生. 

被动错误信息(false negatives)是多数组织机构需要面对的另一项挑战,被动错误信息(false negatives)就是对于真实的恶意攻击者或者未授权活动检测失败。多数组织机构有适当的机制来检测攻击,如入侵检测系统,防火墙日志,系统日志和进程计帐。这些工具的目的是为了检测有可疑或者未授权活动,但是,其中有两个重要的问题会导致产生被动错误信息(false negatives)检测失败:数据负载过重和新的漏洞,数据负载过重是当组织机构捕获过多的数据,而没有全部被查看,因此攻击者被忽略过,如,多数组织机构记录G级别的防火墙或者系统活动信息,这样对与重新复查这些成吨的信息来鉴别可疑行为变的极其困难。第二个问题就是新型漏洞的攻击,而造成安全软件没有能力来检测这种个攻击。Honeynet通过绝对的捕获所有进出honeynet的信息来减少这种新型攻击产生的漏捕。记住:Honeynet里只有很少或者没有的相关应用平台和程序所产生的活动,这表示所有捕获的相关信息是有一定嫌疑的。即使我们漏捕最初始的攻击,我们仍然截获这个活动,如Honeynet中有2个系统在没有任何警告给Honeynet 管理员的情况下被入侵,我们没有探测到这次攻击知道被入侵的主机发起对外的连接,一旦这些尝试被我们探测到,我们就检查了所有捕获的活动信息来鉴定这个攻击:它是怎样成功的,为何我们漏捕了,通过这些研究,honeynet减少了被动错误信息(false negatives)所产生的问题. 

对于有价值的数据的复查可以很明显的减少主动错误信息(false positives)和被动错误信息(false negatives)的产生。记住:下面我们所讨论的发现是特定我们的网络,这不意味着你的组织机构中会看到同样的模式或者行为,我们使用这个采集到的数据来演示部分blackhat的性质和早期警告和预测的可能性。 


Analyzing the Past
当我们研究黑帽子团体的时候,Honeynet项目惊奇地看到黑帽子团体是如此的活跃。我们的发现是令人惊慌的。下面是我们对十一个月来所收集数据的一些统计。公布这些数据的目地是展示黑帽子团体的频繁活动。需要注意的是,这些统计信息只代表了一个没什么价值的小家庭网络,它没有对外广而告之并且没有试图引诱黑客。那些有很高名气和很大价值的大型组织机构极有可能被探测和攻击的次数多得多。 

攻击后的分析: 

从2000年4月到11月,7台默认安装的Red Hat 6.2服务器在它们被放上Internet的三天之内被攻击。基于此,我们估计一个默认安装的Red Hat 6.2服务器的预期生命少于72小时。当我们最后一次试图证实这个估计的时候,系统在八小时内就被攻破。一个系统最快在15分钟内就被入侵。这意味着系统在连上Internet的15分钟内就被扫描,探测和入侵。碰巧的是,这是我们在1999年3月建立的第一个蜜罐系统。 
在2000年10月31日,我们放置了一个默认安装的Windows98系统,就象许多家庭和组织那样设置了共享。这个蜜罐系统在24小时之内就被入侵。在接下来的三天中又被入侵了四次。就是说在少于四天内它被成功地入侵了五次。在2000年5月,我们有了第一个全月的Snort入侵警告信息,Honeynet项目记录了157个Snort警告。在2001年2月,Honeynet项目记录了1398个Snort警告,表示了超过890%的增长。这些增长可能受到对Snort入侵检测系统配置文件修改的影响。然而,我们也从防火墙日志中看到了活动的增加。在2000年5月我们有了第一个全月的防火墙的警告信息,Honeynet项目防火墙记录了103个不同的扫描(不算上NetBios)。在2001年2月,Honeynet项目记录了206个不同的扫描(不算上NetBios)。这表示增加了100% 。这些数字表示了黑帽子活动的持续的增加,极有可能是因为更具攻击性的自动扫描工具的出现和它们能更容易地被得到。 
在三十天内(2000年的9月20日-10月20日),Honeynet收到524个不同的NetBios的扫描,平均每天17个不同的扫描。 
在2001年2月,一共对Honeynet有27次X86漏洞利用。X86意思是这些攻击被设计是对付Intel架构系统的。在这些攻击中,有8次是对Solaris Sparc系统的进行的。因为系统架构不兼容,这些漏洞利用对Sparc系统是无效的。这暗示了一些攻击者并不确认是什么操作系统或在其上运行了什么版本的服务。当他们发现了服务,他们甚至首先不确认系统是不是脆弱的,或者甚至是不是正确的系统类型。这种活动方式能使黑帽子在更短的时间内扫描和攻击更多的系统。 
从2000年4月至今,除了通常的扫描外,最流行的探测方法是DNS版本查询,接下来的就是RPC服务的查询。 
最流行的攻击是对Intel架构系统的rpc.statd溢出攻击。 
最流行的扫描方法是对整个IP段对特定端口的SYN-FIN扫描(通常按先后顺序)。这反映了聚焦于单个脆弱性的策略,针对这个脆弱性扫描到尽可能多的系统。许多黑帽子只使用单个的工具,或只利用他们知道如何利用或最有效的漏洞。 
Predicting the Future
Honeynet项目想要研究的一个方向是对系统攻击的前期预警,这样也可以给Honeynet搜集更多有价值的数据带来理论上的帮助。这些理论并不是非常新的,而且也有有些大公司在使用着,我们也希望我们的研究对这些公司及其它组织有所帮助。在详细地解释我们的方法之前,我想先声明:我们的研究还处于初始阶段,还有大量的数据分析工作需要进行。 

OK,让我们开始吧…… 

我现在讨论的仅仅是一个独立的Honeynet,仅是提供单节点的、数据量不大的观察结果。下面所要提及的方法将会在世界各国更广阔的环境、有众多Honeynet的环境中测试。 
我们并没有试图对由同一个攻击者发起的攻击作出识别,原因很简单,因为现在欺骗技术使用太广泛了。 
我们的许多推测建立在一个攻击者总是首先扫描然后攻击服务器这个流程上。当然,有些情况下或许扫描与攻击这两个事件根本是偶然。但我们仍坚持上述的观点。
我们努力对攻击情况做出合理的预测,期间Honeynet的两位成员提出了两个不同的方法,但是最终发现他们的结果是大同小异的,几乎所有的入侵者都在他们实施真正攻击前的两到三天被发现。 

使用统计学原理对事件做预警[Statistical Process Controls(SPC)]: 

首先是非常基础的统计学分析,类似于工厂里对生产情况进行统计对比。这种方法虽然看起来相当简单,但却能够精确地判断出短时期内(三天会更短)对Honeynet可能发生的攻击情况,简单的操作如下: 

我们分析了从2000年4月到2001年1月的所有snort记录。 
对snort报告得最多的10种攻击,我们计算出每天每种攻击会被重复多少次。 
然后,我们计算出每种攻击方式3天内的滑动平均模型,称作3DMA(three day moving average),然后我们在图上标出每种攻击方式在每天及每三天内会被报告多少次。 
我们计算出一个时期内的攻击水平平均值。 
在任何一个3DMA阶段内,如果发现2倍于平均值的攻击数量,或者持续高速增长,我们就可以认为这是一个危险信号。 
在这里,我们并没有区分入侵尝试及成功攻击,只是在图表画出来后,再标记上成功及企图的攻击,所有的数据可以在Honeynet的网站上获取。下面是我们的一些发现: 


Honeynet在2000年4月9日到2000年9月31日期间记录下了八次成功的攻击事件,除了一件之外,其余的都利用上面所描述的方法得到了准确的预测。 

在这段时间的试验以及所有的攻击中,多数的攻击尝试都是在3DMA超出了平均水平――也就是我们的控制点2倍,只有一次是7天之内,才发生真正的攻击事件。下面是一些事例: 

RPC: 我们从2000年4月1日对RPC服务进行了观察,总共用了180天时间,在第61至68天之间,发现图表中的查询次数有明显上升趋势,终于在第68天,一次利用rpc.statd的攻击发生了。另一次是在第153到170天之间,有大量的请求111端口的数据,而后就是在第177天时的一次对rpc.statd的成功溢出攻击。下面是一个对这期间活动的模型图表,X座标是天,Y座标是指发生次数。

DNS/named: 从第81-85天看起来不正常地活跃,有许多异样的请求发送到name server。在第85天,named服务受到了一次不成功的攻击。 
Validation through Regression Analysis and ARIMA: 
第二种方法对于第一种方法是一个有益的补充,比如它可以揭示出在有人违反snort的rpc规则后,大概多长时间系统遭攻陷,明确两者间的关联。在一段连续的时间内,有些简单的模型可以对违反rpc规则与系统真正被攻陷间做出清晰的关联。 

从下面的图表模型中我们可以看出,利用rpc.statd进行攻击的行为其实早几天就能被发现。横座标表示日期,在这里是从1-180天,向下的曲线通常表明有一些重要的事件发生,这能够预报一些攻击行为,比如在第68天我们受到攻击之前的10天内,就出现了这样的行为,而在其后又有三次向下的曲线,紧接着就是一次同样的rpc攻击发生在第177天。这里我也不太了解向上的曲线代表什么,但通常处在这种情况下,是一个平稳时期,没有太多的意外情况发生。 


需要说明的是,在这些分析模型中肯定会存在一些错误,我们需要更多的数据,以及对这些分析预测模型更完善的利用方式,这样才能够有效地得出攻击预警的一些思路。 

利用ARIMA模型找出攻击前的特征 

另一个研究的领域是识别出某些类型的攻击或者扫描存在着的特征,这两个事例都来自于我们Honeynet小组成员的“每月扫描”中,下面的图形描述了在一个月中我们遭受的端口扫描的数量。这里我们很乐于回答的另一个问题是对于不同的扫描及准备攻击的行为:“在一段时期内的数据收集之后,我们想要观察什么呢?”在这个简单的ARIMA(回归滑动平均模型,Auto Regression Integrated with Moving Averages)案例中,是直接按捕获的数据资料进行分析的,ARIMA是一个可以用在对一定时期内搜集的数据进行深度分析的基本模型,下面的图表表明了在九月份我们遭受的端口扫描的频繁程度。 


ARIMA模型的结果以下面表格的形式表示,这个表格显示说明了端口扫描是这些攻击中看起来较有代表性的,它先是向上拉起一个高峰,然后由其它类型的行为如预攻击等等终止。我们成员中的统计学专家还建议,三天的移动平均数计算在这样的时期内可能是太过粗糙的,对于这种类型的攻击,两天可能是一个相对合适的取值。 

在上面的两种分析中,我们的分析结果都受到了数据量不足的制约。但它还是给我们带来很多的经验,分析大量的数据,应该能够带来更多并非琐碎的,而是对我们从攻击本身建立起对攻击的预警体系,很有帮助的一件事。对于将来的测试以及改进这些理论,我们打算在下面做一些工作: 
我们需要获取更多的,彼此相互关联的数据来进行对比分析。 
更多的变量参数值――增加一些不同类型的snort捕获的数据,会有助于我们理解事件发生的流程。 
不同的统计分析技术,比如事件历史分析(Event History Analysis) 
我们欢迎安全组织测试或者开发这样的理论,并且将其应用于实际的统计分析上,对于不同的分析方法我们尤其感兴趣。我们在这里提供给大家的并不是最好的分析方法,事实上,一切研究都刚起步。下面的链接是Honeynet Project过去捕获到的数据,共有十一个月,从2000年4月起至2001年2月止honeynet_data.tar.gz 


结论
在这十一个月中,我们努力地捕获所有的扫描、攻击及利用我们机器的一些行为的信息。这些信息被我们以两种方式分析。第一种方式说明了blackhat团队的活跃性,要记住,Honeynet是一个没有关键信息、并且不做任何宣传的网络,如果你的网络里有重要数据,或者你大做宣传,那么你可能会面临更多的攻击。第二种方法我们用来检验攻击预警理论。我们认为利用它能够对未来的攻击行为作出预测。Honeynet并不是仅有一种搜集信息的手段,事实上,我们有许多方法来尽量减少主动信息错误和被动信息错误。充分利用了数据采集以及数据分析的方法,一个组织就能够更好地对blackhat团队的攻击做出防护了。 

B2层 发表时间: 05/05 10:46

论坛: 黑客进阶

20CN网络安全小组版权所有
Copyright © 2000-2010 20CN Security Group. All Rights Reserved.
论坛程序编写:NetDemon

粤ICP备05087286号