一种用于大规模网络安全监控的大数据架构

李磊 山东省烟台市公安局交通警察支队

引言

作为一个传统的网络安全问题，入侵检测与预防问题已经被科研人员研究了三十多年[1]，第一个被提出的概念是入侵检测系统（IDS），它于1987年被提出[2]。然而，由于要分析的数据类型不断演变，对此问题的研究仍然一直在持续。另外，攻击者针对新的防护手段与防火墙策略不断调整其攻击手段，也使得该研究领域不断发展。此外，近年来，与入侵识别和检测相关的异构安全数据的处理方法研究，也是研究的热点。

大多数传统网络入侵检测系统（NIDS）的技术实现依赖于网络流量分析，它们一般通过检查来自多个协议（HTTP、SIP、DNS等）的网络流量以发现异常行为，这些异常行为通常依赖于对异常行为的规则定义。一旦观察到异常行为，系统就会发出报警（IDS）或停止通信（IP S）。目前的IDS还会分析多种协议，并将其观察到的数据与事件由SIEM（安全信息和事件管理）相关联以便检测入侵行为。但是，一个缺点是，目前基于IDS实现的深度分组分析解决方案不可扩展，并且无法适用于会产生大量数据的大型网络。

在大型政府单位、运营商等网络环境中，必须处理大量的流量数据。主IP流记录中包含源及目标IP与端口、IP协议版本、时间戳、字节数与数据包数等属性，其数据量、数据生成速度、数据多样性等均会成为数据收集与分析的挑战。而数据来源的多样性（蜜罐、DNS监控、IDS、IPS等）更要求有一套统一的分析方法。

本文通过提出一个用于企业网络入侵检测与预防的系统架构，解决了上述问题。本文方法的数据源包括DNS流量、HTTP流量、IP流记录与蜜罐数据等。上述数据中的每一种都已经被单独应用于入侵检测并被证明是有效的[3-7]。然而，为了应对各种新型攻击手段和混合攻击技术，安全防护系统必须利用所有可用的分析数据源。本文提出的系统在同一个分布式数据存储和处理系统中集成了三个不同的数据存储系统，数据被分布式数据关联系统利用，从而能够支持大规模网络安全监控。

一、系统架构和应用

本文提出的安全监控系统的总体结构如图1所示，系统由异构分布式数据存储系统与其他分布式数据相关系统组成。

本文系统收集处理了四类用于网络安全监控的数据：

·DNS回复

·HTTP数据包

·IP流记录

·蜜罐数据

（一）数据采集

作为互联网的核心服务，几乎所有的网络通信都是通过DNS发起的。在网络通信过程中，需要执行DNS请求以获取与域关联的IP地址，然后查询所需的资源。因此，对DNS进行监控以识别恶意域，是主动检测和防止恶意通信的有效方式。在大规模网络的具体实现中，需要在网络中的递归DNS服务器上设置DNS探测器，用于收集所有相关的DNS请求和网络回复。本文系统的DNS探测器捕获发往递归DNS服务器的DNS回复，并从DNS数据包中提取信息。所有被观察到的域及提取的信息都存储在一个高可扩展且可用的数据库Apache Cassandra数据库中。

在互联网用户流量中，HTTP流量占很大一部分，同时也是众所周知的入侵媒介。对嵌入在HTTP数据包中的URI及其有效负载进行研究，能够有效地检测与防止恶意网络通信。因此，本文系统在网络HTTP代理级别对HTTP流量实施监视，网络中的所有HTTP连接尝试都通过该代理，并通过检查分组的嵌入域和IP目的地，对连续参与相同通信的不同URI实施动态分析。相同的技术也可以应用于任何包括IP地址和URI的协议分析，如SIP数据包。

Cisco NetFlow是一种应用较广的通过路由器实施IP流量监控的监控技术，它能够记录通过路由器转发的所有通信，具体记录内容包括源和目标IP、源和目标端口、时间戳、使用的协议、交换的数据量等。这些流记录信息对检测入侵或发现僵尸网络通信非常有价值。本文的系统通过从网络中的核心路由导出NetFlow记录，对从企业网络与Internet之间的所有通信进行了存储。NetFlow记录采用分布式存储方式存储在nfcapd二进制文件中。

本文系统中使用的最后一种数据是蜜罐数据。蜜罐通常用于模拟易受攻击的服务并包含虚假的生产网络数据。它看上去就像一台存在缺陷的计算机，其部署目的就是被攻击。对蜜罐的连接尝试通常是探测攻击的表征，因此，记录蜜罐信息可以了解针对特定网络的攻击者特征，如其使用的IP地址、协议、漏洞利用文件、扫描策略等。利用蜜罐数据可以调整安全策略，以防止攻击者对生产机器发起真正的攻击。本文系统架构中选择的蜜罐解决方案是Dionaea[]，这是一种低交互蜜罐，能够模拟HTTP、FTP、MSSQL、SMB等多种易受攻击的网络服务，对Dionaea的所有连接尝试都存储在SQLite数据库中。

（二）数据关联

本节对分布式数据关联系统的基本原理和数据处理方式进行阐述。系统将来自四类数据源的数据进行整合，从而计算描绘网络的风险水平值。

在本文系统中，当有客户端查询域名时，请求将被转发到本地的递归DNS服务器。它通过向权威DNS服务器提出递归请求来解析域名。所有进入递归DNS服务器的权威DNS回复都会被存储在Cassandra数据库中。收集DNS回复时，系统执行了三个操作来推断域名的恶意程度：

·根据三个公开的黑名单对域名实施检查，三个黑名单的分值BLdom递增。

·利用DNS数据自动分类技术识别恶意域名[3,4]，此处采用机器学习算法计算所得的置信度Cdom作为风险值，数值越接近1，域名越可能是恶意的。

·根据蜜罐记录的IP地址检查DNS资源记录中的每个IP。每出现一次匹配，则计数器Hdom递增。假设某域名有5个A资源记录，即5个IP地址相关联，若其中3个被蜜罐记录，则其Hdom得分为3。

根据上述三个数值，可以利用式（1）计算域名恶意程度值Domscore，并将该值与数据库中的各个域名一起计算与存储：

对于由核心路由导出的所有数据流量，本文系统用三个相关方案来推断通信的恶意程度。这些关联方案适用于不属于企业网络范围的IP地址：

·根据蜜罐记录的IP地址检查与流量相关的IP地址。如果出现匹配，则检查端口匹配情况。增加对应于IP地址匹配和端口匹配的两个布尔值，用于计算Hflow。如果首先匹配IP地址，则仅计算后者。

·根据DNS数据库检查与流量关联的IP，以确定这些IP是否与我们认为是恶意的域有关联。将MDflow计算为对应于与流量记录的IP相关联的所有域的Domscore数值总和。

·如果流记录中出现的IP地址与DNS数据库的任何域都无关，则此地址的分数为NOflow=1。这表明可能出现了使用硬编码IP的网络通信，可能是可疑行为，因为攻击者可能会尝试绕过基于DNS的入侵检测。

根据上述三个数值，可以利用式（2）计算出根据流量记录所确定的网络风险值Flowscore：

在本文的系统中，HTTP流量是通过代理在线采集的，这些流量被转发到本文的分析系统中进行下述计算评估：

·检查HTTP数据包的URI，以确定其是否嵌入DNS数据库中存在的域。然后计算Dweb= Domscore以判断URI是否是恶意的。

·针对有目标或源IP地址的HTTP数据包，根据其是否登录蜜罐，判断用于表示其与潜在恶意来源通信的Hweb值（1或0）。

·由包括蜜罐在内的仿真HTTP服务器接收的有效负载中的HTTP数据包，判断PLhweb值（1或0），用于表示在HTTP数据包中公开注入代码或shell脚本的痕迹。

·最后分析HTTP数据包的有效负载，以观察其是否包含被动DNS数据库中存在的域名。如果找到这些域，则PLdweb得 分等于相应域的Domscore之和。

根据上述四个数值，可以利用式（3）计算出描述HTTP数据包恶意程度的分值Webscore：

（三）应用

前面提出了三个数据指标Domscore，Flowscore和Webscore，用于评估域名、流量和HTTP数据包恶意的可能性。当出现导致IDS发出警报或IPS出现阻止行为的通信时，可以分别利用上述指标进行具体判断。

二、数据存储和处理

上一节简要介绍了本文系统所利用的数据是在不同点收集并存储在各种数据存储系统中的（参见图1）。系统实际运行环境在包含近200台计算机终端的行业办公网络环境中，在测试阶段我们测量了下述数值：

·Dionaea蜜罐：每天从15个不同的主机尝试大约1000次连接。

·NetFlow：平均日流量9600000，每分钟出口一次（约450MB）。

·DNS：每天约1300万次DNS回复（约1.5k MB）。

Dionaea蜜罐，连接由少量攻击者发起，数据量不大，处理要求不高。另外，在测试期内，发现部分IP可能随着时间的推移创建冗余连接。对于数据量较小的此类数据，SQLite数据库的查询速度非常快，因此本文系统选择了SQLite数据库存储记录信息（IP、端口、协议、有效负载等）。值得注意的是，即使监控对象变成更大规模的网络，如拥有500台或10,000台计算机的网络，也不会影响部署在网络中的单个蜜罐机器记录的数据量，因此，此类数据总量也不会有太大变化。

网络流量数据的存储更具挑战性，尤其是在本文的系统中需要的是一种可扩展解决方案。在系统实现中，我们每分钟用nfdump导出网络流量，以实现近乎实时的网络通信监控。网络流量记录被存储在几个分布式服务器上的nfcapd二进制文件中。在本文的实际案例实现中，多个服务器并非必需的，但由于路由器导出的流量会随着网络规模的变大而增长，因此采用了多台分布式服务器的方式，这种选择能够确保满足任何规模网络的可扩展性存储要求。然而，由于nfcapd文件是二进制文件，它也导致了一些数据处理问题。大数据框架（如Hadoop）具有通常基于文本的MapReduce任务输入格式。虽然Hadoop支持二进制输入/输出的内置序列文件格式，但是，在上传之前，必须先在HDFS（Hadoop分布式文件系统）序列文件中转换nfcapd文件。此过程意味着较高的计算开销，耗时且无法实现安全监控的实时性。因此，另一种解决方式是开发一个新的API，直接读取本机nfcapd格式的数据。该解决方案优于本文系统中的解决方案，并且速度很快，文献[9]中的实践证明其对在200节点的测试平台中能够提供14Gbps的吞吐量。

与网络流量类似，本文的实践结果表明，DNS监控也会产生较大的数据量。此外，该数据量也会随着实施DNS查询的用户/机器数量（即网络的大小）而增长。与网络流量的全量存储方式不同，对DNS监控，不需要存储所有相关数据，可以从DNS分组中提取部分信息以避免信息冗余，同时节省存储空间。在本文系统中，存储的信息包括域名、TTL、部分标志符、首次访问和末次访问时间戳等。

为了满足数据存储和可用性的要求，DNS数据从数据包中提取并存储在Apache Cassandra数据库中。Cassandra是一种用于数据存储的分布式数据库，数据访问方面的性能较为突出。此外，Apache Cassandra自0.6版本开始集成Hadoop管理，从而确保了与大数据处理的最新解决方案的便捷交互。本文系统采用此实现方式能够确保系统的体系结构适用于比测试网络规模更大的网络环境。

三、性能评估

针对本文提出的网络安全监控大数据架构，本节针对Hadoop、Pig、Hive和Spark四个应用最为广泛的开源大数据框架的性能进行了性能比较。在评估中，本节针对与技术指标相关的三种不同任务，对上述四个大数据框架的执行性能进行了实验测试。实验环境为由8台计算机（1个主节点、7个从节点）组成的集群环境，其中，所有计算机的性能配置均为：Intel(R) Core(TM) 2 Duo，Ubuntu 12.04.4操作系统，4GB内存。实验中所采用的大数据框架版本分别为Hadoop-1.2.1、Hive-0.9.0、Pig-0.11.1和Spark-0.6.1。Spark框架的每个节点分配2GB内存，共14GB工作内存。针对所有框架和测试任务均做了10次测试。

三种测试任务分别为：

任务1：查找与给定源IP与源端口匹配的数据包；

任务2：在有效流量中查找包含给定字符串的数据包；

任务3：计算每个源IP的目标IP数量并对结果进行排序。

任务1的需求也就是计算Hdom要做的工作，即查找与域名相关的IP是否有被记录。Hflow、Hweb和BLdom的计算也需要执行同类型的操作。针对本文研究的四个框架，表1记录了执行该操作所需的时间，包括10次测试所花费的平均时间、时间中位数，以及最小、最大持续时间。

从表1(a)的实验结果可以看出，针对任务1，Hadoop的Hive性能近似，均需约17.5秒执行时间；Pig是所有测试框架中速度最慢的，平均需26.475秒执行时间；Spark的执行效率比其他框架高得多，且比较稳定（平均时间、中位时间、最长和最短执行时间差别较小），是任务1下的最佳方案。

表1(b)和表1(c)也给出了针对任务2和任务3的实验结果记录。其中，针对任务2，需要计算PLhweb和PLdweb，此项计算需要分析HTTP数据包的内容以查找给定字符串和域名，该工作也可用于通过在URI中搜索恶意域来计算Dweb。针对任务3，能够突显出网络环境中与Internet通信量最大的计算机，这也是网络安全监控中所需的重要信息。

针对这两类任务的执行测试情况，能够观察到与任务1几乎相同的结果数据趋势。Pig仍旧是最慢的解决方案，特别是对于任务3，需要82.744秒的任务执行时间，是Hadoop用时的两倍多、Spark用时的50倍。另外，除任务2之外，Hadoop和Hive的执行时间几乎相同，Hive的平均执行时间快于Hadoop，但Hadoop比Hive更稳定。Spark还是比其他三个方案执行时间更短，每个任务的结果均约为1秒。对于任务2来说，Spark的表现较为稳定，但对于任务3，Spark的稳定性则较差，其最小与最大执行时间之差高达6倍。

四、结语

本文提出了一种新的可扩展网络入侵检测与防护技术架构，并对该架构的系统实现进行了阐述。本文的系统实现以分布式方式收集和存储蜜罐数据、DNS数据、HTTP流量与IP流量数据。介绍了基于这些数据的几种入侵检测与取证分析应用方案，并在四种数据的存储与处理方案中评估并提出了适合本文架构的五种最先进的大数据框架。

虽然本文的架构在安全分值计算中延迟很少，但是仍然使用了Hadoop和Shark的离线分析工具。在未来的研究中，将使用在线分析大数据框架（如Spark Streaming 或Storm）实现相同的系统功能，并对两类方案的优劣进行比较研究。