Know Your Enemy:
Statistics
Analyzing the past ... predicting the future
Honeynet Project
http://project.honeynet.org/
http://www.xfocus.org/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模型的结果以下面表格的形式表示，这个表格显示说明了端
