如何自行搭建一个威胁感知大脑 SIEM?| 硬创公开课
近年来态势感知、威胁情报等等新词不断出现,其实万变不离其宗,它们都是利用已知的数据来判断风险,甚至预知未发生的威胁。这如同一个老练的探险者孤身穿行在原始丛林,他能轻巧自然地避开蛇虫鼠蚁,用脚印来预知猛兽的威胁。这一切都依赖于他那颗善于思考,经验丰富的大脑。
在网络安全的原始森林里,SIEM就扮演这样一个威胁感知大脑的角色。如何在合理成本下打造一个最为强大、合适的 SIEM 系统,是许多安全人员头疼的问题。雷锋网有幸邀请到了拥有十年安全产品经验的百度安全专家兜哥,为大家讲解如何使用开源软件搭建企业的SIEM系统。
嘉宾简介
兜哥,百度安全专家,具有十年云安全产品经验,主要研究方向为机器学习、僵尸网络、威胁情报、沙箱技术、具有多年企业安全建设经验,拥有安全方向相关专利多项;发表多篇安全学术论文。
【百度安全专家-兜哥】
公开课内容整理
▼
雷锋网(公众号:雷锋网)按:由于本次公开课偏向实操,涉及到许多的实际操作和代码示例,限于篇幅就不一一展示,文章下方附本次公开课视频,有兴趣的读者可以自行观看,本文主要以展示思路为主。了解技术细节可以关注兜哥的个人公众号:“兜哥带你学安全”,和兜哥本人进行技术交流。
前言
在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接口
这些通过短期加白可以有效解决,比较麻烦的是扫描器对结果的影响,这部分需要通过扫描器指纹或者使用高大上的人机算法来去掉干扰。
兜哥后记
使用算法来挖掘未知攻击行为是目前非常流行的一个研究方向,本文只是介绍了其中比较好理解和实现的一种算法,该算法并非我首创,不少安全公司也都或多或少有过实践。篇幅有限,这里不再一一讲解。算法或者说机器学习本质是科学规律在大数据集集合上趋势体现,所以很难做到精准报警,目前阶段还是需要通过各种规则和模型来辅助,不过对于挖掘未知攻击行为确实是一支奇兵。
雷锋网注:由于本次公开课偏向实操,涉及到许多的实际操作和代码示例,限于篇幅就不一一展示,本文主要以展示搭建思路为主,细节代码可以在兜哥的个人公众号:“兜哥带你学安全”, 可以和兜哥本人进行技术交流。
公开课视频
课后答疑整理
以下内容为公开课后宅客频道读者提问答疑记录:
1.宅客:自己用开源项目搭建SIEM系统时,容易遇到哪些坑?哪些环节需要额外注意?
兜哥:容易遇到的是性能问题,还有对开源软件不太熟悉,因为确实我们刚接触时都是比较新的东西,帮助文档比较少,容易造成理解上的问题。
其次是攻击建模,这个很靠经验,传统SIEM就是误报特别多。我们的做法是:先离线训练规则,误报可控后直接在storm实时处理,基本最后能做到分钟级发现。
另外,在流量搜集上挑战很大,传统的 libpcap 性能差,基本只能处理几十兆带宽,需要使用 pf-ring ,基本可以单机处理 2-6G 带宽(全量处理)
2.宅客:公司自己人搭建一个SIEM和买商业SIEM产品如何选择,适用于哪类规模的公司?(考虑实际人力、时间成本和效益)
兜哥:中型(1000人左右的)公司,可以有3个人以上投入时,可以自己搭建 opensoc 这种。如果公司规模小些,只能投入一个人建议用ossim , 每天数据量几十G的,ossim 可以搞定。
整个搭建成本,时间一般三个月可以搞定,但是规则的积累是个长期过程。我们差不多搞安全这么多年,一直都在丰富模型和规则,出现漏洞还要及时跟进。
3.在检索威胁情报这一块,有什么特殊的信息收集手段吗?
兜哥:Openioc 可以订阅开源的情报,量已经非常大了。国内的威胁情报厂商比较多,比如微步在线。呃……黑产库的积累其实比较靠人缘,合法性其实一直是个灰色地带,你懂得。
4.宅客:威胁情报这块,百度的人工智能有什么应用吗?
兜哥:应用比较多,比如从云端的海量数据中,针对一直威胁的样本 dns 使用聚类等算法,识别潜在的有关联的,未知的样本 dns。
通过安全运营中心的人工识别,挖掘未知攻击行为,然后以可机读的方式推送给我们的 WAF、ADS、IDS , AI 一大应用就是从已知样本以及海量数据中挖掘未知,这个算法应用很多。
4.宅客:neo4j 将结构化数据存储在网络上,数据量打了会不会搞不定?
兜哥:会的,这里(公开课直播)只是演示,可以用 sparkx,而且 neo4j 也有集群方案,不过问题其实还好,因为我们是动态请求去重,抽象后才入库,量其实不大,1T数据量入库可能不到100M。
5.宅客:能不能提供一些SIEM具体应用场景,数据分析模型,或者推荐一下在那里获得?
分析webshell 用有向图效果不错,其他web攻击,尤其是攻击载荷在请求参数里面的用隐式马尔可夫可以。
6.宅客:网络设备的设备接入的数据价值大吗?有必要接吗?
兜哥:网络设备系统日志可以监控对网络设备的暴力破解、违规操作等,netflow可以辅助判断蠕虫、ddos等。
8.宅客:网络入侵检测( network instusion detection ) ,你们有啥好算法?
兜哥:关联算法 apriori 图算法、异常分析算法比如hmm 隐式马尔可夫。
本堂公开课PPT资料下载
在公众号“宅客频道”(ID:letshome),回复:“兜哥”,即可获得此次公开课PPT。
雷锋网原创文章,未经授权禁止转载。详情见转载须知。
文章点评:
最新评论
-
rong673 03月31日 10:40不错啊