网络安全态势感知之大数据采集及预处理

ID：Computer-network

结合的常见应用需求，我们从生态链中选取了一些重要技术和实现方法。用于支撑的平台可采用如图1所示的架构模式。

图1 大数据生态链的网络安全态势感知应用架构

的核心就是从大量数据中挖掘出价值，而我们的首要工作就是要明确有哪些数据以及怎样采集。

在计算机信息系统中，一般按照形态的不同可将数据分为结构化数据和非结构化数据。结构化数据的特点是结构固定，每个字段都有特定的语义和长度，可用二维表结构来逻辑表达实现，领域常见的这类数据包括报警、事件日志、数据、摘要分析结构化描述记录以及各种相关的信息。非结构化数据是不规则或不完整的数据，其特点是格式非常多样，不方便用二维逻辑表来表现，需要先对数据进行格式转换或信息提取，领域常见的这类数据包括各类办公文档、文本、报表、HTML、XML、声音、图像文件等。

在应用中，按照应用场景计算需求的不同可将分为静态数据和动态数据（流式数据）。静态数据就像水库里的水一样，看上去静止不动，很多数据仓库系统存储的就是这类数据；这些数据一般来自不同数据源，利用ETL工具加载到数据仓库中，也一般不会更新，技术人员可利用数据挖掘和OLAP分析工具从这些静态数据中发现价值。动态数据也就是流式数据，是一组顺序、大量、快速、连续到达的数据序列，被视为一个随时间延续而无限增长的动态数据集合。它像流水一样，不是一次过来而是一点一点“流”过来，处理流式数据时也是一点一点处理，因为如果全部收到数据后再处理会有较大延迟，消耗大量内存，如对PM2.5的监测，因为需要实时显示空气质量情况，监测系统会对数据源源不断地回传并进行实时分析，预判空气质量变化趋势。

在的应用中，按照数据来源和特点可以将数据分为四类。一是环境业务类数据，主要包括被感知环境中的各类资产和属性；二是网络层面数据，主要包括包捕获数据、会话或流数据、包字符串数据；三是层面日志数据，包括各种系统、应用所产生的日志数据等；四是告警数据，通常来自、等安全设备或软件的报警信息。当然，如果对涉及的重要数据进行罗列，大致可以包括以下类型：完整内容数据、提取内容数据、会话数据、统计数据、元数据、日志数据和告警数据等。

对于不同类型、不同来源的数据，我们采用的数据采集方法也是不尽相同的。总的来说可分为主动式采集和被动式采集。其中与平台关联性较强的技术和方法主要有以下几种：

● 传感器

● 网络爬虫

● 日志收集系统

● 数据抽取工具

● 分布式消息队列系统

1、传感器

传感器（Sensor）俗称探针，以软件和硬件的形式安装在网络中，用于采集和发送数据，以及监控网段内各类资产的信息，它工作在网卡的嗅探模式。比较常见的情况是，一个传感器是由代理和插件所共同构成的具有网络行为监控功能的组合。传感器的功能主要包括数据采集、、、异常检测、协议识别等。

根据放置的位置不同，可将传感器分为内置型和外置型。前者一般部署在、等网络设备中以直接采集数据，大部分现代企业级和都能配置成传感器，并可以通过网络将所采集的数据导出来，当然也可以将许多开源的工具软件安装在硬件上并配置成传感器。后者即各种网络设备已经部署完毕，无法移动原有网络，需要外置部署，往往与线缆、网络分路器、汇聚和探针配合使用。

根据网络规模的大小及其所面临的威胁类型，传感器有着不同的作用和类型，如表1所示。

表1 传感器类型

有的传感器只需将采集到的数据记录在磁盘上，有时会基于已采集的数据再生成其他数据，这种类型的传感器功能简单，属于轻量化的传感器，通常没有额外安装的插件。有的传感器则不仅需要采集数据，还需要执行检测任务，当需要分析数据时会把数据“拉”到分析设备上进行，而非在传感器上，这种传感器最为常见，即带有一定检测能力的传感器。还有一种类型的传感器，其功能十分强大，集采集、检测和分析理解于一身，这种传感器除了配备采集和检测工具之外，还会安装一些分析插件，其好处是节约硬件资源，但缺点是容易因为对数据进行了不恰当的处理而导致一些重要数据的损失。毕竟机器的分析能力有限，还是需要一些人工辅助，才能更好地进行。

在这三种类型的传感器中，第二种传感器最为常见，也是优先推荐的类型。因为仅仅采集数据的传感器的功能确实过于单一有限，而集采集、检测和分析于一体的传感器又容易造成数据的缺失和分析能力的受限。兼具采集和检测功能是传感器较为有效且合理的功能设置，更安全且更有保障，对数据进行检测后再提交给平台，也方便平台以及安全管理人员进行进一步的深度分析理解。

由于传感器主要负责截取数据，因此需要具有较好的数据转发能力和较高的容量。为了对数据进行检测和解析处理，传感器还应具备一定的端口检测能力，对于一些高级的传感器还可增加自动学习并识别高层次协议的能力，即协议智能识别能力。总之，根据我们的实际需要，选择并设计合适的传感器进行数据采集。

2、网络爬虫

随着的迅速发展，产生了大量的信息，如何获取并利用这些海量信息成为一个重要问题，于是应运而生。（Web Crawler）又常称为网页蜘蛛、网络机器人、网络铲，它是一种按照一定规则自动抓取万维网信息的程序或者脚本。其行为一般是先“爬”到对应的网页上，再把需要的信息“铲”下来，它比普通的网络搜索引擎（比如百度、谷歌）更具有针对性、更精准，能定向抓取相关网页资源。当然，其也可以作为搜索引擎抓取系统的重要组成部分。

（1）网络爬虫的工作原理

简单的能够从一个或若干个网页的URL（统一资源定位符）开始，获得初始网页上的URL，在抓取网页的过程中不断从当前页面上抽取新的URL放入队列，直到满足一定停止条件。复杂一些的能够根据一定的网页分析，过滤与主题无关的链接，只保留有用的链接，并将其放入等待抓取的URL队列中，然后根据一定的搜索策略从队列中选择下一步要抓取的网页URL并重复上述过程，直到达到系统的某一条件时停止。所有被抓取的网页将会被系统存储，并进行一定的分析、过滤，最后建立索引，以便之后的查询和检索。一个通用的工作流程框架如图2所示。

图2 网络爬虫工作流程

● 首先选取一部分种子URL。

● 然后将这些URL放入待抓取URL队列中。

● 从待抓取URL队列中取出待抓取的URL，解析其，获得IP，将URL对应的网页下载下来，存储到已下载网页库中，并将这些URL放入已抓取URL队列。

● 分析已抓取到的网页内容中的其他URL，再将这些URL放入待抓取URL队列中，进入下一个循环过程。

（2）网络爬虫的类型结构

已逐渐成为人们主动获取万维网上信息的重要方式，其种类多样、可性强。按照系统结构和实现技术，大致可分为以下几种类型：通用、聚焦、增量式、深层等。在现实中，抓取系统往往是一个分布式的三层结构，最底层分布在不同地理位置的数据中心，在每个数据中心有若干台抓取，而每台抓取上可以部署若干套爬虫程序。对于一个数据中心的不同抓取，其协同工作方式大致有主从式和对等式两种，可根据实际需要进行选择。

（3）网络爬虫的爬取和更新策略

在系统中，待抓取URL队列是很重要的一部分。如何对URL进行排序是一个重要的问题，这也就是我们要介绍的的爬取策略，因为它决定了抓取页面的顺序。比较常见的爬取策略有深度优先遍历策略、宽度优先遍历策略、反向链接数策略、大站优先策略、OPIC策略以及PartialPageRank策略等。对于何时更新以前已经下载过的页面，也有相应的网页更新策略，常见的有历史参考策略、用户体验策略和聚类抽样策略等。

总的来说，技术还是比较成熟的，提供了很多很好的类库，用实现一个简单的爬虫程序并不难，且所需的代码量非常少。

3、日志收集系统

数据中有相当一大部分是各种设备、系统和应用中所产生的日志数据，它们往往隐藏了许多有用信息。在过去，因为采集分析手段的缺失，这些日志常常存储一段时间就被清理了。而随着技术的成熟，日志的价值重新得到重视。如何将分布在各个设备、系统和应用中的日志数据收集起来进行高效的汇总？我们会用到一些高性能的分布式日志收集系统，如Flume、Facebook Scribe、Apache Chuwwka等，这里重点介绍Flume。

（1）Flume的产生背景

Flume是Cloudera提供的一个高可用、高可靠、分布式海量日志采集、聚合和传输的系统。设计Flume的宗旨是向Hadoop批量导入基于事件的海量数据。Flume支持在日志系统中定制各类数据发送方，用于收集数据，同时Flume具有对数据进行简单处理并写到各种数据接收方的功能。一个典型的例子就是利用Flume从一组中收集日志文件，然后将这些文件中的日志事件转移到一个新的HDFS汇总文件中以做进一步的处理，其终点通常为HDFS。

（2）Flume系统架构

Flume采用三层架构，分别为Agent（代理）、Collector（收集器）和Storage（存储器），每一层都可以水平扩展。在这三个层次中，Agent和Collector均由Master统一管理，进行统一监控和维护，并且Master可以有多个（用ZooKeeper进行管理和），能有效地避免单点故障。Flume系统架构如图3所示。

图3 Flume系统架构

（3）Flume的工作原理

在使用Flume的时候，需要运行Flume代理（Agent），因为Flume由一组以分布式拓扑结构相互连接的代理所组成。Flume代理是由持续运行的Source（数据来源）、Sink（数据目标）和Channel（连接数据源和数据目标的渠道）所构成的进程。“代理们”是这样运作的：Source产生事件并将其传送给Channel，Channel存储这些事件并转发给Sink。这种Source-Channel-Sink的组合即为基本的Flume构件。因此，使用Flume的主要工作就是通过配置代理使得各个组件连接在一起。Flume工作过程大致如图4所示。

图4 Flume工作过程

在实际应用当中，可以采用多Agent串联（一个接一个）的方式，也可以采用多Agent合并（并联）的方式，此外，还可以对单一Source进行多种处理（即一个Source有多个Channel和Sink），多种使用模式可任意挑选。

4、数据抽取工具

Hadoop最大的优势就在于能够支持不同形式和不同来源的数据，并对其进行存储和解析，进而抽取出相关信息将多个数据集组成非常有用的结果。目前的实际情况是很多有价值的数据都是以结构化形式存储在许多组织的关系型系统中，如何将这些关系型所存储的结构化数据抽取到Hadoop平台中；以用于进一步的分析处理，是一项重要且有意义的工作。这里，我们介绍一款专门用于数据抽取的工具Sqoop。

（1）Sqoop简介

Sqoop是SQL-to-Hadoop的缩写，它也是Hadoop生态系统中的一员，主要用于在Hadoop和关系型（结构化存储器）之间交换数据，可以改进数据的互操作性。通过Sqoop可以很方便地将数据从Oracle、等关系型中导入Hadoop，或者将数据从Hadoop导出到关系型中，使得传统关系型和Hadoop之间的数据迁移变得非常方便。Sqoop主要通过JDBC与关系型进行交互，理论上，支持JDBC的关系型都可以使用Sqoop与Hadoop进行数据交互。Sqoop专门为集而设计，支持增量更新，可以将新记录添加到最近一次导出的数据源上，或者指定上次修改的时间戳。Sqoop已经过两个版本的发展，Sqoop1是命令行工具，不提供 API，很难嵌入其他程序中，其中所有的连接器都必须掌握所有输出格式，而Sqoop2具有用以运行作业的组件和一整套客户端，包括命令行接口、网站用户界面、 API等，还能使用其他执行引擎（如Spark）。

（2）Sqoop基础组件——连接器

Sqoop拥有一个可扩展的框架，使得它可以从（向）任何支持批量数据传输的外部存储系统中导入（导出）数据。一个Sqoop连接器（Connector）就是这个框架下的基础模块化组件，用于支持Sqoop的导入和导出。这种连接器有很多种类，比如通用的JDBC连接器可以连接所有支持JDBC协议的，还有针对、Oracle、DB2、Microsoft SQL Server等关系型的专用连接器。这些常用的连接器一般会内置在Sqoop中。还有很多针对各种数据存储器的第三方连接器可以使用，如支持企业级数据仓库如Teradata和NoSQL存储器的连接器，它们往往需要另外单独下载安装。

（3）Sqoop的工作原理

Sqoop最重要的功能就是把数据导入Hadoop。它通过一个MapReduce作业从中导入一个表，这个作业从表中抽取一行行记录，然后将记录写入HDFS中，图5展示了Sqoop的导入过程。

图5 Sqoop导入过程

在向HDFS导入数据时，最重要的是确保访问的数据源是一致的，而从中并行读取数据的Map任务分布运行在不同的进程中，因此不可能共享同一个事务。保持一致性的最好方法就是在导入时不允许运行任何对表中现有数据进行更新的进程。

Sqoop的导出功能架构与其导入功能架构非常相似。在执行导出操作之前，Sqoop会根据连接字符串来选择一个导出方法，对于大多数系统来说，Sqoop都会选择JDBC；然后Sqoop会根据目标表的定义生成一个类（class），这个类能从文本文件中解析出记录，并且能够向表中插入类型合适的值；然后会启动一个MapReduce作业，从HDFS中读取源数据文件，使用生成的类解析出记录，并且执行选定的导出方法。图6展示了使用MapReduce并行执行导出的过程。

图6 Sqoop导出过程

5、分布式消息队列系统

在大规模分布式系统中常使用消息队列，它是在消息传输过程中保存消息的容器或，主要目的是提供消息路由、数据分发并保障消息可靠传递，为分布式系统的各个构件之间传递消息并提供承载。目前常见的分布式消息队列产品有Kafka、ActiveMQ、ZeroMQ和RabbitMQ等。从性能和可扩展性上看，ZeroMQ、Kafka、RabbitMQ、ActiveMQ依次递减。从功能种类和应用广度上看RabbitMQ和ActiveMQ强于Kafka和ZeroMQ。综合比较的话，与RabbitMQ和ActiveMQ相比较Kafka算是轻量级系统，同时又能提供消息持久化保证（不像ZeroMQ），性能、高可用和可扩展方面表现也很优异，平均得分最高，目前应用场景较多，也非常适合用于平台，因此我们重点介绍Kafka消息队列。

（1）Kafka的产生背景

在系统中常常会遇到一个问题：整个由各个子系统组成，数据需要在各个子系统中高性能、低延迟地不停流转。传统的企业消息系统并不适合大规模数据处理。为了既能处理在线应用（消息），也能处理离线应用（数据文件和日志），Kafka应运而生。Kafka是LinkedIn开源的分布式消息队列系统，诞生于2010年，具有极高的吞吐量和较强的扩展性和高可用性，主要用于处理活跃的流式数据。

最初，Kafka被用于进行日志收集、用户行为实时收集以及机器状态监控等，后来，还可作为流式计算系统的底层构件，如LinkedIn的流式计算系统Samza就是构建在Kafka和YARN之上的。对于像Hadoop这样的传统日志分析系统，其能够提供离线处理日志消息的能力，但要是进行实时处理，就会有较大延迟，而通过Hadoop的并行加载机制加载Kafka消息队列系统后就能够统一线上和离线的消息，提供实时或近实时消息处理能力。总的来说，Kafka可以起到两个作用：一是降低系统组网复杂度，二是降低复杂度，各个子系统不再是相互协商接口，各个子系统类似插口插在插座上，Kafka承担高速数据总线的作用。

（2）Kafka的整体架构

Kafka的整体架构非常简单，是显式的分布式架构，主要涉及三个角色：

消息生产者（Producer）：消息（Message）和数据的生产者，产生特定主题（Topic）的消息并传入代理集群。

代理服务器（Broker）：也称缓存代理，是Kafka集群中的一台或多台。

消息消费者（Consumer）：消息和数据消费者，订阅Topic并处理其发布的消息。

Kafka的架构如图7所示。

图7 Kafka整体架构图

其中，Producer、Broker和Consumer都可以有多个。Producer和Consumer实现Kafka注册的接口，数据从Producer发送到Broker，Broker承担一个中间缓存和分发的作用。Broker的作用类似于缓存，是活跃的数据和离线处理系统之间的缓存，主要把数据分发注册到系统中的Consumer。客户端和端的通信是基于简单、高性能且与语言无关的实现的。

（3）Kafka消息发送流程

Kafka消息发送流程如图8所示。

图8 Kafka消息发送流程

首先补充一个基本概念——Partition（分区），它是Topic物理上的分组，一个Topic可以分为多个Partition，每个Partition是一个有序、可持续添加的队列，Partition中的每条消息都会被分配一个有序的序列号id，称之为offset（偏移量），在每个Partition中此偏移量都是唯一的。

Kafka消息发送的流程大致为：Producer根据指定的分区方法（例如Round-robin、Hash等），将消息发布到指定Topic的Partition中；Kafka集群接收到Producer发过来的消息后，将其持久化到硬盘，并保留消息指定时长（可配置）大数据搜集，而不关注消息是否被消费；Consumer从Kafka集群里pull（拉）数据，并控制获取消息的offset。

（4）Kafka的主要特点

Kafka有以下几个主要特点：

● 同时为发布和订阅提供高吞吐量。据了解，Kafka每秒可以生产约25万条消息（50 MB），每秒处理55万条消息（110 MB）。

● 可进行持久化操作。将消息持久化到磁盘，因此可用于批量消费，如ETL等。通过将数据持久化到硬盘以及实现多副本，从而防止数据丢失。

● 分布式系统，易于向外扩展，可以与ZooKeeper结合。所有的Producer、Broker和Consumer都会有多个，均为分布式的，无需停机即可扩展机器。

● 消息被处理的状态是在Consumer端维护，而不是由端维护，当失败时能自动平衡。

● 支持在线应用和离线应用的场景。

（5）Kafka的应用场景

Kafka的应用场景主要有以下几种：

消息队列：比起大多数传统的消息系统，如ActiveMR或RabbitMQ，Kafka有更好的吞吐量、内置的分区、冗余及容错性，这使得Kafka成为一个很好的大规模消息处理应用的解决方案。普通的消息系统一般吞吐量相对较低，当需要更小的端到端延时的时候，可依赖于Kafka提供的强大的持久性保障。

行为跟踪：可用于跟踪用户浏览页面、搜索及其他行为，以发布–订阅的模式实时地记录到对应的Topic中。当这些结果被订阅者拿到后，就可以做进一步的实时处理或放到Hadoop离线数据仓库里进行处理。

日志收集：用于日志收集的开源系统有很多，如前面介绍的Flume等。Kafka也能进行日志收集或者说是日志聚合，其特别之处在于，Kafka会忽略文件的细节，将其更清晰地抽象成一个个日志或事件的消息流，这就让Kafka处理过程延迟更低，更容易支持多数据源和分布式数据处理，在提供同样高效的性能的同时具有更高的耐用性。

数据监控和交换：可作为操作记录的监控模块来使用，即汇集和记录一些操作信息。在很多组织的生态系统中可以把Kafka作为数据交换枢纽，将不同类型的分布式系统（如关系、NoSQL、离线系统、流处理系统、图计算系统等）统一接入Kafka，从而实现与Hadoop各个组件之间的不同类型数据的实时高速交换，很好地解决不同系统之间的数据生成/消费速率不同的问题。

流处理：这是最为广泛的应用场景，通过收集并保存流式数据，提供之后与之对接的Storm或其他流式计算框架来进行处理。很多用户会将原始Topic的数据进行阶段性处理、汇总和扩充，或者以其他的方式转换到新的Topic下再继续后续处理，Storm和Samza就是非常著名的用于实现这种类型数据转换的计算框架。

持久性日志：Kafka可以为一种外部的持久性日志的分布式系统提供服务。这种日志可以在节点间备份数据，并为故障节点数据恢复提供一种重新同步的机制，Kafka中的日志压缩功能为这种用法提供了条件。

（编辑：源码门户网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!