作者:兜哥
来源:https://www.leiphone.com/news/201703/hUizFhBz5GAQQ5Jw.html

前言

在RSA2017会议上,应用大数据技术在安全领域,挖掘深入的攻击行为依然是一个热点。

SIEM简介

市场调研机构IDC预计,未来全球数据总量年增长率将维持在50%左右,到2020年,全球数据总量将达到40ZB。一个中型互联网公司一天产生的数据量通常可以超过几T甚至几十T。传统的盒子形式的安全产品已经没有能力处理如此大量的数据。

SIEM(security information and event management),顾名思义就是针对安全信息和事件的管理系统。SIEM通过统一搜集、格式化、存储、分析企业内部的各类日志、流量数据,挖掘攻击行为。

完整的SIEM至少会包括以下功能:

  • 漏洞管理
  • 资产发现
  • 入侵检测
  • 行为分析
  • 日志存储、检索
  • 报警管理
  • 酷炫报表

其中最核心的我认为是入侵检测、行为分析和日志存储检索。

SIEM的发展

对比 Gartner2009 年和 2016年的全球SIEM厂商排名,可以清楚看出,基于大数据架构的厂商Splunk迅速崛起,传统四强依托完整的安全产品线和成熟市场渠道,依然占据领导者象限,其他较小的厂商逐渐离开领导者象限。最重要的存储架构也由盘柜(可选)+商业数据库逐渐转变为可横向扩展的大数据架构,支持云环境也成为趋势。

开源SIEM

常见的开源SIEM主要有 OSSIM 和 OPENSOC,其中 OPENSOC 完全基于大数据架构,更适合目前的中大型企业。OPENSOC 是思科2014年在 BroCon 大会上公布的开源项目,但是没有真正开源其源代码,只是发布了其技术框架。我们参考了 OPENSOC 发布的架构,结合公司实际落地了一套方案。

OPENSOC 完全基于开源的大数据框 架kafka、storm、spark 和 es 等,天生具有强大的横向扩展能力。本文重点讲解的也是基于 OPENSOC 的 SIEM 搭建,以及简单介绍如何使用规则和算法来发现入侵行为。

SIEM架构

上图是Opensoc给出的框架,初次看非常费解,我们以数据存储与数据处理两个纬度来细化,以常见的 linux 服务器 ssh 登录日志搜集为例。

数据搜集纬度

数据搜集纬度需求是搜集原始数据,存储,提供用户交互式检索的UI接口,典型场景就是出现安全事件后,通过检索日志回溯攻击行为,定损。

logtash其实可以直接把数据写es,但是考虑到 storm 也要数据处理,所以把数据切分放到 logstash,切分后的数据发送 kafka,提供给 storm 处理和 logstash 写入 es。数据检索可以直接使用 kibana,非常方便。数据切分也可以在 storm 里面完成。

这个就是大名鼎鼎的ELK架构。es比较适合存储较短时间的热数据的实时检索查询,对于需要长期存储,并且希望使用hadoop或者spark进行大时间跨度的离线分析时,还需要存储到hdfs上,所以比较常见的数据流程图为:

数据处理纬度

这里以数据实时流式处理为例,storm 从 kafka 中订阅切分过的ssh登录日志,匹配检测规则,检测结果的写入 mysql 或者 es。

在这个例子中,孤立看一条登录日志难以识别安全问题,最多识别非跳板机登录,真正运行还需要参考知识库中的常见登录IP、时间、IP情报等以及临时存储处理状态的状态库中最近该IP的登录成功与失败情况。比较接近实际运行情况的流程如下:

具体判断逻辑举例如下,实际中使用大量代理IP同时暴力破解,打一枪换一个地方那种无法覆盖,这里只是个举例:

扩展数据源

生产环境中,处理安全事件,分析入侵行为,只有ssh登录日志肯定是不够,我们需要尽可能多的搜集数据源,以下作为参考:

  • linux/window系统安全日志/操作日志
  • web服务器访问日志
  • 数据库SQL日志
  • 网络流量日志

简化后的系统架构如下,报警也存es主要是查看报警也可以通过kibana,人力不足界面都不用开发了:

消息队列:kafka

Kafka是一种高吞吐量的分布式发布订阅消息系统,有如下特性:

  • 通过O(1)的磁盘数据结构提供消息的持久化,这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。
  • 高吞吐量 :即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。
  • 支持通过Kafka服务器和消费机集群来分区消息。
  • 支持Hadoop并行数据加载。

流式处理:storm

Apache Storm 是一个免费开源的分布式实时计算系统。简化了流数据的可靠处理,像 Hadoop 一样实现实时批处理。Storm 很简单,可用于任意编程语言。

Storm 有很多应用场景,包括实时数据分析、联机学习、持续计算、分布式 RPC、ETL 等。Storm 速度非常快,一个测试在单节点上实现每秒一百万的组处理。

storm拓扑支持python开发,以处理SQL日志为例子:

假设SQL日志的格式是

"Feb 16 06:32:50 "  "127.0.0.1" "root@localhost" "select * from user where id=1"

一般storm的拓扑结构:

简化后 spout 是通用的从 kafka 读取数据的,就一个 bolt 处理 SQL 日志,匹配规则,命中策略即输出”alert”:”原始SQL日志”。

数据搜集:logstash

  • Logstash是一款轻量级的日志搜集处理框架,可以方便的把分散的、多样化的日志搜集起来,并进行自定义的处理,然后传输到指定的位置,比如某个服务器或者文件。

  • 当然它可以单独出现,作为日志收集软件,你可以收集日志到多种存储系统或临时中转系统,如MySQL,redis,kakfa,HDFS, lucene,solr等并不一定是ElasticSearch。

logstash的配置量甚至超过了storm的拓扑脚本开发量,这里就不展开了。

实时检索:ElasticSearch

ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎,基于RESTful web接口。Elasticsearch是用Java开发的,并作为Apache许可条款下的开放源码发布,是当前流行的企业级搜索引擎。设计用于云计算中,能够达到实时搜索,稳定,可靠,快速,安装使用方便。

数据源

生产环境中,处理安全事件,分析入侵行为,我们需要尽可能多的搜集数据源,以下作为参考:

  • linux/window系统安全日志/操作日志
  • web服务器访问日志
  • 数据库SQL日志
  • 网络流量日志

数据库日志搜集

常见的数据日志搜集方式有三种:

镜像方式

大多数数据库审计产品都支持这种模式,通过分析数据库流量,解码数据库协议,识别SQL预计,抽取出SQL日志

代理方式

比较典型的就是db-proxy方式,目前百度、搜狐、美团、京东等都有相关开源产品,前端通过db-proxy访问后端的真实数据库服务器。SQL日志可以直接在db-proxy上搜集。

客户端方式

通过在数据库服务器安装客户端搜集SQL日志,比较典型的方式就是通过logstash来搜集,本文以客户端方式进行讲解,其余方式本质上也是类似的。

logstash配置

安装

下载logstash https://www.elastic.co/downloads/logstash 目前最新版本5.2.1版

开启mysql查询日志

mysql查询日志

配置logstash

运行logstash

命令:bin/logstash -f mysql.conf

日志举例

常见攻击特征

分析攻击特征,下列列举两个,更多攻击特征请大家自行总结:

特征一:

使用联合查询枚举数据时会产生大量的NULL字段。

特征二:

枚举数据库结构时会使用INFORMATION_SCHEMA,另外个别扫描器会使用GROUP BY x)a)

注意的是:

  • 生产环境中的规则会比这复杂很多,需要你不断补充,这里只是举例
  • 单纯只编写map会有大量的重复报警,需要开发reduce用于聚合
  • 应急响应时需要知道SQL注入的是那个库,使用的是哪个账户,这个需要在logstash切割字段时补充
  • 应急响应时最好可以知道SQL注入对应的链接,这个需要将web的accesslog与SQL日志关联分析,比较成熟的方案是基于机器学习,学习出基于时间的关联矩阵
  • 客户端直接搜集SQL数据要求mysql也开启查询日志,这个对服务器性能有较大影响,我知道的大型公司以db-prxoy方式接入为主,建议可以在db-proxy上搜集。
  • 基于规则识别SQL注入存在瓶颈,虽然相对web日志层面以及流量层面有一定进步,SQL语义成为必然之路。

CASE:后门识别

这里介绍如何用图算法是被webshell。

webshell特征

webshell特征其实很多,从统计学角度讲,有如下特点:

  • 入度出度均为0
  • 入度出度均为1且自己指向自己

neo4j

neo4j是一个高性能的,NOSQL图形数据库,它将结构化数据存储在网络上而不是表中,因其嵌入式、高性能、轻量级等优势,越来越受到关注。

导入数据

可生成有向图如下:

查询入度为1出度均为0的结点或者查询入度出度均为1且指向自己的结点,由于把ref为空的情况也识别为"-"结点,所以入度为1出度均为0。

优化点:

生产环境实际使用中,我们遇到误报分为以下几种:

  • 主页,各种index页面
  • phpmyadmin、zabbix等运维管理后台
  • hadoop、elk等开源软件的控制台
  • API接口

这些通过短期加白可以有效解决,比较麻烦的是扫描器对结果的影响,这部分需要通过扫描器指纹或者使用高大上的人机算法来去掉干扰。

兜哥后记

使用算法来挖掘未知攻击行为是目前非常流行的一个研究方向,本文只是介绍了其中比较好理解和实现的一种算法,该算法并非我首创,不少安全公司也都或多或少有过实践。篇幅有限,这里不再一一讲解。算法或者说机器学习本质是科学规律在大数据集集合上趋势体现,所以很难做到精准报警,目前阶段还是需要通过各种规则和模型来辅助,不过对于挖掘未知攻击行为确实是一支奇兵。

点击收藏 | 0 关注 | 0
登录 后跟帖