公司简介   产品资讯   客户服务   安全资源   顾问服务   合作伙伴 


 

认识你的敌人:

统计

分析过去 ... 预知未来

Honeynet Project
http://project.honeynet.org/
资料来源: http://project.honeynet.org/papers/stats/

在过去的几年里,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 入侵侦测系统警告管理员系统被攻击,可能是一般已知的攻击被侦测到,但是,这个警告可能是由一封包含对这个已知漏洞的警告并包含了攻击者所需的 Souce Code 来通知管理员的邮件错误触发的,或者可能是网路监视通讯程序 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
当我们研究 blackhat 团体的时候,Honeynet 项目惊奇地看到 blackhat 团体是如此的活跃。我们的发现是令人惊慌的。下面是我们对十一个月来所收集数据的一些统计。公布这些数据的目地是展示 blackhat 团体的频繁活动。需要注意的是,这些统计讯息只代表了一个没什麽价值的小家庭网路,它没有对外广而告之并且没有试图引诱骇客。那些有很高名气和很大价值的大型组织机构极有可能被探测和攻击的次数多得多。

攻击後的分析∶

  • 从 2000 年 4 月到 11 月,7 台预设安装的 Red Hat 6.2 服务器在它们被放上 Internet 的三天之内被攻击。基於此,我们估计一个预设安装的 Red Hat 6.2 服务器的预期生命少於 72 小时。当我们最後一次试图证实这个估计的时候,系统在 8 小时内就被攻破。一个系统最快在 15 分钟内就被入侵。这意味著系统在连上 Internet 的 15 分钟内就被扫描,探测和入侵。碰巧的是,这是我们在 1999 年 3 月建立的第一个诱陷系统。
  • 在 2000 年 10 月 31 日,我们放置了一个预设安装的 Windows98 系统,就像许多家庭和组织那样设定了共享。这个诱陷系统在 24 小时之内就被入侵。在接下来的三天中又被入侵了 4 次。就是说在少於 4 天内它被成功地入侵了 5 次。在 2000 年 5 月,我们有了第一个全月的 Snort 入侵警告讯息,Honeynet 项目记录了 157 个 Snort 警告。在 2001 年 2 月,Honeynet 项目记录了 1398 个 Snort 警告,表示了超过 890% 的增长。这些增长可能受到对 Snort 入侵检测系统设定档案修改的影响。然而,我们也从防火墙日中看到了活动的增加。在 2000 年 5 月我们有了第一个全月的防火墙的警告讯息,Honeynet 项目防火墙记录了 103 个不同的扫描(不包括 NetBios)。在 2001 年 2 月,Honeynet 项目记录了 206 个不同的扫描(不包括 NetBios)。这表示增加了 100% 。这些数字表示了 blackhat 活动的持续的增加,极有可能是因为更具攻击性的自动扫描工具的出现和它们能更容易地被得到。
  • 在 30 天内(2000 年 9/20-10/20),Honeynet 收到 524 个不同的 NetBios 的扫描,平均每天 17 个不同的扫描。
  • 在 2001 年 2 月,一共对 Honeynet 有 27 次 X86 漏洞利用。X86 意思是这些攻击被设计是对付 Intel 架构系统的。在这些攻击中,有 8 次是对 Solaris Sparc 系统的进行的。因为系统架构不兼容,这些漏洞利用对 Sparc 系统是无效的。这暗示了一些攻击者并不确认是什麽作业系统或在其上执行了什麽版本的服务。当他们发现了服务,他们甚至首先不确认系统是不是脆弱的,或者甚至是不是正确的系统类型。这种活动方式能使 blackhat 在更短的时间内扫描和攻击更多的系统。
  • 从 2000 年 4 月至今,除了通常的扫描外,最流行的探测方法是 DNS 版本查询,接下来的就是 RPC 服务的查询。
  • 最流行的攻击是对 Intel 架构系统的 rpc.statd 溢出攻击。
  • 最流行的扫描方法是对整个 IP 区段对特定通讯埠的 SYN-FIN 扫描(通常按先後顺序)。这反映了聚焦於单个脆弱性的策略,针对这个脆弱性扫描到尽可能多的系统。许多 blackhat 只使用单个的工具,或只利用他们知道如何利用或最有效的漏洞。

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 的网站上获取。下面是我们的一些发现∶

  1. Honeynet 在 2000 年 4/9 到 2000 年 9/30 期间记录下了 8 次成功的攻击事件,除了一件之外,其馀的都利用上面所描述的方法得到了准确的预测。

  2. 在这段时间的试验以及所有的攻击中,多数的攻击尝试都是在 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)

我们欢迎安全组织测试或者开发这样的理论,并且将其应用於实际的统计分析上,对於不同的分析方法我们尤其感兴趣。我们在这里提供给大家的并不是最好的分析方法,事实上,一切研究都刚起步。从 2000 年 4 月起至 2001 年 2 月止 honeynet_data.tar.gz

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


The Honeynet Project
Certification & Awards

2006-02
2005 MIS Best Choice

2006-02
DragonSoft Vulnerability Database - CVE-Compatibility Certificate

2005-12
Small and Medium Enterprise Business Start-Up Award

2005-12
Small and Medium Enterprise Innovation Research Award

2005-11
Golden Torch Award

2005-04
National Quality Guarantee Golden Award

2005-03
Golden Peak Award

2004-11
DragonSoft Secure Scanner - CVE-Compatibility Certificate
  Copyright© DragonSoft Security Associates, Inc. All rights reserved.
  台湾总部∶新竹市光复路一段 607 巷 30 号 5F   Tel: 03-563-0989 Fax: 03-579-7758
  台北业务处∶中和市中山路二段 351 号 9F   Tel: 02-8221-5408 Fax: 02-8221-5476