大数据安全分析平台搭建及使用经验分享

在大数据应用普及以及信息安全上升为国家高度后，信息安全能力落地的挑战日益增多。一方面，企业内部的安全体系架构日益复杂，各式各样的安全数据越来越多，传统分析方法难以奏效。另一方面，传统分析方法无法有效的检测新型攻击手法。同时，在大数据时代下对威胁的判断以及响应有着更高的要求。为此，本文介绍如何通过开源组件搭建一个大数据安全分析平台，并且分享部分相关经验。本文主要从以下六个方面进行介绍：

1.平台框架

2.数据库设计

3.离线数据准备

4.Python2->3的升级

5.归一化注意事项

6.安全分析准备

一、平台框架

在日志管理方面有一套较为成熟方案就是ELK。ELK并不是指一个软件，而是指三个软件的组合：

E是指Elasticsearch，其主要负责日志的检索和分析。

L是指Logstash，其主要负责日志的收集、处理和存储。

k是指kibana，主要负责日志的可视化。

但如果直接采用上述所说的ELK来搭建大数据安全分析平台会存在一定的不足，因此我们需要对其进行一定的修改。

加入kafka

讲解为什么加入kafka之前，我们先了解下kafka是用来干什么的。Kafka用比较官方的话是具有高并发能力的一个消息队列或消息分发系统。如果官方的解释无法理解，那么请记住下面的解释：kafka是让合适的数据以合适的形式出现在合适的地方。

在大数据安全分析平台中我们需要一个规则引擎来做实时检测（后面会介绍规则引擎），而在规则引擎中常常需要检测时序的数据，因此对数据有着一定的要求。所以才需要引入kafka这个能让数据以合适的形式出现在合适的地方的组件。

了解了kafka是干什么和为什么加入kafka之后我们需要了解下一个问题：kafka这个组件应该放在框架中的哪个地方呢？在回答这个问题之前我们可以先简单了解下kafka的架构图：

通过上面图可以发现Kafka本质的工作是获取数据然后再把数据吐出去。而且上面我们提到过平台中是需要一个规则引擎做实时分析的，并且ELK中的Logstash是用来收集日志用的。因此我们可以把新加入的kafka放在logstash之后，规则引擎之前。这样做既可以以高容错的方式存储海量的数据，同时又可以保证数据的顺序性。

规则引擎

首先要介绍这里提及的规则引擎的概念：运行检测规则的实时计算引擎。在大数据安全分析平台中，我们需要对实时收集到的日志进行检测，一旦满足某种规则就产生对应的安全事件或安全告警。这对于处理时间有着有着较高的要求：近乎实时，因此我们需要在平台中加入实时计算引擎。

而在实时计算引擎技术中比较成熟的是Flink以及Spark，这里选用Flink作为我们的引擎，原因可以参考下面对两者之间的简单对比：

Flink

• 流式处理，延迟较小，吞吐量大。

• 提供状态管理，可以保存和更新状态信息。

• 一定容错性，出现故障后可以从离开的位置再次开始处理。

• 提供事件时间处理，窗口等功能，保证处理复杂需求的功能。

Spark

• 基于微批处理的流处理（并不满足低延时需求）。

• 同样支持容错性。

• 同样支持高吞吐。

• 调参较为麻烦。

• 高级功能并不十分丰富。

看完上述的简单对比应该明白为什么采用flink作为我们的规则引擎。这时候就又要思考另一个问题了：规则引擎应该放在平台的哪个位置。其实答案很简单，因为之前说过规则引擎的作用是检测收集到的日志然后生成安全事件或者安全告警，而安全事件或告警最终是要存入到ES数据库中的。因此规则引擎的位置应该是在ES数据库之前，kafka之后的。

至此，整个大数据安全分析平台的总体框架就出来了，如下图所示：

二、数据库设计

在上面平台框架中我们可以看到只是用了Elasticsearch数据库，是不是意味着在实际使用的过程中就不需要用到其他的数据库呢？答案是否定的，同样需要使用MySQL这类的关系型数据库。

本章节的主要目的是简单介绍在配置ES数据库和设计MySQL表时的相关注意事项，因为错误的配置或者表设计往往会导致数据库的性能降低以及带来难以言喻的使用体验。

Elasticsearch

在Elasticsearch中是把数据存放在一条条索引下的，因此如何设计一个索引非常重要。根据笔者日常使用和观察后总结为：

1.根据类型设置索引

大数据平台的数据源类型众多，如防火墙、IPS、主机端数据等。因此根据数据源的类型进行索引设计不仅能够简单的进行索引区分，更能够让使用者快速上手。如保存A防火墙数据的索引名可以为“logstash-wafA”，保存终端数据的索引名可以为“logstash-endpoint”。

2.根据时间或固定时间内的大小进行设置

根据时间建立索引，时间可以是一天或是以一个月为周期。但具体是设定为一天还是一个月则要根据对应数据的大小进行确定。像是上述提及到的安全事件和安全告警概念，两者的区别是：安全告警是安全事件的进一步提取产物，安全事件是直接从原始日志中提取的结果。根据安全告警和安全事件的关系可以得出结论：同一段事件内产生的安全告警数的确比安全事件少。因此安全告警相比安全事件而言更加适合以月为周期建立索引。

另外，在Elasticsearch中对字段进行搜索的前提是在配置中把该字段写入到索引中。通常写入索引中的字段有src_ip（源ip）、dst_ip（目的ip）、hostname（主机名）等常见字段，但在实际使用过程中往往需要对某些没有开启检索功能的字段进行搜索。这时候就给分析带来一定的挑战性：无法进行快速检索或不得不使用其他的字段或搜索条件进行搜索。而在Elasticsearch中如果开启太多字段进行搜索或搜索字段中的内容太冗长往往会导致性能的下降。因此哪些字段开启搜索功能需要谨慎考虑，争取性能和功能之间得到平衡。

MySQL

实际中通常是把用户的租户信息、身份关系等资料存放在MySQL的表中，而日常开发过程中往往是随着需求的变多而导致表数目的增多以及表之间的关系变得复杂，这同样对后续分析带来了一定的困难。

对于安全分析而言，更多的工作重心是对安全事件、告警进行分析然后进行响应。此时往往需要用到MySQL中的一些数据，尽管虽然有相关现成的接口可以获取到某些信息但更多时候不得不手动进行查询以获取真正想要的信息。这时候过多的表数量以及复杂的表关系将会导致花费大量的时间在此，从而导致降低分析的效率。

假设这样一个场景，需要获取两个资产出现的同样类型的告警，而这两个资产又分别在不同的网段和业务分组中，同时资产名字、资产网段信息和资产业务分组信息又分别存放在独立的表中，这是就需要先查看多张表的数据结构然后进行联合查询，最后再根据获取到的信息进行告警查询。分析上述的这个场景可以发现时间大部分都浪费在了获取表的相关信息中，从而大大减少了用于进行分析的时间。因此，实际情况中我们需要对表的数量以及表之间的关系进行一定程度的控制。

三、离线数据准备

在实际中面临着这样一种情况：大数据安全分析平台可能放置在无法访问外网的环境中，而平台中的部分功能却又依赖于外部的数据。面对这种可能出现的情况就需要提前准备离线数据，这种类型的数据包括但不限于：IP地理位置、威胁情报、漏洞信息等。

现有的大数据安全分析平台针对上述所说的数据都有着自家的离线版本，因此本章在这主要介绍如何通过开源手段进行离线数据收集。

IP地理位置

在对ip进行分析时一个较为重要的指标就是这个ip的归属地，因此很有必要拥有能进行查询ip地理位置归属地的数据库。而关于ip地址库的开源工具中，较为有名的莫过于ip2region这个工具。

对于ip2region工具的如何使用这里并不作过多的介绍，只需要知道这个工具的提点有以下几点便可：

1.标准化数据格式

2.数据库文件体积小

3.支持多客户端查询

4.查询速度极快

威胁情报

威胁情报能够揭示不同攻击者的攻击手段以及攻击之间的相互关系，同时又可以为安全事件/安全告警中的相关可疑项进行实锤，正因为有着这样的优点最近几年来这个概念非常火热，正因如此一个优秀的安全分析平台该功能是必不可缺的。

在开源的威胁情报中，比较著名的莫过于MISP了。MISP的中文名称为：开源威胁情报和共享平台，正如其名MISP可以用于收集、存储、分发和共享有关安全事件分析和恶意分析的网络安全指标和威胁。同样这里省略该工具的使用方法，只是略为介绍该工具的优点：

1.支持多种形式的数据导入、导出功能，这大大方便了和其他工具的联动性。

2.灵活的api，这说明可以快速上手、对接该工具。

3.丰富的IOC指标，这有助于提高发现风险的概率。

漏洞信息

获取漏洞信息这在传统安全时代就已经非常重要了，如今在数据分析平台中更是必不可缺的部分。这里推荐OpenVAS这一款工具来获取漏洞信息，其中文名是开放式漏洞评估系统，对于这款工具不熟悉的人只需要知道它是商业漏扫工具Nessus的开源版本即可。该工具最大的优点有两个，第一个是该工具以及其漏洞数据库定时更新，因此不用担心某天出现“断粮”的情况，另一个优点则是该工具所包含的漏洞信息是较为全面的，但毕竟是开源软件总有着它的局限性。

四、Python2->3的升级

时间已经来到了2020年，正是今年是Python2版本停止进行维护而Python2和3之间的代码并不兼容，因此如果此时继续使用2版本进行开发的话会为以后留下很多的问题。而实际上从Python2升级到3中往往会有很多坑的存在，在此简单总结如下：

1.升级后缺少动态链接库文件

在编译安装Python3后发现系统中缺少相关动态链接库文件而产生相关报错信息，但经过排查发现系统中却存在该文件，并且根据报错信息的提示需要我们更改gcc的相关配置。但gcc所涉及的东西较多，一旦修改很可能导致系统中产生其他未知的错误，因此需要在不修改gcc配置的情况下进行修复。在经过多方测试和查询资料后发现可以通过创建软链接的方式进行处理。

2.升级后依赖Python2导致死循环

在实际中往往会遇到一种比较搞笑的情况就是：Python版本升级为3后，运行yum或部分相关命令时提示你需要运行在版本2下。这种情况下网上给出的修复方案有很多，但有些修复方案如卸载版本2直接创建版本3的软链却会造成死循环的可能性。因为yum本身是基于python2开发的，一旦卸载后再重新安装则会导致yum的不可用，要是想使用yum还得重新把python2进行安装。建议在测试相关升级方案时在测试环境中进行测试，并确保没有错误的情况下再在生产环境中使用。

3.升级后没有相关的第三方库

Python是以丰富的第三方库而出名的，如果一旦出现版本2中有某一个第三方库而版本3中没有对应的库或对应库的功能不及版本2时，这就变成了一个较为头疼的问题：要么放弃该库，要么自己手动的对版本2的代码改造升级为版本3的代码。经过踩坑发现，比较高性价比的方法是采用兼容的写法。采用兼容的写法虽然也需要进行代码的改动，但改动量相比较少可以接受。同时也存在使用脚本把代码从版本2升级为3的效果，但使用脚本进行升级仍然可能会在实际运行中出错，建议进行多次测试。

五、归一化注意事项

先简单介绍归一化的概念：把不同格式日志中的字段映射到统一标准中。

在进行大数据安全分析平台时往往需要把不同设备、不同格式的日志进行收集，而日志中往往包含着大量有用的字段值。但不同日志之间对于同一个数据的名称可能是不一样，因此需要把他们映射到相同字段中。但在实际的使用中可能存在国内设备和国外设备同时使用的情况，这就导致日志格式甚至日志字段名相差较大的情况。这个时候最简单的做法就是除了功能效果相同的字段以外其余的字段采用并集的方法进行囊括，这样就不用担心出现该字段时无法进行映射的问题。

该做法的确是通用、可行的办法，但却会对安全分析时带来一定的困难：

1.通过查看映射后的标准你可以发现标准中存在很多有用的字段，但实际上日志中并没有提供该值。

这种情况往往会导致：如果想要把分析经验固化为脚本时，往往需要编写多个脚本：一个脚本可能是该字段值存在时使用，另一个脚本则为该值不存在时使用。久而久之这样的处理脚本会增多，最终出现难以维护的情况。

并且也会给人工分析带来一定的麻烦：在进行日志信息关联的时候必须先查看该字段是否有值，如果没有值时只能通过ip等基本元信息进行关联。但在复杂环境中，ip这样的元信息存在相同的情况（多网段情况下就可能存在ip一样的情况），因此稍不注意就可能得出错误的结果。

2.映射后的字段值越多，越容易存在名字相近或含义相近而导致的使用错误情况。

以常见的http日志中记录的URL为例，在归一化映射后的标准中可能存在相关字段名称为：xxxURL、URLxxx、interface、http.URL，面对类型名字相近或含义相近的字段名往往需要先查阅相关说明文档才能确定不同字段值之间的含义；而想获取某方面功能的字段时同样也需要输入相关关键字，然后再从匹配结果中进行一个个的查询，最终才能获取到想要的结果（尽管该字段往往没有值存在）。

因此，做归一化的确是一件好事，但是否需要过多的归一化后的字段这需要我们去进行思考和实际测试了。

六、安全分析准备

上面的几部分都是搭建安全分析平台以及相关踩坑的经验分享，接下来这部分则是介绍使用该平台进行分析前所需要做的准备工作。

基础工作

1.熟悉Elasticsearch语法

上面提到Elasticsearch是用于日志检索和分析用的，它有着它一套的查询语法，因此事先掌握它的语法能够很好的提升分析效率和速度。简单归纳了以下常用、简单的查询语法：

• 多条件值查询

  在实际分析过程中，往往需要对满足多个条件的结果进行查询，因此很有必要掌握多条件值查询语法。

• 模糊查询

  同样，在分析过程中可能会针对攻击手法进行某些关键字的查询，这个时候模糊查询就非常有效，它可以快速的把相关可能的结果收集起来。

• 范围查询

  在实际过程中往往需要根据字段值来匹配相关范围内的结果，这个时候就需要用到范围查询。

2.熟悉常见日志字段值

使用安全分析平台时往往要和各种各种的日志打交道，因此很有必要熟悉日志中的字段名以及字段值含义。这样在进行分析时能够快速从日志中提取到自己想要的字段，从而大大提升分析效率。

3. 熟悉关联引擎规则

关联引擎可以帮我们产生一定的安全事件或告警，因此只有在熟悉关联引擎规则的情况下才能在产生事件/告警时明白问题的严重性以及发展到哪一步程度，这样就能够为接下来的分析和处理流程提供一定的导向作用。

熟悉环境

1.了解网络拓扑结构

不同的网络环境所受到的攻击手法以及所暴露的攻击面都是不一样的，因此在进行分析之前很有必要了解当前网络拓扑架构。只有一个内外网出入口的环境一旦被攻击成功，攻击痕迹往往在出入口中都会被记录。而如果具有多个内外网出入口的环境被攻击成功进行分析就较为困难了，往往需要对攻击手法、暴露的风险点等特征进行分析取证后才能确认整个的攻击流程。

2.了解资产分布、分类情况

对环境中的资产分布、分类情况有一定的了解能够帮我们快速的判断相关安全事件或告警到底是否为误报。比如一个DNS服务器产生的http攻击事件/告警很大可能就是误报；一个内网服务器中产生的病毒木马告警则表明很有可能已经被攻击者攻击成功了。

3.了解历史安全问题

了解系统中的历史安全问题往往能给我们进行分析排查提供一定的思路：是旧的漏洞修复不完整导致的攻击成功？还是攻击者以前就已经留下木马后门呢？同时还能揭示该系统的脆弱性存在哪个地方，以便为后续的相关修复工作做准备。

七、总结

本文先是简单介绍了如何通过开源组件简易的搭建一个大数据安全分析平台，然后分享了部分搭建以及数据准备经验，最后引出安全分析的相关必备技能。

本章只是我们：如何利用那个大数据平台进行安全运营的开篇章节，后续会分享如何利用大数据平台进行安全告警分析、攻击溯源以及攻击确认的经验，有兴趣的朋友们可以留意后续更新。（梁广鹏）

PS：文章作者只是一名安全工程师，并不是一名后台开发人员。因此上述内容中可能存在部分偏差，请大家原谅并谢谢指点。

声明：本文来自腾讯安全智能，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。