分类 技术 下的文章

什么是OpenSOC

思科在BroCON大会上亮相了其安全大数据分析架构OpenSOC(由Cisco和Hortonworks共同开发),引起了广泛关注。OpenSOC是一个针对网络包和流的大数据分析框架,它是大数据分析与安全分析技术的结合,
能够实时的检测网络异常情况并且可以扩展很多节点,它的存储使用开源项目Hadoop,实时索引使用开源项目ElasticSearch,在线流分析使用著名的开源项目Storm。

OpenSOC是大数据安全分析的框架设计,对数据中心机排放数据进行消费和监控网络流量。opensoc是可扩展的,目的是在一个大规模的集群上工作。

OpenSOC能做什么?

  • 可扩展的接收器和分析器能够监视任何Telemetry数据源
  • 是一个扩展性很强的框架,且支持各种Telemetry数据流
  • 支持对Telemetry数据流的异常检测和基于规则实时告警
  • 通过预设时间使用Hadoop存储Telemetry的数据流
  • 支持使用ElasticSearch实现自动化实时索引Telemetry数据流
  • 支持使用Hive利用SQL查询存储在Hadoop中的数据
  • 能够兼容ODBC/JDBC和继承已有的分析工具
  • 具有丰富的分析应用,且能够集成已有的分析工具
  • 支持实时的Telemetry搜索和跨Telemetry的匹配
  • 支持自动生成报告、和异常报警
  • 支持原数据包的抓取、存储、重组
  • 支持数据驱动的安全模型

是不是很强大?

OpenSOC运行组件包括哪些?

intro.jpg

  • 两个网卡(建议使用Napatech的NT20E2-CAP网卡)
  • Apache Flume 1.4.0版本及以上
  • Apache Kafka 0.8.1版本及以上
  • Apache Storm 0.9版本及以上
  • Apache Hadoop 2.x系列的任意版本
  • Apache Hive 12版本及以上(建议使用13版本)
  • Apache Hbase 0.94版本及以上
  • ElasticSearch 1.1版本及以上
  • MySQL 5.6版本及以上等。

据说,能把这个框架跑起来的人不多。

OpenSOC组成部分(核心)

OpenSOC-Streaming:这个库包含了拓扑结构的加工、丰富,索引,及相关的信息,PCAP重建服务,以及其他各种数据服务。可以在GitHub下载:https://github.com/opensoc/opensoc-streaming

OpenSOC-UI:操作界面,日志和网络数据包的分析,显示警告和错误。可以在GitHub下载:https://github.com/opensoc/opensoc-ui

OpenSOC深入剖析

OpenSOC框架是大数据分析框架的衍生

先来看看OpenSOC概念性框架,总体来说,就是分为三个部分:左侧为数据输入(采集),中间为数据处理(计算),右侧为数据分析(展现和输出)。

arc1.jpg

再来看看其数据流框架,在概念性框架的基础上,把每一步的功能组件都一一列清楚了。分为六个部分:

  1. Source Systems,数据输入源,分为主动和被动两种方式;
  2. Data Collection,数据收集,主要采用Flume进行数据收集和预处理,PCAP进行抓包收集;
  3. Messaging System,消息系统,主要是Kafka分布式消息系统进行数据缓存,根据数据源不一样来划分不同的topic;
  4. Real Time Processing,实时处理,主要采用Storm实时计算框架进行数据整理,聚合,DPI分析,等,这里,每个kafka topic都需要单独的storm 应用程序来独立处理;
  5. Storage,存储,就是把计算的结果和原始数据写入相应的存储模块,原始数据存入Hive,日志数据存入ElasticSearch便于索引查找(结合kibana),抓包数据存入HBase;
  6. Access,访问层,简单说就是把分析结果数据从存储中取出来,通过各种BI工具渲染到页面,当然,也可以把数据以web service的方式提供给第三方。

arc2.jpg

赛克通公司在大数据处理方面,也有自己的一套计算框架,此框架可调整性相对较大,可以根据用户数据体量,计算要求灵活变换。

sectong_arc.jpg

核心计算模型

OpenSOC核心计算模型采用Storm来负责处理,前面提到过,每个设备或数据流,都需要单独的storm应用程序(topology,拓扑)来进行运算,这个对于部署storm应用的时候特别要注意了。
当然,storm是分布式计算框架,应用程序多的话只需要增加物理计算机就能解决,不是什么大问题。

PCAP分析拓扑

pcap.jpg

由图示可以看出,storm的kafka spout获取到的pcap数据,经过基本解析后即存入相应的存储模块,并没有太多的计算内容。这个相对而言比较容易理解。

DPI分析拓扑

dpi.jpg

由图示看出,DPI拓扑中,计算引擎做的功能比pcap多了许多,中间关联了很多其他模块,比如:whois查询,GEO地址定位等,丰富了分析的内容。
由此可以联想到,在DPI拓扑中,我们可以增加其他的第三方关联,比如:botnet僵尸网络知识库,ip reputation数据库(ossim提供),舆情数据库等,这样这个计算框架就强大了许多,可以做的分析也就更多。

Enrichment高级分析

enrichment.jpg

高级分析模块详解,这里把每个步骤的数据流都做了对照,GEO信息来自MySQL数据库,whois信息和CIF来自HBase数据库。

更多的关于最佳实践和学习,请参照官方发布的PPT内容。

OpenSOC 改进建议

总体框架性改进

improve.jpg

总体框架上,可以让OpenSOC更加灵活一些,处理流程可以更加简化一些。比如:由storm计算完成之后,不一定由storm直接写入相应存储(mysql,hive,hbase,es等),
而是再次丢入kafka(其他应用和计算框架还能重复利用),由另外的程序来进行执行写入操作,这样减轻了storm的负担,增加了灵活性。

处理引擎类改进

spark_replace_storm.jpg

大数据工程师都知道,storm是实时处理引擎,时效性非常好。但是,需要加入机器学习或SQL引擎时,storm就失色了。这时候,Spark来了,有可能替代hadoop的引擎出现了,对于应用开发更加轻松。不多说,上图。

storm_vs_spark.jpg

可视化引擎改进

我们都知道,OpenSOC可视化引擎用的kibana,kibana能做的事情很多很多,当然,kibana对于elasticsearch非常合适,其他的就不一定了。所以,必须要结合相应的BI工具,比如:Tableau,Power Pivot等。
如果由spark代替了storm作为计算引擎,可以在可视化框架中加入zeppelin(一个基于spark的开源可视化notebook工具),直接在zeppelin中将业务逻辑梳理好,这样更加快速的加速spark的开发。
关于zeppelin的详细信息请参见【数据可视化】Zeppelin JDBC 数据可视化(WEB方式)