开源SOC的设计与实践

开源SOC的设计与实践

作者:糖果

0×01 概要

开源日志系统分析很常见, 现在基于开源中间件可以很有效的搭建日志中心,处理各种数据的收集与分析。 日志系统也是信息系统,从软件工程的角度来看和一般的信息系统有很多类似的地方,我们可以从服务器物理部署的角度来解释这种系统,这种更多的是从运维角度来看,我们也可以从软件系统构成的角度来分析,也可以从数据流向看系统。我们这次把物理部署和软件逻辑系统放到一起,展示出整个系统的数据流向,数据存储和处理逻辑,也展示了从系统设计到插件工厂的实现逻辑。

1.png

0×02 需求

现实的需求很简单,就是从我们要从收集到日志数据中,分析各种可能存在威胁,按照高中低危进行报警,并统计威胁数据,进行报警与后续动作。

简化威胁定义表同,如下:

SRC_IP,DST_IP,LEVEL,TYPE

192.168.1,192.168.6,high,php_injection

192.168.1,192.168.6,middle,xss_injection

192.168.1,192.168.6,low,sql_injection

整个系统要做的就是:

1.数据收集:生产中很多服务器的日志和状态数据,我们都可以拿来分析。如果是nginx服务器,我们可以通过访问日志发现访问中的威胁,如果部署有HIDS,我们可以分析单机服务器的状态,并与长期聚合的白名单进行比对,发现威胁。

2.数据清洗:实际我们收集了大量的各种日志数据,这些数据,我们不能直接拿来用,初级阶段的日志分析和简单查找可以做到,之后,我们需要对数据的格式进行整形,如果进行威胁分析,就要把大量不关键的信息清洗掉。

3.威胁分析:我们的数据在先期经过了整型和规范化后,可以把数据与我们的威胁特征库进行比较分析,用我们积累的威胁特征库来威胁判断,发现数据中是否存在异常的威胁行为存在。

4.威胁展示:经过数据的清洗与威胁初步判断,我们找出了,存在于日常中日志中的威胁行为,我们需要对这些数据,按优先级,威胁高低程度显现,给安装安全运维人员使用。

5.威胁报警:在实际的工作中,会有各种威胁报警产生,但是真正危害到系统的关键性威胁,是有一个优先层级的,我们往往把优先级高,危害大的威胁行为,第一时间通知管理人员,比如:生产服务器发生与危险主机的外连通信,服务器产生了,根本不该产生的SQL注入行为。

0×03 数据收集与存储

我们尽量从现有的生产环境中,取得对我们来说有用的数据源信息,前期开源工具起动很大的作用,比如,我们用nxlog、filebeat之类的工具在服务上架设数据agent,架设syslog server服务器,使用共享ES数据集群, 在这个阶段我们关注数据源来源,数据内容,接受的方式,部署数据agent的平台环境,这是构建数据日志信息系统必经的一条路。

2.png

数据存储:

1.Syslog服务器: Syslog是基于UDP协议的,很多设备都支持syslog日志传送,生产中有很多nginx为基础的web应用,nginx也可以发送syslog格式的日志。

2.ES数据库服务器集群:ES对于存JSON形式的数据非常友好,我们可以把syslog数据进行数据整形存到ES中。

3.Kafka队列:有时数据IO特别大时,需要一个缓存来存数据,然后再消费到ES或是ClickHouse中。

4.ClickHouse:ClickHouse支持大数据存储,可以支持SQL查询。

5.MongoDB:这种KV数据库几乎也是要用的,用于存放共享配置信息。

6.Graylog数据网关:如果我们支持通过HTTP接口去ES中取数据,要处理跨index的查询,而实际当中,如果可以把ES的操作按业务单元再抽象出一层,把对业务数据的操作,归并成大类的REST API操作,会让处理逻辑更清晰,更好维护,这种情况下,Graylog提供的REST服务就为我们解决了这个问题,Graylog提供了原始数据“流”数据组织的跨越,具体的此处不细说。

数据收集:

1.NxLog:Nxlog是支持跨平台的系统级日志收集,我们可以在Windows好部署Nxlog解决特定日志的收集问题。

2.CatKafka:catkafka可以把本地落地的日起文本推送到kafka队列中,然后从队列中消费到ES或是ClickHouse中。

3.Logger:这个就是把文本放到syslog服务器接受端口。

4.Filebeat:把文本内容发到ES中。

0×04 威胁分析处理

既然威胁分析系统也是信息系统的一种,我们把重点放在,如果对系统划分,如果对接,如果组织和设计程序单体这些点上。如果,我们系统是基于ES为数据库为基础核心,或是Graylog这种提供了REST API的数据查询接口服务的系统,我们可以很简单的划分组织数据,通过一套REST API就可以取得我们想要的日志数据。日志数据有了,如何识别日志中是否有威胁行为,就是要针对不同的数据源做分析工作,就是构建整威胁分析系统的大脑灵魂部分,我们要有根有据的识别出那些数据是有问题的, 威胁分析过程如下:

1.取特定业务数据源的数据。->2.与威胁规则库进行比较。->3.判断结果根据黑白名单。->4.进行威胁定级。->5.生成威胁报告。

3.png

完成这些事,关键的3个点:

1.数据源:没有数据源无从进行分析。

2.判断策略:对威胁和异常的定义,是我们判断的主要依据,实际生产中,有各种威胁,这种威胁的定义都是不一样,我们只有有这种对异常的判断依据,才能分析出什么是问题行为。

3.黑白名单:威胁报警噪音,各种系统和设备的误报其实是一直存在,我们实际事况也很复杂,应对误报比较有效的一种方式,就是构建黑白名单机制,把明显的误报都放到白名单里,把特别需要注意的,出现过问题的服务列表放到黑名单里。

4.png

数据分析:

从软件系统设计的角度来看,3个角度来分析信息系统:

1.架构设计:整体的架构设计很明了,基于ES和ClickHouse为数据存储核心,围绕核心写子系统。

2.概要设计: 如果非系统的概要级描述, 从技术角度来看,我们采用插件方式组织模块,从业务上来讲,SQL注入和PHP注入的关联性是不大的,我们采用插件的方式也是为了解开模块间的耦合关系。

3.单元插件设计: 体现出单体设计大不同,可以从单体类的接口设计和目录构成来区分。

0×05 模块单体设计

1.单体设计:

模块对象接口设计:为了使用类工厂集中调度模块,我们预定了插件模块必须要有接口函数。

5.png

/*定义单体可处理的输入数据*/class input_data {string src_ip,string dst_ip,string payload};/*定义单体输出的数据型态*/class output_data {string src_ip,string dst_ip,string payload,int level};class xxx_Injection {vritual int Init(void); // 负责所有相关外部数据资源的获取和黑白名单的设置。virtual output_data* main(input_data *message); // 主要的威胁判断和特征判断。virtual int fin(void); // 释放相关资源};

6.png

2.目录构成设计

我们除去预定的接口,同时约定了插件目录结构构成。

lib、src、data、config文件夹,Makefile、run.sh、logs三个文件。

lib文件夹:所有的特征库都在这里,比如libInjection这个库。

src文件夹:插件的源代码。

data文件夹:单体测试用的CSV文件。

config文件夹:黑白名单配置文件。

Makefile文件:单体配置文件。

run.sh文件:运行脚本。

logs文件:调试日志。

3.代码实现。

有了特征库,预定了接口,剩下就是具体的编码,这个因项目和数据业务而不同,占不展示。

0×06 威胁报表与报警

7.png

整个系统起到点睛作用的部分就是威胁报告输出,最开始我们简单的约定了威胁输出了的格式:

1.威胁输出格式。

SRC_IP,DST_IP,LEVEL,TYPE

192.168.1,192.168.6,high,php_injection

192.168.1,192.168.6,middle,xss_injection

192.168.1,192.168.6,low,sql_injection

如果是在ClickHouse生产系统中创建威胁表格要比这个多,字段和展现的数据聚合是有关系的,我们简单的举例一下:

SRC_IP:攻击IP,是谁发起的IP,我们可以对应IP在表中产生地理位置信息,典型的报表形式就是用于地图跑。攻击IP是可以威胁情报进行比对的。

DST_IP:被攻击IP,具体那个服务器被攻击,一般的公司都有服务器管理的CMDB数据库,可以在生成报告时,直接找到对应的IDC、机房、管理员。

LEVEL:威胁级别,高中代危,看黑白名单和特征库的定级。

TYPE:具体是什么威胁,比如:SQL注入、XSS注入、PHP注入。

2.威胁报告的形式。

邮件: 每天早上发送昨天的攻击总结日报告、周报告、月报告等。被威胁IP的top10、被攻击总数top10、威胁聚合分布。

实时报告:提供实时查询接口,直接给出ClickHouse威胁情报的聚合信息,实时查询挂在墙上。

0×07 总结

目前我们把一个基于开源技术的微型日志威胁分析系统介绍完了,并没给出更具体的实现代码,更多的为基础部署架构和设计方式提代了一个思路,具体到包括单体接口实现的约定,理想状态下,按照这种模式写出的模块的大同小异,我们这么预定也是为了后续系统扩展和调试更方便。如果有人不太喜欢这种方式,其实也是没有问题,一定会有更好更高效的方式处理系统的设计和实现,然后呢?然后我们后续会更具体针对某一些特定业务,给出对应业务插件的实现。

Tags: